Very sorry you’re experiencing this! Except for last few things that sound especially uncomfortable, I was struggling with a similar situation a few months back... Unenthusiastic replies nor delaying them seemed to work, and even when clearly expressing that I didn’t feel comfortable sharing some information I would still receive long, animated responses and more random personal questions- which I couldn’t tell was out of obliviousness. I think most of the time I just wanted to tell them to stop but struggled to come up with a way to communicate it professional/assertively. 

My unhelpful response (mainly out of empathy!) is that I began to only give timely replies if it was code-related and if we absolutely had to converse I would not react much at all; just dry yes/no replies, no emotive reactions. And anytime the conversation felt like it was skewing into a topic that was not work-related/off-topic, I did my best to redirect us and ignore the invitation to go there. 

I remember this was an issue that really weighed on me for some months, so I can’t imagine how it might be for you. Hopefully there will be better answers after me and that you will not have to involve HR 🙏.

Junior Software Engineer at Series B Startup

Grace

A ticket a day sounds kind of stressful, I hope they are not all completely unrelated and touching various domains (but maybe this is normal and Idk how most dev teams work)! I struggled with this as well but to piggy-back off of previous great comments, perhaps a way to tackle this is planning ahead the design as much as possible.

My team has been using a 'Technical Design Document' per ticket, where we define in our own words the business needs and more importantly, formulate exactly what needs to be done; which areas of the code, which methods to modify or add, where it fits into the flow, how it affects existing logic, etc, how this will be tested. This has been monumental in getting tickets completed by or before the Sprint (story-pointing and estimating gets closer to accurate and consistent as an instinct for this naturally develops). Formerly, a lot of us just had tickets spilling over every Sprint and it felt like almost nothing was getting done.

When I first started writing my design docs, I felt like I was moving slower and that it was actually impeding my progress. However, what it was actually doing was forcing me to face all of my 'battles' earlier on rather than half-commit through the entire Sprint. (I have also realized that my procrastination is sometimes just out of fear of embarrassment/imposter syndrome! A lot of the scary bits for me has been reaching out to the right domain experts for clarity :P)

I can't remember which Masterclass/vid it was but recall Rahul quoting the SEAL motto, "slow is smooth, smooth is fast", and I think about it often.

It sounds like you have done many things in your power to resolve this issue. I have been on this boat before, (and it was excruciating when the reviews were waiting on senior or staff engs that were overburdened already), and I personally think it is worth bringing up to your managers. I do not regard it as “snitching”, (I guess you will have to word tactfully) esp since it affects team’s velocity and also reflects badly on your manager. Do you have a manager? (There were times when my team did not and my soul died a little bit each time this happened 🥲.)

Secondly, I noticed this idea from a colleague who @here’s the team on Slack, linking the PR and starting a Google Hangout so that they can explain the PR to urge reviews afterwards. Although, I am not sure how effective this will be for you given you actively bring it up during standup etc.

Series B Startup

Entry-Level Software Engineer

When a PR is dense and intimidating, I have found it helpful to set up a brief team meeting and have the author talk through it at a high level and answer questions, before submitting our individual reviews. 

Ps. I actually enjoy pulling their code to walk through specific areas myself :P