Live data from Hacker News

Peter Naur's view of programming

hiringengineersbook.com

121–130 of 198 posts

Re: Peter Naur's view of programming

#121

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…

Large companies also do occasional complete re-writes of legacy products. It's not as common (because of course the larger the project, the more expensive it is), but it still happens.

I would also argue that rewriting your code somewhat frequently is part of good engineering. As you discover more of the problem, old code needs to be discarded. Usually what happens is that you start solving problem A, then realize a new need to solve problem B. But really it would've been much better to solve a combination of the two, problem C, which requires an entirely different approach than dumping new code for B onto the old codebase for A.

It's actually part of why I wrote the article, because I do honestly believe it is a common misconception that rewrites are more expensive than modifications (although I'm sure that's true in some cases).

Also, I gotta say, while I appreciate that you took time to comment and chime in with the discussion, the way you worded it was quite rude and a bit hurtful.

Re: Peter Naur's view of programming

#122

"Worthless" is an exaggeration: any significant body of code running a critical business process would be missed---and expensive to recreate---if it were lost. But I think the article does make a good point about the value to others. Unless you have a dev team whose head is in that code, and a business team built around that software workflow, just having the code won't be of much value to you. The value of software…

A better description would be "a liability". Every extra line of code is a line that has to be maintained in perpetuity. Each new engineer has to learn it all again.

The saleable product has value. A library you use for multiple products has some value. Everything else is cost.

Re: Peter Naur's view of programming

#123
post #98

This fits nicely with some ideas I've been working on about "Tribal Knowledge". It's going to take some thought to integrate fully. I am primarily looking at the work of Ong on orality and the distinctions he draws between oral and literal cultures. It's not uncommon to hear the phrase used as a pejorative, with the implicit assumption that oral culture is inferior to literate culture and that tribalism == primitivis…

Thank you for your comment and input from this direction, super interesting!

Reminded me a bit of Jon Blow's excellent talk here: https://www.youtube.com/watch?v=pW-SOdj4Kkk

Do you have any resources you can recommend on this topic?

Re: Peter Naur's view of programming

#124

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

Re: Peter Naur's view of programming

#125
> Retaining talent is even more important than you might think. It’s crazy that in an industry where the main value is tied up so much to individual contributors, people change jobs every two years

For most companies I'm familiar with, switching jobs (usually to a different company) is the most effective (and often the only) path to achieving a significant raise or promotion without moving into management.

Re: Peter Naur's view of programming

#126
post #56

I have lost count of the number of startup founders I come across who have an unsuccessful product and are looking for an exit and go "we have all this amazing code. It has to be worth at least $X". No, all of your code is worth exactly $0 to any company looking to acquire you. They either want your product (read: users) as a whole or just the talent behind it. In 99% of such acquisitions your entire codebase will be…

I was at a startup that ran for two years and wrote a lot of code.

At the liquidation, the entire body of code from the two years was auctioned for $1372 to one of the founders. Chances are, if he had not bid, it would have been abandoned entirely. I doubt he looked at it, after.

Re: Peter Naur's view of programming

#127
post #71

That's an egregiously baity title. That's not cool here: https://news.ycombinator.com/newsguidelines.html Edit: The submitted title was "Your source code is worthless". I've changed it now.

My apologies, dang. I thought it was borderline, but it captured the essence of what I was trying to say. Sadly it kind of derailed the discussion a bit, so I guess you're right.

Thanks for changing it instead of deleting it. How do you feel about "On the Value of Source Code"?

Re: Peter Naur's view of programming

#128

> Retaining talent is even more important than you might think. It’s crazy that in an industry where the main value is tied up so much to individual contributors, people change jobs every two years For most companies I'm familiar with, switching jobs (usually to a different company) is the most effective (and often the only) path to achieving a significant raise or promotion without moving into management.

Where does everyone get the impression that you can just move into management? It's certainly not the case in circles I move in. In 15 years I've not seen a single promotion into management. That's in London.

Re: Peter Naur's view of programming

#129

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

I dunno, “it doesn't have to be that way” is very contextual. I think the peak group coherence and idea integration available in physical proximity is probably considerably above the peak available with current-day telecommunications (and current-day social/psychological technologies/practices surrounding it). But of course most groups won't be able to reach either peak, and the peaks for particular individuals or groups may be reversed from that, or there may be other factors that reverse them. (For instance, being able to more legibly put effort into communication practices with the excuse of “we need to relearn to work together because remote”, even if doing the same thing while in proximity would have had even better effects—and not necessarily because of external pressure, since the same emotive mechanic can operate within the group.)

Re: Peter Naur's view of programming

#130

> Retaining talent is even more important than you might think. It’s crazy that in an industry where the main value is tied up so much to individual contributors, people change jobs every two years For most companies I'm familiar with, switching jobs (usually to a different company) is the most effective (and often the only) path to achieving a significant raise or promotion without moving into management.

Where does everyone get the impression that you can just move into management? It's certainly not the case in circles I move in. In 15 years I've not seen a single promotion into management. That's in London.

I think London England has a class structure that discourages this. In North America the push to team leader happens quite often and middle management common. The glass ceiling is usually cto/ceo/coo.
Post reply on HN