Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Peter Naur's view of programming

hiringengineersbook.com

Post reply on HN
Print view View original

141–150 of 198 posts

Re: Peter Naur's view of programming

#141

Post by sriku »

mssundaram wrote: post #124
QuercusMax wrote: post #29

The point about theory-building requiring (or at least being accelerated by) interpersonal communication / teaching rings very true. In the middle of last year, my team went through a major re-org, and I'm now working with a whole bunch of new teammates. My project didn't get cancelled in the reorg; in fact, it's actually come to more prominence due to synergy in the projects we work on. Essentially my new teammates…

> All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated. It doesn't have to be that way, but if that's new to you and your team, I can understand that happening

One of the complaints about remote work at my company that I keep hearing (and also feel myself) is that our staff miss having "random" conversations. I quote random, because it isn't about the literal randomness, but kind of closer to "unstructured and unintended" conversations. We run an ideation-to-prototype event at the company and currently the teams are struggling with ideation that used to happen in such a "random" manner rather easily in person.

Re: Peter Naur's view of programming

#142

Post by striking »

sriku wrote: post #141
mssundaram wrote: post #124

Earlier quoted context omitted.

> All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated. It doesn't have to be that way, but if that's new to you and your team, I can understand that happening

One of the complaints about remote work at my company that I keep hearing (and also feel myself) is that our staff miss having "random" conversations. I quote random, because it isn't about the literal randomness, but kind of closer to "unstructured and unintended" conversations. We run an ideation-to-prototype event at the company and currently the teams are struggling with ideation that used to happen in such a "ra…

At my workplace, we have a few blocks of time scattered around the schedule for teammates to just jump in and code with other people. No agenda, no one is required to join. But a few always do, because it's so pleasant.

Re: Peter Naur's view of programming

#143

Post by sriku »

This seems to offer a criterion to decide the value of a business - if your business ceases to be one by publishing all your source code free to use, then you should look at other business models?

Is ElasticSearch (the company) then just a "bad business model"? Won't Google suffer if Amazon just waits for them to release their code and turns it into a managed service in competition? (Both companies are eminently capable here).

Re: Peter Naur's view of programming

#144

Post by IggleSniggle »

CryptoGhost wrote: post #76
IggleSniggle wrote: post #55

I am sometimes guilty of reading the comments before reading the article. I often find the reactions more concise, insightful, and valuable to me than the source material. That said: If you are reading this comment and haven’t read the article, go read the article instead. This is an inverse scenario: imho most of the comments here are interesting but have only marginal value building from the insight of the article.

The author doesn't make a good case for "The main value of a software company is the mapping of source code and problem space in the developer’s heads" being a universal truth. There are some problem domains and practical development and deployment roadblocks that simply make certain source code more valuable than others. Nowadays it seems people are more willing to throw money at open sourcing solutions so competing…

I agree, but at least for me, this did not diminish the value of the article.

Re: Peter Naur's view of programming

#145

Post by IggleSniggle »

gfody wrote: post #79
IggleSniggle wrote: post #50

Earlier quoted context omitted.

I disagree. It’s the offloading of a decision space very carefully explored. Perhaps “language” and “syntax” can be generalized (ie “excrement”), but the ability to offload a decision space about how to react to a given scenario, without requiring someone to be actively thinking about the minutiae of the problem space, will always have value. Whether that takes the form of a dependency graph in a software application…

if source code takes the form of human language I would no longer call it source code - it still might be excrement but not necessarily so.

I feel as though many problem spaces are already expressible in human language, but that “code” is just a more concise expression of the same thing.

The main issue with common language encoding is dialect (this happens in code, too, especially “common” languages like C++, Java, or JavaScript). That is to say, the assumptions you bring with you about what for example a “schedule” is affects all subsequent decisions based on it, but there are many possible interpretations for the semantics of such a thing.

It seems to me that most programming languages of today are better than “human language.” They more concisely AND precisely express the decision space.

I assumed “better tooling” meant some deeper heuristic wherein you might expect an AI to interpret your meaning based on your own enculturation, accepting the high subjectivity of any request/definition and producing an output formed by these assumptions.

I would still call this “source code” however, in much the same way that legal precedent is the source code for the next legal decision.

Re: Peter Naur's view of programming

#146

Post by learc83 »

QuercusMax wrote: post #68
rorykoehler wrote: post #40

Earlier quoted context omitted.

Remote work should help you in this case. Writing and reading are scalable. 1:1’s are not for explaining how stuff works and why. If you don’t write this all down then you are introducing risk and key person dependency.

Unfortunately for me, I started developing really bad RSI around January of last year, and typing has been incredibly painful. In the past I would have discussed things using whiteboards, sitting down side-by-side with code, etc.; these are all very hard to do if typing causes pain. Interactive sessions are also very helpful, as there are so many assumptions and background material baked into things that often take a…

Dragon works very well for dictation, and a Wacom style tablet works great as a remote substitute for whiteboarding.

There are also voice coding solutions like Talon voice that work well (I use it regularly).

Re: Peter Naur's view of programming

#147

Post by lmm »

btilly wrote: post #43
cloogshicer wrote: post #10

Earlier quoted context omitted.

> Most apps aren't in such a difficult space and keep working basically forever. Sadly, this doesn't match my experience. Software that isn't actively maintained always dies, sooner or later.

Whether this is true depends on what you do. The last update to TeX (widely used in math and computer science for typesetting) was 12 January 2014. A lot of payment processing systems are still running on code written in the 1960s and 1970s. Frequently untouched since Y2K. I have a friend who went to work in the mid 2000s for a company she had worked for in the early 1970s. Out of curiosity she looked up her old prog…

> The last update to TeX (widely used in math and computer science for typesetting) was 12 January 2014.

But if you want to actually use it you'll install a much more recent distribution - probably texlive from 2020.

Re: Peter Naur's view of programming

#148

Post by nojvek »

I resonated very strongly with the Theory of problems. At my last place I was very productive. Revamping their deploy system, frontend infra, had my hands in a lot of things.

However my pay wasn’t going up by much. I left for a new company and I feel like a noob having to re-learn things. It’s prolly going to take me an year to produce more value than I get paid.

Old company prolly had to replace me and spend 200k*2 years to get same context.

Very few companies understand the essence behind retaining good people. Promoting can be wayyy cheaper than having to hire someone new.

It really pisses me off when this happens to female and minority engineers. They frequently get looked down upon and left out for well deserved promos.

If you care about diversity, retain and grow your existing team. It’s cheaper and faster.

Re: Peter Naur's view of programming

#149

Post by quelsolaar »

gamacodre wrote: post #107
DavidAdams wrote: post #103

Earlier quoted context omitted.

Yeah, my first thought after reading that anecdote was that the new COO should have been fired.

And the CTO too, for caving to that argument.

A team that needs 6 months to get their code running on a computer on-premise, might also be replaceable. Maybe the lesson is that that team that produces source code without value.

Re: Peter Naur's view of programming

#150

Post by TheNewAndy »

StillBored wrote: post #110

I think the author is seriously confused over the value of some crap his startup created in a couple man years vs actual products with market share, long term maintenance and thousands+ of man years of engineering/testing/documentation time. He even admits that they were rewriting large parts of it on a regular basis. That by itself indicates much of the code actually had little value, if the engineers themselves wer…

Which doesn't really explain why when most of the source code to Windows XP leaked, it barely moved the needle on anything.
Post reply on HN