I believe there are some programming jobs in which the code is absolutely the easier part. Not all of us work in signal processing, integrated systems or have to push upstream to Linux kernel because the company we work for really needs a memory allocation optimization for its data centers.
Navigating customer requirements and building something that satisfies both market's needs and company strategy can be an incredibly difficult and frustrating problem to solve. Especially if you need to also oversee the execution of the strategy. So not only you have to predict what they want or know the domain deeply enough to understand what they say they want is not what they really want, you also have to come up with a plan for executing your solution in a corporate environment.
There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, establishing support for executing a plan or creating alignment on big efforts. In large corporate environments with multiple international customers, code is most of the time not the hardest problem.
I think 80% of a SWE's job is to communicate with the XFN partners (either gathering requirements, pushing back, managing up, collaborations, etc) and then plan out the actual coding (gather code pointers, look at past code, plan architecture, talk to the team). The last 10% is the coding. And then the other 10% is the maintenance of that and past code (which honestly should be a lot more but incentives are not aligned well).
It's hard for people to understand jobs they don't do. They imagine we spend 8 hours a day clacking at the keyboard.
> There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, [...]
Why would they cover programming? That's what all the books on programming are for.
Also I see no need for signal processing to make programming a hard problem. Writing correct code is hard. Writing code that makes incorrect code easy to spot and hard to write is hard.
You can be great at local maximums, communication, establishing support for executing a plan or creating alignment on big efforts, and proceeded to still create a ball of mud. Bug ridden, hard to read, hard to debug.
A buggy big ball of mud that does mostly the right thing is still going to beat a high-quality, carefully architected solution that reliably does the wrong thing, though.
And for a huge amount of code, it's not very hard to make it good enough, because the requirements, once understood, are pretty straightforward and perfect correctness often matters much less than you would think.
What a grounded take on this and wished more people saw it this way
Just yet another case of people seeing only the extremes and not the entire spectrum
You nailed it: in a corporate setting, code is definitely not the hardest part and it’s why companies can sometimes make do with a skeleton crew of offshore engineers who make $20-$30 bucks an hour
The way harder part is building the right thing and just designing the thing soundly to begin with
This type of software is where AI absolutely kills it - problems with tons of forum posts, writing code for systems with a ton of various kinds of quality developer documentation
On the other hand, if you’re doing something novel or sending a $10bn machine to mars, you probably don’t want to yolo it with AI
> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
Because programmers have generally been forced to wear additional, invisible hats that are essential to making the code happen in the first place.
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. Either directly or worse. The gigantic salaries paid to the most prolific employees is not due to their ability to write code. It is due to their ability to interrogate the shit out of the customer until they finally reveal the true requirements.
> 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.
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.
Not really. In those safety-critical areas, the code really is no different. What is significantly different is the surrounding process.
I had to make some software changes to an old medical device this year. The overwhelming majority of the effort was understanding what the customer wanted and giving them feedback into how that would change the existing system and the risks associated. Then, creating a plan to follow the necessary standard (IEC62304) and creating the associated documentation and getting it reviewed and approved.
The actual code that changed was probably only around 100 LOC but the project took several months. Heck, the code was simple enough that an intern could have done it.
I left out the code on medical devices for a reason! And similarly for avionics software.
(The distinction I’m making is between the code that operates the medical device and the code that operates the app I make doctors’ appointments in. The latter is subjected to a different - and lighter - regime than the former.)
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).
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.
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.
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.
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.
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
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.
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).
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.
> 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.
Invoice: $1000
One bolt tightened: $1
Knowing which bolt to tighten: $999
> The gigantic salaries paid to the most prolific employees is not due to their ability to write code. It is due to their ability to interrogate the shit out of the customer until they finally reveal the true requirements.
Bit of both probably. I've seen really awful code in my time, so would say "actually coding well" is indeed one of the hard parts.
But knowing what the real problem to be solved is, is indeed important. (Isn't that what sales is? Working with the customer to tease out the real thing they need solving?)
> (Isn't that what sales is? Working with the customer to tease out the real thing they need solving?)
For any product of any complexity you can can essentially never successfully delegate that process to a non-programmer.
Indeed you can not that often even trust that the client employee doing the asking knows what it is they need. Almost certainly someone in the organisation who was not in the meeting is better placed to tell you what is actually required.
This task needs an analyst; that analyst needs to have experience of writing meaningful code.
Exactly. Writing code is easy. Junior developers do it all the time. Hell, they write far mode code and do it faster!
I go half the speed of a junior developer, but the code I write lasts five years to a decade with an order of magnitude or two fewer bugs and long-term maintenance burden.
I think people also have a natural tendency to assume that the amount you are paid is correlated to how difficult the job is, which isn't quite true. The market value of a role has a lot of additional factors besides how intrinsically difficult the actual job is such as supply and demand and the funding source. Programmers may have been able to demand high salaries partially because the explosion in demand came faster than the explosion in supply.
While it is true that a programmer's job is a lot more than writing code, I also wonder to what extent that businesses will actually be able to tell a good programmer from a bad one. For example, a lot of folks at big companies can honestly get away with being a ticket-taking code monkey because so much of the responsibility has been abstracted away so that they don't actually get punished for not caring about the customer. It's sort of similar to how many schools realistically wouldn't care to distinguish between a teacher who puts in extra effort into their classroom versus one who clocks in and clocks out as long as some bare minimums were being met.
I think strong programmers will get rewarded in the right companies that need them, but it's still an open question as to how many companies exist that have their bottom lines actually depend on a programmer doing a good job at wearing all those extra hats.
nope, I've definitely worked on a lot of projects where knowing how to satisfy the requirements was not the challenge, writing the code was genuinely hard. complex data structures that had to have invariants maintained, distributed access to shared memory, dealing with various forms of fault tolerance, and above all getting some complex algorithms to run at an acceptable speed - all that really does get bottlenecked on the difficulty of the specific low level code you have to write. and then there are the architectural issues that make all the difference not when the code is first written but months later when you want to add another big feature and find out that fitting it into the existing code base is hampered by the early decisions you made. I'm honestly glad to have LLMs to help with a lot of that, though I'm also glad that I built up the skills to do them myself over the last few decades and am a little sad that programmers today will not build a lot of those skills up.
If you have shop where you have the best product-owner in the world, and exact clarity on how you want to build something, how all failures are handled, all the tradeoffs, all the implementation details, all the risks, then product is simple, then your company absolutely can get away with hiring a less than top-tier engineer.
However if you're combining all of those skills/roles into one individual (a staff+ engineer) then of course it's going to be expensive.
In my experience the only people who get paid "well" to just code up well defined JIRA tickets are new grads, and this is essentially a training period until they grow into leading complex and ambiguous projects independently. You can't hang out there more than a few years.
Wow, some "the killer is calling from inside the house" vibes right there. But I totally agree that the game of telephone has always been _an_ issue - maybe not _the_ issue but certainly a big one.
> Writing code is not hard. Writing correct code is.
Dude.
Writing correct code is the whole process. If you're defining coding without care for correctness, of course you can write it off as not the hard part.
The point of the OP in this case wasn't code that compiles, but code that does what the customer wants. If the customer orders an email client but really wants a chat application, coding a working email client is not "correct". And insisting that the customer ordered the wrong thing won't change the reality of the matter.
> The gigantic salaries paid to the most prolific employees is not due to their ability to write code. It is due to their ability to interrogate the shit out of the customer until they finally reveal the true requirements.
That doesn’t describe any devs I know, especially not in the old days. Interrogating customers and bringing back requirements was the job of management (who got big salaries, too.)
That has only been true in the largest corporation I've worked for (around $4bn annually). Even then, we (devs) had to challenge inconsistencies in requirements or incomplete specifications.
The only job I've ever had where I could just do exactly what I was told and get away with it was right after I got out of college.
Agree. What a strange perspective. Engineering is what is hard, and that includes coding and non-coding activities but doesn’t require customer interrogation.
I think you're confusing product and engineering. I get that programmers are smart so we just assume we can do every job, but it's a waste of your time and salary to talk extensively to customers and create product requirements. Let the PM's run the user research sessions, you can find more productive things to do.
However, where we agree, is that there is more to engineering than writing code. It's problem solving. Even if the product team, the c-suite, the board, the investors, et al, are all in on a product that they believe customers want, doesn't mean the real problem of bringing that idea to life at scale has been solved.
Product should, definitely, run user research along with Product Design. But what I find is that people in either have a problem imagining a solution that's a couple of orders of magnitude easier to build, but also much easier for our customers (usually boils down to making the right choices for customers — the savings are not in the common "choose good defaults", but in actually removing flexibility that's needed only in 1% of cases).
Thus, I insist on engineering being involved early to put real world constraints on wild ideation ("it would take 3 months for 5 engineers" quickly changes what's a must-have :)) — sometimes, a curious, critical mind can expose things like these without having to do the research or user testing themselves.
Now, throughout my 20 year career, it's been very rare to find a product person who will both understand customers deeply, tie their needs to business value, and be able to formalize the intersection of these in a form of good requirements for design and engineering to eventually build!
So I really believe an engineer's (and design) role there is to serve as a sanity check as they dive into actual building — does this really make sense? If they do not, they run the risk of a project completely failing or perhaps not even shipping once someone else questions the value of continuing to invest in this 3 month project 9 months in. ;-)
Writing code has a minimum IQ requirement; a significant fraction of the population will essentially never be able to code by themselves. That labor supply limitation is what's kept programmer salaries relatively high.
Writing code doesn't have a notably higher (if at all higher, vs lower!) IQ requirement compared to some of the basic components of EE or MechE work. Programmer salaries have been driven up by the ability to write-once-sell-globally and the dramatic profit margin difference between that and, say, producing chips where there's a much higher fixed cost due to the need for more real material, tooling, etc. Many of those roles require a much higher-than-baseline-skill, but it pulls up the compensation competition for almost everyone else too. (Though even then there are a lot of unglamorous, line-of-business, internal-tools-programming work that's not paid particularly well even in a lot of parts of the US far from the big tech companies.)
Salaries are a product of supply AND demand. Supply of good programmers and EE/MechE is low because it requires above average intelligence and a lot of education, while demand for software has been much higher than demand for EE/MechE. Now that the demand side might invert.
After 30+ years in the industry the absolute best programmers I know never spoke to any customers, like ever. so bullshit comment all around. I’ve been coding for 30+, have obscene salary and do not wear any “additional hats” or talk to any “customers.”
“understanding requirements” is as much “wearing other hats” as having hands is “wearing other hats” for a carpenter.
coding is always the hard part, always. whenever I was on any project and we had more work than resource we never hired “people to wear other hats” - we hired people
to write code, that’s it. thats the fucking job.
you ever see a leet-code-for-understanding-requirements? yea, me either…
Everybody saying "coding was never the hard part" is really telling on themselves. Coding was never "hard" because most organizations were absolutely unwilling to take on any technical work that was hard. That tells us about business strategy and culture rather than anything about the fundamentals of programming or technical work.
The real conclusion is that programming is such a high-leverage activity that even technically trivial, low-quality programming is immensely valuable economically. That's not going anywhere, but maybe LLMs are going to make it all that much cheaper. (Which is mostly great! But I really don't look forward to the painful debugging and maintenance that reams of shit code will push down on programmers.)
But also, there still is a ton of programming that is fundamentally difficult. That's not going anywhere either. And LLMs are useful there too, but they're currently nowhere near replacing the expertise needed to do novel and non-trivial technical work.
In an ideal world, making mediocre code cheaper should leave more room for taking on harder technical challenges. In reality, this has always been dictated far more by non-technical factors—culture, leadership, trust, risk tolerance...—than by anything intrinsic to programming. But, at least for now, we can use the LLM hype to motivate the kind of deeper technical work that always made sense but was too uncertain or too open-ended or too long-term for non-technical leadership.
And we should also drop the bullshit "code was never the hard part" framing.
Those corporations that undertake the actually difficult bits of programming end up charging so much money, to the point that people go out of to not use them though. Splunk, Oracle Database, Spanner, Datadog, VMware. We don't live in an idealized world divorced from business and money, unfortunately, but worse, software developers are notoriously cheap and hard to sell to. If I did the hard work and made a compiler that generate code that runs 10% faster, I should have a solid business. Even Intel couldn't make a business out of icc though. So the code is the hard part but business is also the hard part and it's a miracle any of this stuff ever gets off the ground.
I agree, the whole 'developers don't code' AI defense was pretty ridiculous. I also concur that development is going to get a lot harder. Anyone that has successfully used AI coding tools knows that you can get massive productivity increases but now I have to figure out how to get a bunch of hyper active child like coding entities with memory deficiencies to build stuff without going off the rail and introducing massive security problems or building something completely mismatched to the requirements. If you can do it, yeah you can get 10x results. But now I am engineering harnesses, architecture specifications, agent structures, statistically sampling, and formal verification systems to guide the code instead of writing the code.
I'm definitely noticing, I imagine the populace at large will soon too. I'm not even talking about random software either, the company I work for has more and more fired that need to be put out because people are spamming out ai-generated code that was at best rubber stamped.
Not even just the customer-facing stuff either, the internal tooling is on fire more and more often. It's not sustainable in the slightest
The sad reality is that the vast majority of customers (whoever you are writing software for: clients, management, or end users) simply don't care as much about quality. If you give them the "time, cost, and quality" pick-two choice, 99.9% of customers are going to ask for fast+cheap. It's not the world I wish we were living in.
This is all the stuff that the frontier labs are going to ship by default next year. Except for the architecture specifications, which agents can already do adequately for most system today.
>get a bunch of hyper active child like coding entities with memory deficiencies to build stuff without going off the rail and introducing massive security problems or building something completely mismatched to the requirements
I see this comparison a lot, but I’m not sure I agree. At least not semantically. The list of what an engineer using agents is responsible for, largely hasn’t changed. Engineering managers haven’t changed responsibilities either.
Even with wrangling agents, you’re really just making them right the “correct code”. Something EMs don’t do, or at least the good ones don’t do with their ICs.
It is quite similar to architecture work when others in the team do the actual coding, and lead devs / architects only have time to try out prototypes.
Only now instead of local or offshore devs, it is agents.
> 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 companies resent that they have to take on risk and pay people to extract value from the market.
Ugh, why do we have to pay people to code, maintenance, etc. Lets pay people to extract more value for our bonuses and shareholders. Lets try to only hire heavyweights so that we don't get hung up on that difficult-to-measure coding process, knowledge transfer, messy human-ness. Oooh how nice, we can hire a fewer employees that know how to leverage code agents that free them up to think about that what REALLY matters...
The answer to all these "if coding is easy" questions is that coding isn't programming (to put it in Lamport's terms).
Encoding your ideas into a programming language is easy. Understanding that your ideas are bad is hard.
You have clients with multiple devices connecting to your backend simultaneously, while you mediate their interactions with your partner systems. Their versions might not be up to date. It's a distributed system. When was the last time you cracked open a distributed systems textbook?
When was the last time you built a system and stared reality right in face, that is:
- can't trust your clocks
- pick 2/3 of CAP
- exactly-once delivery impossible
- the code will need to be altered and released without downtime
- hackers will try to exploit you for fun and profit
- your manager doesn't want you wasting time getting the above right
Coding just often has a fast feedback loop. If you can't do it people are going to notice pretty fast. You can fail as an architect or prod management for a long time before people discover you are not good at it.
One thing that is good to have in all those positions is an understanding of the code base and where it can slowly evolve to and how that positions the code base best in the market. I'd say the best way to build this understanding is still to build parts of the system yourself. Not talk to experts or agents about the code base.
Non-coding architects were typically a by-track rather than superiors to ICs. Though I imagine some of them could think they were. Product managers also often don't have proper reports in the sense line managers would.
Those computing ideas (like distributed systems, concurrency and task scheduling) can even be found in even a single program/system. They are often entangled with even broader concepts, like visual layouts, security (authentication, authorization), communication and encryption, control systems, signal processing,… And those are often accidental complexity.
The essential complexity can be easily resolved by talking to domain experts. You will get a nice requirements document afterwards. That’s when the engineering and management concerns appear.
You seem to be misunderstanding the premise of the statement. Go write, "print 'foo';" and copy and paste that statement one hundred thousand times. Congratulations, you just wrote one hundred thousand lines of functioning code! Was that hard? No? Okay, so how is this different from other code? The difference is that it's easy to _understand_ how that code works, because it's the same behavior repeated over and over. So, writing code is easy, but understanding code is difficult! And, when we code with AI, undertanding is precisely the part that it can't handle, even though that's where almost all of the value is!
> Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book?
I still read TAOCP occasionally as a hobby. The combinatorial algorithms and data structures are just fascinating. That said, this argument seems irrelevant to majority of the programming jobs. I doubt most engineers will ever need to implement anything mentioned in TAOCP, thanks for all kinds of powerful abstractions.
I agree with the author that coding is objectively "difficult" but this is something I am good at, while dealing with people, changing requirements, bureaucracy, and maintaining work relationships I find challenging. I always say coding is the easy part of the job (for me).
The author's main thesis, that coding is hard, conflates what an individual finds easy or hard, with what is easy or hard for an average person.
>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? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers?
Because they're not the ones deciding it, they just provide input for the Heads/VPs/managers who make the strategic decisions. And they are paid pretty well for this.
> 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 rare.
It seems the author has misunderstood the point of the common narrative and has torn apart what’s essentially a strawman.
The degrees, the books, that’s not the supposedly easy part. That’s the HARD PART, and it’s actually the “what you build” thing. What you build is the code architecture, knowing how to conjure objects, methods, modules, lambdas out of thin air in a way that faithfully represents a real-world problem. Literally the shape of the resulting code. It’s not product or CS.
The easy part is supposed to be actually typing out the code, putting the methods together, remembering method names and syntax quirks.
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.
I guess my impression using these tools daily is that it hasn't diminished the need for my own technical expertise. The conversations I have with it are highly highly technical, and to me the insights come from both sides, I see things the LLM doesn't, and the LLM sees things I don't. It writes a lot of bugs that I have to spot, and writes designs that aren't correct. (This isn't a criticism, I do the same). I think the ideal world version of this stuff is complementary, but the current insane bubble economics mixed with the insane religious fervor make that unpalatable to the leading AI companies. (Like, I think Sam Altman said that anything below a trillion dollar IPO valuation is a "non-starter".) So, "nice coding tool", even if that's the BEST and most realistic outcome, is just not going to do it for them.
Yes, writing code that (appears to) work was not the hard part. Even before LLMs you could find very cheap contractors on Upwork or through offshoring companies to write "code".
Well-engineered code is hard. It still is. Code that is reliable, extensible, maintainable, scalable, legible, understandable is hard. Code where the specs and the "why" behind it were pressure-tested via thought and good intuition.
One of the strongest teams I worked with, working on an extremely large and ambitious project used to answer a lot of product/executive type questions regarding missing areas that we knew how to author and could safely assume general design consensus “it’s just typing”.
It was a very useful contraction in the right senior circles where there was a pretty good understanding of the meaning and decently reliable assumed consensus.
I eventually stoped using the phrase because it had started leaking deeper into the team and the impact on earlier career or less confident programmers was often no longer positive, it could be misinterpreted in lots of different ways but the most harmful was when it would further decimate confidence and discourage requests for help when something wasn’t obvious to the ultimate author.
As with almost every attempt to generalize in software engineering the repetition or extrapolation beyond the context in which it was intended can have negative side effects, it doesn’t matter if it’s a simple notion like “dry”, or a comment like “code was never the hard part”. None of these phrases survive context loss and still retain efficacy at general receivers.
Is what he said wrong? Why don’t you attack his argument rather than his background. Not snark. I want to see the holes in what he says and I literally don’t care about who he is.
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.
That depends on the quality of the degree. I was well served on my Software Engineering degree, coupled with the trader school in computing I went during high school.
Then naturally seniority teaches office politics, and what to actually invest time on.
Coding is easy if you enjoy doing it, met plenty of professional programmers that hated it and never felt the desire to improve. To them it was a way to get a paycheck that paid reasonably well.
Better to have a job you don't like that pays well than to have a job you don't like that pays poorly. But at the same time - if you're smart enough to program well enough to get paid while hating it it's such a shame to not find something you enjoy that will still pay you enough.
LLMs are the invention of the loom. Code is being industrialized.
Yes, there always will be artisanal weavers and a smaller number of them get paid a lot more money to do this by people who can afford it. Everyone else either started operating a loom or did something else.
Automated looms are now making mass amounts of textiles but the artisans are no longer doing the physical act of weaving. The artisans come up with cool designs, get feedback from customers, solve people's problems and outsource the rest (physical labor).
We are in the loom moment. Are you designing things people want? Are you doing the weaving? These two paths can coexist but they are diverging disciplines with diverging difficulties and diverging value.
Typing code into a computer is rapidly becoming physical labor now. The layer of creativity and problem solving is quickly rising to a level above the code since the code is a fluid now that comes and goes easily.
Art, Bespoke, Artisinal, Mass produced, Engineering, Aeronautical Engineering, Aerospace Engineering, Material Science.
Mass production is certainly here for the majority of programming jobs. The competition for the jobs that are left will be intense, but most simply won’t make the bar. Someone said elsewhere “It’s no different than ordering a pizza: I don’t do the work.” Yes. Pizza is automated now. But no pizza employees are coming for my job. When the AGI comes for my job, we will either have post-scarcity utopia or more likely we’ll all be dead.
It seems so obvious that a non-tech company can benefit hugely from AI for their bespoke use case, especially if no one in the company knew how to write code pre-AI. But it's also easy to put some planks down across a stream and call it a bridge, that doesn't mean it's built well, going to last, or that there's no longer a need for structural engineers and architects.
These comments reveal a stark reality: most HN commenters have never worked on a really hard problem. They think hard problems are leetcode hards that have a prescribed list of known techniques to apply.
They think communication, alignment, gathering requirements, and other political bullshit is the hard part because they have never actually solved or had to grapple with a truly hard problem.
That’s fine, but it shows the corporate programmer who is probably in meetings all day has a vastly different reality than those of us who have had to solve open problems with no solution written somewhere because there is none.
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.
do you know how many eBay clones were out there after Ricardo? how many people built twitter clones?
building the website was never the hard part, making people get to it and use it was always the costly and hard part. nobody talks about embedded device programming when they say code was never the hard part.
"The labor is valuable" is basically the refrain of every single laborer in every industrial revolution.
The point isn't that labor isn't "valuable" it's that "value" here is a moral position. This same thesis could have been said about basically any mechanized industry.
There is no putting the genie back in the bottle. You can't un-invent the nuclear bomb, or the printing press, or the steam engine. We need to find a politically stabilizing way forward, and that means we need political coalitions that don't consume themselves with infighting.
Right now we can't even work together to build housing for young people... how the hell are we going to get through this mess without actually trying to build something bigger by making sacrifices.
Writing code that's logical and easy to follow, that can be extended in several likely dimensions without major plumbing work, and that doesn't contain "gotchas" for the maintainer, is not at all easy.
> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
There's probably a lot wrong with the "coding was never the hard part" take, but this quote right here shows that the author is not willing to engage with the actual idea that folks who say this are espousing. Because if the author was discussing these ideas on good faith, he'd know that the answer is obvious: there's much, much more to a software engineer's job than just coding, and that other stuff is very hard to do well, and people pay for that.
Again, I'm not saying the "coding was never the hard part" folks are right, but I really, really hate straw men.
> I don't mean to imply there are no developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder, tho.
Well, this is also an insult.
Cleanest way I read this is seeing how basically none of it makes any sense for someone coding as a hobby, or in any non-business context.
This is not an article about coding, it’s a promotional piece for business stakeholders.
As computing systems become increasingly capable and encroach in our territory that distinguishes us and lead to our success as a species, intelligence (whatever that is or isn’t), we redefine the problem and handwave away the new capabilities.
It’s getting increasingly more difficult to do that in knowledge domains with current frontier agentic systems. They’re not AGI, but they start to make it increasingly difficult to move the goal posts for many people’s comfort.
We really need a lot more philosophers, sociologists, and frankly economists working on this problem: in an era where physical needs were mechanized away and increasingly aspects of the knowledge economy are shifting away, what does it look like in modernity? How do we sustain or adapt our current economic models? What new models may be needed? Do we need to continue to enforce this whole work to survive in an environment where much work is disappearing or at the very least shifting around.
No, we’re not there yet. You still need experts to guide things around, but it’s becoming increasingly easier to do more in this space with less humans. That’s not a trivial change in the US where we put most our eggs in this whole knowledge economy basket.
Unpopular opinion: I fully believe that anyone who says "code was never the hard part" was an irresponsible coder who perhaps never had to work for themselves.
No matter how long you spend on architecture, no matter how carefully you plan your features, if you are an actually good developer there are choices that emerge only from the first draft of the code — things that you could do better, broader ideas that suddenly emerge and change your view of your own work, abstractions that become possible once you internalise the project through writing it, realisations that a requirement is unscalable, unworkable or unsafe, etc.
Nobody ever finds all those things only in the planning stage in any piece of code of consequential size or functionality: if it was easy, we'd all be doing waterfall development like 1970s consultants or using StP like 90s consultants, and none of those other ideas about coding would ever have emerged.
LLMs will just write the code. They will never have the rest of that experience. And I think any coder who doesn't have a visceral feel for what I said above is just bad at it.
"The code was never the hard part" is just edgelord AI evangelists masking denial with a pithy mantra. The code, its capabilities, the tooling choices, it's all indivisible from all the other hard parts.
But then these are often also the people who think they can use AI song or image generators to do the bulk of the work and "add the finishing touches". They also think "taste is all that is left" when the thing that gets us paid is not just our taste, it's our responsibility for and to our work.
The arguments are couched in questions… which all either have ready answers or imply strawman arguments that few are making.
I suspect it’s emotional and indirect because the author understands how poor its arguments are. That leaves open the question of why do the blog post at all, but I guess bloggers have to blog, whether or not they’ve got anything to say. An angry, emotional, vague post probably gets a nice amount of views.
"Code was never the hard part" misses the point but so does this blog post. This blog post from 2011 is worth reading and really cuts into the middle of the dreads-of-programmer.
Don’t call yourself a programmer: “Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo.” If you call yourself a programmer, someone is already working on a way to get you fired. You know Salesforce, widely perceived among engineers to be a Software as a Services company? Their motto and sales point is “No Software”, which conveys to their actual customers “You know those programmers you have working on your internal systems? If you used Salesforce, you could fire half of them and pocket part of the difference in your bonus.” (There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)
That patio11 post was good but you're overstating its relevance here by suggesting the thread's central topic is missing the point. The fizzbuzz part even undermines the "Code was never the hard part" message. If code was never hard, why has it always been so difficult to find talent that can do the most basic of tasks with code? Why was it considered a good average for programmers to only bang out 1000-2000 lines of code per year, measured by observing a team over 15 years, when it was well known even back in those days that skilled programmers could produce a lot more, and deliver even more business value quicker?
> When I introduce myself, I usually call myself a programmer, regardless of my current work on chip architecture and management and stuff. I got into programming for the money, so it's not like I'm overflowing with pride when uttering "programmer". I just think programming is a great career and the right thing to call myself for me.
> There's an alternative approach where you program, but you don't call it that, and you use programming as a starting point from which you transition to some form of being involved in business as directly as possible.
> It sounds a bit roundabout to me – why not just get an MBA instead? – but maybe it's the right path for some (especially considering that some prestigious MBA programs want you to have industry experience before you can even enroll.)
> The important thing is to choose the path that suits your preferences, follow it consistently, and realize where your approach is most likely to succeed. Because where I work, someone applying for a programming position and not calling himself a programmer will not make a good impression.
Sometimes calling yourself a "Software Engineer", or focusing on "$X company revenue definitely attributed to my efforts" rather than the technical details, is the right thing to do. Sometimes it's not. In any case I'll continue explaining to outsiders that "software engineer" is mostly just a fancy term for "programmer", and to programmers to call themselves whatever they think will best give them a chance at working where, on what, and for how much money they desire.
TBH the "don't call yourself a progreammer" part of this blog is the least interesting part of it. It's decent or awful advice depending on the person.
The more interesting part, to me, is the 15 year old recognition that programmers' jobs are to replace other workers. It's definitely not a new thought at all, but it's interesting to reflect on considering how the dynamics are starting to turn the other way around.
Saying this as someone who knows many programming languages... but I don't consider myself a programmer because that's too job-oriented. Like.. I write code for fun and "programming" isn't fun.. it's a living. This approach has let me follow multidisciplinary paths by framing my career away from the code-as-my-product mentality.
I think there is a de-facto distinction between different kind of programmers, we just need a clear names for them. Like, "builders" for folks who ship products and see code as an annoying intermediate step and "engineers" for people who build technically sound software.
Business has detested IT forever. It is basically considered blue collar work they felt held hostage to as it was 'brain' based instead of 'muscle' based, and it threathened to expose the grift of clueless "management" (not all is). They yried to placate with CTO, and l created tech diluted CIO and CISO titles for themselves, but the fear and loathing is as strong as ever.
This is dishonest. Nobody said "coding is easy" in a void. They said "code isn't the hard part" - in the context of LLMs. The obvious implication being that the actual speed of writing code wasn't the bottleneck. The implication is not that it's easy to think of what to write, or that any of the other parts of coding are easy.
I feel like you're getting hung up in semantics such that your essay doesn't say the obvious: coding is "easy" relative to confidently knowing how and what to do next at every stage.
The comparison does not imply that coding is an easy thing to do, just that it's easier than being really, really good at the bigger picture.
What Carmack did wasn't hard because writing C is hard.
This is the kind of thing where everyone just talks past each other because "coding" can refer to a ton of different things. I think we've all had the experience of having to write large mechanical boilerplate or refractors which was definitely highly automatable coding. I think we've also all has the experience of being utterly dismayed at how hard it is to write certain logic, especially with LLM "assistance". I've spent the last couple days marveling at how consistently fable introduces race conditions into a complex state machine I'm maintaining. Coding can be hard, or easy sometimes
Is it just me, or is this article arguing against a straw-man?
Isn't the real argument that "writing code is not the hard part"? As in, reading and understanding is the hard part. Figuring out what and how to change is the hard part.
Writing is the last 1% that happens after you have already finished the 99% of talking to people, figuring out what needs to be built, building up context about the codebase and surrounding infrastructure in your heard, planning the actual changes.
That quotation is coming from programmers themselves.
Managers and execs aren’t saying this it’s the programmers and coders themselves making the claim that coding was never the hard part.
It is still an insult though. It’s an insult to themselves. It’s the lie all programmers including me tell themselves as reality itself insults us. Coding WAS the hard part.
That’s exactly what we were good at. Now our skills are getting owned by automation. How do we face reality shitting in our faces? We lie. We fabricate a reality that’s more acceptable. We frame our environment in a way that still validates our existence. If AI has invalidated all of my programming skill then I need to find something else to support my identity.
To be precise, it depends on the domain. The people who could actually write algorithms or core implementations were always a minority. Programmers like me mostly did copy-paste from Stack Overflow or assembled libraries.
It's not that code wasn't difficult—it really was.
In CRUD apps, about 70~80%of the work was building the same thing over and over, so once you got familiar with it, most of it was repetitive practice. But the number of people who could actually create something new was always small.
Most business programs had issues that arose in the application stage, the application layer. In this application layer, only a very small portion involved difficult logic. Most of it was just applied.
The problem is that people often romanticize the lower layers beyond their own, compilers and low level systems, calling that 'real programming,' and in doing so, they make programming seem harder than it is. In reality, the coding that most people make money from is mostly at the abstracted layers. The infrastructure beneath those layers is owned by giant corporations. If you work at one of those giants, that's fine. But beneath them are countless consumers paying those giants, and the coding that targets those consumers isn't that difficult.
In the end, whether coding was difficult or easy depends entirely on which layer you're working in.
What's certain is that coding was difficult, and it still is.
If you’re struggling at formal thinking, coding will be hard for you. I’m not talking about designing software with higher concepts, like thread, network IPC, web application routing, gui,… but more simpler one like basic data structures (list, tree, maps, graphs,…), algorithms (search, sort, balancing trees,…), and paradigms (procedural, functional, oop, relational,…).
I’ve met a lot of programmers where those concepts where only words and not something they have understood. A snippet of code is either something they have to learn or copy, it’s not something they can fluently manipulate. It’s the difference between having to use a dictionary and sample phrases and speaking the language fluently. The former is a chore, while you don’t even notice the latter.
I resonate with much of what you have pointed out, but I have a different perspective on certain parts.
Software consists of various layers, and everyone has their own specific areas of strength.
For instance, because I am an application programmer, I often need to write code that prevents the program from halting—aligning with recent programming trends that involve preserving the computation context using monads.
In other words, my strengths lie in the overall architecture and interface design.
This fundamentally relates to cohesion and coupling. I excel in this area, particularly when dealing with codebases around the 60,000-line mark. This is a realm where books like Clean Code are quite effective (many people dislike it, but it is actually a well-written book).
Put differently, I possess the ability to mass-produce software (regardless of absolute quality). Over the course of 7 years, I have built CRUD applications for 43 companies across 16 different domains (ranging from drones and golf simulators to tax SaaS and supermarket POS systems). Therefore, I believe I have at least an average, solid capability in this regard. The primary area where I actually made money was PLC, so while I may not have deep academic expertise, I certainly do not think I lack capability.
In Korea, the profession known as SI (System Integration) is a field where you enter contracts on a "project" basis. In that environment, I have encountered a wide variety of people. From those experiences, my takeaway is that programming is divided into quite several distinct layers.
To speak of algorithms first: I learned basic algorithms and fundamental data structures in university. However, in the field where I worked, there were many people who struggled to implement those basic algorithms, yet they still built a large number of applications. Why is that? There was even someone who made an amount of money I could never dream of touching in my lifetime. Why did he make so much money when he didn't even know how to implement basic algorithms?
The answer is quite simple. It is because the "implementation model" and the "contract and cost model" are different.
The contract and cost model is a self-contained body of knowledge. It is the ability to know exactly where to fit a given piece into the puzzle. Implementation is simply the ability to build that piece from scratch. In fact, mostly due to issues like employee turnover and the organization's future maintenance capabilities, many teams (specifically, organizations with lower implementation capabilities) decide on an open-source library and design their architecture based on its API. In these cases, the primary technical challenge becomes how to connect those components based on the performance of that library.
Yet, people tend to think that only those who can implement from scratch are capable of programming. A person who can take someone else's implementation and piece it together to fulfill their own contract is also a programmer, but people frequently forget this. Depending on which layer you exist in, certain knowledge requires you to implement it yourself, while other knowledge only requires you to understand the contract. I believe this is the core of programming.
Those on the side that must design and build libraries or frameworks naturally have things they must know about implementation, as they are creating the SDKs. However, I have seen quite a few cases where these very people have no idea how their work is actually utilized in the upper layers.
And these types of knowledge are highly fragmented.
In my case, I am familiar with quite a few paradigms. On my personal homepage wiki, I can differentiate between OOP, DOD (Data-Oriented Design), and others, and in the context of relational databases, I know exactly where the ORM impedance mismatch occurs. However, this is largely an area intertwined with architecture, and its essence is closely linked to David Parnas's theory of information hiding.
In other words: to what extent do we hide the internals, and where do we expose them to minimize the contact surface area and ensure a safe connection?
For example, I can't implement PostgreSQL's B-tree. But I can design a business system using PostgreSQL. I only know the name of TCP congestion control—I don't know how to implement it. But I can build networked applications.
That's what an 'industry' really is. The ability to trust the contracts of other people's implementations and assemble them. The ability to trust others.
In that regard, I agree with many of your points. However, I actually believe the software industry needs more of those "average" people. I think the very definition of an "industry" should premise that average people can maintain their livelihoods simply by dedicating themselves to a single specific field. From that perspective, when building one's expertise within this fragmented landscape of knowledge, it is perfectly natural not to know much outside of your own specific layer.
It seems to me like two things can be (and are) true: programming can be hard in absolute terms, and is also the easy part of the thing that we call “software engineering.”
> 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.
For most people sure. I’ve had GC kill a service in production, or even just tank p99. And I think a decade of C gives you a massive head start with rust. Less screaming “WTF WHY?” at the compiler anyway.
> I don't mean to imply there are no developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder, tho.
This is a specific attitude I try to beat out of juniors. You will not be dismissive of the point of this exercise.
It is usually forgetting that everything can fail and will fail. And I mean everything. If it shouldn't fail it will at some point. And you should take that into account. And we usually don't until third or so time...
Great article. Nice pragmatic and cool-head take on what is going on. Thank you for posting this.
Side note: I so forgot about the "Don't make me think" book! Thanks for reminding this exists. I submit this should be part of "Software Development 101", right there alongside SICP.
The author's primary misunderstanding in my opinion is that time consuming is being conflated with hard.
>If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
There is more to those roles than just coding. In fact the more expensive "programmers" often do not code themselves.
>Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs?
Something being time consuming is different from something being hard. There are simple factory jobs that also demand overworking.
>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?
Building software takes time and since velocity is important companies wanted people who could increase velocity.
>If coding is easy, why do we have doorstoppers like Clean Code and The Pragmatic Programmer? Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book? Why do we have bootcamps or even whole college degrees dedicated to it?
So authors can make money? Programming is learned by a ton of kids on their own there is no need for boot camps or college degrees just for the benefit of being able to program.
If coding is easy, was Carmack just at the right place at the right time? Why do we consider Fabrice Bellard a genius?
The earlier you are to a field the easier it is to have your impact recorded. In markets with first movie advantage being earlier also helps a lot. A lot of people were able to program so what made them earlier than others was not just being able to program.
>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?
Again something being time consuming doesn't mean it was hard.
>If coding is easy, why do many now feel like their identity and professional purpose are being stripped away from them?
When you spend a big percentage of your life doing something it becomes part of your identity regardless of difficulty.
>If coding is easy, why is software so damn buggy?
Because making bug free software takes a lot of time and resources. Those resources have a higher return on investment elsewhere.
>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?
People are clueless because it is hard. Pay is not based off of difficulty.
>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? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers?
Because the company finds it cheaper to outsource? A ton of companies have their employees setting up and using telemetry to understand their customers so it's not a one dimensional thing.
>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!
Programming takes time and resources. These may have a higher return on investment elsewhere than this niche feature. It may make maintaining the entire product take more resources to support a niche feature.
>If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out?
Again building entire products takes a lot of resources. And 10x the cost of building every product is not going to be competitive in the market.
Code is the hard part if you are John Carmack or in a similar position where you have to squeeze every drop of performance from a hardware. That is the minority of programmers.
Maybe the author has a skill issue, as they conflated "software engineering" with "coding".
It is all the parts of maintaining the software with time and engineering with all the moving parts (not the coding) is the point of why software engineering exists.
It's more accurate to say "code was only the worst bottleneck in a multi-bottleneck system". The second-worst bottleneck has been promoted to first. And it might be only marginally better.
Code generation was never the hard part. Knowing wtf you’re supposed to actually write was always much harder and this hasn’t changed. It’s not hard to write a loop or an if-statement. It’s hard to actually solve a problem with them at production scale. Carmack’s Fast Inverse Squareroot is not hard to write - it’s hard to figure out how to even do one in the first place. Writing it out is the easy part.
Claude writes 90% of my code but the bottlenecks always were and still are:
* getting clear requirements from product
* getting the damn code reviewed so I can merge it
Neither of these are fixed. Frankly, overuse of AI has made both of these worse. Claude brained product owners going hog wild with Claude Design are a nightmare to deal with, and the volume of absolute trash quality code being submitted for review is soul crushing.
No, using AI to automate code reviews is not acceptable. Code Review isn’t about a systematic checklist (though they can help) it’s about making sure people understand the actual changes being made to the system because it’s people who are accountable for what happens in production. LLMs can be part of the process of reviewing code but they suffer from the same issues as any other chatbot based tools (hallucinations, context confusion or not enough context, getting bogged down in impossible code paths or other minutia, etc…) so you have to review that review carefully too. Human judgment is still king.
These days my job is primarily reviewing offshore slop and making sure it’s in a good enough state to merge. I’m doing merge and release management way more than actually coding (and it sucks btw because I actually enjoy coding with or without agents). If the quality of the code turned in for me to review and merge is any indication, engineers/system architects are going to have their hands full.
It's a strange choice of something to take personally. It doesn't mean code is supposed to be easy for everyone at all times, just that past a certain point of your own personal path towards mastery the utility of not having to write code diminishes and the complications of delegating rise in proportion to the shrinking gains.
> If deciding what to build is the hard part, why do so many product managers seem clueless?
The divide between product managers and developers mimics the artificial divide between humanities and STEM.
You divide workers into competing groups, then make they outperform each other.
In reality, practically all humans can both become excellent coders and acquire deep product skills as well. We can also learn a wide variety of other skills in a single lifetime. The only blockers on that are social and psychological, you're meant to not believe that is possible.
All this talk about code in this adversarial role with product comes from that, and all of it dissolves under almost any valid critical angle. The engagement with this kind of discussion takes place exclusively in that aforementioned social layer.
Making software is no longer very hard. It's becoming a few steps up from burger flipping. Maybe somewhere around line chef.
There's still some skill involved, but the skill is mostly in manual testing, and accurately phrasing what went wrong. The AI is better at debugging than people are, and the code isn't great, but perfectly adequate for pretty much everything. And it's even fine at system design these days.
It's interesting realizing how mind numbingly thoughtless my job has become.
Don't get me wrong, I wouldn't mind it if this was skilled work, but it just isn't.
Interesting take. Can you link us to your (correct, maybe even formally correct) AI-generated software? Given how general this post is, I assume you wouldn't mind if I extend this to, Idk, aviation or spaceflight, so mind linking to any GH repos you have where you've written code to work in environments like that? I ask because all you said was "making software" and didn't say what kind of "software" we're talking about.
Since you apparently work on this kind of software, here's a challenge for you: take the last several bugs that were reported and paste them into Fable, pointing it at your code.
How long does it take? Does it find the issue? In more or less time than the engineers took?
Ask it to review your code for design and cohesiveness issues. How does it do?
Sorry, but we aren't talking about me here. You were the one who made the claim that AI pretty much makes making software trivial nowadays. Specifically, you wrote:
> Making software is no longer very hard. It's becoming a few steps up from burger flipping. Maybe somewhere around line chef.
You did acknowledge that "some" skill was required:
> There's still some skill involved, but the skill is mostly in manual testing, and accurately phrasing what went wrong. The AI is better at debugging than people are, and the code isn't great, but perfectly adequate for pretty much everything. And it's even fine at system design these days.
All I asked was for you to back this up, since the burden of proof is on you to prove your claim, not on me to prove it for you.
Can you link us to your git repo(s) and/or other artifacts that demonstrate this take? I and many other here I think won't agree, and we mostly love being taught.
I believe there are some programming jobs in which the code is absolutely the easier part. Not all of us work in signal processing, integrated systems or have to push upstream to Linux kernel because the company we work for really needs a memory allocation optimization for its data centers.
Navigating customer requirements and building something that satisfies both market's needs and company strategy can be an incredibly difficult and frustrating problem to solve. Especially if you need to also oversee the execution of the strategy. So not only you have to predict what they want or know the domain deeply enough to understand what they say they want is not what they really want, you also have to come up with a plan for executing your solution in a corporate environment.
There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, establishing support for executing a plan or creating alignment on big efforts. In large corporate environments with multiple international customers, code is most of the time not the hardest problem.
Yes, I resonate with this and the article above.
I think 80% of a SWE's job is to communicate with the XFN partners (either gathering requirements, pushing back, managing up, collaborations, etc) and then plan out the actual coding (gather code pointers, look at past code, plan architecture, talk to the team). The last 10% is the coding. And then the other 10% is the maintenance of that and past code (which honestly should be a lot more but incentives are not aligned well).
It's hard for people to understand jobs they don't do. They imagine we spend 8 hours a day clacking at the keyboard.
> They imagine we spend 8 hours a day clacking at the keyboard.
I do, but the order of the keys makes a difference somewhat.
> There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, [...]
Why would they cover programming? That's what all the books on programming are for.
Also I see no need for signal processing to make programming a hard problem. Writing correct code is hard. Writing code that makes incorrect code easy to spot and hard to write is hard.
You can be great at local maximums, communication, establishing support for executing a plan or creating alignment on big efforts, and proceeded to still create a ball of mud. Bug ridden, hard to read, hard to debug.
A buggy big ball of mud that does mostly the right thing is still going to beat a high-quality, carefully architected solution that reliably does the wrong thing, though.
And for a huge amount of code, it's not very hard to make it good enough, because the requirements, once understood, are pretty straightforward and perfect correctness often matters much less than you would think.
What a grounded take on this and wished more people saw it this way
Just yet another case of people seeing only the extremes and not the entire spectrum
You nailed it: in a corporate setting, code is definitely not the hardest part and it’s why companies can sometimes make do with a skeleton crew of offshore engineers who make $20-$30 bucks an hour
The way harder part is building the right thing and just designing the thing soundly to begin with
This type of software is where AI absolutely kills it - problems with tons of forum posts, writing code for systems with a ton of various kinds of quality developer documentation
On the other hand, if you’re doing something novel or sending a $10bn machine to mars, you probably don’t want to yolo it with AI
> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
Because programmers have generally been forced to wear additional, invisible hats that are essential to making the code happen in the first place.
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. Either directly or worse. The gigantic salaries paid to the most prolific employees is not due to their ability to write code. It is due to their ability to interrogate the shit out of the customer until they finally reveal the true requirements.
> 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.
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.
Not really. In those safety-critical areas, the code really is no different. What is significantly different is the surrounding process.
I had to make some software changes to an old medical device this year. The overwhelming majority of the effort was understanding what the customer wanted and giving them feedback into how that would change the existing system and the risks associated. Then, creating a plan to follow the necessary standard (IEC62304) and creating the associated documentation and getting it reviewed and approved.
The actual code that changed was probably only around 100 LOC but the project took several months. Heck, the code was simple enough that an intern could have done it.
I left out the code on medical devices for a reason! And similarly for avionics software.
(The distinction I’m making is between the code that operates the medical device and the code that operates the app I make doctors’ appointments in. The latter is subjected to a different - and lighter - regime than the former.)
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).
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.
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.
> 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.
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.
Maintenance over time is 90% of the work anyways, you don't start a project from scratch every day
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
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).
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.
> 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.
> The gigantic salaries paid to the most prolific employees is not due to their ability to write code. It is due to their ability to interrogate the shit out of the customer until they finally reveal the true requirements.Bit of both probably. I've seen really awful code in my time, so would say "actually coding well" is indeed one of the hard parts.
But knowing what the real problem to be solved is, is indeed important. (Isn't that what sales is? Working with the customer to tease out the real thing they need solving?)
> (Isn't that what sales is? Working with the customer to tease out the real thing they need solving?)
For any product of any complexity you can can essentially never successfully delegate that process to a non-programmer.
Indeed you can not that often even trust that the client employee doing the asking knows what it is they need. Almost certainly someone in the organisation who was not in the meeting is better placed to tell you what is actually required.
This task needs an analyst; that analyst needs to have experience of writing meaningful code.
Exactly. Writing code is easy. Junior developers do it all the time. Hell, they write far mode code and do it faster!
I go half the speed of a junior developer, but the code I write lasts five years to a decade with an order of magnitude or two fewer bugs and long-term maintenance burden.
I think people also have a natural tendency to assume that the amount you are paid is correlated to how difficult the job is, which isn't quite true. The market value of a role has a lot of additional factors besides how intrinsically difficult the actual job is such as supply and demand and the funding source. Programmers may have been able to demand high salaries partially because the explosion in demand came faster than the explosion in supply.
While it is true that a programmer's job is a lot more than writing code, I also wonder to what extent that businesses will actually be able to tell a good programmer from a bad one. For example, a lot of folks at big companies can honestly get away with being a ticket-taking code monkey because so much of the responsibility has been abstracted away so that they don't actually get punished for not caring about the customer. It's sort of similar to how many schools realistically wouldn't care to distinguish between a teacher who puts in extra effort into their classroom versus one who clocks in and clocks out as long as some bare minimums were being met.
I think strong programmers will get rewarded in the right companies that need them, but it's still an open question as to how many companies exist that have their bottom lines actually depend on a programmer doing a good job at wearing all those extra hats.
nope, I've definitely worked on a lot of projects where knowing how to satisfy the requirements was not the challenge, writing the code was genuinely hard. complex data structures that had to have invariants maintained, distributed access to shared memory, dealing with various forms of fault tolerance, and above all getting some complex algorithms to run at an acceptable speed - all that really does get bottlenecked on the difficulty of the specific low level code you have to write. and then there are the architectural issues that make all the difference not when the code is first written but months later when you want to add another big feature and find out that fitting it into the existing code base is hampered by the early decisions you made. I'm honestly glad to have LLMs to help with a lot of that, though I'm also glad that I built up the skills to do them myself over the last few decades and am a little sad that programmers today will not build a lot of those skills up.
Knowing what to write in the first place is the hard for me, and always has been.
Building on this, as evidence:
If you have shop where you have the best product-owner in the world, and exact clarity on how you want to build something, how all failures are handled, all the tradeoffs, all the implementation details, all the risks, then product is simple, then your company absolutely can get away with hiring a less than top-tier engineer.
However if you're combining all of those skills/roles into one individual (a staff+ engineer) then of course it's going to be expensive.
In my experience the only people who get paid "well" to just code up well defined JIRA tickets are new grads, and this is essentially a training period until they grow into leading complex and ambiguous projects independently. You can't hang out there more than a few years.
> Either directly or worse.
Wow, some "the killer is calling from inside the house" vibes right there. But I totally agree that the game of telephone has always been _an_ issue - maybe not _the_ issue but certainly a big one.
> Writing code is not hard. Writing correct code is.
Dude.
Writing correct code is the whole process. If you're defining coding without care for correctness, of course you can write it off as not the hard part.
“The best code is the code you didn’t have to write” - a wise coder
The point of the OP in this case wasn't code that compiles, but code that does what the customer wants. If the customer orders an email client but really wants a chat application, coding a working email client is not "correct". And insisting that the customer ordered the wrong thing won't change the reality of the matter.
"Correct" does not just mean "compiles" (syntactically correct), for one thing.
Correct code is that which does what is required of it at whatever level of correctness you are examining, as was said. But it's the whole thing.
There is no sensible distinction to be drawn between writing correct code and merely writing code. The former is the only definition.
> The gigantic salaries paid to the most prolific employees is not due to their ability to write code. It is due to their ability to interrogate the shit out of the customer until they finally reveal the true requirements.
That doesn’t describe any devs I know, especially not in the old days. Interrogating customers and bringing back requirements was the job of management (who got big salaries, too.)
That has only been true in the largest corporation I've worked for (around $4bn annually). Even then, we (devs) had to challenge inconsistencies in requirements or incomplete specifications. The only job I've ever had where I could just do exactly what I was told and get away with it was right after I got out of college.
Agree. What a strange perspective. Engineering is what is hard, and that includes coding and non-coding activities but doesn’t require customer interrogation.
That job was often called a "business analyst" in "the old days".
Not in agency or consulting jobs.
I think you're confusing product and engineering. I get that programmers are smart so we just assume we can do every job, but it's a waste of your time and salary to talk extensively to customers and create product requirements. Let the PM's run the user research sessions, you can find more productive things to do.
However, where we agree, is that there is more to engineering than writing code. It's problem solving. Even if the product team, the c-suite, the board, the investors, et al, are all in on a product that they believe customers want, doesn't mean the real problem of bringing that idea to life at scale has been solved.
Product should, definitely, run user research along with Product Design. But what I find is that people in either have a problem imagining a solution that's a couple of orders of magnitude easier to build, but also much easier for our customers (usually boils down to making the right choices for customers — the savings are not in the common "choose good defaults", but in actually removing flexibility that's needed only in 1% of cases).
Thus, I insist on engineering being involved early to put real world constraints on wild ideation ("it would take 3 months for 5 engineers" quickly changes what's a must-have :)) — sometimes, a curious, critical mind can expose things like these without having to do the research or user testing themselves.
Now, throughout my 20 year career, it's been very rare to find a product person who will both understand customers deeply, tie their needs to business value, and be able to formalize the intersection of these in a form of good requirements for design and engineering to eventually build!
So I really believe an engineer's (and design) role there is to serve as a sanity check as they dive into actual building — does this really make sense? If they do not, they run the risk of a project completely failing or perhaps not even shipping once someone else questions the value of continuing to invest in this 3 month project 9 months in. ;-)
>Writing code is not hard.
Writing code has a minimum IQ requirement; a significant fraction of the population will essentially never be able to code by themselves. That labor supply limitation is what's kept programmer salaries relatively high.
Writing code doesn't have a notably higher (if at all higher, vs lower!) IQ requirement compared to some of the basic components of EE or MechE work. Programmer salaries have been driven up by the ability to write-once-sell-globally and the dramatic profit margin difference between that and, say, producing chips where there's a much higher fixed cost due to the need for more real material, tooling, etc. Many of those roles require a much higher-than-baseline-skill, but it pulls up the compensation competition for almost everyone else too. (Though even then there are a lot of unglamorous, line-of-business, internal-tools-programming work that's not paid particularly well even in a lot of parts of the US far from the big tech companies.)
>Writing code doesn't have a notably higher (if at all higher, vs lower!) IQ requirement compared to some of the basic components of EE
Average IQ of Electrical Engineers: 121
https://www.iqcareerlab.com/tools/iq-for-profession/electric...
...which is the top 10% of the population.
https://www.desperateminds.com/blog/iq-120.html
Salaries are a product of supply AND demand. Supply of good programmers and EE/MechE is low because it requires above average intelligence and a lot of education, while demand for software has been much higher than demand for EE/MechE. Now that the demand side might invert.
> interrogate the shit out of the customer until they finally reveal the true requirements.
Or are forced to figure them out.
How can I downvote a comment
After 30+ years in the industry the absolute best programmers I know never spoke to any customers, like ever. so bullshit comment all around. I’ve been coding for 30+, have obscene salary and do not wear any “additional hats” or talk to any “customers.”
Understanding requirements means talking to customers. A customer can be anyone, even other devs that consume your code/product.
“understanding requirements” is as much “wearing other hats” as having hands is “wearing other hats” for a carpenter.
coding is always the hard part, always. whenever I was on any project and we had more work than resource we never hired “people to wear other hats” - we hired people to write code, that’s it. thats the fucking job.
you ever see a leet-code-for-understanding-requirements? yea, me either…
Everybody saying "coding was never the hard part" is really telling on themselves. Coding was never "hard" because most organizations were absolutely unwilling to take on any technical work that was hard. That tells us about business strategy and culture rather than anything about the fundamentals of programming or technical work.
The real conclusion is that programming is such a high-leverage activity that even technically trivial, low-quality programming is immensely valuable economically. That's not going anywhere, but maybe LLMs are going to make it all that much cheaper. (Which is mostly great! But I really don't look forward to the painful debugging and maintenance that reams of shit code will push down on programmers.)
But also, there still is a ton of programming that is fundamentally difficult. That's not going anywhere either. And LLMs are useful there too, but they're currently nowhere near replacing the expertise needed to do novel and non-trivial technical work.
In an ideal world, making mediocre code cheaper should leave more room for taking on harder technical challenges. In reality, this has always been dictated far more by non-technical factors—culture, leadership, trust, risk tolerance...—than by anything intrinsic to programming. But, at least for now, we can use the LLM hype to motivate the kind of deeper technical work that always made sense but was too uncertain or too open-ended or too long-term for non-technical leadership.
And we should also drop the bullshit "code was never the hard part" framing.
Those corporations that undertake the actually difficult bits of programming end up charging so much money, to the point that people go out of to not use them though. Splunk, Oracle Database, Spanner, Datadog, VMware. We don't live in an idealized world divorced from business and money, unfortunately, but worse, software developers are notoriously cheap and hard to sell to. If I did the hard work and made a compiler that generate code that runs 10% faster, I should have a solid business. Even Intel couldn't make a business out of icc though. So the code is the hard part but business is also the hard part and it's a miracle any of this stuff ever gets off the ground.
It is hardly any different from reviewing or debugging the code quality of most offshore deliveries.
I agree, the whole 'developers don't code' AI defense was pretty ridiculous. I also concur that development is going to get a lot harder. Anyone that has successfully used AI coding tools knows that you can get massive productivity increases but now I have to figure out how to get a bunch of hyper active child like coding entities with memory deficiencies to build stuff without going off the rail and introducing massive security problems or building something completely mismatched to the requirements. If you can do it, yeah you can get 10x results. But now I am engineering harnesses, architecture specifications, agent structures, statistically sampling, and formal verification systems to guide the code instead of writing the code.
No one seems to mind the quality drop though. The buyers of this stuff could never discern.
I'm definitely noticing, I imagine the populace at large will soon too. I'm not even talking about random software either, the company I work for has more and more fired that need to be put out because people are spamming out ai-generated code that was at best rubber stamped.
Not even just the customer-facing stuff either, the internal tooling is on fire more and more often. It's not sustainable in the slightest
It took a while before the MBA hivemind woke up to this happening because of outsourcing two decades ago.
You forgot "as long as"
... as long as the buyers could never discern
The sad reality is that the vast majority of customers (whoever you are writing software for: clients, management, or end users) simply don't care as much about quality. If you give them the "time, cost, and quality" pick-two choice, 99.9% of customers are going to ask for fast+cheap. It's not the world I wish we were living in.
This is all the stuff that the frontier labs are going to ship by default next year. Except for the architecture specifications, which agents can already do adequately for most system today.
>get a bunch of hyper active child like coding entities with memory deficiencies to build stuff without going off the rail and introducing massive security problems or building something completely mismatched to the requirements
Development is essentially becoming management.
I see this comparison a lot, but I’m not sure I agree. At least not semantically. The list of what an engineer using agents is responsible for, largely hasn’t changed. Engineering managers haven’t changed responsibilities either.
Even with wrangling agents, you’re really just making them right the “correct code”. Something EMs don’t do, or at least the good ones don’t do with their ICs.
It is quite similar to architecture work when others in the team do the actual coding, and lead devs / architects only have time to try out prototypes.
Only now instead of local or offshore devs, it is agents.
I was mainly doing architectural work as a coder long before LLMs came along.
So was everyone else who wasnt slopping out boilerplate.
Code is the written representation of your idea how to solve a problem.
Now you tell someone else your idea and have to hope they get it. Otherwise you have to argue, rephrase, start all over again.
We are back to the tree-swing project management, but we added another layer
> 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 companies resent that they have to take on risk and pay people to extract value from the market.
Ugh, why do we have to pay people to code, maintenance, etc. Lets pay people to extract more value for our bonuses and shareholders. Lets try to only hire heavyweights so that we don't get hung up on that difficult-to-measure coding process, knowledge transfer, messy human-ness. Oooh how nice, we can hire a fewer employees that know how to leverage code agents that free them up to think about that what REALLY matters...
The answer to all these "if coding is easy" questions is that coding isn't programming (to put it in Lamport's terms).
Encoding your ideas into a programming language is easy. Understanding that your ideas are bad is hard.
You have clients with multiple devices connecting to your backend simultaneously, while you mediate their interactions with your partner systems. Their versions might not be up to date. It's a distributed system. When was the last time you cracked open a distributed systems textbook?
When was the last time you built a system and stared reality right in face, that is: - can't trust your clocks - pick 2/3 of CAP - exactly-once delivery impossible - the code will need to be altered and released without downtime - hackers will try to exploit you for fun and profit - your manager doesn't want you wasting time getting the above right
Coding is the easy bit.
Nope, coding was still the hard bit. Every failing programmer would jump into architects or prod management but not the opposite way.
Coding just often has a fast feedback loop. If you can't do it people are going to notice pretty fast. You can fail as an architect or prod management for a long time before people discover you are not good at it.
One thing that is good to have in all those positions is an understanding of the code base and where it can slowly evolve to and how that positions the code base best in the market. I'd say the best way to build this understanding is still to build parts of the system yourself. Not talk to experts or agents about the code base.
Usually you don't have an option other than leaving, most organisations don't let seniors keep coding and nothing else.
Either move up the ladder or leave.
Non-coding architects were typically a by-track rather than superiors to ICs. Though I imagine some of them could think they were. Product managers also often don't have proper reports in the sense line managers would.
Those computing ideas (like distributed systems, concurrency and task scheduling) can even be found in even a single program/system. They are often entangled with even broader concepts, like visual layouts, security (authentication, authorization), communication and encryption, control systems, signal processing,… And those are often accidental complexity.
The essential complexity can be easily resolved by talking to domain experts. You will get a nice requirements document afterwards. That’s when the engineering and management concerns appear.
You seem to be misunderstanding the premise of the statement. Go write, "print 'foo';" and copy and paste that statement one hundred thousand times. Congratulations, you just wrote one hundred thousand lines of functioning code! Was that hard? No? Okay, so how is this different from other code? The difference is that it's easy to _understand_ how that code works, because it's the same behavior repeated over and over. So, writing code is easy, but understanding code is difficult! And, when we code with AI, undertanding is precisely the part that it can't handle, even though that's where almost all of the value is!
> Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book?
I still read TAOCP occasionally as a hobby. The combinatorial algorithms and data structures are just fascinating. That said, this argument seems irrelevant to majority of the programming jobs. I doubt most engineers will ever need to implement anything mentioned in TAOCP, thanks for all kinds of powerful abstractions.
I agree with the author that coding is objectively "difficult" but this is something I am good at, while dealing with people, changing requirements, bureaucracy, and maintaining work relationships I find challenging. I always say coding is the easy part of the job (for me).
The author's main thesis, that coding is hard, conflates what an individual finds easy or hard, with what is easy or hard for an average person.
Coding while definitely not easy, it was never the hard part.
The hard part has always been how to solve x problem. Coding is the last piece of that part, which while not easy is not the hardest.
The art of computer programming books are not about coding they are about computer science, i.e. figuring out how to compute solutions to problems.
Figuring out what to build is definitely not the hard part though.
>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? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers?
Because they're not the ones deciding it, they just provide input for the Heads/VPs/managers who make the strategic decisions. And they are paid pretty well for this.
> 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 rare.
It seems the author has misunderstood the point of the common narrative and has torn apart what’s essentially a strawman.
The degrees, the books, that’s not the supposedly easy part. That’s the HARD PART, and it’s actually the “what you build” thing. What you build is the code architecture, knowing how to conjure objects, methods, modules, lambdas out of thin air in a way that faithfully represents a real-world problem. Literally the shape of the resulting code. It’s not product or CS.
The easy part is supposed to be actually typing out the code, putting the methods together, remembering method names and syntax quirks.
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.
I guess my impression using these tools daily is that it hasn't diminished the need for my own technical expertise. The conversations I have with it are highly highly technical, and to me the insights come from both sides, I see things the LLM doesn't, and the LLM sees things I don't. It writes a lot of bugs that I have to spot, and writes designs that aren't correct. (This isn't a criticism, I do the same). I think the ideal world version of this stuff is complementary, but the current insane bubble economics mixed with the insane religious fervor make that unpalatable to the leading AI companies. (Like, I think Sam Altman said that anything below a trillion dollar IPO valuation is a "non-starter".) So, "nice coding tool", even if that's the BEST and most realistic outcome, is just not going to do it for them.
Yes, writing code that (appears to) work was not the hard part. Even before LLMs you could find very cheap contractors on Upwork or through offshoring companies to write "code".
Well-engineered code is hard. It still is. Code that is reliable, extensible, maintainable, scalable, legible, understandable is hard. Code where the specs and the "why" behind it were pressure-tested via thought and good intuition.
One of the strongest teams I worked with, working on an extremely large and ambitious project used to answer a lot of product/executive type questions regarding missing areas that we knew how to author and could safely assume general design consensus “it’s just typing”.
It was a very useful contraction in the right senior circles where there was a pretty good understanding of the meaning and decently reliable assumed consensus.
I eventually stoped using the phrase because it had started leaking deeper into the team and the impact on earlier career or less confident programmers was often no longer positive, it could be misinterpreted in lots of different ways but the most harmful was when it would further decimate confidence and discourage requests for help when something wasn’t obvious to the ultimate author.
As with almost every attempt to generalize in software engineering the repetition or extrapolation beyond the context in which it was intended can have negative side effects, it doesn’t matter if it’s a simple notion like “dry”, or a comment like “code was never the hard part”. None of these phrases survive context loss and still retain efficacy at general receivers.
He is right though Coding was hard for many.
Farming was also hard, manual work wise and now machines overtook. It's still hard because of marginalization.
It will happen to Coding, Consulting, Creating work, etc as well.
Starts with a rant that appeals to hardcore programmers and then tells them to adapt.
Of course he is an AI consultant among other things.
OP here. You're absolutely right, I just want to add that "other things" include being a programmer since the nineties :)
Edit to add: instead of "adapt" (which would imply "embrace AI", which I didn't say), my intent was more along the lines of "be adaptable."
Is what he said wrong? Why don’t you attack his argument rather than his background. Not snark. I want to see the holes in what he says and I literally don’t care about who he is.
You must be anti ai among other things.
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.
It's not even about the degree. Fresh computer science graduates already know how to code but can't do the senior developer stuff.
https://www.nair.sh/guides-and-opinions/communicating-your-e...
That depends on the quality of the degree. I was well served on my Software Engineering degree, coupled with the trader school in computing I went during high school.
Then naturally seniority teaches office politics, and what to actually invest time on.
Well said.
Oh really? I thought the language needed to be ALGOL on a Burroughs B6700!
If it solves the business case. A proper engineer would actually recognise that should be NEWP in 2026.
Coding is easy if you enjoy doing it, met plenty of professional programmers that hated it and never felt the desire to improve. To them it was a way to get a paycheck that paid reasonably well.
Better to have a job you don't like that pays well than to have a job you don't like that pays poorly. But at the same time - if you're smart enough to program well enough to get paid while hating it it's such a shame to not find something you enjoy that will still pay you enough.
LLMs are the invention of the loom. Code is being industrialized.
Yes, there always will be artisanal weavers and a smaller number of them get paid a lot more money to do this by people who can afford it. Everyone else either started operating a loom or did something else.
Automated looms are now making mass amounts of textiles but the artisans are no longer doing the physical act of weaving. The artisans come up with cool designs, get feedback from customers, solve people's problems and outsource the rest (physical labor).
We are in the loom moment. Are you designing things people want? Are you doing the weaving? These two paths can coexist but they are diverging disciplines with diverging difficulties and diverging value.
Typing code into a computer is rapidly becoming physical labor now. The layer of creativity and problem solving is quickly rising to a level above the code since the code is a fluid now that comes and goes easily.
Art, Bespoke, Artisinal, Mass produced, Engineering, Aeronautical Engineering, Aerospace Engineering, Material Science.
Mass production is certainly here for the majority of programming jobs. The competition for the jobs that are left will be intense, but most simply won’t make the bar. Someone said elsewhere “It’s no different than ordering a pizza: I don’t do the work.” Yes. Pizza is automated now. But no pizza employees are coming for my job. When the AGI comes for my job, we will either have post-scarcity utopia or more likely we’ll all be dead.
Easy on the cocaine. There are no credible AI code bases on GitHub.
nah. my company (not a tech company)'s stack is ai generated and it has created credible value.
It seems so obvious that a non-tech company can benefit hugely from AI for their bespoke use case, especially if no one in the company knew how to write code pre-AI. But it's also easy to put some planks down across a stream and call it a bridge, that doesn't mean it's built well, going to last, or that there's no longer a need for structural engineers and architects.
These comments reveal a stark reality: most HN commenters have never worked on a really hard problem. They think hard problems are leetcode hards that have a prescribed list of known techniques to apply.
They think communication, alignment, gathering requirements, and other political bullshit is the hard part because they have never actually solved or had to grapple with a truly hard problem.
That’s fine, but it shows the corporate programmer who is probably in meetings all day has a vastly different reality than those of us who have had to solve open problems with no solution written somewhere because there is none.
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
do you know how many eBay clones were out there after Ricardo? how many people built twitter clones? building the website was never the hard part, making people get to it and use it was always the costly and hard part. nobody talks about embedded device programming when they say code was never the hard part.
"The labor is valuable" is basically the refrain of every single laborer in every industrial revolution.
The point isn't that labor isn't "valuable" it's that "value" here is a moral position. This same thesis could have been said about basically any mechanized industry.
There is no putting the genie back in the bottle. You can't un-invent the nuclear bomb, or the printing press, or the steam engine. We need to find a politically stabilizing way forward, and that means we need political coalitions that don't consume themselves with infighting.
Right now we can't even work together to build housing for young people... how the hell are we going to get through this mess without actually trying to build something bigger by making sacrifices.
Coding is not programming.
Typing code is indeed not the hard part, programming is.
Writing code to do a thing is easy.
Writing code that's logical and easy to follow, that can be extended in several likely dimensions without major plumbing work, and that doesn't contain "gotchas" for the maintainer, is not at all easy.
> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
There's probably a lot wrong with the "coding was never the hard part" take, but this quote right here shows that the author is not willing to engage with the actual idea that folks who say this are espousing. Because if the author was discussing these ideas on good faith, he'd know that the answer is obvious: there's much, much more to a software engineer's job than just coding, and that other stuff is very hard to do well, and people pay for that.
Again, I'm not saying the "coding was never the hard part" folks are right, but I really, really hate straw men.
I'm not insulted. I actually agree with that even when I was doing some more "hardcore" low level system programming.
Figuring out what code to write and what not to write was always hard.
The code would come out easier the more time I spent thinking and designing and talking about it with others.
of course, YMMV
Coding is just a small part of a modern software engineers job. And some may think it isn’t the hardest part.
> I don't mean to imply there are no developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder, tho.
Well, this is also an insult.
Cleanest way I read this is seeing how basically none of it makes any sense for someone coding as a hobby, or in any non-business context.
This is not an article about coding, it’s a promotional piece for business stakeholders.
Almost all of us would agree if this was just better articulated:
"Code was never the hardest part."
There you go. Doesn't imply that coding is easy.
To some degree the defense just popped up because it’s part of the AI effect, at least in my opinion: https://en.wikipedia.org/wiki/AI_effect
As computing systems become increasingly capable and encroach in our territory that distinguishes us and lead to our success as a species, intelligence (whatever that is or isn’t), we redefine the problem and handwave away the new capabilities.
It’s getting increasingly more difficult to do that in knowledge domains with current frontier agentic systems. They’re not AGI, but they start to make it increasingly difficult to move the goal posts for many people’s comfort.
We really need a lot more philosophers, sociologists, and frankly economists working on this problem: in an era where physical needs were mechanized away and increasingly aspects of the knowledge economy are shifting away, what does it look like in modernity? How do we sustain or adapt our current economic models? What new models may be needed? Do we need to continue to enforce this whole work to survive in an environment where much work is disappearing or at the very least shifting around.
No, we’re not there yet. You still need experts to guide things around, but it’s becoming increasingly easier to do more in this space with less humans. That’s not a trivial change in the US where we put most our eggs in this whole knowledge economy basket.
Unpopular opinion: I fully believe that anyone who says "code was never the hard part" was an irresponsible coder who perhaps never had to work for themselves.
No matter how long you spend on architecture, no matter how carefully you plan your features, if you are an actually good developer there are choices that emerge only from the first draft of the code — things that you could do better, broader ideas that suddenly emerge and change your view of your own work, abstractions that become possible once you internalise the project through writing it, realisations that a requirement is unscalable, unworkable or unsafe, etc.
Nobody ever finds all those things only in the planning stage in any piece of code of consequential size or functionality: if it was easy, we'd all be doing waterfall development like 1970s consultants or using StP like 90s consultants, and none of those other ideas about coding would ever have emerged.
LLMs will just write the code. They will never have the rest of that experience. And I think any coder who doesn't have a visceral feel for what I said above is just bad at it.
"The code was never the hard part" is just edgelord AI evangelists masking denial with a pithy mantra. The code, its capabilities, the tooling choices, it's all indivisible from all the other hard parts.
But then these are often also the people who think they can use AI song or image generators to do the bulk of the work and "add the finishing touches". They also think "taste is all that is left" when the thing that gets us paid is not just our taste, it's our responsibility for and to our work.
A pretty weak essay.
The arguments are couched in questions… which all either have ready answers or imply strawman arguments that few are making.
I suspect it’s emotional and indirect because the author understands how poor its arguments are. That leaves open the question of why do the blog post at all, but I guess bloggers have to blog, whether or not they’ve got anything to say. An angry, emotional, vague post probably gets a nice amount of views.
long said that success is 1% idea, 9% implementation and 90% other stuff like marketing that I don't care about.
> If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out?
Because it is hard. :). Writing good code - takes years of practice.
"Code was never the hard part" misses the point but so does this blog post. This blog post from 2011 is worth reading and really cuts into the middle of the dreads-of-programmer.
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
Good post!
That patio11 post was good but you're overstating its relevance here by suggesting the thread's central topic is missing the point. The fizzbuzz part even undermines the "Code was never the hard part" message. If code was never hard, why has it always been so difficult to find talent that can do the most basic of tasks with code? Why was it considered a good average for programmers to only bang out 1000-2000 lines of code per year, measured by observing a team over 15 years, when it was well known even back in those days that skilled programmers could produce a lot more, and deliver even more business value quicker?
Besides, there was a whole back-and-forth among multiple bloggers and comment sites (including here: https://news.ycombinator.com/item?id=3170766) from back then in response that agreed or disagreed with that patio11 post. Here's one: https://web.archive.org/web/20111126183459/http://www.jacque... Here's another (though a couple years later): https://yosefk.com/blog/do-call-yourself-a-programmer-and-ot... From the second one's conclusion:
> When I introduce myself, I usually call myself a programmer, regardless of my current work on chip architecture and management and stuff. I got into programming for the money, so it's not like I'm overflowing with pride when uttering "programmer". I just think programming is a great career and the right thing to call myself for me.
> There's an alternative approach where you program, but you don't call it that, and you use programming as a starting point from which you transition to some form of being involved in business as directly as possible.
> It sounds a bit roundabout to me – why not just get an MBA instead? – but maybe it's the right path for some (especially considering that some prestigious MBA programs want you to have industry experience before you can even enroll.)
> The important thing is to choose the path that suits your preferences, follow it consistently, and realize where your approach is most likely to succeed. Because where I work, someone applying for a programming position and not calling himself a programmer will not make a good impression.
Sometimes calling yourself a "Software Engineer", or focusing on "$X company revenue definitely attributed to my efforts" rather than the technical details, is the right thing to do. Sometimes it's not. In any case I'll continue explaining to outsiders that "software engineer" is mostly just a fancy term for "programmer", and to programmers to call themselves whatever they think will best give them a chance at working where, on what, and for how much money they desire.
TBH the "don't call yourself a progreammer" part of this blog is the least interesting part of it. It's decent or awful advice depending on the person.
The more interesting part, to me, is the 15 year old recognition that programmers' jobs are to replace other workers. It's definitely not a new thought at all, but it's interesting to reflect on considering how the dynamics are starting to turn the other way around.
Saying this as someone who knows many programming languages... but I don't consider myself a programmer because that's too job-oriented. Like.. I write code for fun and "programming" isn't fun.. it's a living. This approach has let me follow multidisciplinary paths by framing my career away from the code-as-my-product mentality.
> There’s nothing wrong with this, by the way. You’re in the business of unemploying people.
Occasionally I see a tech person in SV upset about AI automating away jobs. My dude, your whole job is to automate away jobs.
I think there is a de-facto distinction between different kind of programmers, we just need a clear names for them. Like, "builders" for folks who ship products and see code as an annoying intermediate step and "engineers" for people who build technically sound software.
Or put differently: code as a means to an end vs code as the end. You need both types, the ratio changes as things change, neither is The Way.
whenever someone says this I assume they mean a crud react app which is a small part of what 'coding' encompasses
I always said programming is 80% thinking and only 20% coding.
nothing has changed since then.
Business has detested IT forever. It is basically considered blue collar work they felt held hostage to as it was 'brain' based instead of 'muscle' based, and it threathened to expose the grift of clueless "management" (not all is). They yried to placate with CTO, and l created tech diluted CIO and CISO titles for themselves, but the fear and loathing is as strong as ever.
This is dishonest. Nobody said "coding is easy" in a void. They said "code isn't the hard part" - in the context of LLMs. The obvious implication being that the actual speed of writing code wasn't the bottleneck. The implication is not that it's easy to think of what to write, or that any of the other parts of coding are easy.
I feel like you're getting hung up in semantics such that your essay doesn't say the obvious: coding is "easy" relative to confidently knowing how and what to do next at every stage.
The comparison does not imply that coding is an easy thing to do, just that it's easier than being really, really good at the bigger picture.
What Carmack did wasn't hard because writing C is hard.
This is the kind of thing where everyone just talks past each other because "coding" can refer to a ton of different things. I think we've all had the experience of having to write large mechanical boilerplate or refractors which was definitely highly automatable coding. I think we've also all has the experience of being utterly dismayed at how hard it is to write certain logic, especially with LLM "assistance". I've spent the last couple days marveling at how consistently fable introduces race conditions into a complex state machine I'm maintaining. Coding can be hard, or easy sometimes
Is it just me, or is this article arguing against a straw-man?
Isn't the real argument that "writing code is not the hard part"? As in, reading and understanding is the hard part. Figuring out what and how to change is the hard part.
Writing is the last 1% that happens after you have already finished the 99% of talking to people, figuring out what needs to be built, building up context about the codebase and surrounding infrastructure in your heard, planning the actual changes.
That quotation is coming from programmers themselves.
Managers and execs aren’t saying this it’s the programmers and coders themselves making the claim that coding was never the hard part.
It is still an insult though. It’s an insult to themselves. It’s the lie all programmers including me tell themselves as reality itself insults us. Coding WAS the hard part.
That’s exactly what we were good at. Now our skills are getting owned by automation. How do we face reality shitting in our faces? We lie. We fabricate a reality that’s more acceptable. We frame our environment in a way that still validates our existence. If AI has invalidated all of my programming skill then I need to find something else to support my identity.
No, code was always difficult.
To be precise, it depends on the domain. The people who could actually write algorithms or core implementations were always a minority. Programmers like me mostly did copy-paste from Stack Overflow or assembled libraries.
It's not that code wasn't difficult—it really was.
In CRUD apps, about 70~80%of the work was building the same thing over and over, so once you got familiar with it, most of it was repetitive practice. But the number of people who could actually create something new was always small.
Most business programs had issues that arose in the application stage, the application layer. In this application layer, only a very small portion involved difficult logic. Most of it was just applied.
The problem is that people often romanticize the lower layers beyond their own, compilers and low level systems, calling that 'real programming,' and in doing so, they make programming seem harder than it is. In reality, the coding that most people make money from is mostly at the abstracted layers. The infrastructure beneath those layers is owned by giant corporations. If you work at one of those giants, that's fine. But beneath them are countless consumers paying those giants, and the coding that targets those consumers isn't that difficult.
In the end, whether coding was difficult or easy depends entirely on which layer you're working in.
What's certain is that coding was difficult, and it still is.
If you’re struggling at formal thinking, coding will be hard for you. I’m not talking about designing software with higher concepts, like thread, network IPC, web application routing, gui,… but more simpler one like basic data structures (list, tree, maps, graphs,…), algorithms (search, sort, balancing trees,…), and paradigms (procedural, functional, oop, relational,…).
I’ve met a lot of programmers where those concepts where only words and not something they have understood. A snippet of code is either something they have to learn or copy, it’s not something they can fluently manipulate. It’s the difference between having to use a dictionary and sample phrases and speaking the language fluently. The former is a chore, while you don’t even notice the latter.
I resonate with much of what you have pointed out, but I have a different perspective on certain parts.
Software consists of various layers, and everyone has their own specific areas of strength. For instance, because I am an application programmer, I often need to write code that prevents the program from halting—aligning with recent programming trends that involve preserving the computation context using monads. In other words, my strengths lie in the overall architecture and interface design. This fundamentally relates to cohesion and coupling. I excel in this area, particularly when dealing with codebases around the 60,000-line mark. This is a realm where books like Clean Code are quite effective (many people dislike it, but it is actually a well-written book). Put differently, I possess the ability to mass-produce software (regardless of absolute quality). Over the course of 7 years, I have built CRUD applications for 43 companies across 16 different domains (ranging from drones and golf simulators to tax SaaS and supermarket POS systems). Therefore, I believe I have at least an average, solid capability in this regard. The primary area where I actually made money was PLC, so while I may not have deep academic expertise, I certainly do not think I lack capability.
In Korea, the profession known as SI (System Integration) is a field where you enter contracts on a "project" basis. In that environment, I have encountered a wide variety of people. From those experiences, my takeaway is that programming is divided into quite several distinct layers.
To speak of algorithms first: I learned basic algorithms and fundamental data structures in university. However, in the field where I worked, there were many people who struggled to implement those basic algorithms, yet they still built a large number of applications. Why is that? There was even someone who made an amount of money I could never dream of touching in my lifetime. Why did he make so much money when he didn't even know how to implement basic algorithms?
The answer is quite simple. It is because the "implementation model" and the "contract and cost model" are different. The contract and cost model is a self-contained body of knowledge. It is the ability to know exactly where to fit a given piece into the puzzle. Implementation is simply the ability to build that piece from scratch. In fact, mostly due to issues like employee turnover and the organization's future maintenance capabilities, many teams (specifically, organizations with lower implementation capabilities) decide on an open-source library and design their architecture based on its API. In these cases, the primary technical challenge becomes how to connect those components based on the performance of that library.
Yet, people tend to think that only those who can implement from scratch are capable of programming. A person who can take someone else's implementation and piece it together to fulfill their own contract is also a programmer, but people frequently forget this. Depending on which layer you exist in, certain knowledge requires you to implement it yourself, while other knowledge only requires you to understand the contract. I believe this is the core of programming.
Those on the side that must design and build libraries or frameworks naturally have things they must know about implementation, as they are creating the SDKs. However, I have seen quite a few cases where these very people have no idea how their work is actually utilized in the upper layers. And these types of knowledge are highly fragmented.
In my case, I am familiar with quite a few paradigms. On my personal homepage wiki, I can differentiate between OOP, DOD (Data-Oriented Design), and others, and in the context of relational databases, I know exactly where the ORM impedance mismatch occurs. However, this is largely an area intertwined with architecture, and its essence is closely linked to David Parnas's theory of information hiding. In other words: to what extent do we hide the internals, and where do we expose them to minimize the contact surface area and ensure a safe connection?
For example, I can't implement PostgreSQL's B-tree. But I can design a business system using PostgreSQL. I only know the name of TCP congestion control—I don't know how to implement it. But I can build networked applications.
That's what an 'industry' really is. The ability to trust the contracts of other people's implementations and assemble them. The ability to trust others.
In that regard, I agree with many of your points. However, I actually believe the software industry needs more of those "average" people. I think the very definition of an "industry" should premise that average people can maintain their livelihoods simply by dedicating themselves to a single specific field. From that perspective, when building one's expertise within this fragmented landscape of knowledge, it is perfectly natural not to know much outside of your own specific layer.
p.s https://www.makonea.com/en-US/casual/cargo-cult-programming-...
It seems to me like two things can be (and are) true: programming can be hard in absolute terms, and is also the easy part of the thing that we call “software engineering.”
Good article if you read it all.
> 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.
For most people sure. I’ve had GC kill a service in production, or even just tank p99. And I think a decade of C gives you a massive head start with rust. Less screaming “WTF WHY?” at the compiler anyway.
> I don't mean to imply there are no developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder, tho.
This is a specific attitude I try to beat out of juniors. You will not be dismissive of the point of this exercise.
> If coding is easy, why is software so damn buggy?
Debugging is hard.
And people are very lazy; test one ideal path, works, done.
It is usually forgetting that everything can fail and will fail. And I mean everything. If it shouldn't fail it will at some point. And you should take that into account. And we usually don't until third or so time...
Great article. Nice pragmatic and cool-head take on what is going on. Thank you for posting this.
Side note: I so forgot about the "Don't make me think" book! Thanks for reminding this exists. I submit this should be part of "Software Development 101", right there alongside SICP.
Then let the code monkeys be insulted then.
Good riddance to the overpaid coders.
And hello cheap replacements!
The bottom line has improved. And that's good for business. Which was the only thing that mattered. Regardless of any reactionary sentimentalism.
The author's primary misunderstanding in my opinion is that time consuming is being conflated with hard.
>If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
There is more to those roles than just coding. In fact the more expensive "programmers" often do not code themselves.
>Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs?
Something being time consuming is different from something being hard. There are simple factory jobs that also demand overworking.
>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?
Building software takes time and since velocity is important companies wanted people who could increase velocity.
>If coding is easy, why do we have doorstoppers like Clean Code and The Pragmatic Programmer? Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book? Why do we have bootcamps or even whole college degrees dedicated to it?
So authors can make money? Programming is learned by a ton of kids on their own there is no need for boot camps or college degrees just for the benefit of being able to program.
If coding is easy, was Carmack just at the right place at the right time? Why do we consider Fabrice Bellard a genius?
The earlier you are to a field the easier it is to have your impact recorded. In markets with first movie advantage being earlier also helps a lot. A lot of people were able to program so what made them earlier than others was not just being able to program.
>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?
Again something being time consuming doesn't mean it was hard.
>If coding is easy, why do many now feel like their identity and professional purpose are being stripped away from them?
When you spend a big percentage of your life doing something it becomes part of your identity regardless of difficulty.
>If coding is easy, why is software so damn buggy?
Because making bug free software takes a lot of time and resources. Those resources have a higher return on investment elsewhere.
>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?
People are clueless because it is hard. Pay is not based off of difficulty.
>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? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers?
Because the company finds it cheaper to outsource? A ton of companies have their employees setting up and using telemetry to understand their customers so it's not a one dimensional thing.
>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!
Programming takes time and resources. These may have a higher return on investment elsewhere than this niche feature. It may make maintaining the entire product take more resources to support a niche feature.
>If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out?
Again building entire products takes a lot of resources. And 10x the cost of building every product is not going to be competitive in the market.
Code is the hard part if you are John Carmack or in a similar position where you have to squeeze every drop of performance from a hardware. That is the minority of programmers.
I don't think that is true. coding at a baseline is hard no matter what. If it was easy everyone could have done it, and clearly that isn't true.
Now there is hard-er coding. Novel algorithms, performance sensitive stuff, and so on.
Since not everyone seems to be familiar with human communication:
The phrase "X is the hard part" means that X is the hardest part, not that all the other parts are easy.
Maybe the author has a skill issue, as they conflated "software engineering" with "coding".
It is all the parts of maintaining the software with time and engineering with all the moving parts (not the coding) is the point of why software engineering exists.
It's more accurate to say "code was only the worst bottleneck in a multi-bottleneck system". The second-worst bottleneck has been promoted to first. And it might be only marginally better.
Exactly! Try reading a large C code base.
Code generation was never the hard part. Knowing wtf you’re supposed to actually write was always much harder and this hasn’t changed. It’s not hard to write a loop or an if-statement. It’s hard to actually solve a problem with them at production scale. Carmack’s Fast Inverse Squareroot is not hard to write - it’s hard to figure out how to even do one in the first place. Writing it out is the easy part.
Claude writes 90% of my code but the bottlenecks always were and still are:
* getting clear requirements from product
* getting the damn code reviewed so I can merge it
Neither of these are fixed. Frankly, overuse of AI has made both of these worse. Claude brained product owners going hog wild with Claude Design are a nightmare to deal with, and the volume of absolute trash quality code being submitted for review is soul crushing.
No, using AI to automate code reviews is not acceptable. Code Review isn’t about a systematic checklist (though they can help) it’s about making sure people understand the actual changes being made to the system because it’s people who are accountable for what happens in production. LLMs can be part of the process of reviewing code but they suffer from the same issues as any other chatbot based tools (hallucinations, context confusion or not enough context, getting bogged down in impossible code paths or other minutia, etc…) so you have to review that review carefully too. Human judgment is still king.
These days my job is primarily reviewing offshore slop and making sure it’s in a good enough state to merge. I’m doing merge and release management way more than actually coding (and it sucks btw because I actually enjoy coding with or without agents). If the quality of the code turned in for me to review and merge is any indication, engineers/system architects are going to have their hands full.
It's a strange choice of something to take personally. It doesn't mean code is supposed to be easy for everyone at all times, just that past a certain point of your own personal path towards mastery the utility of not having to write code diminishes and the complications of delegating rise in proportion to the shrinking gains.
> If deciding what to build is the hard part, why do so many product managers seem clueless?
The divide between product managers and developers mimics the artificial divide between humanities and STEM.
You divide workers into competing groups, then make they outperform each other.
In reality, practically all humans can both become excellent coders and acquire deep product skills as well. We can also learn a wide variety of other skills in a single lifetime. The only blockers on that are social and psychological, you're meant to not believe that is possible.
All this talk about code in this adversarial role with product comes from that, and all of it dissolves under almost any valid critical angle. The engagement with this kind of discussion takes place exclusively in that aforementioned social layer.
TL;DR weak bait
Making software is no longer very hard. It's becoming a few steps up from burger flipping. Maybe somewhere around line chef.
There's still some skill involved, but the skill is mostly in manual testing, and accurately phrasing what went wrong. The AI is better at debugging than people are, and the code isn't great, but perfectly adequate for pretty much everything. And it's even fine at system design these days.
It's interesting realizing how mind numbingly thoughtless my job has become.
Don't get me wrong, I wouldn't mind it if this was skilled work, but it just isn't.
Interesting take. Can you link us to your (correct, maybe even formally correct) AI-generated software? Given how general this post is, I assume you wouldn't mind if I extend this to, Idk, aviation or spaceflight, so mind linking to any GH repos you have where you've written code to work in environments like that? I ask because all you said was "making software" and didn't say what kind of "software" we're talking about.
Since you apparently work on this kind of software, here's a challenge for you: take the last several bugs that were reported and paste them into Fable, pointing it at your code.
How long does it take? Does it find the issue? In more or less time than the engineers took?
Ask it to review your code for design and cohesiveness issues. How does it do?
Sorry, but we aren't talking about me here. You were the one who made the claim that AI pretty much makes making software trivial nowadays. Specifically, you wrote:
> Making software is no longer very hard. It's becoming a few steps up from burger flipping. Maybe somewhere around line chef.
You did acknowledge that "some" skill was required:
> There's still some skill involved, but the skill is mostly in manual testing, and accurately phrasing what went wrong. The AI is better at debugging than people are, and the code isn't great, but perfectly adequate for pretty much everything. And it's even fine at system design these days.
All I asked was for you to back this up, since the burden of proof is on you to prove your claim, not on me to prove it for you.
Oh. So, because I said I work in software you assumed I worked in safety critical systems?
Interesting. A little unhinged, but interesting.
Anyways, as I said elsewhere, I don't code for fun, and my employer would be unhappy if I sent you their proprietary code.
You can decide to do some experiments yourself, or you can decide that you don't want to hear it. No skin off my back either way.
Can you link us to your git repo(s) and/or other artifacts that demonstrate this take? I and many other here I think won't agree, and we mostly love being taught.
Nope. I don't code for fun, and my employer will be very unhappy if I start sending people private repos.
/s