At the end of the week, if you suffered a hard drive crash and all of your recent code got erased, how quickly could you recreate it? That's how much of your week was spent coding. The rest of the week was spent transforming you into the person who could code the thing you coded.
Contrast this with a chair maker. If at the end of the week, their chair got thrown in a woodchipper, some significant fraction of the next week would be in unavoidable labor making the exact same chair.
This is the fundamental difference between these two activities that gets abstracted away when we both think of them as "labor".
I see where you're coming at. But don't underestimate the amount of design work that goes into making a good chair. It probably took more time than your think, which transforms them into the person who can craft the chair
Yes, but that is part of the point: a chair being built is mostly distinct from a chair being designed (there is of course a small amount of design that is done while building). Software is designed at a much higher percentage while being created (or if you prefer, there is a cycle between the two states).
You also don’t often learn why you don’t need a chair while building one.
> or if you prefer, there is a cycle between the two states
Yes, what I mostly emphasize with this mode of thinking is that the act of building software is primarily there to transform people (you try a thing, it doesn't work like you think it would, that inspires you to try another thing) and the software at the end of it is largely a byproduct.
If you have the right people-state, producing the software is trivial, it's how do you port the right knowledge into their brains in the first place and and software should be just another tool in your toolbox towards that aim.
Chair makers do not make one chair - they make one for the whole family. Then they make more in a very similar style for the next family. There is very little new design in a chair - it has all been done.
We don’t order bespoke-design chairs because construction is expensive, so we adapt to available chairs. In a world without construction-related scarcities and mostly design expenses (think sci-fi with that so far unachievable ability to manipulate the reality on molecular level), a chair can be feasibly created for specific personalities of yourself and others in given circumances, possible context in which you might use it, the interior it would fit in, etc.
In software, this kind of construction scarcity does not exist. Once you design a chair, you can instantiate it to your heart’s content.
Having been in this situation more than once, recreating a concept from scratch when you've already coded it once takes ~20% of the time. This also tracks with my long term empirical observation that roughly 80% of a software project is maintenance, testing, debugging, monitoring, fixing bugs, planning, refactoring, etc.
Sitting down to an editor and typing out ascii charachters is the smallest and least consequential part of software development. And that was _before_ LLMs enter the equation - now it's not even strictly necessary. The software industry needs to get over its obsession with coding as an activity, and with code as an asset. Code is at best a necessary liability. Software systems are what we should be focused on.
This is what I tell my students. The hard part of programming is the understand and plan phases and barely any of that takes place at the keyboard. The rest is just typing in your completed plan.
And if you find yourself going in circles while you're typing in code, you probably didn't complete the plan phase.
To elaborate a little, I told them that usually during this process you'll bounce back and forth a little bit. You'll notice while your coding something up there was something you didn't understand and so you drop back, understand, and then move forward again. So there's some back and forth, but hopefully general progress is forward.
As for iteration, there's a little bit of iteration in every phase. But there's also iteration over the entire process. Once you've understood the problem, come up with a plan, coded it up, and look back to see what could have been done better, it might be time to re-understand the problem.
The problem is not with code, its with management having no real perception of the problemspace they inhabitate and how they damage and polute said space.
The myriad of "nocode" aka i dont want to deal with the whole complexity solutions tells you what its really all about.
How do you get a caste todo its job when all they do is refuse the call to adventure, smear responsibility over hierarchy and then demand tools to shirk the job they refused todo in the first place?
especially if you include the total refusal of that caste to take responsibility - e.g. compliance - hence looking for any possibility to outsource that, be it M$ or AWS or (now new kid on da blok) "AI"
Wish there was a "capable" first management tracking tool, that rates organisations and companies by ability to create, maintain and innovate in tech. Sort of a reverse linkedIn for company culture, but only focused on that, department by department, not culture, no ammenities, just engineering culture. Must be worth something to not be stuck for a year or two in an invisible dead end filled with tech debt and pressure.
There’s more to it than that though. The solution using the least possible lines is often inscrutable and brittle. The art is in finding the right level of abstraction which can deliver the performance required while being sufficiently legible. Depending on the specific problem you have to weight your solution accordingly, if performance is critical you must often forfeit legibility. The art is in recognising and dealing with trade offs.
when building an airplane one of the goals is to figure out what you can remove without affecting the stability of the plane. performance (use of fuel) matters here too. so it's kind-of the same thing?
Yeah. I have occasionally seen the opposite: worked a couple of places where leaders were so keen for people not to write code it became frustrating. But never had anyone breathing down my neck to spend more time writing code.
I will say this. After all the thinking and discussion is done, code is the means by which the desired value is realised, so if you're an engineer and you never write any at all there is a chance you might not be as involved in delivering that value as you might like to think. Plenty of situations where that's not true, of course, but it's definitely one of those things that can be a smell.
Many non-dev people think LLM does the thinking and the typing. That’s where the misconception comes from as regards to LLM replacing completely developers I guess
> That’s where the misconception comes from as regards to LLM replacing completely developers I guess
The misconception also arises because Ai companies use the word thinking and everything else too which is what the general population says and then this just gets caught on by Engineers too.
When we say reason/think/etc. all the hype created by AI definitely gets a boost imo.
Do we say these for a lack of a better term or was it intentional that we say reason/think?
First of all I just want to say, I completely agree with the main point of this post, and argue for more full-lifecycle discussions on a regular basis at every job I've had.
With that said, I partially disagree this block:
> When I’m heads-down-coding, I’m not seeing, I’m not asking, and I’m not learning about the problem. To do that, I have to get up from my desk, go to where the problem is and/or the people I need to ask are, and have a conversation.
There are two types of problems when developing software. The problem of figuring out what you want to do, and the problem of figuring out how to do it.
These often impact each other, either because a limitation on what you can do changes what you end up trying to do, or because you learn something new about the use case, like this post describes. But keeping these two problems separated in your mind, at least for a time, is what lets us focus and find solutions.
>I’ve seen so many times how 10 lines of code can end up being worth £millions, and 10,000 ends up being worthless.
I don't care how easy it is, I'm not fixing something worth millions when I won't see a penny of that. It's on the business to double check their shit.
I think the ivory towers because managers mostly manage by how much of the plan can we ship. It is too radical to have developers take time from that to talk to customers which is a shame for the developer, customer and business.
This is one reason I always roll my eyes when people talk about how vim keyboard bindings are so great because you don't have to move your fingers from the home row. The actual action of typing text is a small part of the process of coding.
Depends on how you work I guess. I explore solutions through coding different versions of some algorithm, sure I could theorycraft as well but I am stronger by just writing code and see if it runs. I type a lot so vim motions help me a ton.
I agree. Vim is my default text editor, but it's not great as an IDE. Don't have much of a choice there either, and have to use the right tool for the job.
One way hand coding is productive is it gives you detailed intimate knowledge of the code. We’ve all seen someone that really knows a system hear about a bug and say “Aha!” and take 5 minutes to pump out a fix.
A well setup Claude Code, with good guardrails and feedback, could possibly do this (we’ve seen examples of it for sure). But it also might loop idiotically not finding the issue.
All the time i do it. I will often provide claude with read only credentials to the db or api access to the logs and it will nail the problem almost every time
Some codebase are a logical mess and have bad names as well. Sometimes Claude is wrong because the semantics of our legacy codebase doesn’t makes sense. Sometimes it find problems at the wrong places because of that.
I feel one upshot of AI coding is that people finally recognize 5 layer enterprise architectures for what they are - useless slop whose purpose is to make solutions more 'professional' and complicated to make the people who write them feel smart, inflate costs and personnel needs and sell consulting on how to solve problems with 5x more code than necessary.
The extra code doesn't encode any requirement.
On the other hand, these couple-hundred line, crappy spitballed together solutions that actually still do what is needed (and are usually are hand-written, LLMs aren't known for brevity) are vindicated.
There are lot of useless, self-serving abstractions out there (looking at you, Spring and Angular)
There is also a lot of useful abstraction that ensures you can more easily understand the system - and that sneaks in orthogonal features such as monitoring and robust error handling, that managers aren't happy to allocate much time for but that prove their worth once the system is actually running.
It's possible, LLMs now offer a different way to solve the same problem, because the cost of adding those orthogonal features now approaches zero jueas quickly as working on the rest of the code. ("Add logging, please"). So it is possible that a lot of frameworks that did provide real value in the past will become obsolete with LLMs.
On the other hand, if you look at stuff like Gas Town, then it's clear people will still revel into inventing crazy architectures full of arcane terminology, independent of how much it's actually needed.
So the only anecdote you could find from your long career is one example at the start of your contracting? What the hell with all those low quality shite talking about code this, code that?
> Founder of Codemanship Ltd and code craft coach and trainer
At the end of the week, if you suffered a hard drive crash and all of your recent code got erased, how quickly could you recreate it? That's how much of your week was spent coding. The rest of the week was spent transforming you into the person who could code the thing you coded.
Contrast this with a chair maker. If at the end of the week, their chair got thrown in a woodchipper, some significant fraction of the next week would be in unavoidable labor making the exact same chair.
This is the fundamental difference between these two activities that gets abstracted away when we both think of them as "labor".
I see where you're coming at. But don't underestimate the amount of design work that goes into making a good chair. It probably took more time than your think, which transforms them into the person who can craft the chair
Yes, but that is part of the point: a chair being built is mostly distinct from a chair being designed (there is of course a small amount of design that is done while building). Software is designed at a much higher percentage while being created (or if you prefer, there is a cycle between the two states).
You also don’t often learn why you don’t need a chair while building one.
> or if you prefer, there is a cycle between the two states
Yes, what I mostly emphasize with this mode of thinking is that the act of building software is primarily there to transform people (you try a thing, it doesn't work like you think it would, that inspires you to try another thing) and the software at the end of it is largely a byproduct.
If you have the right people-state, producing the software is trivial, it's how do you port the right knowledge into their brains in the first place and and software should be just another tool in your toolbox towards that aim.
Perhaps sometimes and in an ideal state, but most folks who code learn a lot and make a lot of design decisions while producing software.
Chair makers do not make one chair - they make one for the whole family. Then they make more in a very similar style for the next family. There is very little new design in a chair - it has all been done.
We don’t order bespoke-design chairs because construction is expensive, so we adapt to available chairs. In a world without construction-related scarcities and mostly design expenses (think sci-fi with that so far unachievable ability to manipulate the reality on molecular level), a chair can be feasibly created for specific personalities of yourself and others in given circumances, possible context in which you might use it, the interior it would fit in, etc.
In software, this kind of construction scarcity does not exist. Once you design a chair, you can instantiate it to your heart’s content.
Reference to https://en.wikipedia.org/wiki/Use_of_Weapons ?
True, except when the chairmaker has to make many times the same chair it becomes less relevant.
Having been in this situation more than once, recreating a concept from scratch when you've already coded it once takes ~20% of the time. This also tracks with my long term empirical observation that roughly 80% of a software project is maintenance, testing, debugging, monitoring, fixing bugs, planning, refactoring, etc.
Sitting down to an editor and typing out ascii charachters is the smallest and least consequential part of software development. And that was _before_ LLMs enter the equation - now it's not even strictly necessary. The software industry needs to get over its obsession with coding as an activity, and with code as an asset. Code is at best a necessary liability. Software systems are what we should be focused on.
Coding is when we carefully write down our solution to a problem.
(Manager pushes paper, pen and a list of problems in front of you and demands, “Now write, just write! And fast!”)
This is what I tell my students. The hard part of programming is the understand and plan phases and barely any of that takes place at the keyboard. The rest is just typing in your completed plan.
And if you find yourself going in circles while you're typing in code, you probably didn't complete the plan phase.
So where do you iterate? Most plans don't survive contact with reality, and all that.
To elaborate a little, I told them that usually during this process you'll bounce back and forth a little bit. You'll notice while your coding something up there was something you didn't understand and so you drop back, understand, and then move forward again. So there's some back and forth, but hopefully general progress is forward.
As for iteration, there's a little bit of iteration in every phase. But there's also iteration over the entire process. Once you've understood the problem, come up with a plan, coded it up, and look back to see what could have been done better, it might be time to re-understand the problem.
The problem is not with code, its with management having no real perception of the problemspace they inhabitate and how they damage and polute said space.
The myriad of "nocode" aka i dont want to deal with the whole complexity solutions tells you what its really all about.
How do you get a caste todo its job when all they do is refuse the call to adventure, smear responsibility over hierarchy and then demand tools to shirk the job they refused todo in the first place?
especially if you include the total refusal of that caste to take responsibility - e.g. compliance - hence looking for any possibility to outsource that, be it M$ or AWS or (now new kid on da blok) "AI"
Wish there was a "capable" first management tracking tool, that rates organisations and companies by ability to create, maintain and innovate in tech. Sort of a reverse linkedIn for company culture, but only focused on that, department by department, not culture, no ammenities, just engineering culture. Must be worth something to not be stuck for a year or two in an invisible dead end filled with tech debt and pressure.
E.W. Dijkstra: "Measuring programming progress by lines of code is like measuring aircraft building progress by weight".
Personally, I think, much of the art of programming is to do as much as possible with as few lines of code as possible.
That’s Bill Gates’, not Dijkstra’s.
measuring aphorism worth by attribution is like architecture about drowning.
To be fair there was no value judgement there, just a correction in attribution.
There’s more to it than that though. The solution using the least possible lines is often inscrutable and brittle. The art is in finding the right level of abstraction which can deliver the performance required while being sufficiently legible. Depending on the specific problem you have to weight your solution accordingly, if performance is critical you must often forfeit legibility. The art is in recognising and dealing with trade offs.
when building an airplane one of the goals is to figure out what you can remove without affecting the stability of the plane. performance (use of fuel) matters here too. so it's kind-of the same thing?
Agree, and even better solution some times: no code at all.
„Managers aim to maximise the amount of code their dev teams produce, and so they maximise the time devs spend writing code.„
Never seen that happen. Do not know anyone who experienced this. Where and who are those managers?
Same, when I do pair programming with my boss he’s very happy if we managed to remove more code than we added
Yeah. I have occasionally seen the opposite: worked a couple of places where leaders were so keen for people not to write code it became frustrating. But never had anyone breathing down my neck to spend more time writing code.
I will say this. After all the thinking and discussion is done, code is the means by which the desired value is realised, so if you're an engineer and you never write any at all there is a chance you might not be as involved in delivering that value as you might like to think. Plenty of situations where that's not true, of course, but it's definitely one of those things that can be a smell.
At my team deleted code is the best code.
Coding is the 5 minute result for an hour of thinking.
How do you define “coding”? In my mind the thinking is part of coding.
I like to say "coding is just typing"
Many non-dev people think LLM does the thinking and the typing. That’s where the misconception comes from as regards to LLM replacing completely developers I guess
> That’s where the misconception comes from as regards to LLM replacing completely developers I guess
The misconception also arises because Ai companies use the word thinking and everything else too which is what the general population says and then this just gets caught on by Engineers too.
When we say reason/think/etc. all the hype created by AI definitely gets a boost imo.
Do we say these for a lack of a better term or was it intentional that we say reason/think?
First of all I just want to say, I completely agree with the main point of this post, and argue for more full-lifecycle discussions on a regular basis at every job I've had.
With that said, I partially disagree this block:
> When I’m heads-down-coding, I’m not seeing, I’m not asking, and I’m not learning about the problem. To do that, I have to get up from my desk, go to where the problem is and/or the people I need to ask are, and have a conversation.
There are two types of problems when developing software. The problem of figuring out what you want to do, and the problem of figuring out how to do it.
These often impact each other, either because a limitation on what you can do changes what you end up trying to do, or because you learn something new about the use case, like this post describes. But keeping these two problems separated in your mind, at least for a time, is what lets us focus and find solutions.
>I’ve seen so many times how 10 lines of code can end up being worth £millions, and 10,000 ends up being worthless.
I don't care how easy it is, I'm not fixing something worth millions when I won't see a penny of that. It's on the business to double check their shit.
Oh, that must be fun to be hired by the client directly... I wish each my programming job was not an ivory tower :(
I think the ivory towers because managers mostly manage by how much of the plan can we ship. It is too radical to have developers take time from that to talk to customers which is a shame for the developer, customer and business.
This is one reason I always roll my eyes when people talk about how vim keyboard bindings are so great because you don't have to move your fingers from the home row. The actual action of typing text is a small part of the process of coding.
Vim recognises that the typing text is a small part of coding by defaulting to a mode in which you can’t even type :)
For me, vim is a nice way to navigate code. It’s really fast to jump from place to place so I can explore quickly and build an understanding.
Is anybody claiming it makes you more productive at writing code? I just find it more convenient and more comfortable.
Theoretically, isn't the fact that you are being more convenient and more comfortable likely to increase your productivity too?
Depends on how you work I guess. I explore solutions through coding different versions of some algorithm, sure I could theorycraft as well but I am stronger by just writing code and see if it runs. I type a lot so vim motions help me a ton.
Just because it is small doesn't mean that it isn't important.
Roll your eyes if you want. A professional takes tools seriously, that includes key bindings and shortcuts.
Yes, it's not the time it takes to type that's the matter, but once you're in the zone you need to stay there without any resistance.
This.
For me, navigating with shortcuts feels like I can keep my inner monologue, it is part of it, maybe because I can spell it?
Dunno, but reaching for the mouse and navigating around breaks that, even if it can be more convenient for some actions.
I agree. Vim is my default text editor, but it's not great as an IDE. Don't have much of a choice there either, and have to use the right tool for the job.
Writing code, notes, diagrams and now also AI prompts is certainly a big part of my work
One way hand coding is productive is it gives you detailed intimate knowledge of the code. We’ve all seen someone that really knows a system hear about a bug and say “Aha!” and take 5 minutes to pump out a fix.
A well setup Claude Code, with good guardrails and feedback, could possibly do this (we’ve seen examples of it for sure). But it also might loop idiotically not finding the issue.
Can you link to any examples of Claude quickly debugging a codebase it didn't write using a nontechnical description of a bug from a real user?
All the time i do it. I will often provide claude with read only credentials to the db or api access to the logs and it will nail the problem almost every time
I closed six bugs last week doing precisely this. They were minor issues but impressive nonetheless.
Some codebase are a logical mess and have bad names as well. Sometimes Claude is wrong because the semantics of our legacy codebase doesn’t makes sense. Sometimes it find problems at the wrong places because of that.
Coding is the result of intense productivity... or was. Hm.
this is resonate with me
I feel one upshot of AI coding is that people finally recognize 5 layer enterprise architectures for what they are - useless slop whose purpose is to make solutions more 'professional' and complicated to make the people who write them feel smart, inflate costs and personnel needs and sell consulting on how to solve problems with 5x more code than necessary.
The extra code doesn't encode any requirement.
On the other hand, these couple-hundred line, crappy spitballed together solutions that actually still do what is needed (and are usually are hand-written, LLMs aren't known for brevity) are vindicated.
There are lot of useless, self-serving abstractions out there (looking at you, Spring and Angular)
There is also a lot of useful abstraction that ensures you can more easily understand the system - and that sneaks in orthogonal features such as monitoring and robust error handling, that managers aren't happy to allocate much time for but that prove their worth once the system is actually running.
It's possible, LLMs now offer a different way to solve the same problem, because the cost of adding those orthogonal features now approaches zero jueas quickly as working on the rest of the code. ("Add logging, please"). So it is possible that a lot of frameworks that did provide real value in the past will become obsolete with LLMs.
On the other hand, if you look at stuff like Gas Town, then it's clear people will still revel into inventing crazy architectures full of arcane terminology, independent of how much it's actually needed.
So the only anecdote you could find from your long career is one example at the start of your contracting? What the hell with all those low quality shite talking about code this, code that?
> Founder of Codemanship Ltd and code craft coach and trainer
Ooh, it’s all coming together.