14 ms·

Peter Naur's view of programming

292 points by cloogshicer 6y ago

cloogshicer 6y ago
The referenced article by Peter Naur (Turing Award winner, invented Backus-Naur-Form) is well worth a read.
- ivan_ah 6y ago
  Here is a link to a PDF version of this paper: [Programming as Theory Building -- Naur 1985] https://demo.cygale.net/naur1985programming.pdf https://demo.cygale.net/naur1985programming.pdf
  - p4bl0 6y ago
    Haha I wonder how did you came across this link? This demo website might disappear or at least the pdf might be removed from it. The stable version of this PDF is on my web page here: https://pablo.rauzy.name/dev/naur1985programming.pdf https://pablo.rauzy.name/dev/naur1985programming.pdf EDIT: to the mods: maybe the link in the parent comment could be updated and my comment deleted? (I am the maintainer of cygale.net — the demo website can be edited by virtually anyone… my personal webpage is much more trustable).
    - ivan_ah 6y ago
      I found the link via Google Scholar search = https://scholar.google.com/scholar?q=Programming+as+Theory+Building https://scholar.google.com/scholar?q=Programming+as+Theory+B... I was looking for a version of the paper with machine-selectable text (because the PDF linked in the OP is a scan with no OCR).
      - p4bl0 6y ago
        Okay thanks. I will put a permanent redirect to inform GScholar's index of the actual stable URL of the document. Text selection and accessibility is indeed why I took the time to build this proper PDF as I explained here before seeing your comment: https://news.ycombinator.com/item?id=26035175 https://news.ycombinator.com/item?id=26035175
hallarempt 6y ago
_My_ source code is invaluable. It's open, public, free to reuse under the GPL. It's a complete implementation of a painting application used by millions of people. It's a huge amount of knowledge readily accessible. You won't be able to buy something like this for any sum of money, so it's free.
- cloogshicer 6y ago
  Is it really the source code that has value, or your continued expansion and development of said code? Genuine question. The reason I'm asking, while I was writing the article, I was considering including the youtube-dl fiasco (when the RIAA took it down from GitHub) as an example. People were concerned not because the code was gone (lots of mirrors popped up quickly), but because they were worried that the contributors would stop further development. I think that's another indicator that the code itself carries little value. However, the problem space you've loaded and mapped to code in your own head, does have lots of value. Of course the fact that you're sharing it with the world in the best format we know so far (code) for free is much appreciated :)
  - ghaff 6y ago
    I think both can be true. A snapshot of source code can be useful as a basis for some other project. However, you're also correct that, if the source code is abandonware and you/others have no interest in maintaining it, it almost certainly becomes less useful over time and at some point just breaks.
  - gpm 6y ago
    Youtube-dl is an app chasing a moving operating of trying to interact with other sites APIs... many of which don't really even want to let youtube-dl do that. Most apps aren't in such a difficult space and keep working basically forever.
    - cloogshicer 6y ago
      > 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.
Pete-Codes 6y ago
Re your newsletter form, I'd take out the first name requirement.
- cloogshicer 6y ago
  Thanks for your suggestion! It's actually optional. I had a problem with spam signups and thought it might help a bit.
asiachick 6y ago
I agreed with a lot of the points and that often source code might not be valuable but.... Much of it sounded like only thinking of a small team doing something no one else care about. Conversely we have github and the millions of libraries it hosts in the form of source code. We also have examples of WebKit based on KHTML, Blink based on that. Electron/Edge/Brave/Vivaldi based on Chromium. There is no one programmer who has the entirety of Chromium in their head and I'm pretty confident most teams would not find it easier to write their own browser from scratch. Chromium or WebKit are embedded in many places. PS5 and Oculus Quest are two off the top of my head.
- cloogshicer 6y ago
  I don't think that Naur was arguing that it has to be a single developer who knows everything. It could also be multiple developers, where each one of them has loaded a sub-problem of a bigger problem into their head. Usually in OSS projects you have a handful or so of contributors doing the bulk of the work, right? Imagine them all going away at once for one of those projects you mentioned. I feel the project would be in pretty bad shape.
dehrmann 6y ago
> But even Panic says in their blog post that they were not too concerned with competitors using their code either, mainly because it would quickly become outdated And the legality bit? Big companies who aren't Uber know this isn't worth it, but even with smaller companies, if someone internally notices, the company could be in a lot of legal trouble. I haven't worked anywhere that would even consider using a competitor's code.
mynegation 6y ago
“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.
- cloogshicer 6y ago
  Agreed, I think that argument back then was just bad.
- jjeaff 6y ago
  What determines if a company is respected or not? Is Uber a respected company?
  - username90 6y ago
    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.
- deepsun 6y ago
  Two more reasons Google doesn't touch others code: 1. They have monorepo with custom build infra, which makes integrating any third_party code pretty hard. 2. In google career culture, one gets promoted for development of something new, not integrating existing proved solutions.
  - 6y ago
vannevar 6y ago
"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 is inextricably linked to the team that has shaped it. So while it isn't worthless, it is certainly of much lower value without that team.
- cloogshicer 6y ago
  Agreed, worthless might have been a bit exaggerated.
  - gabereiser 6y ago
    worthless-to-outsiders is more concise to me that conveys what the author was intending.
- ncmncm 6y ago
  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.
  - username90 6y ago
    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.
    - atomicson 6y ago
      It depends on size of the company. Cost is a relative instrument. Develop a big market product, highly demanding, or for a critical mission application is another story for "cost".
gfody 6y ago
source code is excrement. an unfortunate side effect necessitated by the immaturity of our tools. someday we'll make software without it and life will be much better for the poo tenders.
- IggleSniggle 6y ago
  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 or a set of assumptions (with their corresponding citations) in a scientific journal, the decision tree (inclusive of dependency graph) will always be essential.
  - gfody 6y ago
    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.
    - IggleSniggle 6y ago
      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.
oaiey 6y ago
It is very often a developer perspective that the source code and the software product is the core delivery. Interestingly that is often not true. Customer care, project management, sales, marketing and so many roles contribute so much more to the value creation than often visible to a developer.
- cloogshicer 6y ago
  I completely agree, that's why I wrote in a footnote: > However, I believe this statement is only true for software companies where the core technology is the main asset. For many software companies, the main value might not lie in their technology, but in other things, such as the network effects, relationships to customers, etc.
Quarrelsome 6y ago
When I used to contract I used to work for a firm that would waste their time panicking about this but the reality was that their code was so bad that if it was released and their competitors could read it then that would probably help us because they'd be wasting their time. Much of it was _very_ hard to read, work with and needed serious improvements. We don't sell the source code, we sell the ability to update, maintain, test and build that code and that's institutional and staff knowledge.
FrozenVoid 6y ago
Source code of a large monolithic projects(Products) lacks value due not being adaptable or modular, but it has worth that can be decomposed and refactored into other software(libraries/packages/headers/functions).
- jimmyvalmer 6y ago
  I'll speak for all the ten-year vets who know stripping a monolith for parts is often as time-consuming as writing from scratch, and always uglier. Software is not a car.
