Live data from Hacker News

Peter Naur's view of programming

hiringengineersbook.com

31–40 of 198 posts

Re: Peter Naur's view of programming

#31

    This is because there are intangible aspects of the model/theory in the programmer’s heads, which can’t be expressed in code and documentation
But it can be expressed in commit messages and "why" comments! This is very important a lot of developers don't understand and want to just "get on with their life" after writing the commit message "fix".

If used properly, version control can be the repository for all ideas stored historically and can be replayed. With well-written commit messages and well-formatted commits, whole ideas can be followed and mistakes can be recognized years after the code has been written. I have seen multiple times when we recognized "oh, they wanted to do this or that, but they forgot to change this", so we could fix it, because we understood the original idea someone had 10 years ago!

I believe, THE PRODUCT of Software Engineers work is not source code, but COMMIT MESSAGES!

Re: Peter Naur's view of programming

#32
"When we hired a new COO, who had mainly worked at bigger companies before, he was shocked to hear that all our code, communication infrastructure and internal systems were living in the cloud. He argued that we should move to on-premise solutions as soon as possible, partially out of fear of intellectual property theft, partially to appease investors with similar fears."

[shudder]

Re: Peter Naur's view of programming

#33

This is because there are intangible aspects of the model/theory in the programmer’s heads, which can’t be expressed in code and documentation But it can be expressed in commit messages and "why" comments! This is very important a lot of developers don't understand and want to just "get on with their life" after writing the commit message "fix". If used properly, version control can be the repository for all ideas st…

This works to some extent, however it's pretty rare that engineers go more than 1 commit deep into the git blame.

Re: Peter Naur's view of programming

#34

This is because there are intangible aspects of the model/theory in the programmer’s heads, which can’t be expressed in code and documentation But it can be expressed in commit messages and "why" comments! This is very important a lot of developers don't understand and want to just "get on with their life" after writing the commit message "fix". If used properly, version control can be the repository for all ideas st…

While I agree that good commit messages help, I think a lot of this info can't be reasonably conveyed through them.

While the analogy might not be perfect, it's kind of like trying to teach someone how to play the piano by asking them to read a book.

Re: Peter Naur's view of programming

#35
I appreciate a good catchy headline as much as the next person, but it's a ridiculous claim that "source code is worthless". On some level maybe it's not worth as much as some might make it out to be, but it's not worthless. There's a ton of strategic insight to be derived from the source code, not to mention just a basic time-value of money level of value.

Re: Peter Naur's view of programming

#36
post #33

This is because there are intangible aspects of the model/theory in the programmer’s heads, which can’t be expressed in code and documentation But it can be expressed in commit messages and "why" comments! This is very important a lot of developers don't understand and want to just "get on with their life" after writing the commit message "fix". If used properly, version control can be the repository for all ideas st…

This works to some extent, however it's pretty rare that engineers go more than 1 commit deep into the git blame.

No it's not at all. I do it daily. You have to learn the tools you use every day!

Re: Peter Naur's view of programming

#37
If you accept the idea that programming is theory building, it's not that difficult to see when source code isn't worthless - when it's not the slow slog of building a theory entirely of well known facts, but when it contains leaps of insight.

There is also value in knowing which particular theories you're fleshing out vs. ignoring.

Re: Peter Naur's view of programming

#38

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.

Even if the project is 'dead' it still runs, particularly on Windows. I'm running the final release of Winamp as I type this. I organize my hard disk with the 1.0 of Spacemonger, which was free before it went paid. I edit audio files with Sound Forge 11 (up to 14 or so now) and before that I had a pirated copy of 6.0 that worked pretty well. I have a 'programs' folder full of stuff that runs without installation, som…

> Code is eternal.

Especially win32 apps, thanks both to windows and wine

> Even if the project is 'dead' it still runs, particularly on Windows.

For software I want to run long term, I always get the win32 version.

Re: Peter Naur's view of programming

#39
tldr: Code needs constant updating, and a coder who hadn't originally wrote the code will almost certainly make distasteful and often incorrect modifications. Ergo, code is worthless.

editorial: Most devs with >5 years experience know this. The digitization of content made movies, music, books, and software all but financially worthless. Split-second, error-free replication has rendered the IP of so-called "knowledge workers" far less valuable (movie studios, recording labels, newspapers, programmers).

Re: Peter Naur's view of programming

#40

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…

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.
Post reply on HN