11 ms·

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 t

by prinny_ 1mo ago

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.

agumonkey 1mo ago
Yes, it reeks of people who spend a lot of time following naming scheme convention and copy pasting a lot of shallow things.
figassis 1mo ago
Yesterday I was working on some video editing tools to create a demo from screen recordings. I started with Gifox, recorded a 5 min video and then started cutting it in their UI (small things like remove these 5 seconds from here, etc). Everytime I performed an action, the spinner would start and take 10-30 seconds to complete. This was on a 36gb M3 mbp with almost nothing else running. It got so unusable and it slowed down my machine so much that I had to force kill the app, and that did nto work, I had to restart the machine. Then I tried in iMovie. I tried importing the raw gifs. It would hang everytime and I had to restart it. So I had to export .mov directly from Gifox. It worked great on iMovie, until I needed to speed up or slow down some clips. I noticed on the first operation, it would spin for about 3s, on the second, 5s, on the third, 10s, and by the 6th operation it would either spin for 1min or not stop at all. The machine started getting flow, iMovie was using 22.4gb of my 36gb machine. Had to also force quit iMovie several times. A task that should have taken 30-60min tops, took 5h. Memory was definitely leaking somewhere, and in different application with completely different engineering budgets. The product was there, people were paying for it, the software was not delivering, which means it was costing customers time and money, meaning people were overpaying for it. This is not a thing product can solve. Programming is absolutelly the hardest part sometimes. You could say throw more AI at it, and MSFT tried, how's that going for them with all the weird product decisions and bugs and apologies?
socratic_weeb 1mo ago
This take is foolish and will always be foolish. Coding was mever easy in ANY domain (not just low level stuff) and the fact that we built syntax highlighting, high-level languages, auto-conplete, static analysis, debuggers, etc., in order to make it easier is the proof.
- halsafar 1mo ago
  Take a step into the business side of software. Code is definitely not the hard part. You wouldn't say wood is hard part (heh) of wood working. It is planning and architecting. When to use the right tools. Just because a ruler has hash marks that doesn't mean measuring is hard it means the ruler doesn't work without it.
  - menaerus 1mo ago
    What type of software have you been writing before entering the business side of software and for how long?
mikojan 1mo ago
> 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.
- rcxdude 1mo ago
  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.
  - avilay 1mo ago
    "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.
gxs 1mo ago
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
gosolozero 1mo ago
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.
- lelanthran 1mo ago
  > 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). That last 10% is the value-add. If you aren't doing that, the other 90% can be done by pretty much anyone, and they won't be "SWE", they'd be minimum-paid white-collar workers. A lot of people miss this in their haste to rationalise their evaporating value - "I'm still useful, because AI is only doing that 10%, I am still needed for the other 90%", not realising that if they aren't needed for that last 10%, they are interchangeable with the office receptionist :-/
  - snowe2010 1mo ago
    This logic makes no sense. If 90% of a software engineers job is not coding, then the valuable part of their job isn’t coding. It’s the other things. Else junior devs or interns would be doing all that work. So no, they aren’t interchangeable with the office receptionist, else the office receptionist would already be doing that job.
- menaerus 1mo ago
  I have been writing code professionally for almost 20 years, hard or at least non trivial problems what many would consider, and my job description does not resemble the tiniest of what you're describing. Coding _is_ difficult and dedicating only 10% of your time for that task will leave you very quickly without the job. Most of the time not only that you spend close to 100% of the time doing the coding part but even more than 100%. Some problems and domains are just difficult and not trivial to the part you can automate them. With the age of AI this may be changing though.
ls-a 1mo ago
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.
hintymad 1mo ago
> 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.
- wbl 1mo ago
  The infra org has to also understand their internal customer!
  - hintymad 1mo ago
    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.
    - senderista 1mo ago
      But do the infra team engineers use the infra they're building?
      - hintymad 1mo ago
        They do, and they help their users all the time
