I took last week off as I focused on full papers from CHI, but this week’s edition of Pointer had several articles that caught my eye.
Five Code Review Antipatterns
Author: Trisha Gee
The anti-patterns are as follows:
- nit-picking, mostly about style (just use a goddamn autoformatter!)
- inconsistent feedback coming from multiple developers’ opinions. The answer to most design questions is “it depends,” they write, and these disagreements should happen elsewhere. Setting a consistent technical direction is hard.
- last-minute design changes, i.e., using code reviews as design reviews.
- “ping-pong reviews” where reviewers and authors go back and forth about changes to make and not to make. The author suggests being explicit about what it means for a code review to be “done,” and having someone (a senior dev, tech lead, or architect) responsible for making that decision.
- “ghost reviews” where someone (reviewer or author) stops responding.
What can your team do? Create a strong code review process. Define its goals, figure out who is involved, set acceptance criteria, and generally create more structure around code reviews instead of “a thing to do.”
This is a good list. Some teams I’ve been on have had this problem of code reviews being “code walks,” which are more of tours through the code. Or that code reviews wouldn’t have any kind of goal, so there’d be some changes but no leader setting a technical direction or vision.
How Our VP of Engineering Used Data to Support Our Engineering Team on a Human Level
Author: Hillary Nussbaum
This is a story about how a VP of Engineering was looking at “velocity metrics” (ugh)—primarily related to pull request throughput—and found that people were working more, but accomplishing less. The reason? A lack of context from switching to remote work.
Though the team was having regular remote meetings, developers still lacked the information they needed to do their work. “People didn’t have the same amount of context,” Ale found. “We used to rely on the fact that we were all together in the office so that if I had something to say, the person next to me would hear it…our team is small enough that usually, everyone on the team has context.”
That’s not suprising, but the interesting part of this article is what they did about it:
- Created systems for intentional public communication (i.e., Slack channels and having decisions logged in Jira)
- Leaning more heavily on documentation
- Writing down plans for the upcoming days and sharing them
- Fostering a culture of sharing
This is a very long article to describe how this organization figured out that they needed to overcommunicate to make up from the loss of in-person interactions, but here we are. It appears to be an advertisement for their “velocity metrics” product, surprise.
With that said, it’s not wrong. My team (all located in NY, with me being the lone member in Chicago) heavily increased their use of Slack and started daily standups to keep each other in the loop about what we’re all working on. The result is greatly increased collaboration and, for me being the formerly-only remote member, much more context about what everyone else is doing. Since I thrive on context, I have appreciated these changes.
The risks - know them - avoid them
Author: Erin Bromage, an immunologist at the University of Massachusetts Dartmouth
This article first makes the case for why blind optimism about COVID—that we’ve “reached the peak” and things will be fine from now—is terrible. There are two reasons for this:
Assuming we have just crested in deaths at 70k, it is possible that we lose another 70,000 people over the next 6 weeks as we come off that peak. That’s what’s going to happen with a lockdown.
As states reopen, and we give the virus more fuel, all bets are off. I understand the reasons for reopening the economy, but I’ve said before, if you don’t solve the biology, the economy won’t recover.
With all that said, the author goes on to describe what the risks are—yes, people spread it within their households, but where do those people get it from? The vast majority, the author claims, are from situations where people are confined indoors: restaurants, call centers, meat-packing plants, choir practice, or sports.
The principle, the author writes, is sufficient “viral exposure over an extended period of time.” Even when people were far away (the call center), the virus being sustained in the air for 8 hours is what caused such dramatic spread. Being far way doesn’t help you when you’re indoors with little airflow.
Outside, though, the story is different:
Social distancing rules are really to protect you with brief exposures or outdoor exposures. In these situations there is not enough time to achieve the infectious viral load when you are standing 6 feet apart or where wind and the infinite outdoor space for viral dilution reduces viral load. The effects of sunlight, heat, and humidity on viral survival, all serve to minimize the risk to everyone when outside.
The Developer Culture Test: What Defines Places Where Developers Thrive?
Author: Gergely Orosz
This is a blog post studying what makes predicts workplaces that have great developer cultures. The full post is worth reading, but the test itself:
Basics: Safety, fair compensation & common-sense flexiblity.
Psychological safety, a blameless culture, paying a fair rate, and being flexible with things like WFH are basics, and they’re foundational to everything that comes after this.
Clarity, Autonomy and Collaboration
- Understanding the “why”
- Backlog / roadmap and engineers contributing to it
- Direct communication in solving problems
- Cross-functional collaboration
- Celebrating taking initiatives
These have to do with integrating engineering into the larger organization (see Do you work at a tech company? by Will Larson). Understanding what the roadmap is, and being able to contribute to it, are key here. Having direct communication lines to other people—both devs and other roles—helps people to feel like they have a sense of ownership.
Sustainable Engineering Culture
- Functionally complete != ready for production
- Code reviews and testing
- CI and CD or developers deploying to production
- Healthy oncall
- Internal open source
The engineering culture makes sure that developers don’t burn out from awful oncall rotations or poor software practices. Missing most of this, the author argues, will make it difficult to hire anyone from true tech companies.
Career Progression
- Technical managers who build trust
- Career ladder
- Parallel IC & manager tracks
- A culture of feedback
- Investing in professional growth
People who are driven want to keep growing. Can senior developers grow into either managers or ICs? Is there a culture of people giving feedback to each other? Do people trust each other? (Feedback is something I greatly lack at my current job, and likely one of the biggest reasons I would choose to move on down the road.)
This was a great read. Thanks, Pointer, for pointing me to it, and to the Pragmatic Engineer blog for writing this out.