The consultant set up in a central conference room, connecting her LLM model to a network of computers. Curiosity piqued, a software engineer asked what she was doing.

"I'm working on a unique LLM model," the consultant explained, her eyes twinkling. "It has incredible potential, but it could use some fine-tuning from different areas of expertise within this company."

Intrigued, the software engineer offered some insights from his coding experience. The consultant gratefully accepted, and together they worked on the model.

Word spread quickly, and others came to see what was happening. Each time, the consultant explained the potential of the LLM and how it could benefit from various contributions. A product manager provided strategic direction, a UX designer offered insights into user interaction, a data scientist shared statistical models, and a quality assurance specialist helped with testing protocols.

As they worked together, the model evolved into something extraordinary. It was no longer just an LLM model; it became a symbol of interdisciplinary collaboration within the company, yielding results no one could have achieved in isolation.

Finally, the LLM was complete, a state-of-the-art tool that revolutionized many aspects of the product. The company was astonished to see what they had created together from a simple idea and their collective expertise.

As the consultant completed her engagement, she left behind not just a technological marvel but a company transformed by the spirit of collaboration and innovation.

Tell me what you thought of the story in the comments below! 👇👇👇

But is it different? To cut through the noise, I decided to try it out for myself, with a focus on AI co-creation.

Antikythera Iterations is a new section on Coder Spikes for sharing these experiences with you. It's about sharing the creative output as well as the path I take to get there, and my thoughts on the process. The priority, however, is to share and get feedback on the creation itself.

Why? If the creation doesn’t resonate with you, then it doesn’t matter how I got there or what I have to say about it.

So let’s see where this takes us, shall we?

Share your thoughts in the comments below! 👇👇👇

Earlier this month, we hosted Global Day of Coderetreat (GDCR) at our Toronto office. After a three-year hiatus from hosting, we wanted to re-awaken some of the community enthusiasm we witnessed when we hosted here for the first time in 2019. Consequently, we planned for a larger event this year. I’m thrilled to say that we nearly doubled our attendee count, going from 27 in 2019 to 45 this year.

In this article, I’ll cover how we scaled the workshop from one that typically involves under 20 participants to one that can handle three times that number. I hope that this will give you some ideas about hosting coderetreats in your tech communities, especially if you are concerned about the happy problem of a large turnout!

Partner with a passionate co-organizer

Four months out

Before you go down the path of planning Global Day of Coderetreat, I recommend partnering with someone who shares your enthusiasm for the event and its underlying purpose (to nurture software development skills in your community). This way, if you have weeks where you’re bogged down with competing responsibilities, you’ll have a partner to keep the event-planning momentum going.

It’s also important to establish a shared understanding with your co-organizer on how decisions on the event are reached. Will you both agree on everything together, will one of you get the final say, or will it depend on what you’re deciding on? Once you’ve established this with your co-organizer, the two of you will need to decide how you intend to leverage the broader set of event volunteers, including the facilitators who will be instrumental in the event’s success. For example, when planning this year’s event, my co-organizer and I consulted heavily with the facilitators on the workshop programming.

Delegate event planning unrelated to workshop programming to an independent volunteer team

Three-and-a-half months out

Having said that, it’s important that you make the best use of every volunteer’s time. For us, that meant only consulting with the facilitators on workshop programming, while non-specific event planning decisions, such as catering, were largely delegated to an independent volunteering team. Everyone was informed on what was being decided, however. This way, anyone could chime in on any proposal before it was committed to.

For example, coderetreat has a “no pizza rule.” This is something that may not be known by all volunteers, especially those new to organizing one, so it’s important that all key decisions are visible to both the facilitators and volunteers. In particular, this includes the dates when these decisions need to be “locked in” so everyone understands what can and can’t be changed.

Send out a call for facilitators

Three months out

As with any event, the success of coderetreat hinges on its attendees. Further, as a technical workshop, the quality of the experience is directly related to the number of qualified facilitators one can secure for the event. Therefore, the first action we took was to send out a “call for facilitators”. Even before creating a registration form for the event, we called on our personal, closed and public networks for people interested in facilitating it. These included:

1. Past colleagues that we worked with and facilitated past coderetreats

2. The online software crafters community, and

3. Social media (predominantly LinkedIn and Twitter)

Concretely, we asked people to fill out a form which collected the following information:

1. Interest in facilitating (or, failing that, interest in participating)

2. Preferred event dates (GDCR can be hosted on either a Friday or a Saturday, so we set a date that would allow for the highest number of facilitators to attend)

3. Preferred hosting method (in-person or virtual)

4. Past facilitator experience

5. Their email address for follow-ups

We followed up with everyone interested. While it’s theoretically impossible to have too many facilitators, we wanted to ensure they were sufficiently experienced in coderetreat. A common recommendation is to consider a facilitator sufficiently experienced if they have attended at least one coderetreat. Fortunately, we had a level of interest which allowed us to set this as the baseline.

Once we had a sense of how many facilitators we’d have for the workshop, we could decide the number of participants, as well as how to structure the workshop activities to best leverage the facilitators’ expertise.

Differentiate the event and target optimal participants

Two-and-a-half months out

We are still seeing the societal impact of the COVID-19 pandemic. In particular, in-person events in tech are far less popular and common than they used to be. Consequently, much of the interest, attention, and discussion online is around online events. In fact, it’s common for people to assume your event is online unless you explicitly specify that it’s happening in person.

This reduced demand for in-person events does come with a silver lining: there is a corresponding reduced supply. This means that it’s easier to differentiate your event from others, and getting the word out can be comparatively easier. In our case, we were the only in-person coderetreat in Canada that day, and there were only a couple of other tech events happening in Toronto that month.

Nonetheless, getting attendees for an in-person event on a weekend is no easy task. We thought about ideal personas to target for a day-long, hands-on coding workshop. Who would be willing, even eager, to give up their Saturday for such an event? After considering this, we targeted recent bootcamp grads and university students. Once we got in touch with the relevant individuals and had a chance to discuss it with them over a video call, they then reached out via their internal networks to promote the event for us. This strategy helped us boost in-person attendance by about 20%!

Intermittently remind both the registrants and the public about the event

Two months out

Here’s a truism worth stating: the most likely people to attend your event are those who have already registered for it!

Therefore we reached out periodically to our registrants via email, suggesting that they tell their friends and sharing reading material with them to get them familiar with and excited about the event. As a bonus, this reminded them about the event, which prevented them from making conflicting plans accidentally.

We were also very lucky to have highly supportive event organizers at our company who shared the event internally and encouraged everyone at the company to promote the event on social media. By far, LinkedIn helped drive most of our attendees, so this was a critical piece of our promotion strategy.

Begin planning the workshop programming

One month out

We began planning the workshop programming only one month out from the event. We were tempted to begin planning this earlier. Waiting, however, meant that we had a much clearer idea of the number of attendees to expect. This allowed us to plan session activities that worked well for the anticipated size of the event. It also meant that the programming stayed fresh in the facilitators’ minds as they were looped in on it only a few weeks before the event itself.

There is ample precedent around how to organize a day-long in-person coderetreat. A default structure as well as common activities, can all be found on coderetreat.org’s Facilitation Guide. If you’ve never organized a coderetreat before, there is plenty of support via that resource, as well as the complementary Software Crafters Slack community.

Conduct an on-location dry-run of the event

One week out

A dry-run or dress rehearsal of the event is absolutely critical. Try as we might, there is no way to visualize everything that can go wrong ahead of time. And in truth, a dry-run doesn’t guarantee this either. It does drastically reduce the number of things that can go wrong, however.

In our case, we conducted a dry-run the day before the event. We could do so as we were already quite familiar with the event space (it being our office, after all). Some aspects that came up included seating position relative to the projector screen, slide size, and anticipating how traffic will flow over the course of the day. It also gave the facilitators a chance to gain a much more concrete feel of what to expect on the event day.

Wrap-up

Hope this write-up helps you plan for your next coderetreat. In regards to deciding what to plan, at which point, use the principle of the last responsible moment to ensure you are maximizing your options while making the best use of everyone’s time. At the same time, remember to plan early and to not turn down help while also channelling that help appropriately. Pair up with a co-organizer and limit decision-making to the two of you while consulting with the wider group of volunteers. If needed, make it explicit that while you can’t promise to agree on everything, you can promise to hear everyone out.

In a follow-up post, we will share more about the event itself: what went well, what we learned, and what we’d like to experiment with at the next coderetreat we organize. Stay tuned!

Why Learning Archetypes

On the one hand, labels can hold us back. They come with expectations on what we can and can’t do, or what we know and don’t know. Those expectations can be self-inflicted, or put on us by others. This is especially true of job titles. Some examples:

• “It’s been years since I’ve coded, and as a Manager, I don’t really do that anymore”

• “Let’s ask them — they’re a Senior Software Developer, so they should know the answer”

This is why at a Coderetreat, we say that we leave our job titles at the door. For similar reasons, we delete our code at the end of a Coderetreat pairing session. Pre-existing notions, assumptions, or expectations oftentimes hold us back from learning — consequently, we discard them when possible.

On the other hand, labels can help us focus. They can help us set our intentions. Who am I showing up as? What do I hope to get out of the day, and how will I do it? This is why we are introducing Learning Archetypes this year.

The Learning Archetypes

Here’s an explanation of each archetype — what it means, and when you might choose to adopt it.

Explorer

By choosing Explorer, you are acknowledging that you know little about Coderetreat and the topics it covers. You are embracing a beginner’s mind (Shoshin), surrendering any preconceived notions you may have — not just about the subject matter at hand, but about related topics as well.

For example, you have experience in software design but have never heard of the Four Rules of Simple Design. Approaching the latter as an Explorer means that you are prepared to question any assumptions about software design that you come in with.

On a deeper level, Shoshin means that you are surrendering part of who you are; namely, as it relates to being knowledgeable in a certain topic. While this can be the hardest part of the Explorer archetype, it can be the most rewarding.

Sharpener

By choosing Sharpener, you have enough of a familiarity of the subject matter to work on mastering an element of it. By analogy: you know what an axe is, what it’s used for, and how to use it — you’re here to practise chopping wood.

For example, you have already attended a Coderetreat before, or have practised code katas. However, you may have only done so alone, or with a limited group of peers (for example, co-workers at your company). You’re here to apply deliberate practice while gaining fresh perspectives by working with other like-minded individuals.

Teacher

Choosing Teacher means that you are here to teach! This one’s pretty obvious. Having said that, it is still a learning archetype, so you are teaching with the intention of further solidifying your own understanding. This could mean exposing any inconsistencies in your own mental models. It could also mean expanding your vocabulary and gaining confidence in your ability to explain complex, nuanced concepts. In-and-of-itself, teaching is most importantly a skill with many elements, including the ability to listen and adapt to the student. This learning archetype provides you with the opportunity to further practise these skills.

Having some experience in the practices of Pair Programming, TDD, and Simple Design is expected if you choose this archetype.

New Hat / Seasoned Hat

Each of the three Learning Archetypes come in two varieties: “New” and “Seasoned”. Each variety can be thought of as choosing a hat to wear for the day.

A “new hat” is one that you’re not used to wearing. It might be the first time that you’re trying it on, or it might be one that’s still uncomfortable. Why would you wear a new hat? Analogy aside, why would you choose a Learning Archetype that you’re not familiar with? Because the day is about learning, and learning means exploring, experimenting, and moving outside of your comfort zone.

On the other hand, a “seasoned hat” is one that you’re comfortable wearing. You can be a Seasoned Teacher if coaching and mentoring come naturally to you. You can be a Seasoned Explorer if you spend most of your days researching and learning new practices, technologies, and frameworks. You can be a Seasoned Sharpener if you frequently attend Coderetreats and practise code katas. Wearing your “seasoned hat” means that you can go deep on the learning that is found within that archetype.

Multiple Learning Archetypes

Can you take on more than one archetype? Absolutely! However, to give some focus to your intention for the day, we recommend adopting no more than two Learning Archetypes.

Conclusion

Learning Archetypes are a tool you can choose to use to focus your learning for the day, and help set learning goals with your pairing partner. Choosing a Learning Archetype is meant to deepen your learning, not stand in the way of it. If you find that your archetype is doing the latter, feel free to abandon it in favour of a different one, or no archetype at all.

The point of the day is learning, and as Coderetreat facilitators, we are here to support you in that endeavour.

RSVP here for Toronto’s Global Day of Coderetreat. We still have some spots, though they’re filling quickly!

In November of 2019, Connected had the honour of hosting Global Day of Coderetreat (GDCR) in Toronto. Twenty-seven passionate professionals showed up, coded together, and left. No one left with any newly-written code (having intentionally deleted it), but many left with new skills, fresh perspectives, and meaningful connections.

While Global Day of Coderetreat has been happening for a decade now, the practice of coderetreat itself predates this. The release of The Pragmatic Programmer in 1999 is generally attributed to igniting the Software Crafter movement, which in turn led to the practice of coderetreat. Recognizing its importance, a group of software professionals (including Corey Haines) organized a global coderetreat in 2009. As they say, the rest is history.

While on the one hand many technologies date themselves quickly, the language-agnostic practice of coderetreat is no less relevant now than it was in the ‘00s, if not more so. In fact, software engineering needs this practice now more than ever. As the profession has grown, so have the codebases. The pressure and urgency to deliver additional features and capabilities is incessant. Room for refactoring and redesign is rare. In our race to deliver “working” software, our technical craft has fallen by the wayside.

