Like most engineers, he did the coding part right, the political part wrong. The right way to approach this would be to hack together a proof-of-concept, get buy-in (and/or participation) from the key engineers of the original system, and slowly build consensus. Yes, it's frustrating. Yes, it takes 10 times as long as just hacking it out. But, you end up not looking like an ass and also probably will end up with a better solution anyway because even you, Mr. Superstar programmer, might miss some details that the other people who have been working on the project longer will catch.
In the situation where you come in after a long weekend and show how you've managed to "fix" other engineers work you end up pissing people off because it makes them feel like you're making them look bad. Make them a part of the solution.
The advice of staying out of other people's code is either good or bad depending on what it means to "stay out". Avoid reading others people's code? Avoid trying to come up with alternative solutions to other people's code? Bad idea. Avoid going in and rewriting other people's code without syncing up with them before you demo your improvements to their boss? Yeah, that's probably good advice.
"Yes, it's frustrating. Yes, it takes 10 times as long as just hacking it out."
Yes, unless you are immortal, life is too short for this kind of crap.
Multiply the "takes 10 times as long" with an arbitrary n problems, and you soon end up wasting years on things that should take a few days.
One way to make "the best way to have a future is to be part of a team that values progress over politics, ideas over territory, and initiative over decorum." actionable is to change your job if you are working in a company where you have to jump through political hoops and "take 10 times as long" to get engineering improvements done.
Imo, being able to play political games is a valuable skill, to be used on the very rare occasion such game playing is really necessary. But you shouldn't have to do it every other day, especially on engineering problems. In this case, it might be better to just change your job, unless you have very very strong reasons for staying on.
EDIT: Not taking a position on the OP's situation or actions, fwiw. Just saying if it takes 10x time to make changes because of politics, might be time to move on.
It depends on the organization how long it takes. In a more 'enlightened' organization it's common courtesy to ping an engineer whose code you are working on improving, and then you can hack away. In a more stodgy one, yes, it could take 10x longer to get everyone on the same page if there are some people whose egos are easily bruised.
Regardless, it's a dick move to rewrite someone's code over the weekend and then roll in on Monday and start demoing it to PHBs that the original authors report to.
It sounds like the author had little respect for the original authors and decided he would swoop in and 'save the day' and not even give them a heads up with what he was doing. Then, he had the nerve to demo it to their superiors, and it's probably not hard to imagine him taking this 'opportunity' to explain why the original authors suck.. I mean, failed to think of this solution. The "but, but, I'm just making the product better" angle provides cover if he's called out on keeping the other authors in the dark.
Being a bit of a cowboy and having tact are not mutually exclusive things. This particular story reeks of someone looking to not just highlight their own skills but to do so at the expense of others.
Maybe it was a dick move for people to waste productivity over turf battles. Everyone's time was wasted.
A lot of these political fights sound a lot like working with unions. "Oh you can't do that, it'll save time and we won't get to work as many hours."..and then a few years later they're wondering why the plant declared bankruptcy.
So you rewrite everyone's code to make it "better" without their permission. Now who maintains all that code? You do. Life's to short to own all the code in the world.
What happens when the change you've just demoed to the boss breaks an important feature that you didn't know about?
In the case of the absurdly slow client/server architecture, what if this was a defense against a chunk of code prone to locking up or crashing? What do you do when your new, faster program suddenly crashes every five minutes after its deployed to production?
I would say that the other people did 'the political part' wrong. Nowhere else in life have I seen so much ego as with programmers.
I once thought it was because programming was a creative profession, and creators are protective of their creations, but I haven't seen anything like this in other creative media. When a musician composes or teaches me some music, I usually hear "that's just how I do it, you can do anything you want with it!".
It's not just about challenging seniority, either, because when I present a new approach to people with more experience than me, 90% of the time I get "here's why that's not actually better..." (and I learn something), and 10% of the time I get "OK, let's do that". (Or maybe it's 99%/1%.)
The only place I've been that even comes close is university politics. Perhaps that could explain programmer politics, since so many programmers come from there.
Like most engineers, he did the coding part right, the political part wrong. The right way to approach this would be...
This assumes there is a right approach. In reality it is highly probable that there is no such thing as a right approach. So actually the right thing to do is find another job.
If you plan on switching jobs every time rewriting someones code over the weekend and demoing it to their boss results in bad things then you better keep your resume polished.
No, but if people get pissed at you for working overtime to dramatically improve the system, it's a strong sign there's a better place you could be. Could the guy be more tactful? Definitely. Could this be the best place the guy could work? Doubtful, if he could make such an impact. But being ostracized rather than educated indicates an unhealthy work environment.
In the situation where you come in after a long weekend and show how you've managed to "fix" other engineers work you end up pissing people off because it makes them feel like you're making them look bad. Make them a part of the solution.
The advice of staying out of other people's code is either good or bad depending on what it means to "stay out". Avoid reading others people's code? Avoid trying to come up with alternative solutions to other people's code? Bad idea. Avoid going in and rewriting other people's code without syncing up with them before you demo your improvements to their boss? Yeah, that's probably good advice.