This article further emphasizes the obvious point that as programmers are well on the way to destroying their own profession and their work is poised to wreck the entire world, that it's time raise awareness that programmers work with much less discipline and responsibility than other professional, accredited, licensed trades, like say... doctors.
But for now, sure, why not just compare yourself to surgeons, as you already anoint yourselves as "engineers".
I really like Geoffrey Litt's new analogy for working with AI coding tools:
> Personally, I'm trying to code like a surgeon.
> A surgeon isn't a manager, they do the actual work! But their skills and time are highly leveraged with a support team that handles prep, secondary tasks, admin. The surgeon focuses on the important stuff they are uniquely good at.
It's also a neat callback to the Mythical Man Month, the most influential early textbook on large scale software engineering.
I sometimes use AI summaries to get the answers I need out of badly written documentation. That's about as far as I find any value or productivity boost.
Consider that this "surgeon" analogy has always been applicable when docs or books are better written and full of useful examples. Also consider that a lot of the annoying "plumbing code" you probably want AI for is fairly closed-ended as there are only so many combinations of API use possible.
I'm really not understanding the continued hype in 2025.
A surgeon has 4 years of undergraduate education, 4 years of medical school, and a 5 year residency, learning to operate (pun intended) with other equally highly trained specialists, many of whom are peers, like anesthesiologists, not merely support. The comparison was already dubious when Brooks made it for operating systems programming. Setting up a comparison with the average "I don't use anything I learned in my CS degree, lol" coder wrangling a chorus of hallucinating stochastic parrots is a bonkers level of hubris from techbros.
XD yes sure. I'd most definitely put those on the same level. Maybe even favor an UI prototyper if it comes down to the real deal. Who needs an open heart surgery when you can have a magnificent css-hover animation that really seals the deal on some 90%-AI-generated slob that only caters to delusional top-management completely out-of-touch with reality.
Irony off: Let's try it with a bit of humbleness next time, ey?
I’ve long advocated that software engineers should read The Mythical Man-Month[0], but I believe it’s more important now than ever.
The last ~25 years or so have seen a drastic shift in how we build software, best trivialized by the shift from waterfall to agile.
With LLM-aided dev (Codex and Claude Code), I find myself going back to patterns that are closer to how we built software in the 70s/80s, than anything in my professional career (last ~15 years).
Some people are calling it “spec-driven development” but I find that title misleading.
Thinking about it as surgery is also misleading, though Fred Brooks’ analogy is still good.
For me, it feels like I’m finally able to spend time architecting the bridge/skyscraper/cathedral, without getting bogged down in terms of what bolts we’re using, where the steel come from, or which door hinges to use.
Those details matter, yes, but they’re the type of detail that I can delegate now; something that was far too expensive (and/or brittle) before.
There's not a lot that Brooks got wrong but the surgical team is it.
There's not a lot of team in a surgical team. Software does not need to be limited to one thing happening at a time the way open heart surgery does. There's room for more hands.
It's more like a sports team. But we don't practice, review, or coach the way they would, and so it takes a lot longer for us to reach excellence.
We're now getting in a position where we have CAD for software, aka CASE, Computer Aided Software Engineering. You can focus on the design of the software, instead of spending hours typing out code.
> My current goal with AI coding tools is to spend 100% of my time doing stuff that matters. (As a UI prototyper, that mostly means tinkering with design concepts.)
this struck me as weird. both in terms of “tinkering” being the most important thing to be doing, and then also describing “working like a surgeon” to be tinkering.
If your development team consists of autistic junior programmers with eidetic memory, then you damn well better make sure that your documentation is exceedingly thorough, absolutely unambiguous, and as restrictive as you can make it.
It's a nice analogy, and I think I'll use it in future.
If you want another one, think of painting. An "Old Master" painter like Rembrandt or Rubens or Botticelli would have had a large workshop with a team of assistants, who would not only do a lot of the work like stretching canvases or mixing the paints, but would also - under the master's direction - actually do a lot of the painting too. You might have the master sketch out the composition, and then paint the key faces (and, most of all, the eyes) and then the assistants would fill in areas like drapery, landscape, etc.
This changed in the Romantic period towards the end of the 1700s, with the idea of the individual artist, working alone in a moment of creative inspiration and producing a single work of genius from start to finish. Caspar David Friedrich or JMW Turner come to mind here.
Some programmers want to be Turner and control the whole work and feel their creativity is threatened if a machine can now do parts of it as well as they could. I'd rather be Rembrandt and sketch out the outline, paint the eyes, and leave the rest to junior engineers... or an AI Agent. It's a matter of preference.
> I'd rather be Rembrandt and sketch out the outline, paint the eyes, and leave the rest to junior engineers
What you’re not mentioning is that code isn’t and end product. It’s the blueprint for one. The end product is the process running and solving sone needs.
What makes software great is how easy it is to refine. The whole point of software engineering is to ensure confidence that the blueprint is good, and that the cost of changes is not enormous. It’s not about coding quickly, throw it over the wall and be done.
The process you outline would be like noting down a few riffs, fully composing a few minutes (measures?) and then have a few random people complete the full symphony. It’s not a matter of having a lot of music sheet, it’s a matter of having good music. The music sheet is important because it helps transmit the ideas to the conductor, who then trains the orchestra. But the audience doesn’t care about it.
So same, users don’t care about the code, but they do care about bugs and not having features. Acting on those feedbacks requires good code. If you can get good code with your process, it’s all good. Bit I’m still waiting for the proof.
Spent most of my time in thinking and asking Claude the right questions at the right moment instead of typing code. Review the code agent generated, let it run tests, deploy to PR branch for live debugging. Review console log and network traffic, paste the information to Cursor and ask Claude for the root cause, code paths and data flow. Solve issues one at a time.
It does feel like a surgeon working with a team of assistants. A lot of information, a lot of decisions, a lot of patience and focus.
46 comments
[ 2.8 ms ] story [ 55.1 ms ] threadCode like a programmer.
This article further emphasizes the obvious point that as programmers are well on the way to destroying their own profession and their work is poised to wreck the entire world, that it's time raise awareness that programmers work with much less discipline and responsibility than other professional, accredited, licensed trades, like say... doctors.
But for now, sure, why not just compare yourself to surgeons, as you already anoint yourselves as "engineers".
> Personally, I'm trying to code like a surgeon.
> A surgeon isn't a manager, they do the actual work! But their skills and time are highly leveraged with a support team that handles prep, secondary tasks, admin. The surgeon focuses on the important stuff they are uniquely good at.
It's also a neat callback to the Mythical Man Month, the most influential early textbook on large scale software engineering.
Consider that this "surgeon" analogy has always been applicable when docs or books are better written and full of useful examples. Also consider that a lot of the annoying "plumbing code" you probably want AI for is fairly closed-ended as there are only so many combinations of API use possible.
I'm really not understanding the continued hype in 2025.
Can you imagine a surgeon using Claude Scalpel as an agent to just go ahead and fix that one artery?
But this time with agents.
Fred Brooks has never been more relevant.
[0]: https://en.wikipedia.org/wiki/Chief_programmer_team
The key quote was something like "You want your software to be like surgery - as little of it as possible to fix your problem".
Anyway, it doesn't seem like this blog post is following that vibe.
XD yes sure. I'd most definitely put those on the same level. Maybe even favor an UI prototyper if it comes down to the real deal. Who needs an open heart surgery when you can have a magnificent css-hover animation that really seals the deal on some 90%-AI-generated slob that only caters to delusional top-management completely out-of-touch with reality.
Irony off: Let's try it with a bit of humbleness next time, ey?
The last ~25 years or so have seen a drastic shift in how we build software, best trivialized by the shift from waterfall to agile.
With LLM-aided dev (Codex and Claude Code), I find myself going back to patterns that are closer to how we built software in the 70s/80s, than anything in my professional career (last ~15 years).
Some people are calling it “spec-driven development” but I find that title misleading.
Thinking about it as surgery is also misleading, though Fred Brooks’ analogy is still good.
For me, it feels like I’m finally able to spend time architecting the bridge/skyscraper/cathedral, without getting bogged down in terms of what bolts we’re using, where the steel come from, or which door hinges to use.
Those details matter, yes, but they’re the type of detail that I can delegate now; something that was far too expensive (and/or brittle) before.
[0]https://en.wikipedia.org/wiki/The_Mythical_Man-Month
There's not a lot of team in a surgical team. Software does not need to be limited to one thing happening at a time the way open heart surgery does. There's room for more hands.
It's more like a sports team. But we don't practice, review, or coach the way they would, and so it takes a lot longer for us to reach excellence.
this struck me as weird. both in terms of “tinkering” being the most important thing to be doing, and then also describing “working like a surgeon” to be tinkering.
It can be summarized as "adding more workers to a project does not speed things up, that's a myth".
It's in the title of the book. It's a good book.
The entire IT field is about to test that idea in a massive scale. Can lots of new automated workers speed things up? We'll see.
If your development team consists of autistic junior programmers with eidetic memory, then you damn well better make sure that your documentation is exceedingly thorough, absolutely unambiguous, and as restrictive as you can make it.
If you want another one, think of painting. An "Old Master" painter like Rembrandt or Rubens or Botticelli would have had a large workshop with a team of assistants, who would not only do a lot of the work like stretching canvases or mixing the paints, but would also - under the master's direction - actually do a lot of the painting too. You might have the master sketch out the composition, and then paint the key faces (and, most of all, the eyes) and then the assistants would fill in areas like drapery, landscape, etc.
This changed in the Romantic period towards the end of the 1700s, with the idea of the individual artist, working alone in a moment of creative inspiration and producing a single work of genius from start to finish. Caspar David Friedrich or JMW Turner come to mind here.
Some programmers want to be Turner and control the whole work and feel their creativity is threatened if a machine can now do parts of it as well as they could. I'd rather be Rembrandt and sketch out the outline, paint the eyes, and leave the rest to junior engineers... or an AI Agent. It's a matter of preference.
What you’re not mentioning is that code isn’t and end product. It’s the blueprint for one. The end product is the process running and solving sone needs.
What makes software great is how easy it is to refine. The whole point of software engineering is to ensure confidence that the blueprint is good, and that the cost of changes is not enormous. It’s not about coding quickly, throw it over the wall and be done.
The process you outline would be like noting down a few riffs, fully composing a few minutes (measures?) and then have a few random people complete the full symphony. It’s not a matter of having a lot of music sheet, it’s a matter of having good music. The music sheet is important because it helps transmit the ideas to the conductor, who then trains the orchestra. But the audience doesn’t care about it.
So same, users don’t care about the code, but they do care about bugs and not having features. Acting on those feedbacks requires good code. If you can get good code with your process, it’s all good. Bit I’m still waiting for the proof.
“Surgically” is how one enters a foreign codebase, especially legacy ones.
Code surgeons, where are they now on the evolution path? Barbers? Butchers?
I doubt it, quite dangerous.
Spent most of my time in thinking and asking Claude the right questions at the right moment instead of typing code. Review the code agent generated, let it run tests, deploy to PR branch for live debugging. Review console log and network traffic, paste the information to Cursor and ask Claude for the root cause, code paths and data flow. Solve issues one at a time.
It does feel like a surgeon working with a team of assistants. A lot of information, a lot of decisions, a lot of patience and focus.
I'd like to officially coin the term "Trad Engineering" and/or "Trad Coding".