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.

▲

lateforwork 5 days ago | parent | next [-]

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

▲

stouset 5 days ago | parent [-]

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.

▲

lateforwork 5 days ago | parent [-]

> The person who signals that some task works and is finished is you.

That's not how it works in most big companies. You can't take arbitrarily long to finish a project. Before the project is greenlit you have to give an estimate for how long the project will take. If your estimate is too big or seems unreasonable the project dies then and there (or given to someone else). Once the project starts you're held to the estimate, and if you're taking noticeably longer than your estimate you better have a good explanation.

	▲	stouset 5 days ago \| parent [-]
		Nobody is saying take three years to complete a week-long task. If you could do a task in one hour, estimate and take two. If you could do it in two days, estimate and take a third day to complete it. Or better yet, estimate three days and take two and a half. I have never seen a software development shop where estimates were treated as anything other than loose, best guesses. Very infrequently are there actually ever genuinely immutable, hard deadlines. If you are working somewhere where that's repeatedly the case—and those deadlines are regularly unrealistically tight—failure is virtually inevitable no matter what you do. So sure, fine, if you're on a death march my suggestions won't work. But in that kind of environment nothing will.

▲

steve_adams_86 5 days ago | parent | prev | next [-]

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

▲

stouset 5 days ago | parent [-]

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.

▲

steve_adams_86 5 days ago | parent | next [-]

> There is always a way to leave things better than how you found them.

I agree, and that's something I do even if I get push back. I think it's essential in all aspects of life, or things typically get worse. People have to care.

My point is more so that it often—in my experience, at least—is met with friction because a lot of people see this kind of housekeeping as bad for bottom lines, or in the weeds, as a distraction, or what have you. I've encountered friction and push back more than acceptance let alone appreciation, I think.

A very common (and sometimes fair) form of push back is along the lines of "let's keep this ticket ONLY to the bug fix/feature/whatever and avoid any unnecessary changes". This is generally good practice, but I'll personally allow unrelated changes if they're relatively simple chores to leave things better than they were found.

If I were to summarize my experience, it's that caring to make things better or as good as they should be typically requires my own time and energy outside of regular work hours. That's a hard sell, especially after 20 years or so. I still do my best to make things better and I've come to expect and meet that friction with the necessary energy to overcome it, but... I mean, it's not always easy or necessarily rewarding. Many of my jobs could have often been dramatically easier if I cared less, but I'm not sure anyone would have even minded that.

▲

gatlin 5 days ago | parent | prev [-]

That's really great and I'm happy for you but your experience is not universal.

	▲	stouset 5 days ago \| parent [-]
		My point isn’t that my experience is universal, but that I find it statistically unlikely that this is nearly as hard as people are making it out to be at the majority of SWE roles. If you find yourself repeatedly working at places where the only option is to crank out garbage at breakneck pace, I don’t know what to tell you. If you stipulate as an axiom that it's impossible to write quality software at ${JOB}, then you're right, by definition there's nothing to be done. I just don't find that a particularly helpful mindset.

▲

fogzen 5 days ago | parent | prev | next [-]

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

▲

Ferret7446 5 days ago | parent | prev [-]

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)

▲

taberiand 5 days ago | parent | next [-]

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

▲

AlotOfReading 5 days ago | parent [-]

Have you looked at a Juicero teardown [0]? It's overengineered to the point where it's a genuinely astonishing bit of engineering art. It's also an incredibly stupid product. Those things are completely compatible.

[0] https://blog.bolt.io/juicero/

▲

monocasa 5 days ago | parent | next [-]

Idk, it looks like most of what this person is complaining is that they don't see a lot of this in high volume consumer products. But like, most high volume comsumer products don't have to crank nearly the same amount of torque either.

It's a silly product, but as far as being over engineered, it looks like it's about what I'd expect for those requirements.

	▲	michaelt 5 days ago \| parent \| next [-]
		Have you ever changed a tyre on a car? If so, you may have noticed the jack you used didn't have several huge CNC machined aluminium parts, a seven-stage all-metal geartrain, or a 330v power supply and it probably didn't cost you $700. Probably it cost more like $40. And sure, a consumer kitchen product needs to look presentable and you don't want trapping points for curious little fingers. But even given that, you could deliver a product that worked just as well for just as long at a far lower BOM cost.
	▲	AlotOfReading 5 days ago \| parent \| prev [-]
		Something is overengineered for the actual problem even if it's necessary to meet the requirements, if the requirements are themselves unnecessary. Imagine speccing a 100m span to cross a small stream. The resulting bridge can reasonably be called overengineered. You can achieve the same goal (getting juice from diced fruit without cleanup) much easier with different requirements. The post mentions that.

▲

joshvm 5 days ago | parent | prev [-]

AvE’s Juicero teardown is also a classic:

https://youtu.be/_Cp-BGQfpHQ?si=V-LLVn1cQmrMsiDZ

▲

stouset 5 days ago | parent | prev [-]

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