I agree with the ideas at a high level, but not sure if we can tag people as “Junior” and “Senior” and make these broad strokes about how they think.
We should think of it in terms of “Theory Builders” and “Just get it done-ers”, and think of them as states of mind, rather than a character trait, or something linked to years of experience.
You may have a theory builder straight out of university (after all many go on to do a PhD straight away!), or a theory builder who has the mindset and just came in from a different profession. Or an 8 year old theory builder! You may have someone with 10 years experience writing code who still slings code.
You may also have one person who was a Theory Builder on Monday, and became a "Get it done-er" by Friday due to a deadline.
Or the person that starts off in "get it done" mode because it looks trivial, notices that it's not and then takes a few steps back to think it through first.
Honestly, these opinions are almost always grounded in people not being honest with themselves, feeling superior to their colleagues and coming up with a character trait and argument why they're just fundamentally better
Sometimes they even are, at least to a degree. No idea wherever it's true in this case, as I know nothing about Christian Ekrem beyond this article.
The article is about Senior Engineers where time spent is a huge factor in the distinction. It would be more that theory building becomes a tuned skill for an engineer over time as a fundamental result of their job than whether they use it every day, started with it as their primary method, etc.
I personally think one does a lot of the theory building while you're getting it done because you're building something new and can't predict the kinds of issues that youll encounter.
Any sort of software that's architected only in flowcharts and uml by 'pure architects' are absolutely worthless to anyone but business people.
I agree that there needs to be a feedback loop including the system and decision makers (I also have a distrust of non-contributing 'architects').
However, just because you can 'get things done' in the current system doesn't imply you have a good enough theory for maintaining it sustainably. I've often seen self proclaimed 10x coders who trade healthy shared theory for mean time to deployment too aggressively.
They are fast, get praise and pay, then move on before the negative effects of their short term strategy becomes clear.
Another job of 'senior' devs is to point out to the business when this is happening.
Senior dev: We’re building a sandwich. It needs a roasted tomato, thin sliced, X mm in thickness. Add some bacon. I want mayonnaise but it needs to be feature gated.
I noticed that. If I don't write the code myself I only develop a very shallow mental model of what's doing. But I guess that always has been the product managers perspective.
I don't think you need to write the code to develop a deep mental model of what's going on, but you do need to think about it a lot and intensely to develop that model and coding forces you to slow down, spend a lot of time thinking about the problem, and generally trying out different ways of looking at it.
Coding in this way is like having a personal Socrates to help walk you through the problem and achieve enlightenment.
This is the way I feel as well. I think there is an ethical way of using AI as an assistant: have it either generate a high level plan for what the architecture of your solution should look like (and decide whether the choice looks correct for the domain and actionable), or let it generate the code and then walk yourself through each line, documenting the solution as you go. I will go as far as to do the latter and then delete the code, re-implementing it to make certain I understand the relevant concepts.
The same thing happens with third party tools and frameworks/libs. The documentation very rarely help you develop a sound mental model of how it work, so your only option is to get your hands dirty - and often also burn your fingers in the process.
I agree with the ideas at a high level, but not sure if we can tag people as “Junior” and “Senior” and make these broad strokes about how they think.
We should think of it in terms of “Theory Builders” and “Just get it done-ers”, and think of them as states of mind, rather than a character trait, or something linked to years of experience.
You may have a theory builder straight out of university (after all many go on to do a PhD straight away!), or a theory builder who has the mindset and just came in from a different profession. Or an 8 year old theory builder! You may have someone with 10 years experience writing code who still slings code.
You may also have one person who was a Theory Builder on Monday, and became a "Get it done-er" by Friday due to a deadline.
Or the person that starts off in "get it done" mode because it looks trivial, notices that it's not and then takes a few steps back to think it through first.
Honestly, these opinions are almost always grounded in people not being honest with themselves, feeling superior to their colleagues and coming up with a character trait and argument why they're just fundamentally better
Sometimes they even are, at least to a degree. No idea wherever it's true in this case, as I know nothing about Christian Ekrem beyond this article.
The article is about Senior Engineers where time spent is a huge factor in the distinction. It would be more that theory building becomes a tuned skill for an engineer over time as a fundamental result of their job than whether they use it every day, started with it as their primary method, etc.
I personally think one does a lot of the theory building while you're getting it done because you're building something new and can't predict the kinds of issues that youll encounter.
Any sort of software that's architected only in flowcharts and uml by 'pure architects' are absolutely worthless to anyone but business people.
I agree that there needs to be a feedback loop including the system and decision makers (I also have a distrust of non-contributing 'architects').
However, just because you can 'get things done' in the current system doesn't imply you have a good enough theory for maintaining it sustainably. I've often seen self proclaimed 10x coders who trade healthy shared theory for mean time to deployment too aggressively.
They are fast, get praise and pay, then move on before the negative effects of their short term strategy becomes clear.
Another job of 'senior' devs is to point out to the business when this is happening.
Among magazine staff there’s a saying about “senior editors”: senior to whom, editor of what?
Naur's essay is not about time spent in the field, which is what 'senior' usually means; it's about time spent on a particular team.
Could’ve just explained it in less words.
Junior dev: Make me a sandwich.
Senior dev: We’re building a sandwich. It needs a roasted tomato, thin sliced, X mm in thickness. Add some bacon. I want mayonnaise but it needs to be feature gated.
One sandwich later. . .
Senior dev: where’s my bread man?
I noticed that. If I don't write the code myself I only develop a very shallow mental model of what's doing. But I guess that always has been the product managers perspective.
I don't think you need to write the code to develop a deep mental model of what's going on, but you do need to think about it a lot and intensely to develop that model and coding forces you to slow down, spend a lot of time thinking about the problem, and generally trying out different ways of looking at it.
Coding in this way is like having a personal Socrates to help walk you through the problem and achieve enlightenment.
This is the way I feel as well. I think there is an ethical way of using AI as an assistant: have it either generate a high level plan for what the architecture of your solution should look like (and decide whether the choice looks correct for the domain and actionable), or let it generate the code and then walk yourself through each line, documenting the solution as you go. I will go as far as to do the latter and then delete the code, re-implementing it to make certain I understand the relevant concepts.
The same thing happens with third party tools and frameworks/libs. The documentation very rarely help you develop a sound mental model of how it work, so your only option is to get your hands dirty - and often also burn your fingers in the process.
I reference this paper all the time, it completely changed the way I think about software.
With lots of HN threads over the years!
AI code is legacy code? - https://news.ycombinator.com/item?id=43888225 - May 2025 (170 comments) (via https://news.ycombinator.com/item?id=43889200)
Naur's "Programming as Theory Building" and LLMs replacing human programmers - https://news.ycombinator.com/item?id=43818169 - April 2025 (129 comments)
Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=42592543 - Jan 2025 (44 comments)
Programming as Theory Building (1985) - https://news.ycombinator.com/item?id=38907366 - Jan 2024 (12 comments)
Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=37263121 - Aug 2023 (36 comments)
Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=33659795 - Nov 2022 (1 comment)
Naur on Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=31500174 - May 2022 (4 comments)
Naur on Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=30861573 - March 2022 (3 comments)
Programming as Theory Building (1985) - https://news.ycombinator.com/item?id=23375193 - June 2020 (35 comments)
Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=20736145 - Aug 2019 (11 comments)
Peter Naur – Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=10833278 - Jan 2016 (15 comments)
Naur’s “Programming as Theory Building” (2011) - https://news.ycombinator.com/item?id=7491661 - March 2014 (14 comments)
Programming as Theory Building (by Naur of BNF) - https://news.ycombinator.com/item?id=121291 - Feb 2008 (2 comments)