> "Code was never the hard part"

It always comes out of the mouth of no-coders, vibe-coders and people who misunderstood coding.

"If coding is easy, how come programmers were in high demand, and have demanded large salaries for years"

It's like saying 'Lawyers write documents!' for their job ... no, that's just an artifact.

Architecture, Systems, State, Integration, Algorithms, Pipelines, Platforms, Ops, Design, Communicating with other Eng, Working on a Team, Understanding Product/Product Marketing Requirements ... and of which the 'code' is just a small bit of the written part.

Honestly ...

Code still is the hard part. Or at least one of them.

Code, is written in a language. Language is opinionated. Things written in that language are also opinionated. LLMs often have horrible opinions.

There is a half truth to code being the easier part.

In order to reduce the complexity of eventually coding something, you use modeling and code probes to validate the business model and then write the code.

This has been around since the days of batch programming and evolved through domain driven design principles.

The reality is the business can’t see that so they don’t invest in it and have no patience for it.

Agile wasn’t embraced because it was better. It was embraced because it was cheaper and faster.

Planning and modeling are the levers of complexity.

The things mentioned in the post aren’t code. That’s why code isn’t the hard part. Writing the algorithm to x y or z isn’t the hard part. Knowing that the algorithm is needed, it’s beneficial, there’s no alternative and the optimization isn’t in vein, that’s the hard part.

Structure, design patterns, software architecture, systems engineering, optimization (not of the LoC but the system), data accessibility (in structure as in implementation like indexes etc)... those are the hard ones that require engineers to design and implement properly.

And that’s only going to be more as it’s not the 20 medior SWEs that throw together a full stack application in two days but the untangling of AI slop as the architecture wasn’t built for hundreds of concurrent users

> Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book?

I still read TAOCP occasionally as a hobby. The combinatorial algorithms and data structures are just fascinating. That said, this argument seems irrelevant to majority of the programming jobs. I doubt most engineers will ever need to implement anything mentioned in TAOCP, thanks for all kinds of powerful abstractions.

Maybe "Code was never the hardest part" is more accurate. Code can be hard, though as others have said, 90% of code out there is crud apps plus forms. The other really hard part of getting people to do any complex work together.

Ive been doing this for enough time. Code is rarely the hard part. Code rarely matters at all in my career experience.

Shipping a working service or product matters and theres a lot of ways you can get there. The upside of good code is usually in maintenance and extensibility but theres a limit to how much those matter in the grand scheme.

Coding something for the second time is much easier. Therefore, coding is easier than some other tasks in software engineering. Getting the spec is usually the harder part, except if following the spec is for really complicated products, like "one does not simply rewrite VIM" shows.

I've always taken it to mean "coding is the easiest part of a developer's job"

That doesn't make it inherently easy, but it is the easiest part to automate.

A modern LLM is perfectly capable of maintaining decent code quality and architecture (provided you ask for it) up to a few thousand lines of code, but after that it very quickly loses the plot if you're not designing your documentation right and keeping a hand on the architectural tiller.

Architecture is about staving off chaos for as long as possible given the maximum functionality you expect it to achieve. That's hard enough for a human, with a deep understanding of your business, to do. Architectures that endure is a hard problem, dwarfing the difficulty of writing the actual code. Choosing what product to build is also a hard problem if you expect to meet any success. What it does, what it specifically doesn't do. Sounds easy on paper, and if all you're doing is Sunday prototypes it feels almost trivial. But once you're doing a real product with real consumers, it's a very different thing.