Me: Which one do you want me to review first, PR 1 or 2?

Coworker: Yes.

Every time you squash a bug before someone else even sees it...

Lead: "There's a bug, you fix"
Me: "The PR for that has been waiting for your review since yesterday..."

PM in daily: your turn. what have you done yesterday?

me: so i finished my PR for feature x and now i'm only waiting for review feedback there, so i can close this ticket today if no major rework is required-

PM: this is not what i asked, i don't want to know what you did, i want to know what was done.

me: uhh... okay, also i started working on task x
[note: task x, a task per definition involving a large amount of research, was very coarsly defined and it wasn't even clear to the PM what he exactly expects from me, and we agreed that the scope needs to be refined in the process],
so as a first step, i started doing some general investigations to get an overview of the topic and learn about concepts a and b-

PM: again, i don't want to know what you did, i want to know what was done.

me: okay well, i have DONE basic research on topic xy and collected information-

PM: this still does not answer my question, what's the deliverable?

me: ...so uhhh.... i read papers? i researched info online and collected and prepared information and links in a presentation which i'm also planning to present to the team-

PM: okay, can you please split your jira task in subtasks so everyone knows exactly what you're working on? otherwise we have no idea what you're doing.

for fuck's sake, shut up. just shut up

Going to do this the next time I review a frontend PR 😂

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.

TFW your client's git policies are so draconian that the dev teams use "develop" as trunk, and completely ignore the release process.

I wrote up 50 pages of git standards, documentation and procedure for a client. Bad indian director 9000 decides the admin (also Indian) who specializes in Clearcase and has no git or development experience is more qualified to decide and let's him set the policy.

FF to today:

- documentation, mostly contradictory, is copy pasted from the atlassian wiki
- source tree is the standard
- no force pushing of any branches, including work branches
- no ff-merge
- no rebasing allowed
- no ssh, because he couldn't figure it out...errr it's "insecure"
- all repos have random abbreviated names that are unintelligible
- gitflow, but with pull requests and no trust
- only project managers can delete a branch
- long lived feature branches
- only projects managers can conduct code reviews
- hotfixes must be based off develop
- hotfixes must go in the normal release cycle
- releases involve creating a ticket to have an admin create a release branch from your branch, creating a second ticket to stage the PR, a third ticket to review the PR (because only admins can approve release PRs), and a fourth ticket to merge it in
- rollbacks require director signoff
- at the end of each project the repo must be handed to the admin on a burned CD for "archiving"

And so no one actually uses the official release process, and just does releases out of dev. If you're wondering if IBM sucks, the answer is more than you can possibly imagine.

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.

*Code review a PR*

“Remove extra new line here.”

Developers who like to "emphasize" conditions.

(Forgot to post this a few days ago. Was just too tired.)

Finally finished the code review from hell.

The patch on top of the PR is +1448 -1114, and nearly all of it is rearchitecting, not moving.

I think I spent six days on it, 4-5 productive hours a day? Seems like a lot. This codebase is a bitch to work in.

I’m spent.

A PR I raised was left un-reviewed for 3 months. And finally when shit hit the fan, I was asked why I never worked on the fix.

I pointed to the PR I raised 3 months ago and I got absolutely flamed for it because obviously, it was my fault that I did my part, asked for a review and moved on to other tasks.

According to my manager, I should have kept pushing for the PR to be reviewed.

I wanted to set the office on fire that day.

Code review time:

Hey Rudy, can you approve my PR? ??? Shouldn't it be can you review my PR?(thought to myself)
Anyway, as a new practice, we(royal we) do not approve PRs with js files. If we touch one, we convert it to typescript as part of a ramp up to a migration that never seems to get here. But I digress.
I look at the laziest conversion in history.

Looked like
Import 'something';
Import 'somethingElse';
Import 'anotherSomething';

export class SomeClass {
public prop1: any;
public prop2: any;
public prop3: any;

public doWork(param: any){
let someValue = param;
// you get the idea
return someValue;
}
}

Anyway, I question if all the properties need to be visible outside of the class since everything was public.
Then if the dev could go and use type safety.
Then asked why not define the return type for the method since it would make it easier for others to consume.
Since parts of the app are still in js, I asked that they check that that the value passed in was valid(no compilation error, obviously).
Also to use = () => {} to make sure "this" is really this.
I also pointed out the import problem, but anyway.

I then see the his team leader approve the PR and then tell me that I'm being too hard on his devs. ????

Do we need to finish every PR comment with "pretty please" now?
These are grown men and women, and yet, it feels oddly like kindergarten.

I've written code in the past that wasn't pretty and I received "WTF?" as a PR comment. I then realized I ate sh*t on that line of code, corrected it and pushed the code. Then we went to Starbucks.
I'm not that old(35), but these young devs need to learn that COMPILERS DO NOT CARE ABOUT YOUR FEELINGS!!!!!
Ahhhhhh
Much better.
Thanks for the platform.

it finally happened, PM/PO/SM is now also dev シ

each standup he now also gives update about his work in progress, with his diligently designed subtasks, perfectly sticking to the daily script, like a good well-behaved employee boi. it's weirdly cute

devs can't await to review his first PR. feeling the strong urge to spank his ass for each minor coding style issue or poorly-named variable...

New developers(5-6 years experience) these days are so pathetic. They dont have any sense of code review. All they want is to put their opinion out without giving any thought.

I had a PR for review today which contains mock specification to match a regular expression and return the corresponding response

The regular expression I put was

104000(02|06|20|48)

Now, this guy comes and puts a comment that we could "simplify" as 104000\d{2}

I replied, the ending digits are not contiguous. The specific pair of digits have to match for these mocks.

Then this guy replied, then we could simplify as 104(0{4}(2|6)l0{3}(20|48)).

I said, I cannot understand how that is simplification. Why do we need such a complex regex to match something very straight forward.

And the guy replied, we should be writing proper regexes, otherwise we could just specify everything explicitly.

I was like WTF man. You try deciphering this next week without taking at least a minute to know which values are matched.

Anyhow, another senior person approved my PR, and I merged it.

When you review a PR from a senior dev, find something improvable, suggest it and the dev updates it accordingly.

The first time when this happened made me the luckiest guy. It's still rare, though.

So you want full stack engineers to: design, do UX, create front end, build backend and deploy it in your mono repo stupid manual deployment "kubernetes cluster", add monitoring alerting manually, review others PR, QA our own apps and features, manually sync to Production, use VPN otherwise we cannot connect to anything, 2factor auth, do SRE, architecture diagrams, demo, run agile ceremonies, and learn a legacy coding language which was never mentioned in the job description. Did I miss anything?

Another case of "devs too stupid to poop" TM.

We had a funny discussion today.

Topic came up that a project using Lucene was incredibly slow.

Then came the yadda yadda of Java bad, Java sucks, Java bla Java blub in the gossip mill.

Both things irritated me, last thing was just the usual "I want to use new stuff cause I wanna be a cool jackass" trouble.

So. Today meeting. We did quick analysis by pair programming.

If I tell you that a whole team managed to review an PR, give it green light...

Despite the PR using the thread safe Lucene IndexWriter in a non-parallel fashion for large bulk inserts?

The whole problem screamed parallelization.

Yeah. If you ignore that scream and implement it in a sequential fashion, it is slow.

Congrats Jimmy, your retard level is off the charts.

Just checked a pr I need to take care of tomorrow…

“Please review [other pr] first, this solves a bug the other one introduces”

…Ah yes. Stupidity.

“Already tested by QA, accept without comments or job will be wasted.”

… I need a vacation or a megaphone to make someone deaf by screaming in their ears again and again: “follow the fucking processes instead of making QA preapprove your shitty code.”

Boss: we can't accept your MR request until you fix the problems we highlighted, everything is blocked and the client is getting angry

My brother in Christ, I understand your concerns but I need you to understand: you decided to block a perfectly working and documented PR because you didn't like having "<!-- -->" in a couple of HTML files and menial bullshit like that.
It may not be the most elegant thing ever but don't put on me the responsibility of your blocks or I'll smash your face with the coffee mugs I've used to work until midnight so that you could deliver the product in time after someone else delayed the deadline twice already.
Thanks and get fucked ASAP.

No comments on PR after thorough review

Spent a lot of time designing a proper HTTP (dare I even say RESTful) API for our - what is until now a closed system, using a little-known/badly-supported message-over-websocket protocol to do RPC-style communications - supposedly enterprise-grade product.

I make the API spec go through several rounds of review with the rest of the dev team and customers/partners alike. After a few iterations, everybody agrees that the spec will meet the necessary requirements.

I start implementing according to spec. Because this is the first time we're actually building proper HTTP handling into the product, but we of course have to make it work at least somewhat with the RPC-style codebase, it's mostly foundational work. But still, I manage to get some initial endpoints fully implemented and working as per the spec we agreed. The first PR is created, reviews are positive, the direction is clear and what's there already works.

At this point in time, I leave on my honeymoon for two weeks. Naturally, I assume that the remaining endpoints will be completed following the outlines/example of the endpoints which I built. When I come back, the team mentions that the implementation is completed and I believe all is well.

The feature is deployed selectively to some alpha customers to start validation testing before the big rollout. It's been like that for a good month, until a few days ago when I get a question related to a PoC integration which they can't seem to get to work.

I start investigating and notice that the API hasn't been implemented according to the previously agreed upon spec at all. Not only did the team manage to implement the missing functionality in strange and some even broken ways, they also managed to refactor my previously working endpoints into being non-compliant.

Now, I'm a flexible guy. It's not because something isn't done exactly as I've imagined it that it's automatically bad. However, I know from experience that designing a good/clear/future-proof API is a tricky exercise. I've put a lot of time and effort into deliberate design decisions that made up the spec that we all reviewed repeatedly and agreed upon. The current implementation might also be fine, but I now have to go over each endpoint again and reason about whether the implementation still fulfills the requirements (both soft and hard) that we set out to meet.

I'm met with resistance, pushback and disbelief from product management and dev co-workers alike when I raise the concern that the API might actually not be production-ready (while I'm frantically rewriting my integration tests and figuring out how the actual implementation works in comparison to what was spec'ed).

Oh, and did I mention that product management wants to release this by end-of-week?!

I can't take this anymore...

I'm reviewing n-th PR and I wanna gouge my eyes rn. This is the example I found in one of the PRs (and I could enumerate the examples for a long time...)

Mother****er piece of sh*t.

So recently my open source project took off and got trending on GitHub (680 starts and 225 forks). This was the first time a project of mine really gained some traction and invested more of my time and weekends to maintain this project - I wrote comprehensive docs, contributing guidelines and reviewed PRs and made sure I commented on every single one of them. Sure, it isn't easy to review 50 PRs a day after coming home from work but the excitement of seeing this project becoming trending fueled me.

First 2 weeks it was good. I would come home from work and have dinner and sit down to maintain the project. Whenever contributors would be stuck, I would help them and write comments on each PR.

But the problem started since last week. People just really want to see their contribution activity graph get populated and hence they would make stupid PRs and literally no one followed contributing guidelines - I mentioned in that that the code should adhere to Pep8 styling but no one gave a shit. Each day I would spend reviewing PR with crappy formatted code and no sign of Pep8, and even some will just file PR and add a fucking docstring to every function or add paragraph of comments. Also, the PR quality was bad with unsquashed commits amounting to 10 or 20 or even sometimes 50.

I wrote the contributing guidelines doc and in that I mentioned every source that contributors could find helpful like how to squash commits, how to file a PR and Pep8 and not to write useless comments. Seriously people, grow up!

I'm getting more and more triggered by my colleagues overusing words in seemingly random fashion.

The word 'perspective' comes up at least 6 times during a meeting, from an x perspective, from a y perspective. It would be fine in a design meeting but it's used _so fucking much_ I cringe every time I hear it.

Another one is 'standard', that gets put in front of every word nowadays, standard process, standard protocol, standard machine, standard pipeline. What does it mean? No clue, what does it add? Nothing.

'Please put this add the standard location.'

Where?

'The default one'

What?!

I remove it from documentation every chance I get.

Furthermore, some documentation changes make small pieces of information super long. A nice summary list of features? Make it at least 3 sentences for every bullet point. 1-sentence info with a reference link to more info? Scratch that let's include all information in that reference paragraph anyway. Sometimes they even expand English expressions for no reason, making them longer and harder to read.

WHYYYY

We always complain about shit documentation and yet we're oblivious to the fact that our own docs are so bloated. Stop repeating information, stop using useless adjectives, just put it all in 1 sentence and add dozens of code examples. One piece of code says more than a billion words.

I'm not innocent either. As a teen I was great at writing long pieces of text that seemed like a great read but were actually way too bloated for the information I needed to convey. It was great for reaching word limits.

Now I'm trying my absolute best to be as concise and to-the-point as possible because I know that nobody likes reading and people just want the information that they're looking for.

Even this rant is overly long, but thank god that it's just a rant and I can let off some steam.

Btw same thing goes for diagrams, too many icons, too much text, too many lines. When I try to submit a clean-as-fuck diagram I get asked to add more info/features to which I say No, we're already at the max.

I even got a PR for review that made some changes to add unnecessary information, I pointed it out and never heard anything from them again. I rejected the PR, and never saw a new one.

* Sigh *

It's just so strange to me, it's never clear to me why these things happen. I'm too much of a coward to point these things out unless they endanger the quality of the product. But maybe they just need somebody to tell it to them.

Me: *Make a PR*

Seniors: *takes 5 days to review* This must be changed

Me: Okay. *Make changes and PR on same day*

Seniors: *takes another 7 days to review* Oh, you also need to change this

Me: really? Okay. *do the changes*

Seniors: Well, I'm gonna accept it. But maybe you should rework all the integration later.

Me: what.

I'm super tired of this shit.

I don't give a fuck anymore. I'm leaving this company in less than a month and I'm so fucking pissed. No matter how fast I work, I ALWAYS end up not getting PR reviews FOR WEEKS. I POSTED A PATCH FOR AN ABSOLUTE BLOCKER THAT HAS MAYBE 20 LINES AND I STILL DON'T HAVE THE FUCKING REVIEWS A WEEK LATER. WHAT THE FUCK. Not to mention that bigger feature I've been working on that blocks subsequent dev steps. It's been, what, a month? And not a single review. The fuck am I supposed to do?

I was asked to fix a critical issue which had high visibility among the higher ups and were blocking QA from testing.

My dev lead (who was more like a dev manager) was having one of his insecure moments of “I need to get credit for helping fix this”, probably because he steals the oxygen from those who actually deserve to be alive and he knows he should be fired, slowly...over a BBQ.

For the next few days, I was bombarded with requests for status updates. Idea after idea of what I could do to fix the issue was hurled at me when all I needed was time to make the fix.

Dev Lead: “Dev X says he knows what the problem is and it’s a simple code fix and should be quick.” (Dev X is in the room as well)

Me: “Tell me, have you actually looked into the issue? Then you know that there are several race conditions causing this issue and the error only manifests itself during a Jenkins build and not locally. In order to know if you’ve fixed it, you have to run the Jenkins job each time which is a lengthy process.”

Dev X: “I don’t know how to access Jenkins.”

And so it continued. Just so you know, I’ve worked at controlling my anger over the years, usually triggered by asinine comments and decisions. I trained for many years with Buddhist monks atop remote mountain ranges, meditated for days under waterfalls, contemplated life in solitude as I crossed the desert, and spent many phone calls talking to Microsoft enterprise support while smiling.

But the next day, I lost my shit.

I had been working out quite a bit too so I could have probably flipped around ten large tables before I got tired. And I’m talking long tables you’d need two people to move.

For context, unresolved comments in our pull request process block the ability to merge. My code was ready and I had two other devs review and approve my code already, but my dev lead, who has never seen the code base, gave up trying to learn how to build the app, and hasn’t coded in years, decided to comment on my pull request that upper management has been waiting on and that he himself has been hounding me about.

Two stood out to me. I read them slowly.

“I think you should name this unit test better” (That unit test existed before my PR)

“This function was deleted and moved to this other file, just so people know”

A devil greeted me when I entered hell. He was quite understanding. It turns out he was also a dev.

Sent my changes before everybody for code review, got git blocked because today was demo day, and ... And asshole guy merged his own PR without code review. That conflicted with my PR. I am going to start posting the shennanigans of asshole guy from now on, just to have a record of his stupidity.

I have a new boss who was hired today. Well, I guess he's supposed to be a 2nd in command to my current supervisor, but I still have to report to him too I guess.

This dude is a high-sodium seasoned dev, and the kind who thinks anyone who's been in the industry less than 15 years should be at best a test engineer or thrown into the 7th ring of Customer Support.

Ugh. I'm now out of gin, which was my backup to my scotch. And this prick expects me to have a PR ready for him to review on a whole new application I've been working on for the last 2 weeks by midday tomorrow. And today was his first day.

Sometimes I like to look at my PR and think "Damn, that's some beautiful code, I can't wait for someone to review it".

Then the review comes and see a bunch of requested changes. =/

Welcome to this week's episode of "sudo-woodo tries to get a single Python script merged", starring...

•The software architect so senior they were working here while I was still in pre-school. Wasn't added as a reviewer and was completely absent on this project for two months but came in on this PR with a few questions, including questioning design decisions they agreed on the last time they saw the project.
•The QA lead with ten years of experience... in Java. Has never even touched Python and asked to review, only for every issue raised but one stemming from not knowing the language.
•The CI guy. A script guru who will find a problem with literally anything. Honestly the most helpful person of the bunch.
•My coworker. Hasn't said anything yet.

please send help

What is it with people just blindly fucking copy pasting from a different project, seeing it work and then submitting it for review.

You copy 2 lines, one of which fixes the thing, WHY KEEP THE OTHER USELESS IRRELEVANT PIECE OF FUCKING SHIT IN THE FUCKING CODE WHY BOTHER WITH KEEPING IT IN IT'S MORE TECH DEBT BECAUSE NOBODY WILL KNOW WHY IT'S THERE

WHY DO I CONTINOUSLY HAVE TO POINT THIS OUT IT'S SO FICKONG TIRING TO CONSTANTLY HAVE TO BE THE ANNOYING REVIEWER WITH +20 COMMENTS ON SMALL PRS IM SO FUCKING TIRED OF BEING 'THAT GUY'

In my language it's called being 'slordig'. Whenever I submit sometning for review I always go over the diff to see is I missed anything that is no longer required and remove it WHY DONT THEY DO THAT TOO

And then their PR stays open for 2 weeks like they forgot about it and during standup they say 'its in review' like I havent already looked at your piece of shit code

FUCK

The CTO has admin on the git repo and while we all have to have 2 other people review our pull requests. This guy will just go make a pr and merge it without review. It's not like its perfect code either. I will be going behind him and finding weird shit that he did days later and then go check the git blame. Yup its another one of his had to push it right now without review moments.

Long time lurker, I now have something to show you and it's something I've proudly made!

I've been working on OctoLenses lately, a Chrome extension allowing you to filter your PR and issues on Github. I find it really useful on a daily basis; and you might too

It can be used to:
- Monitor the PRs that need a review (or that have been reviewed successfuly)
- Find issues on open-source projects you like that you could take on
- Anything you can express with a Github search basically

It's good enough that I feel like I can share it with you, and I'd really like if you could take some of your time to give me a bit of feedback.

What do you like?
What you don't?
Which feature should I add?
Anything constructive basically :)

