Software teaming

This is how I was introduced to software teaming.

When I was a bit younger, I had an idea of what kind of a software professional I should be in the future. In my mind, the perfect programmer was a ‘lone wolf’ with an exceptional command of data structures and algorithms, all the popular programming paradigms, the theory of computation, and so on. They could solve any problem thrown at them. They would just take the problem, seclude themselves in a metaphorical cave (a cubicle in real life), work on the problem, and then come back after a while with the perfect solution. No code review was needed because that would mean there would’ve been things the programmer didn’t know yet. No collaboration with other developers was needed because, well, what would they know? This person was already the perfect 10x developer.

When I started working professionally in a software company, I learned quite quickly how little I knew. However, my ideal of a programmer wasn’t challenged. If anything, the work environment supported that kind of ideal. All the developers worked in their cubicles most of the time. The only time they would gather together to collaborate was during ceremonies like daily stand-ups, sprint plannings, or retrospectives. Nobody seemed to like those things either, they were more like a necessary evil. Once finished, people seemed happy to go back to their cubicles to continue their work in isolation.

It seemed like the perfect place to foster the stereotypical solo developer. Of course, I could ask questions from my co-workers and they would be happy to help most of the time. But in the end, it was my responsibility to finish my tasks and all the problems related to them. The tasks would get gradually more difficult and soon I was designing and implementing large pieces of functionality all by myself.

In the end, this kind of solo development is tough. There is a lot of pressure on you to find solutions to the problems. If you can’t do it, in the worst case your mental health can take a hit. I found myself thinking about work-related problems a lot at home. Sometimes I would even spend a substantial amount of my free time searching for solutions, maybe even trying them out. It wasn’t sustainable and I paid the price for it.

Eventually, I moved on. I joined a workplace where I was introduced to mob programming. Simply put, it’s like pair programming with more than two people. The idea is that the whole team (hopefully not more than 5 people) works on the same problem, on the same computer, typically in front of a big screen.

My initial reaction to mob programming was strong and negative. It was at odds with my “10x developer” ideal. And how could it possibly be productive to have five people working on the same thing? Why not just split up and work on five different things simultaneously? I came up with all sorts of excuses for why I didn’t like the idea. But I think the real reason was the lack of psychological safety.

Up until that point, I had worked in a way where collaboration didn’t exist. People would mostly work alone and would only talk to each other during the mandatory ceremonies, or when they couldn’t solve a problem on their own. There was no incentive to work together. In fact, in some cases, it was even frowned upon. I remember a co-worker telling me they got scolded for having two people troubleshoot a bug something at the same computer.

When you work in that kind of environment for years, surely it will become the norm for you. Anything that deviates from that norm will start raising your eyebrows, and you start justifying to yourself why that way of working must be wrong.

At my new workplace, it took several months to get to know my new team. At first, I would still work mostly alone, but I would at least ask others to review my code (in person, on my computer) before I would commit it. It took a long time to be comfortable to show my unfinished, crappy code. I suspect that for some people, this could be an impossible obstacle.

After a while, I started pair programming with another developer. Following the Driver–Navigator pattern changes everything. The Navigator tells the Driver what they want to achieve next, and the Driver merely translates that intent into code. In this setup, there is no longer my code. It’s our code. If the code is crappy, unoptimized, and ugly, it is because we decided to make it that way. For me, this shift in mindset was the key to giving up most of my insecurities.

Mob programming is an extension of pair programming. If you still follow the Driver–Navigator pattern, then there’s one Driver and the rest of the group are Navigators. The Navigators are solving the problem, making the decisions and finally telling the Driver what to do. This joint ownership and responsibility for the code makes it even more powerful than pair programming when you think about psychological safety.

When we make decisions as a team, I no longer feel the burden of responsibility as heavily compared to if I were working alone. At home, I don’t think about work problems as often, because I know that the next day there will be a whole team solving the problem together. The burden is not only on me to find a solution to the problems.

Being introduced to this way of working was the turning point in my career. It’s one of those moments that divide my professional career into ‘before’ and ‘after’. It was such a huge mental shift that it opened doors in my mind to other practices as well.

Nowadays, I’m actively looking for ways to improve the way I work. I also try to keep my mind open to new things. I feel like I owe my current perspective to the horrible first experience I had with mob programming, and my reluctant journey to eventually accept and embrace it.