seanmcdirmid 6y ago
You just need great archeologists to dig some worth out of source code whose authors have long past. At least, that's the premise behind Vernor Vinge's programmer archaeologists as portrayed in the fiction A Deepness in the Sky. Dystopian views of how code will evolve in the future are useful to informing on these kinds of things.
QuercusMax 6y ago
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 are working on applications which have 2-4 years of catching up to reach the same level of maturity as my existing work. It's taken me the better part of a year to communicate the whys, whats, and hows of the systems we've built. I've given multiple talks, explained in 1:1s, written docs, and it's just taken a really long time to get across these ideas. All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated.
- inadequatespace 6y ago
  > All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated. This, along with the fact that employment half-life is long relatively to COVID (2 years average tenure), convinces me that this "remote permanent" hype is going to grind to a screeching halt in another year or so. Yes, I'm putting my money where my mouth is (in SF Bay real estate, in this case).
- rorykoehler 6y ago
  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.
  - cloogshicer 6y ago
    I think the point that Naur was trying to make is exactly that this process (unfortunately) doesn't scale. That is my experience at least (even in very well documented projects).
  - chubot 6y ago
    It depends on the situation. Documentation and in-person meetings aren't mutually exclusive. A meeting to go through the docs and update them is often very useful. Not everything has to be "scalable". There are many parts of the code that only 1 or 3 people will ever work on. In fact in most places I'd say that's most of the code.
jariel 6y ago
Working code (beyond super basic CRUD) that maintains a companies revenues is 'priceless' not 'worthless'. It's 'worthless' to outside parties, but that's completely besides the point. I worked at a Networking startup that made it's own ASICs and was sold for billions on the legit premise of 'working silicon'. The plans were actually stolen by a contractor who walked out, and while bad, were a little besides the point because they can't reasonably be used by others. It's like saying 'GM's factory is worthless'. Well maybe on the free market, but as an operating entity it's worth a lot. And yes, 'autonomy' is a nice thing for senior devs, but it's also hard to do in practice.
kissgyorgy 6y ago
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!
- lumost 6y ago
  This works to some extent, however it's pretty rare that engineers go more than 1 commit deep into the git blame.
  - kissgyorgy 6y ago
    No it's not at all. I do it daily. You have to learn the tools you use every day!
- cloogshicer 6y ago
  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.
ajsharp 6y ago
"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]
- DavidAdams 6y ago
  Yeah, my first thought after reading that anecdote was that the new COO should have been fired.
  - gamacodre 6y ago
    And the CTO too, for caving to that argument.
    - quelsolaar 6y ago
      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.
ajsharp 6y ago
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.
groby_b 6y ago
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.
jimmyvalmer 6y ago
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).
npsimons 6y ago
That's not the post's headline; why did someone cherry pick this subheading? Is this simple clickbaiting?
- cloogshicer 6y ago
  I think the title was changed by a moderator, but it's actually quite accurate now.
zwieback 6y ago
Provocative, exaggerated title but a great article. I would argue that many bodies of source code are worth something even if they were handed to me without any additional info. Let's say I'm working with a new microcontroller and someone gives me the source to a TCP/IP stack for that new micro. From the data sheet of the micro I could make sense of the lower levels of the stack and TCP/IP is so well defined that just the value of someone making it work on the particular hardware, which is mostly busywork, has huge value.
bjornsing 6y ago
I agree with the conclusions, but the premise that “source code is worthless” is click-baity and misleading. After having gone through a few M&A discussions with a high-tech software startup this is how I think about it: Nobody wants to buy just the source code. Talent / team that is used to work together and has proven itself has some value (i.e. “talent acquisition”), but valuation won’t be very high. What’s really valuable is talent and code (with IPR rights) combined. But don’t think you can put the source code on GitHub under an MIT license and it won’t affect your M&A discussion... ;)
shahrk 6y ago
Unless you are Waymo and the theft is by one of your employees.
cccc4all 6y ago
Source code is worthless AFTER it's written. It still has to be written first.
dwohnitmok 6y ago
This is startup-centric and depends heavily on the velocity of your project. For intrinsically difficult problems that evolve slowly or not at all (the most extreme example of this would be e.g. unsolved CS problems), source code is gold and its theft represents a huge blow to any competitive advantage a product might have had. Note that this is different from saying the source code itself doesn't evolve. For problems whose difficulty relies rather on business concerns and which evolve rapidly then (the theft of) source code is nearly worthless.
castwide 6y ago
The article makes a lot of good points, but I disagree with the notion that source code is worthless. The true test of the source's value isn't what would happen if it got stolen. It's what would happen if it disappeared altogether.
IggleSniggle 6y ago
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.
- CryptoGhost 6y ago
  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 firms don't have to roll their own but thats not a hard and fast phenomenon.
  - IggleSniggle 6y ago
    I agree, but at least for me, this did not diminish the value of the article.
  - mjburgess 6y ago
    I think "software company" can probably hold the weight of the argument, if defined well. ie., a Bank maybe finds most of its value in that its code runs, etc. A software company, perhaps, we could define (1) simply as any company where this is true; or if that's cheating, (2) any company where its competitive advantage derives from its software developing over time. I think the claim of this article is that (1) and (2) refer, aproximately, to the same companies: ie., that software which is changed to adapt to ever changing needs derives that capacity from the "theory of the programmers" and not the code.
paxys 6y ago
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 thrown out.
- ncmncm 6y ago
  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.
jayd16 6y ago
"Kill your darlings" is probably a better aphorism. Obviously source code is useful on its face, and its also the truest documentation of current requirements. Worthless is an overstatement.
deleted 6y ago
[deleted]
aeldidi 6y ago
Rather than "Source Code is Worthless", I find it makes more sense to think of the lesson learned here as "Source Code is Only Worth Something to the Public if it's Well Documented and Stable", which happens to be true more often in practice. For example, someone I used to know would always say that while the Linux kernel as a product (a free and open source operating system) is priceless, the source itself is worthless unless you have an understanding of its internals, and I think that this is generally true for codebases of similar size and complexity, although I'd argue Linux specifically doesn't fall into this area only because of the fact that drivers make up most of the code in it. Stability is especially important when considering long term worth of code. When youtube-dl was removed from GitHub not too long ago, people were worried that the project would stop being updated and maintained, despite the fact that mirrors of the source code were everywhere. In that case, because the project needs constant updating and maintaining to keep up with websites like YouTube who have no incentive to continue to keep a stable API for downloading videos.
superjan 6y ago
This is easier to reason about if it’s not about your own code. Consider this: would you swap your own codebase for your competitor’s if you had the chance? For me, it’s a resounding no. I bet it’s the same from their perspective.
jhallenworld 6y ago
Source code is most valuable to the person who wrote it / knows it intimately. If I can use my code on different jobs it will definitely save me time. For this reason I try to make any library code MIT licensed. This allows me to use it for different clients without them complaining. Our contracts are set up to allow this. Often the customer's proprietary code is a small fraction of all the code.
blindm 6y ago
> Communicating the mapping of the code and the real world, as Naur describes, would have required us to document all these processes in meticulous detail. If we had tried to, I believe the result would’ve been multiple hundred pages describing the business processes Or in other words: building in business logic is paramount and the only thing you should be doing if running a startup, otherwise these engineers are just dossing around with code that doesn't yield a profit.
dbrueck 6y ago
The article is great, though a more accurate (but admittedly less thrilling) title would have been "Poorly Documented Source Code Is Virtually Worthless". Good source code includes level of intent comments, it explains the reasoning behind decisions (especially the tradeoffs that were made) and warns future readers of potential pitfalls. In both a professional setting as well as when wanting to contribute to a favorite OSS project, few things are more frustrating than jumping into the code only to realize it's missing this type of info.
- jimmyvalmer 6y ago
  > "Poorly Documented Source Code Is Virtually Worthless". And richly documented code is non-virtually worthless. If you don't believe me, try parsing one of these so-called "literate programs." Any 10-year vet will far more quickly grok a piece of code when its textual flow isn't disrupted by verbiage that only makes sense to its author.
