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.
IDK, a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code. Those performance problems start out not mattering much, first it impacts one seldom-used part of the site, then another, but that chips away at users and can eventually tank the product. That doesn't even get into writing code such that it can be well-understood and modified easily later. It also says nothing about reducing/fixing bugs.
If you have a site whose performance steadily gets worse and the rate of new features steadily declines and the rate of bugs steadily goes up, then your site/app will probably not have a great future.
All of those things depend on solid code. If staff engineers who are too busy talking and building consensus such that they aren't connected with the actual programming and situation on the ground, then all the talking and consensus-building won't matter.
> a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code.
On those complex systems in particular the problems start long before any code is written.
A software engineer can create and understand the specs, requirements, design the system, architectural decisions, define everything about that software and data, model everything, failure, performance, operational topics, documents everything, etc. before a single line of code is written, and of course they can write good code. Then there are the coders who patch together chunks of code from Stack Overflow or whatever boilerplate they have in the company's repository. I know every coder likes to call themselves a "software engineer" but there's a world of difference between the two types.
For the first group code was never the hardest part. For the second group there was never any other part.
I think most people who write code are the latter and not the former. The industry has diluted the term "engineer" so much that they maybe don't even realise that traditional engineering projects are about more than just implementation work.
No they can’t do everything before writing a line of code. The design and requirements feed into the code and vice-versa over and over through the lifecycle of a piece of software.
Some architecture work and design will be done beforehand, but many details will fall into place as the code is being written, thrown away, adapted, etc.
The idea that code is mere transcription - which I see a lot in these AI discussions - is completely false. Code is a form of low-level design and is where the rubber hits the road.
The best requirements, designs, marketing, etc are worth jack if one fucks up the code. The code is the actual product.
Which part of my list was just "a detail" to be dealt with at some point in the lifecycle (but only if you're not too busy shipping features) for you? You're laying bricks before knowing if the wall's supposed to be concrete.
> Code is a form of low-level design and is where the rubber hits the road.
Sure but in keeping with your analogy tires are fungible across most cars and it takes minutes to change one if you picked the wrong compound. It takes years to properly design a tire, not to speak of everything that sits on top of those tires. By the time you actually "meet the road" you already defined to a tee what you want to achieve from every perspective and everything you do is to meet that goal, even if you have to make tweaks. You don't find out if it's a scooter or a roadster tire while working on it.
> The best requirements, designs, marketing, etc are worth jack if one fucks up the code.
Why are you mixing some fundamental things which are essential and can't be changed along the way without massive effort and risk, if at all, with things like marketing?
Do you want to aimlessly write code while chasing a target that moves randomly and conflicting because your plan was to define things "at some point"? You're really making my point with your insistence that it's all about code and every other fundamental thing is "a detail" that just comes along the way.
No part of your list was just a detail, but all parts of the list consist of essential properties and details. As I said, many of those details will fall into place when one starts implementing the core architecture.
It also matters a lot what scale one is operating at. Bigger scale will require more effort up front, PoCs, several big iterations, etc.
To give a smaller scale example, I defined a general simple protocol for two local components, picked the IPC and defined the handshake and teardown sequence. The developer defined the message contents. Reviewed together, then it was implemented. Testing showed that component B, which was OSS and had a fixed rate was sending too fast so the developer patched it to do debouncing.
Coding is nothing like changing tires. To abuse an incorrect analogy even more, the architect would prescribe the properties of the tire or even the behaviour of the vehicle and the developer would design and construct the tires/tracks/whatever either from existing parts or from scratch. Possibly going back and forth on the actual means of locomotion.
To wrap it up. Requirements, architecture and design can be changed. When implementing features I always do architecture review with the team and adapt it based on their feedback. We have rejected or negotiated requirements based on PoC or just developer evaluation.
Sometimes that doesn’t work, sure. If it’s a critical feature or there are hard architectural restrictions one puts in the dev work to figure it out and maybe this leads to a non-ideal implementation.
Fundamental mistakes at requirements or architecture level do have higher impact, but iterating and having a good arch <-> dev feedback loop is one of the best methods I know to tackle that.
To give another example, I investigated the potential implementations for a feature and prepared a list of technical approaches sorted by specific architectural attributes. The dev team wrote the code to validate them and option 1 turned out to be impossible because of platform constraints. I adjusted the architecture to use option 2.
In my experience, the parent's view and your view are an example of the divide between the Silicon Valley / startup mindset -- it doesn't need to last, it just needs to get us a paycheck so we can go on to the next paycheck -- and actual software engineering where people build resilient systems meant for humans to use for a long time.
There's a conflation too that to approach things with this level of thought and care requires waterfall design (it doesn't), so people shrug it off or resist because if you want to think carefully and design thoughtfully you can't also Move Fast and Break Things.
Ironically, we all complain about enshittification.
I would counter with it's easier to fix bugs, improve performance, pay down technical debt than it is to fix consensus, stakeholder buy-in, and strategic direction. So even though good code, design, and architecture isn't easy it's still the easy part in a relative sense.
That’s because fundamentally you need those strategic items to have space to do those particular detail items. If you have the best strategy and no execution, you can probably hire for that. If you have no strategy and decent execution, you are driving the Titanic into the iceberg.
Fixing bugs, improving performance, paying down technical debt all require this as well, which makes them significantly more difficult to actually implement.
Yup. And performance problems don't just bleed the user base, they also slow down development and testing internally, both directly and by nudging developers away from attempting some tests or use cases in the first place.
I can understand when people say the code was the way part, but under the assumption that the system design and architecture are clean, code is high quality or the project is greenfield, and there is proper testing and validation. Then, sure, the lines of code aren't the hardest but that's only because that hardest work was front loaded and given a different name. Even then it's still not always easy.
Getting to a state where those assumptions are true is HARD. And takes a lot of careful programming.
Yes. Once it is true, the code is easy to write. But only because a lot of effort went into making it easy. And keeping it easy is also hard. Without focused effort to keep the code clean and easy to modify, it starts to rot.
> IDK, a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code.
I don't think you're really disagreeing with the original sentiment? However, I think you're taking a much broader view of "code" than is intended by the original statement.
In your framing, you're kind of confounding code with architecture. Code is really just the act of making a computer do a thing you want it to do, for some definition of "thing you want it to do". Architecture is more about understanding which things you want the computer to do, and in which ways.
There are a million ways to code a task. That's the "code" the original statement is talking about. Understanding which of those ways is an appropriate way is a separate skill, whether you call it architecture, or something else.
Web software I don't know but there are many "modern software" that were meant to replace COBOL code running on AS400 that ended up never making it to production because they were running so badly and projects ended up being money pits.
yea, a lot of my prior work was in the "code is the easy part" I was a frontend engineer for years. And something like 90% of my job the code was not the hard part.
I loved writing GPU shaders or optimizing visualization performance, but most of the time it was wiring up netcode to UI elements that exist.
Ironically as I've moved into focusing on more GPU and kernel programming AI is now lapping me there anyway, however the impact of knowing what sort of algorithsm are state of the art in papers, what is causing memory bandwidth issues etc... does a lot to drive the machine.
I'm yet to work on an enterprise project where programming is beyond simple validation, simple SQL, simple sheduling, simple mapping, simple error handling. Might be more about web backend than the whole field, but the challenge always comes from formulating requirements in a rigid form with all edge cases considered.
This might be the reason why many personal projects are so technical and impressive - it's the itch that's not scratched at work.
This is one of my theories why AI is well-suited for these kinds of projects. It's mostly CRUD, written in well-known patterns. This not to discount the programmer or the job in general, it's what the task calls for.
Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise projects. Trying to make hardware go faster with more efficient code is much harder than optimizing an SQL query and safeguarding it, and these are well understood problems, in general.
Yep, LLMs excel here because most of the time analogous solution is already in the codebase. Most of my initial promtps include "look how it's done in X and do the same".
If you just mean a large company, I would say they do exist - though it may take some looking for them.
You can find them in companies that have to deal with "real" things (hardware, factories, production lines), or where there is an interest in taking advantage of emerging technology (advertising, e-commerce)
I would call my current project relatively systems-level too, as it's a network proxy. Not quite kernel level but definitely not trivial "if this then that" style coding.
My perspective is that application programming - CRUD, forms, IO orchestration - was always vulnerable, even before AI. Think about APIs for payments, APIs for subscriptions. E-commerce in a box type solutions.
That's why I always pushed to do more systems level work, on more exotic or weird technologies. It's not because I think I'm a better programmer, than someone slinging Spring code or React forms. But because in this industry it's better to be a goat than a cow.
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.
The percentages are different for different types of SWEs, not all SWEs spend 80% of their time on XFN comms. I agree with your larger point that a non-trivial amount of a SWE's time is spent on XFN comms and team alignment. My argument is that if an individual contributor is not spending a majority of their time on problem solving and implementation (including maintenance of legacy code), they are not maximizing their potential. If they are spending 80% of their time on non-coding activity they are better suited for an Manager role (Engineering or Product). At the end of the day, coding is not hard only if you are a good coder to begin with. If you are a good EM/PM then people issues will not be hard (which coders often complain about).
A big problem with online discourse about programming if that so many people are in bubbles that they think are normal and think that anything outside of their experience is niche and rare.
‘Enterprise’ software includes SaaS, internal LoB software, integration work, and a bunch of other things I can’t name. The LoB and integration work is usually boring from a technical point of view, so articles don’t get written as much, and they likely wouldn’t do as well on HN, compared to something highly technical about scaling something to serve millions of users. There’s probably many more hours of work, and more programmers, doing LoB and integration, but people in a SaaS bubble don’t see what happens elsewhere.
About halfway through my career, I spent about 10 years working in the enterprise SaaS/PaaS space. 6 as a developer, ~4 as a product manager. Both sides of that coin are difficult. Trying to create a product strategy that meets the needs of hundreds of large companies is a special kind of hell. And on the dev side, even "simple" things are not simple when they have to be implemented at scale, software updates cannot break existing customer code/configurations, and customers must have a hundreds knobs and dials and scripted escape hatches to implement their own business logic.
Even when code was not the hardest problem, it was still a hard problem.
Mostly this. The phrase "code was the never the hard part" touches on a larger culture war. I was I was moving up in the ranksit was common to see people, both myself and then watching others, say things like "I just want to code".
Coding was the job. But there were diminishing returns in that getting better at coding wasn't as impactful as getting better at all the social skills, big picture strategy, and general scheming.
Maybe "code was never the hard part" should be replaced with "coding wasn't the most important part". But I think we all know what it means. Those higher level skills are the things that LLMs can't do, at least for now. Coding? It can do that, at least sort of.
It's exactly this - "coding was never the hard part" translates more directly to "coding was never was slowing me down". It's nailing down requirements, it's cross-functional team meetings, it's planning the testing and rollout, it's integrating with all the other parts of the product and systems, etc etc etc. Optimizing coding was just aiming at the fastest part of the job already.
> 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.
The really hard part of this does in my opinion not so much lie in the aspects that you describe, but rather in doing this without leaving scorched earth with most/all of the stakeholders involved.
In other words:
Doing what you described is in my opinion something that can be learned, and in my opinion a central reason why many programmers consider this to be difficult is that they never learned it, and/or (related to this) were never given the opportunity to be responsible for all of this, so they lack experience.
On the other hand, navigating the whole office politics, and running the political gauntlet that is collateral to it is hell on earth. The only way to survive this is to give a big "fuck you" to everyone, which I more politely described with "leaving scorched earth with most/all the stakeholders involved" above.
Writing some code that actually works for the problem at hand, can be fairly easy.
Writing code that does this while being clean and efficient is a lot harder. How many slow, buggy programs have been written because the assigned programmer did not yet have the expertise needed to do it right?
IDK, I worked like in ~20 enterprises and I didn't really see what you describe.
"Navigating customer requirements" is mostly everyone speculating on customer needs and pushing the part they own, and whoever happens to get closer to the higher management's ear, wins. Then market decides if that's is a good thing or bad thing. If it's good, normally the person who pushed this doesn't even receive credit for it, because either the command chain too long or the stakeholder's memory too short and postfactum everyone pretends they authored good decisions and opposed bad ones.
It might be tiresome and exhausting, like all intense politics, but it's not hard in any technical sense. Most mediocre people can do it and do it.
For something to be hard and complex you need rules and professionals on all levels who understand and follow the rules and driven by meritocracy alone. That's simply never the case.
> 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
True. And there is another angle: ownership. The author also said “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days”. This is like saying that a programming language designer does not own the spec of the language itself but just wants to write hte compiler. I find such altitude counterproductive. Case in point, many companies hire PMs for their internal infra org. I mean, shouldn't the engineers in the infra org know exactly what they design to build? If you don't want to own what to build, you end up letting someone else tell you what to do, except that the person is neither an expert nor even your user.
And that should be the engineers' job instead of outsourcing it to PMs who do not even use any of the infra services -- I'm not insulting the PMs, of course, but to state a fact. Infra is used to serve the internal engineering teams, and the PMs don't code, so they don't have a need to use the infra.
I've been programming for 30 years and "Code was never the hard part" does not offend me. It's something i've been saying for a long time. You can teach anyone the mechanics of coding well in like 6 months.
Programming is the hard part! I want to make this distinction because to me programming is about solving problems and coding is a way to express the solution.
Designing algorithms, architectures, etc can be done without a programming language. Coding is putting it down into some language.
Sometime in the past 10-20 years there was a prestige shift where people started using the term "developer" for what you're describing as "programmer", relegating "programmer" to what you're describing as "coder", and "coder" to "hobbyist programmer/developer" (while weirdly "coding" remained colloquially the thing programmers do).
Advice to job seekers I remember in the 2010s was to not call yourself a programmer because that was where the bad "code monkey" jobs were, but it hadn't yet been much of a thing when I first started looking at the end of the 2000s.
These waves where someone found a new way to focus on the valuable part and leave the grunt work to lowly others comes again and again. As always the truth remains that each step in the process is relatively trivial and is is the overall complexity e2e and scale and handling edge cases that are where value is created. But that won‘t stop groups trying to differentiate themselves by looking down on others even when it is clearly failing. As long as there is a benefit to the group driving it.
I've also been doing this professionally for about 30 years, plus another 10 as a hobby/learning before then, so I think I have much of the same experience as you, and I do agree. Although, I think with the advent of LLMs, programming is no longer the hard part. The hard part of programming is the convergence of context management for humans while also presenting it to a computer to do something. Much of data structures and algorithms "best practices" are ways to efficiently get your work done as well as keeping it so that a human has context.
For example, one guy I used to work with wrote this really awesome algorithm about 25 years ago, and I'm responsible for maintaining it since he long retired. I can't go into details, but this is the core algorithm in moving billions of dollars between institutions overnight. It's about 10 screenfuls of c that had been converted from the original FORTRAN 77 with dozens of gotos and weird branching statements and about 20 parallel arrays that store indices for pointer chasing. It's almost impossible for a human to follow (I've actually fed it to an LLM and said rewrite this with for loops and no gotos so I can understand it - and it worked!) but it's blindingly fast. The actual problem it solves can be stated in about three sentences, but programming it was hard because of the context management. The reason that my company keeps getting royalties on this is that it's so hard that they'd rather pay us than write it themselves. But I bet an LLM could write it from scratch now.
So maybe programming is no longer the hard part, or at least context management is no longer the hard part and that humans should move up the chain to help manage the context for LLMs so they can get more done efficiently.
Switching topics a little...much of what I think makes coding the hard part was the tension between big-design-up-front and you're-not-going-to-need-it philosophies. Early in my career I worked in health care and that was BDUF and the coding was easy because program managers spent years defining every screen that would be shown to the users, what queries were needed to fill the screen, all of that. We just took the spec and coded it. Coding was easy. But the failure of BDUF was that it still didn't really match what the customer wanted.
Then enter agile and YAGNI, in that limit, coding is easy, just write what the user story says. But then you have to refactor from what was left behind on yesterday's user story. So smart engineers would cheat a little with YAGNI and say, yes we will put an abstraction in because the next user story. I would say that "good engineers" or "good coders" found that balance in abstraction to move fast but make abstractions not overkill. And I think that's what all the wailing and gnashing of teeth is right now: the good engineers aren't needed anymore.
I can tell an LLM to code something, and as I add complexity it's happy to refactor and manage the context so we don't need to worry about "clean code" or "quality code". As long as what the LLM writes meets the spec, then we're happy.
Ah, sorry long rant and ramble. But I just think the "hard part" has been managing context, and the context we're managing context is just changing. Those good at managing context will be good at coding with LLMs, and those that weren't won't be.
This is a very good comment, one of the best i've read here.
> I would say that "good engineers" or "good coders" found that balance in abstraction to move fast but make abstractions not overkill.
i think this is spot on and could be where the concept of "llm's have no taste" comes from. There is art (and science) in determining the right level of abstraction that satisfies the user story in a performant way while leaving the door open for extension.
> As long as what the LLM writes meets the spec, then we're happy.
going back to just meeting the spec vs the art of perfect abstraction is a bitter pill to swallow and I imagine removes a lot of the joy some found in software development.
I said this in another comment a few weeks back - but, at least for me the "joy" of software development was describing what I wanted and getting it. That used to mean fighting with code and trying to be clever and clean or following the right design pattern. But now, I get "joy" from using English to describe my problem and getting the right answer. When the LLM one-shots it, I get the feedback that I'm describing things correctly and clearly. I'm still getting the same joy just in a different form now. I'm old enough and have been doing this long enough that "giving up writing code" is not sad for me. I'm still expressing my ideas, just differently now.
the article means code as a whole not just the moment you input some if else in a screen but the whole act from thinking about it to make it live in prod.
I don't even sit in front of a computer to write programs, I do that in the car.
I type them in when I'm in front of the computer.
All the actual work though? That gets done in a space where there's no phone, no people walking up and talking to me, no distracting social media, no screens, just quiet-ish and a couple of hours to think.
> 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.
"carefully architected solution" is not what they are saying. A "buggy big ball of mud" will not generally "do the right thing", if it did, it would not be a "buggy big ball of mud". Straightforward requirements do not imply straightforward solutions. In the early 2000s Facebook wanted a quick way to search for friends updates, a straightforward requirement. Turned out they had to build a full graph DB inside MySQL, not straightforward code at all.
> In large corporate environments with multiple international customers, code is most of the time not the hardest problem.
This is true, and this is the thing that makes me want to not be part of this dumb system anymore. If leadership on the same company can't align, that shouldn't be my problem, and I hope they get replaced by AIs that can.
Would add this is not exclusive to large corporations either. My smaller employer is also struggling hard because leadership simply cannot prioritize. Everything is either not being worked on or is the highest priority which in practice just means nothing is the priority, and no matter what myself and my team work on always seems to be the wrong thing.
It's absolutely devastating to team morale. We never feel like we're contributing.
What devastated me this week is that I was slogging so hard for the past several months trying to deliver on what I was asked to deliver on, only took 1 week of PTO out of the 4 weeks I have saved up, spent nights and weekends trying to honestly solve multiple high priority yet HARD problems that 500 other engineers in the company couldn't solve, I'm making good progress on a couple of them single-handedly, yet my manager, who just came back from 3 weeks of vacation just gave me a performance review saying I am not meeting the "bar" for my level and need to do more cross-functional work and amplify my "impact". He's going on vacation again next week to watch the eclipse.
Fuck this. I want to travel, I want to enjoy life. I used to chase eclipses, too. I tried my best, all I ever get is "what you are doing is not enough". What the hell IS enough then? I already don't take vacation and don't exercise, I've put on 7kg of weight since I joined, yet you told me THAT is "not enough". Should I stop sleeping and eating?
Change priorities all you want, honestly I really don't care, and I've dealt with customers too, it happens. Just don't tell me I didn't get anything done. Recognize the fact that I tried hard every time you changed your priority, and I only had 2 months out of 8 to work on your latest priority, and calibrate your expectations to 2 months of work, not 8.
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.
> Likewise, coding is easy. It's just writing, and any child can learn it.
Any teacher of a low level CS course knows this is completely untrue. In my CS 101 course our problems were relatively straightforward and short, and lots of people struggled mightily to the point of dropping the course. IMO coding requires a particular way of thinking that a large subset of people just aren't good at, and as someone whose done tons of screening interviews at college recruiting fairs where I give relatively easy problems and ask someone to code a solution, I will tell you the idea that anyone can do it is just false.
Why does it have to be Shakespeare? There are millions of good writers that got there by working hard. Seems pointless to go into either extreme, when just being good at anything is generally hard.
It doesn't have to be Shakespeare, but hopefully everybody agrees that writing at Shakespeare's level is indeed hard. I agree that writing good (but not great) or even just ok literature is still hard, but that invites a bunch of no-true-scotsman arguments that I just can't be bothered dealing with (like "writing Fifty Shades of Grey isn't actually hard" or something similar).
The comment I responded to suggested that we don't really have to be "insulted" because code is actually not hard, good code is hard. But the statement "code was never the hard part" doesn't make that distinction, it's a blanket statement, that any normal person would associate with all software. I argue there is no reason to try justifying such a misleading statement.
Completely agree. I feel like lots of comments in this thread are getting side tracked by useless nitpicking, e.g. "Writing code is not hard. Writing correct code is." - oy vey.
In it's original context, it's very clear what "Code was never the hard part" was referring to, that of all the steps of product development (ideation, requirements, design, implementation (coding), deployment, operations, maint, etc.), that code was not the hard part. That's the meaning we should be discussing, and I agree with the author, I believe coding very much was the hard part. Since Jeff Dean and Sanjay Ghemawat were recently in the news, I recall some stories about them fixing issues with the search index in the early days of Google where there were random bit flips that were causing the index to be corrupted, and they fixed it and coded a durable solution. This is very much just a code-specific problem that very, very few other people would have been able to solve.
But I must insist: "building a car" is not hard (millions of children do so every year with Pinewood derby style box car kits), building a "real car" that you can use and that passes regulations is harder, but knowing the difference between the two is where the real hard work is.
The truly difficult work is knowing when your client/boss asks you to "build a car," do they really just want/need a small Pinewood derby box car as a toy, do they need a four-door sedan that can legally drive on major highways, an 18-wheeler freight truck, or do they actually need/want a bicycle, or a shopping cart, or a railroad box car, or information about how to take public transit that will serve them cheaper and easier than anything you could build in their timeframe and budget.
That's what people mean when they say that code was never the hard part.
I get what you're trying to say, but coding is hard. A significant percentage of children struggle with it from the very beginning, unable to reason in a very specific way, read and understand errors, trace incredibly detailed logic, gain mental model of memory and state, etc. According to these[1] sources[2] computer science has the highest college drop out rates: ~10.7%. I worry that "code was never hard" is going to become a misleading truism for business leaders.
> I worry that "code was never hard" is going to become a misleading truism for business leaders.
The fact that children cannot do it does not mean that it is particularly hard, and computer science attracts a lot of people who just like video games and have no mathematical ability.
I think that the fact that programmers were/are doing a lot of the job that other positions take credit for is significant. Others can get by on bullshit, but the programmer's job in turning that bullshit into code forces them to make something real out of it through a combination of back-and-forth interrogation and just making it up when necessary. Turning handwaving into a product is a skill that programmers have, and is why AI isn't helping tech-illiterate businessmen create things that work.
I believe Graeber perfectly predicts the problems, in 2019, with vibe coding creating immediate "value" from production, but failing to produce true value through maintaining the system (like one continually washes a cup to give it value over time).
> (like one continually washes a cup to give it value over time).
But it doesn't give value, it prevents value loss.
I don't know why people are telling themselves maintenance work is virtuous. It's waste. It's necessary waste, and doing the work may be virtuous, but the work itself is pure waste. Fighting entropy.
EDIT:
I wish we talked more about the need for low-maintenance patterns and products. In this industry, many of us already recognize this instinctively, but we often misattribute the problem to "complexity". Think of e.g. rather substantial niches and common practices among developers, like static site generators, no-build-step development, or on the backend side, the popularity of header-only libraries in C and C++. All these tend to be labeled as reducing dependencies, but that's just the means - what they do is they minimize independently rotting parts. The build system isn't bad because it's complex - it's bad because you have to constantly babysit it. Conversely, a static site once rendered will open ~forevermore, and so will a piece of C/C++ code that relies on single-header libraries.
Similarly, the popularity of containers is in large part this. All the mess isolated in a self-contained bundle that is preserved against rot, at least for a while. Inside, there's nothing to maintain - it works until it's not needed, or until the "outside world" changed too much, at which point you throw the thing away and get a new one. Etc.
> But it doesn't give value, it prevents value loss.
It keeps thing operational. Software changes because requirements changes, the context it is used it changes, or just the iterative nature of it where features are rolled out over time so that users can immediately start getting some functionality if not all that was originally planned (MVP).
Maintenance work is neither virtuous nor waste. Its just nature of the things we build.
I agree however with the part on more talk about low-maintenance patterns and products. IMO its often the trade-off between velocity vs quality/technical debt. So it happens, industry is favoring more and more towards velocity for delivering features that often add little value to the users, just because $$$, competition and maybe the grind culture.
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.
> Ask claude, use ssh with key-based auth and he will take care of it :) just saying
This already goes over the heads of most non-developers.
I think you're misunderstanding my point. It's not that LLMs aren't a useful tool or that they won't replace some developers. But rather that software development as a specialty won't go away because most people can't build software with LLMs in a way that won't blow up.
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 in tech, so does the authority granting license to proceed do code reviews?
Because when I submit building plans, they are manually reviewed and approved (or denied) by registered architects, engineers, and planners employed by the authority for just this purpose.
Gaming Commissions oversee gambling machines and will audit code to ensure the RNGs are accurate, return to player meets the expected requirements, and so forth.
I'm sure other highly regulated industries also have their code audited.
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).
Even if you get a crispy set of requirements from all parties you are still responsible for implementing all of then while making sense of the existing system (and from my experience significant issues arise at this stage when the full extent of requirement implications ia better understood). On top of that you might also be responsible for operating the thing, participate in compliance doc writing and do ongoing maintenace.
Yes, these things reduce (not necessarily how to zero) how much compliance the programmer is doing. They aren't figuring out how to get a car legally on the road, they're still figuring out how to get a car to do car things. The compliance questions the engineer sees are largely engineering questions. Sometimes hard engineering questions.
While there are for sure a lot of programming jobs that don't touch anything "important", like making dime a dozen websites or apps, I think you underestimate the number of things that need some form of higher quality control.
The level of quality needed (or imposed) will vary. It is a wide spectrum from dealing with banking/transactions (money at risk) to brake controllers and auto pilots (human lives at risk). But there is a lot of this, all over the world.
I work somewhere in the middle (rather slow but extremely heavy industrial equipment, where emergency stop is always a safe if costly option). There are domains where emergency stop is not a thing though: some systems on an aircraft in flight, a pacemaker, etc.
My point is though, that there is a ton of code where stakes are higher than "oops, I guess we will fix it next sprint". And while not all of that have regulatory constraints, sometimes a company realises that the financial cost of issues significant enough that it is worth holding themselves to higher standards anyway.
Any coder with experience or ability imagines a world where software architects are regulated the way real architects are, and acts accordingly.
I mean, this was drilled into me at uni — that software was not likely to escape regulation forever and that you can't know with certainty how all the code you're writing will be used when you're not observing the use.
For example, under what constraint regime should the calculator app bundled with an OS be written? It's just a little bundled toy app. Until someone under pressure uses it to calculate a medicine dose, expecting it to be a calculator like it says.
Perhaps this gives away my age more than anything else.
> For example, under what constraint regime should the calculator app bundled with an OS be written? It's just a little bundled toy app. Until someone under pressure uses it to calculate a medicine dose, expecting it to be a calculator like it says.
This captures a sentiment I have often felt when people don't take bugs seriously. Or don't take it seriously that they introduced regressions. You should feel personal responsibility for your bugs. When your shit doesn't work, and people are trying to use it, you are basically hurting them, personally.
But it seems with the increase of AI coding, the industry is going the other direction. Nobody seems to care about bugs introduced by slop coding. Except perhaps the users.
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.
The problem is that non-technical people just see The Code. And now when they prompt an LLM they also see The Code. Voila - finally we don't need those pesky engineers.
Communicating like this is to try to get them to understand that The Code is barely about the text on the screen and is instead about much more - both abstract in the code (but how on earth do you explain that to someone nontechnical without just sounding like "no trust me my job is really hard, I promise.") and also in all the external stuff - the world The Code lives in (users, ops, support staff...).
Is it a perfect analogy? Of course not, and I'd never explain it like this to someone technical. But they're not the audience.
---
Adjacent: I've always gotten the feeling that even the most well-meaning/trusting nontechnical leaders have always been fairly nonplussed by software complexity and software development.
Deep down, they seem to think it can't possibly be that hard, despite the fact they can't write it themselves. Sometimes, even worse, they have dabbled in writing small, or even medium-sized solo projects. And think - well isn't software engineering just doing that but with other people? And their attitudes can reflect them, sometimes all the time, sometimes just slipping through when under duress like delayed projects etc.
And yet despite their attitudes, they then also find:
- if they try to outsource, they have a bad time
- if they try to proooompt, they have a bad time
- if they try to pay less, they have a bad time
and so the invisible hand of the free market itself forces their hand in paying prodigious salaries and fighting to retain talent. And all throughout they remain internally nonplussed even if they manage to keep up appearances.
Your analogy breaks down because code is not heavily regulated as cars are.
This is worth saying precisely because of this difference - people see huge amounts of bad code generated by LLMs and think it is equivalent to carefully written code because the results look similar at first glance and they don’t bother to read it.
Absolutely there can be a bunch of hard things wrapped around easy things. When those things can't be separated neatly than it doesn't make sense to separate them such that we can call the easy parts easy (or even parts really).
That said, it's still reasonable to think that once (and only once) the hard part is done, then the easy part is easy. It would just be wrong to think that you can do the whole thing without having to do hard parts. I think the argument here is that with AI this is more possible—that the tasks are more separable. Even if it's the same one person doing the hard stuff and then passing what they learned to the AI to do the easy stuff.
Two reasons they might not separate well (there are others):
- If in a company's product development it's hard(er) to have one person doing H and another doing E, then you're generally going to have one person doing H and E. More or less, this means a person can only do E easily if they do H beforehand. So hard things are required no matter what.
- People come in whole persons. If people skilled/educated to do H tend to be the same people skilled/educated to do E (can be because of how programming is educated, but also can be because there aren't that many programmers), then you're always going to be plugging programmers who have both H and E into roles and it'll probably be more efficient to plug them into roles requiring both rather than just H or just E. You could, within that population, determine who is comparatively advantaged (and we do do this mildly with senior vs junior or with "architects"), but plugging a person into an E-only role is going to involve that person questioning what happened during the H part beforehand. In part because they're good enough at H to question it, but more importantly because they're implementing the H such that they're aware when their E might not be as easy as it could be.
Both of these seem like they might be less true now with AI (and also perhaps because there are more programmers).
I mean, I think the point is, every discipline isn't ever that discipline in a vacuum, it touches the real world, and we build meta-structures around said things that may not look like programming, but certainly require deep programming SME.
Even in academia, you have meta structures that you constantly need to think about.
Of course, you can keep trying to isolate the "pure" thing from the "accidentals", but it's not going to work when the work gets sufficiently complex
The reason people say "writing code isn't the hard part" is because the only thing an LLM saves effort on is typing code into the computer. You still have to know what the code should do, and you still have to review the code the LLM generated to make sure it is reasonable. In other words, you still have to do the hardest parts of your job, and the LLM only saves you effort on something which was no real effort to begin with. That is why they are an ineffective tool, because they are helping you with the bits you don't actually need help with.
I don't agree that "the coding was never the hard part" in general, but it is true at least often.
For those cases where it is true, it is pretty much like your example, and the distinction is there in your example just like theirs. You supported their point.
> 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.
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.
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.
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.
I'm beginning to wonder if a lot of commenters have forgotten that waterfall is a failed methodology in part because you can't always just gather requirements by say introspection or interrogating the customer for them. In order to reveal the true, accurate requirements, you often need to write code. Not always, sure, just like some code is relatively easy to write, some requirements are easy to both accurately specify ahead of time and even satisfy. (An old XKCD hinting at this distinction: https://xkcd.com/1425/ Only nowadays we actually can easily satisfy a lot more of those old easy-to-specify-difficult-if-not-impossible-to-satisfy requirements. That's the way progress in the field often goes.) Decades of startups support the iterative approach, along with pivoting, the successful ones learning the lessons of writing less committal code and discovering requirements iteratively. And it's hard to actually pull that off -- so many companies have gone under or lost out significantly to competitors because they couldn't write code fast enough, or change code fast enough, either with the goal of discovering the real requirements or adequately satisfying those requirements once known. Code is hard in general.
> 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.
"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 of the job. We shouldn't define down competence.
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.
> 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.)
I think this is true when you realize "customer" means "coworker" or "person on the next team over" or "management" or "your intuition about the problem". Which all sort of have the same shape.
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 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.
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.
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. ;-)
A business does need a small number of their most senior engineers doing high altitude work that can, at times, include helping sales estimate new features. But in my experience, it's not rocket science and a good product team can do this on their own with a quick async check over chat. At most, a single meeting is all it takes.
I've heard of Sales Engineers as well, embedding programmers directly with sales teams.
But the vast majority of programmers should not be spending any significant amount of their time on this. Their value is in building and scaling well-specified systems.
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.)
Do you believe these numbers? Is there a cite somewhere in the literature for valid, proctored IQ tests being given to representative samples of different professions for these kinds of comparisons? The link you've provided is to a company selling online IQ tests.
I'm not seeing any other posts of yours on this comment thread. Maybe you forgot to hit the "reply" button (or accidently outed an alt?) My only point was that majormajor saying that programmers might only be roughly the same smartness as electrical or mechanical engineers would put them comfortably above the average person.
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.
While you are directionally accurate, the flaw in your thinking is revealed by the fact that bad programmers also have high salaries, and plenty of five year olds have no problem being bad programmers, so there is clearly no need for above average intelligence or education to be a bad programmer.
As hard as it might be for this audience to comprehend, supply is limited simply because it is an undesirable profession. The majority of the population couldn't think of anything worse to spend their time doing. Much as the same reason why they don't want to go work on oil rigs and other such work that is high paying but what most people are unwilling to do.
High compensation is actually not as strong as a motivator as you might think. It can tip the scales if someone is already on the fence, but it doesn't suddenly make someone who absolutely can't stand something to change their mind.
I've watched dozens of people try to learn to code and fail, some definitely not for a lack of trying. Of those that did learn, only a fraction had the IQ or passion to be genuinely good at it.
The difficulty of it has absolutely been a bottleneck to the supply of good devs, keeping salaries high.
We've also seen decades of effort, much of it successful, aimed at making it easier. Programming used to be harder. (Difficulty alone doesn't account for high salaries.) If it was never "the hard part", what motivation for all that effort? Books, pedagogy, tooling, languages, even the notion of publishing a library is an attempt to make coding a related task easier for others. There's been comparatively less effort in making "the other parts" easier. Though certainly things like software development methodologies count.
My hunch is that the difficulty has moved, not reduced in practice. We make one layer easier and then another mountain lies at the layer above, just as hard.
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…
You actually do. All of those puzzle-style questions of the sort of "how many liters of water in Mediterranean" ask you to develop a solution with a vague requirement by leveraging what you know roughly to demonstrate you can specify requirements yourself (oh, Mediterranean is roughly 5000sqkm [-> I need surface area], on average 50m deep [-> I need average depth], this gives me A x B liters total) — I'd call these the leet-code version of requirement understanding/development.
But really, any interview is really about giving you a requirement, and seeing _how_ you understand it, how you clarify it with your stakeholders (interviewers), and then how you address them.
The author might be missing the intent of the observation. Maybe they’re misinterpreting it.
What I, and many people who’ve said, “code was never the hard part,” aren’t referring to the skill of an individual. It’s not the hard part of the engineering process of developing software. Programming languages have manuals. Many data structures are well documented. There are frameworks for damn near everything. While the difficulty of producing code varies by the skill of the programmer and the complexity of the problem domain; writing and understanding the code is a tractable and straight-forward problem. I can and have taught many people. People can learn.
What most people are referring to is that the hardest parts of producing software are all the things an organization has to do in the production of it. It’s not writing the code that is the hardest part for an organization. It’s getting everyone to understand the problems, working together, gathering requirements, developing specifications, validating releases, testing, etc. It can often look like herding cats and is probably harder.
If what you're saying is true we are moving into an era where rockstar product managers are going to be more in demand than programmers since they can do all of what you mentioned above.
And typically (though not always) product managers have better people skills than programmers and consequently they might be more effective at the "gathering requirements" and "working together" bits you mentioned above.
Even much of the "validating releases" and "testing" parts should also be things that a decent PM should be able to wrangle now by themselves with some LLM agents to assist them. Afterall, why bother about code quality of a testing harness. So long as the PM can keep a coherent test case list and have end to end tests that cover them, programmers can leave that to them as well.
Well, it's true. In a world where code is commoditized, a PM who knows exactly what the customers' needs are will be much more successful than an engineer who does not. Not sure what is controversial about that.
Highly experienced programmers seem to have a hard time understanding this.
Why do we have tens of thousands of test cases and we still find new errors constantly? Why is our software so bloated and slow? We do we still have security breaches?
LLMs can be useful tools when guided by experts. I don’t think a PM with a dream is going to cut it in the long run.
It also depends on how you model the problem. You can easily say the hardest part is hiring people if you are the boss. Since the people you hire can do everything else that needs to be done.
Managing and motivating people is the hardest part for the person who is doing it.
If you are hiring you might say it is harder to find good managers than programmers.
It is not measurable who did a good job at what as almost everything requires a group of people doing different things.
You can see how pointless this is becoming as we don’t have a measure for anything.
This kind of problem requires assumptions because it doesn’t hing on anything natural.
For example, if you start by believing salary indicates value then you can go from there.
In the end there are millions of managers, millions of programmers, millions of ux designers etc. It is kind of funny to suggest doing any of these is inherently harder than the other.
Just imagine you are judging a project. You have everything about it recorded. How hard do you think it would be to judge who had more part in the outcome in what way? If 10 people judged it separately, how many would have similar opinions etc.
It is impossible to judge even for a specific case, so it is a joke to consider to find the universal rule for it.
In the end it is ok to believe something but it is also important to not forget that it is a belief
1000%. The expense of writing software was and still is high.
Whether it’s commercial software company or an internal team writing custom software, the return on that investment depends on many things outside of the code itself.
Getting everyone to understand the problems, working together, etc, etc are issues that are inherent to organisations.
They’re orthogonal to AI and to the actual hard technical skills needed to execute on a specific strategy. And if the technical skills are lacking, it doesn’t even matter how good an organisation is at collaboration, whereas hard skills plus organisational disfunction are a known successful pattern :)
Many people did look at this through an individual lens and claimed that design skills, domain knowledge are the truly important abilities. I remember reading on HN at least a couple of popular articles claiming that.
Actually, they’re all important and having great design skills without matching coding skills is IMO not really possible. The code feeds into the design, the requirements, the architecture and shapes them.
I don’t disagree. I’ve worked on teams that definitely valued the non-coding skills more and it showed in their inability to deliver on certain requirements… mainly performance and stability.
But these are skills that can be taught to individuals.
But teaching an organization that their real bottleneck isn’t how fast they’re writing code; it’s producing production-ready software that people understand and are willing to take responsibility for… that’s much harder.
Many businesses want to treat software development like an assembly line and revert back to Taylorism. It’s knowledge work and there’s no royal road. Good teams get fast when they have the right mix of skills and trust from the organization.
What we’ve been delving into for the last decade has been a decline in the value of labour and work.
“Code isn’t the hard part,” isn’t meant as an insult at individual programmers or to devalue their work. That’s being done by big tech and their AI hype machine.
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.
It's not really telling on oneself. Like you said, the easy stuff (e.g. basic business process automation i.e. constructing simple database queries) happens to be economically high ROI right now. Something like 3d graphics or signal processing or whatever are comparatively niche and less likely to pay as well. Most jobs that people will actually pay for are actually pretty mindless. Even for the more "advanced" jobs, it's likely the domain knowledge and not the programming per se that's difficult.
> 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.
Genuine question and not trying to be snarky here, I am actually curious: what fields or types of programming does this apply too? I think I've read anecdotes online about people in fields I previously (a few years ago lol) thought "oh yea an llm will never be able to help with that" and now see articles about how llm's are doing just that.
LLMs are surprisingly bad at basic CMake, but i don't see why they should be.
Much of the truly LLM-difficult code is probably hiding in the libraries we import. Database engines, compilers, efficient data parser, control theory, signal processing, protocol implement-ions, or anything with a 12000 page German ISO standard that need to pass a $12.000 certification lab. But this also compose of such a tiny fraction of programmers or code in the world.
A-lot of my work lies in that last one... but that's also where that "code is easy, knowing what to code isn't" is the most true; because industrial standards tend to not spare any expense on the word count, while the implementation is a ~2000 row state machine. I've not yet found an LLM capable of successfully parsing this kind of specification documents, but it's possible they will reach there eventually.
But i do feel online debate do clump the software field a bit too much when AI is discussed. JavaScript compose probably 98% of all code the LLMs are trained on since it's powering every website scraped for training. As such, people in web-development seem to have far more praise to LLM capability than i'm able to give.
My personal AI experience has been very mixed in comparison, regularly making up functions of common libraries, hallucinate the description of technical terms, straight up writing un-compilable c-code, or get confused by relatively small code-bases. Useful but not majorly changing my work at the moment (pretty good at comments, test cases, or as google replacement).
Granted, I've only tried models up to Opus 4.8, and not had experience with the newest "tier" of models with Fable, Kimi K3 or GPT 5.6; but the prices on those are also starting to compete badly with my salary at the moment.
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.
This feels like post-LLM coding romanticization. Before LLMs, people would regularly say stuff like "I could build this in a weekend" under a "Show HN" post. How many times have people said "I could build Twitter in a weekend". I've even found in a post-LLM world, that kind of language has only increased.
When you are looking at something that already exists, where all the requirements are defined, when all the edge cases have been decided, then coding was the easy part. People didn't "burn out" because it was difficult to figure out how to write SQL. People "burned out" because the requirements constantly changed, demand was ever increasing, and edge cases were constantly being triggered.
>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?
Classic engineer type opinion where every else is dumb, except for him. So many people have come to see leetcoding as an intellectual badge of honor, when most of us know its cultural rigamarole and the code written on the job will rarely reflect the type of work that will done.
I'm not saying coding is easy, plenty of people struggle with it. But as far as the job goes, unless you are a junior just grinding through JIRA tickets, coding was the easiest (and arguably the most rewarding) part of the job.
You are putting a lot of words and judgements into the authors mouth.
Why exactly is it acceptable to not just do your role and expect the underlying requirements to be correct and measurable, especially when there are separate roles whose sole purpose is to do exactly that?
Because being a code monkey is getting devalued like crazy every hour that agentic coding improves in ability. If all you do is take well specified requirements and turn them into a piece of code you are going to lose your livelihood unless you can learn to do more than that or you're at the very top end of people who do that.
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
I suspect the massive shitshow of Windows 11 and all of its failings is a result of large quantities of vibe code being merged into the OS. People are noticing.
Just because some of Windows 11 was released before Claude Code doesn’t mean that the really shitty stuff from the last year wasn’t vibe-coded garbage.
Windows 11 was released before vibe coding was viable. And the shit show seems to be that they push ads and bloatware on people, not that it doesn't work reliably. Windows 11 IoT LTSC has been absolutely rock solid for me on both machines I have it on. Waaay more stable and reliable than Linux, and even a bit better than Mac (which is also way better than Linux).
If they are vibe coding anything, it hasn't had any bad consequences yet. The ads and bloat are human decisions!
In the last two years Windows 11 has shipped with increasingly serious bugs. Many of my co-workers report needing to reboot a few times a day because issues just compound.
I regularly have major issues with Teams and Outlook. Crashes, not showing messages until hours later, calls dropping every few minutes, and the app just never opening. Just Friday afternoon I could not close Teams from the Task Manager
They do. Most economically viable software already exists today, most people's job is to make .1% improvements, and features on top. For this work it's obviously pivotal that any change should not worsen the existing software, as that instantly nullifies the value of improvements.
Another kind of highly valuable software is a new design which digitizes some process, like the ticket management of a rail company. If you don't follow the internal processes and workings of the firm exactly, or you do not interface with existing systems 100% accurately, your software very soon becomes worthless.
Figuring out how to create a piece of code that solves the exact problem the customer has, while not breaking anything, and fitting into existing operations seems to be a big head scratcher still, and something humans still need to do, at least that was my experience so far with LLMs.
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.
The most important result of quality in software is that it's faster to produce and cheaper. How are people defining quality? We're not building tables with the finest wood.
Low quality ends up taking longer to build over the long run. It gets harder and harder to add or change features.
This is why I believe true engineering art comes in actually marrying all three: build great quality quickly at reasonable (small) cost!
If you need it to work for at least a month or two (instead of one and done, which some demoware is like). Following a few rules early on will ensure you can keep evolving it — even if it's MVP/demoware/whatever — as long as you know you need to evolve it soon after you build it!
This isn't true. I don't think you or me would want a car/TV/smartphone that's cheap and flashy but breaks every two weeks. Sometimes people are strapped for cash that's why they cheap out on stuff, or really are enthusiastic about it, so they tolerate it breaking all the time, but for everything else, reliability is king.
Nobody _wants_ it, but in practice if all cars/TVs/smartphones break every two weeks, what choice do people have?
In tech, the era of competing based on quality is long gone. The winning strategy is to get a monopoly/oligopoly and then you can let the quality decay to zero and people will have no choice but to keep paying you money (or to your handful of equally-mediocre competitors).
There is a minimum but beyond that people don't care. Asian brands like Toyotas are the most reliable yet the Ford F150 is the best selling vehicle in the world.
>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.
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.
Why wouldn't they be working on better harnesses? Every feature that has gotten popular has gotten integrated so far, and their product managers aren't stupid.
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.
Yup you'd fail fast because you could not at the time bullshit and handwave the computer. When you don't do the implementation work itself your sloppiness is mostly the concern and inconvenience of implementors. And I concur the best way to understand the system is through the code, and the best way to understand the code is to write it.
We aren't going to understand the systems we whackchitect from now on. It's the endless prodding and begging instead, something that makes me infinitely sad.
>jump into architects or prod management but not the opposite way.
This has nothing to do with any intrinsic difficulty with coding and more to do with the industries penchant to rewrite everything every couple of years. The reason you don't see people who went to management become ICs again, is because you have to spend time learning the new, correct™, way to do read and write code.
From the constant API churn for something like React, or even the 20 million updates to write "modern" C++, someone who has had those minute decisions abstracted away will struggle to write code.
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.
LLMs can write TLA+ models just fine. It can help even with small mobile apps. Surprisingly, simple TLA models were able to find design/workflow issues almost in every of a few vibe-coded apps I've tried on vacation.
> Encoding your ideas into a programming language is easy.
This is still difficult. Sometimes the programming language or the programming methods you want to use effect how you desing the system on an abstract level.
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.
All of our developers are now using agents. We're not hand-writing code at all anymore. And yet, some of our developers deliver stories in an hour, others deliver similar complexity stories in a week. Executives are surprised to discover they cannot simply turn over a product-authored jira story and have it yield a single agent-written PR. There is still significant work that happens between the point at which a story is written, and the point at which correct prompts are input that generate the code that fits the requirements. Very significant work. I think that when people say "code was never the hard part", they're only guilty of eliding the point that "code was never the only part" or "the hardest part", and that there's so much other stuff that programmers do at various levels of competency, and that... perhaps up to now it was easy for product folks and execs gloss over since they just put us all in one bucket of "people that write code".
I think "Code was never the hardest part" is more fair.
Code itself can absolutely be difficult, but it's seldom the most difficult part of a project. Generally the hard part is actually figuring out what you want, and how to achieve what you want, then the actual code is pretty straightforward in most cases.
I've been programming since the the 1980s and I'm not insulted by the idea that code isn't the hard part.
The "code was never the hard part" is a narrative pushed strongly by designers, MBA guys and product managers. Even before AI, they've always treated programmers like low-lives, someone beneath them and completely replaceable like commodity. Ironically, of this entire group, it isn't programmers that are being replaced left and right. Whole product teams, designers are being replaced. Good coders are still in demand - because, someone has to fix the vibe coded mess. In design, there is no reference for good and bad. You either like a design or not. In code, something either works or not. That's why it's always hard to replace a programmer as opposed to a designer.
Has Claude code et al replaced programmers? Not really. And it will be a long time before it can - because someone needs to still instruct the direction of the code, the base architecture to build upon and that comes with real human experience.
At the start of my career I was being paid for the code I wrote.
By the end of my career I was being paid for the code I didn't have to write.
One of the nicest complements I ever got from a coworker was that he was astonished how much I accomplished with so little code. Everything I built was designed to be easily and quickly extensible with minimal changes, I planned my structure for future needs.
That is why high paid programmers have been in demand, because learning that takes more than intelligence, it takes wisdom.
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.
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!
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 think a lot of the discourse around AI is imprecise, but you’ve done a good job of clarifying. AI is also changing the definition of some terms, so debates are happening where people use the same words, but mean very different things.
Some people say “coding” to mean the process of converting a well-defined plan (requirements, architecture, everything) into executable code. Others use “coding” to also include all the small decisions you make when writing code, like the abstractions you build and how you handle ambiguous requirements.
AI has decoupled “typing the code” from “making the decisions about what to type” because AI can generate code from very ambiguous prompts. So “coding was always the easy part” is meant to use the second definition and emphasize that you may be able to generate code, but having good decisions embedded in the code is still a difficult, unsolved problem with AI.
There are also different definitions of “what to build” with some people meaning the technical details, as you’ve called out, and others (I think especially more business/product roles) meaning the functional requirements of the system.
By saying coding is the hard part, you're insulting all engineers.
Edit:
Although the current job market is heavily distorted, there used to be distinction b/w developer and engineer in the past. As the mainstream development model shifts from waterfall to iterative models, it became necessary for everyone to be engineering-capable -- only up to a certain point. So, every developer now carries a certain amount of engineering knowledge, but now they started to misunderstand and underestimate the value of engineering, and this is what you would get at the very end.
In my peak programming years in Germany, about 5-6 years ago, every company that ever tried to hire me, wanted to do some sort of CRM for xyz. It’s fun when you build it once, but then you change the domain, and realize you’re essentially building the same thing, but for different people. I’d gotten so bored of it all by 2020 that I’d approach them right away, asking “are you building yet another CRM for xyz?” They didn’t like it, because it would undermine their work. But it’s true - thousands of highly-educated, well-paid people in Munich at the time, were essentially paid to build and maintain glorified sheets software for managing people and resources.
You can guess which companies and people were hit the hardest, when it turned out that all that software could eventually be generated by a machine.
And that if you make a bot that produces syntax you haven’t produced a programmer.
Some workers are more 1:1 with syntax, like a developer from a gig platform or overseas contractor, the deliverable being code files.
But the staff software engineer deliverable should be software, novel outputs, a face in meetings, someone to blame if it all goes wrong, a member to fill out the ranks, a person to get coffee with and talk about adjacent things that open new doors, in a sales capacity it might mean travel and interpersonal stuff like drinks and talks to convince people to integrate, it’s thoughtful often emotional back-and-forth from frustrated contributors on GitHub that lead to changes and innovations, and other things of value that language models can never do.
I would say further that even if you model emotional intelligence, or the whole world even, unless AI has a face I can punch if it crosses some line and it knows it has a face, what its own face is and why that matters to itself, it will always fall short in terms of empathy. Our sense of empathy and emotion originated in the wilds among fear and terror and the thrill of catching and eating food, discovering others, and understanding the consequences of everything before me in this moment.
>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.
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.
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.
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.
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.
I never had burnout from writing code; I had burnout from PM changing priorities every day or from tickets being half-baked. Also been burned out from being awakened that switch in somewhere in the Middle East had high CPU usage, which I was on call for for some reason (I wasn't on the network team, but that team didn't have bandwidth to be on call)
Writing code is easy; that's why I do it as a hobby on weekends as well. I don't have to sit through five arch review meetings that talk about how we are going to name the class rather than what the API contract is supposed to be.
Sure, writing good C is hard, and writing PHP (used to be) hard because language design is full of inconsistencies. There is so little "hard" code that I wrote for money. Plenty of somewhat harder things that I wrote for myself because it's entertaining. There was a time when I had to spend more time getting a pull request ready than actually writing code in that PR.
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.
This is a bit of a false dichotomy. The thing that isn't code (at least in some people's minds) isn't "requirements analysis". It's architecture, data modeling, deployment, inter/intra-team communication, triaging, prioritising, code reviewing, testing. It's all of software development, and not simply writing lines of code (which in itself can be hard of course.)
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.
The truth of that statement depends on what you consider as "coding".
The way I would define it, coding is to software development as cutting is to open heart surgery. It is the final part of the process after 99% of the decision making and application of experience has already been done. There is still some craft or "surgical technique" to it, but the hard part was surely everything that came before (requirements, architecture, design, etc, etc) that got you to the point where all you had left was a bunch of classes and fully specced out modules (and implied test cases) to code up.
I feel that some people, maybe including a lot of the people working at the AI companies, think that the software development job mostly consists of "coding", and perhaps in machine learning (not much code in an LLM!) it mostly does, but if you are a developer and define coding as the final "sit down and implement it" phase, then surely that is the easy part.
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.
For me the hard part is remembering the "long tail" of the stuff I don't use long enough for my brain to consider it worth putting in the permastore. So I just spend a lot of time googling stuff I already "know" how to do, because the frequency is too low.
It's not hard, it's just bloody annoying. And that's my favorite use of AI so far. Telling it what the code should do, and it translates that into language X's stdlib incantations.
I also find this to be the optimal level of AI usage. If I let the AI run around the codebase doing other stuff, then I need to spend more time and energy later catching up. Whereas, if I stay "in the driver's seat", ask for tiny changes, and approve them manually, the mental model doesn't never gets desynced.
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.
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.
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.
> 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 very rare.
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.
I think we should first define what “coding” is and whether “code” means “any code” or “optimal code”, because otherwise we’ll just keep talking past each other.
But I enthusiastically agree with your point about engaging with your output and having that deep understanding of all the intricacies and, well, you already said it better.
I also can’t shake the feeling that many hardcore LLM proponents are actually, genuinely worse at this than I am, and that’s simply it. In my vicinity, the loudest and most extreme LLM jockeys are all people who I personally don’t think are great engineers, or even that smart. They might be right in the end and I might be wrong, but these people definitely won’t become my role models anytime soon.
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.
> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
My take on that question is that programmers were in high demand because, for the last 60 or so years, it has been cheaper to write software for general purpose computers to automate things that were done by people and more rudimentary machines, e.g. accounting, manufacturing, music production, etc than it was to pay the people to continue doing those jobs. So, it continues a trend for programmers to be replaced by software, at least until something in the process breaks.
At its core, there is something difficult about programming. Fred Brooks talked about the need for perfection, Don Knuth about there being about 1 in 50 persons who had the mindset for computer science. But we haven't really been paid because it's difficult, we've been paid because we're cheaper than the alternative.
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.
> 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.
I like heuristics, but find broad statements are usually a bad idea in IT/Software. Developers in particular are very quick to find holes in logic.
When I think of code, I like to compare it to old complex physical machines. Think automaton. If you zoom in enough, what you see is indeed somewhat simple. But zoom out and the answer changes.
Then there is maintenance, manufacturing, tooling, etc.
I suspect that as humans living in a physical world, we understand intuitively the vast knowledge and skills required to design and build different kinds of machines. Software tends to hide inside boxes that look similar, but are infinitely variable.
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.
Maybe the future has those as two different jobs re: hard problems.
- The sorcerer: Have meetings with others until you know just how valuable a solution to this hard problem actually is, characterize it well, pool resources use cases and documentation, and then work with whatever wizard (or university thereof) is known to be able to solve that kind of problem. Have them find a solution to the hard problem and publish it. Use that publication as context, and have your LLMs integrate the solution.
- The wizard: Find hard problems with adequate funding behind them. Solve them. Don't worry about stakeholders or integrations--the problems are hard enough on their own.
It used to be we found ourselves jumping back and forth between sorcerer and wizard. But there are so many hard problems with solutions that are now in the training data for these models. A relevant skill for the sorcerer, besides the skills that are relevant in those meetings, is not solving hard problems head on, but being a sort of remixer of existing solutions to hard problems.
I think this would actually be better, because more hard problems would get solved in the open where they can benefit everybody, rather than ending up as IP-shaped ammo for zero sum games.
Most useful software engineering work is doing fairly simple things and the numbers of people doing this work reflects that.
> those of us who have had to solve open problems with no solution written somewhere because there is none.
Probably because solving said 'truly hard problem' is niche with little or limited value as few people have tried to solve it (otherwise a solutions will likely have been written).
"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 programmer" 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.
"If coding is easy, how come programmers were in high demand, and have demanded large salaries for years"
It's like saying 'Lawyers write documents!' for their job ... no, that's just an artifact.
Architecture, Systems, State, Integration, Algorithms, Pipelines, Platforms, Ops, Design, Communicating with other Eng, Working on a Team, Understanding Product/Product Marketing Requirements ... and of which the 'code' is just a small bit of the written part.
> 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 8 hour work day was quite a victory but since it happened long ago i would really like to see how health and productivity in each occupation declines over time and by task. I expect not just the obvious jobs to have quite absurd numbers and vary a lot from person to person. One might imagine a gradually increasing hourly rate, a decreasing one or a combination of the two. Writing code i could probably do 2x an hour per day. Much respect for those who can do full days. If we imagine there to be roughly 500 defined occupations it seems quite doable to measure how "easy" coding really is.
There’s too many dimensions to make broad claims like this and it always makes me wince a little.
In my career code was the hard part for the first few years. Then I got over the hump and everything else about my job was harder. Today code is the easiest and least interesting part. But I’ve also experienced in 13 years maybe… I’m going to say 2% of the world of professional coding. I bet if tomorrow I was asked to do some kernel optimization or make Postgres better or reverse engineer an emulator for some PLC something something, I would be deep into a land where code is the hard part.
I currently work on a glorified admin panel. The code should be the easy part. Unfortunately, the codebase is absolute trash. The code and the requirements are hard. My colleagues which drove the codebase to this miserable state think they’re developer extraordinaires. They don’t see the problems, at all. I can’t change anything and if I ask to be put on a different project I might be fired.
There is a half truth to code being the easier part.
In order to reduce the complexity of eventually coding something, you use modeling and code probes to validate the business model and then write the code.
This has been around since the days of batch programming and evolved through domain driven design principles.
The reality is the business can’t see that so they don’t invest in it and have no patience for it.
Agile wasn’t embraced because it was better. It was embraced because it was cheaper and faster.
Planning and modeling are the levers of complexity.
Ive been doing this for enough time. Code is rarely the hard part. Code rarely matters at all in my career experience.
Shipping a working service or product matters and theres a lot of ways you can get there. The upside of good code is usually in maintenance and extensibility but theres a limit to how much those matter in the grand scheme.
Coding something for the second time is much easier. Therefore, coding is easier than some other tasks in software engineering. Getting the spec is usually the harder part, except if following the spec is for really complicated products, like "one does not simply rewrite VIM" shows.
To be fair, the use of absolutes like "never" is a red flag. If the statement were "code is often not the hardest part", that's certainly plausible and debatable depending on context. The implication that coding is easy is what's offensive.
> 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.
Well it's easy to come up with code, not hard at all. But what kind of code? Does it work? And more importantly, can it be maintained and adjusted to evolving requirements?
Coding is easy just like writing is easy. What makes the difference is what you write.
i’d bet half of my normie programming career was spent capturing requirements, understanding the target domain problems etc for easy normal web development. once that is done code is a grocery list for 90% of it
I've always taken it to mean "coding is the easiest part of a developer's job"
That doesn't make it inherently easy, but it is the easiest part to automate.
A modern LLM is perfectly capable of maintaining decent code quality and architecture (provided you ask for it) up to a few thousand lines of code, but after that it very quickly loses the plot if you're not designing your documentation right and keeping a hand on the architectural tiller.
Architecture is about staving off chaos for as long as possible given the maximum functionality you expect it to achieve. That's hard enough for a human, with a deep understanding of your business, to do. Architectures that endure is a hard problem, dwarfing the difficulty of writing the actual code. Choosing what product to build is also a hard problem if you expect to meet any success. What it does, what it specifically doesn't do. Sounds easy on paper, and if all you're doing is Sunday prototypes it feels almost trivial. But once you're doing a real product with real consumers, it's a very different thing.
depends on the industry. but in consulting the hard part is dealing with customers who dont understand their own business and analysts who think writing software is rote factory work but somehow struggle to write a handful of coherent user stories not littered with subjective and ambiguous language
these two groups are telling me my time is numbered because of llm and ai when in-fact im struggling to see how ai doesnt replace them both
really good software engineers are expected to be experts in their job and that of the rest of the project team, these individuals are primed to be empowered by ai in a really disruptive way.
Code was never the hard part… once you made it to some level of advanced programmer. Then clarity, maintainability, etc. became the next tier of Maslow's Hierarchy of Coding.
Nothing is ever hard that you've done 100 times before and know how to do. Creating documented step by step instructions that cover all or most eventualities is.
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.
"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.
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.
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.
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.
Moving up and down the layer of abstraction is an orthogonal skill. The skill I’m talking is taking some axiomatic concepts (can be opcodes or functions from a high level DSL) and then build something using the given rules. I took basic algorithms as an example because they are trivial in the grand scheme of things while learning something like flask or Laravel involves too many concepts.
At the core, both involve the same formal thinking, but it’s easier with higher level concepts to have tangible results (it helps with the rote learning) than purely abstract ones.
After reading your follow-up comment, I realize I may have misunderstood some parts, but I think there is a slight difference in our fundamental perspectives. Still, given your context and your experience, your view is probably the right one for you, and given my worldview and my situation, mine is probably right for me. I agree with your points, and thank you for taking the time to comment. Even though our views differ in some ways, it's precisely because of those differences that we have these conversations—and thanks to your comment, I was able to organize my own thoughts. Have a great day. I always appreciate your thought-provoking comments
I really enjoyed reading your comment. I was reminded of a perspective from Patterns of Software, a collection of essays from the 90s by Richard Gabriel. The very first one talks about the ideal of "reuse".
"A similar idea [to libraries] is the Collected Algorithms published by ACM years ago in an ALGOL-like publication language. I remember when I was a kid in 1968 looking up algorithms for sorting and searching in my first programming job. However, what every manager learns is that reuse under these circumstances requires a process of reuse or at least a policy. First, you need to have a central repository of code. ... Second, there has to be a means of locating the right piece of code ... It does no good to have the right piece of code if no one can find it. Classification in the world of books, reports, magazines, and the like is a profession, called cataloging. Librarians help people find the book. But few software organizations can afford a software cataloger, let alone a librarian to help find the software for its developers. This is because when a developer manager has the choice of hiring another developer or a software librarian, the manager will always hire the developer."
He talks about a few reasons for why this is, one of them being simply that plenty of code for your project will just have to be new / different enough from existing code, so there's not much reuse benefit there. He qualifies that with performance concerns, but that's just one reason why it would have to be different.
Another thing I was reminded of, from the intro of Etudes for Programmers:
"Programming is a craft, and programmers must attain a standard of
craftsmanship. Much programming is done in cottage shops -- that is, in small
shops with meager tools, much work done by hand, and learning attained from
other laborers, by chance, and often not at all. ... the academics have also
discovered that a craft cannot be taught well by teachers alone; the guild
apprenticeships had considerable merit. In a classic apprenticeship the
candidate spent many years doing menial tasks while absorbing fundamental
techniques of the trade from more experienced workers in the shop. Gradually
the apprentice was given more technical responsibility and, after a formal test
of skills, eventually became a journeyman certified competent for all ordinary
jobs in the trade. The journeyman traveled the world and, if the muses allowed,
one day presented a masterpiece to the guild and became a craftsman of the
highest rank -- a master of the guild."
Seeking for the average to be that of journeyman, rather than apprentice, seems like a worthwhile goal for the industry. You sound like a journeyman to me, and I can generally trust other journeyman programmers. We don't all need to be masters to have an industry, and that's probably not possible anyway. You say you can't implement TCP congestion control -- but you can build networked applications. Building networked applications is an ordinary job of the trade, and I'm sure you know how to do it in a number of ways. I also suspect that if you had to create some custom UDP protocol for something, you would be able to implement some form of congestion control for it in not too much time -- even if that involves searching for and copying a known algorithm, or if you're lucky finding and using a pre-built library flexible enough for your custom needs. That highlights two more reasons for why we don't hire librarians over developers. First is that, if you're at a journeyman level, then you can be trusted to handle the rather common scenarios where you have to do something for which there's no perfect matching library or framework or SDK you can just use. Whether you have to roll up your sleeves and go low level, relying on very little, or just need to be able to tie enough separate preexisting things together with some minimal glue to handle the new/different stuff, they're both activities that require a programmer rather than a librarian. (I guess this is just further elaboration of the already mentioned "there will be custom code not eligible for replacement by something reusable" reason.) Second, the task of a librarian to find software has been made much easier since the 90s with things like search engines, massive communication channels to share and find out about stuff, and massive open source repositories. It's so easy now that developers themselves can do a decent job at it among their other duties.
To me, one of the most agonizing parts of programming is that whenever I think I have discovered something new and write down a good explanation for it, I inevitably find out that a pioneer programmer from long ago has already given the exact same phenomenon a much more elegant name. Your analogy of the Journeyman explains the model I was trying to describe far more gracefully.
I actually think all these industry issues arise because the ultimate role most programmers aspire to is that of the Master. They want to be the ones designing the rules, frameworks, and architectures that mass produce journeymen. In reality, a department head at a major tech company certainly holds a position worthy of being called a Master.
However, I believe being a Journeyman is a thoroughly valuable and respectable end destination in itself. The reason is that once someone becomes a Master, they drift away from the actual field. They start focusing purely on building tools for the journeymen, whereas it is the journeyman who generally remains closest to the actual consumers.
I read your comment carefully. Thank you for taking the time to reply, and have a great day. It's been a weekend full of things to think about.
This post misses the point about what has changed. It's not that coding is or was easy, it's that coding is _more than typing code_.
Typing is easy. Coding is hard. LLMs eliminate the typing and aid with all the other parts of writing code (where is the system that I want to mutate, how does it work today, debate the tradeoffs inherent in the potential plans of action).
What remains after factoring out the typing and the time spent assembling an understanding of code is opportunity cost. That's not an insult any more than memory managers are an insult to languages like C.
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.
> 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.
"Code was never the hard part" is the dumbest thing I've ever heard.
Making something work, has always been easier than making something someone can read. AIs also, seem to benefit from clean abstractions, appropriate code reuse, etc. (coincidentally, the thing they suck most at).
It's the same thing with english, except that english doesn't have a compiler.
Comprehension is the only measure of communication if you're talking about a human language. Programming shares the same goal. Both, often also need to do something else useful. Programming, and lawyering, have a lot more in common than people think.
We're creating a culture of sh*tting on codebases so the highest paid execs can cash out when things get tough. It isn't a new phenomenon, but it's one we'll need to endure until enough people lose enough money that the accountants start taking notice and start saying "you should be more careful, or you'll lose your shirt". In the interim, the people that care are working insane hours to try to protect the things they believe in from inevitable doom, and risking being fired to do it. There is a balance to both sides, and the jury is out on whether or not anthropic/openai/alibaba can save us from the future we are creating now with short-term goals.
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.
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.
It’s not that coding is easy, it’s more that coding was not the bottleneck in the process at large organizations. It was (and still is) getting agreement on what to build, meeting with stakeholders, and dealing with the ever-changing priorities.
A lot of people enjoy coding, it’s the rest of the job they don’t like. That’s why it feels hard.
If a tool was going to come along and automate away a huge part of a programmer’s job, I think most would want that tool to eliminate the meetings, ambiguity, scope creep, and administrative work… not the coding itself.
My best days at work were days with nothing on my calendar, when I could just put on some headphones and make something. At the end of the day I felt like I accomplished something and had something I could see and use to show for it; I finished the day happy and energized. Contrast that with a day full of meetings, fire drills, and busy work, where at the end of the day I’m mentally and emotionally drained, wondering if I should quit to stock shelves at the local grocery store. Which day sounds “harder”?
I don’t know about where everyone else works, but defining the details of what to build seems so hard that no one actually does it, so it falls on us as we build things. During one project I got a directive from the CIO (which has only happened 1 time in 20 years) to get what I was working on done in 4 weeks. I made all the decisions myself when it came to the details and had something mostly working in 2 weeks (I skipped all meetings and any other distractions during this time). Several months later, the bureaucracy came into play. The principal architect on the project, who I never talked to before the CIO told me to get it done, finished his design and some details needed to be worked out. One such detail was a port list. It took 4+ months of meetings to get that done, and it still required constant tweaking after that for another year. There was a half dozen other things like that in the same project. So yeah, the initial code was pretty quick and fun to write, and then it was followed by 2-3 years of hell, that probably should have been worked out before we started coding. I ended up having to go back and re-write a bunch of stuff to align with the design that was decided on over a year after the deadline the CIO gave me. In most cases, I think the updated code is worse, as the bureaucratic design creates a lot of operational work that my original design avoided entirely, but I digress.
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.
interestingly ai has reignited the craft of performance and efficiency in programming. overall in the macro timeline i think the profession is going to be in a better place
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.
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...
> 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 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.”
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
I mean, yeah, we are pretty trash without years of domain knowledge. But programmers do have a large domain. Some are experts at a/v, some security/networking, some like to make games/demos. These domains were highly accessible to us and still are. It's not like we solved coding exercises all day when we weren't leasing our souls to companies.
In which world are you living? For most programming jobs, the code is absolutely the easiest part of the whole thing, which is just gatekept into absurd bureaucracy and ceremony. Even if coding became 100x faster with 0 errors tomorrow, the software in most companies would still move at a snail's pace.
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.
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.
> Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs?
Programming used to be a rare skill. Not so much now. In fact, it hasn't been for well over a decade.
My current employer started aggressively hiring for programmers in India in the early 2010s. They get paid a fraction of what our software engineers do in the US. There are many talented engineers in India, and those who get hired by us either find a way to come to the US for an enormous pay increase, or use us as a stepping stone to quickly find better work. And my employer is seemingly fine with this. They expect these cheap employees to do programming, not engineering.
Programming may not necessarily be easy, but it is cheap. It has become a relatively common skill, driving down its market value. A lot of tech companies were slow to figure this out because times were good, interest was low, and investment was flowing.
AI is waking people up to a truth that has been around for a while now.
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 software world has an abundance of mediocre coders that just happen to be good at writing e-mails, meetings, architecture (but not really), powerpoints, navigating customer requirements and product design. It’s in their interest to downplay coding skills.
While the former can certainly be challenging, it’s by far not rocket science. Any reasonably intelligent human can discuss requirements or design a product at a decent level.
Writing code at a decent level is beyond the average reasonably intelligent human. If your mind doesn’t tick a certain way, you will not be able to do it and it will be painfully obvious to anyone that can do it.
Depends on what you work, if you optimize algos and low level stuff I think it's an insult if you're like 95% that have fairly easy issues and just juggle data around it isn't and code has never been the problem. Even now the issue where I work is the actual solid requirements and technical plan before the implementation. I move higher up to something like architecture/rm since AI coding is pretty decent and does the job.
I have met many programmers throughout my career, and very few of them want to talk to stakeholders, much less customers (exceptions are freelancers and founders, especially of software development shops). And, “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days”.
Then you have met many programmers but very few engineers. The kind that want to avoid thinking about the wider context and only be told what to do will never progress past a mid-level. By the time you get to staff+ it truly is never about the code, and there's a reason why staff+ salaries are an order of magnitude higher than mid-level ones.
I think the statement "code was never the hard part" is true but it's relative.
Programming is not easy and it takes years to master. Some people became really good at solving complex programming puzzles and 'Code Jams' and focused on it. Unfortunately, the same aspect which made this skill highly visible and highly praised, is what made it easiest to automate.
All those medals, trophies and certificates... not the mention advantages at big tech software job interviews... Came at a cost.
Meanwhile there is a whole group of people who have been honing their skills in software design, architecture, distributed systems, security and other less visible, less rewarded skills who have been ignored by the markets. These people still can't be automated.
It's a large problem space so after a decade or two, the coding aspect feels small relative to all the theory and experience surrounding it.
I met many senior people who didn't take programming seriously as a skill, long before LLMs.
One time, when I was at university, one of my math lecturers was boasting about the superiority of math as a discipline and said to the class "Software engineers... There are no software engineers; they're programmers."
That statement was never true but it's much more obvious now. The fact that a lot of people shared this belief highlights the fact that these other skills were invisible.
There is probably as much engineering (if not more engineering) involved in delivering a complex, reliable software project as there is delivering a complex skyscraper project in civil engineering... It's the same kind of activity; lots of interdependent parts, each with their own constraints and requiring many decisions to be made with lots of tradeoffs. At least with a skyscraper, the customer requirements are relatively very stable.
Too many people on hacker news sound like blacksmiths at the beginning of the industrial revolution. Get with the times, artisanal handwritten code is worthless
Sometimes coding is hard. There are two types of hard things: algorithms and architecture. LLMs are good at algorithms, not good at architecture.
Most of the time coding is not very hard, it’s filling in the blanks, implementing the business logic, writing boilerplate code. LLMs are good at this too.
Saying AI can do all the code isn't even accurate either though that's what's weird about all these takes
As soon as the context builds up high it just starts doing things straight up wrong
I've been trying to network a simple tactics game with AI and it just is a hydra of sync issues despite clear explanations of what they are and bug reports and desired end-states.
> 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.
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.
>If coding is easy, was Carmack just at the right place at the right time?
Yes, it's fairly axiomic that he was "just at the right place at the right time" because there are dozens of modern "boomer shooters" on steam that are not nearly as successful as DOOM or Quake. You might counterargue that its always harder to do something thats never been done before but that would only be a tacit admission that coding actually was the easy part in that case.
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.
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.
> 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.
Code really is the easiest part. That doesn't mean code is easy. It means everything is hard, and code is just the least hard part. The best programmer in the world will still create bugs. Therefore you need something else to account for and deal with the eventual bugs.
In the rest of the engineering world, the way you do that is by standards bodies developing reliable, tested, certified methods to build things that avoid common problems. Pipes that are certified to a certain PSI or UV exposure. Wires certified to a certain amount of amperage, wetness, heat. Nails certified with a certain metal grade, tolerances.
Those standard parts are then used in a certified building method for a specific application at specific usage criteria. 3x 12d nails in one kind of wood joint. Beams spaced 24" apart, with 3/4" CDX plywood spread load. You don't guess or follow trends. You don't do what you think is "clean" or "beautiful". You solely follow the engineering standards and code. Now you don't have to think much, and your results are highly reliable. The job becomes easy.
Software doesn't have professional engineering and building standards like that. So humans literally just make this shit up as they go, making software however the zeitgeist of HN says "feels good". This results in unpredictable, unreliable software products that are hard to build because nobody agrees on the "right way".
Somebody read a blog post, or a slogan or quip on a Wikipedia page, and decided on their own interpretation of how that generic advice would drive their work. Software engineers only talk to other software engineers, so they don't realize how incredibly unscientific, inefficient, unreliable, and difficult their work is. Trying to make something predictable and reliable is therefore very hard. Not because writing the code is hard, but because the entire software product lifecycle is basically vibes. The uncertainty, variability, and lack of reproducible standard parts makes figuring out how to build something become way more complicated than it should be.
The actual lines of code are easy to read and write. But without the standards common to every other engineering discipline, the rest of the job is a slog.
The software development profession is in the midst of upheaval. Nobody knows how the AI revolution will play out in the end, but it is clear many aspects of work and life will be transformed—including programming.
I'm still not seeing it.
I'm seeing a lot of loud people, a lot of LOC produced, and a lot of people angrily pointing to their sideprojects... but no massive impact outside our bubble. Remember it's 2026, we are 5 years into this hype, the models are better than ever, and all the software we used around us is basically in the state it would have been in had we projected 2021 tech 5 years into the future ("in 2026, there will be... another backend JS runtime!")
I'm afraid all the personal anecdotes of technologists have not translated to real world results... other than negative ones like GitHub now having 0 9s of reliability.
Of course I suppose I'm "coping", as if I wouldn't be over the moon if AI had made me 10x productive... but maybe, just maybe, a lot of people really like talking to chatbots?
Hmm, hasn't "code was never the hard part" typically been said when downplaying the impact of AI-assisted coding, rather than highlighting it for marketing purposes?
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.
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?
Fun example I've had (some weeks ago), Agent completely dismissed the lack of strong consistency in our db system, this tiny bug would have caused a massive problem in the future.
A bug that is not immediately obvious, no syntax error, logic is sound, works as expected on local and QA envs. But let it run in prod for 2 months and you have a massive problem.
I'm not dismissing LLM's here btw, just pointing out that there is probably a lot of things that go into the category "you don't know what you don't know". These kinds of issues may or may not be a problem depending on the business you are in.
Most of the time the latest models perform better than I expect.
Ouchy. That isn't as bad as the slop I've seen: one example I saw a few weeks ago from vibe-coded software had this absolutely mind-blowing bit of Rust code:
No, I'm not joking either, this is actual code that Claude wrote (and I'm pretty sure it's the latest models too but I don't actually know for certain, since the "dev" never specified). This idiom is repeated about 238 more times through that one file. I have tried repeatedly to help this person out but they're the kind of vibe-coder who thinks they know best, and who will take your advice and drop it into CLAUDE.md verbatim, and then Claude will go off and do the most literal interpretation of that text and not best practice.
To be clear, I don't hate LLMs. They're really useful for very specific things or where you know the domain very well. But then I see slop like this (and the dependency many people have on them -- I have literally heard my own close acquaintances say that they could not see themselves without a Claude subscription) and it really hammers home that software quality is not at all going to get better because of these things unless something changes.
Yeah, trying too hard to guide with hard rules, instead of asking the LLM for self-review, is going to go wrong. The LLM is much better at code review than it is at writing code.
Use a high effort model and let the llm review it's output and figure it out on its own.
The code still won't be great, but it'll be good enough.
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?
No, I didn't. I asked you to provide me an example of code that you had generated via AI that might survive in such an environment. But if you re-read my original post, I also gave you an escape hatch: just code that was correct. Not even formally.
I'd say your refusal to provide any examples of your original claim is pretty telling, and your reasoning is pretty convenient for you, now isn't it?
Edit: also, I'd like to point out that it was you who used the word "software" as a general claim. You never specified what kind of software. Since you continue to expect me to derive the proof for you instead of you providing the evidence, I don't see any need to continue this discussion since nobody is obviously going to learn anything. I'm sure many of us here would love to learn what secret sauce your using that makes software engineering so trivial, but you don't seem willing to actually provide that.
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.
IDK, a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code. Those performance problems start out not mattering much, first it impacts one seldom-used part of the site, then another, but that chips away at users and can eventually tank the product. That doesn't even get into writing code such that it can be well-understood and modified easily later. It also says nothing about reducing/fixing bugs.
If you have a site whose performance steadily gets worse and the rate of new features steadily declines and the rate of bugs steadily goes up, then your site/app will probably not have a great future.
All of those things depend on solid code. If staff engineers who are too busy talking and building consensus such that they aren't connected with the actual programming and situation on the ground, then all the talking and consensus-building won't matter.
> a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code.
On those complex systems in particular the problems start long before any code is written.
A software engineer can create and understand the specs, requirements, design the system, architectural decisions, define everything about that software and data, model everything, failure, performance, operational topics, documents everything, etc. before a single line of code is written, and of course they can write good code. Then there are the coders who patch together chunks of code from Stack Overflow or whatever boilerplate they have in the company's repository. I know every coder likes to call themselves a "software engineer" but there's a world of difference between the two types.
For the first group code was never the hardest part. For the second group there was never any other part.
I think most people who write code are the latter and not the former. The industry has diluted the term "engineer" so much that they maybe don't even realise that traditional engineering projects are about more than just implementation work.
No they can’t do everything before writing a line of code. The design and requirements feed into the code and vice-versa over and over through the lifecycle of a piece of software.
Some architecture work and design will be done beforehand, but many details will fall into place as the code is being written, thrown away, adapted, etc.
The idea that code is mere transcription - which I see a lot in these AI discussions - is completely false. Code is a form of low-level design and is where the rubber hits the road.
The best requirements, designs, marketing, etc are worth jack if one fucks up the code. The code is the actual product.
> but many details
Which part of my list was just "a detail" to be dealt with at some point in the lifecycle (but only if you're not too busy shipping features) for you? You're laying bricks before knowing if the wall's supposed to be concrete.
> Code is a form of low-level design and is where the rubber hits the road.
Sure but in keeping with your analogy tires are fungible across most cars and it takes minutes to change one if you picked the wrong compound. It takes years to properly design a tire, not to speak of everything that sits on top of those tires. By the time you actually "meet the road" you already defined to a tee what you want to achieve from every perspective and everything you do is to meet that goal, even if you have to make tweaks. You don't find out if it's a scooter or a roadster tire while working on it.
> The best requirements, designs, marketing, etc are worth jack if one fucks up the code.
Why are you mixing some fundamental things which are essential and can't be changed along the way without massive effort and risk, if at all, with things like marketing?
Do you want to aimlessly write code while chasing a target that moves randomly and conflicting because your plan was to define things "at some point"? You're really making my point with your insistence that it's all about code and every other fundamental thing is "a detail" that just comes along the way.
No part of your list was just a detail, but all parts of the list consist of essential properties and details. As I said, many of those details will fall into place when one starts implementing the core architecture.
It also matters a lot what scale one is operating at. Bigger scale will require more effort up front, PoCs, several big iterations, etc.
To give a smaller scale example, I defined a general simple protocol for two local components, picked the IPC and defined the handshake and teardown sequence. The developer defined the message contents. Reviewed together, then it was implemented. Testing showed that component B, which was OSS and had a fixed rate was sending too fast so the developer patched it to do debouncing.
Coding is nothing like changing tires. To abuse an incorrect analogy even more, the architect would prescribe the properties of the tire or even the behaviour of the vehicle and the developer would design and construct the tires/tracks/whatever either from existing parts or from scratch. Possibly going back and forth on the actual means of locomotion.
To wrap it up. Requirements, architecture and design can be changed. When implementing features I always do architecture review with the team and adapt it based on their feedback. We have rejected or negotiated requirements based on PoC or just developer evaluation.
Sometimes that doesn’t work, sure. If it’s a critical feature or there are hard architectural restrictions one puts in the dev work to figure it out and maybe this leads to a non-ideal implementation. Fundamental mistakes at requirements or architecture level do have higher impact, but iterating and having a good arch <-> dev feedback loop is one of the best methods I know to tackle that.
To give another example, I investigated the potential implementations for a feature and prepared a list of technical approaches sorted by specific architectural attributes. The dev team wrote the code to validate them and option 1 turned out to be impossible because of platform constraints. I adjusted the architecture to use option 2.
In my experience, the parent's view and your view are an example of the divide between the Silicon Valley / startup mindset -- it doesn't need to last, it just needs to get us a paycheck so we can go on to the next paycheck -- and actual software engineering where people build resilient systems meant for humans to use for a long time.
There's a conflation too that to approach things with this level of thought and care requires waterfall design (it doesn't), so people shrug it off or resist because if you want to think carefully and design thoughtfully you can't also Move Fast and Break Things.
Ironically, we all complain about enshittification.
How does not everyone understand this? It's why waterfall development never worked.
I would counter with it's easier to fix bugs, improve performance, pay down technical debt than it is to fix consensus, stakeholder buy-in, and strategic direction. So even though good code, design, and architecture isn't easy it's still the easy part in a relative sense.
That’s because fundamentally you need those strategic items to have space to do those particular detail items. If you have the best strategy and no execution, you can probably hire for that. If you have no strategy and decent execution, you are driving the Titanic into the iceberg.
> stakeholder buy-in
Fixing bugs, improving performance, paying down technical debt all require this as well, which makes them significantly more difficult to actually implement.
Yup. And performance problems don't just bleed the user base, they also slow down development and testing internally, both directly and by nudging developers away from attempting some tests or use cases in the first place.
I can understand when people say the code was the way part, but under the assumption that the system design and architecture are clean, code is high quality or the project is greenfield, and there is proper testing and validation. Then, sure, the lines of code aren't the hardest but that's only because that hardest work was front loaded and given a different name. Even then it's still not always easy.
Getting to a state where those assumptions are true is HARD. And takes a lot of careful programming.
Yes. Once it is true, the code is easy to write. But only because a lot of effort went into making it easy. And keeping it easy is also hard. Without focused effort to keep the code clean and easy to modify, it starts to rot.
> IDK, a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code.
I don't think you're really disagreeing with the original sentiment? However, I think you're taking a much broader view of "code" than is intended by the original statement.
In your framing, you're kind of confounding code with architecture. Code is really just the act of making a computer do a thing you want it to do, for some definition of "thing you want it to do". Architecture is more about understanding which things you want the computer to do, and in which ways.
There are a million ways to code a task. That's the "code" the original statement is talking about. Understanding which of those ways is an appropriate way is a separate skill, whether you call it architecture, or something else.
You've really seen a web software product die because of performance issues?
Healthcare.gov was a national scandal due to poor performance related to bad requirements gathering.
The $32M Hertz scandal
The $480M bug that killed a trading company in 12 secs
Challenger
Probably a bunch of stories from healthcare
Web software I don't know but there are many "modern software" that were meant to replace COBOL code running on AS400 that ended up never making it to production because they were running so badly and projects ended up being money pits.
Friendster
Wave waves at you from the grave.
Did Wave have performance issues? I thought it was amazing, they just killed it because it didn’t have enough adoption
Yes, it is hardly ever the web-side of it though.
Knowing what to do “wrt the code they write” is directly consequential to knowing what do at all, you proved the original point correct.
yea, a lot of my prior work was in the "code is the easy part" I was a frontend engineer for years. And something like 90% of my job the code was not the hard part.
I loved writing GPU shaders or optimizing visualization performance, but most of the time it was wiring up netcode to UI elements that exist.
Ironically as I've moved into focusing on more GPU and kernel programming AI is now lapping me there anyway, however the impact of knowing what sort of algorithsm are state of the art in papers, what is causing memory bandwidth issues etc... does a lot to drive the machine.
I'm yet to work on an enterprise project where programming is beyond simple validation, simple SQL, simple sheduling, simple mapping, simple error handling. Might be more about web backend than the whole field, but the challenge always comes from formulating requirements in a rigid form with all edge cases considered.
This might be the reason why many personal projects are so technical and impressive - it's the itch that's not scratched at work.
This is one of my theories why AI is well-suited for these kinds of projects. It's mostly CRUD, written in well-known patterns. This not to discount the programmer or the job in general, it's what the task calls for.
Scientific programming, hardware interfacing, embedded, demoscene, game engines, HFT or HPC calls for much different breed of code, and generally way harder to formulate in code w.r.t. these enterprise projects. Trying to make hardware go faster with more efficient code is much harder than optimizing an SQL query and safeguarding it, and these are well understood problems, in general.
Yep, LLMs excel here because most of the time analogous solution is already in the codebase. Most of my initial promtps include "look how it's done in X and do the same".
It depends what you mean by enterprise project?
If you just mean a large company, I would say they do exist - though it may take some looking for them.
You can find them in companies that have to deal with "real" things (hardware, factories, production lines), or where there is an interest in taking advantage of emerging technology (advertising, e-commerce)
I would call my current project relatively systems-level too, as it's a network proxy. Not quite kernel level but definitely not trivial "if this then that" style coding.
My perspective is that application programming - CRUD, forms, IO orchestration - was always vulnerable, even before AI. Think about APIs for payments, APIs for subscriptions. E-commerce in a box type solutions.
That's why I always pushed to do more systems level work, on more exotic or weird technologies. It's not because I think I'm a better programmer, than someone slinging Spring code or React forms. But because in this industry it's better to be a goat than a cow.
> ...it's better to be a goat than a cow.
That's the first time I've heard that idiom. What does it mean?
Trading systems? Most complex things I've worked on.
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.
The percentages are different for different types of SWEs, not all SWEs spend 80% of their time on XFN comms. I agree with your larger point that a non-trivial amount of a SWE's time is spent on XFN comms and team alignment. My argument is that if an individual contributor is not spending a majority of their time on problem solving and implementation (including maintenance of legacy code), they are not maximizing their potential. If they are spending 80% of their time on non-coding activity they are better suited for an Manager role (Engineering or Product). At the end of the day, coding is not hard only if you are a good coder to begin with. If you are a good EM/PM then people issues will not be hard (which coders often complain about).
I feel like almost every standout product in the world was a result of someone with good instincts and not the results of XFN communication.
Unfortunately it is still the job...
A big problem with online discourse about programming if that so many people are in bubbles that they think are normal and think that anything outside of their experience is niche and rare.
‘Enterprise’ software includes SaaS, internal LoB software, integration work, and a bunch of other things I can’t name. The LoB and integration work is usually boring from a technical point of view, so articles don’t get written as much, and they likely wouldn’t do as well on HN, compared to something highly technical about scaling something to serve millions of users. There’s probably many more hours of work, and more programmers, doing LoB and integration, but people in a SaaS bubble don’t see what happens elsewhere.
About halfway through my career, I spent about 10 years working in the enterprise SaaS/PaaS space. 6 as a developer, ~4 as a product manager. Both sides of that coin are difficult. Trying to create a product strategy that meets the needs of hundreds of large companies is a special kind of hell. And on the dev side, even "simple" things are not simple when they have to be implemented at scale, software updates cannot break existing customer code/configurations, and customers must have a hundreds knobs and dials and scripted escape hatches to implement their own business logic.
Even when code was not the hardest problem, it was still a hard problem.
Mostly this. The phrase "code was the never the hard part" touches on a larger culture war. I was I was moving up in the ranksit was common to see people, both myself and then watching others, say things like "I just want to code".
Coding was the job. But there were diminishing returns in that getting better at coding wasn't as impactful as getting better at all the social skills, big picture strategy, and general scheming.
Maybe "code was never the hard part" should be replaced with "coding wasn't the most important part". But I think we all know what it means. Those higher level skills are the things that LLMs can't do, at least for now. Coding? It can do that, at least sort of.
It's exactly this - "coding was never the hard part" translates more directly to "coding was never was slowing me down". It's nailing down requirements, it's cross-functional team meetings, it's planning the testing and rollout, it's integrating with all the other parts of the product and systems, etc etc etc. Optimizing coding was just aiming at the fastest part of the job already.
> 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.
The really hard part of this does in my opinion not so much lie in the aspects that you describe, but rather in doing this without leaving scorched earth with most/all of the stakeholders involved.
In other words:
Doing what you described is in my opinion something that can be learned, and in my opinion a central reason why many programmers consider this to be difficult is that they never learned it, and/or (related to this) were never given the opportunity to be responsible for all of this, so they lack experience.
On the other hand, navigating the whole office politics, and running the political gauntlet that is collateral to it is hell on earth. The only way to survive this is to give a big "fuck you" to everyone, which I more politely described with "leaving scorched earth with most/all the stakeholders involved" above.
Writing some code that actually works for the problem at hand, can be fairly easy.
Writing code that does this while being clean and efficient is a lot harder. How many slow, buggy programs have been written because the assigned programmer did not yet have the expertise needed to do it right?
IDK, I worked like in ~20 enterprises and I didn't really see what you describe.
"Navigating customer requirements" is mostly everyone speculating on customer needs and pushing the part they own, and whoever happens to get closer to the higher management's ear, wins. Then market decides if that's is a good thing or bad thing. If it's good, normally the person who pushed this doesn't even receive credit for it, because either the command chain too long or the stakeholder's memory too short and postfactum everyone pretends they authored good decisions and opposed bad ones.
It might be tiresome and exhausting, like all intense politics, but it's not hard in any technical sense. Most mediocre people can do it and do it.
For something to be hard and complex you need rules and professionals on all levels who understand and follow the rules and driven by meritocracy alone. That's simply never the case.
> 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
True. And there is another angle: ownership. The author also said “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days”. This is like saying that a programming language designer does not own the spec of the language itself but just wants to write hte compiler. I find such altitude counterproductive. Case in point, many companies hire PMs for their internal infra org. I mean, shouldn't the engineers in the infra org know exactly what they design to build? If you don't want to own what to build, you end up letting someone else tell you what to do, except that the person is neither an expert nor even your user.
The infra org has to also understand their internal customer!
And that should be the engineers' job instead of outsourcing it to PMs who do not even use any of the infra services -- I'm not insulting the PMs, of course, but to state a fact. Infra is used to serve the internal engineering teams, and the PMs don't code, so they don't have a need to use the infra.
But do the infra team engineers use the infra they're building?
They do, and they help their users all the time
I've been programming for 30 years and "Code was never the hard part" does not offend me. It's something i've been saying for a long time. You can teach anyone the mechanics of coding well in like 6 months.
Programming is the hard part! I want to make this distinction because to me programming is about solving problems and coding is a way to express the solution.
Designing algorithms, architectures, etc can be done without a programming language. Coding is putting it down into some language.
Sometime in the past 10-20 years there was a prestige shift where people started using the term "developer" for what you're describing as "programmer", relegating "programmer" to what you're describing as "coder", and "coder" to "hobbyist programmer/developer" (while weirdly "coding" remained colloquially the thing programmers do).
Advice to job seekers I remember in the 2010s was to not call yourself a programmer because that was where the bad "code monkey" jobs were, but it hadn't yet been much of a thing when I first started looking at the end of the 2000s.
These waves where someone found a new way to focus on the valuable part and leave the grunt work to lowly others comes again and again. As always the truth remains that each step in the process is relatively trivial and is is the overall complexity e2e and scale and handling edge cases that are where value is created. But that won‘t stop groups trying to differentiate themselves by looking down on others even when it is clearly failing. As long as there is a benefit to the group driving it.
I have called myself a programmer for most of my career. I have no concern about prestige.
I think some people are talking past each other because programmer/programming means different things to different people.
I like Dave Farley's classification of Coders, Developers and Software Engineers.
https://www.youtube.com/watch?v=fcjBfSiyI0k
I've also been doing this professionally for about 30 years, plus another 10 as a hobby/learning before then, so I think I have much of the same experience as you, and I do agree. Although, I think with the advent of LLMs, programming is no longer the hard part. The hard part of programming is the convergence of context management for humans while also presenting it to a computer to do something. Much of data structures and algorithms "best practices" are ways to efficiently get your work done as well as keeping it so that a human has context.
For example, one guy I used to work with wrote this really awesome algorithm about 25 years ago, and I'm responsible for maintaining it since he long retired. I can't go into details, but this is the core algorithm in moving billions of dollars between institutions overnight. It's about 10 screenfuls of c that had been converted from the original FORTRAN 77 with dozens of gotos and weird branching statements and about 20 parallel arrays that store indices for pointer chasing. It's almost impossible for a human to follow (I've actually fed it to an LLM and said rewrite this with for loops and no gotos so I can understand it - and it worked!) but it's blindingly fast. The actual problem it solves can be stated in about three sentences, but programming it was hard because of the context management. The reason that my company keeps getting royalties on this is that it's so hard that they'd rather pay us than write it themselves. But I bet an LLM could write it from scratch now.
So maybe programming is no longer the hard part, or at least context management is no longer the hard part and that humans should move up the chain to help manage the context for LLMs so they can get more done efficiently.
Switching topics a little...much of what I think makes coding the hard part was the tension between big-design-up-front and you're-not-going-to-need-it philosophies. Early in my career I worked in health care and that was BDUF and the coding was easy because program managers spent years defining every screen that would be shown to the users, what queries were needed to fill the screen, all of that. We just took the spec and coded it. Coding was easy. But the failure of BDUF was that it still didn't really match what the customer wanted.
Then enter agile and YAGNI, in that limit, coding is easy, just write what the user story says. But then you have to refactor from what was left behind on yesterday's user story. So smart engineers would cheat a little with YAGNI and say, yes we will put an abstraction in because the next user story. I would say that "good engineers" or "good coders" found that balance in abstraction to move fast but make abstractions not overkill. And I think that's what all the wailing and gnashing of teeth is right now: the good engineers aren't needed anymore.
I can tell an LLM to code something, and as I add complexity it's happy to refactor and manage the context so we don't need to worry about "clean code" or "quality code". As long as what the LLM writes meets the spec, then we're happy.
Ah, sorry long rant and ramble. But I just think the "hard part" has been managing context, and the context we're managing context is just changing. Those good at managing context will be good at coding with LLMs, and those that weren't won't be.
This is a very good comment, one of the best i've read here.
> I would say that "good engineers" or "good coders" found that balance in abstraction to move fast but make abstractions not overkill.
i think this is spot on and could be where the concept of "llm's have no taste" comes from. There is art (and science) in determining the right level of abstraction that satisfies the user story in a performant way while leaving the door open for extension.
> As long as what the LLM writes meets the spec, then we're happy.
going back to just meeting the spec vs the art of perfect abstraction is a bitter pill to swallow and I imagine removes a lot of the joy some found in software development.
I said this in another comment a few weeks back - but, at least for me the "joy" of software development was describing what I wanted and getting it. That used to mean fighting with code and trying to be clever and clean or following the right design pattern. But now, I get "joy" from using English to describe my problem and getting the right answer. When the LLM one-shots it, I get the feedback that I'm describing things correctly and clearly. I'm still getting the same joy just in a different form now. I'm old enough and have been doing this long enough that "giving up writing code" is not sad for me. I'm still expressing my ideas, just differently now.
Not just the right level of abstraction but the right choice of abstraction.
the article means code as a whole not just the moment you input some if else in a screen but the whole act from thinking about it to make it live in prod.
> You can teach anyone the mechanics of coding well in like 6 months.
You can absolutely not do this
I don't even sit in front of a computer to write programs, I do that in the car.
I type them in when I'm in front of the computer.
All the actual work though? That gets done in a space where there's no phone, no people walking up and talking to me, no distracting social media, no screens, just quiet-ish and a couple of hours to think.
> 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.
"carefully architected solution" is not what they are saying. A "buggy big ball of mud" will not generally "do the right thing", if it did, it would not be a "buggy big ball of mud". Straightforward requirements do not imply straightforward solutions. In the early 2000s Facebook wanted a quick way to search for friends updates, a straightforward requirement. Turned out they had to build a full graph DB inside MySQL, not straightforward code at all.
> In large corporate environments with multiple international customers, code is most of the time not the hardest problem.
This is true, and this is the thing that makes me want to not be part of this dumb system anymore. If leadership on the same company can't align, that shouldn't be my problem, and I hope they get replaced by AIs that can.
Humans suck.
Would add this is not exclusive to large corporations either. My smaller employer is also struggling hard because leadership simply cannot prioritize. Everything is either not being worked on or is the highest priority which in practice just means nothing is the priority, and no matter what myself and my team work on always seems to be the wrong thing.
It's absolutely devastating to team morale. We never feel like we're contributing.
I'm already unfazed at that part and don't care.
What devastated me this week is that I was slogging so hard for the past several months trying to deliver on what I was asked to deliver on, only took 1 week of PTO out of the 4 weeks I have saved up, spent nights and weekends trying to honestly solve multiple high priority yet HARD problems that 500 other engineers in the company couldn't solve, I'm making good progress on a couple of them single-handedly, yet my manager, who just came back from 3 weeks of vacation just gave me a performance review saying I am not meeting the "bar" for my level and need to do more cross-functional work and amplify my "impact". He's going on vacation again next week to watch the eclipse.
Fuck this. I want to travel, I want to enjoy life. I used to chase eclipses, too. I tried my best, all I ever get is "what you are doing is not enough". What the hell IS enough then? I already don't take vacation and don't exercise, I've put on 7kg of weight since I joined, yet you told me THAT is "not enough". Should I stop sleeping and eating?
Change priorities all you want, honestly I really don't care, and I've dealt with customers too, it happens. Just don't tell me I didn't get anything done. Recognize the fact that I tried hard every time you changed your priority, and I only had 2 months out of 8 to work on your latest priority, and calibrate your expectations to 2 months of work, not 8.
The fact the everyone is fighting just to define what AI is doing to coding is a sign that most developers are just terrible at their skill.
I think it could be summed up with "it being easy part of the problem doesn't mean it is easy, just *easier than the rest"
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
"easy" and "easier" have very different meanings.
I've read through these comments and, as is typical of HN, virtually none of them refute or even address the points made by TFA.
> 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.
> Likewise, coding is easy. It's just writing, and any child can learn it.
Any teacher of a low level CS course knows this is completely untrue. In my CS 101 course our problems were relatively straightforward and short, and lots of people struggled mightily to the point of dropping the course. IMO coding requires a particular way of thinking that a large subset of people just aren't good at, and as someone whose done tons of screening interviews at college recruiting fairs where I give relatively easy problems and ask someone to code a solution, I will tell you the idea that anyone can do it is just false.
English is a hard language to learn, especially as an adult. So many weird rules that everyone takes for granted.
Many still struggle with getting fizzbuzz right.
Why does it have to be Shakespeare? There are millions of good writers that got there by working hard. Seems pointless to go into either extreme, when just being good at anything is generally hard.
It doesn't have to be Shakespeare, but hopefully everybody agrees that writing at Shakespeare's level is indeed hard. I agree that writing good (but not great) or even just ok literature is still hard, but that invites a bunch of no-true-scotsman arguments that I just can't be bothered dealing with (like "writing Fifty Shades of Grey isn't actually hard" or something similar).
The comment I responded to suggested that we don't really have to be "insulted" because code is actually not hard, good code is hard. But the statement "code was never the hard part" doesn't make that distinction, it's a blanket statement, that any normal person would associate with all software. I argue there is no reason to try justifying such a misleading statement.
Completely agree. I feel like lots of comments in this thread are getting side tracked by useless nitpicking, e.g. "Writing code is not hard. Writing correct code is." - oy vey.
In it's original context, it's very clear what "Code was never the hard part" was referring to, that of all the steps of product development (ideation, requirements, design, implementation (coding), deployment, operations, maint, etc.), that code was not the hard part. That's the meaning we should be discussing, and I agree with the author, I believe coding very much was the hard part. Since Jeff Dean and Sanjay Ghemawat were recently in the news, I recall some stories about them fixing issues with the search index in the early days of Google where there were random bit flips that were causing the index to be corrupted, and they fixed it and coded a durable solution. This is very much just a code-specific problem that very, very few other people would have been able to solve.
But I must insist: "building a car" is not hard (millions of children do so every year with Pinewood derby style box car kits), building a "real car" that you can use and that passes regulations is harder, but knowing the difference between the two is where the real hard work is.
The truly difficult work is knowing when your client/boss asks you to "build a car," do they really just want/need a small Pinewood derby box car as a toy, do they need a four-door sedan that can legally drive on major highways, an 18-wheeler freight truck, or do they actually need/want a bicycle, or a shopping cart, or a railroad box car, or information about how to take public transit that will serve them cheaper and easier than anything you could build in their timeframe and budget.
That's what people mean when they say that code was never the hard part.
I get what you're trying to say, but coding is hard. A significant percentage of children struggle with it from the very beginning, unable to reason in a very specific way, read and understand errors, trace incredibly detailed logic, gain mental model of memory and state, etc. According to these[1] sources[2] computer science has the highest college drop out rates: ~10.7%. I worry that "code was never hard" is going to become a misleading truism for business leaders.
[1]: https://missiongraduatenm.org/college-dropout-statistics/#:~...
[2]: https://www.coursmos.com/college-dropout-statistics/#:~:text...
> I worry that "code was never hard" is going to become a misleading truism for business leaders.
The fact that children cannot do it does not mean that it is particularly hard, and computer science attracts a lot of people who just like video games and have no mathematical ability.
I think that the fact that programmers were/are doing a lot of the job that other positions take credit for is significant. Others can get by on bullshit, but the programmer's job in turning that bullshit into code forces them to make something real out of it through a combination of back-and-forth interrogation and just making it up when necessary. Turning handwaving into a product is a skill that programmers have, and is why AI isn't helping tech-illiterate businessmen create things that work.
> Writing code is not hard. Writing correct code is.
Now add the time dimension - keeping code correct as the business and the people in it change.
That's how I explain to people that LLMs will not replace us developers.
https://media.ccc.de/v/36c3-11241-from_managerial_feudalism_...
Timestamp is: 36:42-39:55
I believe Graeber perfectly predicts the problems, in 2019, with vibe coding creating immediate "value" from production, but failing to produce true value through maintaining the system (like one continually washes a cup to give it value over time).
> (like one continually washes a cup to give it value over time).
But it doesn't give value, it prevents value loss.
I don't know why people are telling themselves maintenance work is virtuous. It's waste. It's necessary waste, and doing the work may be virtuous, but the work itself is pure waste. Fighting entropy.
EDIT:
I wish we talked more about the need for low-maintenance patterns and products. In this industry, many of us already recognize this instinctively, but we often misattribute the problem to "complexity". Think of e.g. rather substantial niches and common practices among developers, like static site generators, no-build-step development, or on the backend side, the popularity of header-only libraries in C and C++. All these tend to be labeled as reducing dependencies, but that's just the means - what they do is they minimize independently rotting parts. The build system isn't bad because it's complex - it's bad because you have to constantly babysit it. Conversely, a static site once rendered will open ~forevermore, and so will a piece of C/C++ code that relies on single-header libraries.
Similarly, the popularity of containers is in large part this. All the mess isolated in a self-contained bundle that is preserved against rot, at least for a while. Inside, there's nothing to maintain - it works until it's not needed, or until the "outside world" changed too much, at which point you throw the thing away and get a new one. Etc.
> But it doesn't give value, it prevents value loss.
It keeps thing operational. Software changes because requirements changes, the context it is used it changes, or just the iterative nature of it where features are rolled out over time so that users can immediately start getting some functionality if not all that was originally planned (MVP).
Maintenance work is neither virtuous nor waste. Its just nature of the things we build.
I agree however with the part on more talk about low-maintenance patterns and products. IMO its often the trade-off between velocity vs quality/technical debt. So it happens, industry is favoring more and more towards velocity for delivering features that often add little value to the users, just because $$$, competition and maybe the grind culture.
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.
> Ask claude, use ssh with key-based auth and he will take care of it :) just saying
This already goes over the heads of most non-developers.
I think you're misunderstanding my point. It's not that LLMs aren't a useful tool or that they won't replace some developers. But rather that software development as a specialty won't go away because most people can't build software with LLMs in a way that won't blow up.
Maintenance over time is 90% of the work anyways, you don't start a project from scratch every day
How many programmers operate under that kind of regulatory and operational constraint regime? I think most don’t.
(In interesting ways this is programming’s greatest boon and curse: if we treated it more like building bridges or cars, the world would be a very different place.)
Touch billing, touch medical data, be at a B2B company that needs to catch all the ISOs to have a chance to land bigger contracts. I don't think it's uncommon.
It might be an unpopular option, but I think the regulatory regimes that control medical and financial privacy as they interact with software are significantly lighter touch than e.g. the regimes that control material quality for bridges and tunnels, much less airplanes.
Not in tech, so does the authority granting license to proceed do code reviews?
Because when I submit building plans, they are manually reviewed and approved (or denied) by registered architects, engineers, and planners employed by the authority for just this purpose.
Gaming Commissions oversee gambling machines and will audit code to ensure the RNGs are accurate, return to player meets the expected requirements, and so forth.
I'm sure other highly regulated industries also have their code audited.
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).
Even if you get a crispy set of requirements from all parties you are still responsible for implementing all of then while making sense of the existing system (and from my experience significant issues arise at this stage when the full extent of requirement implications ia better understood). On top of that you might also be responsible for operating the thing, participate in compliance doc writing and do ongoing maintenace.
Yes, these things reduce (not necessarily how to zero) how much compliance the programmer is doing. They aren't figuring out how to get a car legally on the road, they're still figuring out how to get a car to do car things. The compliance questions the engineer sees are largely engineering questions. Sometimes hard engineering questions.
While there are for sure a lot of programming jobs that don't touch anything "important", like making dime a dozen websites or apps, I think you underestimate the number of things that need some form of higher quality control.
The level of quality needed (or imposed) will vary. It is a wide spectrum from dealing with banking/transactions (money at risk) to brake controllers and auto pilots (human lives at risk). But there is a lot of this, all over the world.
I work somewhere in the middle (rather slow but extremely heavy industrial equipment, where emergency stop is always a safe if costly option). There are domains where emergency stop is not a thing though: some systems on an aircraft in flight, a pacemaker, etc.
My point is though, that there is a ton of code where stakes are higher than "oops, I guess we will fix it next sprint". And while not all of that have regulatory constraints, sometimes a company realises that the financial cost of issues significant enough that it is worth holding themselves to higher standards anyway.
Any coder with experience or ability imagines a world where software architects are regulated the way real architects are, and acts accordingly.
I mean, this was drilled into me at uni — that software was not likely to escape regulation forever and that you can't know with certainty how all the code you're writing will be used when you're not observing the use.
For example, under what constraint regime should the calculator app bundled with an OS be written? It's just a little bundled toy app. Until someone under pressure uses it to calculate a medicine dose, expecting it to be a calculator like it says.
Perhaps this gives away my age more than anything else.
> For example, under what constraint regime should the calculator app bundled with an OS be written? It's just a little bundled toy app. Until someone under pressure uses it to calculate a medicine dose, expecting it to be a calculator like it says.
This captures a sentiment I have often felt when people don't take bugs seriously. Or don't take it seriously that they introduced regressions. You should feel personal responsibility for your bugs. When your shit doesn't work, and people are trying to use it, you are basically hurting them, personally.
But it seems with the increase of AI coding, the industry is going the other direction. Nobody seems to care about bugs introduced by slop coding. Except perhaps the users.
That's why I said "that you can use AND meets regulation". All software on average.
I think most do. You often sees that OSS often provide a disclaimer that they’re not liable for damages. You can’t easily do that when you provide a paid service. B2B often have SLA contracts that usually keeps everyone on their toes and not sling bugs right and left.
90% of code wouldn't pass a basic audit, let alone any sort of regulatory scrutiny. Developers are building the easy version most of the time.
The problem is that non-technical people just see The Code. And now when they prompt an LLM they also see The Code. Voila - finally we don't need those pesky engineers.
Communicating like this is to try to get them to understand that The Code is barely about the text on the screen and is instead about much more - both abstract in the code (but how on earth do you explain that to someone nontechnical without just sounding like "no trust me my job is really hard, I promise.") and also in all the external stuff - the world The Code lives in (users, ops, support staff...).
Is it a perfect analogy? Of course not, and I'd never explain it like this to someone technical. But they're not the audience.
---
Adjacent: I've always gotten the feeling that even the most well-meaning/trusting nontechnical leaders have always been fairly nonplussed by software complexity and software development.
Deep down, they seem to think it can't possibly be that hard, despite the fact they can't write it themselves. Sometimes, even worse, they have dabbled in writing small, or even medium-sized solo projects. And think - well isn't software engineering just doing that but with other people? And their attitudes can reflect them, sometimes all the time, sometimes just slipping through when under duress like delayed projects etc.
And yet despite their attitudes, they then also find:
- if they try to outsource, they have a bad time
- if they try to proooompt, they have a bad time
- if they try to pay less, they have a bad time
and so the invisible hand of the free market itself forces their hand in paying prodigious salaries and fighting to retain talent. And all throughout they remain internally nonplussed even if they manage to keep up appearances.
Your analogy breaks down because code is not heavily regulated as cars are.
This is worth saying precisely because of this difference - people see huge amounts of bad code generated by LLMs and think it is equivalent to carefully written code because the results look similar at first glance and they don’t bother to read it.
The code in cars is, by definition.
That is probably around 0.0001% of all code deployed.
For me this metaphor only makes the original point more credible.
Absolutely there can be a bunch of hard things wrapped around easy things. When those things can't be separated neatly than it doesn't make sense to separate them such that we can call the easy parts easy (or even parts really).
That said, it's still reasonable to think that once (and only once) the hard part is done, then the easy part is easy. It would just be wrong to think that you can do the whole thing without having to do hard parts. I think the argument here is that with AI this is more possible—that the tasks are more separable. Even if it's the same one person doing the hard stuff and then passing what they learned to the AI to do the easy stuff.
Two reasons they might not separate well (there are others):
- If in a company's product development it's hard(er) to have one person doing H and another doing E, then you're generally going to have one person doing H and E. More or less, this means a person can only do E easily if they do H beforehand. So hard things are required no matter what.
- People come in whole persons. If people skilled/educated to do H tend to be the same people skilled/educated to do E (can be because of how programming is educated, but also can be because there aren't that many programmers), then you're always going to be plugging programmers who have both H and E into roles and it'll probably be more efficient to plug them into roles requiring both rather than just H or just E. You could, within that population, determine who is comparatively advantaged (and we do do this mildly with senior vs junior or with "architects"), but plugging a person into an E-only role is going to involve that person questioning what happened during the H part beforehand. In part because they're good enough at H to question it, but more importantly because they're implementing the H such that they're aware when their E might not be as easy as it could be.
Both of these seem like they might be less true now with AI (and also perhaps because there are more programmers).
I mean, I think the point is, every discipline isn't ever that discipline in a vacuum, it touches the real world, and we build meta-structures around said things that may not look like programming, but certainly require deep programming SME.
Even in academia, you have meta structures that you constantly need to think about.
Of course, you can keep trying to isolate the "pure" thing from the "accidentals", but it's not going to work when the work gets sufficiently complex
The reason people say "writing code isn't the hard part" is because the only thing an LLM saves effort on is typing code into the computer. You still have to know what the code should do, and you still have to review the code the LLM generated to make sure it is reasonable. In other words, you still have to do the hardest parts of your job, and the LLM only saves you effort on something which was no real effort to begin with. That is why they are an ineffective tool, because they are helping you with the bits you don't actually need help with.
I don't agree that "the coding was never the hard part" in general, but it is true at least often.
For those cases where it is true, it is pretty much like your example, and the distinction is there in your example just like theirs. You supported their point.
> 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.
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.
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.
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.
"wear additional, invisible hats "
No ... those are not invisible hats ... those are the real hats.
Software is 'Knowledge Distillation' the code is the hieroglyphic artifacts.
Engineers Engineer, Scribes Scribe.
Just so happens developers do their own scribing.
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.
I'm beginning to wonder if a lot of commenters have forgotten that waterfall is a failed methodology in part because you can't always just gather requirements by say introspection or interrogating the customer for them. In order to reveal the true, accurate requirements, you often need to write code. Not always, sure, just like some code is relatively easy to write, some requirements are easy to both accurately specify ahead of time and even satisfy. (An old XKCD hinting at this distinction: https://xkcd.com/1425/ Only nowadays we actually can easily satisfy a lot more of those old easy-to-specify-difficult-if-not-impossible-to-satisfy requirements. That's the way progress in the field often goes.) Decades of startups support the iterative approach, along with pivoting, the successful ones learning the lessons of writing less committal code and discovering requirements iteratively. And it's hard to actually pull that off -- so many companies have gone under or lost out significantly to competitors because they couldn't write code fast enough, or change code fast enough, either with the goal of discovering the real requirements or adequately satisfying those requirements once known. Code is hard in general.
> 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 of the job. We shouldn't define down competence.
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.
> 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.)
I think this is true when you realize "customer" means "coworker" or "person on the next team over" or "management" or "your intuition about the problem". Which all sort of have the same shape.
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 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.
That job was often called a "business analyst" in "the old days".
Not in agency or consulting jobs.
> 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.
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. ;-)
A business does need a small number of their most senior engineers doing high altitude work that can, at times, include helping sales estimate new features. But in my experience, it's not rocket science and a good product team can do this on their own with a quick async check over chat. At most, a single meeting is all it takes.
I've heard of Sales Engineers as well, embedding programmers directly with sales teams.
But the vast majority of programmers should not be spending any significant amount of their time on this. Their value is in building and scaling well-specified systems.
>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
Do you believe these numbers? Is there a cite somewhere in the literature for valid, proctored IQ tests being given to representative samples of different professions for these kinds of comparisons? The link you've provided is to a company selling online IQ tests.
Is the argument that electrical and mechanical engineers are not smarter than the average person? How about figure 8 (PDF page 86) of:
https://web.archive.org/web/20120905095856/http://www.ssc.wi...
Doesn't this basically make the argument I'm making, that there's no well-defined band of IQ test scores for different professions?
I'm not seeing any other posts of yours on this comment thread. Maybe you forgot to hit the "reply" button (or accidently outed an alt?) My only point was that majormajor saying that programmers might only be roughly the same smartness as electrical or mechanical engineers would put them comfortably above the average person.
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.
While you are directionally accurate, the flaw in your thinking is revealed by the fact that bad programmers also have high salaries, and plenty of five year olds have no problem being bad programmers, so there is clearly no need for above average intelligence or education to be a bad programmer.
As hard as it might be for this audience to comprehend, supply is limited simply because it is an undesirable profession. The majority of the population couldn't think of anything worse to spend their time doing. Much as the same reason why they don't want to go work on oil rigs and other such work that is high paying but what most people are unwilling to do.
High compensation is actually not as strong as a motivator as you might think. It can tip the scales if someone is already on the fence, but it doesn't suddenly make someone who absolutely can't stand something to change their mind.
I've watched dozens of people try to learn to code and fail, some definitely not for a lack of trying. Of those that did learn, only a fraction had the IQ or passion to be genuinely good at it.
The difficulty of it has absolutely been a bottleneck to the supply of good devs, keeping salaries high.
We've also seen decades of effort, much of it successful, aimed at making it easier. Programming used to be harder. (Difficulty alone doesn't account for high salaries.) If it was never "the hard part", what motivation for all that effort? Books, pedagogy, tooling, languages, even the notion of publishing a library is an attempt to make coding a related task easier for others. There's been comparatively less effort in making "the other parts" easier. Though certainly things like software development methodologies count.
My hunch is that the difficulty has moved, not reduced in practice. We make one layer easier and then another mountain lies at the layer above, just as hard.
> Writing code is not hard. Writing correct code is.
Xing Y is not Z. Xing `additional adjective` Y is.
Writing prose is not hard. Writing good prose is.
Cooking food is not hard. Cooking good food is.
...
> 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
There’s a minimum karma requirement.
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…
You actually do. All of those puzzle-style questions of the sort of "how many liters of water in Mediterranean" ask you to develop a solution with a vague requirement by leveraging what you know roughly to demonstrate you can specify requirements yourself (oh, Mediterranean is roughly 5000sqkm [-> I need surface area], on average 50m deep [-> I need average depth], this gives me A x B liters total) — I'd call these the leet-code version of requirement understanding/development.
But really, any interview is really about giving you a requirement, and seeing _how_ you understand it, how you clarify it with your stakeholders (interviewers), and then how you address them.
URL please?
Carpenters don't just nail things together and expect that to be a usable/useful product.
If you can't/won't understand what you're supposed be doing, you're either useless or making useless shit.
Thanks for giving me a laugh, I was just imagining https://programming-motherfucker.com/ as an absurd "Hat-wearing, motherfucker" site instead.
The author might be missing the intent of the observation. Maybe they’re misinterpreting it.
What I, and many people who’ve said, “code was never the hard part,” aren’t referring to the skill of an individual. It’s not the hard part of the engineering process of developing software. Programming languages have manuals. Many data structures are well documented. There are frameworks for damn near everything. While the difficulty of producing code varies by the skill of the programmer and the complexity of the problem domain; writing and understanding the code is a tractable and straight-forward problem. I can and have taught many people. People can learn.
What most people are referring to is that the hardest parts of producing software are all the things an organization has to do in the production of it. It’s not writing the code that is the hardest part for an organization. It’s getting everyone to understand the problems, working together, gathering requirements, developing specifications, validating releases, testing, etc. It can often look like herding cats and is probably harder.
If what you're saying is true we are moving into an era where rockstar product managers are going to be more in demand than programmers since they can do all of what you mentioned above.
And typically (though not always) product managers have better people skills than programmers and consequently they might be more effective at the "gathering requirements" and "working together" bits you mentioned above.
Even much of the "validating releases" and "testing" parts should also be things that a decent PM should be able to wrangle now by themselves with some LLM agents to assist them. Afterall, why bother about code quality of a testing harness. So long as the PM can keep a coherent test case list and have end to end tests that cover them, programmers can leave that to them as well.
Well, it's true. In a world where code is commoditized, a PM who knows exactly what the customers' needs are will be much more successful than an engineer who does not. Not sure what is controversial about that.
A test doesn’t prove much.
Highly experienced programmers seem to have a hard time understanding this.
Why do we have tens of thousands of test cases and we still find new errors constantly? Why is our software so bloated and slow? We do we still have security breaches?
LLMs can be useful tools when guided by experts. I don’t think a PM with a dream is going to cut it in the long run.
Organization is too abstract here.
It also depends on how you model the problem. You can easily say the hardest part is hiring people if you are the boss. Since the people you hire can do everything else that needs to be done.
Managing and motivating people is the hardest part for the person who is doing it.
If you are hiring you might say it is harder to find good managers than programmers.
It is not measurable who did a good job at what as almost everything requires a group of people doing different things.
You can see how pointless this is becoming as we don’t have a measure for anything.
This kind of problem requires assumptions because it doesn’t hing on anything natural.
For example, if you start by believing salary indicates value then you can go from there.
In the end there are millions of managers, millions of programmers, millions of ux designers etc. It is kind of funny to suggest doing any of these is inherently harder than the other.
Just imagine you are judging a project. You have everything about it recorded. How hard do you think it would be to judge who had more part in the outcome in what way? If 10 people judged it separately, how many would have similar opinions etc.
It is impossible to judge even for a specific case, so it is a joke to consider to find the universal rule for it.
In the end it is ok to believe something but it is also important to not forget that it is a belief
It’s getting everyone to understand the problems, working together (etc)…
There are manuals for this too, and interestingly enough this has been studied since the Romans at least! Is it then really the hard part?
Apparently it is. Modern companies seem to prefer dysfunction over anything else. I have been trying to understand why for my whole career.
Competing incentives and the natural result of dealing with lots of people mostly
1000%. The expense of writing software was and still is high.
Whether it’s commercial software company or an internal team writing custom software, the return on that investment depends on many things outside of the code itself.
Getting everyone to understand the problems, working together, etc, etc are issues that are inherent to organisations.
They’re orthogonal to AI and to the actual hard technical skills needed to execute on a specific strategy. And if the technical skills are lacking, it doesn’t even matter how good an organisation is at collaboration, whereas hard skills plus organisational disfunction are a known successful pattern :)
Many people did look at this through an individual lens and claimed that design skills, domain knowledge are the truly important abilities. I remember reading on HN at least a couple of popular articles claiming that. Actually, they’re all important and having great design skills without matching coding skills is IMO not really possible. The code feeds into the design, the requirements, the architecture and shapes them.
I don’t disagree. I’ve worked on teams that definitely valued the non-coding skills more and it showed in their inability to deliver on certain requirements… mainly performance and stability.
But these are skills that can be taught to individuals.
But teaching an organization that their real bottleneck isn’t how fast they’re writing code; it’s producing production-ready software that people understand and are willing to take responsibility for… that’s much harder.
Many businesses want to treat software development like an assembly line and revert back to Taylorism. It’s knowledge work and there’s no royal road. Good teams get fast when they have the right mix of skills and trust from the organization.
What we’ve been delving into for the last decade has been a decline in the value of labour and work.
“Code isn’t the hard part,” isn’t meant as an insult at individual programmers or to devalue their work. That’s being done by big tech and their AI hype machine.
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.
It's not really telling on oneself. Like you said, the easy stuff (e.g. basic business process automation i.e. constructing simple database queries) happens to be economically high ROI right now. Something like 3d graphics or signal processing or whatever are comparatively niche and less likely to pay as well. Most jobs that people will actually pay for are actually pretty mindless. Even for the more "advanced" jobs, it's likely the domain knowledge and not the programming per se that's difficult.
> 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.
Genuine question and not trying to be snarky here, I am actually curious: what fields or types of programming does this apply too? I think I've read anecdotes online about people in fields I previously (a few years ago lol) thought "oh yea an llm will never be able to help with that" and now see articles about how llm's are doing just that.
LLMs are surprisingly bad at basic CMake, but i don't see why they should be.
Much of the truly LLM-difficult code is probably hiding in the libraries we import. Database engines, compilers, efficient data parser, control theory, signal processing, protocol implement-ions, or anything with a 12000 page German ISO standard that need to pass a $12.000 certification lab. But this also compose of such a tiny fraction of programmers or code in the world.
A-lot of my work lies in that last one... but that's also where that "code is easy, knowing what to code isn't" is the most true; because industrial standards tend to not spare any expense on the word count, while the implementation is a ~2000 row state machine. I've not yet found an LLM capable of successfully parsing this kind of specification documents, but it's possible they will reach there eventually.
But i do feel online debate do clump the software field a bit too much when AI is discussed. JavaScript compose probably 98% of all code the LLMs are trained on since it's powering every website scraped for training. As such, people in web-development seem to have far more praise to LLM capability than i'm able to give.
My personal AI experience has been very mixed in comparison, regularly making up functions of common libraries, hallucinate the description of technical terms, straight up writing un-compilable c-code, or get confused by relatively small code-bases. Useful but not majorly changing my work at the moment (pretty good at comments, test cases, or as google replacement).
Granted, I've only tried models up to Opus 4.8, and not had experience with the newest "tier" of models with Fable, Kimi K3 or GPT 5.6; but the prices on those are also starting to compete badly with my salary at the moment.
That makes sense, great answer thank you.
It is hardly any different from reviewing or debugging the code quality of most offshore deliveries.
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.
This feels like post-LLM coding romanticization. Before LLMs, people would regularly say stuff like "I could build this in a weekend" under a "Show HN" post. How many times have people said "I could build Twitter in a weekend". I've even found in a post-LLM world, that kind of language has only increased.
When you are looking at something that already exists, where all the requirements are defined, when all the edge cases have been decided, then coding was the easy part. People didn't "burn out" because it was difficult to figure out how to write SQL. People "burned out" because the requirements constantly changed, demand was ever increasing, and edge cases were constantly being triggered.
>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?
Classic engineer type opinion where every else is dumb, except for him. So many people have come to see leetcoding as an intellectual badge of honor, when most of us know its cultural rigamarole and the code written on the job will rarely reflect the type of work that will done.
I'm not saying coding is easy, plenty of people struggle with it. But as far as the job goes, unless you are a junior just grinding through JIRA tickets, coding was the easiest (and arguably the most rewarding) part of the job.
You are putting a lot of words and judgements into the authors mouth.
Why exactly is it acceptable to not just do your role and expect the underlying requirements to be correct and measurable, especially when there are separate roles whose sole purpose is to do exactly that?
Because being a code monkey is getting devalued like crazy every hour that agentic coding improves in ability. If all you do is take well specified requirements and turn them into a piece of code you are going to lose your livelihood unless you can learn to do more than that or you're at the very top end of people who do that.
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
Are you the buyer of the stuff?
It took a while before the MBA hivemind woke up to this happening because of outsourcing two decades ago.
I suspect the massive shitshow of Windows 11 and all of its failings is a result of large quantities of vibe code being merged into the OS. People are noticing.
And when exactly did Windows 11 release?
Just because some of Windows 11 was released before Claude Code doesn’t mean that the really shitty stuff from the last year wasn’t vibe-coded garbage.
Windows 11 was released before vibe coding was viable. And the shit show seems to be that they push ads and bloatware on people, not that it doesn't work reliably. Windows 11 IoT LTSC has been absolutely rock solid for me on both machines I have it on. Waaay more stable and reliable than Linux, and even a bit better than Mac (which is also way better than Linux).
If they are vibe coding anything, it hasn't had any bad consequences yet. The ads and bloat are human decisions!
In the last two years Windows 11 has shipped with increasingly serious bugs. Many of my co-workers report needing to reboot a few times a day because issues just compound.
I regularly have major issues with Teams and Outlook. Crashes, not showing messages until hours later, calls dropping every few minutes, and the app just never opening. Just Friday afternoon I could not close Teams from the Task Manager
They do. Most economically viable software already exists today, most people's job is to make .1% improvements, and features on top. For this work it's obviously pivotal that any change should not worsen the existing software, as that instantly nullifies the value of improvements.
Another kind of highly valuable software is a new design which digitizes some process, like the ticket management of a rail company. If you don't follow the internal processes and workings of the firm exactly, or you do not interface with existing systems 100% accurately, your software very soon becomes worthless.
Figuring out how to create a piece of code that solves the exact problem the customer has, while not breaking anything, and fitting into existing operations seems to be a big head scratcher still, and something humans still need to do, at least that was my experience so far with LLMs.
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.
The most important result of quality in software is that it's faster to produce and cheaper. How are people defining quality? We're not building tables with the finest wood.
Low quality ends up taking longer to build over the long run. It gets harder and harder to add or change features.
This is why I believe true engineering art comes in actually marrying all three: build great quality quickly at reasonable (small) cost!
If you need it to work for at least a month or two (instead of one and done, which some demoware is like). Following a few rules early on will ensure you can keep evolving it — even if it's MVP/demoware/whatever — as long as you know you need to evolve it soon after you build it!
This isn't true. I don't think you or me would want a car/TV/smartphone that's cheap and flashy but breaks every two weeks. Sometimes people are strapped for cash that's why they cheap out on stuff, or really are enthusiastic about it, so they tolerate it breaking all the time, but for everything else, reliability is king.
Nobody _wants_ it, but in practice if all cars/TVs/smartphones break every two weeks, what choice do people have?
In tech, the era of competing based on quality is long gone. The winning strategy is to get a monopoly/oligopoly and then you can let the quality decay to zero and people will have no choice but to keep paying you money (or to your handful of equally-mediocre competitors).
There is a minimum but beyond that people don't care. Asian brands like Toyotas are the most reliable yet the Ford F150 is the best selling vehicle in the world.
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
>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.
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.
Do you have a source for that claim?
Why wouldn't they be working on better harnesses? Every feature that has gotten popular has gotten integrated so far, and their product managers aren't stupid.
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.
Yup you'd fail fast because you could not at the time bullshit and handwave the computer. When you don't do the implementation work itself your sloppiness is mostly the concern and inconvenience of implementors. And I concur the best way to understand the system is through the code, and the best way to understand the code is to write it.
We aren't going to understand the systems we whackchitect from now on. It's the endless prodding and begging instead, something that makes me infinitely sad.
>jump into architects or prod management but not the opposite way.
This has nothing to do with any intrinsic difficulty with coding and more to do with the industries penchant to rewrite everything every couple of years. The reason you don't see people who went to management become ICs again, is because you have to spend time learning the new, correct™, way to do read and write code.
From the constant API churn for something like React, or even the 20 million updates to write "modern" C++, someone who has had those minute decisions abstracted away will struggle to write code.
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.
Non coding architects, aka Solution Architects tend to be the next career level after Technical Architect in most organisations I have been part of.
No one would jump directly into a Solution Architect.
PMs yeah, those have had various backgrounds how they came there.
Again, on my personal experience.
LLMs can write TLA+ models just fine. It can help even with small mobile apps. Surprisingly, simple TLA models were able to find design/workflow issues almost in every of a few vibe-coded apps I've tried on vacation.
> Encoding your ideas into a programming language is easy.
This is still difficult. Sometimes the programming language or the programming methods you want to use effect how you desing the system on an abstract level.
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.
All of our developers are now using agents. We're not hand-writing code at all anymore. And yet, some of our developers deliver stories in an hour, others deliver similar complexity stories in a week. Executives are surprised to discover they cannot simply turn over a product-authored jira story and have it yield a single agent-written PR. There is still significant work that happens between the point at which a story is written, and the point at which correct prompts are input that generate the code that fits the requirements. Very significant work. I think that when people say "code was never the hard part", they're only guilty of eliding the point that "code was never the only part" or "the hardest part", and that there's so much other stuff that programmers do at various levels of competency, and that... perhaps up to now it was easy for product folks and execs gloss over since they just put us all in one bucket of "people that write code".
I think "Code was never the hardest part" is more fair.
Code itself can absolutely be difficult, but it's seldom the most difficult part of a project. Generally the hard part is actually figuring out what you want, and how to achieve what you want, then the actual code is pretty straightforward in most cases.
I've been programming since the the 1980s and I'm not insulted by the idea that code isn't the hard part.
Yes. I've also heard it said "code was never the bottleneck"
The "code was never the hard part" is a narrative pushed strongly by designers, MBA guys and product managers. Even before AI, they've always treated programmers like low-lives, someone beneath them and completely replaceable like commodity. Ironically, of this entire group, it isn't programmers that are being replaced left and right. Whole product teams, designers are being replaced. Good coders are still in demand - because, someone has to fix the vibe coded mess. In design, there is no reference for good and bad. You either like a design or not. In code, something either works or not. That's why it's always hard to replace a programmer as opposed to a designer.
Has Claude code et al replaced programmers? Not really. And it will be a long time before it can - because someone needs to still instruct the direction of the code, the base architecture to build upon and that comes with real human experience.
IMO it goes both ways. Each side can look into how they see the other side to understand the psychology of the other side.
Also I write good code and managers are thrash.
At the start of my career I was being paid for the code I wrote.
By the end of my career I was being paid for the code I didn't have to write.
One of the nicest complements I ever got from a coworker was that he was astonished how much I accomplished with so little code. Everything I built was designed to be easily and quickly extensible with minimal changes, I planned my structure for future needs.
That is why high paid programmers have been in demand, because learning that takes more than intelligence, it takes wisdom.
Right. The big misconception is that really good programmers just write code at 10x the speed of bad ones. Nope, the complete opposite in fact.
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.
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.
customers very rarely have budget for the time it takes to produce well engineered code
And thus they end up paying even more for badly engineered code
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!
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 think a lot of the discourse around AI is imprecise, but you’ve done a good job of clarifying. AI is also changing the definition of some terms, so debates are happening where people use the same words, but mean very different things.
Some people say “coding” to mean the process of converting a well-defined plan (requirements, architecture, everything) into executable code. Others use “coding” to also include all the small decisions you make when writing code, like the abstractions you build and how you handle ambiguous requirements.
AI has decoupled “typing the code” from “making the decisions about what to type” because AI can generate code from very ambiguous prompts. So “coding was always the easy part” is meant to use the second definition and emphasize that you may be able to generate code, but having good decisions embedded in the code is still a difficult, unsolved problem with AI.
There are also different definitions of “what to build” with some people meaning the technical details, as you’ve called out, and others (I think especially more business/product roles) meaning the functional requirements of the system.
By saying coding is the hard part, you're insulting all engineers.
Edit: Although the current job market is heavily distorted, there used to be distinction b/w developer and engineer in the past. As the mainstream development model shifts from waterfall to iterative models, it became necessary for everyone to be engineering-capable -- only up to a certain point. So, every developer now carries a certain amount of engineering knowledge, but now they started to misunderstand and underestimate the value of engineering, and this is what you would get at the very end.
In my peak programming years in Germany, about 5-6 years ago, every company that ever tried to hire me, wanted to do some sort of CRM for xyz. It’s fun when you build it once, but then you change the domain, and realize you’re essentially building the same thing, but for different people. I’d gotten so bored of it all by 2020 that I’d approach them right away, asking “are you building yet another CRM for xyz?” They didn’t like it, because it would undermine their work. But it’s true - thousands of highly-educated, well-paid people in Munich at the time, were essentially paid to build and maintain glorified sheets software for managing people and resources.
You can guess which companies and people were hit the hardest, when it turned out that all that software could eventually be generated by a machine.
No, it means you’re more than just syntax.
And that if you make a bot that produces syntax you haven’t produced a programmer.
Some workers are more 1:1 with syntax, like a developer from a gig platform or overseas contractor, the deliverable being code files.
But the staff software engineer deliverable should be software, novel outputs, a face in meetings, someone to blame if it all goes wrong, a member to fill out the ranks, a person to get coffee with and talk about adjacent things that open new doors, in a sales capacity it might mean travel and interpersonal stuff like drinks and talks to convince people to integrate, it’s thoughtful often emotional back-and-forth from frustrated contributors on GitHub that lead to changes and innovations, and other things of value that language models can never do.
I would say further that even if you model emotional intelligence, or the whole world even, unless AI has a face I can punch if it crosses some line and it knows it has a face, what its own face is and why that matters to itself, it will always fall short in terms of empathy. Our sense of empathy and emotion originated in the wilds among fear and terror and the thrill of catching and eating food, discovering others, and understanding the consequences of everything before me in this moment.
>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.
Customer Success definitely doesn't get compensated what they're worth.
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.
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.
Easy on the cocaine. There are no credible AI code bases on GitHub.
> There are no credible AI code bases on GitHub.
heh that's quite a statement. How would you even know and what does "credible" mean?
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.
good news, the ceo of this non tech company has years of experience as a competent sofware dev
What kind of systems do you work with where code is a fluid?
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.
I never had burnout from writing code; I had burnout from PM changing priorities every day or from tickets being half-baked. Also been burned out from being awakened that switch in somewhere in the Middle East had high CPU usage, which I was on call for for some reason (I wasn't on the network team, but that team didn't have bandwidth to be on call)
Writing code is easy; that's why I do it as a hobby on weekends as well. I don't have to sit through five arch review meetings that talk about how we are going to name the class rather than what the API contract is supposed to be.
Sure, writing good C is hard, and writing PHP (used to be) hard because language design is full of inconsistencies. There is so little "hard" code that I wrote for money. Plenty of somewhat harder things that I wrote for myself because it's entertaining. There was a time when I had to spend more time getting a pull request ready than actually writing code in that PR.
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."
> You're absolutely right
Claude, is that you? :)
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.
This is a bit of a false dichotomy. The thing that isn't code (at least in some people's minds) isn't "requirements analysis". It's architecture, data modeling, deployment, inter/intra-team communication, triaging, prioritising, code reviewing, testing. It's all of software development, and not simply writing lines of code (which in itself can be hard of course.)
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.
I personally find that I hate any activity in a context where I'm paid for it.
The truth of that statement depends on what you consider as "coding".
The way I would define it, coding is to software development as cutting is to open heart surgery. It is the final part of the process after 99% of the decision making and application of experience has already been done. There is still some craft or "surgical technique" to it, but the hard part was surely everything that came before (requirements, architecture, design, etc, etc) that got you to the point where all you had left was a bunch of classes and fully specced out modules (and implied test cases) to code up.
I feel that some people, maybe including a lot of the people working at the AI companies, think that the software development job mostly consists of "coding", and perhaps in machine learning (not much code in an LLM!) it mostly does, but if you are a developer and define coding as the final "sit down and implement it" phase, then surely that is the easy part.
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.
For me the hard part is remembering the "long tail" of the stuff I don't use long enough for my brain to consider it worth putting in the permastore. So I just spend a lot of time googling stuff I already "know" how to do, because the frequency is too low.
It's not hard, it's just bloody annoying. And that's my favorite use of AI so far. Telling it what the code should do, and it translates that into language X's stdlib incantations.
I also find this to be the optimal level of AI usage. If I let the AI run around the codebase doing other stuff, then I need to spend more time and energy later catching up. Whereas, if I stay "in the driver's seat", ask for tiny changes, and approve them manually, the mental model doesn't never gets desynced.
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.
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.
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.
> 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 very rare.
The author is conflating coding with other parts of the sw engineer role.
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.
I think we should first define what “coding” is and whether “code” means “any code” or “optimal code”, because otherwise we’ll just keep talking past each other.
But I enthusiastically agree with your point about engaging with your output and having that deep understanding of all the intricacies and, well, you already said it better.
I also can’t shake the feeling that many hardcore LLM proponents are actually, genuinely worse at this than I am, and that’s simply it. In my vicinity, the loudest and most extreme LLM jockeys are all people who I personally don’t think are great engineers, or even that smart. They might be right in the end and I might be wrong, but these people definitely won’t become my role models anytime soon.
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
> If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)?
My take on that question is that programmers were in high demand because, for the last 60 or so years, it has been cheaper to write software for general purpose computers to automate things that were done by people and more rudimentary machines, e.g. accounting, manufacturing, music production, etc than it was to pay the people to continue doing those jobs. So, it continues a trend for programmers to be replaced by software, at least until something in the process breaks.
At its core, there is something difficult about programming. Fred Brooks talked about the need for perfection, Don Knuth about there being about 1 in 50 persons who had the mindset for computer science. But we haven't really been paid because it's difficult, we've been paid because we're cheaper than the alternative.
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.
> 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.
I like heuristics, but find broad statements are usually a bad idea in IT/Software. Developers in particular are very quick to find holes in logic.
When I think of code, I like to compare it to old complex physical machines. Think automaton. If you zoom in enough, what you see is indeed somewhat simple. But zoom out and the answer changes.
Then there is maintenance, manufacturing, tooling, etc.
I suspect that as humans living in a physical world, we understand intuitively the vast knowledge and skills required to design and build different kinds of machines. Software tends to hide inside boxes that look similar, but are infinitely variable.
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.
Maybe the future has those as two different jobs re: hard problems.
- The sorcerer: Have meetings with others until you know just how valuable a solution to this hard problem actually is, characterize it well, pool resources use cases and documentation, and then work with whatever wizard (or university thereof) is known to be able to solve that kind of problem. Have them find a solution to the hard problem and publish it. Use that publication as context, and have your LLMs integrate the solution.
- The wizard: Find hard problems with adequate funding behind them. Solve them. Don't worry about stakeholders or integrations--the problems are hard enough on their own.
It used to be we found ourselves jumping back and forth between sorcerer and wizard. But there are so many hard problems with solutions that are now in the training data for these models. A relevant skill for the sorcerer, besides the skills that are relevant in those meetings, is not solving hard problems head on, but being a sort of remixer of existing solutions to hard problems.
I think this would actually be better, because more hard problems would get solved in the open where they can benefit everybody, rather than ending up as IP-shaped ammo for zero sum games.
Most useful software engineering work is doing fairly simple things and the numbers of people doing this work reflects that.
> those of us who have had to solve open problems with no solution written somewhere because there is none.
Probably because solving said 'truly hard problem' is niche with little or limited value as few people have tried to solve it (otherwise a solutions will likely have been written).
Darn, hopefully curing cancer becomes less niche so we can solve it ;)
To be less tongue-in-cheek, your logic is flawed. We simply have too many hard problems than we do smart people, unfortunately.
And the ones we do have seem to like optimizing comfort over risk, such as taking cush consultancy positions.
In my experience the complexity of the coding challenges tackled correlates well with the talent of the engineers.
It is uncommon to find engineers doing work they find trivial outside of some consulting niches.
"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 programmer" 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.
"If coding is easy, how come programmers were in high demand, and have demanded large salaries for years"
It's like saying 'Lawyers write documents!' for their job ... no, that's just an artifact.
Architecture, Systems, State, Integration, Algorithms, Pipelines, Platforms, Ops, Design, Communicating with other Eng, Working on a Team, Understanding Product/Product Marketing Requirements ... and of which the 'code' is just a small bit of the written part.
Honestly ...
> 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 8 hour work day was quite a victory but since it happened long ago i would really like to see how health and productivity in each occupation declines over time and by task. I expect not just the obvious jobs to have quite absurd numbers and vary a lot from person to person. One might imagine a gradually increasing hourly rate, a decreasing one or a combination of the two. Writing code i could probably do 2x an hour per day. Much respect for those who can do full days. If we imagine there to be roughly 500 defined occupations it seems quite doable to measure how "easy" coding really is.
There’s too many dimensions to make broad claims like this and it always makes me wince a little.
In my career code was the hard part for the first few years. Then I got over the hump and everything else about my job was harder. Today code is the easiest and least interesting part. But I’ve also experienced in 13 years maybe… I’m going to say 2% of the world of professional coding. I bet if tomorrow I was asked to do some kernel optimization or make Postgres better or reverse engineer an emulator for some PLC something something, I would be deep into a land where code is the hard part.
I currently work on a glorified admin panel. The code should be the easy part. Unfortunately, the codebase is absolute trash. The code and the requirements are hard. My colleagues which drove the codebase to this miserable state think they’re developer extraordinaires. They don’t see the problems, at all. I can’t change anything and if I ask to be put on a different project I might be fired.
There is a half truth to code being the easier part.
In order to reduce the complexity of eventually coding something, you use modeling and code probes to validate the business model and then write the code.
This has been around since the days of batch programming and evolved through domain driven design principles.
The reality is the business can’t see that so they don’t invest in it and have no patience for it.
Agile wasn’t embraced because it was better. It was embraced because it was cheaper and faster.
Planning and modeling are the levers of complexity.
Ive been doing this for enough time. Code is rarely the hard part. Code rarely matters at all in my career experience.
Shipping a working service or product matters and theres a lot of ways you can get there. The upside of good code is usually in maintenance and extensibility but theres a limit to how much those matter in the grand scheme.
Coding something for the second time is much easier. Therefore, coding is easier than some other tasks in software engineering. Getting the spec is usually the harder part, except if following the spec is for really complicated products, like "one does not simply rewrite VIM" shows.
Coding is not programming.
Typing code is indeed not the hard part, programming is.
To be fair, the use of absolutes like "never" is a red flag. If the statement were "code is often not the hardest part", that's certainly plausible and debatable depending on context. The implication that coding is easy is what's offensive.
> 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.
Well it's easy to come up with code, not hard at all. But what kind of code? Does it work? And more importantly, can it be maintained and adjusted to evolving requirements?
Coding is easy just like writing is easy. What makes the difference is what you write.
i’d bet half of my normie programming career was spent capturing requirements, understanding the target domain problems etc for easy normal web development. once that is done code is a grocery list for 90% of it
I've always taken it to mean "coding is the easiest part of a developer's job"
That doesn't make it inherently easy, but it is the easiest part to automate.
A modern LLM is perfectly capable of maintaining decent code quality and architecture (provided you ask for it) up to a few thousand lines of code, but after that it very quickly loses the plot if you're not designing your documentation right and keeping a hand on the architectural tiller.
Architecture is about staving off chaos for as long as possible given the maximum functionality you expect it to achieve. That's hard enough for a human, with a deep understanding of your business, to do. Architectures that endure is a hard problem, dwarfing the difficulty of writing the actual code. Choosing what product to build is also a hard problem if you expect to meet any success. What it does, what it specifically doesn't do. Sounds easy on paper, and if all you're doing is Sunday prototypes it feels almost trivial. But once you're doing a real product with real consumers, it's a very different thing.
I think it can be pretty hard. It can be hard to find the right fit/abstractions.
LLMs don't fix that though. I see some truly awful code come out of them. And no, it's not just better context or use more skillz.md.
depends on the industry. but in consulting the hard part is dealing with customers who dont understand their own business and analysts who think writing software is rote factory work but somehow struggle to write a handful of coherent user stories not littered with subjective and ambiguous language
these two groups are telling me my time is numbered because of llm and ai when in-fact im struggling to see how ai doesnt replace them both
really good software engineers are expected to be experts in their job and that of the rest of the project team, these individuals are primed to be empowered by ai in a really disruptive way.
Code was never the hard part… once you made it to some level of advanced programmer. Then clarity, maintainability, etc. became the next tier of Maslow's Hierarchy of Coding.
Nothing is ever hard that you've done 100 times before and know how to do. Creating documented step by step instructions that cover all or most eventualities is.
ya, it wasn't hard and that's why one of the highest paid jobs for decades
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
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.
Code still is the hard part. Or at least one of them.
Code, is written in a language. Language is opinionated. Things written in that language are also opinionated. LLMs often have horrible opinions.
"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.
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.
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.
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.
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-...
Moving up and down the layer of abstraction is an orthogonal skill. The skill I’m talking is taking some axiomatic concepts (can be opcodes or functions from a high level DSL) and then build something using the given rules. I took basic algorithms as an example because they are trivial in the grand scheme of things while learning something like flask or Laravel involves too many concepts.
At the core, both involve the same formal thinking, but it’s easier with higher level concepts to have tangible results (it helps with the rote learning) than purely abstract ones.
After reading your follow-up comment, I realize I may have misunderstood some parts, but I think there is a slight difference in our fundamental perspectives. Still, given your context and your experience, your view is probably the right one for you, and given my worldview and my situation, mine is probably right for me. I agree with your points, and thank you for taking the time to comment. Even though our views differ in some ways, it's precisely because of those differences that we have these conversations—and thanks to your comment, I was able to organize my own thoughts. Have a great day. I always appreciate your thought-provoking comments
I really enjoyed reading your comment. I was reminded of a perspective from Patterns of Software, a collection of essays from the 90s by Richard Gabriel. The very first one talks about the ideal of "reuse".
"A similar idea [to libraries] is the Collected Algorithms published by ACM years ago in an ALGOL-like publication language. I remember when I was a kid in 1968 looking up algorithms for sorting and searching in my first programming job. However, what every manager learns is that reuse under these circumstances requires a process of reuse or at least a policy. First, you need to have a central repository of code. ... Second, there has to be a means of locating the right piece of code ... It does no good to have the right piece of code if no one can find it. Classification in the world of books, reports, magazines, and the like is a profession, called cataloging. Librarians help people find the book. But few software organizations can afford a software cataloger, let alone a librarian to help find the software for its developers. This is because when a developer manager has the choice of hiring another developer or a software librarian, the manager will always hire the developer."
He talks about a few reasons for why this is, one of them being simply that plenty of code for your project will just have to be new / different enough from existing code, so there's not much reuse benefit there. He qualifies that with performance concerns, but that's just one reason why it would have to be different.
Another thing I was reminded of, from the intro of Etudes for Programmers:
"Programming is a craft, and programmers must attain a standard of craftsmanship. Much programming is done in cottage shops -- that is, in small shops with meager tools, much work done by hand, and learning attained from other laborers, by chance, and often not at all. ... the academics have also discovered that a craft cannot be taught well by teachers alone; the guild apprenticeships had considerable merit. In a classic apprenticeship the candidate spent many years doing menial tasks while absorbing fundamental techniques of the trade from more experienced workers in the shop. Gradually the apprentice was given more technical responsibility and, after a formal test of skills, eventually became a journeyman certified competent for all ordinary jobs in the trade. The journeyman traveled the world and, if the muses allowed, one day presented a masterpiece to the guild and became a craftsman of the highest rank -- a master of the guild."
Seeking for the average to be that of journeyman, rather than apprentice, seems like a worthwhile goal for the industry. You sound like a journeyman to me, and I can generally trust other journeyman programmers. We don't all need to be masters to have an industry, and that's probably not possible anyway. You say you can't implement TCP congestion control -- but you can build networked applications. Building networked applications is an ordinary job of the trade, and I'm sure you know how to do it in a number of ways. I also suspect that if you had to create some custom UDP protocol for something, you would be able to implement some form of congestion control for it in not too much time -- even if that involves searching for and copying a known algorithm, or if you're lucky finding and using a pre-built library flexible enough for your custom needs. That highlights two more reasons for why we don't hire librarians over developers. First is that, if you're at a journeyman level, then you can be trusted to handle the rather common scenarios where you have to do something for which there's no perfect matching library or framework or SDK you can just use. Whether you have to roll up your sleeves and go low level, relying on very little, or just need to be able to tie enough separate preexisting things together with some minimal glue to handle the new/different stuff, they're both activities that require a programmer rather than a librarian. (I guess this is just further elaboration of the already mentioned "there will be custom code not eligible for replacement by something reusable" reason.) Second, the task of a librarian to find software has been made much easier since the 90s with things like search engines, massive communication channels to share and find out about stuff, and massive open source repositories. It's so easy now that developers themselves can do a decent job at it among their other duties.
To me, one of the most agonizing parts of programming is that whenever I think I have discovered something new and write down a good explanation for it, I inevitably find out that a pioneer programmer from long ago has already given the exact same phenomenon a much more elegant name. Your analogy of the Journeyman explains the model I was trying to describe far more gracefully.
I actually think all these industry issues arise because the ultimate role most programmers aspire to is that of the Master. They want to be the ones designing the rules, frameworks, and architectures that mass produce journeymen. In reality, a department head at a major tech company certainly holds a position worthy of being called a Master.
However, I believe being a Journeyman is a thoroughly valuable and respectable end destination in itself. The reason is that once someone becomes a Master, they drift away from the actual field. They start focusing purely on building tools for the journeymen, whereas it is the journeyman who generally remains closest to the actual consumers.
I read your comment carefully. Thank you for taking the time to reply, and have a great day. It's been a weekend full of things to think about.
This post misses the point about what has changed. It's not that coding is or was easy, it's that coding is _more than typing code_.
Typing is easy. Coding is hard. LLMs eliminate the typing and aid with all the other parts of writing code (where is the system that I want to mutate, how does it work today, debate the tradeoffs inherent in the potential plans of action).
What remains after factoring out the typing and the time spent assembling an understanding of code is opportunity cost. That's not an insult any more than memory managers are an insult to languages like C.
Typing up English language logic into code hasn’t been a job for 40 years.
That’s what people mean by this.
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.
The real insult… “That’s a five minute change”
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.
> 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.
Agreed.
"Code was never the hard part" is the dumbest thing I've ever heard.
Making something work, has always been easier than making something someone can read. AIs also, seem to benefit from clean abstractions, appropriate code reuse, etc. (coincidentally, the thing they suck most at).
It's the same thing with english, except that english doesn't have a compiler. Comprehension is the only measure of communication if you're talking about a human language. Programming shares the same goal. Both, often also need to do something else useful. Programming, and lawyering, have a lot more in common than people think.
We're creating a culture of sh*tting on codebases so the highest paid execs can cash out when things get tough. It isn't a new phenomenon, but it's one we'll need to endure until enough people lose enough money that the accountants start taking notice and start saying "you should be more careful, or you'll lose your shirt". In the interim, the people that care are working insane hours to try to protect the things they believe in from inevitable doom, and risking being fired to do it. There is a balance to both sides, and the jury is out on whether or not anthropic/openai/alibaba can save us from the future we are creating now with short-term goals.
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.
Coding is just a small part of a modern software engineers job. And some may think it isn’t the hardest part.
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.
writing code is hard. building a successful product is harder, and is only sometimes a consequence of the code.
It’s not that coding is easy, it’s more that coding was not the bottleneck in the process at large organizations. It was (and still is) getting agreement on what to build, meeting with stakeholders, and dealing with the ever-changing priorities.
A lot of people enjoy coding, it’s the rest of the job they don’t like. That’s why it feels hard.
If a tool was going to come along and automate away a huge part of a programmer’s job, I think most would want that tool to eliminate the meetings, ambiguity, scope creep, and administrative work… not the coding itself.
My best days at work were days with nothing on my calendar, when I could just put on some headphones and make something. At the end of the day I felt like I accomplished something and had something I could see and use to show for it; I finished the day happy and energized. Contrast that with a day full of meetings, fire drills, and busy work, where at the end of the day I’m mentally and emotionally drained, wondering if I should quit to stock shelves at the local grocery store. Which day sounds “harder”?
I don’t know about where everyone else works, but defining the details of what to build seems so hard that no one actually does it, so it falls on us as we build things. During one project I got a directive from the CIO (which has only happened 1 time in 20 years) to get what I was working on done in 4 weeks. I made all the decisions myself when it came to the details and had something mostly working in 2 weeks (I skipped all meetings and any other distractions during this time). Several months later, the bureaucracy came into play. The principal architect on the project, who I never talked to before the CIO told me to get it done, finished his design and some details needed to be worked out. One such detail was a port list. It took 4+ months of meetings to get that done, and it still required constant tweaking after that for another year. There was a half dozen other things like that in the same project. So yeah, the initial code was pretty quick and fun to write, and then it was followed by 2-3 years of hell, that probably should have been worked out before we started coding. I ended up having to go back and re-write a bunch of stuff to align with the design that was decided on over a year after the deadline the CIO gave me. In most cases, I think the updated code is worse, as the bureaucratic design creates a lot of operational work that my original design avoided entirely, but I digress.
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.
interestingly ai has reignited the craft of performance and efficiency in programming. overall in the macro timeline i think the profession is going to be in a better place
Well written. I completely agree with you.
Chainsaw isn't better than the lumberjack.
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.
> 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...
> 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.
whenever someone says this I assume they mean a crud react app which is a small part of what 'coding' encompasses
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.”
long said that success is 1% idea, 9% implementation and 90% other stuff like marketing that I don't care about.
2010 - "Everyone can learn to code, come work at my startup."
2026 - "Coding was always hard, please don't lay me off."
Code was never the hard part
I roll my eyes at this when thinking about the poor JavaScript developer that cannot write code without things like jquery or React.
If code were so easy there wouldn’t be so much bloat and slow garbage in the world.
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
Microsoft did research on this and it was found that only 14% of time was writing code.*
That 14% might have been hard, but it is definitely still the smallest part of being an engineer.
* https://www.microsoft.com/en-us/research/wp-content/uploads/...
Shots fired
Exactly! Try reading a large C code base.
I mean, yeah, we are pretty trash without years of domain knowledge. But programmers do have a large domain. Some are experts at a/v, some security/networking, some like to make games/demos. These domains were highly accessible to us and still are. It's not like we solved coding exercises all day when we weren't leasing our souls to companies.
In which world are you living? For most programming jobs, the code is absolutely the easiest part of the whole thing, which is just gatekept into absurd bureaucracy and ceremony. Even if coding became 100x faster with 0 errors tomorrow, the software in most companies would still move at a snail's pace.
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.
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.
Someone said this?
> Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs?
Programming used to be a rare skill. Not so much now. In fact, it hasn't been for well over a decade.
My current employer started aggressively hiring for programmers in India in the early 2010s. They get paid a fraction of what our software engineers do in the US. There are many talented engineers in India, and those who get hired by us either find a way to come to the US for an enormous pay increase, or use us as a stepping stone to quickly find better work. And my employer is seemingly fine with this. They expect these cheap employees to do programming, not engineering.
Programming may not necessarily be easy, but it is cheap. It has become a relatively common skill, driving down its market value. A lot of tech companies were slow to figure this out because times were good, interest was low, and investment was flowing.
AI is waking people up to a truth that has been around for a while now.
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 software world has an abundance of mediocre coders that just happen to be good at writing e-mails, meetings, architecture (but not really), powerpoints, navigating customer requirements and product design. It’s in their interest to downplay coding skills.
While the former can certainly be challenging, it’s by far not rocket science. Any reasonably intelligent human can discuss requirements or design a product at a decent level.
Writing code at a decent level is beyond the average reasonably intelligent human. If your mind doesn’t tick a certain way, you will not be able to do it and it will be painfully obvious to anyone that can do it.
Depends on what you work, if you optimize algos and low level stuff I think it's an insult if you're like 95% that have fairly easy issues and just juggle data around it isn't and code has never been the problem. Even now the issue where I work is the actual solid requirements and technical plan before the implementation. I move higher up to something like architecture/rm since AI coding is pretty decent and does the job.
Insisting that code is the hard part is like insisting that spelling & grammar are the hard part of being a writer
I think the statement "code was never the hard part" is true but it's relative.
Programming is not easy and it takes years to master. Some people became really good at solving complex programming puzzles and 'Code Jams' and focused on it. Unfortunately, the same aspect which made this skill highly visible and highly praised, is what made it easiest to automate.
All those medals, trophies and certificates... not the mention advantages at big tech software job interviews... Came at a cost.
Meanwhile there is a whole group of people who have been honing their skills in software design, architecture, distributed systems, security and other less visible, less rewarded skills who have been ignored by the markets. These people still can't be automated.
It's a large problem space so after a decade or two, the coding aspect feels small relative to all the theory and experience surrounding it.
I met many senior people who didn't take programming seriously as a skill, long before LLMs.
One time, when I was at university, one of my math lecturers was boasting about the superiority of math as a discipline and said to the class "Software engineers... There are no software engineers; they're programmers."
That statement was never true but it's much more obvious now. The fact that a lot of people shared this belief highlights the fact that these other skills were invisible.
There is probably as much engineering (if not more engineering) involved in delivering a complex, reliable software project as there is delivering a complex skyscraper project in civil engineering... It's the same kind of activity; lots of interdependent parts, each with their own constraints and requiring many decisions to be made with lots of tradeoffs. At least with a skyscraper, the customer requirements are relatively very stable.
Too many people on hacker news sound like blacksmiths at the beginning of the industrial revolution. Get with the times, artisanal handwritten code is worthless
Geez people.
Sometimes coding is hard. There are two types of hard things: algorithms and architecture. LLMs are good at algorithms, not good at architecture.
Most of the time coding is not very hard, it’s filling in the blanks, implementing the business logic, writing boilerplate code. LLMs are good at this too.
Saying AI can do all the code isn't even accurate either though that's what's weird about all these takes
As soon as the context builds up high it just starts doing things straight up wrong
I've been trying to network a simple tactics game with AI and it just is a hydra of sync issues despite clear explanations of what they are and bug reports and desired end-states.
As a coder/programmer/programmer analyst/senior technical staff/software developer for over 60 years, I approve this message.
It’s not that coding is easy. That misses the point. The point is, coding is recurrent. Automation follows recurrence, not ease.
Tech is not the issue, people are
"If figuring out what to build is the hard part, why do so many product managers seem clueless" - because people
"LLMs may be good at coding" - they are not;
Insult it one thing, it’s also not true in the slightest which is the bigger issue.
> 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.
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.
> Code was never the hard part
And yet I spent a majority of my career fixing mistakes, including my own
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.
>If coding is easy, was Carmack just at the right place at the right time?
Yes, it's fairly axiomic that he was "just at the right place at the right time" because there are dozens of modern "boomer shooters" on steam that are not nearly as successful as DOOM or Quake. You might counterargue that its always harder to do something thats never been done before but that would only be a tacit admission that coding actually was the easy part in that case.
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.
> talking to users ... good code ... we should aim for both
tl;dr nothing has changed.
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.
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.
> 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
Code really is the easiest part. That doesn't mean code is easy. It means everything is hard, and code is just the least hard part. The best programmer in the world will still create bugs. Therefore you need something else to account for and deal with the eventual bugs.
In the rest of the engineering world, the way you do that is by standards bodies developing reliable, tested, certified methods to build things that avoid common problems. Pipes that are certified to a certain PSI or UV exposure. Wires certified to a certain amount of amperage, wetness, heat. Nails certified with a certain metal grade, tolerances.
Those standard parts are then used in a certified building method for a specific application at specific usage criteria. 3x 12d nails in one kind of wood joint. Beams spaced 24" apart, with 3/4" CDX plywood spread load. You don't guess or follow trends. You don't do what you think is "clean" or "beautiful". You solely follow the engineering standards and code. Now you don't have to think much, and your results are highly reliable. The job becomes easy.
Software doesn't have professional engineering and building standards like that. So humans literally just make this shit up as they go, making software however the zeitgeist of HN says "feels good". This results in unpredictable, unreliable software products that are hard to build because nobody agrees on the "right way".
Somebody read a blog post, or a slogan or quip on a Wikipedia page, and decided on their own interpretation of how that generic advice would drive their work. Software engineers only talk to other software engineers, so they don't realize how incredibly unscientific, inefficient, unreliable, and difficult their work is. Trying to make something predictable and reliable is therefore very hard. Not because writing the code is hard, but because the entire software product lifecycle is basically vibes. The uncertainty, variability, and lack of reproducible standard parts makes figuring out how to build something become way more complicated than it should be.
The actual lines of code are easy to read and write. But without the standards common to every other engineering discipline, the rest of the job is a slog.
The software development profession is in the midst of upheaval. Nobody knows how the AI revolution will play out in the end, but it is clear many aspects of work and life will be transformed—including programming.
I'm still not seeing it.
I'm seeing a lot of loud people, a lot of LOC produced, and a lot of people angrily pointing to their sideprojects... but no massive impact outside our bubble. Remember it's 2026, we are 5 years into this hype, the models are better than ever, and all the software we used around us is basically in the state it would have been in had we projected 2021 tech 5 years into the future ("in 2026, there will be... another backend JS runtime!")
I'm afraid all the personal anecdotes of technologists have not translated to real world results... other than negative ones like GitHub now having 0 9s of reliability.
Of course I suppose I'm "coping", as if I wouldn't be over the moon if AI had made me 10x productive... but maybe, just maybe, a lot of people really like talking to chatbots?
Don't get your panties in a twist over marketing slop selling AI to companies
Hmm, hasn't "code was never the hard part" typically been said when downplaying the impact of AI-assisted coding, rather than highlighting it for marketing purposes?
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.
Those who know, do. Those that understand, teach.
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?
Fun example I've had (some weeks ago), Agent completely dismissed the lack of strong consistency in our db system, this tiny bug would have caused a massive problem in the future.
A bug that is not immediately obvious, no syntax error, logic is sound, works as expected on local and QA envs. But let it run in prod for 2 months and you have a massive problem.
I'm not dismissing LLM's here btw, just pointing out that there is probably a lot of things that go into the category "you don't know what you don't know". These kinds of issues may or may not be a problem depending on the business you are in.
Most of the time the latest models perform better than I expect.
Ouchy. That isn't as bad as the slop I've seen: one example I saw a few weeks ago from vibe-coded software had this absolutely mind-blowing bit of Rust code:
pub(crate) fn zeroed_safe<T>() -> T { unsafe { std::mem::zeroed() } }
pub(crate) fn read_unaligned_safe<T: Copy>(src: const T) -> T { unsafe { std::ptr::read_unaligned(src) } }
pub(crate) fn box_from_raw_safe<T>(ptr: mut T) -> Box<T> { unsafe { Box::from_raw(ptr) } }
pub(crate) fn isize_to_wndproc_safe(value: isize) -> WNDPROC { unsafe { Some(std::mem::transmute::< isize, unsafe extern "system" fn(HWND, u32, WPARAM, LPARAM) -> LRESULT, >(value)) } }
No, I'm not joking either, this is actual code that Claude wrote (and I'm pretty sure it's the latest models too but I don't actually know for certain, since the "dev" never specified). This idiom is repeated about 238 more times through that one file. I have tried repeatedly to help this person out but they're the kind of vibe-coder who thinks they know best, and who will take your advice and drop it into CLAUDE.md verbatim, and then Claude will go off and do the most literal interpretation of that text and not best practice.
To be clear, I don't hate LLMs. They're really useful for very specific things or where you know the domain very well. But then I see slop like this (and the dependency many people have on them -- I have literally heard my own close acquaintances say that they could not see themselves without a Claude subscription) and it really hammers home that software quality is not at all going to get better because of these things unless something changes.
Edit: grammar/spelling
Yeah, trying too hard to guide with hard rules, instead of asking the LLM for self-review, is going to go wrong. The LLM is much better at code review than it is at writing code.
Use a high effort model and let the llm review it's output and figure it out on its own.
The code still won't be great, but it'll be good enough.
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.
> Oh. So, because I said I work in software you assumed I worked in safety critical systems?
No, I didn't. I asked you to provide me an example of code that you had generated via AI that might survive in such an environment. But if you re-read my original post, I also gave you an escape hatch: just code that was correct. Not even formally.
I'd say your refusal to provide any examples of your original claim is pretty telling, and your reasoning is pretty convenient for you, now isn't it?
Edit: also, I'd like to point out that it was you who used the word "software" as a general claim. You never specified what kind of software. Since you continue to expect me to derive the proof for you instead of you providing the evidence, I don't see any need to continue this discussion since nobody is obviously going to learn anything. I'm sure many of us here would love to learn what secret sauce your using that makes software engineering so trivial, but you don't seem willing to actually provide that.
As I said, feel free to experiment, I gave you some hints where to start. Or not. I don't win any prizes either way.
They simply asked you to support your claims, as an ethical person would. Without that, your words are just noise.
And I see that this isn't the only comment you made where someone asked to provide supporting evidence and you dodged.
You're welcome to try it out yourself.
Non responsive trolling. Bad faith muted.
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