3 ms·

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

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

gfodor 14y ago
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.
- briandear 14y ago
  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.
johngalt 14y ago
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.
- mdonahoe 14y ago
  He didn't replace it, he made a demo. The original owners then had to implement his design. I've coded up demos as tools for getting my point accross for a particular feature. I don't own or maintain the resulting implementation. It was a proof of concept. He proved his point. Though if you make too good a demo, you might end up gettig assigned to do the rest, and that is danger you speak of.
wtracy 14y ago
It's not always a political problem. 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?

gfodor 14y ago

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.

briandear 14y ago
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.

johngalt 14y ago

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.

mdonahoe 14y ago
He didn't replace it, he made a demo. The original owners then had to implement his design. I've coded up demos as tools for getting my point accross for a particular feature. I don't own or maintain the resulting implementation. It was a proof of concept. He proved his point. Though if you make too good a demo, you might end up gettig assigned to do the rest, and that is danger you speak of.

wtracy 14y ago

It's not always a political problem. 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?