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.
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.
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.
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.
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.
Fixing bugs, improving performance, paying down technical debt all require this as well, which makes them significantly more difficult to actually implement.
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.
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.
The $480M bug that killed a trading company in 12 secs
Challenger
Probably a bunch of stories from healthcare
This might be the reason why many personal projects are so technical and impressive - it's the itch that's not scratched at work.
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.
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.
That's the first time I've heard that idiom. What does it mean?
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.
I do, but the order of the keys makes a difference somewhat.
Unfortunately it is still the job...
Even when code was not the hardest problem, it was still a hard problem.
‘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.
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.
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 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?
"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.
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.
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.
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.
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.
> 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.
You can absolutely not do this
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.
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.
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.
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.
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.
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
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.