Theory vs. Practice in Software

A successful Software Engineer possesses both skills and knowledge, which in turn require both theory and its application (practice). To understand the distinction between the two, let’s start with an analogy.

When it comes to getting a driver’s license in Canada, the courses available have two main components: a theory (in-class) component and a practical one. The practical one means that the student drives a real car (under the close supervision and guidance of an instructor). For good reason, both course components are mandatory for graduation. What does a mismatch of knowledge and skills look like? Perhaps like a habitual highway driver having a go at the Nürburgring.

Similarly, an emphasis on practice exists in software engineering. Over the past 20 years, we’ve seen universities adopt co-op programs for their software engineering degrees. Around the time I was applying for university, there was only one school in Canada that offered a co-op program as an optional stream. Now, the vast majority of institutions include this as a mandatory component of their curriculum.

Once a new graduate enters the workforce, however, it’s largely up to them to continue to grow both their knowledge and skills.

Relatively speaking, acquiring knowledge is the easy part. Today, access to technical knowledge is unprecedented. By using Google in conjunction with a plethora of resource websites such as Stack Overflow, Software Engineers often find the answer to their technical problem in a matter of seconds. The use of web search to find technical solutions is normal and even expected within the profession.

On the other hand, systematic approaches for developing practical skills are less clear for Software Engineers. Many often seek out interesting work that challenges them, which is an indication that a fair amount of practical skill building happens “on-the-job.” On the other hand, some engineers may “hack” on a side project from home and build skills that way.

These are both good options, but they both measure learning progress the same way: the amount of completed working software.

Measuring Learning

Agile organizations focus on delivering working software, sprint over sprint. Agile teams optimize for velocity. Engineers are conditioned to measure progress by how much working software they write. Even the times we set aside for learning, we use “working software” as our measuring stick.

Current software management processes, such as Modern Agile and Scrum, emphasize delivery of business value (usually via features) to the end user. This becomes the measure of a team’s success.

We use the “value delivery” (or “problem solving”) lens to evaluate our learning progress. This is not surprising given that the second Agile value emphasizes shipping working software. While this approach may be appropriate for building a software product, it is a fundamentally flawed way of cultivating our learning.

Software Engineers have become victims of their own success; many of us embody the value of shipping working software so deeply that we use it as a measure of learning progress. We’ve conditioned ourselves to only recognize learning if we have some working code to show for it.

This manner of “on the job” learning is incidental practice. Solely relying on this as a means of learning can be detrimental to our careers in the long term. Setting aside time for deliberate practice means setting aside time that is optimized for learning, as opposed to delivering working software.

The Value of Deliberate Practice

While shipping working software is rewarding, it has serious shortcomings when it comes to being the only method by which we build our practice of writing software. Over my career, I have seen codebases across multiple companies that contain the relics of past learnings in the form of defunct frontend frameworks, misapplied design patterns, and swaths of irrelevant test suites. These do not belong in the codebase, yet persist there as no time is allocated for their removal.

This idea of a separate “space” set aside for and dedicated to learning is not just found in the field of software engineering. In his TED talk, Eduardo Briceño talks about two “zones” of working: a performance zone and a learning zone. He talks about how professionals ranging from ancient orators to modern entertainers work in these two distinct zones—one optimized for performing, while the other is optimized for learning.

A key aspect of the learning zone is a safe environment to fail, because failure is a key part of learning experientially. What could this look like for Software Engineers?

The Value of Coderetreat

Coderetreat is a Software Engineer’s learning zone. It is a time and space set aside where we can retreat from our regular approach to work and fundamentally shift our mindset away from shipping software and towards levelling up our practice. There are a few key characteristics of coderetreat that optimizes it for learning and helps emphasize deliberate practice.

Coderetreat Characteristics

The Structure

Typically, coderetreats are day-long workshops split into multiple sessions (ranging anywhere from four to seven). Each session is an hour long; within this time a few minutes are reserved for an introduction, while at least ten minutes are reserved at the end for a retrospective. Most of the session is reserved for pair programming.

This structure is effective for a number of reasons. First, an entire day affords us ample time to “go deep.” This means carefully exploring rich concepts such as inversion of control, or getting really adept at using a specific tool such as IDE keyboard shortcuts for refactoring.

Second, multiple sessions provide us an opportunity to “reset” after each one and start fresh. We can approach each session with a beginner’s mind, as opposed to being weighed down with biases, preconceptions, and limitations from the last session. This may mean working on a fresh problem altogether, or with a new pairing partner. However, it always means deleting your code.

Deleting the Code

We delete the code at the end of each session. This un-trains us from using working software as a measure of learning progress. To put it another way, we are far less likely to focus on completing the problem if the solution will end up being discarded anyway.

Deleting the code also puts an emphasis on building skills over knowledge. By rewriting the code from scratch, we are working on the practice of writing code, versus capturing knowledge in the form of code. Of course, this is meant to be applied within reason—use of boilerplate code in the form of a running application and executing test suite is completely acceptable.

Nonetheless, the allure of keeping the code around for future reference can be irresistable. Keeping us honest is one of the many ways our pairing partner can help.

Pair Programming

The knowledge half-life of Software Engineers typically ranges from three to five years. Staying up-to-date on the latest approaches, technologies, paradigms, and frameworks is therefore critical. This ultimately means being open to fresh perspectives.

Pair programming at coderetreat helps practitioners to gain fresh perspectives by working with industry professionals that we typically do not get to work with at our regular jobs.

Furthermore, pair programming keeps our learning salient and valid. Pairing with another Software Engineer is like a real-time audit of our thought process. Any biases can be immediately challenged by the partner. This either crystallizes our understanding of the opinions we hold, or it shatters them so that they can be reconstituted from scratch with an updated outlook.

Our pair is also our accountability partner. They ensure that we stay on track towards our learning goals of the session, and help us avoid going down “rabbit holes.” For example, if a pair sees that we are spending too much time on the setup of our development environment, they can call this out and suggest an alternative approach—such as searching for a repo that contains a boilerplate solution.

A great pairing experience at a coderetreat means that each pair member shares their learnings with the other in real time. Once the session ends, the pair has an opportunity to share their learnings with the wider group at a learning retrospective.

Learning Retrospectives

Multiple sessions in a coderetreat enable us to collect and apply feedback so that our learning is continually optimized session over session. The retrospective plays a critical part in achieving these optimizations. These retros happen at the end of every coderetreat session.

Generally, the purpose of a retrospective is to reflect on the past iteration of work and determine what went well, and what didn’t. In a coderetreat learning retrospective, we reflect on and share our learnings and how we achieved them. This inspires others to not only pursue discovered tidbits of knowledge (such as a new code library), but also to adopt tactics that worked effectively for other pairs (such as adopting ping-pong pairing to maintain a consistent TDD workflow).

Why Software Engineering needs more coderetreats

All of this works together to level up the abilities of Software Engineers that attend coderetreats. Below are the four key ways that coderetreats support this levelling up:

1. Focus on deliberate practice over searchable knowledge

Access to knowledge for practicing Software Engineers is unprecedented. Solutions to common problems can be found in a manner of seconds. However, this is only part of what makes great Software Engineers. The prevalence of knowledge has led to an erosion of people’s made skills. Coderetreat allows us to overcome this by providing a space for deliberate practice.

2. Priority on learning over solving a problem

Modern software methodologies have conditioned us to measure our learning based on how much working code we write. Learning doesn’t necessarily happen this way; we often learn by breaking code. Coderetreat helps us discover ways to optimize learning as opposed to software delivery.

3. Dedicated time to improve our craft, as opposed to training on the job

On-the-job training is shallow and precarious. We learn just enough to accomplish the problem at hand, and apply solutions we don’t fully understand to production code. Coderetreat offers us the opportunity to truly grok the approach or solution that we’ve chosen.

4. Gaining fresh perspectives over reinforcing existing intuitions

Our intuition can be wrong. We challenge it by working (actually coding) with fellow industry professionals we don’t normally work with. Coderetreat is a place where we don’t just meet, but also write software with people who can challenge us and help us grow professionally.

Final Thoughts

In the ultra-competitive world of software engineering, it’s essential that those of us who seek to build better products and drive impact to end users continue to seek new and improved ways of working.

My hope is that this piece might inspire you to either attend or organize a coderetreat in your community or organization. Global Day of Coderetreat is a great way to get started, though it only happens once a year. Fortunately, Connected is hosting Toronto’s Global Day of Coderetreat on November 5th this year — RSVP here for the event!

Woody Zuill is known for discovering Mob Programming (or simply, “mobbing”). In one of his talks, he details its relation to Flow. First, he distinguishes Lean Flow, Individual Flow, and Team Flow as distinct concepts. Lean Flow is thought of as the process of minimizing work-in-progress (also referred to as inventory) through the reduction of queue times caused by blockers and dependencies (for example, waiting on a designer to approve a UI revision that’s uncovered during implementation).

Individual and Team Flow, on the other hand, stem from Mihaly Csikszentmihalyi’s definition of Flow that we had covered at length in the prior post. See the excerpt below from the talk in question:

Woody asserts that his team is indeed able to get into a flow state. If Flow is possible when mobbing, could it be achievable when pairing as well? And do these flow states feel different from the classical flow states achieved when working alone?

It turns out that there are common characteristics around Flow that Csikszentmihalyi explains in depth. These hold true no matter how varied the activity or domain — whether it’s a parent teaching their toddler about the world, or a surgeon performing an operation on a patient (both of these are examples taken from Csikszentmihalyi’s book).

Let’s revisit the four conditions of Flow that were covered in the last post, and relate them to the pair programming experience.

Four Conditions of Flow

The four conditions of Flow are what enable a flow state to be both entered into and sustained. Practising pair programming effectively is not easy — in prior posts, I have described at various ways in which pair programming can go awry and how adhering to prescribed pairing styles such as ping-pong and strong-style can help maintain the effectiveness of pairing. Here, I’ll describe how Csikszentmihalyi’s model for Flow can help improve the effectiveness of pair programming, regardless of the particular pairing style being used.

A Challenge Requiring Skills

Challenging ourselves while solo coding is typically straightforward. Product teams that employ a scatter-gather strategy for completing the work have this figured out. Team members pick work at the right challenge for themselves off the backlog. For example, less experienced coders will leave the harder tickets for the more senior members of the team to tackle.

But how does this work with a team that pairs continuously? What if a junior who is anchoring a relatively straightforward ticket is paired up with a senior? How does the senior ensure that they’re being sufficiently challenged?

One way to achieve this is for the senior to take a coaching stance. For example, the pair may start in Driver-Navigator with the junior driving. The senior then takes copious notes not just about, for example, “how might we improve this codebase” but also, “what feedback can I provide to this junior engineer to help accelerate advancement in their skills?”

At the next pairing break, the Navigator shares their notes and the pair discuss. Should they try a more ambitious refactoring and see where it goes? Even if it’s thrown away, the junior will have gained valuable experience in how a comprehension refactoring is performed. Or, the senior shares feedback on how the junior can be more effective. This could be sharing keyboard shortcuts and strategies for learning them quickly, or tips on how to change code more incrementally, AKA “baby steps”.

In summary, ensuring the work is challenging for a pair is a much taller order than for a soloist. Nevertheless it is not only possible but critical if the team recognizes the importance of up-skilling its more junior members.

Conditions for Focus

At first blush, “conditions for focus” seems easy to achieve in the age of remote work. If we are fortunate enough to be able to work from a secluded spot in our home, there’s no manager to come by and tap us on the shoulder to ask us for that “five minute favour”. We are arguably in much better control of stymieing distractions such as these. Even with plenty of virtual means of being reached, we can easily switch them off — as examples, we can simply close our email client or snooze our Slack notifications.

Paradoxically, the challenge in achieving “conditions for focus” can arise when we plan for longer pairing sessions. Namely, the challenge of actually having the pairing session happen in the first place. For a few reasons, I have noticed that blocking off anything longer than one hour for pairing dramatically drops the likelihood that the session happens. For one, there is the challenge of finding calendar availability with your pairing partner. The other challenge — unspoken yet insidious — is the lack of appetite for long pairing sessions. The reality is that most find the thought of a multi-hour pairing session daunting and debilitating. And that’s assuming that both pairing participants plan to challenge themselves at the session. If that prerequisite isn’t met, it’s easy for the senior to use the excuse that they simply don’t have that much time in their day available — they need time to “be productive”.

To overcome this, I typically aim for one-hour pairing sessions. If it’s possible to book a longer pairing session, I plan for multiple 25-minute sessions with 5-minute breaks in between each, making that plan clear to my pairing partner.1 These 5-minutes are used to either check-out completely or perform a short retro. In the past, if we both wanted to keep going (i.e. skip the break) then we would. Now, I insist on the retro instead. If we want to keep going, that means things are going well. What are these things, exactly? How can we “turn up the good”?

“Conditions for focus” means having the conditions for achievable and sustainable focus. That means being able to agree with our colleague on frequent pairing sessions of reasonable lengths. It also means having the option to take breaks frequently, and to reflect on what’s working and what isn’t.

Clear Goals

Traditionally, when we think of goals in a professional setting we think big. Increase customer engagement. Ship that release. Reduce our change failure rate. In the context of Flow, however, we think of goals on a much smaller scale. When it’s practising a musical instrument, a goal may be to play a piece of music all the way through without making a mistake. Oftentimes, a better goal means going even smaller — play a single bar2 such that every note is played clearly and in tune, while keeping the rhythm of the piece.

