from Hacker News

The reality of working in tech: We're not hired to write code (2023)

by foxfired on 4/3/25, 12:53 AM with 132 comments

• by don-code on 4/3/25, 2:19 AM

  I have a coworker who _excels_ at writing code - one of those engineers who can metabolize caffeine directly into code.

  They write code to implement the all-important features. They write code to work around lack of process. They write code to work around problem people not doing their jobs well. They write code to work around buggy code by other developers. They write code to work around their own code, written weeks or months earlier.

  I've been encouraging them to _reduce_ the amount of code they write, and instead consider the context around why they're writing the code. Code is just one way - and not always a particularly good way - that we can solve people and process problems.

• by mcv on 4/3/25, 6:10 AM

  I wonder if the fact that we're not hired to write code, is also the reason we're not paid as much as some other roles. This is my big frustration: that senior programmers (in NL at least) are not paid as much as managers, POs, various kinds of architects, and even scrum masters.

  A couple of years ago, I was freelancing for a company where I wrote a lot of excellent code. They had a bunch of data they wanted to do something with, but weren't entirely sure what or how, so I did that for them. Connected, visualized it, made it fast, and they loved it. And so did I. It was fun work, I talked to a lot of people about what they wanted and needed, and delivered that.

  My freelance period ended, but I wasn't ready to leave this project yet, so I became an employee, but that turned out to be a massive step back in terms of income. Despite the fact that I worked closely with lots of stakeholders and solved complex problems for them, their internal rules didn't allow them to pay me as more than a code monkey. I felt all the non-code work I did wasn't being appreciated. Nor the code work.

  I left, they ruined the application (it's apparently slow as molasses now), and now I'm about to go back. I guess I've made peace with the fact that they don't pay programmers as much as I think they should. (It's not actually bad pay, just not as much as non-programmers get.) But mostly, it was a fun project that taught me a lot, and I want more of that.

• by lijok on 4/3/25, 2:14 AM

  In most companies, writing code is the last thing developers (should) do. You're there to achieve business objectives, and you were hired because someone thought your experience and skillset will be necessary to achieve those business objectives. Sometimes those objectives are met with an excel sheet, sometimes they're met by losely integrating various 3rd parties, sometimes they're met by integrating various libraries, and sometimes it requires treading new ground and writing some real code.

  The best web dev isn't the one that knows .Net, React, Svelte, GraphQL, micro-frontends, etc. The best web dev is the one that can convince their manager that their business objectives can be achieved by using WordPress.

• by arealaccount on 4/3/25, 2:08 AM

  In the same way a nascar driver isn’t hired to drive, but hired to win races.

  Feels sorta pedantic.

  Fun read nonetheless.

• by MathMonkeyMan on 4/3/25, 2:07 AM

  The jobs I've had are about figuring out what to do, modifying code, and communicating why to other people.

  It's fun to create a new thing or to remove an old thing that isn't needed anymore, but that's just when you can get away with it.

• by prescriptivist on 4/3/25, 2:53 AM

  Guess what: This has all changed with LLMs. The impact of the average developer is proportional to the amount of code they ship in a world of copilots (key word is "ship", not write) and that's why some of the staff engineers I work with have 3 concurrent Cursor projects for the same codebase in flight at the same time. These are some of the best engineers I've ever worked with and they have drank the cool-aid of volume over quality.

  I'm keen to this because I maintain our CI systems and have become acutely aware of the overhead of hallucinations breaking our CI tooling in pathological ways that draw me in to diagnose. A year ago I would have to log into our CI Kubernetes cluster to diagnose a busted build that doesn't self-report failure maybe... once a month. These days it's a couple times a week. LLM based dev is both amazing in the legit force multiplier it adds to writing code as well as the way it introduces some of the most incoherent and silly ways it breaks existing conventions.

  I guess the headline is correct in that we are not hired to write code anymore, instead we are hired to shepherd code now, and a lot of it. And a lot of this code we shepherd is good enough but some amount of it is bad enough to break existing processes, but that is secondary to the volume and velocity we perceive from LLM code gen.

• by xnx on 4/3/25, 2:18 AM

  Code is a liability. Employees are a liability. Solving problems with as little code/employees/risk/cost is the goal.

• by johnwatson11218 on 4/4/25, 12:10 PM

  I was working with deepseek to distill my thoughts on this and the best quote was " This resembles a lossy compression of software, where the "loss" is non-essential complexity.".

  "literate programming meets LLMs"—where the goal isn’t just fewer lines, but denser meaning. If you’re experimenting with it, start small: try distilling a single function with GPT-4 + human review, and see if the result feels correct but simpler. In other words LLM assisted code refactoring for compression and clarity is the way to resolve the argument between 'more' or 'less' code in general.

• by vkaku on 4/3/25, 10:27 AM

  I think that we're diluting the scope too much. Not only do people get paid to solve problems, also to execute them. When we get into the non execution zones, it causes many layers of beaureaucracy that will bankrupt any respectable company.

• by em-bee on 4/3/25, 4:17 AM

  While I was previously the go-to person for building new features, I was unable to contribute to the implementation of Angular due to my lack of experience with it.

  was he unable or was he not allowed or simply not asked? it sounds like it could be the latter which is something i'd expect from that kind of dysfunctional company, but if he was really unable then this person should not be working as a software developer.

• by zombiwoof on 4/3/25, 3:06 AM

  We are hired to support whatever closed door management agreements were made. Mostly not even made for the company goals but the managers self interest

• by MPSimmons on 4/3/25, 2:08 AM

  >Does it mean that we shouldn't write code or shouldn't try to get better at it? Not at all. When working in a team, what matters most is that the weakest developer be at the very least competent. The rest is to try to build and maintain the company's product and features.

  Yes. A company doesn't exist to hire programmers who write code. Software development is a means to an end.

• by Willingham on 4/3/25, 12:06 PM

  This article makes many valid points, but it’s important to remember 10%~ of devs are system developers(OS, compilers, firmware, database kernels etc.) For these jobs, the code itself often IS the core product. Correctness, stability, and compatibility come first, therefore the ‘out with the old and in with the new’ mentality is much less prevalent.

• by disambiguation on 4/3/25, 6:26 PM

  Yes the nature of employment is that you're paid to do whatever the guy paying you tells you to do. Roles and specializations are organizational tools - meaning, for the benefit of the organization, not you. There will never be an exact match between the "definition of a role" and "the work that needs to be done."

• by 94b45eb4 on 4/3/25, 3:47 AM

  I used to hear this all the time back in the early 2000's. It's far from a new idea.

  The version I heard (or at least the one which stuck in my head) was "your job is not to write code, your job is to solve problems".

  edit: I wish this was more mentioned more frequently these days. I see junior developers very focused on superficial aspects of code and specific "cool" frameworks these days. Often I find myself asking "what problem does this solve? What are the trade-offs with your approach? etc." and it's just crickets. I think we have made a lot of progress with modern frameworks, tools, etc. but I also think there is something from the "old days" of programming which we have lost, which I think we should have fought a bit more to keep.

• by dogleash on 4/3/25, 3:29 PM

  Managementbrain's definition of a well rounded developer is also the definition of people they're trying to promote out of development. Then they look around at developers wondering why they all just don't "get it".

  Probably because they took the money to change role rather than keep the job they wanted.

• by renegade-otter on 4/4/25, 10:18 AM

  We ARE hired to write code, but it's our job to know how to write less of it.

  Sometimes I go into the weeds and create a monstrocity bowl of spaghetti around a feature. Then I pull back, simplify it, and get amazed at how I missed that.

  The trick is to STOP and think. Not everything is a "needful".

• by yawnxyz on 4/3/25, 2:48 AM

  if this was true, then leetcode wouldn't be the cost of admission?

• by WalterBright on 4/3/25, 3:25 AM

  You're hired to make money for the company.

• by deterministic on 4/4/25, 3:08 AM

  Not my experience at all. I write code every day and our customers pay real money to use it.

• by vincenthwt on 4/3/25, 2:22 AM

  In other words, software engineers need to "sell" the value of their work.

• by BrenBarn on 4/3/25, 3:03 AM

  This is another article that largely boils down to "Some people really really like money."

• by calimoro78 on 4/3/25, 10:03 PM

  Our first job is not: to code. Our first job is: not to code.

• by upghost on 4/3/25, 2:05 AM

  I mean its no wonder "vibe coding" is so appealing if this is the incentives framework. Why put brainpower in if it is treated as disposable junk. Just tell the AI to vibe out some slop and move on -- "business" can't tell the difference anyway.

  FWIW-- I resist this mindset, but I am sympathetic to it, I understand where it comes from. Pearls before swine and whatnot.