dang 6y ago
That's an egregiously baity title. That's not cool here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Edit: The submitted title was "Your source code is worthless". I've changed it now.
- jimmyvalmer 6y ago
  It's baity because it's true.
  - dang 6y ago
    That is not an adequate theory of baitiness.
- wnoise 6y ago
  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.
  - dang 6y ago
    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.
    - wnoise 6y ago
      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.
nitwit005 6y ago
The problem with saying it's about developers building up theory is that we all tend to forget quite a bit. Code tends to contain a ton of fixes, versioning details, or algorithmic tricks no one remembers. I've certainly rebuilt something from scratch only to immediately stub my toe.
Ericson2314 6y ago
"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. Now, it still would be true that less source code is better than more source code, so line by line / marginally source code is a liability. But reproducible functionality would be valuable. The remaining worthless might have to do with much especially b2b proprietary software being utter crap, and all the value being in the sales relationship and none in product/service being traded.
- ErikAugust 6y ago
  I think it’s incentives, partially. Programmers say their job is to put themselves out of their jobs. People don’t want to be out of their jobs, really. And we know that doesn’t happen. If anything, it locks them into their job, as “subject matter experts”. Also, most applications are built on a million layers of reusable abstractions. Even in the highest level of the code people are using frameworks and other libraries. A lot of source code is just business logic and glue code when you remove the stuff it is built upon, which tends to be much better (and many times, open and free).
  - Ericson2314 6y ago
    > Programmers say their job is to put themselves out of their jobs. People don’t want to be out of their jobs, really. And we know that doesn’t happen. If anything, it locks them into their job, as “subject matter experts”. I agree it is a fools errand to ask people to work against their incentives, but by https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox I don't think there is actually disincentive given enough risk tolerance to let the new equilibrium emerge. Write better programs, and increasing the demand for programming. I think the bigger problems is most programs are bad and alienated. Programming with everything nicely packaged and ready to be modified is like working with a clean workbench / shop. If you've never been in a clean one, cleaning seems like a chore, but if you have, working in a dirty one seems not only inefficient, but gross and undignified. It's "take care of your tools, and your tools take care of you" vs being "lord of my garbage heap of tech debt". Any self-respecting craftsperson should choose the former.
iamwil 6y ago
Anyone read the post author's book, Hiring Engineers? Is it any good and worth the $75?
- cloogshicer 6y ago
  Hey, author here. What's the situation that you're in? You (or anyone else reading this) can ping me at alexander [at] hiringengineersbook [dot] com, maybe I can help you figure out if the book is good for your situation or give some advice on the spot. No worries, not trying to sell anything (other than the book), just always curious what challenges people are facing when hiring.
TheJoYo 6y ago
I'm missing where autonomy comes into this.
pan69 6y ago
Source code isn't worthless, it's just not as important as the developers who wrote it because those developers can write a next, much better version, of the same software with the domain knowledge they have acquired writing the previous version(s). In practice this means that source code is disposable.
dbsmith83 6y ago
I agree with the conclusions drawn in the article, but not the premise. Source code is definitely not worthless. Two examples: 1) using source code to find security exploits 2) competitive machine learning algorithms In the second case, imagine if a competitor had access to algorithms used in marketing for bidding on ads. You know what features it uses, what default values it uses, how it works, etc. You could do some damage with that knowledge
- enobrev 6y ago
  It seems that you not only agree, but argue further that source code is a liability.
  - dbsmith83 6y ago
    Hah, nice try, but no. Arguing that something is a liability if it fell into the wrong hands does not mean it is worthless or worth less than zero. It simply means it is worth protecting.
TheJoYo 6y ago
> They would be much faster just building it themselves from scratch, than trying to understand the crummy code we had hacked together. They might use your code as a reference, especially from any research components of the project. You'd be surprised what automated analysis of gitlab repos bring to light.
mywittyname 6y ago
I feel like the Unix philosophy of very small programs that do one thing, and do it well, is an application of the concepts in this article. > One of Naur’s main conclusions is that making changes to an existing program (to accommodate changing requirements) is often more costly than writing new code from scratch, at least if done by people from a different team. 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: Small, single purpose applications require less maintenance (which is expensive), but proper design allows them to be combined to create more complicated programs.
- daotoad 6y ago
  But to compose something large you begin to need hundreds of these small tools interacting. Do you build slightly larger tools that integrate the small tools? Even these larger tools my need to be composed into another level of abstraction to build the final system. This is essentially the same architecture that you would build with a layered set of abstractions and interfaces. It's really just a matter of how the different bits communicate that is different.
yudlejoza 6y ago
- There's no such thing as programming - There's only research programming
daotoad 6y ago
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 == primitivism == bad and undesirable. But I've come to believe that there are always going to be things that cannot or should not be represented in written documentation. Documentation is an artifact that must be maintained. Individual professionals and organizations spend a huge amount of energy producing, managing, and maintaining written documentation. But how much time have we spent on oral transmission of ideas? Almost none. And that's because we dismiss it as an approach. It's seen as less than or primitive, or at best something to discourage. But if you accept that there must always be some oral information, then ignoring the issues of how we communicate, update, and persist that orally transmitted information seems foolish. There are cultures that have more recently made the the transition from being primarily oral to literal that have not forgotten the skills needed to manage this class of knowledge. I wonder what practices we can learn from them that we can use to improve our ability to share and communicate more effectively.
- pasquinelli 6y ago
  would the oral transmission of information be what's called in other industries training?
- cloogshicer 6y ago
  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 https://www.youtube.com/watch?v=pW-SOdj4Kkk Do you have any resources you can recommend on this topic?
