“Code was never the hard part” is an insult to all programmers

"wear additional, invisible hats "

No ... those are not invisible hats ... those are the real hats.

Software is 'Knowledge Distillation' the code is the hieroglyphic artifacts.

Engineers Engineer, Scribes Scribe.

Just so happens developers do their own scribing.

> You can teach anyone the mechanics of coding well in like 6 months.

You can absolutely not do this

Getting everyone to understand the problems, working together, etc, etc are issues that are inherent to organisations.

They’re orthogonal to AI and to the actual hard technical skills needed to execute on a specific strategy. And if the technical skills are lacking, it doesn’t even matter how good an organisation is at collaboration, whereas hard skills plus organisational disfunction are a known successful pattern :)

Many people did look at this through an individual lens and claimed that design skills, domain knowledge are the truly important abilities. I remember reading on HN at least a couple of popular articles claiming that. Actually, they’re all important and having great design skills without matching coding skills is IMO not really possible. The code feeds into the design, the requirements, the architecture and shapes them.

It’s not that coding is easy, it’s more that coding was not the bottleneck in the process at large organizations. It was (and still is) getting agreement on what to build, meeting with stakeholders, and dealing with the ever-changing priorities.

A lot of people enjoy coding, it’s the rest of the job they don’t like. That’s why it feels hard.

If a tool was going to come along and automate away a huge part of a programmer’s job, I think most would want that tool to eliminate the meetings, ambiguity, scope creep, and administrative work… not the coding itself.

My best days at work were days with nothing on my calendar, when I could just put on some headphones and make something. At the end of the day I felt like I accomplished something and had something I could see and use to show for it; I finished the day happy and energized. Contrast that with a day full of meetings, fire drills, and busy work, where at the end of the day I’m mentally and emotionally drained, wondering if I should quit to stock shelves at the local grocery store. Which day sounds “harder”?

I don’t know about where everyone else works, but defining the details of what to build seems so hard that no one actually does it, so it falls on us as we build things. During one project I got a directive from the CIO (which has only happened 1 time in 20 years) to get what I was working on done in 4 weeks. I made all the decisions myself when it came to the details and had something mostly working in 2 weeks (I skipped all meetings and any other distractions during this time). Several months later, the bureaucracy came into play. The principal architect on the project, who I never talked to before the CIO told me to get it done, finished his design and some details needed to be worked out. One such detail was a port list. It took 4+ months of meetings to get that done, and it still required constant tweaking after that for another year. There was a half dozen other things like that in the same project. So yeah, the initial code was pretty quick and fun to write, and then it was followed by 2-3 years of hell, that probably should have been worked out before we started coding. I ended up having to go back and re-write a bunch of stuff to align with the design that was decided on over a year after the deadline the CIO gave me. In most cases, I think the updated code is worse, as the bureaucratic design creates a lot of operational work that my original design avoided entirely, but I digress.

Most useful software engineering work is doing fairly simple things and the numbers of people doing this work reflects that.

> those of us who have had to solve open problems with no solution written somewhere because there is none.

Probably because solving said 'truly hard problem' is niche with little or limited value as few people have tried to solve it (otherwise a solutions will likely have been written).