Many of us are familiar with rubber duck debugging or rubberducking. It is a way to debug a problem by talking through it at a low level, usually to someone unfamiliar with the situation or systems involved. Slowing down and discussing the issue leads to a solution or an alternative idea suggested by the other person.

At work, my manager, Kaynen, and I created a new methodology for helping engineers make decisions called Jiminy Cricketing.

What in the world is Jiminy Cricketing?

The term comes from the story of Pinocchio, where Jiminy Cricket serves as Pinocchio's conscience. Jiminy guides him toward making the right decisions and avoiding temptation. Jiminy Cricketing is a process where developers talk through a problem and its implications with a peer, similar to rubber duck debugging, to avoid cutting corners and making appropriate decisions. It is about engineering managers (and product or project managers) being open and available for communication to encourage developers to consider the implications of their work and make decisions that align with their values and principles.

Imagine you are a developer working and encountering a problem with larger implications than in the scope of the ticket. Instead of making a snap decision or feeling forced to make one yourself, take a step back and talk through the situation with a peer. Ask someone else to help be your conscience to make the best decision possible. 

• The process isn't well defined here; which direction should we take?
• This code may have security concerns; should we escalate it to the security team?
• Our continuous integration system has an outage; the tests pass on my machine. Should we merge it anyway?

The world of software engineering is moving faster and faster. Each decision eats away at our reserve of willpower. We can reinforce that willpower by leveraging others in our decision-making. The goal is to avoid cutting corners and ensure ethical decisions are made.

Building a collaborative culture in your teams

A benefit of Jiminy-Cricketing is that it fosters a culture of collaboration and communication within teams. When developers take the time to talk through complicated decisions and their implications, they can gain insights and perspectives from their peers that they might not have considered on their own. This can lead to better decisions and solutions for the project as a whole.

This may not be something new or revolutionary. Maybe this is just how it should work. Software engineers must feel they can ask their managers for this direction, someone to lean on. Unfortunately, I have experienced organizations where this isn't the case throughout my previous history consulting. Some may see this as delegating a decision to someone above you. It is, but it isn't.

I hope you find ways to make yourself available and be someone's Jiminy.