How does this translate to coding? Firstly, specification by example and BDD allow us to break down a user story into a series of scenarios. Each scenario is comprised of one or more examples. Each example can be codified into an automated test. Writing a failing test that expresses behaviour of unimplemented code is the first goal. The next goal is to make that test pass. The goal after that is to improve the code we’ve written so that it can be easily maintained and extended. By laying out these small, Flow-oriented goals, we’ve just described the red-green-refactor workflow of TDD.

Continuous Feedback

Feedback is what informs us of our progress towards achieving our goals. Good feedback is timely and actionable. When one plays a note on a musical instrument, the feedback is instantaneous as the note is heard immediately. If the performer has a “good ear”, they will recognize whether the note is flat or sharp. In this way, they clearly know in which direction to adjust the pitch.

In a similar way, effectively practising TDD means reading and interpreting the error messages of the executed test. As long as we move incrementally (AKA “baby steps”), the error messages will be actionable. If our unit tests are well-written and well-maintained, they execute quickly — therefore, the feedback they offer will be timely as well.

The smaller we make our goals, the clearer they become. Small goals also make continuous feedback achievable. Effective feedback is timely and actionable. In software development, this is enabled through TDD. In addition, pair programming adds a layer of support that keeps us on track while continuously improving upon the effectiveness of our goal-setting and feedback collection.

Final Thoughts

Not only is Flow possible when pairing, there are often plenty of opportunities for improvement. We can uncover these opportunities when we reflect on and apply Csikszentmihalyi’s four conditions of Flow. Further, we see how marrying pair programming with TDD allows us to set clear goals that are supported by highly effective feedback loops — namely, feedback that is both timely and actionable.

I find that Csikszentmihalyi’s mental model around Flow holds a high degree of relevance to the practice of Software Engineering and pair programming in particular. I hope to explore this further in future posts.

Having said that, I have created the above poll to learn about what you want to read more about. Please take a moment to read through the options and pick the one that jumps out at you.

Thank you!

If you have any experience with computer programming, you can probably relate to this. On the other hand, if you have experience working with other Software Engineers, you may have been warned against it. Harking back to my startup years, I can remember times when I worked late into the night alone on the codebase, only to have it rewritten by other members of the software engineering team once other factors were considered.

The case against Flow

Robert “Uncle Bob” Martin makes the case against precisely the kind of behaviour I described above in his book, “Clean Coder:”

Much has been written about the hyper-productive state known as “flow.” Some programmers call it “the Zone.” Whatever it is called, you are probably familiar with it. It is the highly focused, tunnel-vision state of consciousness that programmers can get into while they write code. In this state they feel productive. In this state they feel infallible. And so they desire to attain that state, and often measure their self-worth by how much time they can spend there.

Here’s a little hint from someone whose been there and back: Avoid the Zone. This state of consciousness is not really hyper-productive and is certainly not infallible. It’s really just a mild meditative state in which certain rational faculties are diminished in favour of a sense of speed.

The problem is that you lose some of the big picture while you are in the Zone, so you will likely make decisions that you will later have to go back and reverse. Code written in the Zone may come out faster, but you’ll be going back to visit it more.

Up until this point, I agree with Uncle Bob. The following paragraph, however, is where our opinions diverge:

One of the big benefits of pair programming is that it is virtually impossible for a pair to enter the Zone. The Zone is an uncommunicative state, while pairing requires intense and constant communication. Indeed, one of the complaints I often hear about pairing is that it blocks entry into the Zone. Good! The Zone is not where you want to be.

Having practiced pair programming for over eight years now, I’ve found that Flow states are indeed possible to achieve while pairing. They feel different from the Flow states experienced when solo programming, but who’s to say that Flow has a particular feeling, anyway?

As it turns out, there is someone who’s had a whole lot to say about Flow. He also happens to be the one who coined the term.

What is flow

The late Mihaly Csikszentmihalyi has studied and spoken on the topic of Flow for several decades, having published his first paper on the topic in 1975. He is, however, best known for his seminal book on the topic: Flow: The Psychology of Optimal Experience (first published in 1990).

At its core, the book makes the case that many human experiences can be transformed into Flow experiences, and one should endeavour to do so, as it brings meaningful and lasting enjoyment to one’s life. Through sampling and analyzing the lives of experts across various disciplines such as sports, music, art, and many others, Csikszentmihalyi determines that these individuals are at their happiest and most fulfilled during periods of intense concentration on tasks involving high degrees of skill to perform.

Through metaphor, his interview subjects described feeling caught up in a flowing current which carried them along as they progressed through their work. Consequently, Csikszentmihalyi arrived at “Flow” as a unifying term to describe these experiences.

Eight elements of Flow

Further, Csikszentmihalyi identifies eight elements that are common across all Flow states, regardless of level of expertise, form of behaviour, or type of discipline.

Four conditions

The first four elements can be thought of as the conditions for a Flow state to entered into and sustained over time. They’re summarized below:

1. A Challenge Requiring Skills: The task being undertaken is challenging in a way that leverages our skills. The difficulty level of the task must be just right, near the limits of our abilities. If the difficulty is too high, we get anxious; if it’s too low, we get bored. The author describes the non-flow states of "anxiety” and “boredom” as “psychic entropy”.

2. Conditions for Focus: If we are to perform near the limits of our abilities, we need to concentrate on the task at hand. Consequently, we require the conditions that allow for this — a well-rested self and a distraction-free environment are just some examples of what we’d need to enter into Flow in the first place.

3. Clear Goals: In order to start taking steps forward, we must have a clear destination in mind. Goals that facilitate a Flow state are ones that can be achieved quickly, yet still pose a meaningful challenge. This is related to the first point: Flow states are invoked by our psyche when we perform near the limit of our abilities.

4. Continuous Feedback: Effective feedback in Flow doesn’t just tell us whether a goal has been achieved — it also illuminates our progress to achieving that goal. The most effective and consistent Flow states observed by Csikszentmihalyi happened when the feedback was continuous. Here’s one example that he mentions in his book: as surgeons operate, they assess how their surgery is going in real-time by continually observing the amount of blood in the patient’s cavity.

Four characteristics

The next four elements can be thought of as distinct characteristics observed once a flow state is entered into. They serve to reinforce the first four conditions described above. The four characteristics of flow are as follows:

1. Effortless Involvement: While creating the conditions for concentration can be challenging, something interesting happens once we enter into a Flow state: our attention becomes completely absorbed by the activity. At this point, we find it difficult to switch contexts or even get distracted. On the contrary, we find that we need to pull ourselves away — almost by force — when our attention is needed elsewhere.

2. Confidence of Control: Expert athletes and artists in Flow perform dangerous feats requiring high degrees of skill with extremely narrow margins for error. At the same time, these same performers describe their experience as a feeling of complete control. Csikszentmihalyi describes this as a “paradox of control” as there are still possibilities for negative outcomes — even if the performer does everything right, an external factor may cause an injury, or they may simply lose against a competing performer. Essentially, this characteristic can be thought of as experiencing an irrationally-high feeling of confidence in one’s own abilities while in Flow.

3. The Loss of Self-Concern: For many of us, self-conscious thoughts nag at us continually as we go about the mundanities of daily life. If we’re alone, we question and second-guess our motivations, intentions, and behaviours. If we’re with others, we speculate on how we’re perceived and what others think of us. By necessity, these self-conscious thought processes evaporate during Flow. The necessity arises from the mind having to dedicate itself fully to Flow state activities. As these activities push us to the limits of our abilities, there is no room for self-conscious streams of thought to manifest and develop.

4. Transformed Sense of Time: Flow states can alter an individual’s sense of time. We can get so engrossed in a task that we are shocked when we get a moment to glance at our watch — “Is that the time already?” It’s also possible for the opposite to happen, however. Csikszentmihalyi describes how an elaborate Ballet move requiring a high degree of concentration can feel like taking minutes to perform to the dancer, yet they actually complete the move in under a second. In summary, Flow states can significantly transform and even impair our sense of time.

The autotelic experience

In a sea of competing demands for our attention, time, and energy, what hope do we have for Flow to be practiced consistently? Fortunately, there is an underlying aspect of Flow that compels us to return to it: the autotelic experience. Csikszentmihalyi describes this as follows:

The term “autotelic” derives from two Greek words, auto meaning self, and telos meaning goal. It refers to a self-contained activity, one that is done not with the expectation of some future benefit, but simply because the doing itself is the reward.

The author goes on further to clarify that most behaviour is neither purely autotelic nor exotelic:

Surgeons usually enter into their long period of training because of exotelic expectations: to help people, to make money, to achieve prestige. If they are lucky, after a while they begin to enjoy their work, and then surgery becomes to a large extent also autotelic.

At first, we may be extrinsically motivated to complete certain tasks. As we are driven to complete more of these tasks, we put effort towards building the skills needed to complete them. As our skills grow and Flow states deepen, practicing these skills becomes increasingly autotelic — rewarding in and of itself.

Wrap-up

Mihaly Csikszentmihalyi provides us with a well-structured definition of Flow via its eight elements. He also demonstrates how Flow states can be observed across a vast array of activities and disciplines.

Indeed, there are a myriad of human activities that could be enriched thanks to the phenomenon of Flow. I believe that pair programming in Flow is not just a real possibility, but one that is realized more often than we give credence to.

I will back up this claim in my next post, where I describe how the eight components of Flow can be observed during a pairing session. I’ll also cover approaches that can be used to sustain Flow in pair programming.

Most of us will have heard of the term by now. Typically, it’s described as the fatigue one feels after a day of non-stop video calls (Zoom being just one of many group video calling tools that are now available).

What causes this phenomenon? Some contend that being on camera for long periods of time can feel performative, reduce mobility, and increase cognitive load; this has led to many companies adopting camera-optional video calls.

However, consider that Software Engineers and other product development practitioners have been complaining about excessive meetings long before the COVID-19 pandemic and the subsequent ubiquity of remote work. In fact, I’d hazard to guess that this complaint stretches back to the start of Agile software development. Among other changes, Agile brought about radically new ways of working where software programmers began to collaborate more closely with other product development disciplines than before.

My prior two posts — Fend-for-yourself-onboarding and The Hero — each covered a fairly straightforward product team anti-pattern. By contrast, this post covers a set of three anti-patterns that are more nuanced and thus trickier to avoid, identify, and address.

Silo-ball

The term “silo-ball” illustrates the practice of “lobbing back” tickets from a downstream lane of a Kanban board to an upstream one. While doing so is sometimes unavoidable, indiscriminate adherence to this practice can be harmful to the team.

For example, if a Software Engineer requires only a few minutes of a Designer’s time to consult them on a particular UX behaviour, then moving the associated ticket back to the “Design” lane undermines the team’s productivity. This is because the cycle time on the ticket has now increased by an indefinite amount — progress has stalled on the work until the Designer picks the ticket up to offer their feedback. Once they do, they again move their ticket back to the “Engineering” lane, where it sits for an indefinite period until a Software Engineer picks it back up again.

Further, if the team gets comfortable with this practice, then team members specialize in working inside one lane only, rejecting involvement in any work outside of their lane. Collaboration plummets as the lanes harden into silos and disciplines are boxed into roles. Ultimately, this leads to a team that cannot respond to change in a rapid and effective manner, due to the rigid dependencies that form across silos and roles.

Instead of moving a ticket backwards on the Kanban board, a team member can resolve their blocker by jumping on a call with their teammate and conducting an impromptu cross-disciplinary pairing session. Given the knowledge asymmetry (i.e. different disciplines), I’d recommend strong-style pairing for such a scenario.

Backward ticket movements on a Kanban board are sometimes inevitable. Nonetheless, a product team should recognize the significant increases in cycle time and reductions in collaboration that they can cause.

Async fixation

What drives the behaviours that lead to “silo-ball”? What’s stopping us from jumping on that 5-minute call with our colleague? Why do we instead ask them to look at it as soon as they “have a moment” to do so — essentially pushing it to the end of their personal queue of to-dos?

A reason could be the unappealing nature of video calls, when compared to in-person interaction. More specifically, we proactively avoid Zoom fatigue by rejecting both video and audio calls altogether. Thus, the commonly-prescribed treatment to Zoom fatigue is to move as much work as possible to asynchronous collaboration. Being “async-fixated” means that we take asynchronous work to its extremes — beyond the realm of common-sense. A company that embraces async work unequivocally is in danger of finding itself at such an extreme, since its employees can justify their unreasonable behaviour as part of the company culture.

How does “async fixation” look like? We replace as many recurring meetings with async approaches as possible:

• “Why have a daily standup over Zoom if we can just auto-create a slack thread that asks the same questions? That is arguably better anyway because it saves a historical record of the responses.”

• “Why can’t we create an EasyRetro board and have team members populate it through the week? That way if they can’t make it to the retro, at least their observations and opinions are captured? That’ll also shorten the actual retro, as most of the collaboration can happen asynchronously.”

There is some merit to these approaches. Doing pre-work leads to more efficient and effective meetings, so any encouragement around defining and completing prep-work is a good thing. At the same time, however, too much pre-work can lead to anchoring bias around an initial topic, especially when retrospectives are involved.

Avoiding synchronous interaction at all costs, however, is counter-productive and harmful. Some examples:

• “Just add a comment in the PR and I’ll get to it.”

  • Leads to significant delays in cycle time as the PR is shuttled back from reviewer to author and back again (see the diagram below for a visualization of this).

