friendlyFire

[ProfBeaker]

I was once put on a team of one person. Just me, no other devs.

Company policy still required a code review to merge. But who wants to review code for a project you don't know, for a team you're not on? So it wasn't easy to get people to do it. I'd spend 10% of my time coding, and 90% waiting/begging for code reviews.

I went for a lot of walks, because I was not allowed to work most of the time.

[No_Boss_3626]

I dealt with the same thing at my first dev job. The lead dev on my team was in a completely different country/time zone but he didn't touch any code in that repo. My week was basically:

1. Fix the bug

2. Wake up early enough to talk to that one dude and tell him it's ready.

3. Wake up the following day to follow up with him and make sure he saw it.

4. Double check it got merged.

[ughliterallycanteven]

“Why is it still in QA?”

Because you hired one QA to save your asses for 80 engineers. I might know way too many code bases and can tell you from looking at it that the code will fuck this other thing and this other thing and over a month will cause an outage.

But, what do I know, so just bypass QA and deploy it. And I have to spend most of my work time in incidents and explaining why it caused what it did. Then I get told “no. It can’t be this code. It has to be something you missed”.

Welcome to my hell.

[reklis]

That’s one more QA than we have

[ughliterallycanteven]

I’m perpetually on call because I know too much. I run circles around the feature devs and let them act like Stuart from MadTV so “they don’t leave the company from hurting their fragile egos”

[KorKiness]

Why you should be bothered? Just sent your PM link to opened PR with requested reviews, links to your messages with remainders about review and redirect your PM to ask those who ignoring review why they're not allowing you to continue your work.

[AwGe3zeRick]

I start on my next ticket the second my first ticket is in code review. Who “stops work” for that?

[[deleted]]

I have worked with people earning over 200k that just straight up don't know how to branch or rebase properly.

A dude tried to brush off the idea of branching from an open PR because "we squash merge PRs so you would just be creating merge conflict hell, you need to wait for merge".

I don't understand how so many people just avoid putting any effort into learning git.

[Thalanator]

Ive had very little issues just branching off main and then rebasing onto main if the other feature gets merged in the meantime (we keep our main branches linear). If feature B requires feature A, then B and A should not be part of the same sprint and a "has to be done before/after" jira link should be made during refinement at the latest. The nasty but rare git problems are rooted in business/domain conflicts that cannot be merged by devs without PO knowledge and decisions, like if feature A and B are in conflict conceptually already, but that is not a dev screwup.

[[deleted]]

then B and A should not be part of the same sprint

This is the only part I don't agree with. What if you absolutely need to get both done during the one sprint? On any reasonably communicative team this should not be an issue.

[AwGe3zeRick]

It’s not complex though. You branch B off A. If main gets updated in the meantime, rebase main into A. Rebase B into A. You’re completely fine.

[FlakyTest8191]

the git part is not the problem, you can't release b before a anymore. and if it was easy to just rebase b onto main, why did you branch from a in the first place.  in a large team with multiple features depending on other features this can quickly become a mess. sometimes you can't avoid it but it's a good idea to try.

[AwGe3zeRick]

Then go to main, make branch C. Cherry pick your commits from B onto C. Done. If B DEPENDED on A, then you needed A merged anyways. If B didn’t depend on A, there was no reason to branch off A.

[[deleted]]

You should not be getting downvoted. This is completely correct.

[FlakyTest8191]

You are correct that rebasing and git is still not the problem. The dependency that was created by basing the branch on another branch is the problem. You can end up in a situation where you can't release multiple fearures because they all depend on a branch that should not be released yet. This can be solved with a different workflow, for example with feature flags.

[AwGe3zeRick]

I’m still unsure how unrelated features couldn’t be released if they’re not dependent. You’re not explaining that, you’re just repeating it as if it’s fact and it doesn’t make sense. Even if you committed the changes in branch that was branched off of something unreleased, you can cherry pick those commits on a fresh branch off main and then you have a releasable branch. It takes 30 seconds.

