The 80% Problem: The Last 20% Is Where the Engineer Used to Live(www.jonathanbeard.io)
22 pointsby speckx3 hours ago5 comments
  • raychis2 hours ago
    This is a good thesis but it does lean a bit too hard on a vague 80/20 metaphor. It kind of romanticises old-school engineering struggles while downplaying how much of past learning was just wrestling with crappy tooling or poor docs. Things are much better now, I wouldn't want to go back. The stronger argument would not just be the old way is better, but that we need a way to preserve judgment that used to be developed through the struggle.
    • jayctan hour ago
      > we need a way to preserve judgment that used to be developed through the struggle.

      it's true. once you've gone "deep" for a few years in at least one technical domain, that depth transfers pretty well to the next big new thing you didn't know you'd have to learn when you started. i think the fear about the new regime is that people will be denied the opportunity to obtain depth in anything. like we'll encounter the human equivalent of domestication syndrome.

      i remember when certain loud individuals believed that {managed memory | IDE auto-complete | statistical db optimizers | programming languages higher than assembly level | ...} were going to make everyone stupid. but the higher-order systems have continued to present rich problems to engage the mind and spark creativity. this era feels different though, the worry more pressing.

    • felix-the-cat2 hours ago
      Right, I find that AI tools combined with solid domain knowledge are incredibly effective. Yeah, if you try to one-shot a complex distributed system you'll end up with a mess, but the same thing would happen if you tried to do it yourself in the space of a day - you're still reasoning and applying experience, it's just you have an automated tool to take care of generating the source code.
      • raychis43 minutes ago
        Yeah, I 100% agree with you. I was very reluctant to pick up AI tools for coding for a long time. But now I have, I've gone from thinking the code was the most important bit to realising the thinking behind the code is the actual real important bit. I am not sure AI tools will ever be able to replace that element.
  • chilipepperhott2 hours ago
    Ironically, this post reeks of Claude.

    > Generative AI hasn’t repealed this rule. It’s relocated it

    • layer82 hours ago
      I was hoping that the author would live in the last 20%, but Pangram says that the article is 100% AI-generated.
    • zabriel_goss2 hours ago
      Generated? Or are we all reading so much generated material in our workflows that it's seeping into our authentic dialogue
      • OJFord2 hours ago
        This is an insightful comment that cuts to the heart of the matter — human agents, like their machine counterparts, are prone to repeat phrasing they've come across before.
        • throw-the-towel2 hours ago
          Man, do I hope the AI-esque phrasing of this comment is just irony.
          • yulkeran hour ago
            You're right to push on that, and the suspicion is real. That type of sensitivity is load bearing, not exaggerated anxiety.
          • OJFordan hour ago
            You're absolutely right!
      • bbg24012 hours ago
        The writing is dissimilar to the authors prior work, and the website is AI bilge. It’s a safe assumption that it’s AI generated
    • mattasan hour ago
      One thing that I've noticed is that there is so much content slopped out by AI that I sometimes write in that style unintentionally.
  • felix-the-cat2 hours ago
    "They cluster around exactly the parts of engineering that take sustained operational experience, the idempotency key that keeps two racing requests from corrupting state, the backoff and jitter that keep a retry from turning into a stampede, the migration written to dodge a long table lock, the rate limiter, the circuit breaker, the structured log that makes the eventual failure diagnosable at 3am."

    But these are things that the AI actually knows how to do just about as well as regular developer would. I run into these problems all the time working on a trading platform and AI is quite good at solving these issues and discussing them if you have questions or providing a collection of strategies you can choose from.

  • senderista2 hours ago
    Slop about slop.
    • yulkeran hour ago
      makes you wonder how much of the token economy is just this sort of circular slop triggered by slop
      • senderista40 minutes ago
        Most of the anti-AI articles I see appear to be AI-written.
  • sublinear2 hours ago
    The answer is simple. Stop working for "big tech" and SV startups. They're the only ones leaning into AI this hard.

    Find a role maintaining services instead of scrambling to build shiny new products, and you'll have what you want.

    There is plenty to do. The last decade of "move fast and break things" broke a lot of things. The work is challenging and rewarding. You're not cleaning up slop. You're not being given so much rope to hang yourself. You will work with people that have been there for decades. They are not all backwards thinking corporate Java devs.