Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "root does what's expected of her"
Ticket: Add <feature> to <thing>. It works in <other things> so just copy it over. Easy.
Thing: tangled, over-complicated mess.
Feature: tangled and broken, and winds much too deep to refactor. Gets an almost-right answer by doing lots of things that shouldn't work but somehow manage to.
I write a quick patch that avoids the decent into madness and duplicates the broken behavior in a simple way for consistency and ease of fixing later. I inform my boss of my findings and push the code.
He gets angry and mildly chews me out for it. During the code review, he calls my patch naive, and says the original feature is obviously not broken or convoluted. During the course of proving me wrong, he has trouble following it, and eventually finds out that it really is broken -- and refuses to admit i was right about any of it. I'm still in trouble for taking too long, doing it naively, and not doing it correctly.
He schedules a meeting with product to see if we should do it correctly. He tells product to say no. Product says no. He then tells me to duplicate the broken behavior. ... which I already did.
At this point I'm in trouble for:
1) Taking too long copying a simple feature over.
2) Showing said feature is not simple, but convoluted and broken.
3) Reimplementing the broken feature in a simpler way.
4) Not making my new implementation correct despite it not working anywhere else, and despite how that would be inconsistent.
Did everything right, still in the wrong.
Also, they decided I'm not allowed to fix the original, that it should stay broken, and that I should make sure it's broken here, too.
You just have to admire the sound reasoning and mutual respect on display. Best in class.19