7 ms·

This is a bit of glib answer. Most of the time is spent coding which encompasses typing, retyping, and retyping again. It also includes banging your head agai

This is a bit of glib answer. Most of the time is spent coding which encompasses typing, retyping, and retyping again. It also includes banging your head against the wall while trying to get one of your rewrites to work against and under-documented API. OP's formulation makes SWE sound like a purely noble enterprise like mathematics. It's more like an oil rig worker banging on pieces of metal with large hammers to get the drill string put together. They went in with a plan, but the reality didn't agree and they are on a tight schedule.

estebank 5mo ago
Most of the time is spent figuring what the right thing to do is, not writing the implementation. Sometimes the process of writing the implementation surfaces new considerations about what the right thing is, but still, producing text to feed to a compiler is not the bulk of the work of a software engineer. It is to unearth requirements and turn them into repeatable software.
- powvans 5mo ago
  Feels like lately most of the time is spent arguing about or at least worrying about whether or not AI is going to replace all software developers.
  - pydry 5mo ago
    Or dealing with the idiotic fallout of somebody who sucks at coding or even has never coded in their life trying to make that happen.
- 7e 5mo ago
  If you’re spending time thinking and not experimenting, then it’s because experimentation is expensive. With an LLM you don’t have to try to predict a complex system in advance, experiments are so cheap to can just converge to a solution directly. None of this pontificating; it’s really not that useful anymore.
  - GolfPopper 5mo ago
    And before long you have a solution that is made up of a thousand pieces of spaghetti that neither you nor anyone else understands. And when your solution becomes too brittle to use, cannot be maintained, or fails catastrophically, then what? Just hope that's someone else's problem?
    - gchamonlive 5mo ago
      Refactoring is cheap too, but you have to read your code and know when to stop and ask the agent to refactor, rewrite, adopt or change libs, fix issues presented by linters and code quality scanners, change abstractions and rethink the architecture. It's never been easier to replace chunks of code with sane software patterns, but you have to have a feel for those patterns. And also understand what's under the hood. You folks speak like the only function of the agent is to spit code and features. Get a grip and treat your deliverables with care, otherwise you only have yourself to blame, not the AI.
      - microflash 5mo ago
        Refactoring is not cheap when you take into account the cost of not breaking things.
        gchamonlive 5mo ago
        When we say "X is cheap" it's in comparison to doing things manually, not irresponsibly
    - a10c 5mo ago
      That's the point. Your prototype doesn't need to be pretty. It just needs to prove that the value is there for it to be made pretty.
      - avador 5mo ago
        Order of operations: Make it work. Make it right. Make it fast.[0] [0]: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=Make%20it%20work%2C%20make%20it%20right&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
- eweise 5mo ago
  AI is pretty good at figuring out what the right thing to do is.
  - incanus77 5mo ago
    AI is pretty good at pulling from the body of existing solutions of what the right thing to do is.
    - mkoryak 5mo ago
      I find that it often pulls a solution that is good enough for this problem today. Sometimes that is great, and other times it's just creating a pile of shit
  - CyberDildonics 5mo ago
    AI is decent at solving problems that lots of people already solved a long time ago.
    - didgetmaster 5mo ago
      Too many people believe that AI is going to come up with elegant solutions to problems that no one has ever solved before. Maybe someday, but for now it seems to be good at finding a solution that may be hidden away somewhere in stack overflow. If it just isn't there, then you are out of luck.
      - munksbeer 5mo ago
        There is almost nothing new in computer programming. 99.999% of any code most of us on this forum write will be repeating patterns that have been written thousands of times before. Tell a coding agent what your new thing needs to do, give it the absolute constraints, max response times, max failover times, and so on, tell it which technologies it has access to or could use, and then tell it to spend a lot of time going over and over the design, coming up with an initial X number of designs (I use 5), and then it must self criticise each one of them and weigh them up, narrow down to three, before finally presenting those three options to the user. Now you read the options, understand them, realise that the AI has either converged on something very sensible, or it has missed something, so you tell it what it missed and iterate. Or it nailed something good, you pick the option you prefer, and tell it to come up with a more fleshed out high level design, describing the flow and behaviour deeply (NO CODE REFERENCES!). Then once you're happy, tell it to use that and write a comprehensive coding plan. Tell it specifically what coding patterns you prefer (you should have these in your AGENTS.md file already), what patterns to avoid (single threaded? multi-threaded? Avoid gc? How you typically deal with error conditions, etc etc). Then have it start iteratively working on the coding plan, and it *MUST* have a strong feedback loop. If there is no feedback loop initially, I tell it to build one. It must be able to write very fluent integration tests (not just unit tests). It must be able to run the app and read the logs. Do all this and I bet you get a better result that 80% of developers out there. Coding agents are extremely good when used well.
