Warning: Attempt to read property "user_firstname" on string in /home/customer/www/thoughtworks.dayshiftdigital.com/public_html/wp-content/themes/connected-2021/single-post.php on line 6

Warning: Attempt to read property "user_lastname" on string in /home/customer/www/thoughtworks.dayshiftdigital.com/public_html/wp-content/themes/connected-2021/single-post.php on line 7

Four Reasons Why Software Engineering Needs More Coderetreats

Paul Sobocinski

Paul Sobocinski

Director of Engineering, Practice

February 20, 2020

In November of last year, Connected had the honour of hosting Global Day of Coderetreat 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? 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

a. 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.

b. 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.

c. 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.

d. 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. Emphasis 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. Emphasis 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. Connected is planning one for the near future. If you’d be interested, please let us know.

Download Accelerating New Product Development Whitepaper

Subscribe to Our Newsletter

Join the Thoughtworks newsletter list to receive curated content that exemplifies our Product thinking approach.

Warning: Undefined array key "modal" in /home/customer/www/thoughtworks.dayshiftdigital.com/public_html/wp-content/themes/connected-2021/template-parts/newsletter-modal.php on line 2

Related Posts