- gmfawcett 6y ago
  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."
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
breck 6y ago
The more you design your program for the current world, the faster it will go out of date. Try to identify what will still be useful in 30 years, and get that part right.
bennysonething 6y ago
This is probably one the most poignant things I've read about programming. I've recently been through a handover, left on my own at at a new job, with a long back log full of fairly useless stories, left to forge relationships with the business. Mostly left depressed and stressed. All the while a manager said "I don't understand why the handover is taking so long, it's all documented". Yeah the documentation didn't really tell me much as I lacked the business context. I'm brand new to this domain too. The article has put into words what I've been feeling for the last year.
StillBored 6y ago
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 were throwing it away. It would be really hard to convince MS/Google/apple/etc that their primary products source code doesn't have any value.
- horsawlarway 6y ago
  I disagree with you... sort of. I think there's some truth that code has value, and there is some risk that making it available can cut into profits (See: Redis, Mongo, etc, changing course after open offerings became available on AWS/Azure/GCP). But I think the much larger truth is that most of the value provided by companies (and most of what they charge for) is not "lines of excellent code" but rather the operating expertise of keeping a complicated system stable and available. For example - All of the companies you listed do have widely available, open source offerings (Android, VS-Code, Mono, Swift, Webkit, etc). The value wasn't in the code, the value was in the ecosystem around it. I think this is true in more cases than folks expect. The Windows source code was leaked, but I don't see any companies scrambling to compete with MS by building on that code. I think even if most of Google's repo was made public - the valuable part was the team that supports the infrastructure behind it, not the lines of code themselves (or at least, they make up a smaller portion of the value)
  - StillBored 6y ago
    Well I don't disagree with that either. Only that I must point out that libre washing a company with an open source product here/there doesn't really count. Sure android is open, but google isn't using it to make money directly, instead it feeds into the closed source ad/marketplace offerings. If they opened that code, or apple opened up the entire iOS stack its quite likely they would have competitors that as you point out lowered the value of their primary offerings. A google with a half dozen competent ad/search companies would look very different than the one that can afford to give away a large part of their product portfolio. So, there is value in operating a "service" buisness, but there is even more value in operating a service business that has high barriers to entry. One way to erect those barriers is with hundreds of millions of dollars in engineering time spent on "source code" be that the code actually doing the searches/etc or the code being used to manage the clusters its running on.
Vinnl 6y ago
The relative worthlessness of source code can easily be seen when the situation is flipped around. When you're told you can look at e.g. a competitor's source code, some open source code somewhere, or a prototype that a colleague already built during a proof-of-concept, that will almost never make you go much faster. Meanwhile, I think organisations underestimate the cost of attempting to keep source code secret. It adds friction to almost every step of the development process, compared to not worrying about whether your build logs or repositories are publicly accessible, even if they're not open source.
StillBored 6y ago
Thinking about this more, I wonder if you can predict whether a software project is "failing" by the amount of code that is getting deleted early on. I've been part of a half dozen or so successful medium->large scale projects, and we never really deleted large parts of the code base. The small teams bootstrapping them had a pretty clear goals of where they were going sufficiently to build a reasonable scafold early on to get somewhat working prototypes. Then as the project took shape things were fleshed or refactored far more than they were thrown away. OTOH, projects i've seen fail frequently had core pieces rewritten on a somewhat regular basis. Which if you think about it in the sense that every time a chunk of code is wholesale replaced, that is X man hours of effort flushed down the toilet. Few startups can afford engineers to be working on things which don't go towards the bottom line. AKA if you have 6 engineers, and on average are replacing 25% of the code base a year, that is the equivalent of just throwing away 25+% of your runway every year. With the team communications overhead/etc I could totally see that it might be possible to never actually make forward progress even though the amount of code being thrown away isn't >50%
- deleted 6y ago
  [deleted]
- fwip 6y ago
  The amount of code written isn't static, and doesn't map neatly to "amount of developer effort." If everything you write has to be "perfect" the first time around, you'll write a fraction as much as if you're willing to build 3 things (either now, or in the future), and take whichever works out the best. It might take more time, or it might take less time.
Simplicitas 6y ago
Hyperboles will always derail any conversation
throwawaygh 6y ago
> Especially for the lower-level components, a good amount of research had been involved. We worked closely with an academic institute that specialized in computer vision. In short, this project wasn’t something that anybody could just easily recreate. So one of the assumptions we had implicitly made was that our source code was one of the company’s major assets. Why not patent?
musicale 6y ago
> 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.
- plutonorm 6y ago
  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.
  - devlopr 6y ago
    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.
  - jagged-chisel 6y ago
    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...
    - plutonorm 6y ago
      This is the opinion of management in England too. Except here there is no way to break into management without going back to school and even then it won't be easy to shake the "developer" image. I'm currently doing a startup, not because I want to do startups, but because I need to get out of development for the sake of my mental health and starting your own company is the only available avenue I have for achieving the transition.
username90 6y ago
> 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.
sriku 6y ago
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).
nojvek 6y ago
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.
mcv 6y ago
I completely agree with this. I never find documentation very useful, and I'm fully aware I've got tons of theory in my head that I couldn't begin to write down. I should try harder because I won't stay on this project forever, and there are enough complex concept involved that aren't immediately obvious. But how do I write that down? And where do I start?
TobySKT 6y ago
Just do audits. There are ISO standards for practically everything and you should run internal audits (and external ones if you can afford it for important stuff)
p4bl0 6y ago
The article from Peter Naur is a must-read. And what it says is absolutely not limited to programming. It is a politically deep and important paper that applies to virtually every human activity that adds value. I recommend reading this paper to all my computer science students. I took the liberty to make a better formatted and easier to read PDF of it a while ago: https://pablo.rauzy.name/dev/naur1985programming.pdf https://pablo.rauzy.name/dev/naur1985programming.pdf
YeGoblynQueenne 6y ago
Could we please change the title back to its original? There is no obvious reason for changing it on the HN post. The title of the article is How to hire senior developers: Give them more autonomy and it's not about Peter Naur's view of programming, it's about the author's view on how to hire senior developers. The article has a few select quotes from Peter Naur's article "Programming as theory building" but the quotes are mainly used to advance the article author's opinions on hiring senior developers, rather than Peter Naur's idea of what programming is. Peter Naur does not seem to be related to this article or its author at all.
notacoward 6y ago
Had a very similar moment at one of the startups I worked for, which also served as my introduction to a new CEO. Shortly after NewCEO was hired, we had an all-hands introduction meeting. "All hands" at this point meant about 50 people, so our largest conference room was packed. I ended up sitting on the floor by the big whiteboard, opposite NewCEO. He started talking about how bigger companies were (he believed) actively trying to reverse-engineer our product. Without exactly meaning to, I said "good luck" loudly enough to get his attention, so he looked at me expectantly. "We're having enough trouble engineering it forwards." A few people laughed. NewCEO kind of glared. I guess I should mention that I was the product architect BTW. We never particularly got along, but he was neither the first nor the last CEO I outlasted during my career so meh. Getting back to the point, maybe a competitor who had access to our code might, with great difficulty, learn something about the problem domain we were exploring (continuous data protection). More likely they would have been misled by all the remnants of wrong turns we'd taken during the exploration process. They'd literally be better off without it. Our entire business was a gamble that we could get to market before bigger competitors woke up to the opportunity and threw more bodies/dollars at it. As it turns out, that's exactly what did happen. We lost the bet. Other people having our code would not have changed that outcome one bit.

