Isn't an insult really, just an argument about terms.

"Code was never the hard part" in my opinion is more about the actual writing and making it compile and fit together. The hard part is one level above: figuring what to write, not only on the architectural level, but also implicitly during the writing itself. LLMs tackle a part of it, but not the whole problem, thus "the code was never the hard part" is about "how to make the already-present plan compile", not "knowing the system underneath is not hard actually"

compare with something automotive: the process for changing an intake gasket and installing a turbo is roughly the same, but if you screw up the compression on your engine in the second case, you ruin everything - saying "installing was never the hard part" means that installation is the final step, however someone still might be upset, because he or she implicitly thinks "installing" means more than just the physical process of bolting the intake on.

Is it an insult to all mechanics to say that "installing stuff was never the hard part"? No, because context here naturally points to a narrow definition which excludes cases requiring engineering, i.e. adding a part in a tight space, drilling the block to make a new auxilliary installed, machining a bracket etc

Nope, only those without a degree that cannot do anything else, e.g. the bricklayers on a building.

Real engineering has always been about talking with the multiple parties, organising architecture meetings, taking down requirements, if no infra team available setup the whole CI/CD pipeline, and so on.

Programming could be done in whatever language, or low code/no code tool, solved the business problem.

Now what will remain to humans is a big question.

I think computer code is largely misunderstood by people as 'Python' and 'Javascript' because unlike some of us here, not everyone had to decide 'which language should we build this in?' I remember an year ago I was building a Version Control Database and i had to carefully opt out of python, Java etc. to choose Go due to dynamic concurrency control. Programming is not limited to building an "AI website" and believing 'Coding is the easy part', once you go beneath the iceberg and understand how Assembly interacts with different languages, what makes C faster than C++, how raw vector operations are more efficient that loop operations, then only a person understands the significance of this statement.

This is more of a rant from my side, but I believe "Coding is the easy part, Programming and Designing an efficient system" is where true grasp of Programming is checked.

If writing code is hard, how is it possible that so many kids learn it in a few months? I learned to program in basic at 9 with literally 2 books (no web back then), at 12 I was coding little programs in turbo Pascal, learnt with just the manual (it was a very good manual). I was not a genius. Granted it gets a certain type of mind to want to learn programming, but it’s far easier to learn than the pedestals it sits on (writing, reading, some maths and planning logic). Also code itself demands very few cultural background to start, hence why we have teenage dev genius but no teenage historian genius

The truth of that statement depends on what you consider as "coding".

The way I would define it, coding is to software development as cutting is to open heart surgery. It is the final part of the process after 99% of the decision making and application of experience has already been done. There is still some craft or "surgical technique" to it, but the hard part was surely everything that came before (requirements, architecture, design, etc, etc) that got you to the point where all you had left was a bunch of classes and fully specced out modules (and implied test cases) to code up.

I feel that some people, maybe including a lot of the people working at the AI companies, think that the software development job mostly consists of "coding", and perhaps in machine learning (not much code in an LLM!) it mostly does, but if you are a developer and define coding as the final "sit down and implement it" phase, then surely that is the easy part.

I don't think I've heard a lot of people say "code was never the hard part". I have heard "Code was never the bottleneck", which is a different thing altogether and is objectively true at my company. The bottlenecks were and still are integrations, QA, requirements refinement, coordination, etc.

what is -coding-? only typing down some code? the hard part is always the design part, reading doc, reading other code, understanding the sum of the parts, making choices, until the code to write is (quite) -obvious-.

Probably is a question of terms: there is two things: -design- and -coding- (but could be anything as: building, drilling, turning, traveling..) so to make things without a good design is the regal way to problems, many times is a problem left by others, and in a world more and more complex and fast-changing can only be more and more worst. Hard to say what part is really the hardest, but starting with a bad design is no good.

And now probably LLM will solve some problems, but for sure these tech will create more and more new ones.

https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf

By saying coding is the hard part, you're insulting all engineers.

Edit: Although the current job market is heavily distorted, there used to be distinction b/w developer and engineer in the past. As the mainstream development model shifts from waterfall to iterative models, it became necessary for everyone to be engineering-capable -- only up to a certain point. So, every developer now carries a certain amount of engineering knowledge, but now they started to misunderstand and underestimate the value of engineering, and this is what you would get at the very end.

I truly believe that software industry in at the crossroads and need to adopt the best solutions for the quagmire it's in at the very moment and so called AI/LLM revolution mentioned in the OP article is only the tip of the iceberg problems [1].

Currently I'm reading the Software Wasteland and The Data-Centric Revolution books by software industry veteran Dave McComb [2],[3].

The books also addressed AI aspects but since it's published around 2018 before LLM, the information probably a bit dated on the issues. Hopefully the third book sequel in the trilogy can cover that aspect very well.

Some key takeaways from [2].

1) Almost all Enterprise Information Systems now cost vastly more to implement than they should

2) Most of the excess cost can be attributed to complexity

3) When you have hundreds or thousands of complex applications, you are completely stuck in what we call the Application Centric Quagmire

4) More large firms spend most of their IT budget on integration (without achieving more than ad hoc interfaces)

5) The fix is to become truly data-centric, where an integrated core model precedes the addition of functionality

References:

[1] A Tale of Two Projects:

https://www.semanticarts.com/a-tale-of-two-projects-healthca...

[2] Q&A on the Book Software Wasteland:

https://www.infoq.com/articles/book-review-software-wastelan...

[3] Software Wasteland and The Data-Centric Revolution:

https://technicspub.com/software_wasteland/

> If deciding what to build is the hard part, why do so many product managers seem clueless?

I'm not sure I follow the logic here. Wouldn't this mean that product design is hard?

That said, yeah, coding is hard. I suspect that those who claim that coding is not hard are high-level ICs. For better or for worse, as the size of a company grows and as one's career progresses, engineers will often tranform to professional box drawers, expert meeting goers, seasoned report writers, fierce gatekeepers...Anything but deep coders. Over time, they lose touch of the actual building and think that any code can be handled by people under them.

People like Jeff Dean, who still codes and optimizes things like TPU kernel code, is very rare.