3 ms·

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

• 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.
        • dkersten 5mo ago
          Ah… that’s a reasonable point. Yes, the difference between a high-trust team and what you described is night and day. I suppose for those situations there’s a much bigger incentive to just throw AI at it, which explains why the big corporates love AI.
  • bborud 5mo ago
    It has varied over the years but it isn't actually relevant since I am talking about when I write software. Writing code just isn't what takes time.
    • QuercusMax 5mo ago
      Getting the code into a state where it actually does what you want takes time - but a lot of that is research, testing, experimentation, documentation, etc. Those can be faster with AI assistance but you still need to bang on it enough to make sure it works right.
  • kakacik 5mo ago
    I am not, yet actual coding is miniscule part of workflow. The rest is cca un-automable by any llm - politics, meetings, discussions, brainstorming, organizing testing teams, stakeholders and so on. This is how big corporations look like, not some SV startups.
    • munksbeer 5mo ago
      I agree. And that stuff is soul destroying. I have done it, and right now I work in a place a little smaller, but we get so much done without all the cruft. And we get it done better. I spend much more time writing code now (*) than at the big corps, and we do a much better job because we can iterate. (*) Well, now claude spends a lot of time writing code, I spend a lot of time designing and steering it. Claude can write remarkably sophisticated code with the correct steering.*
  • prmph 5mo ago
    No, no actually capable engineer should be just banging away at code. This is one way to know the level of an engineer. Less capable engineers think in terms of implementing runtime execution and solving runtime errors. More capable engineers think in terms of designing the most effective architecture and abstractions for maintainability, performance, and robustness. I have a project I am working on, It has not compiled in months, but that's ok, since the real work, for me, is in the architectural design. Yes, getting it to actually run takes some time and effort, but for me that is almost mechanical now.