There have been non-coding software architects for decades before LLMs became a thing. Most of us more experienced people are not in architect positions mainly because there are way fewer of those available. That’s changing now.
What we lose when we stop coding
Submitted 18 hours ago by codeinabox@programming.dev to programming@programming.dev
https://newsletter.humanwhocodes.com/posts/what-we-lose-when-we-stop-coding
Comments
abc@suppo.fi 18 hours ago
marcos@lemmy.world 17 hours ago
Non-coding architects has been a well known organizational red-flag for decades.
Non-coding people always lose track of reality, and it’s a disaster to give them decision power over fine-grained technical choices.
Now, I don’t really know how that maps into non-coding software developers, but I’m not optimist.
kibiz0r@midwest.social 10 hours ago
It’s a matter of feedback loops.
It’s the same problem as when you divide teams by front-end/back-end, or implementation vs testing, or features vs platforming.
When you don’t have to feel the pain of your decisions, you’re going to make bad decisions.
towerful@programming.dev 17 hours ago
As a solo dev, Claude has moved me from a “code writing developer” to a “system making developer”.
Someone would come to me with a problem, I’d chew it over come up with a plan and execute it to the best of my ability. And I loved writing the code, solving the problems, learning new stuff, and ultimately seeing something I built get used and make other people’s lives/jobs/whatever better.
But many times I would come to the conclusion that it’s beyond my skillset (or I could do it, but the sheer quantity of learning would mean I don’t hit the deadline or that I wouldn’t be confident in the result) and not take on the work - despite understanding the problem they want to solve.
Now, someone comes to me with a problem and I either say “yeh, I can solve that. But let me dig into it a little first”, or I say “I don’t understand that enough to be able to design a solution for that”.
It’s no longer beyond my skillset. I have to understand the problem presented, I have to understand what the users want, and I have to understand what the result is. From this, I can know what the code/architecture/frameworks/stack will probably look like.
That’s the first step of solving a programming problem.
I don’t necessarily have to know/learn exactly how to achieve it.
It feels like I’ve gone from solo-dev to manager.
Thankfully, I guess, I’ve done full-stack, k8s, native app development. So I have experience.
Which brings me to my point:
I’ve had this exact scenario.
Then I point Claude to the docs, and then it “knows” how to solve the problem.
I point Claude at the docs because I know the specific software can solve a part of my problem, because I have evaluated previously that it can.
I don’t necessarily know exactly what I’m looking for, or what exactly the answer is. I don’t necessarily know the keywords to be able to find it on DDG.
But Claude could probably suggest something, and I’ll know what I’m looking for when I see it.
I’ve even had Claude build it’s own docs from a GitHub repo of docs because the actual API docs are trash (looking at you Vimeo).
LLMs aren’t smart. They are expensive to run. And they take a LOT of the fun and knowledge out of programming & development.
But they are a tool.