Out Of Scope - #2
The worst type of bug
Welcome Back!
Pop quiz! What’s the worst type of bug?
Well, from experience I would have to say stomach bug, which is how I spent most of this week down and out. After living in bubbles for 2 years, I guess we should all be prepared for our coddled immune systems to react strongly to anything they encounter now. Be careful out there!
… I still managed to emerge and get in a dig at Tesla fanbois though. I crave the drama.
The Case For Mob Reviewing
You’ve all heard of pair and mob programming but something we’ve been trying recently in our team is pair or mob reviewing.
I currently work on a platform team so our team reviews a lot of code that my immediate teammates didn’t write. It has been difficult to onboard newer members of the team (including me!) to the huge scope of all the different changes that come through our review queue. Our onboarding docs included a collection of past reviews as examples of “bad changes” that needed to be blocked in the past or caused outages. These are helpful but didn’t cover all of the everyday cases!
So what is mob reviewing? It’s exactly as it sounds, we schedule a weekly meeting where whoever can make it goes through our team review queue together. We’ve also tried to curate interesting or complex changes to each other, but this can be more time consuming, and sometimes the benign is helpful to chat about as well.
On my smaller team at work, there are only two engineers including myself (is two really a “team”? maybe a pair?). We build components used by other teams, so we get a lot of external contributions/changes to our code. If there are some larger or more complicated changes in our queue, we will schedule quick 5-10 minute meetings a la carte to chat through the changes and review together.
We don’t do this for reviewing each other’s code as often, but I think with the right attitudes (constructive and respectful, not attacking), it could work there too! Designers already do this with their synchronous design crits.
Why?
to knowledge share from teammates with more context to teammates with less context
to catch more potential issues when talking through changes
to onboard and level up new team members
to build confidence for all teammates for reviewing without context
to get reviews done in a timely manner
to connect the remote team
Does anyone do something similar? Would this work for your team? Do you do anything else unique to onboard new team members?
ICMYI
We talk about the hot engineering market most times as a good thing. You can quit your job and go get a better one! But we don’t talk often about the cost on the people left behind who aren’t quitting their jobs (and not everyone can or wants to).
Normal burnout as tickets pile up with fewer people to work on them
Morale and motivation hits as you see your teams shrinking and maybe feel under-compensated and undervalued
The burden of interviewing and onboarding new employees
Exhausting priority churn
Do you all have a weekly limit on interviews you do?
The hottest topic of the moment is the RTO (return to office).
I’m going to include some discussion next week about the RTO debate so please comment your hot takes (on both sides of the argument). Its important to note on every hot take of the debate - who benefits from this position? Most people I know including myself want remote flexibility, but are there any negatives to remote work?
I definitely do not miss the commute.
I love uses of tech for good.
That’s it folks!
Stay safe and healthy and see you next week!
Regarding the ICMYI section:
I couldn't agree more. I think it's happening more often than we think, we just don't talk enough about it. Thanks!