PunchyHamster 1mo ago
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"
mempko 1mo ago
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.
- javier2 1mo ago
  Especially writing code has rarely been very hard the past 10 years. It was always reading existing code and understanding its implications that was the hard part, and understanding how to adapt new requirements together with the existing ones.
- ErroneousBosh 1mo ago
  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.
- retinaros 1mo ago
  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.
- michaelrpeskin 1mo ago
  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.
rockemsockem 1mo ago
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.
- Aeolun 1mo ago
  > a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing Yes, and absolutely nobody will care if it does the thing it was meant to do. Performance is near always an afterthought because there is no single team that gets judged on performance.
  - yallpendantools 1mo ago
    I think we often don't realize how much performance is part of the user requirements (i.e., "the thing it was meant to do") because users don't specify that as a requirement. And when they do we get all engineer-y about it and start asking about TTFBs, throughput rates, TPS's and nobody gets anything sensible out of the conversation. But users don't mention it because they don't know how slow complex systems could be or how complex a mere CMS could be that for them this is one of those requirements that don't even need to be said. Anecdata time... There was once a scrappy start-up who, like all scrappy start-ups, was taking on the heavyweight incumbent gorilla of the industry. They started poaching the small customers from the gorilla, just enough for the gorilla to notice. These customers often cited how "fast and lightweight" the start-up's platform was compared to the gorilla. The claim wasn't really supported by Grafana. The numbers weren't bad; in fact they were very average. For some metrics, the gorilla was actually still the gold standard the scrappy start-up targeted. The engineers suspected "fast and lightweight" had more to do with the user experience (they had smoothly-animated loading screens) than actual server performance. Still, it's not a complaint so they took that as a win. After a couple of years of steady growth poaching from the gorilla, they started getting bug reports of slow performance. The customers have been seeing more and more of the smooth loading screen animations and less of the data they actually need to work on. And this time, the claims were supported by Grafana! There was no way to massage the statistics to even claim the reports are outliers or to pass the blame on to the unreliable ISPs. The problem, it turns out, was that they were sending emails as notifications for a bunch of user actions and at that point there were about 2-3 such user actions per minute. While they could async some of those, there were a bunch whose succeeding states assumed that the notifications have been sent. After three weeks of profiling and going through the whole performance optimization playbook, the fix boiled down to a one-liner in SQLAlchemy that offloaded loading notification mailing lists to Postgres cursors rather than loading whole lists into memory in one go. Moral of the story: no one is asking you to build a racecar but that doesn't mean performance is not table stakes. A good senior engineer knows just where the balance is to still deliver business value. That is the salary you are paying for.
rudnevr 1mo ago
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.
ivanjermakov 1mo ago
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.
- bayindirh 1mo ago
  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.
  - munksbeer 1mo ago
    > 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. I don't mean to undersell this type of programming. I don't work in the true HFT space, which now means something very different from 20 years ago. These days it is FPGA, or maybe more, not sure. But for standard low latency (think microsecond hotpath, rather than nanos) the techniques are well known and easily codified with example code and AGENTS.md rules. You can achieve very good results this way, and then further refine with human intervention and measuring. Measuring and iterating is often the hard part. I'd really love someone to describe in detail the type of programming they are doing that can't be codified such that another human can learn it, follow the rules and achieve the needed results. I just don't see any magic in our craft, it is all just following rules.
    - 1mo ago
jibal 1mo ago
"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.
qurren 1mo ago
> 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.
- ToucanLoucan 1mo ago
  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.
  - qurren 1mo ago
    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.
aleph_minus_one 1mo ago
> 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.
haswell 1mo ago
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.
- yyx 1mo ago
  Do you have any advice for someone who wants to take this path? I'm betting on determinism, simulations, tests and CEL.
nevdka 1mo ago
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.
jghn 1mo ago
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.
- DanHulton 1mo ago
  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.
didgetmaster 1mo ago
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?
- brabel 1mo ago
  > How many slow, buggy programs have been written because the assigned programmer did not yet have the expertise needed to do it right? Basically, all of it. By the time a programmer has enough experience to design and implement software properly they are “promoted” to some paper pushing management position.