292 points by cloogshicer 6y ago

cloogshicer 6y ago

The referenced article by Peter Naur (Turing Award winner, invented Backus-Naur-Form) is well worth a read.

ivan_ah 6y ago
Here is a link to a PDF version of this paper: [Programming as Theory Building -- Naur 1985] https://demo.cygale.net/naur1985programming.pdf https://demo.cygale.net/naur1985programming.pdf
- p4bl0 6y ago
  Haha I wonder how did you came across this link? This demo website might disappear or at least the pdf might be removed from it. The stable version of this PDF is on my web page here: https://pablo.rauzy.name/dev/naur1985programming.pdf https://pablo.rauzy.name/dev/naur1985programming.pdf EDIT: to the mods: maybe the link in the parent comment could be updated and my comment deleted? (I am the maintainer of cygale.net — the demo website can be edited by virtually anyone… my personal webpage is much more trustable).
  - ivan_ah 6y ago
    I found the link via Google Scholar search = https://scholar.google.com/scholar?q=Programming+as+Theory+Building https://scholar.google.com/scholar?q=Programming+as+Theory+B... I was looking for a version of the paper with machine-selectable text (because the PDF linked in the OP is a scan with no OCR).
    - p4bl0 6y ago
      Okay thanks. I will put a permanent redirect to inform GScholar's index of the actual stable URL of the document. Text selection and accessibility is indeed why I took the time to build this proper PDF as I explained here before seeing your comment: https://news.ycombinator.com/item?id=26035175 https://news.ycombinator.com/item?id=26035175

hallarempt 6y ago

_My_ source code is invaluable. It's open, public, free to reuse under the GPL. It's a complete implementation of a painting application used by millions of people. It's a huge amount of knowledge readily accessible. You won't be able to buy something like this for any sum of money, so it's free.

cloogshicer 6y ago
Is it really the source code that has value, or your continued expansion and development of said code? Genuine question. The reason I'm asking, while I was writing the article, I was considering including the youtube-dl fiasco (when the RIAA took it down from GitHub) as an example. People were concerned not because the code was gone (lots of mirrors popped up quickly), but because they were worried that the contributors would stop further development. I think that's another indicator that the code itself carries little value. However, the problem space you've loaded and mapped to code in your own head, does have lots of value. Of course the fact that you're sharing it with the world in the best format we know so far (code) for free is much appreciated :)
- ghaff 6y ago
  I think both can be true. A snapshot of source code can be useful as a basis for some other project. However, you're also correct that, if the source code is abandonware and you/others have no interest in maintaining it, it almost certainly becomes less useful over time and at some point just breaks.
- gpm 6y ago
  Youtube-dl is an app chasing a moving operating of trying to interact with other sites APIs... many of which don't really even want to let youtube-dl do that. Most apps aren't in such a difficult space and keep working basically forever.
  - cloogshicer 6y ago
    > 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.

Pete-Codes 6y ago

Re your newsletter form, I'd take out the first name requirement.

cloogshicer 6y ago
Thanks for your suggestion! It's actually optional. I had a problem with spam signups and thought it might help a bit.

asiachick 6y ago

I agreed with a lot of the points and that often source code might not be valuable but.... Much of it sounded like only thinking of a small team doing something no one else care about. Conversely we have github and the millions of libraries it hosts in the form of source code. We also have examples of WebKit based on KHTML, Blink based on that. Electron/Edge/Brave/Vivaldi based on Chromium. There is no one programmer who has the entirety of Chromium in their head and I'm pretty confident most teams would not find it easier to write their own browser from scratch. Chromium or WebKit are embedded in many places. PS5 and Oculus Quest are two off the top of my head.

cloogshicer 6y ago
I don't think that Naur was arguing that it has to be a single developer who knows everything. It could also be multiple developers, where each one of them has loaded a sub-problem of a bigger problem into their head. Usually in OSS projects you have a handful or so of contributors doing the bulk of the work, right? Imagine them all going away at once for one of those projects you mentioned. I feel the project would be in pretty bad shape.

dehrmann 6y ago

> But even Panic says in their blog post that they were not too concerned with competitors using their code either, mainly because it would quickly become outdated And the legality bit? Big companies who aren't Uber know this isn't worth it, but even with smaller companies, if someone internally notices, the company could be in a lot of legal trouble. I haven't worked anywhere that would even consider using a competitor's code.

mynegation 6y ago

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

cloogshicer 6y ago
Agreed, I think that argument back then was just bad.
jjeaff 6y ago
What determines if a company is respected or not? Is Uber a respected company?
- username90 6y ago
  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.
deepsun 6y ago
Two more reasons Google doesn't touch others code: 1. They have monorepo with custom build infra, which makes integrating any third_party code pretty hard. 2. In google career culture, one gets promoted for development of something new, not integrating existing proved solutions.
- 6y ago

vannevar 6y ago

"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 is inextricably linked to the team that has shaped it. So while it isn't worthless, it is certainly of much lower value without that team.

cloogshicer 6y ago
Agreed, worthless might have been a bit exaggerated.
- gabereiser 6y ago
  worthless-to-outsiders is more concise to me that conveys what the author was intending.
ncmncm 6y ago
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.
- username90 6y ago
  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.
  - atomicson 6y ago
    It depends on size of the company. Cost is a relative instrument. Develop a big market product, highly demanding, or for a critical mission application is another story for "cost".

gfody 6y ago

source code is excrement. an unfortunate side effect necessitated by the immaturity of our tools. someday we'll make software without it and life will be much better for the poo tenders.

IggleSniggle 6y ago
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 or a set of assumptions (with their corresponding citations) in a scientific journal, the decision tree (inclusive of dependency graph) will always be essential.
- gfody 6y ago
  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.
  - IggleSniggle 6y ago
    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.

oaiey 6y ago

It is very often a developer perspective that the source code and the software product is the core delivery. Interestingly that is often not true. Customer care, project management, sales, marketing and so many roles contribute so much more to the value creation than often visible to a developer.

cloogshicer 6y ago
I completely agree, that's why I wrote in a footnote: > However, I believe this statement is only true for software companies where the core technology is the main asset. For many software companies, the main value might not lie in their technology, but in other things, such as the network effects, relationships to customers, etc.

Quarrelsome 6y ago

When I used to contract I used to work for a firm that would waste their time panicking about this but the reality was that their code was so bad that if it was released and their competitors could read it then that would probably help us because they'd be wasting their time. Much of it was _very_ hard to read, work with and needed serious improvements. We don't sell the source code, we sell the ability to update, maintain, test and build that code and that's institutional and staff knowledge.

FrozenVoid 6y ago

Source code of a large monolithic projects(Products) lacks value due not being adaptable or modular, but it has worth that can be decomposed and refactored into other software(libraries/packages/headers/functions).