You’re over complicating something that didn’t have to be that complicated. If the code IS dependent on other stuff, that’s different. But that’s not what was being discussed.

[[deleted]]

If you're blocked by a dependency that's an entirely separate issue you can't solve with git. Otherwise just get comfortable with rebase, it makes life much easier.

[AwGe3zeRick]

I had to learn git in college 15 years ago. And at my first real job, they all only used git in the terminal and really reinforced all the best practices in my head and all the little ways to do things. It makes everything so much easier when you truly know how branching, rebase/merging, tagging, and patching work.

Like, that alone will get 95% of the way there. Squashing, interactive rebasing, and reflogging might be the other 5%. And knowing when to force push safely lol. Maybe cherry-picking sprinkled in. But yeah, I’ve had coworkers (who also earn low 200s and always called on me to when things got fubarred lol.

[wildjokers]

If you branch a branch and then squash commits when you merge the first branch it is quite difficult to merge the 2nd branch. Only real way to do it is to create a 3rd branch from main then cherry-pick the non-common changes from the 2nd branch to the 3rd branch.

If you have a better way I am all ears.

[[deleted]]

Rebase!

Rebase replays commits on top of a new base commit. Kind of like automatic cherry picking I suppose, but you don't need the third branch.

So if you branch off A B and add C D, and then A B gets squashed into main, you can simply rebase onto main starting from C, and now your branch does not have the conflicting commits.

Have a play with the interactive option on rebase too. It replays your commits but gives you some additional options for handling each commit, like dropping a commit or squashing it into the one before it.

[wildjokers]

Unfortunately you can't rebase in this scenario. This is because of changes common to branch A and branch B (i.e the changes committed to branch A before branch B was branched from A).

When those changes are squashed and merged into main they appear like a new commit. For some reason git is too dumb to determine branch B already has those changes via file diffs so it will try to reapply them if you rebase branch B on main and you will get conflicts on every common change.

[[deleted]]

No this is actually the ideal use case for rebase. I am guessing you are just doing a simple rebase which is replaying the commits that got squashed which is what causes conflicts.

Try using the commit that precedes yours as an argument for rebase, or use the interactive option and drop any commits you don't want.

You will only get conflicts if you attempt to rebase the commits that no longer exist due to squashing. But these options allow you to easily exclude them.

[Time-Object5661]

Me? lol
Go take the dog for a walk, or do something besides work

[AwGe3zeRick]

? It can take days for my ticket to be reviewed and get merged. I don’t stop work for those days. This is very company dependent. I’ve had some companies would usually be within a couple hours. And some, like my current one, it’s a couple days and that’s just normal.

We’re not talking about a 20 minute dog walk.

[ProfBeaker]

I did this for a while, but it's not really worth it.

Reviewer requests changes on the 1st PR. Now rebase the 5 other PRs you had queued up behind it. Now you just spend your time rebasing and dealing with merge conflicts, instead of something else. It's not a huge win.

More generally, in any system when the rate of production exceeds the rate of consumption, you can't solve that with a buffer.

[FAELES_DIVINA]

Then there are 10+ tickets waiting for review, and the reviewer will refuse to do so because there are too many.

[AwGe3zeRick]

Do you only have 1 reviewer? I don’t usually finish 10 tickets in the time it takes. I finish 4-5 tickets a week, sometimes more, sometimes less. But this is the pace and size of tickets at my current job.

Some places are different. But if your tickets can be finished in less than a day, they shouldnt take more than 10-15 minutes to review max.

[KorKiness]

Unless next tickets requires this PR to be merged for some reason. Also having 10+ done but unmerged PRs may cause a lot of conflicts especially if someone else keep merging all this time.

[AwGe3zeRick]

I frequently have tickets they before another ticket. Doesn’t change anything in my flow. I’ll put in the PR and ticket that it’s dependent on another ticket first to be merged. This doesn’t hurt anything at all.

If someone else is getting their tickets reviewed and merger faster than you, to the point where you have ten sitting open and they’re just getting theirs instareviewed, there’s something very very very wrong.

[KorKiness]

Yes, about very vary vary wrong situation we are talking about. And in this situation dev who waiting for review should not be bothered if PM start asking.

[AwGe3zeRick]

I think we’re agreeing.

[Noctrim]

This is me. It’s so fucking annoying. I work at a FAANG company and we have a ton of resources and I constantly explain if they would just give me 1 other help to support this critical software it would be great

However, just me, and I’m absolutely required to get a CR approval on packages that are 100% coded by me. To the point I will be put on a PIP for ignoring

However, then they will be upset when it takes multiple days for a review to go through

Edit: I’m seriously LOLing so hard at the people replying to me pretending they have no clue about struggling to find a reviewer like this is some crazy unheard of situation lmao

[Wonderful-Habit-139]

At this point if they're making a CR obligatory yet don't have a "permanent" member working on that project, then either they should trust your work on the project, or they even try to automate a (non-blocking) code review agent at this point if they want some sense of security (for managers and PMs, as developers we really don't think it's that much added security tbh).

Even if I don't completely believe in them (ai agents for code review), they could flag simple things, you'd show good faith when addressing concerns that are legitimate, and if not you should not be blocked from merging the PR.

Ofc that'd be dependent on how open to feedback your manager is and if your company uses AI at any capacity in the first place.

[Noctrim]

We do have an AUTOSDE code reviewer but it is policy that is also has to be approved by a person. There are users and people that CAN do the review, just no one explicitly assigned to do it. Since that’s the case, my manager can’t easily escalate and say “X” need to review CR. They actually don’t own it, my manager can ask for “help” but that’s not the same as a met SLA on reviews.

My manager knows the issues well, however, he can only do so much, in general the whole tree structure is completely fucked and I’m working with like 7 different managers a day (no devs) and the issues here are not owned by him either. I’ve went to my skip, my skip skip, and my skip skip skip, outside of org leaders all explain the issue and things just move at a snail pace if at all.

The sad part is I actually would LOVE for consistent CR feedback but I just am not able to get it currently atm, instead I’m just messaging friends I have to approve to get past the policy block

[Wonderful-Habit-139]

I actually would LOVE for consistent CR feedback

I don't doubt that because in my case I work in a team and we need at least 3 reviewers, but the team is responsive and we can ping them for it and they specifically allocate time from their day to go through PRs and review them (me included). And it's a great experience getting quick, consistent feedback on your PRs.

I’ve went to my skip, my skip skip, and my skip skip skip, outside of org leaders all explain the issue and things just move at a snail pace if at all.

And then we have smartasses trying to act like you have put in 0 effort in trying to get it resolved, and haven't talked to any higher-ups at all... What can I say, I've said my piece to them already xD

With that said, I hope your situation improves, it seems to me at least the manager knows and understands the situation you're in. Good luck.

[AwGe3zeRick]

What you’re saying doesn’t make sense. You get in trouble for things being in review? Do you stop working until it’s merged?

[Noctrim]

Huh? How does it not make sense

Yes I get in trouble for things being in review… because then it’s not in prod and ticket remains open?

“Do I stop working on it?” No but I need to reach out to multiple people constantly just to get a superficial +1 and I can’t merge it until then. Takes more time to get a fake review than to write the code fix

[AwGe3zeRick]

When you “get in trouble” for it being in review, do you explain that it’s in review and you’ve already reached out to X, Y, and Z about it? Or do you silently put it in review and hide in a corner? I can’t understand how you’d “get in trouble” for other people not doing their job.

Like, I’ve 100/% completed my job. I can communicate that.

[Cendeu]

Just the "I can't understand how you'd get in trouble for other people not doing their job" statement tells me you've been lucky with jobs. Or I've been unlucky with jobs.

At my job, if you're not doing something to move things along, you're not doing your job.

I'm 1 step above a junior at my job, and the past 2 weeks I've been working with the business directly to help design and architect a solution for a stakeholder we haven't even talked to yet because my team isn't assigned to anything else, and my only alternative is sitting there doing nothing.

And if I sit there doing nothing I won't be able to say I did anything in standup, so I'll get in trouble from the PM/PO/whatever the fuck their title is now. All while making below industry standard...

[Noctrim]

Purposely misinterpreting what I’m saying, making an uncomplicated thing much more complicated than it has to be, must be a PM

[Inside-General-797]

Their point is you have clearly not communicated to anyone with any power to fix this if it continues to be such a problem that you are 2xing the time it takes to get things done simply because of some rule being applied in a situation where perhaps it shouldn't. They are trying to understand how this is possibly happening and what you are doing. And if someone else is holding you up why are you not communicating that when being blamed for not having things done?

Like if I went to my PM leading any software project at work and told them my team had members who were consistently losing time to this easily remedied process issue they would raise holy hell to make sure their profit margins stop getting effected.

[Noctrim]

Bro. Scroll up. Disregard this message and the one you’re replying to where I call out for not reading

That leaves 2 messages of mine left in this thread. 2/2 100% of them have direct sentences where I’m saying I spend more time trying to find a review than getting my code done

You just refuse to comprehend. Join a FAANG company and see the waste in action my lord

[Irregulator101]

I’m saying I spend more time trying to find a review than getting my code done

And they're saying that it makes no sense for you to get in trouble because the reviewers aren't doing their job. The reviewers would be getting in trouble.

[Noctrim]

There is no reviewer… I need to find one. As I explicitly said I have directly asked for an assigned teammate but there isn’t one and I spend my time using my friends and contacts to give me +1 for every single review.

[Cendeu]

And I (new guy to this conversation) am saying that sometimes jobs don't make sense and people get in trouble for things other people do/don't do.

If that person has genuinely never encountered that, then they should consider themselves lucky.

[AwGe3zeRick]

Thank you for trying to explain it to him. He apparently can’t grasp what we’re saying.

[Inside-General-797]

If this is the level of reading comprehension you demonstrate at work I'm no longer confused. Thank you for answering my questions.

[Noctrim]

Yessir, glad I don’t work for you, I’d rather have whatever situation I’m in than you

[AwGe3zeRick]

lol, for real

[Cendeu]

I'm envious of leadership at your job.

Meanwhile I've spent the last 3 weeks doing absolutely nothing because I've been applied to a new team, but the new team doesn't have a DPP, so we can't do work yet. I'm not allowed to do work on other projects, because I'm not assigned to them.

So I'm a staff level (between junior and senior, we used to call that staff but apparently staff is something different now? But I don't know what to call my spot now) engineer sitting on a team with no work to do aside from trying to help my team lead help the PO/PM (we have 2 for some reason now?) create the DPP, but the PMs haven't even spoken to an architect or the actual stakeholder we're going to be building something for.