Thank you (and sorry for the self-promotion)!

Not claiming any originality here... I'm just happy to finally have included it. We'll see if it passes PR review - might make my coworkers "steam" a little (pun intended) ;)

What the heck
Who does this?

A bug is born
... and it's sneaky and slimy. Mr. Senior-been-doing-it-for-ears commits some half-assed shitty code, blames failed tests on availability of CI licenses. I decided to check what's causing this shit nevertheless, turns out he forgot to flag parts of the code consistently using his new compiler defines, and some parts would get compiled while others needed wouldn't .. Not a big deal, we all make mistakes, but he rushes to Teams chat directing a message to me (after some earlier non-sensible argument about merits of cherry picking vs re-base):
Now all tests pass, except ones that need CI license. The PR is done, you can use your preferred way to take my changes.

So after I spot those missing checks causing the tests to fail, as well as another bug in yet another test case, and yet another disastrous memory related bug, which weren't detected by the tests of course .. I ponder my options .. especially based on our history .. if I say anything he will get offended, or at best the PR will get delayed while he is in denial arguing back even longer and dependent tasks will get delayed and the rest of the team will be forced to watch this show in agony, he also just created a bottleneck putting so many things at stake in one PR ..

I am in a pickle here .. should I just put review comments and risk opening a can of worms, or should I just mention the very obvious bugs, or even should I do nothing .. I end up reaching for the PM and explained the situation. In complete denial, he still believes it's a license problem and goes on ranting about how another project suffering the same fate .. bla bla bla chipset ... bla bla bla project .. bla bla bla back in whatever team .. then only when I started telling him:
These issues are even spotted by "Bob" earlier, since for some reason you just dismissed whatever I just said ..
("Bob" is another more sane senior developer in the team, and speaks the same language as the PM)
Only now I get his attention! He then starts going through the issues with me (for some reason he thinks he is technical enough to get them) .. He now to some extent believes the first few obvious bugs .. now the more disastrous bug he is having really hard time wrapping his head around it .. Then the desperate I became, I suggest let's just get this PR merged for the sake of the other tasks after may be fixing the obvious issues and meanwhile we create another task to fix the bug later .. here he chips in:
You know what, that memory bug seems like a corner case, if it won't cause issues down the road after merging let's see if we need even to open an internal fix or defect for it later. Only customers can report bugs.