• “Just start a Slack thread and see what people say.”

  • Biases respondents to those with easily-expressible and vocal opinions on the matter; respondents who have nuanced opinions that take more effort to articulate are less likely to contribute.

• “Just start a Google Doc and share it with everyone.”

  • Anchors the discussion to the first version of the document, so only incremental changes are suggested and made.

Some ideas, comments, or questions are difficult to phrase. Sometimes your co-worker needs to talk through their thoughts with you. Sometimes, over-reliance on asynchronous chat tools can lead to a rabbit-hole of questions on a Slack thread that can instantly become moot via a 2-minute real-time conversation.

Deep work obsession

Besides Zoom fatigue, there’s another reason for async fixation that is far more compelling and insidious.

I’ve been listening to Deep Work (on audiobook) lately. While a great book, there is an implicit assumption running through the entire book — that deep work is done alone, and that it’s on you as an individual to figure out how to eliminate distractions so that you can effectively practise it.

Don’t get me wrong. I’m an avid believer in deep work and have practised it solo for certain tasks (for example, writing this post). However, as product practitioners, we should not take deep work as the aspirational pinnacle of productivity.

You may be asking — why not? What happens when we optimize a product team around solo deep work? Wouldn’t we get an explosion of profound insights, or an accelerated delivery of features and bug-fixes through large swaths of thoughtfully-written code?

Unfortunately, the answer is no. While we may gain some novel ideas or sophisticated code via solo deep work, we lose the short feedback loops that validate customer value via continuous delivery of working software. In other words, we lose agility.

That said, deep work need not be abandoned or even compromised to preserve agility. Deep work in groups can be resilient to interruptions, as opposed to being at the mercy of them. Here are some ways in which this can be achieved:

1. Effective pair programming sessions are deep work sessions. It takes some practice to get in a flow state with your pairing partner, but it is possible.

2. A team that adopts pair programming with regular pair rotations eliminates the need for pull requests (PRs). Eliminating PRs usually means eliminating the predominant distraction on most product teams.

3. A pair of programmers can be maintain a flow state resiliently as follows: one person from the pair can field any synchronous requests while the other person continues to code. The interrupter now gets their answer sooner and doesn’t need to put their own task on hold.

4. The team can choose to work as an ensemble, with one work-in-progress task at a time. In this way, the interruptions simply become part of the work.

Conclusion

Whether it’s “silo-ball”, “async fixation”, or “deep work obsession”, all lead to the same result over time: a team operating as a waterfall, with each team member closed off from the other in their own silo-sanctuary, where they measure their own effectiveness based on how long they can stay focussed and uninterrupted instead of whether they are creating anything of value.

Having said that, we can have the best of both worlds. We can leverage the freedom that remote work affords to carve out larger periods of deep work (both as solo and as group practitioners). We can also leverage synchronous communication in thoughtful ways to level-up on collaboration while reducing a wasteful upward creep in cycle times.

My advice to software product practitioners is this: embrace remote work and optimize for deep work, but don’t neglect synchronous co-creation that enables short cycle times and tight feedback loops. Because at the end of the day, it’s the latter that ensures that we’re building valuable, working software for our customers.

This post covers another anti-pattern that can also deceive the product team into thinking that it’s operating effectively. When this anti-pattern manifests, the team sees itself as passionate, committed, and ultimately effective “in the face of adversity”.

The fact that this “adversity” is self-inflicted is the first hint that something is off.

Having spent around half of my professional software engineering career working at startups, I have experienced my fair share of heroism. Both as the hero, as well as the helpless stakeholder-in-distress.

The best way to explain what heroism looks like, and why it’s harmful to the team and the product in the long-term, is by means of a short fable. While the fable as a whole is fictitious, the story’s elements are not. I have experienced, first-hand, all of the behaviours covered below.

The product team hero: a short fable

Gillian is the hero of this story. She’s a dedicated, passionate, team player who is committed to doing whatever it takes to meet and exceed expectations as an ambitious software engineer.

The story starts with a scheduled public release. While the deadline looms, the work continues to pile up. The team falls behind schedule. Gillian pulls a few late nights and manages to ensure that the work is done on time.

Finally, the team agrees that the release is ready for public launch, and the flags are flipped. The team celebrates late into the night, and everyone eventually heads home.

Curious about how the new release is going, Gillian checks out some of the app’s performance metrics on her phone, just before bed. To her dismay, there are over a thousand errors reported in Sentry!

She immediately sits up in bed, cracks open her laptop, and begins troubleshooting. She decides not to alert her team yet. “Maybe I can fix this myself and spare them from having to work during off-hours”, she says to herself.

After several hours of intensely-focused debugging, she finds the issue. It turned out easy to fix and deploy — it was a misconfiguration that she mistakenly introduced during one of her sleep-deprived late nights getting the release back on schedule. She feels embarrassed. “Well, at least I was able to fix it without waking up my teammates”, she reflects.

The next day, Gillian receives a pubic kudos from the Team Lead — he noticed the late-night commits and hot-fix push to production. Her all-nighter did not go unrecognized! The embarrassment she felt last night fades away, and is replaced with a sense of accomplishment and pride. She promises herself that she’ll continue to work hard and to be there for her team, no matter what.

Consequently, the team leans more and more on Gillian; with her passion and dedication, she becomes the go-to expert on the codebase and the domain. Several months and releases pass with their fair share of bumps in the road. Fortunately through it all, Gillian is always there to save the day.

Until one day, she isn’t.

One morning, the Team Lead gathers everyone together for an important announcement. Gillian needs to take a leave of absence due to burnout.

“We take burnout very seriously here, so we’re giving her all the time she needs to recover” the Team Lead continues. “I don’t need to tell you all how important Gillian is to the team. I need all of you to step-up over the next while, especially until Gillian comes back.” No one’s surprised by this announcement, but murmurs of empathy and support echo through the team.

Without their hero, the team struggles to meet release deadlines. There are some areas of the codebase that the team does not want to touch until Gillian comes back. Consequently, larger changes to the app are deferred or avoided altogether. The technical debt builds up, and the designer gets frustrated that, one after another, their ambitious UX redesigns are rejected by the team. The team assures itself that it’ll get better once Gillian gets back from her time off.

Except that she doesn’t. During her time off, Gillian is able to gain some valuable perspective. She realizes that her unofficial “hero” designation is detrimental to her long-term psychological and physical health. Not seeing a path to transition out of that role at her current company, she submits her notice, much to the dismay of her team.

Epilogue

The team kept going. Over time, more people were hired while others left. Yet there was always someone who ended up with the understood yet unstated role of “hero”. Thus, the “hero culture” persisted on the team — this left a wake of poorly-understood code that was increasingly-difficult to maintain and extend. Team members stopped volunteering to be the hero, so the team began to recruit for the role. Due to the accumulated product and technical debt, both the product and team lost its lustre, and recruiting talented practitioners to the team became impossible.

How could this story end? It depends. The product itself may end up getting shuttered, or a new team may get created to rebuild a “version 2.0” from scratch. Either outcome would be a sad end to a product team that should have been capable of growing sustainably and indefinitely over time.

Summary and analysis

Let’s start by calling out some key events and behaviours:

1. Gillian soloing late into the night to ensure the release stays on schedule

2. Gillian pulling an all-nighter to debug and fix a production issue introduced by the release

3. The Team Lead praising Gillian’s late-night efforts and initiative

4. The team relying on Gillian to be the subject matter expert on many critical areas of the codebase

Each of the above made the team progressively more reliant on Gillian. What could have been done instead, to shift the reliance back onto the team? Let’s go through some possibilities.

1. Avoid “soloing” to move faster

Rather than negotiating a team’s practices to meet a deadline, negotiate scope instead. This may involve the whole team working as an ensemble to determine what to de-scope for the release.

For teams who do not have full authority to define their own scope, the Product Manager is typically the liaison between the team and the stakeholders outside of the team. This is why it’s important to include them in the ensemble scoping sessions.

2. Avoid “soloing” during a critical production incident

This could’ve gone much worse for Gillian and the team — if there was another team member who also decided to work on the same issue without bothering the other team members, it could lead to the team members overriding each others’ work and leading to significant delays in getting the hot-fix out.

Typically, teams define an incident-management process that ensures clear responsibilities and tight collaboration, usually via ensemble programming.

3. Run a blameless post-mortem after every production incident

While praise for Gillian was definitely well-deserved, the Team Lead should not have stopped there. He should have ensured that a post-mortem was scheduled, with actionable insights generated that were followed through on.

Usually, team members gravitate towards their routine behaviour of knocking work off of the backlog. It’s therefore up to the Team Lead to ensure that the underlying causes of the incident are determined, and changes are made to prevent it from happening again. This is done by committing to and following through on a post-mortem, even when it feels like a distraction from regular work.

4. Avoid knowledge silos via regular pair-rotation

It’s expected and beneficial for each team member to bring their own set of distinct skills and experience to the team. This is often misunderstood as an acceptability around certain team members having more knowledge of certain areas of the codebase than others. The latter situation is is harmful to team sustainability, as portrayed in the above story.

Regular (i.e. at least daily) pair-rotation can effectively address this. While there can be resistance to this as it can be seen as hampering momentum, the velocity gains from maintaining the same pairings for weeks-on-end are short-term and come at the expense of team sustainability. Therefore, regular pair-rotation should be encouraged.

Conclusion

To be clear, there is nothing wrong with “heroic” acts by the team — just the reliance of a singular “hero” on the team to save the day whenever the team is in trouble.

To summarize my recommendation — avoid relying on one team member considerably more than you would rely on another, and certainly don’t glorify such an arrangement, as it harms both the individual being relied on, as well as the team as a whole.

Taking my cue from the other team members, I would lean on the product manager on the team whenever I had questions around this. The questions began seeping into how we wrote the software. Should we do the larger refactor now, or defer it? Should we write tests? Should we follow TDD for this work? Something didn’t sit right with me about this.

Then, one day a mentor of mine provided a powerful analogy:

Do you ask your manager permission to use a certain data structure, or to name a variable a certain way? Why then, are you asking permission to follow TDD?

This helped shift my mindset away from TDD being a means to “optionally improve test coverage” and towards a way of working that I adopt as a principle. It has been covered at length elsewhere about how TDD is more than just increasing test coverage. Michael Feathers’ talk on the synergy between testability and good design is a great example of this:

I am inclined to adopt a similar mindset towards pair programming — the more solo programming I do or encourage others to do, the more I realize that it creates and propagates anti-patterns on product teams.

In this post, I cover one of these anti-patterns, as well as how pair programming can counteract it.

(Fend-for-your)self-onboarding

Over the course of my career, I’ve onboarded onto dozens of new product teams both as a junior, intermediate, and senior software engineer. Every time, regardless of role, it’s been both an exciting and stressful experience. On the one hand, the existing team members are keen to see what I bring to the team. More cynically, they are eager to evaluate whether I’m up-to-snuff. In that vein, I’ve gotten past remarks such as:

• “That’s a pretty basic query, don’t you have three years of experience in SQL?”

• “As you’ve written production Rails apps before, Surely you won’t have an issue creating a basic Ruby class to encapsulate this logic.”

The key point here is that teams evaluate new members to find and fill knowledge gaps quickly. Sometimes, these gaps are not easily-fillable — when this happens, the team must accept that there may not be a fit on the team for the new member. The sooner the team can find this out, the better for everyone involved.

Many product teams (across different companies) have developed approaches that are ostensibly meant to onboard new team members quickly via a self-paced, independent onboarding process. Here are some examples:

1. Dev environment setup: “How fast can you get your development environment set up? The current record is 6.5 hours, held by Susan. She didn’t need to ask for help once!”

2. Grab something off the backlog: “Pull a bug off the backlog and get it to dev-done. Pick something straightforward so you don’t need to bother the other devs, as they’re busy with the currently-scheduled sprint. That way, you get an idea of our process, and you can show us that you can work independently.”

3. Poke around the codebase: “Play around with the app on your own and walk yourself through the codebase. This should get you familiar enough so that you can work on some features next sprint. Again, try not to bother the team with questions, and instead figure it out on your own by using the app. You’ve used our app before, right?”

In reality, these types of challenges screen for people who prefer to work on their own, and screen out people who are inclined to problem-solve collaboratively. Furthermore, it sets the expectation for the new team member that this is how the team works, and reinforces a pattern of maximizing “solo” time and minimizing collaboration time.

This an anti-pattern because it screens out exactly the type of people you need on a product team: collaborative co-creators and problem-solvers, as opposed to soloists who work best on their own and struggle with focused co-creation in a group setting.

Counteracting the anti-pattern with pairing

Let’s revisit how we can replay the earlier scenarios, but involve pairing so as to emphasize collaboration over independent work:

1. Dev environment setup: Instead of having the new team member do this on their own, pair them up with someone who has gone through the setup steps already. Use strong-style pairing with the new team member filling the role of Strong-Navigator — pairing up this way can expose comprehension gaps in the setup documentation. At the end of the session, reflect on and discuss how the dev environment setup process can be improved. Examples of questions to ask:

   1. Does the documentation need to be updated?

   2. Are there defunct libraries that can be removed?

   3. Can more of the process be scripted?

2. Grab something off the backlog: Instead of doing this, have the new team member pair up with other team members on actual items being worked on that week (or sprint). Strong-style pairing with the new team member filling the role of Typist can be effective here, as such an arrangement does not require for them to have any familiarity with the codebase beforehand. At the end of the pairing session, the pair can reflect on any gaps that the new team member may have, and how to address them (e.g. “I’ve never used Rails serializers, I’ll spend some time learning more about them”)