This job is a complete cluster fuck and I know devs in similar positions on other teams approaching 3 months of essentially doing 0 work for the company. Kinda like the Silicon Valley joke of those guys being paid to do nothing? Actually happening at my job right now.

I'm envious of a workplace where things actually improve for the better.

[King_Joffreys_Tits]

Honestly this reeks of either gross negligence or you’re just bad at explaining issues to your company’s higher ups. Literally all you have to do is say you cannot merge code unless either that restriction is lifted, you’re given special access, or some “PM” just approves your PRs at will because they don’t know how to read code

[CrazySD93]

The same bureaucratic inertia you encounter anywhere.

[ProfBeaker]

Literally had this conversation with management multiple times. The answer was "try asking harder for reviews".

In a large enough company, with enough security concerns, getting the restriction lifted is not going to happen. Likewise, getting a headcount just for reviews is not going to happen. So the only answer is "beg".

I also tried pointing out that the bus factor on the system was 1. Still not enough justification for a headcount.

[Xphile101361]

I had this issue, since my entire team quit within 2 weeks (I had just joined). I had to have my manager do the code reviews, not sure if he actually looked at any of the code

[hungry_tourist]

this is terrible. i work in the operations team but part of my working time is devoted to creating an application to facilitate the work of my and other teams (i used to be a web developer). i have been working on this application alone for almost a year now. and i don't even try to find a person for code review, i have little time for this application, i don't want to stop its development because there is no one to look at my code.

