This to me seems to be a very odd interpretation of the phrase “coding was never the hard part”. First, that doesn’t mean that it’s not hard, just not the hardest. Second, and more importantly, they jump to deciding what to build being the hard part as if those are the only two things?

I have used a variation of this phrase (I usually say coding was never the bottleneck at work) but I’ve never even considered deciding what to build as to be what the bottleneck is.

First, I should say by coding I mean taking a concrete design for a change and writing a single pass at implementation. Modern models to this extremely quickly with up to good performance depending on exactly what you ask them to do.

The things that take up more time in software development just for engineers, leaving aside things that design and pms do.

• Coming up with that concrete design for a change (humans may do this in many ways, one of which is writing the code without a plan and refining)
• Architecting the system at all levels. This one is continuous and huge. A good architecture will easily adopt changes as they come, but you can never foresee all possibilities, and even if you could, there’s usually other people around you who can’t, which brings me to
• Communicating the system design and coming to consensus about aspects of it. This is mostly applicable to teams and is the primary reason individuals can often outperform entire teams. It’s also one reason why throwing a second LLMs at a problem doesn’t solve it at twice the rate. You’ll never get linear scaling
• Upkeep tasks: what needs to be replaced and fixed now, how do we best monitor and alarm to figure this out in the future.

There are “what to build” aspects in here and many engineers also spend time on the overall what to build questions, but the way the article was talking about it seemed very high level.

Coding isn’t easy, it’s hard. But it’s also not usually the bottleneck in software development.

I read "Code was never the hard part" as "Writing the Code down is easier than the stuff you do before it (like Architecture, Design Patterns, Requirements) and after it (Testing, Troubleshooting, Refactoring, etc)".

This to me seems to be a very odd interpretation of the phrase “coding was never the hard part”. First, that doesn’t mean that it’s not hard, just not the hardest. Second, and more importantly, they jump to deciding what to build being the hard part as if those are the only two things?

I have used a variation of this phrase (I usually say coding was never the bottleneck at work) but I’ve never even considered deciding what to build as to be what the bottleneck is.

First, I should say by coding I mean taking a concrete design for a change and writing a single pass at implementation. Modern models to this extremely quickly with up to good performance depending on exactly what you ask them to do.

The things that take up more time in software development just for engineers, leaving aside things that design and pms do.

• Coming up with that concrete design for a change (humans may do this in many ways, one of which is writing the code without a plan and refining)
• Architecting the system at all levels. This one is continuous and huge. A good architecture will easily adopt changes as they come, but you can never foresee all possibilities, and even if you could, there’s usually other people around you who can’t, which brings me to
• Communicating the system design and coming to consensus about aspects of it. This is mostly applicable to teams and is the primary reason individuals can often outperform entire teams. It’s also one reason why throwing a second LLMs at a problem doesn’t solve it at twice the rate. You’ll never get linear scaling
• Upkeep tasks: what needs to be replaced and fixed now, how do we best monitor and alarm to figure this out in the future.

There are “what to build” aspects in here and many engineers also spend time on the overall what to build questions, but the way the article was talking about it seemed very high level.

Coding isn’t easy, it’s hard. But it’s also not usually the bottleneck in software development.

Typing the code isn't hard.

Figuring out what code to type is.

Coding is problem solving, and solving problems can be very hard depending on the problem you're trying to solve.

I appreciate the intent behind that sentence, and the problem is that is written (or said) by people who don't understand coding.

Syntax was never the hard part. Code syntax is a set of rules that you can teach a machine and it's "easy" enough for an LLM to grasp it. The problem here is that this phrase does a "code = syntax" but ignoring all the difficult things that actually are in the code. Architecture, design, tradeoffs, translation of vague requirements into concrete software components...

All of those things are terribly hard, and the reason why many LLM-first coding projects get abandoned at 70% and then companies need to hire a Software Development consultancy to mop up their mess.

Whoever you are, don't outsource your understanding, judgement, empathy and taste to AI. Don't abdicate your responsibility. Don't be a meat proxy.

By expanding the ability to program to people without the knowledge of how that code works in the first place, it's naive to expect that most uses of AI in programming will be informed uses by senior developers able to recognize errors and security flaws.

Such a pro-AI position also ignores the enormous amount of theft that these tools are built on.

Code is integral. Everything they add to it, and build around it, is to support the code. Code is the God in the machine.

How do we thrive?

Accept that change happens. Be equal parts curious and critical about the new stuff.

That is not the solution. One cannot thrive if one cannot be seen or has been discarded as a relic no matter how up to date that person is. They will never be granted the opportunity to thrive as they have before as an employee. Their only hope to thrive is if they (magically) gain all the skills and networks necessary to be an entrepreneur that can do it all themselves. Nearly a unicorn.

Meantime while trying, they burn through what savings they have on the hope and dream of "being relevant again" and have about a 5% chance of success.

