in Tech

Mobbing @ Tagged

Where it started

It’s 2 a.m. on a Friday. You have been sitting in a windowless computer lab in the basement of the CS department for almost the entire day. You and your three project partners are not out that night because every single one of you really loves writing low-level C code to optimize that matrix multiplication assignment due next week. You argue about implementation, make design decisions together, pass the keyboard back-and-forth – everyone’s eyes glued to one screen. You’re completely in the zone. You’re in sync. You have flow.

Achieving that flow is one of the hardest problems in the workplace. There are countless theories as to what is the best way to get there. But what if you just tried to do exactly what you did in college? That’s what we did at Tagged, and it worked.

Mob programming @ Tagged

At the end of last year we released a completely redesigned version of the Tagged Newsfeed to our desktop web users. The front-end was rewritten from scratch using Angular JS, resulting in some big performance improvements. With an increase in new comments, likes and photo uploads we saw how much Tagged users engage with the sleeker Newsfeed and given our increasingly mobile userbase, we decided to bring this experience to mobile.

I was one of the three engineers tasked with delivering this feature. With a relatively small team, we decided to experiment with the development process. During the planning stage, we agreed to reinforce our commitment to following rudimentary design principles:

  1. Maintainability
  2. Extendibility
  3. Reuse

One of our team members had recently joined the organization and wasn’t familiar with the peculiarities of our codebase and process. She came to us with a strong javascript background, but she hadn’t done much backend development. Since the architecture required we build backend components first, we needed to make a lot of early design decisions. We collaborated on these decisions and used our shared time to bring her up to speed on PHP.

We adapted many PP concepts. The driver worked on a laptop connected to an overhead screen that everyone could see, and the two navigators designed and validated the driver’s implementation of the task being worked on. We switched roles often, usually after a subfeature was finished. This process occurred naturally as we tried to find what worked.

Other employees soon noticed the three of us holed up in the Tagged gaming room for days at a time and started wondering what we were up to, so we shared our new method with other developers and it got a lot of traction.

Tagged encourages experimentation with new technologies and methods, so we soon had our own dedicated mobbing room. A few weeks later, Tagged invited Woody Zuill, who coined the phrase “Mob Programming,” to host a mobbing workshop with the entire engineering team.

We extracted several practical lessons from Woody’s workshop, including the following:

  1. Have a single mobbing workstation: We used to work on our own computers, which forced us to check out recent versions of the code after each pull. Sharing one computer eliminated this overhead.
  2. Continuous code review: Whenever we were done with a feature, we would put up a pull request and review it together as if it were someone else’s code before merging it into master.
  3. No need for stand-ups: All three of us knew what we worked on and what was planned for the day.
  4. Navigators do all the conceptual work: The driver is merely an input device that transcribes higher-level ideas and implementation details into working code.

Incorporating these and other tips from Woody helped us streamline our process and improve the component-level design of our feature. The navigators did most of the architecting, which allowed us to make collaborative high-level design decisions, complying with our stated goals. The best engineering practices always prevailed, as someone from the group would always catch some easy-to-oversee code smells. We would often hear:

“Hmm, we are using logic in the template, this code probably belongs in the controller,” and “This class is gonna be hard to test. We should directly inject the dependency so we can mock it out easily later,” and “What is this number ‘25’ you are passing to the method call? Make a descriptive class constant.”

We minimized slip-ups and had each other’s backs when it came to testing, designing and straight-up coding. Because we entered and remained in flow, we shipped this amazing feature to millions of users in just over a month.

With the feature done, every member of our mob is now an expert on Tagged’s mobile web Newsfeed. Should it be necessary to maintain or extend existing functionality, any one of us could easily get it done. Through mobbing, we produced easily-readable and well-documented code that even non-experts can follow and work with.

Albert Eloyan

Albert Eloyan is a Software Engineer I on the Tagged Web team.

More Posts