deleted 5mo ago
[deleted]
bborud 5mo ago
Are you, perchance, assuming that since you spend most of your time struggling with actual code, this is so for everyone else? Or are you saying that I'm lying. That I am secretly hammering away at my keyboard while pretending not to? No, writing code hasn't been how I spend most of my time for many decades now.
- therealdrag0 5mo ago
  Are you a staff level engineer that has dozens of other engineers banging away at code projects you help define?
  - eska 5mo ago
    Try to write a design doc before you implement something (which people find they need to do for LLMs to work at all anyway). You’ll find that you spend much less time actually writing code. Write proper API documentation laying out the assumptions and intent, generate some good API docs, write a design and architecture document (which people find they need for LLMs to work at all anyway). You’ll find that you spend a lot less time reading code.
    - dkersten 5mo ago
      > which people find they need to do for LLMs to work at all anyway Everything we have to do for AI to function well, would help humans to function better too. If you take the things for AI, but do them for humans instead, that human will easily 2x or more, and someone will actually understand the code that gets written.
      - overfeed 5mo ago
        > If you take the things for AI, but do then for humans instead, that human will easily 2x or more, and someone will actually understand the code that gets written This only works on high-trust teams and organizations. A lot of AI productivity gains are from SWE putting the extra effort because the results will be attributed to them. Being a force-multiplier for others isn't always recognized, instead, your perfomance will likely judged solely on the metrics directly attributed to you. I learned this lesson the hard way by being idealistic, and overestimating the level of trust that had been built after joining a new team. Companies pay lip service to software quality, no one gives a shit if your code has the lowest SEV rates.
ecocentrik 5mo ago
Glib is called for. The amount of information asymmetry that's still on the table as vibe coders and vibe engineers and vibe doctors emerge is staggering. Professional experience is still incredibly valuable. Most software developers might spend more than 6% of their time coding but no senior developers are banging their heads for hours over typos. https://www.youtube.com/shorts/xBilK3gT5e0 https://www.youtube.com/shorts/xBilK3gT5e0
- pear01 5mo ago
  This is temporary. What is the SKILL.md equivalent going to be in five years? In ten? You don't already see a pattern emerging around solutions to encode that "professional experience" into the tools themselves? These LLMs can already incorporate our entire cultural corpus yet your "professional experience" is the threshold they won't cross?
  - ecocentrik 5mo ago
    The capacity of the person prompting it to understand is the threshold they won't cross. They can squeeze the gap as much as possible by dumbing down answers or slowly ramping up information complexity but there is a limit to comprehension.
    - pear01 5mo ago
      This is an interesting answer for questions about human agency and accountability/personhood questions but I don't see how it leads to increased confidence in the role of human as SWE. If LLMs get good enough, one might be tempted to ask so what if most humans can't understand the output? Human civilization has by and large been a constant exercise in us collectively accomplishing more and more while individually comprehending less and less. Our ancestors likely understood more about hunting live game or murdering each other than we do. Most of us do not consider that a great loss. Most of us living in the modern world depend on things we don't fully comprehend. I'm just not sure how this would lead to being reassured re the human as SWE.
