The value of team programmings

In this article, I want to explain, why team programmings across units with developers from many backgrounds and areas of the codebase are extremely valuable for companies and individuals, but often undervalued and deprioritized by developers. I will focus on this specific type of team programmings, not about team programmings within a cross-functional unit, even though most of the benefits apply there as well.

In companies, where cross-functional units are the norm rather than the exception, developers sometimes consider cross-unit team programmings less valuable. Therefore, only a small group of individuals is attending these team programmings, which can limit its value. The reasons for this are manifold.

The most common cause is, that such team programmings are rarely in direct alignment with the most pressing topic in every unit. Therefore, there is often another topic that gets most of the units’ attention. Carving out time for a different topic often does not happen because of the necessary context switch. Another reason is the other topic being considered less important by the person making the decision for not attending a team programming1.

However, in my opinion, coming from the experience working with different teams and units, team programmings are rarely a bad investment of time, but much more often a valuable opportunity for all participants and the organisation itself.

It is not (so much) about the short-term effects

What most people miss is the fact, that team programmings are less about writing a high amount of code in a short time, but much more about shared learning and understanding. This is especially valuable across independent units because it creates a no-bureaucracy, no-policy way of enabling cross-unit alignment, as alignment often comes from shared understanding.

On an organisational level, team programmings are not so much about short-term outcome but about the positive long-term effect that you get when various smart people are mixing their knowledge and ideas with each others. But of course, there is much more value than this.

Learning from varying colleagues

In software development, there are an almost infinite number of approaches to most problems or tasks. Humans tend to stick to the solutions they already know and that somehow work for them. However, there might be much better approaches.

Think about refactoring: You can do it manually, or you can utilise your IDE. You can do it guided by tests, or you can break all the test while choosing another approach. Sometimes, different ways are just better than others, and sometimes there is no clear better way.

However, in any case, it is valuable for a developer to know different approaches and therefore extending their problem solving toolbox. This does not only apply for refactoring but also for softer topics, such as breaking down complex problems, communicating with people and also writing tests or structuring code.

All these things you can learn very efficiently by working with other people. Team programmings are a great context to do so. Especially in team programmings outside your unit, you will often meet different colleagues and encounter different styles.

Practicing to communicate

When working with varying colleagues, you will become superb at explaining and communicating your ideas to a heterogenous audience. Therefore, you are not just learning by observing colleagues, but you are also learning how to lead people into a certain direction.

Discover, what you don’t know

The argument “The team programmings are not relevant for us” is common, but rarely true. I often got this argument from people who are then writing extremely complex code inside their units just because they are unaware that there are better approaches or tools available in the ecosystem in which they are working.

In a team programming, you are not only solving a specific problem with your colleagues, but you are also using tools and method to do so. Be it a test framework or an IDE feature. Furthermore, you might solve a problem in the context of the system on which you are working daily. Thus, it will broaden your horizon and will provide you with additional context to make better decisions inside your unit. And it might even help you to encounter useful features of the platform on which you are working daily. This will help you to be a faster and better developer further on.

Furthermore, team programmings are a great place to ask specific questions, for example about a feature of the used testing framework.

Surfacing potential cross-unit problems

When people from different units meet and work together, they might run into problems. Be it slow builds, flaky tests or some strange IDE behaviour. Often, while one person is experiencing this issue, others might confirm that they had it in the past or are still struggling with it.

This not only sparks a great opportunity for another cross-unit team programming to solve the underlying issue, but also is valuable for people in platform units2, who could address this topic as part of their unit work. Therefore, team programmings with people from various units also help platform units to work on the right things.

And of course, sometimes you happen to have someone in the room who knows the solution to the problem, that was annoying but not annoying enough to ask on Slack.

Finding solutions for broader or more complicated topics

Especially when topics are affecting multiple units, it is much easier to develop a good solution when you have people from all affected units in the room. An example for such a topic is refactoring a shared codebase into modules that are in alignment with the company structure and ownership of these areas.

Furthermore, when problems are complicated, it is very valuable to discuss them with a crowd of intelligent people. In contrast to meetings, where you just discuss, in a team programming you directly try-out ideas hands-on and discuss challenges as they arise. This helps everybody to develop a shared understanding, surface questions and potential edge-cases. Moreover, it distributes the most difficult task, the thinking, to many people.

As we all know, diversity matters. Therefore, bringing people from different backgrounds, domains, and units into the same room and onto the same problem, can lead to astonishing results.

Meeting your colleagues

Finally, meeting colleagues with whom you are not working daily is always a good use of your time, as it helps you, to get to know them professionally. Furthermore, you might also get insights in their reality and into how they perceive your system and what their challenges are. This creates empathy, but also sparks opportunities for improvement.

This is especially true in remote companies or when you are not sitting all in the same room and have lunch together anyway.

Conclusion

Cross-unit team programmings are extremely valuable, both, for developers and the company in which they are working.

If you consider yourself a leader in tech, I would like to invite you to engage in team programmings and encourage the people around you, to do the same.

You might be surprised, what will happen then.

What are your experiences with team programmings? Let me know in the comments or reach out via LinkedIn or Twitter. Sharing highly appreciated!

1. This person is the developer themselves, in almost all cases.
2. https://teamtopologies.com/key-concepts