nbardy 1mo ago
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.

by prinny_ 1mo ago

agumonkey 1mo ago

Yes, it reeks of people who spend a lot of time following naming scheme convention and copy pasting a lot of shallow things.

figassis 1mo ago

Yesterday I was working on some video editing tools to create a demo from screen recordings. I started with Gifox, recorded a 5 min video and then started cutting it in their UI (small things like remove these 5 seconds from here, etc). Everytime I performed an action, the spinner would start and take 10-30 seconds to complete. This was on a 36gb M3 mbp with almost nothing else running. It got so unusable and it slowed down my machine so much that I had to force kill the app, and that did nto work, I had to restart the machine. Then I tried in iMovie. I tried importing the raw gifs. It would hang everytime and I had to restart it. So I had to export .mov directly from Gifox. It worked great on iMovie, until I needed to speed up or slow down some clips. I noticed on the first operation, it would spin for about 3s, on the second, 5s, on the third, 10s, and by the 6th operation it would either spin for 1min or not stop at all. The machine started getting flow, iMovie was using 22.4gb of my 36gb machine. Had to also force quit iMovie several times. A task that should have taken 30-60min tops, took 5h. Memory was definitely leaking somewhere, and in different application with completely different engineering budgets. The product was there, people were paying for it, the software was not delivering, which means it was costing customers time and money, meaning people were overpaying for it. This is not a thing product can solve. Programming is absolutelly the hardest part sometimes. You could say throw more AI at it, and MSFT tried, how's that going for them with all the weird product decisions and bugs and apologies?

socratic_weeb 1mo ago

This take is foolish and will always be foolish. Coding was mever easy in ANY domain (not just low level stuff) and the fact that we built syntax highlighting, high-level languages, auto-conplete, static analysis, debuggers, etc., in order to make it easier is the proof.

halsafar 1mo ago
Take a step into the business side of software. Code is definitely not the hard part. You wouldn't say wood is hard part (heh) of wood working. It is planning and architecting. When to use the right tools. Just because a ruler has hash marks that doesn't mean measuring is hard it means the ruler doesn't work without it.
- menaerus 1mo ago
  What type of software have you been writing before entering the business side of software and for how long?

mikojan 1mo ago

> 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.

rcxdude 1mo ago
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.
- avilay 1mo ago
  "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.

gxs 1mo ago

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

gosolozero 1mo ago

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.

lelanthran 1mo ago
> 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). That last 10% is the value-add. If you aren't doing that, the other 90% can be done by pretty much anyone, and they won't be "SWE", they'd be minimum-paid white-collar workers. A lot of people miss this in their haste to rationalise their evaporating value - "I'm still useful, because AI is only doing that 10%, I am still needed for the other 90%", not realising that if they aren't needed for that last 10%, they are interchangeable with the office receptionist :-/
- snowe2010 1mo ago
  This logic makes no sense. If 90% of a software engineers job is not coding, then the valuable part of their job isn’t coding. It’s the other things. Else junior devs or interns would be doing all that work. So no, they aren’t interchangeable with the office receptionist, else the office receptionist would already be doing that job.
menaerus 1mo ago
I have been writing code professionally for almost 20 years, hard or at least non trivial problems what many would consider, and my job description does not resemble the tiniest of what you're describing. Coding _is_ difficult and dedicating only 10% of your time for that task will leave you very quickly without the job. Most of the time not only that you spend close to 100% of the time doing the coding part but even more than 100%. Some problems and domains are just difficult and not trivial to the part you can automate them. With the age of AI this may be changing though.

ls-a 1mo ago

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.

hintymad 1mo ago

> 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.

wbl 1mo ago
The infra org has to also understand their internal customer!
- hintymad 1mo ago
  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.
  - senderista 1mo ago
    But do the infra team engineers use the infra they're building?
    - hintymad 1mo ago
      They do, and they help their users all the time

PunchyHamster 1mo ago

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"

mempko 1mo ago

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.

