Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "reviewee"
-
Well, I am not sure whether this is supposed to be about worst experience as a reviewER or a reviewEE so I'ma do both. First as a reviewer.
So, on my first project in this company, I introduced automated build scripting (read: suggested, was "volunteered" to do it, then had to bust my ads to get it done). Prior to this, our process was run the thing in Visual Studio a bunch of times (don't ask) and package the resulting files. Well, new requirements made this not sustainable.
So after many many meetings in which I assured my co-workers that the script wouldn't cock up and go sideways and format our server (HOW???) and showed them how to work it AND added all the features they requested. I finally send the script out for code review. Oh the joy. Questions like: "why did you implement this?" Came from the guy who told me to implement it. "Can you change the formatting?" I checked and no. "Why isn't this to the code standard?" Because the code standard doesn't include scripting languages.
And here is the piece that takes the whole piss soaked shitsicle pie "I don't understand why we're doing this in the first place. We have a build process already, why do we need a new one?" FUCKING REALLY?!?!? YOU WERE IN THE GODS DAMNED MEETING WHERE WE DECIDED TO DO THIS!!! SET OUT THE REQUIREMENTS!!! LITERALLY EVERYTHING TO DO WITH THIS SCRIPT YOU WERE THERE AND YOU'RE ASKING WHY WE'RE DOING IT NOW!?!?! Fucking hell. I forced it through anyway because I had the higher ups all signed off on it, but seriously. Just because we're doing something new that slightly inconveniences you, doesn't mean it doesn't need to be done. Stop being afraid of change.
Side note: these people actually would regularly hold up process and product improvement because change is scary.2