I've been programming for 30 years and "Code was never the hard part" does not offend me. It's something i've been saying for a long time. You can teach anyone the mechanics of coding well in like 6 months.

Programming is the hard part! I want to make this distinction because to me programming is about solving problems and coding is a way to express the solution.

Designing algorithms, architectures, etc can be done without a programming language. Coding is putting it down into some language.

I like Dave Farley's classification of Coders, Developers and Software Engineers.

https://www.youtube.com/watch?v=fcjBfSiyI0k

Sometime in the past 10-20 years there was a prestige shift where people started using the term "developer" for what you're describing as "programmer", relegating "programmer" to what you're describing as "coder", and "coder" to "hobbyist programmer/developer" (while weirdly "coding" remained colloquially the thing programmers do).

Advice to job seekers I remember in the 2010s was to not call yourself a programmer because that was where the bad "code monkey" jobs were, but it hadn't yet been much of a thing when I first started looking at the end of the 2000s.

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

You can absolutely not do this

I've also been doing this professionally for about 30 years, plus another 10 as a hobby/learning before then, so I think I have much of the same experience as you, and I do agree. Although, I think with the advent of LLMs, programming is no longer the hard part. The hard part of programming is the convergence of context management for humans while also presenting it to a computer to do something. Much of data structures and algorithms "best practices" are ways to efficiently get your work done as well as keeping it so that a human has context.

For example, one guy I used to work with wrote this really awesome algorithm about 25 years ago, and I'm responsible for maintaining it since he long retired. I can't go into details, but this is the core algorithm in moving billions of dollars between institutions overnight. It's about 10 screenfuls of c that had been converted from the original FORTRAN 77 with dozens of gotos and weird branching statements and about 20 parallel arrays that store indices for pointer chasing. It's almost impossible for a human to follow (I've actually fed it to an LLM and said rewrite this with for loops and no gotos so I can understand it - and it worked!) but it's blindingly fast. The actual problem it solves can be stated in about three sentences, but programming it was hard because of the context management. The reason that my company keeps getting royalties on this is that it's so hard that they'd rather pay us than write it themselves. But I bet an LLM could write it from scratch now.

So maybe programming is no longer the hard part, or at least context management is no longer the hard part and that humans should move up the chain to help manage the context for LLMs so they can get more done efficiently.

Switching topics a little...much of what I think makes coding the hard part was the tension between big-design-up-front and you're-not-going-to-need-it philosophies. Early in my career I worked in health care and that was BDUF and the coding was easy because program managers spent years defining every screen that would be shown to the users, what queries were needed to fill the screen, all of that. We just took the spec and coded it. Coding was easy. But the failure of BDUF was that it still didn't really match what the customer wanted.

Then enter agile and YAGNI, in that limit, coding is easy, just write what the user story says. But then you have to refactor from what was left behind on yesterday's user story. So smart engineers would cheat a little with YAGNI and say, yes we will put an abstraction in because the next user story. I would say that "good engineers" or "good coders" found that balance in abstraction to move fast but make abstractions not overkill. And I think that's what all the wailing and gnashing of teeth is right now: the good engineers aren't needed anymore.

I can tell an LLM to code something, and as I add complexity it's happy to refactor and manage the context so we don't need to worry about "clean code" or "quality code". As long as what the LLM writes meets the spec, then we're happy.

Ah, sorry long rant and ramble. But I just think the "hard part" has been managing context, and the context we're managing context is just changing. Those good at managing context will be good at coding with LLMs, and those that weren't won't be.

the article means code as a whole not just the moment you input some if else in a screen but the whole act from thinking about it to make it live in prod.

I don't even sit in front of a computer to write programs, I do that in the car.

I type them in when I'm in front of the computer.

All the actual work though? That gets done in a space where there's no phone, no people walking up and talking to me, no distracting social media, no screens, just quiet-ish and a couple of hours to think.