jimmyvalmer 6y ago
I'll speak for all the ten-year vets who know stripping a monolith for parts is often as time-consuming as writing from scratch, and always uglier. Software is not a car.

seanmcdirmid 6y ago

You just need great archeologists to dig some worth out of source code whose authors have long past. At least, that's the premise behind Vernor Vinge's programmer archaeologists as portrayed in the fiction A Deepness in the Sky. Dystopian views of how code will evolve in the future are useful to informing on these kinds of things.

QuercusMax 6y ago

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 are working on applications which have 2-4 years of catching up to reach the same level of maturity as my existing work. It's taken me the better part of a year to communicate the whys, whats, and hows of the systems we've built. I've given multiple talks, explained in 1:1s, written docs, and it's just taken a really long time to get across these ideas. All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated.

inadequatespace 6y ago
> All-remote work has definitely made a big (negative) impact in the velocity that ideas can be communicated. This, along with the fact that employment half-life is long relatively to COVID (2 years average tenure), convinces me that this "remote permanent" hype is going to grind to a screeching halt in another year or so. Yes, I'm putting my money where my mouth is (in SF Bay real estate, in this case).
rorykoehler 6y ago
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.
- cloogshicer 6y ago
  I think the point that Naur was trying to make is exactly that this process (unfortunately) doesn't scale. That is my experience at least (even in very well documented projects).
- chubot 6y ago
  It depends on the situation. Documentation and in-person meetings aren't mutually exclusive. A meeting to go through the docs and update them is often very useful. Not everything has to be "scalable". There are many parts of the code that only 1 or 3 people will ever work on. In fact in most places I'd say that's most of the code.

jariel 6y ago

Working code (beyond super basic CRUD) that maintains a companies revenues is 'priceless' not 'worthless'. It's 'worthless' to outside parties, but that's completely besides the point. I worked at a Networking startup that made it's own ASICs and was sold for billions on the legit premise of 'working silicon'. The plans were actually stolen by a contractor who walked out, and while bad, were a little besides the point because they can't reasonably be used by others. It's like saying 'GM's factory is worthless'. Well maybe on the free market, but as an operating entity it's worth a lot. And yes, 'autonomy' is a nice thing for senior devs, but it's also hard to do in practice.

kissgyorgy 6y ago

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!

lumost 6y ago
This works to some extent, however it's pretty rare that engineers go more than 1 commit deep into the git blame.
- kissgyorgy 6y ago
  No it's not at all. I do it daily. You have to learn the tools you use every day!
cloogshicer 6y ago
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.

ajsharp 6y ago

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

DavidAdams 6y ago
Yeah, my first thought after reading that anecdote was that the new COO should have been fired.
- gamacodre 6y ago
  And the CTO too, for caving to that argument.
  - quelsolaar 6y ago
    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.

ajsharp 6y ago

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.

groby_b 6y ago

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.

jimmyvalmer 6y ago

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

npsimons 6y ago

That's not the post's headline; why did someone cherry pick this subheading? Is this simple clickbaiting?

cloogshicer 6y ago
I think the title was changed by a moderator, but it's actually quite accurate now.

zwieback 6y ago

Provocative, exaggerated title but a great article. I would argue that many bodies of source code are worth something even if they were handed to me without any additional info. Let's say I'm working with a new microcontroller and someone gives me the source to a TCP/IP stack for that new micro. From the data sheet of the micro I could make sense of the lower levels of the stack and TCP/IP is so well defined that just the value of someone making it work on the particular hardware, which is mostly busywork, has huge value.

bjornsing 6y ago

I agree with the conclusions, but the premise that “source code is worthless” is click-baity and misleading. After having gone through a few M&A discussions with a high-tech software startup this is how I think about it: Nobody wants to buy just the source code. Talent / team that is used to work together and has proven itself has some value (i.e. “talent acquisition”), but valuation won’t be very high. What’s really valuable is talent and code (with IPR rights) combined. But don’t think you can put the source code on GitHub under an MIT license and it won’t affect your M&A discussion... ;)

shahrk 6y ago

Unless you are Waymo and the theft is by one of your employees.

cccc4all 6y ago

Source code is worthless AFTER it's written. It still has to be written first.

dwohnitmok 6y ago

This is startup-centric and depends heavily on the velocity of your project. For intrinsically difficult problems that evolve slowly or not at all (the most extreme example of this would be e.g. unsolved CS problems), source code is gold and its theft represents a huge blow to any competitive advantage a product might have had. Note that this is different from saying the source code itself doesn't evolve. For problems whose difficulty relies rather on business concerns and which evolve rapidly then (the theft of) source code is nearly worthless.

castwide 6y ago

The article makes a lot of good points, but I disagree with the notion that source code is worthless. The true test of the source's value isn't what would happen if it got stolen. It's what would happen if it disappeared altogether.

IggleSniggle 6y ago

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.

CryptoGhost 6y ago
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 firms don't have to roll their own but thats not a hard and fast phenomenon.
- IggleSniggle 6y ago
  I agree, but at least for me, this did not diminish the value of the article.
- mjburgess 6y ago
  I think "software company" can probably hold the weight of the argument, if defined well. ie., a Bank maybe finds most of its value in that its code runs, etc. A software company, perhaps, we could define (1) simply as any company where this is true; or if that's cheating, (2) any company where its competitive advantage derives from its software developing over time. I think the claim of this article is that (1) and (2) refer, aproximately, to the same companies: ie., that software which is changed to adapt to ever changing needs derives that capacity from the "theory of the programmers" and not the code.

paxys 6y ago

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 thrown out.

ncmncm 6y ago
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.

jayd16 6y ago

"Kill your darlings" is probably a better aphorism. Obviously source code is useful on its face, and its also the truest documentation of current requirements. Worthless is an overstatement.

deleted 6y ago

[deleted]

aeldidi 6y ago

Rather than "Source Code is Worthless", I find it makes more sense to think of the lesson learned here as "Source Code is Only Worth Something to the Public if it's Well Documented and Stable", which happens to be true more often in practice. For example, someone I used to know would always say that while the Linux kernel as a product (a free and open source operating system) is priceless, the source itself is worthless unless you have an understanding of its internals, and I think that this is generally true for codebases of similar size and complexity, although I'd argue Linux specifically doesn't fall into this area only because of the fact that drivers make up most of the code in it. Stability is especially important when considering long term worth of code. When youtube-dl was removed from GitHub not too long ago, people were worried that the project would stop being updated and maintained, despite the fact that mirrors of the source code were everywhere. In that case, because the project needs constant updating and maintaining to keep up with websites like YouTube who have no incentive to continue to keep a stable API for downloading videos.

superjan 6y ago

This is easier to reason about if it’s not about your own code. Consider this: would you swap your own codebase for your competitor’s if you had the chance? For me, it’s a resounding no. I bet it’s the same from their perspective.

jhallenworld 6y ago

Source code is most valuable to the person who wrote it / knows it intimately. If I can use my code on different jobs it will definitely save me time. For this reason I try to make any library code MIT licensed. This allows me to use it for different clients without them complaining. Our contracts are set up to allow this. Often the customer's proprietary code is a small fraction of all the code.