3. Poke around the codebase: Instead of setting vague expectations and telling the new team member to do this, plan for the whole team to work as an ensemble and include the new team member in the regular ensemble rotation. Ideally, the team is already spending some of its time working this way; if that is the case, the team can just ramp up on those sessions over the course of the new team member’s onboarding period.

What about evaluation?

As mentioned, when a new person joins the team, there are two main concerns that the team has about the new team member:

1. How do we ramp them up as quickly as possible?

2. How do we evaluate that they’re a fit for the team?

It’s not hard to see how a pairing-centric onboarding process will improve the first point. But what about the second? If we give them onboarding tasks to complete, we can evaluate their technical aptitude based on how well they complete those tasks. If they pair on everything, then completion of the task tells us next-to-nothing — for all we know, their pairing partner could’ve done all the work.

Fortunately, there’s a straightforward solution to this. If you’re a lead who is tasked with evaluating whether the new team member is a good fit for the team, simply collect feedback from everyone with whom the newcomer has paired with since joining (ideally, this is every single team member). I find this to be a much more comprehensive and reliable way to evaluate the new team member than looking at how quickly they set up their development environment, or looking at some initial “solo” work they completed for the team (that will likely need rework anyway).

Final Thoughts

Pair programming continues to be a grossly under-leveraged tool for product teams. This tool can be effective at counteracting harmful anti-patterns that undermine a product team’s collaborative capabilities. I’ve covered one such anti-pattern in this post; in subsequent posts I cover a few more. These include:

1. Heroism: how heroes can jeopardize a product team’s long-term sustainability

2. Silo-ball: the tendency for silos across disciplines to emerge within product teams, and how this creates unneeded bottlenecks that make the team more susceptible to spikes in cycle time

3. Async Fixation: when product teams insist on only interacting asynchronously, leading to unnecessary increases in cycle time and shallow collaboration

I hope that the “(fend-for-your)self-onboarding” anti-pattern covered in this post has resonated with you; if not, perhaps one of the anti-patterns covered in future posts will resonate. Either way, I invite you to share your thoughts via a reply or comment.

I explore this idea further in a prior post: Lessons from an Education Revolutionary. That post also introduces Sir Ken Robinson (1950-2020), a thought leader in education whose posthumous influence continues to catalyze transformative change in prevailing education systems. In 1998, he led a national commission on creativity, education and the economy for the UK Government. Bringing together leading business people, scientists, artists and educators, he published The Robinson Report in May of 1999. Here is a quote from that report:

There are many misconceptions about creativity. Some people associate creative teaching with a lack of discipline in education. Others see creative ability as the preserve of a gifted few, rather than of the many; others associate it only with the arts. In our view, creativity is possible in all areas of human activity and all young people and adults have creative capacities. Developing these capacities involves a balance between teaching skills and understanding, and promoting the freedom to innovate, and take risks.

So then, what exactly is creativity? Why is it important to product development? How can it be applied effectively in that context?

Defining Creativity

The Robinson Report defines creativity as follows:

Imaginative activity fashioned so as to produce outcomes that are both original and of value.

While this definition was conceived in the context of education reform, it can be used as a means to improve the effectiveness of software product teams. Because fundamentally, these are teams that create and learn continuously. Software is created and shipped to the customer, while the team evaluates the delivered product and the applied process in feedback cycles. Essentially, a software product team is engaged in learning activities continuously as a consequence of its “raison d'être.”

Creativity’s five elements

By virtue of the Robinson Report’s definition, any creative activity must satisfy five elements. These are summarized below:

1. It pursues purpose: there is some intention behind the activity, whether it is to build a skill, create something of value in itself, or even to simply play.

2. It uses imagination: whether it is imaginal, imaginative, or imaginary, the mental experiences involved in using our imagination are a necessary co-requisite to creativity.

3. It is original: whether the originality is individual, relative to one’s peers, or historic, it is inevitably present in any creative activity.

4. It judges value: this happens when one reflects on and evaluates the output of their creative activity — were any mistakes made? How does it match with its original purpose?

5. It is a process: for sustained creativity, there is an interplay between two modes of thought: generative and evaluative. The creative process is essentially bouncing back and forth between generating ideas and evaluating them.

Now that we have a mental model through which to observe creativity objectively, let’s apply our understanding to some behaviours on software product teams.

Creativity on software product teams

We can think of two contexts in which software product teams engage creatively when delivering software:

1. Product: the team imagines an original product feature, builds and ships it to the customer, and finally evaluates its efficacy. Based on this evaluation, a new purpose is set by the team to either optimize the feature or to pivot to a new one.

2. Process: the team imagines the best way of working together (guided, yet unfettered by existing guidelines). They agree on their own original approach on how to work together. A few weeks later, the team evaluates this way of working during a retrospective; during this activity, they reflect on what worked and what didn’t. They also revise their purposed way of working by deciding on what old approaches to discard and what new approaches to experiment with.

The Robinson’s definition of creativity maps naturally to software product teams — both the work that these teams do, and how they do it. Consequently, a product team’s effectiveness can be interrogated through the lens of this definition.

As an example, let’s see how imagination can be applied to team retrospectives in order to improve their effectiveness.

Leveraging imagination in retrospectives

Imagination is multifaceted. In his book, Sir Ken Robinson describes three distinct mental experiences that are involved with imagination:

1. Imaginal: bringing to mind images drawn from real experiences, for example, your mother’s hair or what you ate for lunch yesterday.

2. Imaginative: bringing to mind images of things you have never experienced, such as a green dog on roller skates, or a vision of how you might spend your next vacation.

3. Imaginary: blending imaginative experiences with real ones, like a vivid dream, a hallucination, or the use of metaphor.

Depending on the activity, any of the above can come into play during a retrospective. Here are some of my favourite (descriptions are courtesy of retromat.org):

1. Mad Sad Glad (imaginal): Put up three posters labeled “mad”, “sad”, and “glad” (or 😡 , 😭 , 😄 ).1 Team members write down one event per colour-coded card, when they've felt that way. When the time is up have everyone post their cards to the appropriate posters. Cluster the cards on each poster. Ask the group for cluster names. Debrief by asking:

   1. What's standing out? What's unexpected?

   2. What was difficult about this task? What was fun?

   3. What patterns do you see? What do they mean for you as a team?

   4. Suggestions on how to continue?

2. Remember The Future (imaginative): Imagine you could time-travel to the end of the next iteration (or release). You learn that it was the best, most productive iteration yet! How do your future selves describe it? What do you see and hear?

   1. Give the team a little time to imagine this state and jot down some keywords to aid their memory.

   2. Let everyone describe their vision of a perfect iteration.

   3. Follow up with 'What changes did we implement that resulted in such a productive and satisfying future?

   4. Write down the answers on index cards to use in the next activity.

3. Sailboat (imaginary): Draw a sailboat onto a flip chart paper. Give it a strong sail as well as a heavy anchor. Add an iceberg in the back of the image. The iceberg represents obstacles they already see coming.

   1. Team members silently write on sticky notes what propelled the team forward, what kept it in place, and what obstacles they see coming. One idea per note.

   2. Post the stickies near the sail, anchor, and iceberg respectively. Read out each one and discuss how you can increase “sails”, cut “anchors”, and avoid “icebergs”.

Final Thoughts

As product development practitioners, do we think of our work as creative?

In the past, I’ve thought of writing code as an act of creativity. A team optimizing its process? That, I’ll admit, never seemed like a creative activity to me. When I reflect on the Robinson Report’s definition of creativity, however, I realize that everything a software product team does can be thought of as inherently creative.

If that is the case, what would happen if software product teams were entirely optimized for creativity over productivity?

As other technology-oriented, knowledge-based industries take their cue from software companies, this bias is in danger of spreading and quashing our ability to innovate (ironically). This is because a solution-oriented bias fails to interrogate the problem itself. This means asking questions such as:

• Is the problem worth solving? If so, why?

• Have we identified the root of the problem?

• Are we solving the right problem?

While asking such questions can be painful and time-consuming, doing so can bring fresh solutions to the fore that would otherwise not be considered.

Offering suggestions

How often have you given or received the following advice around offering suggestions:

If you see a problem, sketch or draft a solution before bringing it up with your manager or peers.

I know I’ve given this advice before. Asking for the solution, arguably, saves time — I don’t have as much context on or understanding of the problem as the person bringing the problem to me. At first blush, it seems more time-efficient to assess a solution rather then mull on the problem.

Yet therein lies the issue. If each person assesses the problem in isolation and brings forward their individually-ideated solution to their manager, then the manager misses out on the set of possible solutions that can only be uncovered through assessing the problem space as a team. Furthermore, if the manager rewards the best individually-ideated solution, then they are disincentivizing the ideation of solutions as a group, and thus suppressing collaboration in the problem space.

Consequently, I do not give the aforementioned advice anymore. Instead, I encourage both reports and peers to talk about problems with each other — to collaborate on them and thus uncover possible solutions that would be otherwise unreachable. I try to work on being comfortable collaborating in the problem space, whether it’s one-on-one or as part of a team.

In that process, I’ve come across a few techniques that I’ve found useful. I will scope this post to one approach in particular that is suited to providing feedback in one-on-ones.

One-on-one feedback

Traditionally, feedback is split into two groups. Positive feedback is essentially given when there is an outcome attributed to an individual that is desirable to the business. The intended outcome of positive feedback is for that person to continue the behaviours that have led to that outcome. “Keep up the good work,” essentially.

Negative feedback, on the other hand, is the opposite. There is an undesirable business outcome that we have attributed to the individual. As managers, we feel it is our job to both attribute the outcome to an individual, as well as determine the course of action to mitigate its future occurrence. In other words, we feel solely responsible for both identifying the problem and most of the solution space.

Most conventional recommendations on providing feedback centre around how to deliver the feedback. Few question the responsibility of the manager. What if they got it wrong? What if more than one person is responsible for the undesirable outcomes? What if there are alternate courses of action to address them? In reality, all are common in knowledge-based industries such as software development. Increasingly, business value is achieved as a team that works together, even when it comes down to individual tasks (pair programming in software, for example).

Nevertheless, as managers we are stuck with the inescapable reality that we are ultimately responsible for the performance of our reports. Thus, problems will arise that are undeniably connected to our reports, and we need a way to collaborate with our reports on them. Enter the CEDAR feedback model.

CEDAR Feedback Model

CEDAR is very effective at providing feedback in a non-directive manner — directive feedback means that the feedback receiver is being told that to do (or what not to do).

The tendency to come to the table with solutions (as opposed to collaborate on the problem) means that leaders tend to gravitate towards directive feedback approaches such as start-stop-continue. While directive feedback models such as this can be very efficient at feedback delivery, it propagates the issue at hand: failing to collaborate in the problem space.

Non-directive feedback is difficult, time-consuming, and counter-intuitive. Consequently, models such as CEDAR can be effective at achieving and sustaining a non-directive approach that gives adequate attention to the problem space.

Here is a summary of the approach:

1. Context: Set the context of the feedback. What led you to bring up the issue? Why is it an important problem to you and the company?

2. Examples: Give concrete examples of activities that you believe to have caused the issue. Explain how they relate to the receiver of the feedback.

3. Diagnosis: Ask the receiver of the feedback to diagnose the problem and its causes. Is there a root cause? Are there contributing factors? Make sure that at this stage, the feedback receiver is doing as much of the talking as possible, and limit yourself to asking questions.

4. Action: Establish next actions with the feedback receiver. It’s important that they drive the synthesis of the actions, with you providing feedback on the actions as needed. Oftentimes, it may involve you having actions of your own.

5. Review: Follow-up on the actions that both you and the feedback receiver have committed to. Primarily, check-in if they need support, but also to close the feedback loop — have the actions have been followed through with? If not, why not?

The above is only my summarized interpretation of CEDAR. I highly recommend reading this article by Anna Wildman (the creator of the model) for a more comprehensive overview.

Applying CEDAR

Let’s walk through an example of how CEDAR can apply:

1. Context:
   Manager: “The tickets you have been working on have been taking longer than expected. This is contributing to the planned release falling behind schedule.”
   

2. Examples:
   Manager: “Of the last eight tickets that you’ve worked on, these five have taken longer than what you had initially estimated.”
   

3. Diagnosis:
   Report: ”I think I could be better at estimating. However a lot of time I have no idea about what’s involved so it’s more of a wild-ass guess. Then, when another team member looks at my PR they point something out that balloons the scope, and it’s back to the drawing board.”
   

4. Actions:
   Manager: “What can we do to improve estimate reliability and accuracy? Or at least, find out when it’s off sooner?”
   Report: “I suppose I can pair program with my teammates more, especially on the larger tickets. That way, the hidden scope is revealed earlier than the PR stage”
   Manager: “Why are you not estimating together, as a team?”
   Report: “I don’t know. I guess that’s just how we do it? I can bring the question up at the next retro.”
   Manager: “Great idea!”
   

5. Review:
   Manager: “How did the retro go?”
   Report: “It went well! I brought up my missed estimates and ballooning scope, and a few of my other teammates were in the same boat. As an experiment we will try to estimate as a group, and we have agreed to always start off the larger tickets as a pair as opposed to solo on them”
   Manager: “Great! Keep me in the loop on the experiment, and let me know if there’s any way I can support.”

In this example, solving the problem at hand involved more than just the report. Their manager encouraged them to bring it up with their team, which in turn yielded a potential process improvement.

