9 ms·

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

123 points by foxfired 2y ago

upghost 2y ago
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.
MathMonkeyMan 2y ago
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.
arealaccount 2y ago
In the same way a nascar driver isn’t hired to drive, but hired to win races. Feels sorta pedantic. Fun read nonetheless.
- defrost 2y ago
  More in the manner a foreman is hired to deliver cars to end customers. A nascar driver seems like overkill, competent drivers that can deliver cars without speeding, truck drivers that can load up and move 10 cars at a time, managing a team of subcontractors who can drive on demand as needed, etc. all seem like better options.
- BoiledCabbage 2y ago
  > Feels sorta pedantic. Absolutely not. A Nascar driver isn't hired to drive to the grocery store. Or to run errands. Their not hired to drive leisurely. They're not hired to be the safest driver. They're not hired to drive the absolute highest speed either (and crash). Their hired to win races. And it's important to understand that. The difference is that in Nascar it's very visible to everyone when a Nascar driver is driving in a way other than what they were hired for, it's not as clear for a programmer. Not to mention success as a programmer also means doing many things other than programming, including knowing when to say "we shouldn't build this".
  - mitthrowaway2 2y ago
    But they're also not hired to simply "win races". You don't hire them to tinker with the car's engine, invent a tire-traction-enhancing additive, lobby for rules changes that favor your team, subcontract the driving to a better driver, or play loud music to disrupt the sleep of the opposing drivers on the night before the race. You hire them to drive the car well enough to win, because driving is the skill you hired them for. You don't hire them to drive Ubers, sure, and likewise you want your programmers to be building things of high value. But you also don't expect them to just walk into the CEO's office, sit down in the big chair, and say "Actually, rather than writing code I can contribute more value from here, so today I'll do this job."
- taneq 2y ago
  I don't think it's pedantic at all. Your NASCAR driver is hired to win races, not to drive. If they drive on the highway, or down to the shops, or at the track when there isn't a race (or qualifying, or testing, etc.) on, or they drive a different team's car, or their own personal car, then they might be driving but they're not doing their job. Their job is to drive that particular team's car in such a way as to (directly or indirectly) win races. In exactly the same way, a software developer isn't just hired to write code. We're hired to solve problems. We usually do that by writing code but that's not always the right approach. If your employer told you they wanted to be able to control a Windows computer from a different computer in the next room, I hope you wouldn't start writing code, you'd just show them Remote Desktop (or VNC etc.) If your employer wanted a web dashboard for your product, you might write a bit of code, but you'd try and find some existing dashboard project with an appropriate license, and hook your product's metrics up to that. Writing code is a tool, of course, and if there's no better way to do a thing (like if you're developing a new product) then writing code is going to be necessary, but a lot of times it's a tool of last resort.
  - chii 2y ago
    if you hired a plumber, and asked him to fix the toilet, you expect him to fix the toilet. You don't expect him to tell you your whole house's plumbing sucks, you have lead pipes and to properly fix the toilet you need to replace it all. Just do the smallest, cheapest thing to fix the toilet. Replace 'fix the toilet' with 'writing code', for programmers.
    - billfruit 2y ago
      But software engineers are tasked with solving business problems. Ofcourse writing code is part of it. But other things too, for example communicating with users to understand requirements better, which lead to a reduction in scope, which reduced the code to be written. Or sometimes it is found that a good solution can be devised but which satisfies about 80 percent of the requirements, and it may be prudent to attempt to negotiate to remove the 20 percent requirements which cannot be satisfied.
- paulcole 2y ago
  The driver helps create revenue the car owner (often in the form of ad dollars). They may do this by driving well or they may do this by dating a country superstar or starting fights with other drivers. Sure at the end of the day driving is a big part of it, but it’s not the only thing. There’s what, 40 cars in the Daytona 500 and 39 of them lose. Are those 39 bad at their jobs?
  - shermantanktop 2y ago
    I know nothing about car racing and I’ll prove it: until your comment I always vaguely assumed that the number of cars in the Daytona 500 was…500?
    - paulcole 2y ago
      The 500 is the length of the race in miles. It’s 200 laps of a 2.5 mile track.
- godelski 2y ago
  Here's a less pedantic version: An academic researcher isn't hired to do research, but publish papers. Similar to TFA, I think the issue is more about alignment than anything. Goodhart's Law creeps up slowly and can destroy any business or industry. Both can also stay off alignment for an uncomfortable amount of time. In our research example, I think it is clear we want our researcher to actually be doing research and that paper publication is a (measurable) natural result of that work, but it should be a bit more obvious to see that there are ways to increase your publication rate without increasing your research rate (or even increase your publication rate at the cost of your research rate). (Obviously I disagree with TFA's point)
