Frühere Suchanfragen
Suchoptionen
Verwaltet von:
For months, a coworker had been bringing up #PairProgramming at our sprint retrospectives, so we tried it out this sprint.
So far, it is fun and also efficient/productive.
For me, it is a totally different workstyle, not so much because of the pairing itself, but because of the focussed structure that it enforces on the work day. Usually, while I had been working on one main task as well, I was always the first to jump in to help with whatever someone came up on the company Slack. Plus various chores around the house #RemoteWork.
So I was much more multi-tasked and "agile" before.
And you have to be much more strict about scheduling your day.
On the tooling side, we are not using any special #PairProgramming software yet, and I have a hunch that we won't.
You can get very far with very little friction with just screen sharing over a #Slack huddle. We can talk to each-other, both see what the "driver" is seeing, we cannot type into the editor at the same time, but the "watcher" can draw on the screen.
As a side-effect of this, I got to experience "AI" coding assistants.
I am staying away from that tech because it is a net-negative societally, environmentally, legally, ethically and all-around, but my coworker is using it (with encouragement from management who are in love with the idea).
So #Copilot pops up in our #PairProgramming sessions.
I have to admit the code and commit message suggestions it makes are surprisingly good. It helps. If you ignore the big picture, it would be tempting.
A pleasant side-effect of #PairProgramming is that it automatically improves the quality of code review and the need to wait for merge request approvals.
Since every line of code in the merge request is the result of negotiation and discussion between two developers, the four-eyes-principle is already satisfied and the merge request can be approved directly.
Without, it would either be rubber-stamped not to cause delays or require quite a lot of time on the reviewer to dive into the details.
I am a #laptop person. Every couple of years I try to get a desktop machine, but it never feels right. Same with attaching monitors to the laptop. Too much hassle, and too much switching back and forth when moving around. With a good MacBook, everything is always right there and always works.
But I set up an external monitor for #PairProgramming now, so that I can watch the shared screen and also look at other windows. And it helps a lot with #Slack, too, whose window management is very clumsy.
@thilo we've tried that some years back. It turned out, that the overall productivity dropped significantly. Often one of the partners spaced out after a few minutes, lost concentration and got bored. Also people have different working modes, some think more broad, others have a depth first approach, some need more breaks than others etc. It's hard to find compatible partners.
Let's just say that over all neither code quality nor productivity increased. It didn't make sense for us to continue.
@vvv I can totally see that. I can attest that it is a lot more tiring than my normal workstyle. And I have to actively force myself to shut down all "distractions". Which may not be sustainable full-time in the long run.
I think it can work, but only in moderation, with some form of rotation with "normal work". And only for tasks that benefit from having two minds bouncing off ideas in real-time. Because that is where I see the efficiency. More and faster code review, design discussions etc.