> Yikes, I think this is how teams end up with "we should just rewrite this whole thing because the guy who wrote it liked doing things his own nonstandard way

> Yikes, I think this is how teams end up with "we should just rewrite this whole thing because the guy who wrote it liked doing things his own nonstandard way and nobody else can understand it once he left". I’d be willing to bet there’s more to the story in nearly every case. The non-standard way is often a deliberate choice to attempt to optimize for output, given unpredictable and unrealistic deadlines. Then it proves futile when, for instance, the goalposts are moved again, and the last 25% of the implementation has to get rushed through. That’s when it turns into a pile of shit, and that’s when the person decides to leave. But not because of the deadline, but because of the incessant complaining, doubting, and negativity toward this developer, who got praise elsewhere for actually innovating. That’s why you hired him after all. Nobody else apparently stepped up to help deal with the situation before it became a problem, hence the victimization. Companies like that are going to have a culture of finger-pointing and blame-throwing. Never taking responsibility for a situation they created. Problem-solvers need not apply. This is how industries, not teams, fail. Good programmers know when to quit the rat race. Or they know how to choose companies that follow the golden rule. Take care of your people and they will take care of you. But if someone is actually doing it to “flex”, they’re clearly not that experienced, in which case it’s also the company’s fault for giving them that much technical authority.