See One, Do One, Teach One
In the medical industry there is a common practice among surgical students learning a new procedure which is “see one, do one, teach one”. Seeing one allows the students to study from another experienced surgeon, ask questions, and take notes completely focused on learning from a teacher. Doing one enforces the application of the learned material allowing for physical practice with guidance from a teacher on the best practices. Finally in teaching one you learn to explain what you did to another and relearn and reinforce the steps of a procedure.
Software development, like surgery, cannot be reduced to a set of definite steps. While possibly more reductionist than medical procedures software development does require thinking and reaction to changing requirements, technical issues, and overall abstract thought. A change to one part of a system can have ramifications on other parts. Bugs can arise from the smallest of oversights. Services can fail for seemingly unknown reasons. All require a developer to be able to build and understand systems without hand holding if a company is to be effective.
As I’ve moved up throughout my career I’ve often found this “see one, do one, teach one” methodology work fairly well. First I will take one or two tickets to do a pairing session with a junior developer. The first ticket is typically me doing most of the work while they watch and engage me with questions and allows me to explain what I’m doing. The second ticket is mostly done by them writing and me watching. In some cases I’ll create the scaffolding and unit tests so they can focus on the code. Then they get to do one on their own with no supervision. This is then a great opportunity for them to struggle and learn while teaching them to reach for resources and ask questions. Ultimately a code review will give them more feedback and visibility. This “do one” cycle slowly evolves into regular development unless they are struggling, in which case they may need to “see one” again. Finally they get to teach, this will help them reinforce what they have learned and create connections with others within the team.
I’m beginning to realize that this practice can go beyond development. I can’t be the only one guiding new hires through a process and teaching them. If so they only establish connections with me, what I need is for them to establish connections with others. I can’t be the only one creating work and breaking down tickets. I need to show others how to do that as well. I need to become more “eyes on, hands off” in my approach to everything so others can feel empowered to do the work. After all after a surgeon teaches a student they don’t follow them around for the rest of their lives giving them feedback. What stems from this line of thinking is helping mold developers into independent thinkers. By micromanaging their work, holding their hand, and feeding them tasks you are reducing them into cogs in a larger machine. A machine cannot adapt itself to change. What we need is an organism that can evolve, grow, and learn.
Personally I’m always reflecting on my views, beliefs, and thoughts (on work and personally). This has given me a lot of joy and success thus far. What I want to do is teach others to do the same. Question, think, grow by seeing, doing, and teaching.