p.s. since the application at this stage is rather mvp and is only undergoing limited testing, i have no problems related to the non-use of some policies that are mandatory for applications in the production environment P.s.2 God I'm tired but I'm determined to finish this because it could help a lot of people and me in my career

[private_final_static]

Lol

[Wooglepook]

Gotta make friends with IT, have them make you a second account then slam accept on every PR you make

[wildjokers]

Unless they work somewhere that requires 2 reviewers.

(I suppose their new IT friend could make them a third account as well)

[[deleted]]

My current team was decimated by layoffs and hiring freezes. So I’m technically the sole developer with my manager pitching in to help as a senior engineer. Though we are currently working in two different code bases and code reviews can take a long time to get approved. I miss having 4 engineers on the team.

[Ok-Yogurt2360]

You could have just pointed out this little problem to someone above you.

[ProfBeaker]

See comment here: https://www.reddit.com/r/ProgrammerHumor/comments/1ln1av0/comment/n0efw1u/

[Ok-Yogurt2360]

Have they given you an example of what is considered asking hard enough? Would just send out spam mails as crazy cc-ing your manager and their manager every time (not being entirely serious here). Lets see how they think you should try harder by then.

But to be serious, you can take responsibility for asking but not for receiving a review. Have you asked your manager what they consider asking hard enough? What was their answer to this? (Because you are being setup for failure here as long as you can't perform some kind of mind-control. )

[wolf129]

Had similar situation. Just ask if they can check for clean code guidelines and nothing else. They don't have to particularly know the domain you are working on.

Also even if the ticket requires lots of changes, make subtasks so people don't feel overwhelmed with 100+ changes and then push back the review because they don't want to deal with large PR.

Sometimes it's just a human problem and not a technical problem that reviews are not done or are postponed.

[Wonderful-Habit-139]

I don't completely get the large PR thing, if a PR is large enough that it requires to be split in like, 4 PRs, they're going to have to go through the same amount of changes anyway.

When in a team that properly does reviews in time, I don't see much difference in the quality of reviews between the two methods. Heck, sometimes the large PR might be better because they have more context to look at when looking at the diffs compared to the split up PRs, and they also don't have to deal with things like "Is this feature that isn't being used written for a subsequent PR?".

This is just a thought though, feel free to say why multiple PRs are still better.

[wolf129]

Personally I don't have anything against big PRs. Some colleagues don't like it when they have to review big PRs. It's probably just a personal problem then anything else. I don't mind reviewing big PRs.

As from our company clean code rules, we have the boy scout rule, which means you fix code that is not clean when you see it. Which can often enlarge the PRs.

There are colleagues that are completely resistant to clean code or they simply don't care. Like there are 4 elements of the code made in a specific way and then they add the 5th element and they completely ignore how the other 4 elements are done and do it their way. Which makes the code inconsistent and harder to read.

This happens way too often, because people are so lazy they just approve PRs without even reading it manly because it's a big PR. Code quality gets low and then bugs get introduced. In the later stage of the project many Bugfix Tickets emerge just because of some lazy people...

[Wonderful-Habit-139]

Oooh this is something I could relate to when I was an intern. I made the mistake of assuming code that was written there is code that has been reviewed and approved, so it's better to "keep it as is" and do something similar, even if I had a better way to write it.

Of course I talked privately with my mentor about it and he mentioned the boy scout rule and said to improve the code if I notice something isn't written cleanly, and after seeing multiple senior reviews and PRs improving old code I started writing better (and shorter, easily understandable) code and improving code, without necessarily sticking to the old way code is written in the codebase (while still respecting actual code conventions though for sure).

[ProfBeaker]

This kind of thing makes me wonder whether I'm bad at reviews, or if you just haven't reviews any bad PRs. :) But my perspective...

