Could we remember to take a little time to review some code? The tickets have been accumulating in the review column for ages, but everyone’s working on something.

Could we be mindful about code quality and checking that things work? Lately, we’ve had more bugs in production.

Could we remember to release code to production more often? “Finished” work is not moving for days, and it gets stale.

We just need to make sure we don’t forget this time. Next time will be different, we have to be better.

A few weeks go by, the same issues reappear. Maybe for a short period of time, thanks to the reminder, we got better at it, but we eventually forget. The solution, again, is to not forget. We have to be better, we just need to make sure we don’t forget to do this thing that we forget to do all the time.

The purpose of a system is what it does.

If the thing the team wants to do it keeps forgetting to do, it’s not, usually, because the individual is bad or needs to get good, it’s because the team finds the alternative preferable, even if it has undesired outcomes. The alternative is what the system actually encourages doing.

The answer is not to ask to be better, to shame or blame, to keep reminding people. The real action is to first look at what’s happening and to go beyond the superficial issues to understand. Normally, there’s no single root cause. After understanding, we can look at changes to implement to actually try to address the situation.

Off-topic

Recently, I’ve discovered a podcast that has blown me away: You Are Not So Smart. So far, I’ve only listened to three episodes, but each has been great. The best one out of the three has been the one about pluralistic ignorance, which I’ll share below.

Pluralistic ignorance is that phenomenon when you think or feel you’re in the minority, but that in reality everyone feels.

When you feel that you must be the only one that doesn’t get it or the only person against something because no one else speaks out or asks questions, it’s more often than not, pluralistic ignorance.

This episode made me think about my experience in software and the situations where nobody says anything or are seemingly okay with things. That one time when in a meeting something didn’t make sense to me, but everyone else looked like they got it, but when I asked a clarifying question it was clear that I wasn’t alone. That time when I was proposing alternatives and nobody supported them, but privately some of them agreed with them (here we can also look into psychological safety).

In the episode, we can see that a simple way to fight pluralistic ignorance is to make everyone know what everyone really feels and thinks. To make people reveal their true thoughts and feelings, they have to be able to feel safe about it. When we divulge the information (making it anonymous, without revealing who said what) people can safely change their public opinion.

Moreover, we can take it upon ourselves to be the ones to say what we think and feel, and many times we might find that it has an impact. Although it’s not an easy thing to do, it comes at a personal risk.

I wonder if this information is something that can be used in teams, maybe via anonymous surveys that gauge people’s feelings and thoughts after a meeting, for example. The episode makes me more aware of the possibility that I might not be the only one that feels in the minority sometimes, and that it might be worth it to open up.

Interesting links

• Please Don’t Fake It Till You Make It: On the Need for Confidence, Honesty, & Integrity in Software Development by Kristen Foster-Marks

• How techies missed what’s wrong with Horizon, how that led to multiple deaths, and what can we learn from it all?, by Andras Gerlits

• Since there have been issues with 2024 being a leap year, check some falsehoods programmers believe about time and names.