Conversely, we can imagine how using an approach involving directive feedback could go. The report would agree to “getting better at estimating”, but may be left figuring out how to do so on their own. Critically, they may never realize that it’s a problem that they in fact cannot solve on their own, and may never think of leveraging their team to solve it.

Wrap-up

Collaboration in the problem space may slow us down in the near term, but can lead to more prudent courses of action in the long term. One-on-ones are just one forum where this can happen. In a subsequent post, I’ll be describing other times where this type of collaboration can happen, as well as other techniques or models that can be applied.

In the meantime, I’m interested to learn about how you encourage collaboration in the problem space. In particular, if you use an alternate to the CEDAR model, I’d love to hear about it!

If you’re new to pair programming, you’re often advised to start with Driver-Navigator. This is only because it happens to be the most well-known pairing style. Corey Haines points out that this style of pair programming is actually an intermediate-level style. In other words, it’s suited more for software engineers who already have significant experience with pair programming.

In order for this style to work, the pair needs to have good communication habits, constantly keeping the other abreast of what thoughts are going through their head. Unfortunately, this level of communication isn’t necessarily built-in to a new pair. Because of this intense communication requirement, I generally consider the Driver-Navigator style of pair-programming to be a more intermediate level style.

— Corey Haines (Understanding the Four Rules of Simple Design)

Prerequisites to Driver-Navigator

A pair of software engineers who are new to pairing with each other or the codebase should consider starting with an alternate pairing style, even if they’re both experienced in pair programming. For example, using strong-style is a good technique for exploring a new codebase, while ping-pong is a good approach for getting comfortable with a new pairing partner.

Let’s say that the pair has found their bearings with the codebase and have established an effective rapport with each other. There are still two additional prerequisites for a successful Driver-Navigator session.

Shared Understanding of Pairing Roles

Fundamentally, a shared understanding of the roles in Driver-Navigator is needed: what each role is responsible for, and what they can expect from their pairing partner. I have found that these responsibilities and expectations are often misunderstood, so it’s good to go over them with your pairing partner.

Driver:

• Responsible for the current step, but may think ahead to the next step. For this reason, “Driver” is considered to be the “tactical” role

• Thinks aloud so that the Navigator can follow along

• Decides when to break for discussion or when to swap roles

Navigator:

• Thinks many steps ahead. “Navigator” is considered to be the “strategic” role

• Listens attentively as the Driver “thinks aloud”

• Takes notes on:

  • Observations of what the Driver does and how they do it

  • Options for where to take the code, what to prioritize next, etc.

• Tries to answer any questions that the Driver asks

• Offers solutions when there is a failing test with an obvious and straightforward fix (e.g. a typo or missing syntax)

• Lets the Driver decide when it’s time to break for discussion, or when to swap roles

  • The pair may also decide to enforce frequent role-swapping through the use of a timer

Both:

• Agree on a working agreement1 for the pairing session. Examples:

  • Either person can take a break at any time, requiring no reason to do so

  • Both people have easy access to a shared whiteboard (e.g. Miro) that is kept handy to facilitate discussions

  • The pair uses a timer to enforce (or only consider) regular:

    • breaks

    • swapping of roles

    • check-ins

Navigator has something to do

The primary responsibility of the Navigator is to think multiple steps ahead. But what does that actually mean? Here are some examples that I’ve experienced where the Navigator role was effective:

1. While the Driver works through an experimental refactor, the Navigator identifies and takes notes on refactoring alternatives that have not been discussed yet

2. While the Driver attempts one fix to a bug, the Navigator notes down other potential fixes

3. While the Driver implements the initial algorithm that was agreed upon, the Navigator realizes an edge case that the algorithm does not cover and notes it down

4. While the Driver sequentially works through implementation of a series of specification examples, the Navigator identifies emerging design patterns in the growing codebase and notes them down

Notice that in all four examples, the Navigator takes notes of their ideas and observations. This is deliberate. The Navigator should avoid speaking these out-loud to the Driver while they are in the middle of driving (i.e. coding). That might not mean typing — it could mean a brief moment of silence while they think about the next move. The key point here is to avoid interrupting the Driver’s flow. Wait for the next break (induced by the Driver or by the timer) to review and discuss the Navigator’s notes.

Avoiding Anti-Patterns

There are plenty of Driver-Navigator anti-patterns; they are written about elsewhere at great length, so I will only provide a brief overview. Here are a few examples:

1. Driver-Twitterer: Navigator stops paying attention to what the Driver is doing, and instead goes on Twitter. Or Slack. Or Jira. The point is, it stops being a pair programming session when the Navigator is no longer engaged.

2. Backseat Driver: Navigator dictates specific instructions to the Driver, e.g. “ do this, now do this, now this…”. Ironically, this anti-pattern is very similar to strong-style pairing. The key difference being that the anti-pattern occurs when Driver expects to have control2.

3. Fighting for the keyboard: Navigator has an idea, but instead of noting it down, says, “here, give me the keyboard, let me try something…”. A number of keystrokes later, the other programmer says “wait, I have a better idea…” and does the same thing. In addition to being unpleasant, this anti-pattern can lead to plenty of half-baked ideas, with precious-few fully-baked ones being earnestly explored, let alone implemented.

In case you haven’t noticed already, these anti-patterns arise when the Navigator doesn’t understand their role, when they don’t have something to do, or both. Generally, the Navigator taking control from the Driver is not an effective move, because once that happens the new Navigator is relegated to observing passively (as opposed to navigating actively). Instead, it’s best to wait until the Driver is ready to give up control. At this point, the pair can decide if the Navigator has something to do. If not, then an alternate pairing style (such as ping-pong or strong-style) can always be considered.

Wrap-up

Given how misunderstood Pair Programming is in general, it’s no surprise that misunderstanding Driver-Navigator is also common. Having a shared understanding of Driver-Navigator, what the pairing style requires, and an appreciation of alternative pairing styles, can go a long way in ensuring an effective pairing session.

This interest kicked into high-gear when I began teaching evenings at a coding bootcamp a few years later. I witnessed the hopes and dreams of eager individuals looking to get into the fresh and exciting profession of software development. This resonated with me. I enjoy my work, and I’m sufficiently skilled to earn a living doing it. I wanted that for my students, too.

Fast-forwarding to today, I have the unique opportunity of running a technical coaching program at work. The word “technical” indicates a focus on knowledge unique to software engineers, yet transferrable across technology domains. In particular, these are the practices of Pair Programming, Test-Driven Development, and Design1.

Education’s Subject Matter Experts

Now I don’t have a pedagogical background — I’m learning as I go. Known as the 0th Order of Ignorance, it’s a risky place to operate from. To put it plainly, I don’t know what I don’t know. I am counteracting this by reading and studying pedagogical techniques. For example, I’ve written about topics such as elenchus and constructivism to get a broad sense of a topic, as well as an awareness of what I don’t know about it.

I’ve also been learning about and studying the work of subject matter experts. In particular, I’ve stumbled upon a particularly radical thinker in the field of education: Sir Ken Robinson.

He gave one of the first TED talks (above), which has since become the most widely-watched TED talk to date. Since that first TED talk, he has given two more,2 in addition to an extended interview with Chris Anderson (Head of TED).

Transforming Education

In all of his TED talks, Sir Ken appeals for a complete overhaul of the current system of education found in most of the world today (especially in the US and UK). To be clear, he explicitly states that a reformation is not enough — a transformation is what is needed.

Essentially, the current system of education has two fundamental faults:

1. It’s predicated on an overly-narrowed definition of intelligence that completely dismisses the crucial importance of creativity.

2. Its delivery model is based on Industrial Age principles that emphasize predictability, uniformity, and efficiency over maximizing every child’s potential as a unique and dynamic individual.

The exclusion of creativity from the definition of intelligence has devastating consequences to the potential of human advancement. If creativity is the means by which we adapt to change, then it should be central to the purpose of modern education. Instead, it is at the periphery — relegated to Arts class and extra-curricular activities.

Similarly, while the Industrial Age has led to rapid economic growth and prosperity, the challenge at the time was one of scale, not innovation. Once inventions such as the commercial steam engine and the spinning jenny were created in the 18th century, capitalism put immense pressure on society to scale its means of production in the following two centuries. This had far-reaching consequences on the fundamental ethos of the 20th century. This ethos continues to reverberate through to the turn of the millennium across multiple “industries” (as we still coincidentally call them). Education is but one discipline that is trapped in the modus operandi of past centuries.

In particular, the parallels between revolutionizing education and avoiding wasteful software development methodologies are uncanny.

Taylorism in Software and Education

Scientific Management (also known as Taylorism) is referenced as the reason why software development teams are often managed as feature factories. In essence, Taylorism asserts “one right way”, which must not be decided subjectively by the workers themselves but instead objectively by management. These “scientific managers” are intentionally hands-off: they observe objectively, collect data impartially, and set standard operating procedures universally. These instructions on how the job is to be done are detailed, inflexible, and non-negotiable. This is by design as only managers have the appropriate “high-level” view which can adequately prioritize and optimize for collective outcomes over individual preferences.

To a tee, this is precisely what appears to be happening in education. Both software and education are experiencing the same problem. And it is a problem in software for the same reason it is one in education. Quite simply, one cannot predict the future. That goes for what the right software product looks like month over month, as well as what the right curriculum and teaching approach works for any given student at any given time.

An Alternative to Taylorism

In software, the problem is far from solved. However, stories have been emerging since the turn of the millennium about how teams and organizations have begun to solve it.

A group of software developers met in 2001 and brought their own ideas about and solutions to the problem of rigid and wasteful software development trends. There was plenty of disagreement. But there was a small intersection of ideas, approaches, and practices that was agreed upon. This intersection came to be known as the Manifesto for Agile Software Development. Stated below:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

If you replace “software” with “education” and “customer” with “student”, the commonality between Sir Ken Robinson’s ideas and the Agile manifesto is striking. Indeed, many agilists regret that Agile was ever framed as a software development approach. It is far more than that. Fundamentally, Agile is a mindset that allows teams and organizations to embrace change while creating value. As it all-too-often happens, when a team decides to adopt Agile while the wider organization is stuck in a Taylorism mindset, the benefit of the former is greatly stunted (if not entirely negated).

So perhaps then, Agile can be thought of as an education framework as much as a software development framework.

Applying Agile to Education

In the development of our technical coaching program at Connected, we certainly endeavour to take an Agile approach. We collect feedback every week, both from the coachees as well as the coaches. Feedback is collected in various means — both in 1:1 sessions, as well as through anonymous submission forms. Based on this feedback, we make minor adjustments to both the content of the coaching sessions, as well as the way the sessions themselves are run.

Rethinking what it means to be creative

To take a page out of Sir Ken’s manifesto “Imagine If…”, perhaps the importance of creativity is under-recognized in software development organizations as much as it is in conventional education. Take, for example, the labelling of certain people as “Creatives”. These tend to be the Marketing Executives, the Creative Directors, and the Heads of Design. They conceive of and contribute to the big and strategic ideas that guide the business.

On the other hand, “creative” is not typically the label ascribed to Engineers who solve the problems that allow technology to grow in leaps and bounds. We don’t call the Mark Zuckerbergs or the Elon Musks of the world Creatives, though we might sometimes call them Engineers.

Wrap-up

I will end on a question to myself but perhaps to all the leaders, teachers, and educators as well:

If creativity lies at the heart of human flourishing, what more can we be doing, on a day-to-day basis, to cultivate creativity amongst our peers, students, coachees, mentees, and beyond?

In this post, I talk about a key usage context for strong-style pairing that is often overlooked.

Leveraging a Subject Matter Expert

Modern software engineering involves much more than simply writing source code that executes some expected behaviour. A more fundamental purpose of software engineering is to create a programmatic model of reality. This reality is often referred to as a business domain, and the distilled logic that mirrors this reality is called business logic. Indeed, Domain-Driven Design (DDD) is the methodology we adopt when we take domain modelling to be the primary goal of software engineering.

Given that domain modelling is a crucial role of software engineering, what happens when the software engineers lack knowledge in the domain? Take accounting as an example. Many accounting designations can take a decade to earn, requiring university degrees, completion of standardized tests, as well as years of relevant experience in the field. How are software engineers expected to acquire this level of knowledge at the same time as building the software product itself?

The answer: they’re not. Or at least they shouldn’t be.

DDD comes with a number of key activities and practices such as event storming and ubiquitous language that leverage domain experts effectively. These domain experts are more commonly referred to as Subject Matter Experts, or SMEs. These SMEs are not typically software engineers. Nevertheless, a SME with a strong technical grasp of a business domain could be navigated through a sufficiently-expressive codebase with the help of a software engineer. This is where the practice of strong-style pairing comes into play.

Shared understanding of the domain model

A firm prerequisite for a successful strong-style pairing session is for the strong-navigator to have a clear idea that they wish to explore. “Explore” can mean implement, validate, or understand. In the usage context of leveraging a SME in a strong-style pairing session, it's the SME who should possess this clear idea. Consequently, the SME takes on the role as strong-navigator, while the other role takes control of the keyboard — we use the term “typist” for this role, though they may not necessarily be typing in this usage context.

Given this setup, the SME now explains their understanding of the business domain, while the typist maps this understanding to the modelled domain of the codebase. As they do so, they step through the code while translating and explaining to the SME how the software behaves.

Such a pairing can build a shared understanding in two key ways:

1. The typist gains an understanding of the business domain beyond what is modelled by the codebase, including gaps and errors in how the modelling has been done.