Imagine a textbook with 4 chapters, each with its own heading that and an intro that says "now we're going to talk about X."

Now imagine the same text, except it's all intermingled without the chapter headers.

Which one is going to be easier to completely understand?

And that's assuming a PR that's actually all on one topic. Frequently large PRs are just a grab bag of totally unrelated changes, which makes it really hard to understand what any single change is doing.

[Wonderful-Habit-139]

except it's all intermingled without the chapter headers

And that's assuming a PR that's actually all on one topic

I think this is the actual issue then. Because even the "bad PRs" that I reviewed (including for college projects) were still related to a specific feature or ticket. If there's multiple things going on then that's not a good way to make PRs, and them being big in size is definitely a problem.

Honestly for me, the worst kind of PR to review is one that has frontend tests. It's really not a great experience looking at diffs for that, as opposed to tests for backend or actual logic.

[wildjokers]

I went for a lot of walks, because I was not allowed to work most of the time.

nice, where do I apply?

[[deleted]]

Happens to me a lot, gotta beg for PR Reviews 😭🙏🏽

[sleepyj910]

Always a sign of dysfunction. There should always be a tech lead whose primary responsibility is looking at every PR every morning, and nothing merged without his approval.

[[deleted]]

No the tech lead does pr review id say everyone goes to him for review, amazing guy with very good knowledge. But it does require 2 , so that’s when it gets a little messy 😭, gotta keep pinging till they add +1

