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".
You also don’t often learn why you don’t need a chair while building one.
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.
In software, this kind of construction scarcity does not exist. Once you design a chair, you can instantiate it to your heart’s content.
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.
(Manager pushes paper, pen and a list of problems in front of you and demands, “Now write, just write! And fast!”)
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.
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?
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.
> Founder of Codemanship Ltd and code craft coach and trainer
Ooh, it’s all coming together.
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 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.
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?
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.
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.