Your Coding Workflow as a Teaching Tool

Part of my path as a software developer is to coach other software developers. One of the biggest challenges I find with coaching developers, especially junior developers, is where to start the conversation about development workflow.

I feel that a person’s workflow is a very personal thing that gets developed and refined by constant practice and reflection on how to be more efficient. Most junior developers tend to have a somewhat erratic workflow because they are at the very beginning of learning what works for them. It is similar to a baby learning to walk. If you watch babies work to figure out walking, you will see that they navigate going from crawling to walking at different rates and in different ways. After some trial and error, they get it all figured out and then are off to the races. I find that since I’ve been writing software for 15+ years I struggle to offer much in the way of help because I can’t personally remember how I got from crawling to walking to running with respect to my development workflow.

In the absence of a common ground, I have started to use my own development workflow as a starting point for the session. I turn each session into a mini project inception by asking the person I am working with to describe the problem we are trying to solve just like I would do when working with a product owner. This allows me to understand the details of the problem and it allows the other person to experience what questions I ask when trying to analyze/decompose a problem. It also gives the person a chance to practice verbalizing and understanding the problem they are trying to solve. I find that these two skills are very important to have as a software developer because most of what we do it taking big business problems and breaking them up into smaller problems that we can tell the computer to solve on our behalf.

The next step is working through the problem via pair programming while I explain to them both the “what” and the “why” of each step that I take. This gives them a chance to experience a flow that I know works for solving problems and gives them the chance to ask clarifying questions in real time using examples from the pairing session. During this process they can begin to use the “whys” to inform their own decisions about how to integrate the session into their workflow. The understanding here is that my flow works for me and may or may not work for them. It is up to them to figure out what parts they want to keep and what parts they want to ignore. It also gives me a chance to get some real time feedback on my flow so I can further refine it to help my evolution as a software developer.

Your workflow exists because you find it efficient for translating business requirements into working code. You are being approached as a coach because others see value in that and want to learn from it. Sharing both the mechanical details and the reasoning behind the details gives others an opportunity to integrate and internalize the details as they refine their workflow. According to *The Talent Code* by Daniel Coyle, imitation is a powerful way to learn a new skill. Sharing your development flow gives the other person an opportunity to use imitation to their understanding the skill of software development. It also gives you an opportunity to get real time feedback on your process to help you grow as a developer.