2. The strong-navigator gains a concrete understanding of how the business domain has been actually modelled by the codebase; similar to the typist, this understanding includes gaps and errors in the current model.

Gaps in the domain model

On a product team, why would such an exchange need to occur? Oftentimes we like to imagine product development operating like a smoothly-flowing river — requirements in, features out.

In reality, the most valuable features don’t flow smoothly through our Sprints or Kanban boards. They either get snagged as being more complex than initially imagined, or they resurface as bugs. In fact, these two causes are often interrelated. Particularly intransigent areas of a codebase can be both difficult to add new functionality to, as well as prone to regressions once the functionality has been added.

This is essentially a manifestation of technical debt as originally defined by Ward Cunningham:

To summarize, the original definition of technical debt was never about shipping poorly-written code that would later be “cleaned up”. It was about implementing a simplified a domain model based on a limited initial understanding.

To be clear, this is the right path to take in the beginning. As the product grows, these simplifications become over-simplifications, and software engineers start to get out of their depth when it comes to their understanding of the business domain. At this point, a SME is consulted. As the codebase is the source of truth when it comes to the currently-implemented domain model, strong-style pairing is therefore the most efficient and safest way to walk an SME through the domain model.

Wrap-up

Software engineering is more than just writing code. Consequently, it should involve more than just the coders. When modelling an especially complex business domain, it’s imperative to involve Subject Matter Experts (SMEs). If we take an Agile approach, our software products will outgrow their original, simplified domain models. They get replaced with more complex ones built in close collaboration with a SME who ensures that they’re modelled in the simplest and most elegant way for the set of use cases that satisfy the product’s customers.

This collaboration ensures that the models stay as simple and correct as appropriate, given the set of use cases that satisfy the customers’ needs. As new models emerge out of existing code, strong-style pairing is the most effective and risk-free strategy to take when collaborating with a SME.

The majority of software engineers with whom I have worked with have a basic understanding of “Driver-Navigator”. In this pairing style, the Driver is in control of the keyboard and thinks aloud while coding the implementation. The Navigator observes attentively, thinking several steps ahead while taking notes, and answering any questions that the Driver may have along the way.

Driver-Navigator is how I was introduced to pair programming almost ten years ago. It has also been the de-facto pairing style in any discussion about pair programming that I’ve had since, with two notable exceptions. The first exception happened during a coderetreat, when I was introduced to Ping-Pong Pairing. The second exception happened when I was recommended Ensemble Programming, which in turn led me to acquire an understanding of Strong-Style Pairing (being a prerequisite to the former).

I cover the value of Ping-Pong Pairing in a prior post. In this post, I discuss Strong-Style Pairing: what it is, why it’s beneficial, and when to use it.

What is Strong-Style Pairing

Strong-Style Pairing was conceived by Llewellyn Falco as a means to coach junior software engineers. The style can be summarized by his Golden Rule of Strong-Style Pairing:

For an idea to go from your head into the computer it must go through someone else's hands.

The roles and interactions in this pairing style are summarized in the diagram below:

Here’s a further elaboration on the two roles.

As the Strong-Navigator, I:

• Have control

• Instruct the Typist on what to code (instead of typing out the code myself)

• Provide instructions in the appropriate level of abstraction for the Typist to follow

• Give up control only once I’m ready to do so

As the Typist, I:

• Have the keyboard

• Type the code

• Wait for instructions from the Strong-Navigator on what to code next

• Ask for clarification if I am unable to follow the Strong-Navigator’s instructions

• Am comfortable proceeding with an incomplete understanding; I trust that the Strong-Navigator knows what they are doing and where they are going

Opportunity and benefits

An opportunity for Strong-Style Pairing arises when one person has an idea that they want to try implementing. I find it works best when two additional criteria are met:

1. The person with the idea has a high degree of confidence in how they want to implement it.

2. The idea is straightforward enough to be implemented in a short amount of time (e.g. in under five minutes).

As mentioned, Driver-Navigator is a far more common pairing style than Strong-Style. Assuming that the former is being used, the common approach to the above scenario is for the person with the idea to take the Driver role. If it’s the Navigator with the idea, the Driver gives up control and the roles are switched.

This creates a problem when the person switching to Navigator doesn’t have a good understanding of what the new Driver wants to try; in this case the new Navigator is not be able to navigate effectively due to that lack of understanding. Once this happens, the Driver begins to code on their own, resulting in an effective end to the pair programming activity.

In addition to preventing this from happening, there are a few other reasons why the pair may be better off adopting Strong-Style Pairing instead of staying in Driver-Navigator:

1. It keeps the other pairing partner (the Typist) engaged. Instead of being relegated to observing, they are actively participating in writing the code.

2. The Typist is able to gain a deeper, more tactile understanding of how the Strong-Navigator thinks and solves problems. Instead of solely observing the Strong-Navigator, the Typist actively participates in solving the problem.

3. If the Typist is not familiar with the codebase, Strong-Style Pairing is an opportunity for them to gain that familiarity in a far more effective way than aimlessly “walking through” the codebase on their own.

4. It constrains the Strong-Navigator to having to articulate their idea coherently and efficiently, so that the Typist can implement it effectively. This develops technical communication skills that lead to a stronger shared understanding on a team.

5. If the Strong-Navigator is not familiar with the codebase while the Typist is familiar with it, then the former role can focus on their idea without getting caught up in implementation details. For example: the Strong-Navigator has an idea around code design they wish to explore, while the Typist has a good understanding of the existing design and can therefore lead them through it efficiently.

Usage Contexts

Having covered an overview of Strong-Style Pairing and some of its benefits, I will now cover some contexts where I’ve found the style particularly effective.

Interviewing

Evaluating the technical acumen of software engineers fairly and effectively has been and continues to be a hard problem to solve. Take-home coding assignments discriminate against people who lack free time outside of work. Asking candidates to code independently during an interview session means that they’re expected to perform in an unfamiliar coding environment while being observed and evaluated.

At Connected, we use strong-style pairing to maintain fairness while reducing the pressure of coding during an interview session. The candidate takes on the Strong-Navigator role, while the interviewer does the typing. This means that the candidate does not need to navigate an unfamiliar IDE setup; in fact they do not even need intricate knowledge of the language syntax (though a rudimentary familiarity definitely helps). It also means that we can evaluate for skills that we care most about — namely, technical communication skills and an understanding of language-agnostic software engineering concepts such as TDD and simple design.

Onboarding

A typical approach to onboarding is to give the new team member a straightforward task and let them implement it on their own, while “encouraging” them to ask for help if they need it. I use scare quotes here because this strategy has the opposite effect for any software engineers who are inexperienced relative to their teammates. Imposter syndrome is an unavoidable reality for these new hires, who oftentimes have the added sceptre of probation hanging over their heads.

Instead, I find that a much kinder approach is to pair them up with a teammate as soon as they’re ready to work on a task. Ideally, neither the task nor the teammate should matter. The new hire is put in the Typist seat, while their teammate takes on the role of Strong-Navigator.

While this may seem intimidating at first, remember that in Strong-Style Pairing, the Typist need not be concerned with anything other than following instructions. If they cannot understand the instructions, they can ask for clarification. It might seem like throwing them in the deep-end of a pool. I contend that it’s actually like walking them into the shallow-end. Throwing them in the deep-end would be expecting them to solo1 on a new ticket, in a new codebase, on a new team.

Off the bat, set the expectation that the point of the pairing session (and perhaps even the first week) is for them to get familiar with what they need to learn in order to be effective on the team. Setting this expectation is a powerful way to invite honesty and openness, while allowing them to set aside time for deliberate learning and practice as they ramp up onto the team.

Wrap-up

There were a few more usage contexts for Strong-Style Pairing that I wanted to cover. I’ve save them for a follow-up post that can be found here: Pairing with a Subject Matter Expert. In the meantime, I hope that Strong-Style Pairing has given you food-for-thought in regards to how you can incorporate pair programming on your product team.

Through this experience, I have observed a few common themes. I have discussed these themes with the people I paired with. We found that these discussions led to a shared understanding which in turn resulted in more effective subsequent pairing sessions.

Furthermore, I have found that these themes apply regardless of pairing style (e.g. driver-navigator vs. strong-style) or context (e.g. working on a TDD kata vs. debugging a production codebase).

The three themes I cover in this week’s post are: control, communication, and group flow.

Control

During a pairing session, exactly one person has control of the coding process at a time. In the traditional Driver-Navigator pairing style, this is the Driver role, who also happens to have the keyboard. In Strong-Style Pairing, however, the Navigator directs the Typist on what code to write. This means that the Navigator has control, while the Typist has the keyboard.

Recognizing the concept of control is important, because it is unavoidably present in a pairing session. It’s impossible for both programmers to have control at the same time, yet a healthy pairing dynamic means that control switches fluidly and frequently between pairing partners. I find that it’s beneficial to call this out in a pairing session and establish norms with your pair around it.

For example, one principle I employ is to agree that control should be given, not taken. I find that it’s very easy to take control when pairing virtually, especially when using tools such as VS Code Live Share and Tuple. While this might seem convenient the person taking control, it can be jarring for the one losing it. Switching control doesn’t need to be a formal thing. I find that simply asking, “mind if I try something?” is usually sufficient.

Having said that, teams and individuals who’ve paired hundreds of hours together may feel this notion of control a stilted way to go about pairing. That is completely fine and even expected for teams with a high degree of pairing proficiency. Nonetheless, I have found that “control” is an important concept to keep in mind when pairing with a new teammate, and especially someone who is new to pair programming.

Communication

In a past post, I explained how I initially struggled with pairing because of my inability to think aloud. Coding in silence meant that my pairing partner had no idea what I was trying to do until the code was written. This severely limited the level and amount of contribution that they were able to offer.

Concretely, they were only able to point out typos, syntax errors, and style inconsistencies — essentially everything a well-configured IDE already does for you. Consequently, they would lose interest and thus struggle to stay engaged during the session.

Having control

Thinking aloud for the person in control is only one part of communication, however. It’s also important for the person in control to be deliberate about how they ask questions to their pairing partner.

Before elaborating on this further, it’s important to explain two collaboration modes that come up when pair programming.

Discussing mode

Actual coding takes a pause when a pair switches to “discussing mode”. Consequently, either person is invited to type out notes, pseudocode, or even sketch out some ideas and diagrams on a virtual whiteboard.

There are two important aspects of this mode. First: executable code is not written. Second: the mode should not last longer than a few minutes.

Coding mode

The other mode is “coding mode”. This is when executable code is being written. During this mode, it’s imperative that the person in control is continually thinking aloud. They should also be aware that asking a question may result in a shift to “discussing mode”, depending on what is asked, and how.

For example, if they ask a straightforward, closed-ended question (such as, “is there a native method for splitting a comma-separated string into an array?”), then the coding mode is maintained, as the pairing partner can provide them with a simple answer. I have found that having a REPL open to do so is a quick an effective way to answer these kinds of questions.

On the other hand, if an open-ended question is asked, this invites a switch from coding to discussing mode. This, of course, is critical — without a discussing mode, there is little point to pair programming in the first place. In most cases however, the discussing mode has rapidly diminishing returns when it lasts longer than a few minutes. In pair programming, the bias should always be towards writing working code, so it’s important that both pairing participants are aware of the mode currently in effect, and when it changes.

For example, the person in control may say, “I’m not sure whether to extract this to a class or a module. What do you think?”. Their pairing partner may respond with, “I’m not sure either. Instead of discussing it, let’s pick the one you’re more comfortable coding out and see where it goes.” In this situation, the pair agreed that switching to discussing mode wasn’t worth it, so coding mode was maintained instead.

If you don’t have control

If one doesn’t have control, there are a few counter-intuitive communication guidelines to keep in mind. When in coding mode, one communicates almost exclusively by answering questions as opposed to proactively making suggestions. This allows for the person in control to maintain an uninterrupted focus.

There is an important exception to this: when a test unexpectedly fails, and the one without control is able to see why. In that case, it makes sense to jump in and proactively make a suggestion, as the person in control has already lost focus due to the unexpectedly failing test (note that this exception doesn’t apply when the test expectedly fails, for example during the “red” step of the “red-green-refactor” cycle).

Use pomodoros

Let’s say that the pair is coding away in coding mode. What if the one without control has an idea they wish to discuss? Similar to discussing, the coding mode also shouldn’t last for too long. A pause in coding and consequential shift to discussing mode presents an opportunity for the person not in control to share their thoughts and discuss their ideas with their pairing partner. This is also a natural point at which to consider handing over control to the other person.

Group Flow

This third pairing theme underpins the first two. All experienced programmers are familiar with the notion of “flow state”, but most have only experienced it when soloing. I was convinced that flow state is something that simply doesn’t happen when pair programming. I later came to realize that one can in fact achieve this while collaborating with another person during a pair programming session.

I believe that recognizing and respecting control helps programmers achieve group flow. Further, establishing communication norms based on coding vs. discussing modes help maintain group flow. Finally, reflecting on the sessions themselves with one’s pairing partner helps optimize for group flow.

Beyond affording an opportunity to shift into discussing mode, working in pomodoros allows for pairs to reflect on their pairing experience. Here are examples of topics that could come up in doing so:

• Did we give enough time for discussion in that last session?

• I noted down some some ideas that I’d like to try. Can we discuss and perhaps you could give me control for the next pomodoro?

• What else can we do to improve our group flow in our next session?

Wrap up