MPSimmons 2y ago
>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.
- mickael-kerjean 2y ago
  That's in theory, in practice a very large amount of companies only hire dev to bring jira tickets to completion where engineers are kept in a complete bubble and will never speak to a single actual customer.
lijok 2y ago
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.
- sharkweek 2y ago
  Oh wow… the WordPress example… Worked at a SaaS company that had a fantastic product and a great tech team that had built it. We also did a lot of data-based research and published it as white papers for lead gen. We wanted to start publishing more content on our site to expand reach, so the team decided a CMS would be a solution for the researchers and content marketers to publish without any tech involvement. Well it turns out our CTO, for a few justifiable reasons if we’re painting with a broad brush, absolutely loathed WordPress. So despite our arguments an integration would be easier/cheaper/less time consuming for everyone, we built our own CMS instead. And we, of course, ended up with a significantly worse version of WordPress that the content folks all hated. So it goes.
- compootr 2y ago
  ... or ones that can convince them not to use WP! (RE: matt mullenwag's breakdown/mental issues)
- facile3232 2y ago
  [dead]
- noosphr 2y ago
  >The best chemical engineer isn't the one that knows the pressure at which chlorine tanks fail, they are the one that knows chlorine gas can be stored in a garage in coke bottles. I look forward to the day that software 'engineers' are held accountable to the same degree that all other engineers are. I've written software for industrial machinery that can kill people if it went wrong. It's amazing how much your views on software change when you realize that your accountability starts at manslaughter and goes up from there. A human life is valued at around $10m in the developed world, incidentally my first real job was fixing an excel spreadsheet that caused $10m in trade losses after the API it called for exchange rates went stale. I'm not saying that we arrest everyone who writes a spreadsheet to help them with their job. But _someone_ should have their head on the line when it becomes a business process without oversight that can cause millions in losses, damages or bills.
xnx 2y ago
Code is a liability. Employees are a liability. Solving problems with as little code/employees/risk/cost is the goal.
- glitchc 2y ago
  Business is a liability. Maybe society should do away with most businesses and free up capital for more useful things. reductio ad absurdum
don-code 2y ago
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.
- pydry 2y ago
  I'd be trying to make better use of this tendency and talent, not trying to curtail it.
  - MultifokalHirn 2y ago
    you are clearly missing the point, and probably feel like you have that tendency and talent yourself
    - pydry 2y ago
      Not at all. Im more of an all rounder. I just like to see people matched to tasks which suit their temperament and talent. I hate seeing people who would rather be doing customer interaction half heartedly refuctoring while people who live and breathe code sit on customer calls bored out of their minds. I also feel a little disgusted at seeing talent wantonly squandered unnecessarily.
      - 9029 2y ago
        I'm having kind of a hard time imagining how such position would look like. Only working on greenfield projects, moving onto the next project once the codebase gets intolerable?
vincenthwt 2y ago
In other words, software engineers need to "sell" the value of their work.
- AliveShine 2y ago
  they like to call it "impact"
dev_mike12 2y ago
[dead]
yawnxyz 2y ago
if this was true, then leetcode wouldn't be the cost of admission?
- jimbob45 2y ago
  The article’s argument was that the company was able to migrate away from his code quickly, so his code didn’t matter. That’s…an argument. I think most developers, myself included, find the idea of migration to be almost impossible in many cases. The author handwaved that away too easily.
- Manuel_D 2y ago
  Writing code may not be the ultimate objective of software developers, but it is one of the primary tools to achieve that objective.
prescriptivist 2y ago
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.
- yoyoyoyop 2y ago
  Can you explain why they have 3 concurrent cursor projects for the same code base?
  - alexjplant 2y ago
    Presumably to crank out multiple features at the same time. After spending some time writing project rules for Cursor I've gotten it to reliably implement end-to-end CRUD operations from a simple description of the fields and functionality. It's pretty neat and surprisingly accurate but it does take time to generate on the order of ~1k LOC so I understand the desire for parallelization. If you have a well-factored codebase with loose coupling, good abstractions, etc. this should be pretty doable without them stepping on each other.
  - trashchomper 2y ago
    I assume they're trying to work on three features at the same time
BrenBarn 2y ago
This is another article that largely boils down to "Some people really really like money."
zombiwoof 2y ago
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
WalterBright 2y ago
You're hired to make money for the company.
- graphememes 2y ago
  most people forget this one
  - deleted 2y ago
    [deleted]
- mitthrowaway2 2y ago
  ... In theory yes, but company incentive structures don't always amount to this. If you take that too literally and act on your own initiative in ways unrelated to your job description, you may well be dismissed for circumventing upper-management decisionmaking and not staying in your lane, even if you make money for the company in the process. Or if you make tons of money for your company doing what you were hired to do, but do so from home in violation of a mandatory RTO order, you may quickly be replaced by someone who makes less money for your company but sits in the correct cubicle. In reality, you're not merely hired to make money for the company, you're hired to do your job, even if it's not the maximally profitable action.
  - WalterBright 2y ago
    The company can absolutely be wrong in their idea of how to make money, no doubt. But it's still what motivates them. I've stepped out of my lane to make money for the company, even when explicitly told not to, but the making money part meant they overlooked my transgressions. I figured they would, as businessmen really like making money. --- If you refuse a mandatory RTO order, you may be replaced with a less productive employee. But from a company standpoint, allowing you to violate it means others will demand it, and it may be a net loss for the company to keep you.
    - Apocryphon 2y ago
94b45eb4 2y ago
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.
- skydhash 2y ago
  I mentor a few friends and my first question when they come to me for troubleshooting is: What's the problem you're having and what has you tried so far? Then I restrict them from talking in too specific technical terms. Instead I orient the conversation to the appropriate metaphor, and more often than not, they can see the solution by themselves (unless it's really a technical implementation issue).
em-bee 2y ago
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.
mcv 2y ago
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.
- sam_lowry_ 2y ago
  This is the general culture in Europe. Techies do not get promoted and do not even have a possibility to grow to management. Everything is run by humanities people and we do not even have the right words to describe this situation, although some voiced their concerns for many years, see e.g. The Two Cultures [1] from 1959. [1] https://en.wikipedia.org/wiki/The_Two_Cultures https://en.wikipedia.org/wiki/The_Two_Cultures
  - lifestyleguru 2y ago
    European societies are extremely class based which is brutally visible in UK, France, Netherlands, even Germany. INSEAD and other MBAs see techies as washing machine repairmen.
    - 2y ago
vkaku 2y ago
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.
Willingham 2y ago
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.
dogleash 2y ago
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.
disambiguation 2y ago
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."
calimoro78 2y ago
Our first job is not: to code. Our first job is: not to code.
deterministic 2y ago
Not my experience at all. I write code every day and our customers pay real money to use it.
renegade-otter 2y ago
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".
- em-bee 2y ago
  this letter/piece of code is long and convoluted because i could not spend much time on it. had i had more time it would be short and concise.
johnwatson11218 2y ago
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.
deleted 2y ago
[deleted]

123 points by foxfired 2y ago

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.

MathMonkeyMan 2y ago

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.

arealaccount 2y ago

In the same way a nascar driver isn’t hired to drive, but hired to win races. Feels sorta pedantic. Fun read nonetheless.

defrost 2y ago
More in the manner a foreman is hired to deliver cars to end customers. A nascar driver seems like overkill, competent drivers that can deliver cars without speeding, truck drivers that can load up and move 10 cars at a time, managing a team of subcontractors who can drive on demand as needed, etc. all seem like better options.
BoiledCabbage 2y ago
> Feels sorta pedantic. Absolutely not. A Nascar driver isn't hired to drive to the grocery store. Or to run errands. Their not hired to drive leisurely. They're not hired to be the safest driver. They're not hired to drive the absolute highest speed either (and crash). Their hired to win races. And it's important to understand that. The difference is that in Nascar it's very visible to everyone when a Nascar driver is driving in a way other than what they were hired for, it's not as clear for a programmer. Not to mention success as a programmer also means doing many things other than programming, including knowing when to say "we shouldn't build this".
- mitthrowaway2 2y ago
  But they're also not hired to simply "win races". You don't hire them to tinker with the car's engine, invent a tire-traction-enhancing additive, lobby for rules changes that favor your team, subcontract the driving to a better driver, or play loud music to disrupt the sleep of the opposing drivers on the night before the race. You hire them to drive the car well enough to win, because driving is the skill you hired them for. You don't hire them to drive Ubers, sure, and likewise you want your programmers to be building things of high value. But you also don't expect them to just walk into the CEO's office, sit down in the big chair, and say "Actually, rather than writing code I can contribute more value from here, so today I'll do this job."
taneq 2y ago
I don't think it's pedantic at all. Your NASCAR driver is hired to win races, not to drive. If they drive on the highway, or down to the shops, or at the track when there isn't a race (or qualifying, or testing, etc.) on, or they drive a different team's car, or their own personal car, then they might be driving but they're not doing their job. Their job is to drive that particular team's car in such a way as to (directly or indirectly) win races. In exactly the same way, a software developer isn't just hired to write code. We're hired to solve problems. We usually do that by writing code but that's not always the right approach. If your employer told you they wanted to be able to control a Windows computer from a different computer in the next room, I hope you wouldn't start writing code, you'd just show them Remote Desktop (or VNC etc.) If your employer wanted a web dashboard for your product, you might write a bit of code, but you'd try and find some existing dashboard project with an appropriate license, and hook your product's metrics up to that. Writing code is a tool, of course, and if there's no better way to do a thing (like if you're developing a new product) then writing code is going to be necessary, but a lot of times it's a tool of last resort.
- chii 2y ago
  if you hired a plumber, and asked him to fix the toilet, you expect him to fix the toilet. You don't expect him to tell you your whole house's plumbing sucks, you have lead pipes and to properly fix the toilet you need to replace it all. Just do the smallest, cheapest thing to fix the toilet. Replace 'fix the toilet' with 'writing code', for programmers.
  - billfruit 2y ago
    But software engineers are tasked with solving business problems. Ofcourse writing code is part of it. But other things too, for example communicating with users to understand requirements better, which lead to a reduction in scope, which reduced the code to be written. Or sometimes it is found that a good solution can be devised but which satisfies about 80 percent of the requirements, and it may be prudent to attempt to negotiate to remove the 20 percent requirements which cannot be satisfied.
paulcole 2y ago
The driver helps create revenue the car owner (often in the form of ad dollars). They may do this by driving well or they may do this by dating a country superstar or starting fights with other drivers. Sure at the end of the day driving is a big part of it, but it’s not the only thing. There’s what, 40 cars in the Daytona 500 and 39 of them lose. Are those 39 bad at their jobs?
- shermantanktop 2y ago
  I know nothing about car racing and I’ll prove it: until your comment I always vaguely assumed that the number of cars in the Daytona 500 was…500?
  - paulcole 2y ago
    The 500 is the length of the race in miles. It’s 200 laps of a 2.5 mile track.
godelski 2y ago
Here's a less pedantic version: An academic researcher isn't hired to do research, but publish papers. Similar to TFA, I think the issue is more about alignment than anything. Goodhart's Law creeps up slowly and can destroy any business or industry. Both can also stay off alignment for an uncomfortable amount of time. In our research example, I think it is clear we want our researcher to actually be doing research and that paper publication is a (measurable) natural result of that work, but it should be a bit more obvious to see that there are ways to increase your publication rate without increasing your research rate (or even increase your publication rate at the cost of your research rate). (Obviously I disagree with TFA's point)

MPSimmons 2y ago

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

mickael-kerjean 2y ago
That's in theory, in practice a very large amount of companies only hire dev to bring jira tickets to completion where engineers are kept in a complete bubble and will never speak to a single actual customer.

lijok 2y ago

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.

sharkweek 2y ago
Oh wow… the WordPress example… Worked at a SaaS company that had a fantastic product and a great tech team that had built it. We also did a lot of data-based research and published it as white papers for lead gen. We wanted to start publishing more content on our site to expand reach, so the team decided a CMS would be a solution for the researchers and content marketers to publish without any tech involvement. Well it turns out our CTO, for a few justifiable reasons if we’re painting with a broad brush, absolutely loathed WordPress. So despite our arguments an integration would be easier/cheaper/less time consuming for everyone, we built our own CMS instead. And we, of course, ended up with a significantly worse version of WordPress that the content folks all hated. So it goes.
compootr 2y ago
... or ones that can convince them not to use WP! (RE: matt mullenwag's breakdown/mental issues)
facile3232 2y ago
[dead]
noosphr 2y ago
>The best chemical engineer isn't the one that knows the pressure at which chlorine tanks fail, they are the one that knows chlorine gas can be stored in a garage in coke bottles. I look forward to the day that software 'engineers' are held accountable to the same degree that all other engineers are. I've written software for industrial machinery that can kill people if it went wrong. It's amazing how much your views on software change when you realize that your accountability starts at manslaughter and goes up from there. A human life is valued at around $10m in the developed world, incidentally my first real job was fixing an excel spreadsheet that caused $10m in trade losses after the API it called for exchange rates went stale. I'm not saying that we arrest everyone who writes a spreadsheet to help them with their job. But _someone_ should have their head on the line when it becomes a business process without oversight that can cause millions in losses, damages or bills.

xnx 2y ago

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

glitchc 2y ago
Business is a liability. Maybe society should do away with most businesses and free up capital for more useful things. reductio ad absurdum

don-code 2y ago

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.

pydry 2y ago
I'd be trying to make better use of this tendency and talent, not trying to curtail it.
- MultifokalHirn 2y ago
  you are clearly missing the point, and probably feel like you have that tendency and talent yourself
  - pydry 2y ago
    Not at all. Im more of an all rounder. I just like to see people matched to tasks which suit their temperament and talent. I hate seeing people who would rather be doing customer interaction half heartedly refuctoring while people who live and breathe code sit on customer calls bored out of their minds. I also feel a little disgusted at seeing talent wantonly squandered unnecessarily.
    - 9029 2y ago
      I'm having kind of a hard time imagining how such position would look like. Only working on greenfield projects, moving onto the next project once the codebase gets intolerable?

vincenthwt 2y ago

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

AliveShine 2y ago
they like to call it "impact"

dev_mike12 2y ago

[dead]

yawnxyz 2y ago

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

jimbob45 2y ago
The article’s argument was that the company was able to migrate away from his code quickly, so his code didn’t matter. That’s…an argument. I think most developers, myself included, find the idea of migration to be almost impossible in many cases. The author handwaved that away too easily.
Manuel_D 2y ago
Writing code may not be the ultimate objective of software developers, but it is one of the primary tools to achieve that objective.

prescriptivist 2y ago

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.

yoyoyoyop 2y ago
Can you explain why they have 3 concurrent cursor projects for the same code base?
- alexjplant 2y ago
  Presumably to crank out multiple features at the same time. After spending some time writing project rules for Cursor I've gotten it to reliably implement end-to-end CRUD operations from a simple description of the fields and functionality. It's pretty neat and surprisingly accurate but it does take time to generate on the order of ~1k LOC so I understand the desire for parallelization. If you have a well-factored codebase with loose coupling, good abstractions, etc. this should be pretty doable without them stepping on each other.
- trashchomper 2y ago
  I assume they're trying to work on three features at the same time

BrenBarn 2y ago

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

zombiwoof 2y ago

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

WalterBright 2y ago

You're hired to make money for the company.

graphememes 2y ago
most people forget this one
- deleted 2y ago
  [deleted]
mitthrowaway2 2y ago
... In theory yes, but company incentive structures don't always amount to this. If you take that too literally and act on your own initiative in ways unrelated to your job description, you may well be dismissed for circumventing upper-management decisionmaking and not staying in your lane, even if you make money for the company in the process. Or if you make tons of money for your company doing what you were hired to do, but do so from home in violation of a mandatory RTO order, you may quickly be replaced by someone who makes less money for your company but sits in the correct cubicle. In reality, you're not merely hired to make money for the company, you're hired to do your job, even if it's not the maximally profitable action.
- WalterBright 2y ago
  The company can absolutely be wrong in their idea of how to make money, no doubt. But it's still what motivates them. I've stepped out of my lane to make money for the company, even when explicitly told not to, but the making money part meant they overlooked my transgressions. I figured they would, as businessmen really like making money. --- If you refuse a mandatory RTO order, you may be replaced with a less productive employee. But from a company standpoint, allowing you to violate it means others will demand it, and it may be a net loss for the company to keep you.
  - Apocryphon 2y ago

94b45eb4 2y ago

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.

skydhash 2y ago
I mentor a few friends and my first question when they come to me for troubleshooting is: What's the problem you're having and what has you tried so far? Then I restrict them from talking in too specific technical terms. Instead I orient the conversation to the appropriate metaphor, and more often than not, they can see the solution by themselves (unless it's really a technical implementation issue).

em-bee 2y ago

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.

mcv 2y ago

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.

sam_lowry_ 2y ago
This is the general culture in Europe. Techies do not get promoted and do not even have a possibility to grow to management. Everything is run by humanities people and we do not even have the right words to describe this situation, although some voiced their concerns for many years, see e.g. The Two Cultures [1] from 1959. [1] https://en.wikipedia.org/wiki/The_Two_Cultures https://en.wikipedia.org/wiki/The_Two_Cultures
- lifestyleguru 2y ago
  European societies are extremely class based which is brutally visible in UK, France, Netherlands, even Germany. INSEAD and other MBAs see techies as washing machine repairmen.
  - 2y ago

vkaku 2y ago

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.

Willingham 2y ago

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.

dogleash 2y ago

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.

disambiguation 2y ago

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

calimoro78 2y ago

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

deterministic 2y ago

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

renegade-otter 2y ago

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

em-bee 2y ago
this letter/piece of code is long and convoluted because i could not spend much time on it. had i had more time it would be short and concise.

johnwatson11218 2y ago

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.

deleted 2y ago

[deleted]