I think a lot of people are generalizing the comment to people in all positions. I've befriended many people I worked with over the years, but I was not the one paying them, giving or denying them opportunities. I also really loved what I did, but I was not the one making sure it had exchange value on the market. Friendship, "passion", etc are really luxuries the OP wanted in this position, but really could not afford in large quantities.

Burnout for me is caused by too much bureaucracy, too many meetings, and incompatible programming philosophies. Only twice in my long career have I left a job due to an insufferable coworker.

This really hits home for me. I'm at my most miserable when working with people who value doing things fast more than doing them well. I suspect those people are also at their most miserable when working with me. I see them as creating work that I'll have to do eventually to clean up their mess, and I suspect they see me as an insufferable gatekeeper.

Or do you dislike cleaning it up? In this case, why do you do it? Noblesse Oblige?

Asking because I love refactoring. I also love pushing features fast. But I absolutely dread having to do "perfect code" in the first try. I keep trying to push this idea (inspired by Mythical-Man-Month) here in HN that a perfect team would have people "working fast and breaking things" with people working behind them that love refactoring everything cleaning it up.

Of course not. I may enjoy cleaning up my own messes, but not one that someone else has foisted upon me. The problem with teams like this is that the fast-movers are long gone by the time the impact of their expediency is being felt. They benefit from the accolades of a launch while shirking the responsibility of operating a product.

> In this case, why do you do it?

Because the product sucks and needs to be improved, but it is an unimprovable mess because everything was done expediently instead of well, some of which needs to be fixed in order to move forward. A lot of the hard work at this point is in figuring out the best pragmatic balance of what to fix vs. what to leave alone. A little forethought could have saved a lot of post-facto toil.

I do like iteration, doing things in small iterative chunks. But that is not the same as putting out a huge mess and hoping someone comes along who enjoys cleaning it up.

Yes, :100: :100:

I have seen this happen so many times. It's a vicious cycle of horribleness. The same people always seem to get the new development also because they were "so successful with the last launch" and the people maintaining it are perceived as slow and ineffectual because it takes so long to iterate (ironically because of the person who looks like a rock star).

I feel very lucky in my career that I don't have to put up with this anymore. If I could go back in time I would just tell myself to quit and find a more compatible company instead of suffering for years under a self-destructive system that punishes people like me. Since breaking free from that and starting my own projects, I've been very successful.

I don't mean to imply that I always write perfect code, or even great code, because surely I don't. I do expect some things to be throwaway that end up staying around. But doing something correct rather than fast in general is a much better long term strategy. Vary as necessary (but only when necessary).

I HATE cleaning up people's messy code. It's 10x easier to do it right the first time. Messy code to me is most messy because it's unclear what is being done. It often comes with insufficient tests, which makes refactoring dangerous.

To me it's a lot like walking into a messy house vs. a clean house. If the house has clutter everywhere, or has a smell from being dirty, then it's not comfortable to be in. If I have to work in it, or clean it, I'd much rather start with a well-organized clean house.

Refactoring is also not fun at all for me. I also LOVE pushing features fast. I don't obsess over "perfect code" but I do obsess over following best practices and stopping for a few minutes to think through a design.

My workflow is:

1. Get it working, minimal effort, PoC

2. Get tests written and passing.

3. Refactor to good code. Perfect is the enemy of good, but it doesn't get committed until it's readable, maintainable, tested, documented.

Sometimes I probably am a little slower than I otherwise could be, but people are often blown away at my ability to iterate and add features quickly. This is because my code is well organized, modular, DRY, and well tested. It takes a little longer the first release, but it more than pays for itself speed-wise as tech debt stays minimum and hackability is high. With over 10 years experience now with this method I'm convinced that it's the only sane way to do things. Anything else is sabotaging your own future.

If I really don't have time to do it right the first time, I know it will be hard to iterate on, it will have bugs in prod, and it will never be pleasant to work in. It takes 10x longer to refactor an existing app to be good code than it does to do it during development when it's all fresh in mind. The best hope is that it has a good spec so it can be re-written from scratch.

I’ve got friends from every job I’ve had in the last 20 years who I still see routinely including some of my best friends.

Overlapping jobs like that indicates you are following a very different career structure than most people, so I’d hesitate to generalise your experience.

So many of my friends and neighbors came here voluntarily- They seem happy, but deep down they must be filled with so much remorse!