I identify mostly as a non-programmer. Yet two weeks into a new job I’m already learning and contributing to Python and C++ -code in detail. The method that enables me to do this is mob programming. This is the idea of having a group of people working together on one computer on a task, taking it in turns to type for the team whilst others instruct. For an idea to get from one’s head to the computer, it flows through someone else’s hands.

This article shares key insights from my one year journey on learning programming by osmosis: just being around programmers working on code, without intention of learning. As a result, it rewrote my history with things I had forgotten and dismissed from my past. I hope it serves as an inspiration to programmers in inviting non-programmers to learn code a layer at a time, immersed in the experience of creating software as a group, to transform the ability to deliver. Lessons specific to skill sets are passed both ways, and while I learn from others, they learn from me, leaving everyone better off after the experience.


Finding Mob Programming

Many different roles contribute to building software: product owners, business specialists, testers. Yet knowledge of programming keeps these roles at a distance. I did not come to programming through wanting to program and taking courses on it.  I came to it through working with programmers in a style called mob programming.

As a tester with my team of nine developers, it was clear I was different. I wasn’t particularly keen on learning programming. There was more than plenty of work in the feedback through empirical evidence and exploration that is my specialty, which I’ve developed in depth over two decades. I’m an excellent exploratory tester and my team’s developers have always been my friends with a pickup truck that I can call in for assistance on anything where code needs to be created. Besides being the only non-programmer, I was also the only woman. This in a team where some people would occasionally spout out things like “women only write comments in code”. It was not exactly an inviting starting position.

I did not like programming, but through my hobbies since the age of twelve and my computer science studies (that killed my interest in programming) I had written code in twelve languages. There was already a small change in how I looked at things for my daughter’s sake. I did not want to transfer my dislike of code to a 7-year old about to be embedded in a teaching curriculum where programming is everywhere. Programming is a mandatory part of Finnish curriculum now.

Time for change

The real change, however, started with a talk in a conference I organized. I had invited Woody Zuill to speak, the discoverer of mob programming. The idea of the whole team working on a single task together on one computer sounded ridiculous. Yet as ridiculous as it seemed, I thought it could be a way for my team to learn from one another as well a great team building opportunity. Instead of taking someone else’s word, we could experience them first hand. And it wasn’t like we had to commit for a lifetime, just to try it out once or twice.


The first experience

With some discussions, my team agreed to try it out. I knew I would be out of my comfort zone – having to be in front of computer working on code. Our first task was to refactor some of our code with Extract Method and Rename automatic refactorings. We had an experienced mob facilitator, Llewellyn Falco, lead the session. While not on the keyboard, I found myself able to comment on the names from the domain. While on the keyboard, I noticed with each round that I was picking things up: keyboard shortcuts, ways to navigate, programming concepts, without anyone really explaining them to me. In the retrospective, I could reflect on my learning and realized that not only was I picking up things that I didn’t know before, everyone else was doing that too.

I felt safe in a group, as I did not need to be fully engaged at any time. I was always supported by a group. The negative remarks on gender did not come out in a group, whereas they had been a regular thing in a more private pairing setting.

From the first experience, my team extended this to a weekly learning activity. I took it further and organized various mob programming sessions with the programming community on different programming techniques and languages. For example learning TDD and working with legacy code in a hands-on manner. Similarly, my team learned to explore the product to identify problems, and we had several occasions where my presence in the room fixed an expensive mistake-in-waiting in only half a sentence. Finding a problem like this early on led to more efficient and productive way of working for everyone. Although it seems inefficient to have so many people working on one thing at the same time, time was saved time in avoiding context switching and passing feedback back and forth. We had increased focus, more quality, and we developed much faster and with less future problems.  


An all female hackathon

I took the idea of mob programming to a weekend hackathon. There I convinced my fellow team mates to try it out, with success on three out of four of the group. I avoided setting the expectations of me being a non-programmer and just joined in with whatever programming skills I had, without disclaimers. There was a woman with less experience with code than me, as she had never looked at code before.