blindm 6y ago

> Communicating the mapping of the code and the real world, as Naur describes, would have required us to document all these processes in meticulous detail. If we had tried to, I believe the result would’ve been multiple hundred pages describing the business processes Or in other words: building in business logic is paramount and the only thing you should be doing if running a startup, otherwise these engineers are just dossing around with code that doesn't yield a profit.

dbrueck 6y ago

The article is great, though a more accurate (but admittedly less thrilling) title would have been "Poorly Documented Source Code Is Virtually Worthless". Good source code includes level of intent comments, it explains the reasoning behind decisions (especially the tradeoffs that were made) and warns future readers of potential pitfalls. In both a professional setting as well as when wanting to contribute to a favorite OSS project, few things are more frustrating than jumping into the code only to realize it's missing this type of info.

jimmyvalmer 6y ago
> "Poorly Documented Source Code Is Virtually Worthless". And richly documented code is non-virtually worthless. If you don't believe me, try parsing one of these so-called "literate programs." Any 10-year vet will far more quickly grok a piece of code when its textual flow isn't disrupted by verbiage that only makes sense to its author.

dang 6y ago

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

jimmyvalmer 6y ago
It's baity because it's true.
- dang 6y ago
  That is not an adequate theory of baitiness.
wnoise 6y ago
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.
- dang 6y ago
  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.
  - wnoise 6y ago
    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.

nitwit005 6y ago

The problem with saying it's about developers building up theory is that we all tend to forget quite a bit. Code tends to contain a ton of fixes, versioning details, or algorithmic tricks no one remembers. I've certainly rebuilt something from scratch only to immediately stub my toe.

Ericson2314 6y ago

"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. Now, it still would be true that less source code is better than more source code, so line by line / marginally source code is a liability. But reproducible functionality would be valuable. The remaining worthless might have to do with much especially b2b proprietary software being utter crap, and all the value being in the sales relationship and none in product/service being traded.

ErikAugust 6y ago
I think it’s incentives, partially. Programmers say their job is to put themselves out of their jobs. People don’t want to be out of their jobs, really. And we know that doesn’t happen. If anything, it locks them into their job, as “subject matter experts”. Also, most applications are built on a million layers of reusable abstractions. Even in the highest level of the code people are using frameworks and other libraries. A lot of source code is just business logic and glue code when you remove the stuff it is built upon, which tends to be much better (and many times, open and free).
- Ericson2314 6y ago
  > Programmers say their job is to put themselves out of their jobs. People don’t want to be out of their jobs, really. And we know that doesn’t happen. If anything, it locks them into their job, as “subject matter experts”. I agree it is a fools errand to ask people to work against their incentives, but by https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox I don't think there is actually disincentive given enough risk tolerance to let the new equilibrium emerge. Write better programs, and increasing the demand for programming. I think the bigger problems is most programs are bad and alienated. Programming with everything nicely packaged and ready to be modified is like working with a clean workbench / shop. If you've never been in a clean one, cleaning seems like a chore, but if you have, working in a dirty one seems not only inefficient, but gross and undignified. It's "take care of your tools, and your tools take care of you" vs being "lord of my garbage heap of tech debt". Any self-respecting craftsperson should choose the former.

iamwil 6y ago

Anyone read the post author's book, Hiring Engineers? Is it any good and worth the $75?

cloogshicer 6y ago
Hey, author here. What's the situation that you're in? You (or anyone else reading this) can ping me at alexander [at] hiringengineersbook [dot] com, maybe I can help you figure out if the book is good for your situation or give some advice on the spot. No worries, not trying to sell anything (other than the book), just always curious what challenges people are facing when hiring.

TheJoYo 6y ago

I'm missing where autonomy comes into this.

pan69 6y ago

Source code isn't worthless, it's just not as important as the developers who wrote it because those developers can write a next, much better version, of the same software with the domain knowledge they have acquired writing the previous version(s). In practice this means that source code is disposable.

dbsmith83 6y ago

I agree with the conclusions drawn in the article, but not the premise. Source code is definitely not worthless. Two examples: 1) using source code to find security exploits 2) competitive machine learning algorithms In the second case, imagine if a competitor had access to algorithms used in marketing for bidding on ads. You know what features it uses, what default values it uses, how it works, etc. You could do some damage with that knowledge

enobrev 6y ago
It seems that you not only agree, but argue further that source code is a liability.
- dbsmith83 6y ago
  Hah, nice try, but no. Arguing that something is a liability if it fell into the wrong hands does not mean it is worthless or worth less than zero. It simply means it is worth protecting.

TheJoYo 6y ago

> They would be much faster just building it themselves from scratch, than trying to understand the crummy code we had hacked together. They might use your code as a reference, especially from any research components of the project. You'd be surprised what automated analysis of gitlab repos bring to light.

mywittyname 6y ago

I feel like the Unix philosophy of very small programs that do one thing, and do it well, is an application of the concepts in this article. > One of Naur’s main conclusions is that making changes to an existing program (to accommodate changing requirements) is often more costly than writing new code from scratch, at least if done by people from a different team. 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: Small, single purpose applications require less maintenance (which is expensive), but proper design allows them to be combined to create more complicated programs.

daotoad 6y ago
But to compose something large you begin to need hundreds of these small tools interacting. Do you build slightly larger tools that integrate the small tools? Even these larger tools my need to be composed into another level of abstraction to build the final system. This is essentially the same architecture that you would build with a layered set of abstractions and interfaces. It's really just a matter of how the different bits communicate that is different.

yudlejoza 6y ago

- There's no such thing as programming - There's only research programming

daotoad 6y ago

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 == primitivism == bad and undesirable. But I've come to believe that there are always going to be things that cannot or should not be represented in written documentation. Documentation is an artifact that must be maintained. Individual professionals and organizations spend a huge amount of energy producing, managing, and maintaining written documentation. But how much time have we spent on oral transmission of ideas? Almost none. And that's because we dismiss it as an approach. It's seen as less than or primitive, or at best something to discourage. But if you accept that there must always be some oral information, then ignoring the issues of how we communicate, update, and persist that orally transmitted information seems foolish. There are cultures that have more recently made the the transition from being primarily oral to literal that have not forgotten the skills needed to manage this class of knowledge. I wonder what practices we can learn from them that we can use to improve our ability to share and communicate more effectively.

pasquinelli 6y ago
would the oral transmission of information be what's called in other industries training?
cloogshicer 6y ago
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 https://www.youtube.com/watch?v=pW-SOdj4Kkk Do you have any resources you can recommend on this topic?
gmfawcett 6y ago
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."

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

breck 6y ago

The more you design your program for the current world, the faster it will go out of date. Try to identify what will still be useful in 30 years, and get that part right.

bennysonething 6y ago

This is probably one the most poignant things I've read about programming. I've recently been through a handover, left on my own at at a new job, with a long back log full of fairly useless stories, left to forge relationships with the business. Mostly left depressed and stressed. All the while a manager said "I don't understand why the handover is taking so long, it's all documented". Yeah the documentation didn't really tell me much as I lacked the business context. I'm brand new to this domain too. The article has put into words what I've been feeling for the last year.

