What is it about programming that most programmers love? Creativity, problem-solving, analysis and critical thinking are just a few. However, when a senior developer explains to a junior, to the letter, how to implement something, we are taking away those great things about programming from the junior and we are taking away the opportunity for learning. But that doesn’t mean that we should give free rein to anyone in the team to implement solutions as they wish. It all depends on the level of the developer and the complexity of the problem/solution space.
The Quadrant
High Level Guidance, Room for Creativity and Failure
For most simple tasks that you assign to a junior developer, only high-level guidance is required with some possible web resources or similar solutions in other projects pointed out to them. You can leave them to get on with it and check in periodically to see what they have been doing. When you see problems, you can use lines of questioning to help them figure out what the problem is and with more lines of questions see if you can prompt them to figure out the solution by themselves. When they cannot figure it out themselves then it’s time to explain to them in detail the problem and the solution but with the aim of teaching first and solving their problem second.
At this level of complexity, not only does prescribing detailed solutions to junior developers limit their learning ability but it also makes the job less fun and being a programmer should be fun.
Programmers are usually highly motivated because it is an interesting, fun and challenging job. We should make sure that we protect the fun aspect of the work, cultivate the motivation and eagerness to learn and not destroy it through handing over detailed solution designs that leave no room for creativity.
Failing Leads to Learning
There’s nothing like failing code to prompt you to learn the fundamentals of the underlying technology. It is not uncommon for a junior to tell me sheepishly that they have wasted 5 hours on a problem that they were having but were able to overcome it in the end. They talk about frustration and are embarrassed by the time they took to figure it out. I tell them that these problems are gifts and we often learn more about a specific area than when everything is going well. So don’t get frustrated, cherish these opportunities. We as seniors should give enough freedom so they can have these experiences and learn.
Prescriptive Guidance, Pair Programming
Sometimes a detailed design needs to be provided to a junior, for example, when there are critical and complex aspects to a solution. One example would be that a complex concurrency model needs to be explained in detail to a junior without prior experience of concurrent programming. In my first job as a C++ developer I worked in a concurrent real-time trading system and I had no previous experience of concurrency, so my boss sat me down designed the solution on paper diagrammatically and explained exactly how I should develop the server program. But when he did this he explained every aspect of the design and how it avoided critical failure modes. Teaching me in this way really worked and I have taken my teachings from this job forward in my career, and I have had a good grasp of concurrency ever since. This is an example of an area where a junior won't be able to work it out by themselves and need a guiding hand to explain low-level concepts through a carefully crafted design.
Pair programming can be excellent in these scenarios. I have found that pair programming works best when a senior and a junior are coupled together. The junior gets hands on experience of coding something very complex and/or very critical and if done right, gets the opportunity to contribute.
Autonomy
Senior developers working on simple to medium complexity/critical code should be left to it. Having a culture of automated testing and QA should capture the problems that anyone is capable of and peer code reviews can also ensure the cleanliness of code and separation of concerns through good abstractions.
Debate and Peer Design
If the problem/solution space is pretty complex and/or pretty critical then it’s time to get people together to debate. There are multiple ways of doing this. The two main models I have used are Peer Design and One Designer, Peer review.
Peer Design is where you get developers in a room with a big whiteboard and you start discussing the problem and the potential solutions. Potential solutions are designed on the whiteboard together and evaluated as a group.
One Designer, Peer Review is where you give the design task to a single developer, or two developers separately and then review the design(s) as a peer group. The design can be iterated after each review but the main design work is carried out by a single developer. Personally I prefer this approach as I think that creativity flourishes best within a single mind. If that mind has been given the objective, the constraints and time then the result is often better thought out and cleaner by the time it gets to the review stage. Peer Design can work but it runs the risk of design by committee with a less innovative result, also powerful personalities can end up overriding others regardless of the quality of their technical insight.