← Back to context

Comment by piker

1 month ago

Always makes me a bit envious as well as awestruck. What a joy it must be in a lot of ways to be able to grind and perfect a piece of software like this. Truly a work of craftsmanship.

You can literally just do this. I’ve never gotten fired from a software engineering job for moving slower and building things that work well, work predictably, and are built to last.

Over a career of working at it, you get dramatically better at higher levels of quality even in earlier passes, so the same level of added effort provides increasing levels of reward as you gain experience.

Nobody ever complains about the person who’s leaving everything they touch a little cleaner than how they found it.

  • > I’ve never gotten fired from a software engineering job for moving slower and building things that work well, work predictably, and are built to last.

    In most companies, that’s not how it plays out. Once something works, you’re immediately moved on to the next task. If you’ve had the time and space to refine, polish, and carefully craft your code, you’ve been fortunate.

    • The person who signals that some task works and is finished is you. You have way more control over this than you are giving yourself credit for.

      If you spend your career acquiescing to every request to “just ship it” then, yes, slowing down a second to do a quality pass will seem impossible. But you really can just do it.

      2 replies →

  • > Nobody ever complains about the person who’s leaving everything they touch a little cleaner than how they found it.

    This should be true, but it's not in my experience. Even small, clear improvements are rejected as off-mission or shunted to a backlog to be forgotten. Like, "cool, but let's hold off on merging this until we can be certain it's safe", or in other words "this is more work for me and I'd really rather not".

    • Do it as part of ticket work you're already doing. There is always a way to leave things better than how you found them.

      I have worked across a wide gamut of roles (full-stack eng, infosec, deploy infra, devops, infra eng, sysadmin), companies (big and small, startups and huge multibillion-dollar players), and industries (finance, datacenters, security products, gaming, logistics, manufacturing, AI) over a thirty year career and I have never felt the level of helplessness that people seem to be claiming. Some places have been easier, some have been harder, but I have never once found it to be as difficult or impossible as everyone laments is the case.

      3 replies →

  • Same. But it took learning to ignore everything every manager was telling me: Go faster, ship before I'm ready to ship, proceed without agreed-on and documented requirements, listen to product instead of customers, follow code conventions set by others...

  • You can definitely go overboard for work. If you want to do it as a hobby, go nuts, but there isn't a point in overengineering far beyond what is needed (recall the Juicero)

    • Overengineering is building a bridge that will stand 1000 years when 100 will do; it's excess rigor for marginal benefit. Juicero wasn't overengineering, it was building a crappy bridge to nowhere with a bunch of gaudy bells and whistles to try and hide its uselessness and poor design, that collapsed with the first people to walk over it

      5 replies →

    • The pendulum has swung so far in the direction opposite of going overboard it’s almost laughable. Everyone retells the same twenty year old horror stories of architecture astronauts, but over a nearly thirty-year career I have seen precisely zero projects that failed due to engineers over-engineering, over-architecting, and over-refactoring.

      I have however seen dozens of projects where productivity grinds to a halt due to the ever-increasing effort of even minor changes due to a culture of repeatedly shipping the first thing that vaguely seems to work.

      The entire zeitgeist of software development these days is “move fast and break things”.