I am in awe how low the bar can get, I try again and suggest let's at least leave a comment for the next poor soul running into that bug so they won't be banging their heads in the wall 2hrs straight trying to figure out why store X isn't there unless you call something last or never call it or shit like that (the sneaky slimy nature of that memory bug) .. He even dismissed that and rather went on saying (almost literally again): It is just that Mr. Senior had to rush things and communication can be problematic sometimes .. (bla bla bla) back in "Sunken Ship Co." days, we had a team from open source community .. then he makes a very weird statement:
Stuff like what Richard Stallman writes in Linux kernel code reviews can offend people ..

Feeling too grossed and having weird taste in my mouth I only get in a bad hangover day, all sorts of swear words and profanity running in my head like a wild hungry squirrel on hot asphalt chasing a leaky chestnut transport ... I tell him whatever floats your boat but I just feel really sorry for whoever might have to deal with this bug in the future ..

I just witnessed the team giving birth to a sneaky slimy bug .. heard it screaming and saw it kicking .. and I might live enough to see it a grown up having a feast with other bug buddies in this stinky swamp of Uruk-hai piss and Orcs feces.

"can you please approve my PR?" yes, sure I'm happy to drop the context I built in my head, to pick up your totally different context, review your code and then rebuild my context.

I get an automated alert on slack whenever I'm requested a review on git, can't you fucking wait 20-40 mins when I'm out of the zone? Ffs.

