27

So here is my week 72 as a reviewer. But first, let me ask y'all. Am I weird to think that you should finish coding the thing and testing the thing before kicking it out to review? Cuz that's how I do it. And that is the process at my work place.

So anyway, I was doing this review. And it was very wrong. Like really, really wrong. We give a thorough intro to our product (perhaps too thorough) so this guy should have known every test case he had to cover. Or at least, if he was unsure, asked. It was all documented.

Anyway, he kicks out this peer review. First thing I notice, it is not following the standard. Fair enough, we didn't give him the coding standard. BUT HE DIDN'T EVEN MAINTAIN THE FORMAT OF THE ORIGINAL FILE. HE JUST DID HIS OWN THING!!! So I email him the coding standard and make a comment in the review. He denies the finding. No reason. Just turns it down. Strike 1.

Then, I'm going through and he didn't even cover all of the core cases. I found several core cases that he missed. And every edge case. Make a not of it. He fixes only the couple of examples I gave him. Strike 2.

Guy decided to redesign a major chunk of our interfaces. Our interfaces are not just used by us (hence interfaces). We designed them the way they were for a reason. It was not a fun design process. Myself, the architect, one of our customers, and the guy that did the implementation all told him to roll back his change. Especially since it wasn't in the scope of what he was doing. He wouldn't. Strike 3.

I go to the lead and bring him in. He has a talk with him. All of the sudden he is putting out multiple builds per finding. Like most times I will put out like 2 to 4 for the whole peer review. No he kicks out minimum one per finding and chokes the review queue. Strike 4.

Strike 5: he tells me, a former DBA, that I didn't know what I was talking about when I told him to move something into a new table, even after I told him that "while in database terms it doesn't make sense, this is for product robustness".

Strike 6: he was just a condescending asshole. Bragging about how he did this job and that job over his career. His longest position held was about 18 months. Bragged about working at my company and being some hotshot at the company: only worked here for 8 months and that was 5 years ago.

You know. I have never really wanted to fight someone after about undergrad. But he came close.

Comments
  • 1
    @illusion466 here's the thing though. In our process nothing goes in the baseline without being reviewed and going through QA. Peer reviews are given 5-10 business day deadlines to be completed by reviewers and they have to be checked off by at least two reviewers before you can consider the review complete. Our deliveries are 4-6 month development cycles. There was no reason for him to make that many builds, especially when he wasn't fixing everything/wasn't fixing the findings in the peer review.
  • 1
    So who was actually striking? That asshole or you because of his dumbness? 🤔
  • 1
    @illusion466 tis the world of contracting unfortunately. We release according to the contract. After each check-in we do make builds to capture the history, but major releases only happen 2-3 times per year.
  • 1
    @Gabe17 they were strikes until I set him on fire. He no longer works here.
  • 1
    @projektaquarius baseball and fire... I never thought these were compatible, but you proved me wrong! 😀
  • 1
    @Gabe17 they don't call them strike anywhere matches for nothing.
  • 1
    @projektaquarius I had to look that up, nice
Add Comment