logicchains 5mo ago
>OP's formulation makes SWE sound like a purely noble enterprise like mathematics. It's more like an oil rig worker banging on pieces of metal with large hammers to get the drill string put together. Those two formulations represent different developers' approaches to the same task. The former being developers who are much better at planning than the latter.
pear01 5mo ago
Let's also not forget a lot of the market edge of SWEs comes in knowing how to navigate these parts. The fact you needed to be reasonably fluent in a language was already a barrier to entry which meant in better times new grads could earn six figures at their first job just for putting in that effort. Maybe you will still be needed. That is one question. How well you will be paid and treated when the barrier to entry is now "I can think" is another. As the parent indicates, most people doing software are not doing things akin to pure math. I don't think most SWEs want that lifestyle anyway. It's ok. You shouldn't fight the coming change. Instead use the time we still have to fight for more equal outcomes (vote for politicians that support UBI, Medicare for all). The longer you delude yourself that you are uniquely needed in an increasingly mechanized world the worse all our outcomes will be.
- arandomhuman 5mo ago
  The barrier to entry to generating code may be "I can think", but the barrier to entry for solving hard, distributed/multi-faceted engineering problems still remains quite high - agents can't really do this still to a decent level of efficacy reliably. The progress models have made in the last 5 years aren't convincing me they'll bridge that gap too soon, although I can see how some people are convinced by how decent agentic harnesses make things. I know it's really easy to get very hyped with the current state of the technology, but try to have a bit of skepticism.
sleight42 5mo ago
This is far more true for junior and perhaps mid-career engineers, unless you're working in an extremely well-defined problem space (* see below). When working as a SWE, the longer I did it (~30 years) more of my time was spent understanding the problem, the edge cases, how to handle the edge cases, how to do all of it affordable, on time, and within budget. That's engineering. What you're describing is "writing code". That's lower value than "solving the problem". I imagine a response, "But agile development, etc." Yep. Part of solving the often sometimes involves creating prototypes to determine the essential viability of the solution. But that's only part of it. Which prototypes do you write? How much time do you allocate to same before accepting it's a dead end (at least for now) and punting on it? That's engineering. Me probably coming across as a dick today? Well, I was diagnosed autistic a year ago, and I'm on extended sabbatical/unemployment (3 years now) due to autistic burnout. And masking is part of how I got the burnout.** * Why would someone be paying for that when there is likely someone else already doing it? Unless you're the rare person who hopes to "disrupt" the competition). ** has me begging the question of why I write here at all. SMH. Why do I do what I do? No idea sometimes.
- cduzz 5mo ago
  I'm going to mix my metaphors a bit here... There's the saying "Any idiot can build a bridge; it takes an engineer to build a bridge that barely stands." To put this another way, any idiotic LLM can write code. It takes a person with domain experience to understand what code to write, rewrite, or not write. I've seen lots of organizations hollow out their internal competence in favor of outsourcing the skills. LLMs are the ultimate expression of that. There are people who say "you need to have people in your organization who understand how things work because they're the ones who solve problems!" and there are other people who say "focus on your core competencies! These problems you're worried about aren't your core competencies, so get rid of those experts, they're expensive and annoying; we can just sign a contract with an organization that'll know things for us." At some point we all will identify exactly how much "seed corn" you need for the next season. We'll figure that out because we're starving, but at least we'll all know.