While parsing nodes in a graph.
In terms of readability and variable naming, how wrong (if at all) is to use:
1. broNode (for sibling nodes)
2. papaNode / mamaNode (for parent nodes)
3. babyNode (for child nodes)

I sincerely don't know how to review this PR

Me: ill use media queries to make our site responsive (site is not responsive before i got here)
Me: code ...
Me: code ...
Me: done, created a PR
Senior: review... removes all the code and media queries and said. We dont have to use media queries because bootstrap is already responsive.

- BULLSHIT! We still need media queries!!!!!

So.. I have raised a PR 2 weeks ago.. it needs approval from 2 of the senior Devs on my team. The first one reviewed it within 3 days, without having to follow up. Then comes the second one, who is senior than the first one. I have been following up with him on a daily basis for the past 1.5 weeks, each time I request him to review my PR he sends me a "sorry" followed by a stupid smiley. I have tried tagging him on Jira, setting up a meeting with him to get it done, nothing's working out. He has already looked at the code and I have explained him the code and the context, but he is just not adding comments/approving/rejecting the PR. I have missed the release date for the feature because of his lack of concern and petty excuses. So done with him.

The current project I'm working with had 3 devs including myself until Jan 1st. Now we're only two, because our lead/manager started to work in other projects and trusted us.

Since that happened, my first PR/Commit of the year was in Jan 5, and it's still open, without any kind of review or comment, as well as my other five (eight in about a day) PRs, while he's making commits directly into develop/main branch, causing conflicts everywhere on what I did...

I'm leaving on friday because the contract is ending.

Good luck I guess.

Code review = number of wtf's pr minute

Code review day 1:

Me: Where are these three templates being used? I don't see any class that uses them.

Him: Oh, yeah. My bad. I'll remove them.

(Time passes)

Him: I don't know what's going on with my branch. Please ignore the PR for now.

(Time passes)

Him: Is there any way for me to get the files from staging. I don't know what I did to my branch.

Me: Hang on. I'll push a copy of the one I have in a new branch.

He declines his PR and stops by to say he's going home but he'll open a new PR tomorrow and remove the unused files.

Code review day 2:

Him: Hey, do you know what happened to my PR? It looks like it disappeared.

Me: You declined it yesterday. Said you'd make a new one today without those extra files.

Him: Ooooh!

Story about my old boss:

I was doing a lot of work in an area that had a data property and a method to build an object. I noticed a reset method that iterated all that objects properties, found the matching data from the data object, passed that data through some logic to format it and then assigned that value to the object property.

As part of my PR I removed that method, since data wasn't changing, and simply called the create method again with data.

The result of tidying the code base and putting it up for review before a merge? I get told I have no respect for my boss's code, that I am undermining him, that I need to be more considerate and respectful of other people's work and that I am no longer allowed to change any code he has written in the code base (half the code base) without talking to him about it first, before it goes up for review. Also if he is working on an area I cannot change anything - not even 1 character (he is working on the core of the app).

Every day there I was so confused :D

So my colleagues don't proactively do PR reviews, even when they're assigned to them, unless asked for the n-th time by me or the PM.
In the meantime other PRs get merged, I need to merge master in my branch, and solve conflicts every time so that it is eligible for merging.
Additionally, while reviewing, the requierements engineer realizes that there were corner cases not initially covered in the ticket description, so I get review findings about covering these.

The best code review experience I had is when I started with my first job I used to write 10 lines of code and used to get 20 comments on that, well i learnt a lot from him and now whenever i get review comments on my PR i actually feel good.

Today was my last day before taking a week off from work. When I originally pushed my branch, GitHub knew I had 7 files changed. I squashed my commits and pushed so that there was one commit. GitHub then decided I had Infinity files changed. Fun way to end the week, posting “I *swear* that I didn’t just put up a PR for review before taking a week off that has Infinity file changes.”

Writing a feature critical for production in 2 hours of solid focus during the morning.

6 hours later it's still not in the build because:
* tech lead wants the code to move to a partial class instead of an extension method, delaying the UX review. No guidelines for this ever existed.

* after seeing the result, the UX team wants some element to be dynamic. A line. A friggin horizontal line.

* after adding the dynamic shiny frigggggin line, I try to test the feature with the server. It is still not deployed because the server guy went home. "The PR was not merged so I assumed we'll add it tomorrow".

Another day at the meat grinder.

Been on a fairly large project for the past two months. Been getting more and more productive and confident with each sprint! Always informed that I’m doing fine. Left a four hour task in progress for a day or so while tending to a PR which had been pending for a week and a half and was currently under review. Removed from the project due to issues with velocity.

Literally slept off during this zoom call. I just woke up I don't wth everyone is talking about. Turns out my PR was up for discussion. Now I have to review a bunch of shit I thought I was done with. OS maintainers can be a pain sometimes 😭

Get assigned a PR review
Spend half an hour meticulously looking through it
Looks flawless, no errors, compiles, test cases passing, expected results
Approve request
Another developer immediately finds a flaw

Fuck. I think I am totally incapable of making myself look good.

Me waiting for a PR review

