English Russian

THE ART OF MATING WITH YOUR COLLEAGUES

At the end of 2022 we started experimenting with pair programming.

At first everything looked perfect: tasks get solved faster, quality goes up, the team is tighter. The first months confirmed it. We talked more, shared knowledge, learned from each other.

Then after six months the problems showed up. Working in pairs all the time was exhausting. People started avoiding it on simple tasks, just to get a breather. The director could not understand why two people work on one task while the speed does not double.

We had to revisit the approach.

Now we use pair work only for hard tasks. If something unusual or deep has to be figured out, two people join in. Pair programming became a tool for special cases.

And then a thought arrived: what if pair programming is only part of something bigger? A universal method that fits any hard task — engineering, business or creative. For many people this is probably obvious and has been for years. For me it was a discovery. Strip the specific context away and a simple but powerful idea is left…

Pair work

Pair work creates conditions you cannot reach alone. People exchange experience, spot mistakes, learn right there in the process.

When a person works alone, they only see their part of the task. It is hard for them to hold the whole context or to notice the weak spots. In a pair one offers an idea and the other checks it immediately. Together they find the better solution faster.

Talking tasks through out loud helps surface problems early. What feels logical inside your head does not always survive a dialogue. Problems come up before they turn into bugs.

Pair work helps people learn. Knowledge is passed not through long instructions but right in the middle of a discussion. It is fast, it applies here and now, and it works.

On top of that, procrastinating together is nearly impossible. Shame in front of your partner will not let you drift off into social media. The work goes faster and with more focus.

But the most valuable part is that people start understanding each other better. Pair work creates an informal space where colleagues interact without formal team building. That makes the team stronger.

Pair work is a way to understand a task more deeply and to find the simple, correct solution. It makes the process clear and the result solid.

Mating instructions

1. Start with yourself, start small

Do not try to roll pair work out across the whole team at once. That creates unnecessary resistance and makes everything harder.

Find one person who is willing to try. I arranged it with Dzimka, for example. I offered to work on a new task together. We discussed the problem, agreed who does what, and started.

That is how it all got going: the task was solved faster and with fewer corrections. Dzimka liked it, and he was happy to try the approach with the other guys.

2. Set the rules

For a practice to settle in, it needs regulations, reference points and best practices. I decided we needed some kind of "Mandatory development process". The idea was simple: give newcomers clear steps so they get up to speed faster. Of course it was "imposed" by me rather than worked out together.

On paper the process looked flawless: everything thought through, everything covered. Here is how it looked:

Mandatory development process

Take a task.
Find a pair.
Call the client and write the conversation down in the ticket.
1. Find out what the problem is and why it should be solved. And whether it can be solved without IT at all.
2. Find out the goal: what we want to achieve, and why achieving it will make somebody happy and calm.
3. Find out how the client will know we did not lie to them when we said it was done: how they are going to check that it worked.
4. Get the list of experts and stakeholders who could give more information. We are most interested in people who can tell us that our solution might break something or break the law.
5. Either right away or after a quick huddle, propose a solution. The solution must be the most miserable, barely working one that still solves the task without breaking the law. Which means we refuse to build any bells and whistles in the first iteration of a task. You have to bug the h*ll out of the client with the question "What the f*ck for?".
Call the experts and the stakeholders. The experts on general questions are: CEO, COO, team lead, risk director.
If during the discussion anybody did not understand or did not know something about our product, code or business, that person writes a note into the documentation. The shorter the better.
Write the text of the test cases straight into the comments in Jira. Literally:

As an admin with such and such rights I go into the admin panel, into this section.

I press the (not yet existing) button that says "Download report".

The page reloads and the text "Report successfully scheduled" appears.

You have to write the main positive scenario and a couple of scenarios where an error is expected. Do not go overboard.

Automate the scenarios with acceptance tests. Which means you write a test for functionality that does not exist yet.
Discuss the architecture with your pair: which components you will create and reuse, what their interfaces will be. Come up with the class and method names. Draw a diagram in Miro — crooked, sloppy, anywhere off to the side.
Discuss how the finished functionality will be switched off. Which means thinking through feature flags, so unfinished code can be poured into production without worrying that it will start working and break everything. Write the launch strategy down in the ticket.
You can write the code together or separately, as you like. The easiest way to split the work is by module and by class.
Write very short commits. Push straight to master.
You can write unit tests or not. If you have a decent acceptance test, that is enough.
As soon as anything at all is ready in production — crooked, sloppy, with the developers standing by to tune things — we call the client directly and show them. We need to find out as fast as possible whether we are building c*ap. No pompous demos, just quietly and quickly getting feedback.
When the solution starts looking final, refactor the code. The emphasis is not on the beauty inside the methods but on modularity and on being able to describe in words what each element does. What matters is that later, glancing over the structure of the components and their interfaces, we can remember what is going on in there.

Of course the process did not become "mandatory". Rules handed down "from above" rarely take root.

I did not insist on following them. Everyone knew they existed. I knew they were not followed. Everyone knew that I knew. And I was fine with it. It even pleased me a little: the team was capable of ignoring idiotic imposed rules.

3. Learn to hate it and shake the nonsense off

Any practice is a crutch. We solve one problem and give birth to a pile of side effects, which sometimes turn out worse than the problem itself.

The same thing happened with pair work. The guys started getting tired of long sessions. They avoided pairing on tasks that looked clear to them. Our CEO was losing patience, not understanding why two developers do the same work, and do it at less than double the speed.

We came to the conclusion that pair work in its original form did not fit any more. It had to be shrunk.

Now the guys call for a partner only on big or hard tasks. The rest of the time they work alone. Pair work became a tool for special cases instead of a universal rule. The point is to use it where it actually pays off.

Conclusion

Pair work is not only for developers. It is a way to solve tasks together, where one person may miss something important and the other will see it.

It is useful where you need unusual solutions or have to dig into something hard. Engineering projects, creative tasks, even a strategy discussion — pair work helps.

Try it in your own field. It may become a handy tool that makes the hard things simpler and the work more interesting.