Out of that weekend, I came out with four major realizations:

  • The best programmer outside the mob only contributed graphics. In the mob, we were adding a feature at a time and committing regularly. The best programmer found it hard not to have a module of her own to work on. There was no long-term plan for incrementally developed software and the version kept changing under her. We tried summarizing the lessons on the technology we used for her, but she kept hitting problems that blocked her.
  • I passed off as a programmer. No-one noticed I wasn’t one. The reason was: I had become one. I realized that programming is like writing. Getting started is easy, and it takes a lifetime to get good at.
  • The non-programmer felt like an equal contributor. Her experience was that the code created was just as much hers as any of the others. That is a powerful experience. She learned the basics with us through typing for us, and reflecting with us.
  • We had working software. Not all groups had the same luxury. In the mob, we had the discipline to have not just code, but working code to a scope that could vary depending on how much time we had to add more functionality.


My main lessons

Cognitive dissonance is a powerful tool

The experiences of working with a mob transformed how I perceived myself over a period of six months. No amount of convincing and rational arguments on how much fun programming is could have done that. When my actions and beliefs are not in sync, my beliefs change. And that is what mob programming did to me. It made me a programmer, through osmosis, and got me started on a long journey of always improving.


Non-programmers have a lot to contribute

I saw that while I was learning a lot, I was also contributing. As a tester, I had information about intents of the real users that seemed mysterious to my programmer colleagues. We would test better while programming, just because I was there. We would avoid mistakes that were about to  happen, just because I was there. I could give feedback without egos in play, and we could all learn skills from one another. Even me being slow was a positive thing – it made the other programmers more deliberate and thoughtful in their actions. They shared the realization that they created better code while slower. I ended up really proud of how much better my developers learned to test with our shared mobbing time.


The team got a lot out of it

I wasn’t the only one who learned – everyone in the team picked up different things. It was a pleasure to see how an individual’s ability to add unit or selenium tests expanded to a team skill set. Also how many times we found better libraries that only one of us had been aware of before.

We slowly moved from working on technical debt and cleaning up to a shared standard, to having technical assets in the form of libraries that would enable us to do things faster.

Everyone got their voices into the code better. We worked with the rule that if we had several ideas of how a problem could be approached, instead of arguing we would do both while we had the least practical information on how it would turn out. It was surprising to notice that someone who would fight to the bitter end about an implementation was able to accept the alternative once both were available. This was not just because people would lower their standards.

We also learned that when one of us did not feel like contributing in a mob format at first, it was a good idea to let them opt-out. The party-like nature of the sessions and the evidence of the rest of us bonding and learning inevitably drew these non-participators back in on their own initiative later on.   


Mob Programming as a practical tool of diversity

Mob programming is a great way to introduce new people to programming, or testing for that matter. It transfers a lot of the tacit knowledge otherwise difficult to share. It brings the best of us to the work we do, as opposed to the most of each individual. While working together, we can remove a lot of the rework with fast and timely feedback. We raise our collective competence, allowing individuals to use specialized skills. We used a rule “learning or contributing” to give a great guideline in thinking of when a mob is doing what it is supposed to.

As software is such a big part of our society’s present and future, we need all hands on deck when creating it. We need to find ways of bridging roles without telling others ‘everyone just needs to be a programmer’. In a mob format, I learned that while I picked up my hidden interest in programming, I would have been a valuable contributor even without it. There was a struggle for both me to go do things I thought I wouldn’t enjoy, and the team to work in a setting they were not used to. It was worth the struggle to remove the distance between myself and the programmers.

Just adding more diversity to the field of software development isn’t enough if those people struggle to get their voices heard. We need to do more than make the world of coding look diverse. With mob programming we can use that diversity to innovate the world of coding overall. (Props on this thought to Kelly Furness, who was in the audience at my DevoxxUK talk).
It’s not just learning programming by osmosis, but the learning is mutual. Give it a chance.

Learning Programming through Osmosis

About The Author
- Software specialist with soft spots for hands-on testing, helping teams grow and building successful products and businesses. Agile, Lean, Lean startup are mindsets I work with. I work towards happiness and wellbeing of people who create software - not just programmers.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>