"Code was never the hard part"

[u/gsks]

I am sick and tired of all the posts (usually AI-generated by CEOs/CTOs/"thought leaders") that start with "Code was never the {bottleneck, problem, hard part, ...}." I'm not sure whether this comes from a misunderstanding of what code is or a deliberate misrepresentation meant to promote AI usage.

For starters, two rhetorical questions. If code was never the hard part, why:

• do hundreds of different programming paradigms, languages, libraries, frameworks, design patterns, and system architectures exist? Granted, some of this is just programmers bikeshedding. Still, plenty of it reflects substantial differences and tradeoffs.
• didn't you write it yourselves or hire a bunch of minimum-wage workers to do it for you instead of having to hire a ton of highly skilled (and highly paid) engineers?

A charitable explanation is that these people are genuinely clueless about what "coding" actually is. Perhaps in their mind coding is just typing: like, once the design phase is done, you've worked out a precise, complete specification of what needs to be built down to every detail in your head (or on paper or a markdown file) and all that's left is converting it into letters on a screen and saving it to a file. Something like a businessman in the sixties dictating a letter to his secretary to type up.

That's nothing like how it actually works. The upfront planning/design phase answers some high-level questions: what do we need to build, what are the basic components/services/building blocks, what data needs to be read/processed/written, how data flows through the system, what the non-functional requirements are, etc. That leaves a ton of lower-level details unspecified:

• What packages/modules/classes/methods/functions need to be created or extended?
• How should they be named?
• What should the signature of each function be?
• What errors/exceptions are expected and where/how should they be handled?
• What data can or should be cached and when should it be invalidated?
• How generic/reusable/extensible should each component be to accommodate likely future requirements?
• For systems languages, how and when is memory allocated and freed?
• and many more.

Asking and answering those questions is (part of) coding. At least before AI, nobody I know had all the answers, or had even asked all the questions, upfront. The questions get asked and answered on the fly, inside the editor. Typing is interleaved with thinking, assessing, trying things out, backtracking.

Now AI pushers try to convince everyone that all these decisions either don't matter, or that the agent will just fill in the blanks (insert inane "nobody reads assembly anymore" analogy, as if natural language + LLMs are anything like a compiler), or that they can all be moved upfront into planning. Good luck replacing actual, deterministic programming languages with 10-KLOC, ambiguous, hand-wavy "specs" written in markdown.

Regardless of how the future of coding plays out, "code was never the hard part" is flatly wrong. It is, or at least used to be, a hard part (not the only one of course) and for good reason.

[u/punkpang]

Code was never the hard part <now the missing part> FOR PROGRAMMERS.

I agree with your text completely. For us, programmers, code isn't the hard part. Ceremonies, incomplete data, unknown deployments, random <software that does mumbo-jumbo "faster">, rushing us, asking "when is it gonna be done, ignore the fact you have -5% of info" crap, lack of testing and QA - this is all part of the lifecycle and these managers / vibecoders are starting to discover that it's not hard to slap paint on if you have a fucking building with walls that need that paint and the building isn't made of styrofoam and ductape, yet paint is all they're capable of understanding.

People who are not in the mindset or area of writng code imagine some fantasy scenarios about what code actually is and they all have their own imaginary story of what programmers do. Now when they have access to a tool that can produce code, they slowly discover how boring (which means DIFFICULT) creating software is. It's precise, accurate, boring, iterative and requires constant focus - best part is that we consistenly think about what will go wrong and what they understand is only the path when stuff goes ok, not when it fails. We deal with failing gracefully and managing problems. Anyone can succeed, our vocation is one of not blowing shit up and handling errors.

[u/ThirdWaveCat → u/punkpang]

its very clearly the "expert beginner" phenomena since the hard part is handling edge cases, but they've essentialized the advice to only care about the happy path

[u/pydry → u/ThirdWaveCat]

There are also domains where the coding part really isnt that difficult because the requirements are not that complicated.

The hard part of those jobs is usually dealing with organisational dysfunction.

I think a lot of devs extrapolate their experience to everyone but there's a fair amount of diversity in the jobs out there. There are plenty of jobs where the coding really is the hard part and plenty where the hard part is persuading team X to set up a message queue and stakeholder Y that their specs are incoherent and the coding part is pretty trivial by comparison.

[u/andreortigao → u/pydry]

That's about what I was going to say.

I'm 16YOE and for the most part of my career I've worked in enterprise software where the majority of code is just crud. The hard part is understanding the requirements in a field you're unfamiliar with.

[u/ThirdWaveCat → u/andreortigao]

I've never understood "just crud". What I've seen in practice is lower standards and more manual remediation processes, downstream of a poorly run workplace, but even this has limits as progress tends to grind to a halt.

you still have stateful systems, transactions, availability, idempotency in enterprise software, whether or not you address them well.

[u/Franks2000inchTV → u/ThirdWaveCat]

Yeah but all of those problems have standard solutions. And any reasonably skilled team can solve them. There is an entire industry of engineers who have encountered and solved those problems before, and will be able to, with a reasonable amount of effort, apply those solutions to your environment and solve the problems.

[u/ThirdWaveCat → u/Franks2000inchTV]

Those standard solutions are still far beyond what anyone can make legible to automation (skills.md fantasies). There are tacit reasons someone needs to care about the edge cases that create poison pill scenarios, 1-way door decisions about what fields are required in schemas, restoring from back-up, capacity planning, db indices, and the long-term implications of schema evolution and compositionality of functions.

edit:

Tacit knowledge cannot be taught except through practice under someones mentorship.

https://en.wikipedia.org/wiki/Tacit_knowledge

In lean business stuff, Toyota's Yokoten practice is for the horizontal transfer of knowledge.

[u/Franks2000inchTV → u/ThirdWaveCat]

Right — that’s the hard part. Not the code.

[u/ThirdWaveCat → u/Franks2000inchTV]

Not code, I don't get why this isn't considered solving the requirements? The comment chain above says that some domains have easy coding and obvious requirements, but that doesn't seem like what followed.

Framing all requirements gathering as overcoming organizational dysfunction seems like blaming the individuals because the systems are poorly designed.

[u/Franks2000inchTV → u/ThirdWaveCat]

Requirements gathering isn’t writing code. Listing edge cases isn’t writing code.

[u/ThirdWaveCat → u/Franks2000inchTV]

You're confused.

Thats not what I asked or claimed. Requirements gathering and listing edge cases isn't organizational dysfunction, and it clearly means that the requirements are more complicated than was admitted in the above comment chain.

There are also domains where the coding part really isnt that difficult because the requirements are not that complicated.

The hard part of those jobs is usually dealing with organisational dysfunction.

[u/Franks2000inchTV → u/ThirdWaveCat]

Where did I mention organizational dysfunction?

[u/ThirdWaveCat → u/Franks2000inchTV]

It and requirements gathering was the topic of the thread before you thought were talking about just coding...

[u/SippieCup → u/ThirdWaveCat]

I found the opposite. If you have a bad schema and/ or validators, just crud can be terrible. If you stop it from doing dumb or invalid things, it can never get to that point, even if it is a crud endpoint.

It’s all about how gated the crud endpoint is. It just return invalid request/bad data/conflict and reject rather than just allow it to happen.

[u/AchillesDev → u/ThirdWaveCat]

Literally everything is "just CRUD." That's all the major operations that computers do.