We coders just want to code. When we feel like we’re on a roll, we don’t want to be interrupted because being in a flow state feels good, and it’s fulfilling when we ship working code as a result. However, it feels even better when we include our teammates, both in the learning as well as the shipping.

While pair programming is the most effective way I’ve seen to include the team in this, it’s still an uncommon practice that feels strange and unusual to many programmers. Hopefully, the pairing themes covered in this post will help demystify it and thus make pair programming accessible to more software engineers.

In this post, I cover Ping-Pong Pairing and its benefits. I consider this pairing style foundational as it holds the key to learning a number of principles that set us up to be effective pair programmers throughout our careers.

Origins

At the start of this month, I launched a technical coaching program at work. Pair programming lies at the foundation of the program. The program is also geared to software engineers of all skill levels, so the content and approach must accommodate those who are entirely new to pair programming. This begged the question:

How do I teach pair programming to those who have never truly experienced it before?

Fortunately, I am not the first to encounter this problem. When Corey Haines started running coderetreats, he realized that the commonly-adopted practice of Driver-Navigator pair programming is actually an intermediate-level practice. He observed that introducing this pairing style to beginners would often backfire:

Unfortunately, too often this [Driver-Navigator] form of pair-programming leads to what I call the “Driver-Twitterer” style of collaboration. In this mode, the person with the keyboard is writing code while the other person watches intently for a short time. Then, after a bit, the navigator starts to lose interest. Perhaps the driver isn’t talking, perhaps the navigator doesn’t want to disturb them. Sometimes I’ve seen where the driver says “just a second, I’ve got an idea,” and then proceeds to code in silence for minutes on end. This can have the effect of boring the navigator. So, what do they do? Naturally, they check twitter. Or email. Or some other non-code-focused task.1

In response to the lack of communication, Corey introduced ping-pong pairing at his coderetreats. By design, this style of pair programming encourages a high degree of communication.

First Form

There are two forms of ping-pong pairing; the first form is summarized below:

Essentially, one person is responsible for writing tests, while the other is responsible for writing and refining the implementation that makes them pass.

I have found this form very effective at getting someone started with Test-Driven Development (TDD). In my experience, one of the most common obstacles to writing tests lies with the software engineers who have never seen how TDD works in practice. This form of ping-pong pairing is the most effective way to nip this in the bud. Simply assign the software engineer with more TDD experience to the “Test Redder” role.

More broadly, this form of ping-pong pairing is the single most effective way of explaining the value proposition of TDD to another software engineer. When I first looked at code that was written using TDD, I thought it was wasteful. I noticed that codebases written using TDD had at least three lines of test code for one line of implementation code.

Only once I experienced TDD did I recognize the value of the approach, and how it goes far beyond simply achieving test coverage. I finally understood what it meant to refactor in confidence, as opposed to in dread. I also discovered the joys of working with code that is refactored continuously.

While such comments might give you a hint, words alone will always be ineffective in explaining the value of TDD to another software engineer. A better way is to try this first form of ping pong pairing with them for a few red-green-refactor rounds. I recommend a code kata to start, but there’s no reason why it can’t be done when working on shipped code (i.e. code that goes to production).

Second Form

The obvious limitation of the first form of ping-pong pairing is the lack of experience that the “Test Greener” gets in writing tests.

In theory, timer-enforced role-switching addresses this. In practice, however, I’ve rarely seen this work. Once a software engineer gets in their flow-state, they try to maintain it for as long as possible. People who are new to pair programming feel that switching roles threatens their flow-state. In actuality, I’ve found that flow-state can be preserved while still switching roles.

It does require some experience with pair programming to accomplish this. If you wish to work on maintaining your flow-state while switching roles, that is precisely what you need to practice doing! Consequently, the second form of ping-pong pairing has role-switching “built-in”. See below for a summary of the approach:

Essentially, one person gives up control by writing a failing test. You can think of it as “ending your turn” in a similar way you would do for a card game: writing a failing test is like drawing a card from the card pile.

For those new to the ping-pong pairing style, I like to start off at the first form with myself in the “Test Redder” role. I then introduce the second form once we have a good rhythm going. Once I feel that this has been established, I wait until they ask me to write the next failing test. At this point, I say:

Now let’s change things up a bit. Keep control for a little while longer. You write the next failing test, and I will get it to pass.

Once they write the failing test and hand control over to me, I follow the previously-mentioned steps: make the test green, refactor the implementation, and finally, write the next failing test. Once I hand control back to them, they realize that we’ve shifted from the first form of ping-pong pairing to the second.

The second form of ping-pong pairing yields all the benefits of the first form, in addition to a seamless means by which control is handed over from one person to another. This ultimately allows for both participants to have equal exposure to all three parts of the red-green-refactor cycle.

Wrap-up

In a follow-up post, I will discuss three core aspects of pair programming that ping-pong pairing highlights and reinforces the importance of. In the meantime, I encourage you to try out the two forms of ping pong pairing by starting with the first and easing into the second when you and your pairing partner is ready.

As you’d expect, the responses have been varied, from emphatic agreement to vociferous disagreement, including everything in between. Many of those who fell in the latter camp have already written response threads dismantling the above argument line-by-line, so I won’t be doing that here. Instead, I’ll share how I started pair programming, and some of the “aha” moments I experienced along the way.

What is pair programming?

Pair programming (AKA “pairing”) is two people programming, with one person typing at a time. Understanding this definition requires one to appreciate that programming is more than just typing, and appreciating this difference is necessary for being convinced of the merits of pair programming.

What is programming?

Fundamentally, programming is the process of identifying and solving problems through the authoring of computer instructions (AKA “code”). Getting these instructions right requires that programmers identify the problem with absolute precision. Within the scope of the problem at hand, this means articulating exactly what the computer should do under every possible circumstance — computers have a zero tolerance for ambiguity.

Further, code is written to be executed by computers as well as comprehended by humans. It is the latter that makes modern software engineering especially challenging. As Martin Fowler said,

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Code readability, however, is only a means-to-an-end to writing code that is easily maintained and extended in response to new circumstances. The accelerating pace of change in software means that the need for well-designed code will only increase.

Thus, software programming in the modern sense is a tall order. Let’s say that you can figure out exactly what the computer needs to do and exactly how to instruct the computer to do it. How do you know that the code you have written is readable to other software engineers? How do you know that your design is simple, yet scalable?

A few answers to these questions exist. Other than pairing, code reviews and general programming experience are two that come to mind. Pair programming is not the only way to write readable and scalable code. Still, many claim that it’s the best way we have so far, compared to the alternatives.

How I started pair programming

I regret that I wasn’t more curious about pair programming when I first learned of it back in 2007. The long-forgotten article I read explained that pair programming involved, “two people sitting at one computer, with one person having control of the keyboard at a time.” That sounded awful! Even back then I knew how I liked to write code: without interruptions, immersed in my “flow state”, and (most importantly) alone. So I dismissed the outlandish concept without giving it any further thought.

Six years later I was faced with pair programming once again when I began working on a team that paired all the time. At first, I hated it. The experience felt like my thoughts were being trampled over.

Intention and reflection

Then, I began to pair with another Software Engineer who was more experienced at pairing than those who I had worked with so far. Instead of “talking over” my thoughts — telling me to do something different from what I was thinking — he gently pointed out that he was unable to read my mind and if I’d be so kind as to tell him what I was thinking.

That was my first “aha” moment when it came to pair programming. Along with other insights, it led to my team developing the approach of Intention-Driven Pairing1 . In addition to setting intentionality around how we worked together, the approach gave us an opportunity to share feedback after every pairing session, so issues such as a lack of “thinking aloud” were identified and addressed early.

Pairing styles

A year later, I had the opportunity to attend my first Coderetreat. There, I paired up with someone I had never met (let alone programmed with) before. I was worried. On the one hand: I knew how to pair with my teammates, thanks to hundreds of hours of pairing together. On the other hand: I couldn’t see how pairing with a complete stranger was going to be any different from the first time I tried pair programming.

Then, they introduced me to ping-pong pairing.

This was another “aha” moment for me. Novices at a given skill need a clear set of instructions (or rules). By following these instructions repeatedly, they establish a baseline skill level. Musicians play scales. Athletes do drills. Programmers do code katas.2

Pairing styles are instructions for novice pair programmers. Ping-pong pairing is an example that is particularly well-suited for programmers who are new to both pair programming and TDD, as it uses the red-green-refactor cycle to ensure that control is frequently rotated between programmers.

Wrap up

I did not enjoy pair programming when I first tried it. I am also still learning how to be a more effective pair programmer. Nonetheless, my most fulfilling, insightful, and productive programming moments have happened in pairing sessions. The pair programming learning curve is steep, but I think it’s worth surmounting.

In a future post, I’ll delve more into pairing styles and why I think they’re the key to effectively introducing novices to pair programming. If you’ve already dismissed pair programming as something that’s not for you, I hope this post has opened you up to the possibility of having your mind changed.

How this iteration happens from an implementation perspective is often less clear. What cyclical workflows does a team adopt that allow it to iterate continuously on not just what to build, but also on how to build it?

“What” and “how” are interwoven

First off, care should be taken when thinking about “what” (the business requirements) and the “how” (the implementation). If we think of them as separate concepts, then we ultimately invite what we are trying to avoid — phases in software development.

Consequently, product teams interweave the “what” and the “how” of software development by adopting Test-First Development1 methodologies. Writing tests prior to implementation continues to be one of the most misunderstood practices in software development. I have seen it referred to as a “testing strategy”, a “luxury”, or only applicable “when stakes are high”.

Given the cost of software development today (including the opportunity cost brought on by talent scarcity), when are the stakes low? For whom are tests considered a “luxury”? For the software engineers, so that they can do their job effectively and sustainably? For the team, so that it can safely pivot in response to rapidly-shifting requirements in the product? What cool-headed professional would not want to “indulge” such a “luxury”?

Perhaps most grievous of all is the misconception that Test-First Development is a “testing strategy”. In the sample phased software development model introduced in a prior post, Business Analysis happens three levels upstream from QA. In a sense, Test-First Development merges the four phases — Business Analysis, Architecture Design, Implementation, and QA — into one. Granted, testing (QA) is there, but so are the three other phases. To call Test-First Development a testing strategy is like calling a house a heating strategy. Yes a house will provide you with heat, but also shelter, safety, comfort, etc.

What is Test-First Development?

In XP Explained, Kent Beck defines Test-First Programming simply as:

… write a failing automated test before changing (or adding) any code.

Further, Test-First Development and Test-Driven Development (TDD) is often thought of as being one and the same. In actuality, the latter is a subset of the former. A straightforward way to determine whether or not TDD is being practiced is the length of the feedback loop. For TDD, this should be in the order of minutes, while other Test-First Development practices can have a feedback loop in the order of days to weeks.

Concretely, TDD leverages the red-green-refactor cycle of software development:

1. Red: Write a failing unit test2

2. Green: Write the implementation to make the failing unit test pass

3. Refactor: while keeping the tests green,

   1. Improve the implementation (without changing the tests)

   2. Improve the tests (without changing the implementation)

Again, it’s important to emphasize this point — a single cycle should happen in the order of minutes. If it takes longer, then it’s not TDD.

When TDD is not enough

Oftentimes, a business requirement cannot be satisfied with TDD alone. While on the one hand a bug can often be addressed by filling in an edge case via a few red-green-refactor cycles, a user story typically involves elaborate end-user interaction. It is impractical, for example, to write a unit test for a user navigating to a website, viewing an item, and then adding that item to their cart. Assuredly, however, the code generated by implementing that requirement would involve several TDD cycles and be supported by a number of unit tests.

For such a scenario, a complementary Test-First Development approach is needed. Specification by Example is one such approach:

Specification by example (SBE) is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements. This approach is particularly successful for managing requirements and functional tests on large-scale projects of significant domain and organizational complexity.3

How Specification by Example prevents phases

The critical part of SBE is frequent collaboration between all four disciplines of software development, namely: QA, Product, Engineering, and Design. SBE encourages this collaboration to be continuous throughout the development process, thus preventing these disciplines from siloing themselves into phases. Here is how a specification written using SBE might look like:

• Given a potential customer visits the website, and
  given that they are using a computer with a pointing device,

• When they hover over a featured product,

• Then they are shown a product preview pop-over.

Note how SBE exposes the need to consider specifics, such as hovering-over a product only makes sense when using a computer with a pointing device (such as a laptop). This is one example of how SBE allows for feedback loops to be drastically shortened. On the other hand, a phased approach would mean that this UX design oversight would be caught in the QA phase, which would be too late in the process to address in a holistic way.

SBE aside, if your cross-disciplinary product team writes the actual specifications together — be it virtual or in-person, synchronous or async, using SBE or otherwise — you’ve already made great headway towards eliminating unnecessary phases and thus adopting an approach that is not just resilient to but also optimized for change. In other words, a team that continuously creates and refines specifications together in short iterations is poised to leverage change and transform it into an opportunity, as opposed to dealing with it as a threat.

Wrap-up

I continue to be amazed by teams claiming to be Agile on the one hand, yet on the other hand the software engineers on these teams gladly accept handed down and “dev ready” specifications. Furthermore, when a specification is incomplete, it’s the software engineers who complain that the process needs to be improved by adding more implementation details before they even look at a ticket. I’ve witnessed that the attraction towards phased approaches doesn’t just come from management or from product — it often comes from the software engineers themselves.

How does your team implement requirements? Can software engineers provide feedback on the specification, and if so, how does that feedback happen? I look forward to hearing your thoughts and experiences.