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

131–140 of 198 posts

Re: Peter Naur's view of programming

#131

Post by Ericson2314 »

paxys wrote: post #84
Ericson2314 wrote: post #77

"source code being worthless" is actually a huge red flag that something is deeply wrong with the way our industry works. There is too much in-house knowledge that isn't being codified. Software production shouldn't be like e.g. Jet engine production, where it's all nontransferable lore. I posit if everyone was automatically build able and deployable (say with Nix) across the board. Source code would have more value.…

You could do all that and the code would still not have any intrinsic worth, because if a company gets their hands on it they don't automatically get a team of developers with domain expertise to maintain it going forward. That's where the real value is. Knowledge and experience can never be codified.

I usually read "domain expertise" as "communications failure"

The purpose of the code is as much to communicate with other humans as it is to communicate with computers.

Re: Peter Naur's view of programming

#132

Post by dgb23 »

cloogshicer wrote: post #121
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…

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…

> the way you worded it was quite rude and a bit hurtful

You probably just hit some nerve of the person you responded to. Granted, your article was exaggerating about the worthlessness of source code, you made a very good and interesting point grounded in real experience.

On top of that you did something that I think is very important, commendable and interesting: Looking at the history of software engineering and programming. There is a wealth of knowledge and insights at our fingertips and as a culture we're not paying enough attention to history.

And the message is very sound if not taken to the extreme. Source code quality matters and is worth investing in, but people ultimately matter more. It's an important message that needs to be heard again and again.

Re: Peter Naur's view of programming

#133

Post by toss1 »

vannevar wrote: post #17

"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…

You are certainly correct about the costs of losing access to the source code, e.g., if it were destroyed.

However, it seems the author was discussing a different meaning of "lost", as in loss of control of the source and having it revealed to the outside world. He made the best arguments I've seen that the bulk of it is worthless to anyone else, who would be better off rolling their own from scratch, and provided a good example.

Indeed, if I were working a problem and somehow ethically came into possession of a competitor's code or product (e.g., via a buyout), the only use I'd put it to would be to try to see if they had any unique insights that we could adapt, and maybe some stand-alone chunks to use. And, indeed, that was the fate of a codebase of which I was quite proud when a company I co-founded got bought.

Re: Peter Naur's view of programming

#134

Post by wnoise »

dang wrote: post #95
wnoise wrote: post #92

Earlier quoted context omitted.

And yet the current title ("Peter Naur's view of programming") now contains even less information about the content of the article. It may be less "clickbaity" -- I certainly am less inclined to click on it, but it's also less useful.

I would say it contains much more information, in addition to being accurate. If anyone can suggest a better (i.e. more accurate and neutral) title, we can change it again.

I'm not sure what you mean by neutrality here; I want the title of a piece to accurately reflect the thesis of the piece, whether or not the piece itself is biased.

But the current HN title is not a thesis at all. At best it's a characterization of the thesis of the piece. It's not a wrong characterization, but I don't see how it's useful. Certainly, he is indeed illustrating and referring back to Peter Naur's description of programming as theory-building, but this title doesn't tell me (a) what Peter Naur's view is, nor (b) why I should care, nor (c) whether this piece even agrees or disagrees with it.

The first subheading of "Your source code is worthless" is a running theme that connects everything. Yes, later on he calls to Naur's "Programming as Theory Building" article as an explanation for this observation, but the belief is more central than the explanation. It starts before the explanation and continues past the engagement with Naur.

I don't see how weakening this strong thesis by hiding it helps make things either more accurate or more neutral. Is it that it seems like an insult? Leave out "your", or change to "most" or "in general".

(In contrast, the article's title of "How to hire senior developers: Give them more autonomy" would be bad one. It is barely touched on, just thrown in at the end, as a conclusion on top of the meat of the piece.)

If I had to suggest something that covered what I consider the main points, and had more than the central theme: 'Source code alone is worthless as "Programming as Theory Building" suggests', but that's starting to attribute a stronger point of view to Naur than may be reasonable.

But the originally submitted title was perfectly okay.

Re: Peter Naur's view of programming

#135

Post by jagged-chisel »

plutonorm wrote: post #128
musicale wrote: post #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.

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.

In the States, it’s not “just move into management,” but an expectation from management that their positions are “above” those who aren’t management, and once an employee maxes out salary at their skill (because we certainly won’t pay the peons more than management...) they only promotion is management. So go take some classes and work your way up that corporate ladder...

Re: Peter Naur's view of programming

#136

Post by [deleted] »

wnoise wrote: post #134
dang wrote: post #95

Earlier quoted context omitted.

I would say it contains much more information, in addition to being accurate. If anyone can suggest a better (i.e. more accurate and neutral) title, we can change it again.

I'm not sure what you mean by neutrality here; I want the title of a piece to accurately reflect the thesis of the piece, whether or not the piece itself is biased. But the current HN title is not a thesis at all. At best it's a characterization of the thesis of the piece. It's not a wrong characterization, but I don't see how it's useful. Certainly, he is indeed illustrating and referring back to Peter Naur's descri…

[deleted]

Re: Peter Naur's view of programming

#137

Post by username90 »

jjeaff wrote: post #22
mynegation wrote: post #14

“One of the fears from management was that a big company like Google could take our code and build a competing service.” Google, or any other respectable company, would not touch source code without a permissive license with a ten foot pole, least of all if it was retrieved as a result of improper access.

What determines if a company is respected or not? Is Uber a respected company?

You can ask engineers that worked there about their processes. Google have extensive processes both for using external code and for engineers accessing user data. I worked for a while on a system that had some user data, and every single access was logged and reviewed to ensure that each data access was in response to a user filing an issue and only accessed the data needed to fix the users issue. That is a standard process implemented in all of Google.

Companies who doesn't have engineers talking about processes are therefore not trustworthy. Doesn't matter if it is due to them being too small to not have ex engineers, or them threatening their engineers into silence, or their engineers simply not caring about processes and therefore not talking. Never trust companies where only upper management makes statements about their processes.

Re: Peter Naur's view of programming

#138

Post by username90 »

> Your source code is worthless

This disregards the effect of having users. Once you have built something and lots of people start using it then the code for the library becomes the main source of truth for what that library should do, since any changes to its behaviour is likely to break someone's workflow.

This is why making "clean rewrites" is so hard, since reimplementing all the peculiar behaviour of the previous implementation is much much harder than implementing new peculiar behaviour for a new library with less well defined requirements.

Source code isn't particularly useful for competitors, no, but it is extremely valuable for your company.

Re: Peter Naur's view of programming

#139

Post by gmfawcett »

daotoad wrote: 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…

I don't know Ong's work at all. But I wonder where "lector" culture fits? If someone is reading or reciting to you, is that oral culture? or is dialogue a necessary component?

Really I'm wondering where the divide is between, "you need to talk with me to learn this", and, "you can subscribe to my channel to learn this."

Re: Peter Naur's view of programming

#140

Post by username90 »

ncmncm wrote: post #122
vannevar wrote: post #17

"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.

Engineers are a liabity. You need them to write and fix code that runs your product, but other than that every extra engineer just demands salary and increases your costs.

Therefore I conclude that engineers have no value for a company, since when ignoring all the value they provide they just cost money.

Post reply on HN