Just review and merge my PR already!!!
Damn is it frustrating to see PRs stagnating after finally finding an open source project I can actually bring something useful to :(

Needed a code review urgently. As I’m the only mobile dev in my team I posted my request in a mobile group channel on Slack asking for someone to take a look. I used @here to notify everyone that’s currently online and I got slammed for using @here in the channel because people got a bloody notification. Grow a pair and stop being a fucking snowflakes. This is a company Slack channel and I am asking you to take a look at company critical PR why wouldn’t I use @here

I hate people who merge the PR while the others are in the middle of the fucking code review

* Fix sleep schedule
* Eat better and gain 20 pounds
* Don't yell at future contributors
* Be very kind to everyone except that one "client"
* Review every PR with patience except that ones from that "client" because I am a petty maintainer
* You'll never understand the pain, "client". Be a human or eat shit.
* Maybe be a maintainer at a different open source project so I don't have to deal with script kiddies 24/7
* Fix sleep schedule so I won't be dev ranting at 6am

When the CTO/CEO of your "startup" is always AFK and it takes weeks to get anything approved by them (or even secure a meeting with them) and they have almost-exclusive access to production and the admin account for all third party services.

Want to create a new messaging channel? Too bad! What about a new repository for that cool idea you had, or that new microservice you're expected to build. Expect to be blocked for at least a week.

When they also hold themselves solely responsible for security and operations, they've built their own proprietary framework that handles all the authentication, database models and microservice communications.

Speaking of which, there's more than six microservices per developer!

Oh there's a bug or limitation in the framework? Too bad. It's a black box that nobody else in the company can touch. Good luck with the two week lead time on getting anything changed there. Oh and there's no dedicated issue tracker. Have you heard of email?

When the systems and processes in place were designed for "consistency" and "scalability" in mind you can be certain that everything is consistently broken at scale. Each microservice offers:

1. Anemic & non-idempotent CRUD APIs (Can't believe it's not a Database Table™) because the consumer should do all the work.
2. Race Conditions, because transactions are "not portable" (but not to worry, all the code is written as if it were running single threaded on a single machine).
3. Fault Intolerance, just a single failure in a chain of layered microservice calls will leave the requested operation in a partially applied and corrupted state. Ger ready for manual intervention.
4. Completely Redundant Documentation, our web documentation is automatically generated and is always of the form //[FieldName] of the [ObjectName].
5. Happy Path Support, only the intended use cases and fields work, we added a bunch of others because YouAreGoingToNeedIt™ but it won't work when you do need it. The only record of this happy path is the code itself.

Consider this, you're been building a new microservice, you've carefully followed all the unwritten highly specific technical implementation standards enforced by the CTO/CEO (that your aware of). You've decided to write some unit tests, well um.. didn't you know? There's nothing scalable and consistent about running the system locally! That's not built-in to the framework. So just use curl to test your service whilst it is deployed or connected to the development environment. Then you can open a PR and once it has been approved it will be included in the next full deployment (at least a week later).

Most new 'services' feel like the are about one to five days of writing straightforward code followed by weeks to months of integration hell, testing and blocked dependencies.

When confronted/advised about these issues the response from the CTO/CEO
varies:

(A) "yes but it's an edge case, the cloud is highly available and reliable, our software doesn't crash frequently".
(B) "yes, that's why I'm thinking about adding [idempotency] to the framework to address that when I'm not so busy" two weeks go by...
(C) "yes, but we are still doing better than all of our competitors".
(D) "oh, but you can just [highly specific sequence of undocumented steps, that probably won't work when you try it].
(E) "yes, let's setup a meeting to go through this in more detail" *doesn't show up to the meeting*.
(F) "oh, but our customers are really happy with our level of [Documentation]".

Sometimes it can feel like a bit of a cult, as all of the project managers (and some of the developers) see the CTO/CEO as a sort of 'programming god' because they are never blocked on anything they work on, they're able to bypass all the limitations and obstacles they've placed in front of the 'ordinary' developers.

There's been several instances where the CTO/CEO will suddenly make widespread changes to the codebase (to enforce some 'standard') without having to go through the same review process as everybody else, these changes will usually break something like the automatic build process or something in the dev environment and its up to the developers to pick up the pieces. I think developers find it intimidating to identify issues in the CTO/CEO's code because it's implicitly defined due to their status as the "gold standard".

It's certainly frustrating but I hope this story serves as a bit of a foil to those who wish they had a more technical CTO/CEO in their organisation. Does anybody else have a similar experience or is this situation an absolute one of a kind?

Why comment on the same thing during code review??

I submitted a PR and had to make a design choice that propagated throughout the module i was working on.

During code review, my coworker commented on every...single...line that this change effected asking "why are we doing x here?" instead of just creating ONE SINGLE THREAD with this question for discussion. There were at least 10 review comments on github from their one review that said "why X?"

Is this normal? Ive only had a few programming jobs and this is the first time this has happened to me.

personally, when someone makes a choice like that, i just make a comment and save the rest of the review until that is addressed.

Senior dev: Complete task and raise PR immediately
2 week later: No review
FML

It's a Monday, I've been trying to fix a bug since the morning, I cannot read or write any code. I tried to review a PR, still cannot read the code. Getting frustrated by the slightest problem.

So today my colleague is installing new dependency to our react native project and do something cool with it.

Him: I already push it in new branch and make a pr, would you review and merge it to master.
Me: ok let me try first.
.
.
Me: it is not working, i get this error.
Him: try change these xxx in xcode.
Me: ok, wait.
.
.
Me: now I get this error
Him: hmm... Try 'react-native link xxxx'
Me: ok
.
.
Me: I get same error like first error.
Him: now try 'react-native unlink xxxx'
Me: hmm... Wait.
.
.
Me: I still get same error, what's wrong?
Him: I don't know, it's working in my mechine .

*Me 'git reset - - hard' and try to build again.
**After building

Me: hey it's working after I git reset lol.
Him: nice
Me: let me clone it and try 1 more time.

*after cloning and building
.
.
Me: I still get same error like 1st error hahaha.
Him: so try to 'react-native link xxx' again.
Me: OKkK
.
.
Me: still get same error
Him: try git reset and build again
Me: hmm
.
.
*after git reset and build again
Me: I still get same error. I think the correct steps is :
1. Clone
2. Do something in xcode
3. React native link
4. React native unlink
5. Git reset - - hard
6. Build

I can't stop laughing 😂🤣😂🤣🤣😂🤣😂

==============
Getting Feedback Rant!
=============

When "this is simpler" feedback results in a function of 500 lines of code.

When I get "don't do X" in the feedback. Thank you very much. What do you want me to do instead?

Unclear feedback.

When the feedback giver changes his mind after I applied the changes!

When applying the feedback introduces a bug.

Simply opinionated feedback that is not enforced by any tool or backed up by any facts.
Please find something better to do in life.

Unactionable feedback.

"Consider X"
I will not consider thank you very much.

"Verify this works"
Duh..

When the feedback giver knows something that you don't.
I know this is a legit case.. still annoying.

"I disagree with the feature"
Go argue with the PM, not relevant to me, thanks!

=====================
GIVING FEEDBACK RANT
=====================

I rewrote the system. Please review it.

No need to review, just approve.

I will change this as part of the next ticket.

I would like to keep it the way it is.
lazy ass..

You can't test this.
It's impossible to test this.

No need to test this.

There's no point to test this.

I'll test this on production.

Not sure why this is working..

Please document this..
Because documentation is like a thing, you know.

Oh, this code is not related to this PR, I just don't want to open a new branch for such a small change. ignore it.

Ignore this.

This will be meaningful in my next change.

Oh my fucking god, we're doing SCRUM, why does every task get stuck in review limbo and take a sprint and a half minimum because of it.

What's that? You committed the tmp/dist/cache field for something only YOU run locally and asked me to review it. Just GET OUT.

I don't get why this retard keeps ignoring my comments on a PR he asked me to review. He is a level above me so I can't push it. I just approve his PR and let him know I do so but with a comment. He then ignores the comments and merges his rubbish changes into the codebase thereby creating a tech debt.

Someone raised a PR for the opensource project "fast XML parser". Since this was a major change, it was difficult to review. I asked for the purpose and requested to break it into multiple PRs, where 1 PR should have related changes only. And any good change but unnecessary change can be avoided to scheduled for later.

We had long arguments for a month or two.

I don't know why but instead of breaking the PR, the contributor keep updating his PR for every commit someone made on the original repo.

He also stopped contributing for other changes, and commenting on other issues. (Change in the behavior)

Finally after 5-6 months, I had to close the PR as it was not active, having conflicts and not as per guidelines.

A former team lead decided the team should review any open PR before proceeding with their own tasks after their breaks. Any open PR also meant reviewing refinements in an ongoing discussion. Several times, we wasted time for review, coding, and discussing when the second reviewer asked to revert the changes introduced according to the requests of the first reviewer.

Now as a freelancer, in smaller projects, I sometimes have no coworkers to review my code. So, apart from testing, I try to pay more attention to linters, static code analysis and automated coding assistance. I have stylelint, eslint, SonarLint, and possibly some more IDE inspections. For the infamous popular blogging software, I also have a so-called PHP code sniffer that checks all PHP and JavaScript code for compliance with the WordPress coding styles, so finally, I got the team experience back: SonarLint suggests removing unnecessary spaces and reformating my code, which in turn makes PHPCS complain that the code violates the legacy code style.

There is a particular power move when you take someone's shit code, refactor it to make it faster, safer and more readable and then request a review from them on your PR. "See how I dunked on you, bitch. This is what superiority is about." And at the same time you can be perfectly polite with "oh you know this part of the code well, I wouldn't want to break anything there" with the "bitch" just strongly implied.

Apologies if this has been asked here before, but I wanted an open feedback on a query: Is there such a thing as overdocumenting?

I take pride in being a very articulate developer, being as descriptive as possible in my emails, internal communications, PR review comments, JIRA etc.

A product guy from the company today mentioned: "Though I understand your good intent behind being as descriptive as possible, it is possible that some of the junior engineers might get overwhelmed/ intimidated looking at those comments/ emails and it might stop them reaching out to you with your doubts."

I was not able to wrap my head around this, because I don't understand how a descriptive explanation might overwhelm anyone. It's a skill I picked up going through my career and I personally have always respected peers who documented things properly.

Open to feedback. Thank you in advance.

me:task assigned is a small fix.Gonna finish Early sit back relax this sprint.
mail(next day):we've moved to microservices.setup as easy as gulp landscape:start
me:cool!shinny new stuff!seems easy!!
project:npm failed..please check module xxx..
me:fine.....
after long mail chain
project:npm failed unknown file not found
me:fine.....
after hours of googling and little github issue browsing
project:server running @ portxxx
me:yay finally happy life!!makes chnages, sent for review.
reviewer:code needs refactoring!!
me:make all changes..waits for faceless reviewer from another timezone!
reviewer:thumbs up.
me:i will make it in time!!!yes!!
jenkins:buid:failure
me:no still i wont give up...
debug finds out new bugs caused by unrelated code...make new PR the end is near,one day more will definitely merge!!!
mail:jenkins down for maintenance!
me:nooooo....waits till last minute gets thumbs up for merge, finally merged in the last second!!

all for 12 lines of code change.
:/
sad life

What do you do when pull requests are enforced, but everyone is so fucking apathetic about reviewing code?

Picked up an issue to contribute to OSS for a community version of a major enterprise software. Did the changes, submitted a pull request. Someone reviewed it, asked for some changes, which i did and pushed the changes.

Then after some discussion with the guys working there, we thought of making some changes to the UI. Step in the company UI guy, he makes some changes, i merge his branch into mine and submit a new pull request.

Now, a new guy comes in to review the code, who has a problem with every change THEIR UI Guy did, and negates everything the first reviewer said, and asks me to do the changes, and boy was I pissed!!

But I did the changes, updated the PR, then the first reviewer comes in again, and suggests some more changes, most of them are for the code, THEIR UI Guydid!! Fucking psychopaths!! Never had i seen such paranoid people in my life!! Educate your fucking team first!!

I one again started with the changes but left mid way!! Now, even if i want to, will not update the PR!! FUCK YOU!!

Person marked the ticket as ready for review, but if you merged the PR, no effective changes would have been applied to the codebase as all line additions were commented out 🫠

My best review was when i changed the code that someone suggested in another PR, which was highly critiqued by the OG devs. One pull to the latest commit and PR to his fork later, the OG dev comments "that looks good" and merges it.

Celebrated for sure that night. I've been hooked on contributions to open source ever since.

:D

This one is funny for me because my current team lead and I have a really comical dynamic regarding reviews.

I can't say I've ever really had a bad experience but I brought up one stand up about how he had rejected my PR and that he was probably just going to reject the next one. So now it's this joke if I get a PR through in one review (which is usually).

One time he spiked a ping pong ball towards me in a match and I replied, "Hey whoa man, this isn't a code review calm down!". 😂

When you spend hours in a messy codebase to fix a bug properly and add an integration spec to cover that specific case.
And even you do a round of testing on staging + providing screenshots, there is always someone on the team that will write in your PR, "It works, I tested the change on my machine".
I understand that some people are skeptical but to the point of not trusting integration tests + screeshots/recordings then please test it on staging or production next time because if it works on your machine doesn't mean it will work there ;)

Working with new guy who is "senior" is such a pain. We had a factory file that is used to populate tables in endpoint tests. The new guy decided to add a static util method called createTestRecord() to a query builder model. Fucking query builder calls in a static method in a query builder class. I send him messages expressing concerns regarding his approach but never got anything back. The guy just ignored me and asked me to review his pr.

I am leaving in 4 months. Release me from my misery. Fuck my life

When you get asked to review a pull request for new functionality and the PR has no specs.

rent / question (there is a question at the end and I'd appreciate your opinion)

8 months ago, I agreed to help a not too distant relative of mine to do his master thesis at the company where I work. He was supposed to build something really MVP, but useful for us and I'd help him get some scientific questions out of it, and provide him with (computing) resources to test his theories / implementations under simulated and much heavier load.

Since then, he didn't get done anything even remotely useful, always just stuck on very rudimentary issues, claimed things are almost ready, I wrote a quick smoke test to prove that the whole application blows up when you touch it, in short - a disaster and went over to radio silence.

In the meanwhile, we didn't need it anymore, so 1.5 months ago, I got in touch with him again, with an even more technical proposal, something, at least I'd think, that's even cooler to do. He asked me some question about hypothetical load, the system should be able to handle eventually, to come up with alternative implementations to compare them against each other. He said that his exam period is going to be over soon and he'll get back to me with some initial version.

2 weeks ago, I got back in touch with him, trying to urge him, to get finally started and get something done. If he'd actually sit down and do it during the holidays as a "full time job", he'd be probably done in 2 weeks. Last week, he came back to me and said he has an initial PR ready to review.

I was excited about it, but basically froze when I realized what he did. He deleted all his previous work - some infrastructure stuff which took us basically 3 months of back and forth to get running - and as far as I could see, all the new code were only auto generated clients based on a swagger specification. In short - I could do it in less then an hour. If you really have no idea what you're doing, it might take you half a day, but definitely nowhere near to a week.

His brother, which a good friend of mine, thinks I'm being too hard on him. His argument was, that it's too hard, and he has to do it in C#, but he only knows Java (I gave him access to some of our repositories to copy paste code together, he didn't need to invent anything. I also prefer C# but wrote my master thesis in Java) Personally, I'm just pissed because he promises stuff that he never does. I totally understand him - I was like that as a student as well, I guess karma is a ... but still, he's wasting my time.

Right now I'm thinking how to get out of this, without having even more time wasted. I doubt he'd ever deliver anything useful. He got plenty of input from me about what he could consider for his scientific question, how to measure performance, ... He can keep his credentials to access our test environment with the test data, but I won't give him access to any additional computing resources, to compare how his solutions might scale on our company's cost. (mainly it's not the money, but I'd have to provide that stuff, and probably help him set it up)

does it sound like a fair deal (saying, I'm done with you. You can finish your topic on your own, but don't expect any help from me)? or am I being a dick about it and too demanding?

My manager had someone else manage me for my whole time at the company so far. Nearly two years now. Anything I’d come to him with, he’d direct me to this other person.

Fair enough, dude’s really good and I learn a lot from him. I see why they trust him with so much. I think he’s a genius. I’ll never be that good. Embarrassed I’m only a few years his junior. Wonder why he’s okay with being a manager for employee pay. Don’t think about it much, normal corporate BS.

Well it got way more “normal” when his ass got laid off without notice. Feel terrible. Him and 70% of my branch’s full timers. Wonder how I got so lucky. Everyone’s gone. We barely have enough people to do a standup. They all had 5+ years on their belts minimum. Only the contractors are left.

Manager emergency meets with me. Tells me all his best staff are gone and I am now the only front end guy on the team. He tells me he is not confident in the fact I am responsible for all of the old guys work and he is worried. He thinks I can’t do it cause he thinks I suck. Fuck me man.

My manager is pissing himself realizing he has lost the only people keeping HIS job for him. He has no clue my skill level. He sees my PR’s take a bit longer to merge, yet doesn’t realize I asked that friend of mine who was managing me to critique my code a bit harder, mentorship if you will, so we’d often chat about how to make the code better or different ways of approaching problems from his brain, which I appreciated. He has seen non-blocking errors come through in our build pipelines, like a quota being reached for our kube cluster (some server BS idfk, all I know is I message this Chinese man on slack when I get this error and he refreshes the pods for me) which means we can only run a build 8x in one day before we are capped. Of all people, he should be aware of this error message and what is involved with fixing it but he sees it and nope, he reaches out to me (after the other guy had logged out already, of course) stating my merged code changes broke the build and reverts it before EOD. Next day, build works fine. He has the other guy review my PR and approve, goes on assuming he helped me fix my broken code.

Additionally, he’s been off the editor for so long this fool wouldn’t even pass an intro to JavaScript course if he tried. He doesn’t know what I’m doing because HE just doesn’t know what I’m doing. Fuck me twice man.

I feel awful.

The dude who got fired has been called in for pointless meetings TO REVIEW MY CODE still. Like a few a week since he was laid off. When I ask my manager to approve my proposals, or check to verify the sanity of something (lots of new stuff, considering I’m the new manager *coughs*) he tells me he will check with him and get back to me (doesn’t) or he tells me to literally email him myself, but not to make any changes until he signs off on them.

It’s crazy cause he still gets on me about the speed of stuff. Bro we got NOTHING coming from top down because we just fired the whole damn corp and you have me emailing an ex-employee to verify PATCH LEVEL CHANGES TO OUR FUCKING CODE.

GET ME OUT

Today i wake up and i expect some bit of sanity in my job. Our CTO Respects no processes and stuff. I check PR's that are requested for review.
PR i 391 files long and it's not node_modules commited :|

Just after feature launch, major bug on production and now I am getting yelled at by my lead as the issue happens to be with the PR i was responsible for reviewing yesterday. Somehow a logic error got past my review. But considering how large the project is it wasn't possible for me to test out every possible scenario myself. They should have had QA handle that. Also, that was my first code review. I can't understand why my boss has such unrealistic expectations. Bugs are expected at this stage. I feel like he just puts too much pressure on me for no other ther reason other than to just trigger my imposter syndrome. That way, I feel like a bad developer even though I am working my ass off. And he gets to avoid giving me a raise. Cant believe I rejected multiple offers to stay at this company. I don't even know why am I still working for this company anymore.

When you are reviewing a PR in which the author has used utilities/libraries that were written by you(which were very generalized and DRY but required for you to read the docs to clearly understand their usage). But instead of using it properly they modify it for their specific usage and made a freaking PR. 

I just can't wait to finish the review and slap their face with a printed copy of the FUCKING docs. 

Seriously, read the goddamn docs. And, if you do change the lib, please update the doc too.

I don't think I wanna be a dev anymore

Just a year ago, I was doing many side projects for fun, aching for proper coding tasks at work.

Now, I got a senior title but I don't want to do ANYTHING, I don't want to learn this new service or learn how to develop new stuff, I've lost all desire to learn something new. I just want a simple af simple low needs job, but also want good pay XD I know, it's stupid, but I really don't care what tech I use or how exciting the product is, I just want a simple repetitive job with little stress and deadlines and good pay

How do you motivate yourselves to get through the day and do your tasks? Honestly every PR review I'm shocked other engineers care so much about the code, they're obv right, I just wonder where that desire to maintain good coding practices comes from

This morning I found out that the code I wrote to convert json data to a new format in our DB was giving errors and a bunch of questions got saved with the wrong property. It was assumed when it was triaged with my boss that we would only see one key property so the code written by me so the code was aimed at that. Well some questions have multiple keys for no reason. They are mostly floating data that hasn't been wiped clean because the develop who wrote this use json data in psql with no validation or data cleaning. This edge case was also never caught on PR reviews and we got a pretty heavy review process. I'm not being blamed for it. Most of it I think all the devs feel bad we didn't catch this because it affected us greatly. I've been working all morning trying to resolve it with my boss and just now in the evening we stopped. I just feel like I'm not a good dev at all and just want advice on how to deal with situations like this. I'm a new dev and this is my first job I have held for almost a year

So we now do continuous deployment to a development environment. Once a PR gets merged it gets deployed there. We then have to manually deploy to staging every so often.

We did this because QA wined that the Dev was constantly breaking Staging, when we contentiously deployed to that.

So now we have a staging instance that is always behind. Which isn't big deal, because its supposed to be stable right?

Well now the stupid fucking QA team is always making mountains of tickets and noise for stuff that is already fixed on the development instance.

Fucking shit that they message me about, or have to call me about. "Hey let me tell me about this thing I found." And then I'm like I already fixed that thing last week.

So it seems to be wasting everyone time to not just CDCI into staging. I have to wait weeks to retest my bugs on staging. To make sure that some other stupid fuckeshir on my team didn't undo or break my fucking fix. Shit keeps getting kicked out of QA Review. Fuck. lol.

Then there like I can update the thing on the database through the front end tool. Well tough shit buddy, your going to have to wait a week unti next staging deployment to see if that tool is fixed. This is your fault for fucking up our pure CDCI with your ideas. Now everything takes longer for everyody.

To sum things up. Some dumb bug makes it into the manual staging deployment and gets fixed an hour later. Doesn't get deployed until next fucking week. QA makes a bunch of noise about it. A thing that is fixed and in the pipe-line.

Also a dumb fucking bug will make it into staging, lets say a critical front-end back office tool that needs to send numbers to the backend, they send a fucking string instead of a number and break it. Now we have to redeploy the tool and backend to staging because there related. Then if we deploy backend we have to deploy the client facing site too. since it also depends on backend.
Its a fucking hassle.

Now if the fucking DevOps guy could do his job, and make a god-damn deploy button for all the staging servers that would be great.

Some background:

About 2 months ago, my company wanted to build a micro service that will be used to integrate 3 of our products with external ticketing systems.

So, I was asked to take on this task. Design the service, ensure extendability and universality between our products (all have very different use cases, data models and their own sets of services).

Two weeks of meetings with multiple stakeholders and tech leads. Got the okay by 4-6 people. Built the thing with one other guy in a manner of a week. Stress tested it against one ticketing service that is used in a product my team is developing.

Everyone is happy.

Fast forward to last Thursday night.

“Email from human X”: hey, I extended the shared micro service for ticketing to add support for one of clients ghetto ticketing systems. Review my PR please. P.S. release date is Monday and I am on a personal day on Friday.

I’m thinking. Cool I know this guy. He helped me design this API. He must’ve done good. . . *looks at code* . . . work..... it’s due... Monday? Huh? Personal day? Huh?

So not to shit on the day. He did add much needed support for bear tokens and generalized some of the environment variables. Cleaned up some code. But.... big no no no...

The original code was written with a factory pattern in mind. The solution is supposed to handle communication to multiple 3rd parties, but using the same interfaces.

What did this guy do wrong? Well other than the fact that he basically put me in a spot where if I reject his code, it will look like I’m blocking progress on his code...

His “implementation” is literally copy-paste the entire class. Add 3 be urls to his specific implementation of the API.

Now we have

POST /ticket
PUT /ticket
POST /ticket-scripted
PUT /ticket-scripted
POST /callback

The latter 3 are his additions... only the last one should have been added in reality... why not just add a type to the payload of the post/put? Is he expecting us to write new endpoints for every damn integration? At this rate we might as well not have this component...

But seriously this cheeses me... especially since Monday is my day off! So not only do I have to reject this code. I also have to have a call now with him on my fucking day off!!!!

Arghhhhhh

I am legit getting tired of trying to help people improve and hit huge roadblocks because nobody seem to care if what we do works for the intended purpose.

I have seen some terrible unstable code that fails 50% of the time on run time and never was reviewed or tested on core software, but since it was worth a lot of story points, people get congratulated for finishing it but nobody bothers checking if it really works in the first place. Story points are meaningless in this Agilefall Frankenstein shit process we use and bosses keep saying they will improve it but nothing gets done.

Worst thing is my work often depends on this shit.

I swear one of my good colleague and I are trying to introduce commit and PR gating, code review, code quality to avoid as much problems as possible while speeding up CI and documentation but 90% of devs do not give a single fuck about it. They just bypass it with admin rights because it supposedly slows them down.

When I bring up to management that the processes are terrible, I get the classic "we can't force people to use these processes because we have to respect their work ethics and it is different from yours." While I get that some things are subjective, in this case that's a lot of words to say they suck and give no fucks.

Sorry for the rant, it is starting affect my morale and efficiency at work, but I know every workplace got its problems.

Colleague put this up on their team's channel today :

" I'll be working from home today, ad hoc task is in review, will be opening a PR for backend changes [ ... ], yesterday was mainly spent on setting up gcp on my local and fixes towards gcp deployment. "

Wait, what? did you just set up the entire GCP on your local [machine]? I wouldn't mind giving you a whole week off if you needed it; if I were your manager.

I hate with a passion Code Review sessions in Pull Requests. It takes days to get approved especially when you have as Lead tech someone with 3 years of experience that rejects PR because doesn't like how I named the variable and also if that person is different time zone.

In my previous company we used to have 30 minutes session if we had PRs and we would go over it.

How does your organisation and team balance PR comments demanding changes and dev time?

Here, while fixing PR comments we sometimes end up wasting as much time as we took in actually developing the feature... As a result, almost every major user story overshoots the estimation and almost every sprint gets delayed.

Yes, to each his own; but talking in general, why do you think this time wasting happens?
Do you think that happens because some of us are not as experienced as the others, the existing code not being up to the mark giving a bad example, or just a skewed review process?

The smaller the code changes the longer the name of PR for the code.
And even more review changes mentioned by the reviewer...

I was supposed to just review the PR. But I couldn't stop myself from making minor changes.

It has been 4 hours now. I'm thinking if I should raise a PR for the PR.

UI specifiaction changed when PR is already waiting for review... great

Learn git. Contribute to open source projects - you may learn more from code review on a single PR than from a whole tutorial. Ask questions constantly. Learn more git. Look for the cleanest solution to a problem. Write code that is easy to improve, easy to expand, and easy to debug. Learn even more git. Don't limit yourself to thinking only in terms of OOP, or functional, or procedural, or whatever type of programming you may be comfortable with. Don't be afraid to do some work by hand. Learn git, so that when all comes crashing down and your team crumbles to pieces, when your relationships fail and your friends disappear, when you're down on your luck and there truly is no hope left in life, you can check out of the dangerous world of your current HEAD and return to the home and comfort of your master branch, which you've kept safe, secure, and functional.

Today I submitted to code review the first iteration of a microservice done with Ramda and flow by request of my collegues. This is the first time they look at anything similar to functional code or typed js, and only one of them took the time to actually do a review.

I really like having my code reviewed and reviewing others', but please don't pester me to make a PR for a microservice you'll never look only to bail off as soon as you see something new that scares you. Buckle up and learn new stuff!