Comment by hakunin
12 hours ago
> Writing code is not hard. Writing correct code is. Knowing what is correct in a setting with paying customers generally involves interacting with those customers.
That's like saying "building a car is not hard, building a real car that you can use and that passes regulation is".
IOW, writing code is hard in every reasonable context.
Speaking/writing English is easy. Writing literature at the level of Shakespeare is hard. Writing educational content that makes hard concepts accessible like Grant Sanderson is hard.
Likewise, coding is easy. It's just writing, and any child can learn it. Coding is not programming, and the hard part of the job lives in that distinction.
> Likewise, coding is easy. It's just writing, and any child can learn it.
Any teacher of a low level CS course knows this is completely untrue. In my CS 101 course our problems were relatively straightforward and short, and lots of people struggled mightily to the point of dropping the course. IMO coding requires a particular way of thinking that a large subset of people just aren't good at, and as someone whose done tons of screening interviews at college recruiting fairs where I give relatively easy problems and ask someone to code a solution, I will tell you the idea that anyone can do it is just false.
English is a hard language to learn, especially as an adult. So many weird rules that everyone takes for granted.
Many still struggle with getting fizzbuzz right.
Why does it have to be Shakespeare? There are millions of good writers that got there by working hard. Seems pointless to go into either extreme, when just being good at anything is generally hard.
It doesn't have to be Shakespeare, but hopefully everybody agrees that writing at Shakespeare's level is indeed hard. I agree that writing good (but not great) or even just ok literature is still hard, but that invites a bunch of no-true-scotsman arguments that I just can't be bothered dealing with (like "writing Fifty Shades of Grey isn't actually hard" or something similar).
2 replies →
But I must insist: "building a car" is not hard (millions of children do so every year with Pinewood derby style box car kits), building a "real car" that you can use and that passes regulations is harder, but knowing the difference between the two is where the real hard work is.
The truly difficult work is knowing when your client/boss asks you to "build a car," do they really just want/need a small Pinewood derby box car as a toy, do they need a four-door sedan that can legally drive on major highways, an 18-wheeler freight truck, or do they actually need/want a bicycle, or a shopping cart, or a railroad box car, or information about how to take public transit that will serve them cheaper and easier than anything you could build in their timeframe and budget.
That's what people mean when they say that code was never the hard part.
I get what you're trying to say, but coding is hard. A significant percentage of children struggle with it from the very beginning, unable to reason in a very specific way, read and understand errors, trace incredibly detailed logic, gain mental model of memory and state, etc. According to these[1] sources[2] computer science has the highest college drop out rates: ~10.7%. I worry that "code was never hard" is going to become a misleading truism for business leaders.
[1]: https://missiongraduatenm.org/college-dropout-statistics/#:~...
[2]: https://www.coursmos.com/college-dropout-statistics/#:~:text...
> I worry that "code was never hard" is going to become a misleading truism for business leaders.
The fact that children cannot do it does not mean that it is particularly hard, and computer science attracts a lot of people who just like video games and have no mathematical ability.
I think that the fact that programmers were/are doing a lot of the job that other positions take credit for is significant. Others can get by on bullshit, but the programmer's job in turning that bullshit into code forces them to make something real out of it through a combination of back-and-forth interrogation and just making it up when necessary. Turning handwaving into a product is a skill that programmers have, and is why AI isn't helping tech-illiterate businessmen create things that work.
1 reply →
> Writing code is not hard. Writing correct code is.
Now add the time dimension - keeping code correct as the business and the people in it change.
That's how I explain to people that LLMs will not replace us developers.
https://media.ccc.de/v/36c3-11241-from_managerial_feudalism_...
Timestamp is: 36:42-39:55
I believe Graeber perfectly predicts the problems, in 2019, with vibe coding creating immediate "value" from production, but failing to produce true value through maintaining the system (like one continually washes a cup to give it value over time).
> (like one continually washes a cup to give it value over time).
But it doesn't give value, it prevents value loss.
I don't know why people are telling themselves maintenance work is virtuous. It's waste. It's necessary waste, and doing the work may be virtuous, but the work itself is pure waste. Fighting entropy.
EDIT:
I wish we talked more about the need for low-maintenance patterns and products. In this industry, many of us already recognize this instinctively, but we often misattribute the problem to "complexity". Think of e.g. rather substantial niches and common practices among developers, like static site generators, no-build-step development, or on the backend side, the popularity of header-only libraries in C and C++. All these tend to be labeled as reducing dependencies, but that's just the means - what they do is they minimize independently rotting parts. The build system isn't bad because it's complex - it's bad because you have to constantly babysit it. Conversely, a static site once rendered will open ~forevermore, and so will a piece of C/C++ code that relies on single-header libraries.
Similarly, the popularity of containers is in large part this. All the mess isolated in a self-contained bundle that is preserved against rot, at least for a while. Inside, there's nothing to maintain - it works until it's not needed, or until the "outside world" changed too much, at which point you throw the thing away and get a new one. Etc.
1 reply →
Most of the people who say LLMs will replace developers have never built and deployed a real app. I know someone working on an app that they were deploying and after "writing" thousands of lines of code with Codex, they needed help to deploy it despite getting pretty clear (IMO) instructions from the LLM. Later they were struggling to set up a test environment or add backups to the point that I was worried they might break production.
The few people who manage to write good quality production apps with AI are developers whether they like it or not and that number isn't high enough to obsolete existing developers.
LLMs will certainly replace most developers. Most developers dont know that "computer" was a profession not long ago (and a quite demanding one).
You are conflating "not understanding how to build software" with "not knowing how to write code". Most developers I've crossed paths with couldn't build a consistent library, let alone a complete, well written, architecturally sound and useful application. Sure, I also know plenty that don't fall into that category but those are the few.
Problems with deploy? Ask claude, use ssh with key-based auth and he will take care of it :) just saying.
I've been writing code "almost daily" for the last 35 years; been doing it professionally for at least 29 years. I've been around, and my peers consider me a proficient developer. I've built stuff ranging from embedded/os level development to DSL languages, from 3D programming to VBA macros. I wrote software used by me, and wrote software used by millions. In some cases, I've maintained products written by me nore than a decade. By your definition, I must be wrong, truth is I can afford to be wrong - my job is not writing code, is designing solutions. Writing code is often the easiest part, and we're mostly automating it. Thank god.
1 reply →
Maintenance over time is 90% of the work anyways, you don't start a project from scratch every day
How many programmers operate under that kind of regulatory and operational constraint regime? I think most don’t.
(In interesting ways this is programming’s greatest boon and curse: if we treated it more like building bridges or cars, the world would be a very different place.)
Touch billing, touch medical data, be at a B2B company that needs to catch all the ISOs to have a chance to land bigger contracts. I don't think it's uncommon.
It might be an unpopular option, but I think the regulatory regimes that control medical and financial privacy as they interact with software are significantly lighter touch than e.g. the regimes that control material quality for bridges and tunnels, much less airplanes.
4 replies →
It's questionable though how much the programmer is operating under it. The programmer's work may need to comply, but there are a bunch of things that can reduce how much the programmer themself deals with it.
There are the executives, the lawyers, the product managers, sometimes the designers, who to varying degrees determine this before they land in the requirements the programmer sees. But there are also the libraries and APIs the company pays to handle compliance so that the company and the programmer doesn't. The programmer implements the library (and may not even had a say in or necessarily care which one was chosen).
2 replies →
While there are for sure a lot of programming jobs that don't touch anything "important", like making dime a dozen websites or apps, I think you underestimate the number of things that need some form of higher quality control.
The level of quality needed (or imposed) will vary. It is a wide spectrum from dealing with banking/transactions (money at risk) to brake controllers and auto pilots (human lives at risk). But there is a lot of this, all over the world.
I work somewhere in the middle (rather slow but extremely heavy industrial equipment, where emergency stop is always a safe if costly option). There are domains where emergency stop is not a thing though: some systems on an aircraft in flight, a pacemaker, etc.
My point is though, that there is a ton of code where stakes are higher than "oops, I guess we will fix it next sprint". And while not all of that have regulatory constraints, sometimes a company realises that the financial cost of issues significant enough that it is worth holding themselves to higher standards anyway.
Any coder with experience or ability imagines a world where software architects are regulated the way real architects are, and acts accordingly.
I mean, this was drilled into me at uni — that software was not likely to escape regulation forever and that you can't know with certainty how all the code you're writing will be used when you're not observing the use.
For example, under what constraint regime should the calculator app bundled with an OS be written? It's just a little bundled toy app. Until someone under pressure uses it to calculate a medicine dose, expecting it to be a calculator like it says.
Perhaps this gives away my age more than anything else.
> For example, under what constraint regime should the calculator app bundled with an OS be written? It's just a little bundled toy app. Until someone under pressure uses it to calculate a medicine dose, expecting it to be a calculator like it says.
This captures a sentiment I have often felt when people don't take bugs seriously. Or don't take it seriously that they introduced regressions. You should feel personal responsibility for your bugs. When your shit doesn't work, and people are trying to use it, you are basically hurting them, personally.
But it seems with the increase of AI coding, the industry is going the other direction. Nobody seems to care about bugs introduced by slop coding. Except perhaps the users.
That's why I said "that you can use AND meets regulation". All software on average.
I think most do. You often sees that OSS often provide a disclaimer that they’re not liable for damages. You can’t easily do that when you provide a paid service. B2B often have SLA contracts that usually keeps everyone on their toes and not sling bugs right and left.
90% of code wouldn't pass a basic audit, let alone any sort of regulatory scrutiny. Developers are building the easy version most of the time.
The problem is that non-technical people just see The Code. And now when they prompt an LLM they also see The Code. Voila - finally we don't need those pesky engineers.
Communicating like this is to try to get them to understand that The Code is barely about the text on the screen and is instead about much more - both abstract in the code (but how on earth do you explain that to someone nontechnical without just sounding like "no trust me my job is really hard, I promise.") and also in all the external stuff - the world The Code lives in (users, ops, support staff...).
Is it a perfect analogy? Of course not, and I'd never explain it like this to someone technical. But they're not the audience.
---
Adjacent: I've always gotten the feeling that even the most well-meaning/trusting nontechnical leaders have always been fairly nonplussed by software complexity and software development.
Deep down, they seem to think it can't possibly be that hard, despite the fact they can't write it themselves. Sometimes, even worse, they have dabbled in writing small, or even medium-sized solo projects. And think - well isn't software engineering just doing that but with other people? And their attitudes can reflect them, sometimes all the time, sometimes just slipping through when under duress like delayed projects etc.
And yet despite their attitudes, they then also find:
- if they try to outsource, they have a bad time
- if they try to proooompt, they have a bad time
- if they try to pay less, they have a bad time
and so the invisible hand of the free market itself forces their hand in paying prodigious salaries and fighting to retain talent. And all throughout they remain internally nonplussed even if they manage to keep up appearances.
Your analogy breaks down because code is not heavily regulated as cars are.
This is worth saying precisely because of this difference - people see huge amounts of bad code generated by LLMs and think it is equivalent to carefully written code because the results look similar at first glance and they don’t bother to read it.
The code in cars is, by definition.
That is probably around 0.0001% of all code deployed.
For me this metaphor only makes the original point more credible.
Absolutely there can be a bunch of hard things wrapped around easy things. When those things can't be separated neatly than it doesn't make sense to separate them such that we can call the easy parts easy (or even parts really).
That said, it's still reasonable to think that once (and only once) the hard part is done, then the easy part is easy. It would just be wrong to think that you can do the whole thing without having to do hard parts. I think the argument here is that with AI this is more possible—that the tasks are more separable. Even if it's the same one person doing the hard stuff and then passing what they learned to the AI to do the easy stuff.
Two reasons they might not separate well (there are others):
- If in a company's product development it's hard(er) to have one person doing H and another doing E, then you're generally going to have one person doing H and E. More or less, this means a person can only do E easily if they do H beforehand. So hard things are required no matter what.
- People come in whole persons. If people skilled/educated to do H tend to be the same people skilled/educated to do E (can be because of how programming is educated, but also can be because there aren't that many programmers), then you're always going to be plugging programmers who have both H and E into roles and it'll probably be more efficient to plug them into roles requiring both rather than just H or just E. You could, within that population, determine who is comparatively advantaged (and we do do this mildly with senior vs junior or with "architects"), but plugging a person into an E-only role is going to involve that person questioning what happened during the H part beforehand. In part because they're good enough at H to question it, but more importantly because they're implementing the H such that they're aware when their E might not be as easy as it could be.
Both of these seem like they might be less true now with AI (and also perhaps because there are more programmers).
I mean, I think the point is, every discipline isn't ever that discipline in a vacuum, it touches the real world, and we build meta-structures around said things that may not look like programming, but certainly require deep programming SME.
Even in academia, you have meta structures that you constantly need to think about.
Of course, you can keep trying to isolate the "pure" thing from the "accidentals", but it's not going to work when the work gets sufficiently complex
The reason people say "writing code isn't the hard part" is because the only thing an LLM saves effort on is typing code into the computer. You still have to know what the code should do, and you still have to review the code the LLM generated to make sure it is reasonable. In other words, you still have to do the hardest parts of your job, and the LLM only saves you effort on something which was no real effort to begin with. That is why they are an ineffective tool, because they are helping you with the bits you don't actually need help with.
I don't agree that "the coding was never the hard part" in general, but it is true at least often.
For those cases where it is true, it is pretty much like your example, and the distinction is there in your example just like theirs. You supported their point.