Maybe the author is misunderstanding the gist of the original article. Regardless, he raises an obviously accurate assessment of those who hold the hiring power. When I was recently out of college learning my craft, it was a common sarcastic refrain of either, "What could be so hard about it, it's all 1's and 0's" or "What's taking so long - you're just typing on a keyboard".

This has been a problem since long before I graduated from college (when classifieds called for 10 years experience on an IBM system that was released two years ago) (see, things don't change so much - names and places, sure, but not much else). People who are in leadership positions, who think they're better and smarter than most everybody else, frequently belittle those who do the grunt work, both physical and mental. It's gotta be a corollary to dunning-kruger theory (or maybe an example of it).

Remember that story about the chalk mark engineer with Ford? Chalk mark 1$, knowing where to mark 1000$ ? Same with code. "Code" is easy. Knowing what to write, why and where, that's the hard part. LLMs have somehow managed to automate the code part, without the abstraction, at least in an error proof way. I don't think "coding isn't that hard" is insulting, and I don't use C++ because I think it's hard. But it's not because writing something is hard, it's because writing precisely what is needed is hard.

Anyway, this debate doesn't matter, negotiate better, be active politically to ban stuff or not, complaining on the internet won't do anyone any good. I know you're emotionally invested in this, just... breathe and do something else? Idk. Also I'm not your enemy on this, so no need to attack me.

Cooking is easy. That's not an insult to a chef.

"Code was never the hard part" is probably made up by someone who never had to program anything serious.

That try, the hard part is algorithmic and avoiding archictuctural traps and experience. Pissing code which didn't work or look like it work but don't is easy.

I won't miss writing code. In part because I still do when I feel like it, but also because most of the time it is extremely boring. A mere mean to a goal for which you probably have the path mapped out in your brain already. It is basically just busywork at that point.

There are these moments where you need to squeeze out performance, where you change something about the UI or generally visuals and get a pleasing result, or where you discover a small tweak that collapses a lot of complexity you originally planned for - but that is, in my humble experience, not the norm in programming. The vast majority of code is boilerplate or stuff you have already written a thousand times in some variation. The more experience you have the worse it gets.

I was ecstatic when I realized how good agents have gotten, realized how I could focus on design and architecture and with small corrections, get more than adequate software. Because for me personally, programming is the least fun part of software development. Most of the time that is. And you can hate it all you want, but programming is a skill worth nothing on its own now, and it will never be again. You can take solice in the fact that you can still do it for fun if you want to.

What OOP refers to is not "writing code" but "designing the code." Everyone can write a book. Even I can. It will be a fucking shitty book, because I don't know how to create suspense, give depth to characters, or any of that stuff. But it's still a book. Writing code is easy. Writing good code is hard. If you want a program to fetch the current outside temp from an API you could throw together random lines of code that vaguely does what you want that you found on stackoverflow and iterate until it works. Will it catch edge cases? No. Will it output in a pretty format? No. Will it be maintainable? No. Will it be the next Facebook? Hard no. But you did write code.

Writing code is easy. Writing good code is hard. And that is why we have door stoppers called "Clean Code" to help us on our way. You might notice that the "how to code" books aren't much thicker than a a pamphlet. But if it ever as much as touches on the topic of good code it will make for a door stopper worthy of a nuclear bunker's entrance.

If coding is easy...

Think of it like DJ'ing.

The rock bottom level of being a DJ is putting a playlist together and playing it. Anyone could do that, you've already probably done it on your phone. Maybe even grouped songs by genre or year if you're feeling fancy.

But a good DJ does more than that. They arrange the songs to give a particular vibe, they play around with the transitions to keep people in the music, they may even remix songs or their entire playlist on the fly. They're artists in their own right, making more than the sum of what went in.

... And that's the same as a programmer. Anyone can bumble their way through to writing code - but is that code anywhere close to optimal, properly annotated, maintainable?

GenAI throwing out thousands of lines of shitty code that has to be bug-fixed multiple times over by a developer is a waste of time, energy, computer parts, and money.

@codeinabox When I say some variation of "writing code is not the hard part," what I mean is this: I can get a 9 year old to write a program that compiles and runs. A literal child can achieve "writing code" within an hour. That specifically is my bar for "writing code" because, by definition, that's what's happening. However, it's obvious there's a vast difference between what a 9 year old can do in an hour and what a professional software engineer does with 20+ years of experience.

If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?

Because programmers seemed magical, mythical, able to create insane amount of value by typing a few words onto a screen. You will see this if you just go and look at how any other industries work. Even just using basic shortcuts puts you into like the top 1% of computer users, that’s how inefficient most people are at working.

Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs? Why did companies seek 10x ninja rockstar coders and subject them to leetcode interviews—surely, a junior fresh out of college could churn out something if it's so easy?

Because developers are asked to do more work than any other office job. The value you create as a developer is 10x what a product manager does. You can do a product manager’s job, they cannot do yours.

If coding is easy, why do we have doorstoppers like Clean Code and The Pragmatic Programmer?

Once again, because programmers are obsessed with efficiency and productivity. Having a book about something doesn’t mean jack though. There are books on how to walk better, that doesn’t mean walking is hard.

Why do we have bootcamps or even whole college degrees dedicated to it?

These are dumb questions, there are degrees for everything.

If coding is easy, why are people angry at AI (or anyone else) copying their code? Why do they act like they've poured their sweat, soul, and copious amounts of time into something so trivial?

People are angry that AI isn’t “following the rules” while simultaneously destroying the planet. People believe the bullshit that LLMs make up and then say “oh, your job was easy the whole time”. No, coding is easy. The rest of it wasn’t. Coding is meaningless without good architecture, good requirements, good UI/UX.

If coding is easy, why do many now feel like their identity and professional purpose are being stripped away from them?

… because the jobs are being taken away and distilled down into just “coding”. How is this hard to understand?

If coding is easy, why is software so damn buggy?

Because business doesn’t (didn’t) care about writing code, they cared about making money. Also the number of bugs has nothing to do with how easy something is. Walking is easy, that doesn’t mean you don’t ever roll your ankle.

If deciding what to build is the hard part, why do so many product managers seem clueless? Why aren't there rigorous 10-step interviews for them? Why aren't they getting paid more than the developers?

Yay! Good questions now! Yeah why do programmers have the only job where they’re quizzed over and over again? Huh, maybe it’s because every other industry thinks the hard part is coding (hence why this focus on coding)!

If deciding what to build is the hard part, why aren't market researchers, usability experts and—hell, customer success—considered rockstars in a software company?

The output of a programmer is directly visible, the output of pretty much every single other job in software development is not. What, are they going to start measuring how many tickets and meetings your scrum master makes?

If implementation is easy and finding demand is harder, why are programmers upset when the salespeople promise a new feature to a customer to close the sale? They've found a genuine demand, something people will pay for!

Who the fuck ever said implementation is easy. Coding is easy. That’s not implementation. The code has to fucking do something. That thing has to be tested. The sales person probably didn’t gather actual requirements before promising the feature, so whatever the customer thinks they’re getting is definitely not what they’re getting.

You can literally see that actual coding is easy when you understand the requirements by looking at tiny development companies that have made a single product where they give customers enormous power to choose new features. The new features come out incredibly quickly.

If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out?

Dumb question. It’s hard enough to sell one product, much less 10. Think about any normal software user finding out there are ten ways to do something. Even some programmers hate it, Python claims there’s only one right way to do any given thing.

Some software developers do say “I don't write code, I solve customer's problems”. But then they turn around and start to opine on monads, memory safety, and DRY principles, while their understanding of the customer is a made-up “user persona”, and they think “affordance” is the money your parents used to give you on weekends so you could go out and have a good time.

Yes, they like to talk about the fun part of the job, not the non-fun part. Big surprise. Also turns out they like to optimize that part to make it more and more fun, because it’s become too easy.

What is important?

You’ve switched the topic. It was about what is hard, not what is important.

But do recognize we're in the middle of an industry-wide tectonic change. We need to figure out how to adapt. We need to understand what is likely to change and what never changes.

No we don’t. This is like saying we need to learn how to adapt when every country has nukes and has started to bomb every country constantly. We need to stop bombing, not learn how to live with it.

Users will always want more and be prepared to spend less

So then we definitely should stop using LLMs.

Programmers have been in the business of disrupting our own industry since the beginning. Nobody uses punch-cards any more. Very few people need to code in assembly, or COBOL. Those decades spent fighting memory bugs in C or C++, with the scars to prove it, are worthless in the age of Rust, Go, Python and JavaScript.

Difference is, those things were an improvement. LLMs are a step backwards.

Accept that change happens. Be equal parts curious and critical about the new stuff.

I love change. I don’t like destroying the planet. It’s even worse when it’s of absolutely no benefit to anyone but billionaires. This isn’t change. This is destruction of the planet.

I like to distinct between programmer and engineering jobs: first is the code ape, that LLM coul theoretically do (still too verbose though) with some hand-holding from a engineer.
The second is creating the solution; how A interacts with B on condition C in environment D.

Sad part is, with how broken the web currently is (each site has to implement every feature themselves), there's lots of code ape jobs.

And btw, execs love LLM because they excel in the same task; creating lots of sentences with a minuscle of meaning and confidently asserting half-truths or outright lies. They have a "it's just like me!" moment. But both are bad at creating solutions.

programming is not hard. translating from human desires into a real project is hard. anyone who has read a project “plan” know what i mean.

Very few people need to code in assembly, or COBOL

But those who do are paid the big bux, that's for sure. Many big banks still have their backend off of COBOL code originally written in the 90s, only with flowery UI updates over the years.

Programmers say it and I doubt they do it to insult themselves. Code was never the hard part, it was just slow

Programmers automating coding then CEOs forcing everyone else to use it is an insult to programmers.

Some fuckers that built AI and fucked their own industry need to take some responsibility here. Some Sloppenheimer out there fucked the market up, one of our own.

Well written blog, thanks. I actually saved it to reread.

"Ok boss, let's make a bet..."