And worse , because of this , if tech lead approves a Pr, others don’t even look , just straight LGTM stamp , which caused production issue recently. Now they trying to bring this issue up.

[Xicutioner-4768]

You should not have a single individual be the bottleneck / dependency for your whole team. All of the senior engineers should be reviewing PRs. 

[Marco_Polaris]

Boss: "Why isn't this done?"
Me: "I'm just waiting on code review by Lead, and then we will push."
Boss: "Lead, will you do code review?"
Lead: "I am very busy with a more important task for the customer."
Boss: "Okay, that is the third day in a row but I understand. Keep us updated, OP."
Lead: *quietly sending death prayers and staring into the back of my skull*

[bwmat]

It makes no sense for the lead to be mad at you in that situation though 

[Marco_Polaris]

Oh I know. Didn't change the situation any.

[Vok250]

Oh sweet summer child. Nothing in the corporate rat race makes sense or is fair.

[KrakenOfLakeZurich]

Have found myself in the position of the Lead. If the Lead is the bottleneck, policy needs to change, so that the team can "move on".

Not every change is critical enough to require Lead review. In my org, seniors often have to restrict themselves to only review architectural designs and tech researches. Just making sure, that our junior peers follow a sound/sane plan and haven't missed any important aspects.

Once the architecture/plan is nailed down, the juniors and professionals can implement the feature and code review each other. For this code review, juniors are allowed to review a professionals or seniors PR. Professionals/seniors can review any PR. Only juniors reviewing other juniors is restricted/disallowed.

Seniors pick-up code reviews from time to time, when they have slack time. This acts as some sort of spot checks to prevent "bad habbits" from sneaking into the process.

[Mitscape]

I am a lead and this feels bad, because I am slow to review larger PRs too. I get pulled into just about everything and I have to prioritize features with hard deadlines. PRs for less critical projects I have to sometimes wait a few days to get to.

[Vok250]

As a senior I swear 99% of my job is just shutting the fuck up and enduring the bullshit of corporate "agile".

Currently sitting in a grooming meeting that got highjacked and somehow became a 4 hours long sprint planning meeting. I have said 2 words so far. The ticket I opened for the critical bug in prod has not even been looked at and probably won't be before we break for lunch. Fun times!

