Coding is when we're least productive
codemanship.wordpress.com
codemanship.wordpress.com
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.
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.
(Manager pushes paper, pen and a list of problems in front of you and demands, “Now write, just write! And fast!”)
And if you find yourself going in circles while you're typing in code, you probably didn't complete the plan phase.
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 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?
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?
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.
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?
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.
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.
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.
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.
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.
> Founder of Codemanship Ltd and code craft coach and trainer
Ooh, it’s all coming together.