Pair to improve flow

Work together on the same task improves development

I worked the last week with another developer on a project after some funding was approved. We have some more weeks together to achieve our goal. Happily it looks like we’ll succeed in this.

I often say people should pair on tasks. That’s what we’ve been doing. Two people sitting side by side with two laptops and a handy monitor to share screens as needed. Often my laptop is closed, or put to the side and we use the other one do our work. This is ideal.

This has been a great experience. Now I’m personally experiencing this. I now know what students told me, and what I witnessed as they collaborated together too. This is also what people in industry regularly suggest too, which is why I like it.

Gaining personal experience is useful

We are working and learning together. As we collaborate on the same piece of work we are to-ing and fro-ing with ideas in a steady flow of work. We keep adapting our work patterns as we focus on moving things forward. 

The focus on one shared piece of work means we benefit from our collective wisdom. One might start something, and the other suggestions a change. There are no egos in the way. We are both learning and having fun while we work. This is much more powerful than a scatter-gather approach.

We are aligned on a shared goal and by collaborating and clarifying our shared work we stay focused on delivering that goal. By talking we stay aligned and find a path forward. By focusing on the same piece of work we also keep in flow and find fast feedback is effortless too. We can pause, discuss, rethink, and then move back to the work in flow. This keeps development fast and smooth.

There is more to put into practice

As we’re still learning this platform and framework, we have more scope for building quality into our work. We are moving in the right direction, and getting better each day. We still have more to learn and incorporate in our practice.

We are using two laptops: one typing the other suggesting ideas and experimenting. This means lots of code tossed aside – who cares – as we clean up working spaces ahead of the new commit from the other person.

We are using trunk-based development so there is only one branch. This works well with a commit pulling in all edited files with ‘git commit -a -m ‘message’ followed by ‘git pull —rebase’ so any new code is merged automatically into our newest commits. This avoids issues. By committing often, moving more towards micro-commits, and pushing to remote every time too we keep merges tiny. 

Testing is lagging in our learning

We have a technical debt issue with testing. Learning as we go means there are fewer tests than desired. We’re still exploring testing frameworks for this platform, and finding issues that slow down testing. We keep trying and exploring; doing what we can as we learn more. As we learn more about the platform it becomes clearer how testing fits into the flow of work.

Some TDD and BDD happens, but not as much as I want. It is getting better, and will keep improving. What we’re doing so far has helped clarify design, and enabled useful refactoring. It provides sanity checks too. More is on the way.

We throw away work easily when we realise we’re going the wrong way. In any case, there are all of the previous commits too, which can be mined for that old bit of code that we find we need.

Find ways for your people to pair on their work

This is the way collaboration should be. Two people working side by side on the same piece of work moving it forward in a smooth flow of shared vision.

Tell this to your people and create opportunities for them to try it too. It’s fun and rewarding.

---