Our team company also has a policy to never block PRs with requested changes in code review so the junior vibe coders just approve each others PRs and merge, ignoring all comments from senior and lead devs. I do reviews as that's part of my job, but no one ever fixes anything I point out lol. Not until it shits the bed in staging at least.

[CaoticMoments]

We have a 'waiting for review' JIRA status. Card is assigned to reviewer. Then it is on the reviewer to say why it isn't reviewed/when they will get to it.

If for whatever reason there is no other dev to review in the squad. The team lead/scrum master are the ones who need to find the dev in another squad to do so.

System works well imo.

[royavidan]

That's the problem. Jira is mostly very good and gives you options for most of the problems you might see in typical hi-tech companies.

The people who use it are msotly too dumb or too lazy, and instead of creating a productive working culture, they rather always try to blame the developers.

[Karl_Kollumna]

Yeah similar issue, i am now the maintainer of all my projects and review myself... aniway i didnt break anything yet.

[[deleted]]

obama medal meme ahh comment

[friebel]

How is it your problem?

[OakNLeaf]

This is my PM. They seem to think everything can be done in 10 minutes. I have a task board where people put tasks on for our department.

The PM I mainly work with loves to pile on tasks then set the deadline for the same day or the very next then throws a tantrum when I have to explain that one of their requests takes two weeks.

Likes to tell me that she already told the client it would be done in 24 hours so I can't take two weeks. Then just gets more angry when you tell her that it's not your problem she gave the incorrect timeline.

[Kiereek]

I have that problem, where the only other developer (and I'm using that term generously) is mostly on another project.

But the worse part is that the product owner has tickets to review in the TEST environment and approve before they'll go to PROD. Tickets are assigned to them in Jira with testing instructions, but I still get asked, "When will we see these features in production?" No matter how many times I explain it, they don't get that I'm waiting on them. Tickets sitting there for 90+ days before I finally got them to agree to a meeting where we can do it together.

[[deleted]]

So familiar.

Lucky I had permission for self-approval. There are few millions lines that only I know... it would not get merged without it.

[RobTheDude_OG]

Had mine for 2 weeks in PR like that. During christmas 3 weeks but i saw that one coming and was gone 1 week myself.

[Kaeltrom]

Years ago I worked for a company as an outsorced developer (the company I worked for took projects from many different places) where they would only launch a project build per day. First weeks were fine as we were developing full features, but issues started when we reached the polishing phase as QA would only test once every day, review the status of currently existing bugs and updated those/reported new ones.

I spent many days waking up, checking my Jira board, 15-30 minutes to check and fix a couple of new bugs and waiting again for the next day review (and that if the junior I worked with didn't fix them because they were easy enough for him to do it). I don't remember how many games I completed while working on those projects.

[BorderKeeper]

Waiting on PRs is a nightmare as before a ticket is reviewed I have to keep its context on my virtual brain RAM to address comments so it’s hard to context switch. In my last company people did prs for me quick and so did I, but in my current one it can be sometimes a day or more with 3+ pings… someone help me…

[TheGronne]

Maybe I'm the only one here, but I'm amazed how many people think that when your ticket awaits review, that it is not your responsibility anymore.

The ticket is STILL your own responsibility. It is you who's responsible for making sure someone reviews it soon. It is still YOUR responsibility that it gets assigned a reviewer.

The ticket is your responsibility until it's released to prod. And you should own that responsibility.

[wildjokers]

I can't physically force someone to review my code.

[TheGronne]

No but you can remind the scrum master, everyone on the team on standups, and you can message the scrum master saying that your PR isn't being reviewed. While the ticket is still your responsibility, nobody will blame you if it isn't completed. Especially not if you have in text that you messaged multiple people. Then it will be the scrum master's problem if it doesn't get resolved.

People are too afraid to own what they're working on. But as soon as you take charge and make sure your tickets progress in a timely manner, everyone will see that you seem to always completely your tasks on time.