Why 'coding is the easy part' misreads what programmers actually do

A working developer pushes back hard on the fashionable claim that LLMs have exposed coding as trivial and that the real difficulty was always figuring out what to build. If writing software were genuinely easy, the author asks, why did it command high salaries and grueling interviews long before ZIRP, why do entire canonical texts and degree programs exist to teach it, and why is shipped software still so buggy? And if requirements-gathering were the truly hard skill, product managers and business analysts would be the ones getting paid the most and grilled in ten-round interviews — which is plainly not how the industry operates.

The piece also skewers the mirror-image cope that code is untouchable human art. It argues there is no clean archetype of a developer who both obsesses over monads, memory safety, and theory-building while genuinely empathizing with customers through more than a fabricated user persona; most engineers lean strongly one way. The honest position, the author contends, is ‘why not both’ — deep craft in the system plus a real grasp of why it’s being built — rather than sloganeering from either camp while an industry-wide shift plays out.

The closing advice is practical about what endures versus what churns. Software will keep accreting complexity, needing maintenance, and outliving the tools it was written in (valgrind, mysql_real_escape_string, dBase), while users will always want more for less and never fully articulate their needs. To adapt, the author urges staying curious but skeptical of hype: seniors should learn adjacent disciplines like UX and customer research, and juniors should invest in fundamentals — pointers, recursion, memory hierarchy, network protocols, algorithms — that stay useful no matter how the AI tooling evolves.