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
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.
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.
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.
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".
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.
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.
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.
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?
17 comments
[ 3.1 ms ] story [ 45.3 ms ] thread(Manager pushes paper, pen and a list of problems in front of you and demands, “Now write, just write! And fast!”)
> Founder of Codemanship Ltd and code craft coach and trainer
Ooh, it’s all coming together.
Personally, I think, much of the art of programming is to do as much as possible with as few lines of code as possible.
Never seen that happen. Do not know anyone who experienced this. Where and who are those managers?
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.
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".
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.
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.
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 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.
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?