Getting Started with Group Programming
Observations from an experiment on working together
At Optimizely, hack weeks are an important part of our engineering culture. Twice a year, we break up the routine and prototype new ideas; it’s a great time to experiment technically as well as culturally. During our Hacky Holidays 2018, the team I worked with decided to try a new working style: mob programming.
What is mob programming anyway?
Pair programming is not something we’re unfamiliar with; in fact, it’s a fairly regular thing to pair up with another engineer to get work done. Mob programming is an extension of that model, where instead of having one driver and one navigator, you have one driver and the rest of the team are navigators (in our case, that was three other engineers). The role of driver is rotated around the team, so everyone has an opportunity to experience driving and navigating.
There are many benefits to mob programming, and some not so great parts, too. One of those downsides is definitely the name; “mob” feels very chaotic, violent, and negative — all characteristics of, well, a mob. Before we even started down the path of trying out mob programming, we decided to change the way we referred to it: group programming.
“Group” is at least more neutral than “mob,” even though you may not have great memories from group projects in school.
Unlike school projects, once we started group programming, we didn’t want to stop. It was a very fun way of working together on a single problem in the same place with the team.
Group programming does not slow you down
Despite having all four team members working on one problem all at once, we didn’t feel slowed down. What actually happened was we ended up moving at a pace we were all comfortable with.
In Python, it’s easy to make a typo and experience runtime issues, so we were able to mitigate those by having four brains on the same code. Besides catching mistakes, we were effectively reviewing the produced code in real-time. The team was on the same page with the design choices because we were able to discuss them before implementing them; we were all working on the same thing, so having the conversation was easy and didn’t feel like an interruption.
When the driver wasn’t sure how to solve a particular problem, the collective minds of the team enabled us to always make forward progress.
Group programming helps build relationships
One benefit of hack week is getting engineers together across different disciplines, but our team took it even further by programming together. We were able to work closely together with engineers we don’t usually get to, and we were able to exercise our muscle of working in distributed locations.
The team was made up of three engineers from San Francisco and one engineer from Austin. With Zoom, we were able to screen share the driver’s screen and the navigators were able to watch and contribute with ease.
Group programming grows the team together
While we were taking care of business as a team, we also noticed that there was an increase in questions that may not have been asked if we were all working independently. For example, we build dependencies for our project when we run “docker build” and while developing, we forgot to rebuild the image; this created an opportunity for one of the team members to ask why we had to run “docker-compose build” instead of just “docker-compose up”. Instead of searching through Slack for the answer to solve the ImportError problem, we were able to teach when to use different Docker commands and why you would need to run one or the other for our application.
Another benefit we discovered was learning how others debug and troubleshoot. Not everyone debugs the same way or asks the same questions, so by providing four different perspectives on a problem, the team was able to see how others ask questions and solve problems when they’re stuck. We can take what we’ve learned from our peers and apply them to our day-to-day to become more effective engineers.
Bringing group programming to your team
Ask how you want to work together
We didn’t realize how easy it was to get started with this working style. In fact, all it took was a question at the beginning of the week: how would we like to work as a team? Do we want to split up the work and work independently, or do we want to make progress when we’re all together?
Keep in mind that these are not mutually exclusive working styles. You can work independently on parts of a project and work as a group.
In your day-to-day work, you may jump into solving problems without considering the repercussions of working on your own and only collaborating when the PR is up. Move your team’s collaboration higher up in the development cycle to increase shared knowledge and productivity.
Identify “simple” and “complex” work
The way we implemented group programming for our project was by group programming on the complex parts and parallelizing on the simple parts. We also decided to combine “research” work into the “simple” bucket because we felt it would be better for one person to read up on the things, educate the team, and propose a decision, which we then were able to discuss, find agreement, and move forward together.
In our case, our simple/research work looked like:
- Set up branch that we’ll all work off of
- Add flask as a dependency to the application stack
- Choose a Flask REST API framework
Our complex work looked like:
- Implement an authentication mechanism
- Implement the resource for handling requests (our view layer)
- Create the SQLAlchemy model and SQL schema
- Write tests for the new resource
Communicate, communicate, communicate
While independent programming and group programming are not mutually exclusive working styles, it does not mean that someone on the team can go work on something independently without asking the team first if it’s okay. When a team member did go off and work on their own during hack week on a part of the project, it was expected that they would check in with the team first to avoid duplicating work, and review what they did with the group ASAP so context was shared while it was still fresh in the implementer’s head.
Try group programming with your team
We found group programming to be a fun change of pace where we were able to solve problems and write code together as a team. At the end of the week, we had a demo-able project and we felt like we improved as team members, collaborators, and engineers. In 2019, try group programming with your team; all it takes is a single question. Happy new year!
Thanks to Lauren Pappone, Sid Kakarla, and Jessica Ross for trying out group programming! It was a super fun hack week.
