A craft can be extremely hard while useful output from it is relatively easy to obtain. Case in point, I used to be a very serious baker. I mean, very serious. It started when I was a child. I made sure I understood things at a molecular level, cared about first principles, redid techniques thousands of times, spent hours on the craft in every axis imaginable. And yet people who baked ten times a year sometimes made better cookies than I did. A friend once made a better carrot cake than mine because she didn't waste time trying to figure out how to "bring depth to carrots." and the many ways of modifying textures. She just picked a very good recipe and had the tastebuds to know it's good enough to make for people.

That didn't mean she understood baking better than I did. If something went wrong, I usually knew why and what to do about it. If someone gave me direction and wild requests, I could get us there, meanwhile she could not. If things didn't work out, her solution was more likely to be "find another recipe"... and finally, the part that "validates" the ego of bakers, if you looked at everything we both made, I'm sure mine was better on average.

BUT... if what people actually value is "who made a great carrot cake tonight?", then yes, baking is easy. All she had to do was find a recipe detailed enough for her and apply it without majorly messing up.

I think that's what the "coding was never the hard part" argument is getting at. The fact that programming has difficulty that people spend decades mastering it, or that the best programmers can do things ordinary programmers cannot does not tell you how much of that depth is actually required to produce the software people value. Which is, tbh, very little.

Anyway, I could spread this analogy further but this is long as it is so I will stop here. It just reminded me of when people accused me of "just knowing how to pick a good recipe" as a way of reducing my development efforts, and it made me laugh.

Agreed.

"Code was never the hard part" is the dumbest thing I've ever heard.

Making something work, has always been easier than making something someone can read. AIs also, seem to benefit from clean abstractions, appropriate code reuse, etc. (coincidentally, the thing they suck most at).

It's the same thing with english, except that english doesn't have a compiler. Comprehension is the only measure of communication if you're talking about a human language. Programming shares the same goal. Both, often also need to do something else useful. Programming, and lawyering, have a lot more in common than people think.

We're creating a culture of sh*tting on codebases so the highest paid execs can cash out when things get tough. It isn't a new phenomenon, but it's one we'll need to endure until enough people lose enough money that the accountants start taking notice and start saying "you should be more careful, or you'll lose your shirt". In the interim, the people that care are working insane hours to try to protect the things they believe in from inevitable doom, and risking being fired to do it. There is a balance to both sides, and the jury is out on whether or not anthropic/openai/alibaba can save us from the future we are creating now with short-term goals.

I always said programming is 80% thinking and only 20% coding.

nothing has changed since then.

interestingly ai has reignited the craft of performance and efficiency in programming. overall in the macro timeline i think the profession is going to be in a better place

Business has detested IT forever. It is basically considered blue collar work they felt held hostage to as it was 'brain' based instead of 'muscle' based, and it threathened to expose the grift of clueless "management" (not all is). They yried to placate with CTO, and l created tech diluted CIO and CISO titles for themselves, but the fear and loathing is as strong as ever.

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.

coding was never the hard part...until today

> I don't mean to imply there are no developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder, tho.

This is a specific attitude I try to beat out of juniors. You will not be dismissive of the point of this exercise.

The real insult… “That’s a five minute change”

An excellent read. However, this part is wrong:

> Those decades spent fighting memory bugs in C or C++, with the scars to prove it, are worthless.

The world runs on C and C++, with billions of lines of code. That code isn't going away. And with AI, maintaining, debugging, and updating it is becoming much easier.