Work with others when you can

It’s always better to work with other people than to do the work on your own.

I’ve been working on another project for about a year now. I recently finished a period when I was able to work alongside someone else for about six weeks. That was a good change. It would be good to do that again more regularly, if not permanently.

For now, I just want to go over how the work change from solo to partner work. As I get these ideas out of my head, maybe it will also help you see how you might learn from my experience.

Solo work is slow work

I worked on my own as this is unfunded work. It might turn into something, that is the dream. As there is no money, it’s hard to ask people to give up their time on a regular basis to work with me on this.

On your own you do all of the tasks, and all of the roles. My routine was to add one more piece of functionality to the application. This meant learning as I developed, which is slow. This was a repeated process of start/stop. I would add the new part and then add tests, and then run it the app. Then add a new piece of functionality. Then stop as something now broke as I added the component in the wrong way. This means digging through new materials to find a new way to do what I want to do. Then refactor the old code. Add new tests. Modify the old tests. Check it all still works correctly. Then review and revise the readme file so that I can use what I learned when I pass this onto someone else in the future.

This process is not elegant. It works, it is sometimes fun. It is often frustrating when you find a part that is not working, and you struggle to find a solution. You experiment, and find those don’t work either.

Part of the struggle is because you’re on your own. There isn’t a partner to bounce ideas off of, and to provide another perspective. Yes, you can talk to the rubber duck, or maybe find someone in a meet up, but this is not quite the same. People in other groups, aren’t in the same boat as you, working to the same goals.

Partners means you go faster

With a partner you have someone to share the highs and the lows. You are not alone, so there are two heads to think through the issues. You can collaborate as a team of two.

Now you can work side-by side on the same parts together. You can resolve issues more smoothly, and also refine work more effectively too, as there are two perspectives on the issues.

Yes, you’re still doing the same process: pick new component to add, develop that learning the new parts as required, then the tests, and refactoring once it is all working correctly. This doesn’t change.

The change is having someone who is there with you. Someone to offer another perspective, and to share the joy and frustration. Someone who can offer another voice on what do we do next.

Two people doing separate parts is two solo workers

We do the same work together to benefit from two heads on the task. We do not do two separate things that are later merged. That is the same as slow solo work. That is a poor choice.

Two solo workers mean you miss out on the option to talk together about the same challenges and issues. You’d both be working on different things, so would have different perspectives on different challenges.

Grow from pair to ensemble or mob

At some point, funding permitting the goal is to turn our pair into an ensemble team of five or six people. We’d all work together on the same parts and speed along as we’d have five or six heads addressing the current challenge.

We’ll see. Hopefully that happens.

Guide your people to pairing and mobbing

Move your people to pairing or mobbing to speed up the flow of your work. At the end of the day it is always about getting work out the door and into people’s browsers or mobiles. You finishing your piece is only a step in that direction. The longer you take to get it out the door, the slower is the flow of work. Working in pairs and mobs aids this mission along with trunk-based development. This has been repeatedly proven by DORA and the work of Dave Farley, and others.

---