StillBored 6y ago

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 were throwing it away. It would be really hard to convince MS/Google/apple/etc that their primary products source code doesn't have any value.

horsawlarway 6y ago
I disagree with you... sort of. I think there's some truth that code has value, and there is some risk that making it available can cut into profits (See: Redis, Mongo, etc, changing course after open offerings became available on AWS/Azure/GCP). But I think the much larger truth is that most of the value provided by companies (and most of what they charge for) is not "lines of excellent code" but rather the operating expertise of keeping a complicated system stable and available. For example - All of the companies you listed do have widely available, open source offerings (Android, VS-Code, Mono, Swift, Webkit, etc). The value wasn't in the code, the value was in the ecosystem around it. I think this is true in more cases than folks expect. The Windows source code was leaked, but I don't see any companies scrambling to compete with MS by building on that code. I think even if most of Google's repo was made public - the valuable part was the team that supports the infrastructure behind it, not the lines of code themselves (or at least, they make up a smaller portion of the value)
- StillBored 6y ago
  Well I don't disagree with that either. Only that I must point out that libre washing a company with an open source product here/there doesn't really count. Sure android is open, but google isn't using it to make money directly, instead it feeds into the closed source ad/marketplace offerings. If they opened that code, or apple opened up the entire iOS stack its quite likely they would have competitors that as you point out lowered the value of their primary offerings. A google with a half dozen competent ad/search companies would look very different than the one that can afford to give away a large part of their product portfolio. So, there is value in operating a "service" buisness, but there is even more value in operating a service business that has high barriers to entry. One way to erect those barriers is with hundreds of millions of dollars in engineering time spent on "source code" be that the code actually doing the searches/etc or the code being used to manage the clusters its running on.

Vinnl 6y ago

The relative worthlessness of source code can easily be seen when the situation is flipped around. When you're told you can look at e.g. a competitor's source code, some open source code somewhere, or a prototype that a colleague already built during a proof-of-concept, that will almost never make you go much faster. Meanwhile, I think organisations underestimate the cost of attempting to keep source code secret. It adds friction to almost every step of the development process, compared to not worrying about whether your build logs or repositories are publicly accessible, even if they're not open source.

StillBored 6y ago

Thinking about this more, I wonder if you can predict whether a software project is "failing" by the amount of code that is getting deleted early on. I've been part of a half dozen or so successful medium->large scale projects, and we never really deleted large parts of the code base. The small teams bootstrapping them had a pretty clear goals of where they were going sufficiently to build a reasonable scafold early on to get somewhat working prototypes. Then as the project took shape things were fleshed or refactored far more than they were thrown away. OTOH, projects i've seen fail frequently had core pieces rewritten on a somewhat regular basis. Which if you think about it in the sense that every time a chunk of code is wholesale replaced, that is X man hours of effort flushed down the toilet. Few startups can afford engineers to be working on things which don't go towards the bottom line. AKA if you have 6 engineers, and on average are replacing 25% of the code base a year, that is the equivalent of just throwing away 25+% of your runway every year. With the team communications overhead/etc I could totally see that it might be possible to never actually make forward progress even though the amount of code being thrown away isn't >50%

deleted 6y ago
[deleted]
fwip 6y ago
The amount of code written isn't static, and doesn't map neatly to "amount of developer effort." If everything you write has to be "perfect" the first time around, you'll write a fraction as much as if you're willing to build 3 things (either now, or in the future), and take whichever works out the best. It might take more time, or it might take less time.

Simplicitas 6y ago

Hyperboles will always derail any conversation

throwawaygh 6y ago

> Especially for the lower-level components, a good amount of research had been involved. We worked closely with an academic institute that specialized in computer vision. In short, this project wasn’t something that anybody could just easily recreate. So one of the assumptions we had implicitly made was that our source code was one of the company’s major assets. Why not patent?

musicale 6y ago

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

plutonorm 6y ago
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.
- devlopr 6y ago
  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.
- jagged-chisel 6y ago
  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...
  - plutonorm 6y ago
    This is the opinion of management in England too. Except here there is no way to break into management without going back to school and even then it won't be easy to shake the "developer" image. I'm currently doing a startup, not because I want to do startups, but because I need to get out of development for the sake of my mental health and starting your own company is the only available avenue I have for achieving the transition.

username90 6y ago

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

sriku 6y ago

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

nojvek 6y ago

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.

mcv 6y ago

I completely agree with this. I never find documentation very useful, and I'm fully aware I've got tons of theory in my head that I couldn't begin to write down. I should try harder because I won't stay on this project forever, and there are enough complex concept involved that aren't immediately obvious. But how do I write that down? And where do I start?

TobySKT 6y ago

Just do audits. There are ISO standards for practically everything and you should run internal audits (and external ones if you can afford it for important stuff)

p4bl0 6y ago

The article from Peter Naur is a must-read. And what it says is absolutely not limited to programming. It is a politically deep and important paper that applies to virtually every human activity that adds value. I recommend reading this paper to all my computer science students. I took the liberty to make a better formatted and easier to read PDF of it a while ago: https://pablo.rauzy.name/dev/naur1985programming.pdf https://pablo.rauzy.name/dev/naur1985programming.pdf

YeGoblynQueenne 6y ago

Could we please change the title back to its original? There is no obvious reason for changing it on the HN post. The title of the article is How to hire senior developers: Give them more autonomy and it's not about Peter Naur's view of programming, it's about the author's view on how to hire senior developers. The article has a few select quotes from Peter Naur's article "Programming as theory building" but the quotes are mainly used to advance the article author's opinions on hiring senior developers, rather than Peter Naur's idea of what programming is. Peter Naur does not seem to be related to this article or its author at all.

notacoward 6y ago

Had a very similar moment at one of the startups I worked for, which also served as my introduction to a new CEO. Shortly after NewCEO was hired, we had an all-hands introduction meeting. "All hands" at this point meant about 50 people, so our largest conference room was packed. I ended up sitting on the floor by the big whiteboard, opposite NewCEO. He started talking about how bigger companies were (he believed) actively trying to reverse-engineer our product. Without exactly meaning to, I said "good luck" loudly enough to get his attention, so he looked at me expectantly. "We're having enough trouble engineering it forwards." A few people laughed. NewCEO kind of glared. I guess I should mention that I was the product architect BTW. We never particularly got along, but he was neither the first nor the last CEO I outlasted during my career so meh. Getting back to the point, maybe a competitor who had access to our code might, with great difficulty, learn something about the problem domain we were exploring (continuous data protection). More likely they would have been misled by all the remnants of wrong turns we'd taken during the exploration process. They'd literally be better off without it. Our entire business was a gamble that we could get to market before bigger competitors woke up to the opportunity and threw more bodies/dollars at it. As it turns out, that's exactly what did happen. We lost the bet. Other people having our code would not have changed that outcome one bit.