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 - "root has a code review"
-
@Root has a code review.
CR comment: “Why would you do it this way? It’s awful. Clean it up!”
Totally fair. I had copied the legendary dev’s code, and it was ick. Cleaning it was easy and enjoyable. I cleaned the source, too.
CR comment: “Why would you touch this? It’s outside the scope of the ticket. You could get it working without changing all this.”
Revert…
CR comment: “The interfaces don’t match. Now it’s confusing, and that makes it harder to maintain.”
🤦🏻♀️16 -
Them: Root, you take too long to get tickets out. You only have a few simple ones. You really need to rebuild your reputation.
Also them: Hey, could you revisit this ticket? Could you help ____ with this other ticket? Hey Root, how do you do this? Root, someone had a suggestion on one of your tickets; could you implement that by EoD? Hey Root, i didn't read your ticket notes; how do you test it? Hey, could you revisit this ticket for the fourth time and remove some whitespace? Hey Root, someone has non-blocking code review comments you need to address before we can release the ticket. Hey Root, we want to expand that ticket scope by 5-6 times; still labeled a trivial feature though.
Also them: Super easy ticket for you. Make sure you talk with teams A, B, C, D, E and get their input on the ticket, talk with ____ and ____ and ____ about it, find a solution that makes them all happy and solves the problem too, then be sure to demo it with everyone afterward. Super easy; shouldn't take you more than a couple days. Oh, and half of them are on vacation.
Also them: Hey, that high-priority ticket you finished months ago that we ignored? Yeah, you need to rewrite it by tomorrow. Also, you need to demo it with our guy in India, who's also on vacation. Yes, tomorrow is the last day. (The next day:) You rewrote it, but weren't able to schedule the demo? Now you've missed the release! It's even later! This reflects very poorly on you.
Also them: Perfect is the enemy of good; be more like the seniors who release partially-broken code quickly.
Also them: Here's an non-trivial extreme edgecase you might not have covered. Oh, it would have taken too much time and that's why you didn't do it? Jeez, how can you release such incomplete code?
Also them: Yeah, that ticket sat in code review for five months because we didn't know it was high-priority, despite you telling us. It's still kinda your fault, though.
Also them: You need to analyze traffic data to find patterns and figure out why this problem is happening. I know you pushed the fix for it 8 months ago, and I said it was really solid, but the code is too complex so I won't release it. Yeah I know it's just a debounce with status polling and retrying. Too complex for me to understand. Figure out what the problem is, see if another company has this same problem, and how they fixed it.
-------------
Yep. I'm so terrible for not getting these tickets out, like wow. Worst dev ever. Much shame.
LF work, PST.13 -
Root: Fleshes out missing data in some factories. Tests affected code and finds the change breaks some specs (but shouldn’t).
Root: Reaches out to spec author.
Root: Messages thundercunt (the ticket’s code reviewer) on slack about the specs and the reaching out. No response.
Root: Works on another ticket while blocked.
Root: Logs off.
Root: Talks with spec author chick in the morning. Decide to pair on specs later.
TC: Still no slack response.
Root: Gives update in standup. Mentions factories and broken specs. Mentions pairing with spec chick.
TC: Still no slack response.
Root: Pulled off tickets in favor of prod issue. Gets ignored by everyone else diagnosing prod issue. Investigates prod issue by herself. Discovers prod issue isn’t from bad code, but bad requirements — code works as requested. Communicates this with details. Gets ignored by people still diagnosing prod issue. Tries again. Gets ignored. Gives up. Works on non-blocked tickets instead.
TC: Still no slack response.
Hours later:
TC: Comments on PR telling me I broke specs (how did I not notice?), that I need to reach out to spec chick and work with her, and that I can’t resolve the ticket until it’s fixed and passes code review.
TC: Still no slack response. (21 hours later at this point)
TC: Logs off. Still no response (25 hours at this point)
———
Ignoring the prod issue for the moment…
I broke specs. No shit.
I need to talk with spec chick. No shit.
I can’t resolve the ticket. No shit!
Bitch, I told you all of this 21 fucking hours prior, and again 3 hours prior during standup. But no, I clearly “don’t communicate” and obviously have no bloody clue what I’m doing, either, so I need everything spelled out for me.
And no, I didn’t resolve the fucking ticket. Why the fuck would I if it still has pending changes? Do you even check? Ugh!
And what the fuck with that prod issue? I’m literally giving you the answer. fucking listen! Stupid cunts.
Why is it all of the women I work with are useless or freaking awful people? Don’t get me wrong, many of the men are, too, but I swear it’s every single one of the women. (Am I awful, too?)
Just. Ugh.
I can’t wait to leave this sewer of a company.
Oddly still a good day, though. Probably because I talked to recruiters and sent out my resume again.rant oh my root gets ignored. root swears oh my root talks in third person root solves a prod issue thundercunt root communicates root wants to leave root gets ignored15 -
I built a feature. I asked questions for days. Nobody helped. I built it anyway, and while I'm not sure it's quite right, it works.
During a code review, I asked for clarification on who the fuck it's for. Simple fucking question. Didn't get an answer. I did get the same crap response twice, though. It's great because it both doesn't answer my question and makes things worse.
Let's refer to this as "branding." Here we go!
------
Root: "Should this be changed to blue? I'm not sure who the end-user is."
TC: "should be purple, then call it something more convenient" (...what?)
Root: "Better phrasing: if we use the feature, it should match our colors and be blue. If customers use it, it should match their colors and be red. It shouldn't be both. I looked through everything again, and i'm convinced that it's only for us, so it should be blue so it matches everything."
TC: "this should be purple, and then call it something [sic] red" (...what!? also: lolcopypaste)
------
But like, that's wrong in every single way. It's internal, not external. Doing both makes it confusing. Doing both and calling it external is fucking stupid. Did she even read the PR? or any of my questions? ugh.
I swear, it's like arguing with a boulder and expecting it to listen. An ugly, oversized boulder that comically resembles Jabba the Hutt. No joke.
Whatever, it can be purple. Later, if someone complains that it's confusing, I'll just link them to the damned PR. Then again, almost everything here is confusing AF, so I doubt anyone will actually notice.
Screw this place. So glad I'm on my way out.rant thundercunt the ugly boulder responds jabba the hutt root asks questions root has a code review6 -
Root has standup.
Root: I had no ticket yesterday morning, so I followed up on <TicketA> with <PersonA> and updated it in Jira and linked its related tickets; talked with <PersonB> about <TicketB>, and reviewed code review comments on <TicketC>, and thought about those while looking into the CI spec failure on <TicketD>. I collapsed for 3 hours before fixing it. Halfway through the collapse, I talked with <PersonC> on <TicketC> CR comments and the spec issue in <TicketD>, then went to lay down again. Afterward, I solved the spec issue in <TicketD>, and started on the new ticket <TicketE> before calling it a day. Plans today are to <…>.
Manager, in private: I need you to proactively let me know if you’re taking long breaks and aren’t working as this impacts business flow.
—————
Yeah.
My update was four times longer than the others’ despite her not giving me a ticket to work on. I responded to slack while I was collapsed on the floor and discussed tickets. And, after I recovered, I went back to work to finish my 8h shift. But this isn’t good enough? And I need to let her know in advance when I’m going to collapse and be a bloody mental zombie for hours? It would be amazing if I knew. I barely have a few minutes notice, and that’s only if I’m really paying attention and looking for signs.
And (conjecture) she probably still thinks I’m not performing well enough. “Affecting our business flow” probably means she’s angry I didn’t talk to other people about low-priority <TicketE> yesterday while I was laying on the damned floor.
Goddamn I hate her.11 -
CR: "Add x here (to y) so it fits our code standards"
> No other Y has an X. None.
CR: "Don't ever use .html_safe"
> ... Can't render html without it. Also, it's already been sanitized, literally by sanitize(), written by the security team.
CR: "Haven't seen the code yet; does X change when resetting the password?"
> The feature doesn't have or reference passwords. It doesn't touch anything even tangentially related to passwords.
> Also: GO READ THE CODE! THAT'S YOUR BLOODY JOB!
CR: "Add an 'expired?' method that returns '!active'?"
> Inactive doesn't mean expired. Yellow doesn't mean sour. There's already an 'is_expired?' method.
CR: "For logging, always use json so we can parse it. Doesn't matter if we can't read it; tools can."
CR: "For logging, never link log entries to user-readable code references; it's a security concern."
CR: "Make sure logging is human-readable and text-searchable and points back to the code."
> Confused asian guy, his hands raised.
CR: "Move this data formatting from the view into the model."
> No. Views are for formatting.
CR: "Use .html() here since you're working with html"
> .html() does not support html. It converts arrays into html.
NONE OF THIS IS USEFUL! WHY ARE YOU WASTING MY TIME IF YOU HAVEN'T EVEN READ MY CODE!?
dfjasklfagjklewrjakfljasdf5 -
001 REM Code review
010 PRINT "Nitpick nitpick nitpick nitpick nitpick"
011 GOSUB REFACTOR
020 PRINT "This function is too complicated, break it up"
021 GOSUB REFACTOR
030 PRINT "Why do you have three methods for this? Put all the logic in one method."
031 GOSUB REFACTOR
040 GOTO 020
041 REM ARGH
998 PRINT "Looks good."
999 STOP8 -
developer makes a "missed-a-semicolon"-kind of mistake that brings your non-production infrastructure down.
manager goes crazy. rallies the whole team into a meeting to find "whom to hold accountable for this stupid mistake" ( read : whom should I blame? ).
spend 1-hour to investigate the problem. send out another developer to fix the problem.
... continue digging ...
( with every step in the software development lifecycle handbook; the only step missing was to pull the handbook itself out )
finds that the developer followed the development process well ( no hoops jumped ).
the error was missed during the code review because the reviewer didn't actually "review" the code, but reported that they had "reviewed and merged" the code
get asked why we're all spending time trying to fix a problem that occurred in a non-production environment. apparently, now it is about figuring out the root cause so that it doesn't happen in production.
we're ALL now staring at the SAME pull request. now the manager is suddenly more mad because the developer used brackets to indicate the pseudo-path where the change occurred.
"WHY WOULD YOU WASTE 30-SECONDS PUTTING ALL THOSE BRACES? YOU'RE ALREADY ON A BRANCH!"
PS : the reason I didn't quote any of the manager's words until the end was because they were screaming all along, so, I'd have to type in ALL CAPS-case. I'm a CAPS-case-hater by-default ( except for the singular use of "I" ( eye; indicating myself ) )
WTF? I mean, walk your temper off first ( I don't mean literally, right now; for now, consider it a figure of speech. I wish I could ask you to do it literally; but no, I'm not that much of a sadist just yet ). Then come back and decide what you actually want to be pissed about. Then think more; about whether you want to kill everyone else's productivity by rallying the entire team ( OK, I'm exaggerating, it's a small team of 4 people; excluding the manager ) to look at an issue that happened in a non-production environment.
At the end of the week, you're still going to come back and say we're behind schedule because we didn't get any work done.
Well, here's 4 hours of our time consumed away by you.
This manager also has a habit of saying, "getting on X's case". Even if it is a discussion ( and not a debate ). What is that supposed to mean? Did X commit such a grave crime that they need to be condemned to hell?
I miss my old organization where there was a strict no-blame policy. Their strategy was, "OK, we have an issue, let's fix it and move on."
I've gotten involved ( not caused it ) in even bigger issues ( like an almost-data-breach ) and nobody ever pointed a finger at another person.
Even though we all knew who caused the issue. Some even went beyond and defended the person. Like, "Them. No, that's not possible. They won't do such dumb mistakes. They're very thorough with their work."
No one even talked about the person behind their back either ( at least I wasn't involved in any such conversation ). Even later, after the whole issue had settled down. I don't think people brought it up later either ( though it was kind of a hush-hush need-to-know event )
Now I realize the other unsaid-advantage of the no-blame policy. You don't lose 4 hours of your so-called "quarantine productivity". We're already short on productivity. Please don't add anymore. 🙏11