- dijksterhuis 5mo ago
  you've definitely been doing this longer than i have, but our outlook and recent experiences sound very similar. also been diagnosed recently, also on similar extended sabbatical/unemployment, also come across as a dick, also trying to mask less because burn out. got an email address in my profile if you'd be interested in talking at some point about something, or even talking about nothing in particular. (i don't normally do this sort of HN networking stuff, i find it super cringe. but there we go).
01100011 5mo ago
Your answer reminds me that my biggest gripe with this site and programmer forums in general is the lack of awareness of the breadth and scale of software development. I'm curious what you work on, because it doesn't sound anything like what I work on. > Most of the time is spent coding which encompasses typing, retyping, and retyping again. It also includes banging your head against the wall while trying to get one of your rewrites to work against and under-documented API. I don't think I've experienced this to a large degree. Maybe early in my career. Most of my time now is spent formulating a solution, and time spent coding is mostly spent trying to compose my changes with the existing code in a way that is performant, reliable and meets the specifications.
RajT88 5mo ago
> under-documented API One wonders why AI hasn't replaced all those non-existent documentation writers yet. Therein lies a clue to what the future holds.
AussieWog93 5mo ago
This was my experience as a junior back in 2019. The actual problem solving was trivial but I would spend days trying to work my way around some Qt work or guess the magic Cmake incantation.
Sh0000reZ 5mo ago
[flagged]

estebank 5mo ago

Most of the time is spent figuring what the right thing to do is, not writing the implementation. Sometimes the process of writing the implementation surfaces new considerations about what the right thing is, but still, producing text to feed to a compiler is not the bulk of the work of a software engineer. It is to unearth requirements and turn them into repeatable software.

powvans 5mo ago
Feels like lately most of the time is spent arguing about or at least worrying about whether or not AI is going to replace all software developers.
- pydry 5mo ago
  Or dealing with the idiotic fallout of somebody who sucks at coding or even has never coded in their life trying to make that happen.
7e 5mo ago
If you’re spending time thinking and not experimenting, then it’s because experimentation is expensive. With an LLM you don’t have to try to predict a complex system in advance, experiments are so cheap to can just converge to a solution directly. None of this pontificating; it’s really not that useful anymore.
- GolfPopper 5mo ago
  And before long you have a solution that is made up of a thousand pieces of spaghetti that neither you nor anyone else understands. And when your solution becomes too brittle to use, cannot be maintained, or fails catastrophically, then what? Just hope that's someone else's problem?
  - gchamonlive 5mo ago
    Refactoring is cheap too, but you have to read your code and know when to stop and ask the agent to refactor, rewrite, adopt or change libs, fix issues presented by linters and code quality scanners, change abstractions and rethink the architecture. It's never been easier to replace chunks of code with sane software patterns, but you have to have a feel for those patterns. And also understand what's under the hood. You folks speak like the only function of the agent is to spit code and features. Get a grip and treat your deliverables with care, otherwise you only have yourself to blame, not the AI.
    - microflash 5mo ago
      Refactoring is not cheap when you take into account the cost of not breaking things.
      - gchamonlive 5mo ago
        When we say "X is cheap" it's in comparison to doing things manually, not irresponsibly
  - a10c 5mo ago
    That's the point. Your prototype doesn't need to be pretty. It just needs to prove that the value is there for it to be made pretty.
    - avador 5mo ago
      Order of operations: Make it work. Make it right. Make it fast.[0] [0]: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=Make%20it%20work%2C%20make%20it%20right&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
eweise 5mo ago
AI is pretty good at figuring out what the right thing to do is.
- incanus77 5mo ago
  AI is pretty good at pulling from the body of existing solutions of what the right thing to do is.
  - mkoryak 5mo ago
    I find that it often pulls a solution that is good enough for this problem today. Sometimes that is great, and other times it's just creating a pile of shit
- CyberDildonics 5mo ago
  AI is decent at solving problems that lots of people already solved a long time ago.
  - didgetmaster 5mo ago
    Too many people believe that AI is going to come up with elegant solutions to problems that no one has ever solved before. Maybe someday, but for now it seems to be good at finding a solution that may be hidden away somewhere in stack overflow. If it just isn't there, then you are out of luck.
    - munksbeer 5mo ago
      There is almost nothing new in computer programming. 99.999% of any code most of us on this forum write will be repeating patterns that have been written thousands of times before. Tell a coding agent what your new thing needs to do, give it the absolute constraints, max response times, max failover times, and so on, tell it which technologies it has access to or could use, and then tell it to spend a lot of time going over and over the design, coming up with an initial X number of designs (I use 5), and then it must self criticise each one of them and weigh them up, narrow down to three, before finally presenting those three options to the user. Now you read the options, understand them, realise that the AI has either converged on something very sensible, or it has missed something, so you tell it what it missed and iterate. Or it nailed something good, you pick the option you prefer, and tell it to come up with a more fleshed out high level design, describing the flow and behaviour deeply (NO CODE REFERENCES!). Then once you're happy, tell it to use that and write a comprehensive coding plan. Tell it specifically what coding patterns you prefer (you should have these in your AGENTS.md file already), what patterns to avoid (single threaded? multi-threaded? Avoid gc? How you typically deal with error conditions, etc etc). Then have it start iteratively working on the coding plan, and it *MUST* have a strong feedback loop. If there is no feedback loop initially, I tell it to build one. It must be able to write very fluent integration tests (not just unit tests). It must be able to run the app and read the logs. Do all this and I bet you get a better result that 80% of developers out there. Coding agents are extremely good when used well.

deleted 5mo ago

[deleted]

bborud 5mo ago

Are you, perchance, assuming that since you spend most of your time struggling with actual code, this is so for everyone else? Or are you saying that I'm lying. That I am secretly hammering away at my keyboard while pretending not to? No, writing code hasn't been how I spend most of my time for many decades now.

therealdrag0 5mo ago
Are you a staff level engineer that has dozens of other engineers banging away at code projects you help define?
- eska 5mo ago
  Try to write a design doc before you implement something (which people find they need to do for LLMs to work at all anyway). You’ll find that you spend much less time actually writing code. Write proper API documentation laying out the assumptions and intent, generate some good API docs, write a design and architecture document (which people find they need for LLMs to work at all anyway). You’ll find that you spend a lot less time reading code.
  - dkersten 5mo ago
    > which people find they need to do for LLMs to work at all anyway Everything we have to do for AI to function well, would help humans to function better too. If you take the things for AI, but do them for humans instead, that human will easily 2x or more, and someone will actually understand the code that gets written.
    - overfeed 5mo ago
      > If you take the things for AI, but do then for humans instead, that human will easily 2x or more, and someone will actually understand the code that gets written This only works on high-trust teams and organizations. A lot of AI productivity gains are from SWE putting the extra effort because the results will be attributed to them. Being a force-multiplier for others isn't always recognized, instead, your perfomance will likely judged solely on the metrics directly attributed to you. I learned this lesson the hard way by being idealistic, and overestimating the level of trust that had been built after joining a new team. Companies pay lip service to software quality, no one gives a shit if your code has the lowest SEV rates.

ecocentrik 5mo ago

Glib is called for. The amount of information asymmetry that's still on the table as vibe coders and vibe engineers and vibe doctors emerge is staggering. Professional experience is still incredibly valuable. Most software developers might spend more than 6% of their time coding but no senior developers are banging their heads for hours over typos. https://www.youtube.com/shorts/xBilK3gT5e0 https://www.youtube.com/shorts/xBilK3gT5e0

pear01 5mo ago
This is temporary. What is the SKILL.md equivalent going to be in five years? In ten? You don't already see a pattern emerging around solutions to encode that "professional experience" into the tools themselves? These LLMs can already incorporate our entire cultural corpus yet your "professional experience" is the threshold they won't cross?
- ecocentrik 5mo ago
  The capacity of the person prompting it to understand is the threshold they won't cross. They can squeeze the gap as much as possible by dumbing down answers or slowly ramping up information complexity but there is a limit to comprehension.
  - pear01 5mo ago
    This is an interesting answer for questions about human agency and accountability/personhood questions but I don't see how it leads to increased confidence in the role of human as SWE. If LLMs get good enough, one might be tempted to ask so what if most humans can't understand the output? Human civilization has by and large been a constant exercise in us collectively accomplishing more and more while individually comprehending less and less. Our ancestors likely understood more about hunting live game or murdering each other than we do. Most of us do not consider that a great loss. Most of us living in the modern world depend on things we don't fully comprehend. I'm just not sure how this would lead to being reassured re the human as SWE.

logicchains 5mo ago

>OP's formulation makes SWE sound like a purely noble enterprise like mathematics. It's more like an oil rig worker banging on pieces of metal with large hammers to get the drill string put together. Those two formulations represent different developers' approaches to the same task. The former being developers who are much better at planning than the latter.

pear01 5mo ago

Let's also not forget a lot of the market edge of SWEs comes in knowing how to navigate these parts. The fact you needed to be reasonably fluent in a language was already a barrier to entry which meant in better times new grads could earn six figures at their first job just for putting in that effort. Maybe you will still be needed. That is one question. How well you will be paid and treated when the barrier to entry is now "I can think" is another. As the parent indicates, most people doing software are not doing things akin to pure math. I don't think most SWEs want that lifestyle anyway. It's ok. You shouldn't fight the coming change. Instead use the time we still have to fight for more equal outcomes (vote for politicians that support UBI, Medicare for all). The longer you delude yourself that you are uniquely needed in an increasingly mechanized world the worse all our outcomes will be.

arandomhuman 5mo ago
The barrier to entry to generating code may be "I can think", but the barrier to entry for solving hard, distributed/multi-faceted engineering problems still remains quite high - agents can't really do this still to a decent level of efficacy reliably. The progress models have made in the last 5 years aren't convincing me they'll bridge that gap too soon, although I can see how some people are convinced by how decent agentic harnesses make things. I know it's really easy to get very hyped with the current state of the technology, but try to have a bit of skepticism.

sleight42 5mo ago

This is far more true for junior and perhaps mid-career engineers, unless you're working in an extremely well-defined problem space (* see below). When working as a SWE, the longer I did it (~30 years) more of my time was spent understanding the problem, the edge cases, how to handle the edge cases, how to do all of it affordable, on time, and within budget. That's engineering. What you're describing is "writing code". That's lower value than "solving the problem". I imagine a response, "But agile development, etc." Yep. Part of solving the often sometimes involves creating prototypes to determine the essential viability of the solution. But that's only part of it. Which prototypes do you write? How much time do you allocate to same before accepting it's a dead end (at least for now) and punting on it? That's engineering. Me probably coming across as a dick today? Well, I was diagnosed autistic a year ago, and I'm on extended sabbatical/unemployment (3 years now) due to autistic burnout. And masking is part of how I got the burnout.** * Why would someone be paying for that when there is likely someone else already doing it? Unless you're the rare person who hopes to "disrupt" the competition). ** has me begging the question of why I write here at all. SMH. Why do I do what I do? No idea sometimes.

cduzz 5mo ago
I'm going to mix my metaphors a bit here... There's the saying "Any idiot can build a bridge; it takes an engineer to build a bridge that barely stands." To put this another way, any idiotic LLM can write code. It takes a person with domain experience to understand what code to write, rewrite, or not write. I've seen lots of organizations hollow out their internal competence in favor of outsourcing the skills. LLMs are the ultimate expression of that. There are people who say "you need to have people in your organization who understand how things work because they're the ones who solve problems!" and there are other people who say "focus on your core competencies! These problems you're worried about aren't your core competencies, so get rid of those experts, they're expensive and annoying; we can just sign a contract with an organization that'll know things for us." At some point we all will identify exactly how much "seed corn" you need for the next season. We'll figure that out because we're starving, but at least we'll all know.
dijksterhuis 5mo ago
you've definitely been doing this longer than i have, but our outlook and recent experiences sound very similar. also been diagnosed recently, also on similar extended sabbatical/unemployment, also come across as a dick, also trying to mask less because burn out. got an email address in my profile if you'd be interested in talking at some point about something, or even talking about nothing in particular. (i don't normally do this sort of HN networking stuff, i find it super cringe. but there we go).

01100011 5mo ago

Your answer reminds me that my biggest gripe with this site and programmer forums in general is the lack of awareness of the breadth and scale of software development. I'm curious what you work on, because it doesn't sound anything like what I work on. > Most of the time is spent coding which encompasses typing, retyping, and retyping again. It also includes banging your head against the wall while trying to get one of your rewrites to work against and under-documented API. I don't think I've experienced this to a large degree. Maybe early in my career. Most of my time now is spent formulating a solution, and time spent coding is mostly spent trying to compose my changes with the existing code in a way that is performant, reliable and meets the specifications.

RajT88 5mo ago

> under-documented API One wonders why AI hasn't replaced all those non-existent documentation writers yet. Therein lies a clue to what the future holds.

AussieWog93 5mo ago

This was my experience as a junior back in 2019. The actual problem solving was trivial but I would spend days trying to work my way around some Qt work or guess the magic Cmake incantation.

Sh0000reZ 5mo ago

[flagged]