javier2 1mo ago
Especially writing code has rarely been very hard the past 10 years. It was always reading existing code and understanding its implications that was the hard part, and understanding how to adapt new requirements together with the existing ones.
ErroneousBosh 1mo ago
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.
retinaros 1mo ago
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.
michaelrpeskin 1mo ago
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.

rockemsockem 1mo ago

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.

Aeolun 1mo ago
> a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing Yes, and absolutely nobody will care if it does the thing it was meant to do. Performance is near always an afterthought because there is no single team that gets judged on performance.
- yallpendantools 1mo ago
  I think we often don't realize how much performance is part of the user requirements (i.e., "the thing it was meant to do") because users don't specify that as a requirement. And when they do we get all engineer-y about it and start asking about TTFBs, throughput rates, TPS's and nobody gets anything sensible out of the conversation. But users don't mention it because they don't know how slow complex systems could be or how complex a mere CMS could be that for them this is one of those requirements that don't even need to be said. Anecdata time... There was once a scrappy start-up who, like all scrappy start-ups, was taking on the heavyweight incumbent gorilla of the industry. They started poaching the small customers from the gorilla, just enough for the gorilla to notice. These customers often cited how "fast and lightweight" the start-up's platform was compared to the gorilla. The claim wasn't really supported by Grafana. The numbers weren't bad; in fact they were very average. For some metrics, the gorilla was actually still the gold standard the scrappy start-up targeted. The engineers suspected "fast and lightweight" had more to do with the user experience (they had smoothly-animated loading screens) than actual server performance. Still, it's not a complaint so they took that as a win. After a couple of years of steady growth poaching from the gorilla, they started getting bug reports of slow performance. The customers have been seeing more and more of the smooth loading screen animations and less of the data they actually need to work on. And this time, the claims were supported by Grafana! There was no way to massage the statistics to even claim the reports are outliers or to pass the blame on to the unreliable ISPs. The problem, it turns out, was that they were sending emails as notifications for a bunch of user actions and at that point there were about 2-3 such user actions per minute. While they could async some of those, there were a bunch whose succeeding states assumed that the notifications have been sent. After three weeks of profiling and going through the whole performance optimization playbook, the fix boiled down to a one-liner in SQLAlchemy that offloaded loading notification mailing lists to Postgres cursors rather than loading whole lists into memory in one go. Moral of the story: no one is asking you to build a racecar but that doesn't mean performance is not table stakes. A good senior engineer knows just where the balance is to still deliver business value. That is the salary you are paying for.

rudnevr 1mo ago

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.

ivanjermakov 1mo ago

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.

bayindirh 1mo ago
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.
- munksbeer 1mo ago
  > 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. I don't mean to undersell this type of programming. I don't work in the true HFT space, which now means something very different from 20 years ago. These days it is FPGA, or maybe more, not sure. But for standard low latency (think microsecond hotpath, rather than nanos) the techniques are well known and easily codified with example code and AGENTS.md rules. You can achieve very good results this way, and then further refine with human intervention and measuring. Measuring and iterating is often the hard part. I'd really love someone to describe in detail the type of programming they are doing that can't be codified such that another human can learn it, follow the rules and achieve the needed results. I just don't see any magic in our craft, it is all just following rules.
  - 1mo ago

jibal 1mo ago

"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.

qurren 1mo ago

> 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.

ToucanLoucan 1mo ago
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.
- qurren 1mo ago
  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.

aleph_minus_one 1mo ago

> 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.

haswell 1mo ago

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.

yyx 1mo ago
Do you have any advice for someone who wants to take this path? I'm betting on determinism, simulations, tests and CEL.

nevdka 1mo ago

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.

jghn 1mo ago

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.

DanHulton 1mo ago
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.

didgetmaster 1mo ago

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?

brabel 1mo ago
> How many slow, buggy programs have been written because the assigned programmer did not yet have the expertise needed to do it right? Basically, all of it. By the time a programmer has enough experience to design and implement software properly they are “promoted” to some paper pushing management position.

nbardy 1mo ago

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.