Article summary
In my previous post, I championed a shift from pair programming to pair exploring during the critical Discovery Phase. Today, I want to get tactical. Depending on the experience levels of your pair, I’ve got some strategies to amp up your discovery game.
For the Seasoned Pair
As I explained in my previous post, the discovery phase is all about figuring out how you can do something. This is the phase when programmers might “spike” on a feature, write on the whiteboard a lot, or read documentation. Below are strategies to employ when both members of the pair are more senior developers. There are two main paradigms you’re likely to be working in: evaluating the merits of different abstractions or actively “spiking” on code to test the validity of an approach.
Dueling Whiteboards
This is the strategy to employ during the abstraction debates. This will be most effective if you actually have separate whiteboards to work on, so, figure that out first. Set a timer, no longer than 10 minutes, where each person privately outlines their vision for a solution on their whiteboard. Then, take turns presenting your conceptual sketches to each other—without interruption or debate.
After these individual pitches, compare notes, address discrepancies, and finally, merge the best elements into a unified diagram. If you like, you can do a second round of timed private whiteboarding after the first, to test how aligned you both are. This exercise not only fosters respect for differing viewpoints but also propels you toward a consensus that’s well-informed and mutually agreed upon.
If possible, bring in a third experienced developer to listen to each pitch, and then offer outside feedback or questions, before moving on to the work of unifying.
The Focused ‘Hackathon’
This strategy comes closest to traditional pair programming. First, list out the potential solutions you’d like to spike on, then pick one to prototype. Sit side by side, with one dev driving and the other navigating. The goal is to hammer out a quick, functional model to test its viability. Don’t strive for perfection; this is about feeling out the solution space. Don’t shy away from pseudo-code, or mocks.
Next, trade roles for the next solution on your list. Continue to switch pairing until all options have been explored, then deliberate on their merits based on your hands-on experience and the code you’ve produced. This approach will lead to a more practical and experiential understanding of your options.
For the Budding Duo
Doing discovery phase work as a pair of inexperienced developers can be a serious challenge, but it’s better to forge a path together than alone. In this scenario, there’s just one strategy I’d recommend.
Fill the Gaps
Lay out the problem clearly and openly discuss where each may lack understanding. Draft a list of burning questions to answer. If one of you knows something that fills a gap, take the time to explain — chances are, you’ll both come away with a better understanding.
After you’ve made an exhaustive list of things you think both of you need to understand before you can proceed, split up for focused research. Each of you should take a different question to answer. Keep it time-bound to one hour max. Don’t get caught up trying to fully grasp a complex subject, learning a new framework, etc. The goal here is a quick iterative process.
When your research block is done, reconvene and exchange your newfound insights. Most likely this will lead to new questions you need answered, or additional clarification on the previous topic. Add these to your list, rinse, and repeat. When your question list (and your brain) is exhausted, you’re ready to stride confidently toward the Implementation Phase.
For the May-December Pair
Having a mixed-experience pair is probably the most difficult setup for the discovery phase. It can too easily devolve into the senior developer doing all the work while the junior follows. Or giving the junior developer tasks to struggle with on their own while the senior gets the “real work” done. How can you effectively pair in an ill-defined environment with a large knowledge gap?
Guided Exploration
Here, the senior developer sets specific tasks that challenge the junior dev to the limits of their knowledge, encouraging them to lead the research and solution exploration. As the junior developer delves into potential solutions and technologies, the senior offers periodic guidance to keep project goals on track and highlight best practices. They may also engage in focused pair programming sessions, with the junior taking the reins on prototyping under the watchful eye of their more experienced counterpart.
I want to emphasize that unlike the Fill the Gaps strategy, the junior dev should spend little to no time working on their own. Even the process of knowledge acquisition, like reading documentation, should be overseen by the senior dev. A lot of good habits around how to find the “right” information can be developed here (and a lot of bad habits broken), and there’s always a chance that the senior dev learns something themselves along the way.
When it comes time to make decisions on the direction to pursue, both developers can collaborate, merging the fresh perspective of the junior with the seasoned judgment of the senior. This approach not only facilitates the discovery phase but also fosters a positive mentorship dynamic that enriches the development process.
Yes, this strategy can require significant patience from the senior developer. Don’t shy away! This is a valuable part of the technique. I’ve previously advocated the benefits of slowing down, and if there’s ever a time in a project to practice forbearance and not rush the process, it’s the discovery phase.
Simon Says
During this process, the more seasoned developer (our ‘Simon’) takes the lead in tackling a specific problem or task, while the junior developer starts in the role of an observer, attentively noting the thought process, problem-solving approaches, and exploratory techniques employed by their senior counterpart.
After a session where ‘Simon’ directs the show, roles transition. Now, the junior developer tries to replicate the previously observed work, attempting to mirror the strategies and decision-making approaches they’ve just learned. This creates a feedback-rich environment, where the junior can gain confidence in applying new methods, and the senior can gauge the efficacy of their mentorship based on how well their methods were replicated.
You should make an effort to truly start over from scratch. Erase the whiteboards, delete the code, and close the browser tabs. Yes, this can feel like a lot of extra time spent recreating something, but repetition is a powerful way to solidify knowledge. Retracing your steps often highlights mistakes you might have made the first time around. Through this Simon Says dynamic, knowledge is not just imparted but solidified and refined, ensuring that both developers exit the discovery phase with a mutually deepened understanding and readiness for the phases that follow. Practice makes perfect.
Are you ready to go exploring together?
Pair exploring isn’t just a practice; I think it’s a philosophy of both software development and creative collaboration. You’re attempting to leverage two minds to not just meet but exceed the capabilities of one. We’re pushing these efforts into the earliest, most dynamic, wildest territory of software development because that’s when you’re most likely to need someone else carrying a torch by your side. No matter your experience levels, I hope that these techniques ensure that, together, you can make the voyage through the discovery phase as insightful and rewarding as possible.
Do you have ideas for other pairing strategies you can use in the discovery phase? Please share them in the comments!