I agree that full pairing does make remote working harder, and the hours should be fixed, but we've been doing promiscuous pairing for a few months now to achieve 'beginner's mind' and that has been just as effective as 'flow', and more consistent to achieve. https://engineering.itpro.tv/2018/12/07/our-first-experiment...
I've been at places that do those too. But they weren't the environment that has enabled my best work.
In particular, PRs and design sessions were/are a context switch which add friction. Even when pairing, however, we'd occasionally have team-wide design sessions, depending on the problem.
And it isn’t a context switch to have someone right next to you hovering while you are trying to develop? What context switch? You do a high level design before you start. Do you really need someone over your shoulder to make sure you can turn requirements into code?
> someone right next to you hovering while you are trying to develop
The pair is a collaboration. They develop together.
> Do you really need someone over your shoulder to make sure you can turn requirements into code?
I listed numerous advantages (and some disadvantages), none of which implied pairing was necessary. I'm merely answering OP's question on which environment has enabled my best work.
I'm not advocating pairing (I'm no longer in a pairing team), not even saying it's the environment that will enable the best work for other people. Our hiring process included a pair programming task to try to gauge how well that person would work in a pairing team, though it's also something you get better with in time.
Do you really need to “develop together” to do most features? Most work that developers do isn’t writing complex leetCode algorithms. Are you really saying you aren’t capable of turning requirements into software design by yourself?
You seem resistant to the idea of pair programming. I'm assuming you've done very little of it in your impressive career. As a fellow software engineer, I'm surprised you would be so resistant to something you have so little experience in. I'm not trying to convince you to pair program, I'm trying to convince you to read up on it and find out why others think it's great. 'Others' including some very skilled software engineers like Kent Beck. But from his own mouth, "pair programming works best with a large uncertain search space of problems and solutions. the closer to a solved problem, the less it helps" https://twitter.com/kentbeck/status/253532726714580992?lang=...
Most problems that developers face every day are solved problems just in a different domain or with changes around the edge based on requirements.
I have no problem with collaboration - ie I’m working side by side war room style with one person doing the front end, the other doing the back end, the QA person testing, etc.
Do you really need to pair to write yet another software as a service CRUD app?
My experience is that PRs quickly turn into a chokepoint which breeds delays and rework. Genuine bugs are rarely found, almost all the feedback is idiom and clarity -- valuable, but I can get the same feedback synchronously from a pair.
Note the reference to frequently committing to HEAD. That's not an accident, it encourages everyone to rebase frequently, keep changes small and to surface problems almost immediately. Whereas PRs quickly go stale and it turns into a game to try and get your PR in first.
In my experience of the past 5 years: yes. Substantially better idea-to-production latency, given a high minimum standard for releaseability.
Little's Law is instructive. There are two ways to increase throughput in a system. One is to reduce latency. The other is to increase in-process inventory. They have very different dynamics.
Most software development like everything else is a combination of inspiration and perspiration. How much time is spent in average day coming up with “ideas” versus just doing the work?
Or putting it in production terms, the number of people coming up with ideas for the iPhone in Cupertino is dwarfed by the number of people building them in China.
That you don’t need pair programming to do much of the grunt work that’s involved in development. Do you really need help making sure you write a for loop correctly?
I do if I'm about to do it wrong, or if something other than a loop might be better, or to write the test that drives it out, or to show me a trick I didn't know, or to get me unstuck, or to tell me there's a library function that lets us skip a loop, or ...
Is your argument that I don't know how pairing works? Because my estimate is that I have around 8,000 hours practicing it at this point, which I suspect may be 8,000 hours or so more than your own professional pairing experience. It's possible that I've been sleep-walking through the whole thing, but unlikely. One of the dozens of intelligent, helpful people I've worked with would've pointed it out.
I’ve been writing code for over 30 years including two assembly language instruction sets (one before going to high school), and C on 4 platforms. I’ve been using my preferred language C# for a decade and JavaScript since it was introduced by Netscape in the 90s. I think I’m capable of writing decent performant code without pairing....
I think I’m capable of writing decent performant code without pairing....
You think you are, but you've never tested this thought and scoff at the idea that you could be wrong, despite being told from experienced people who have tested it that you are wrong?
Is your argument seriously "I've never done it, but it doesn't work" to someone saying "I've done lots of it and it works well"?
Again, seeing that my first experience as a hobbyist was rewriting programs in assembly in the 80s that were too slow in higher languages on a 1Mhz 65C02 based computer, my second job as a professional was dissecting C compiler output to see how I could optimize the code generated or at times rewrite it in x86 assembly (custom printer drivers for industrial printers) and my third job was optimizing a proprietary compiler/IDE for Windows Mobile devices. I think I have a little more experience optimizing code than someone who has been doing it “for six years”.
This is finding your identity as a performance programmer challenged, and defending your identity instead.
"That sounds stupid, but they claim it's good, so I'll try it and see if I can learn anything".
"look at my credentials, don't question me, this other person can't know anything I don't, how dare anyone suggest I can learn anything from anyone else, don't you know who I am? Also they're a n00b."
You act as if I’ve never sat with another developer brainstorming which is different than constant pair programming. I wasn’t the one who bragged about six whole years of experience
In my anger I turned this into a measuring contest.
I think what you're reading is me saying "it's impossible to write good code without a pair", which (a) isn't true and (b) isn't what I said.
What I'm reading is that you say pairing is strictly less effective than soloing, which (a) isn't true and (b) isn't true.
If we were talking about professionally programming in assembly language, I would take your views seriously because of your relevant experience in that matter. In doing so I might not agree and I would very likely be wrong, but I would acknowledge your expertise on that topic.
What I ask is the same courtesy when it comes to pairing.
The opposite of “pair programming” isn’t “developing solo”.
Like I said above, most problems that developers are working on everyday isn’t some complex algorithm it’s translating business requirements to code.
Collaboration is often definitely better than developing solo but it isn’t “pair programming”. But developing solo can be faster. The more developers you add to a feature, the more communication and coordination overhead you have (The Mythical Man Month a book written in the 60s). Honestly, we’ve found that three people working on three separate features solo can get more done than three people working on the same feature over the same amount of time. Again we make it a point to switch up so we can see the whole picture.
When the product owner comes in and realizes we didn’t consider something, it’s almost always faster to have that one person who knows how the change will affect the whole stack - UI/Back end/database/deployment, infrastructure requirements than to have five people trying to coordinate the change.
Collobaration can mean “war rooming” or “swarming”.
War rooming for example is getting your back end and front end developer together in a room along with your QA person, your Devops, and your product owner working on their piece of the feature, rapidly iterating.
I work on a team where each developer can easily go back and forth between the three languages we use (JS/C#/Python), front end development in React, database design, Devops with CloudFormation, CodeBuild, Code Deploy and Code Pipeline sometime we will split up the parts. Other times one person will do a quick design session, do the whole stack, do a post review along with design docs in MarkDown.
If you have well rounded developers, they will often switch roles on the next feature just to have knowledge and a different perspective.
Pairing removes many barriers to development:
* built-in code review
* knowledge sharing: removes silos
* helps avoids overengineering (few pairs have the same overengineering idea, so you tend to settle on a decent un-overengineered solution)
TDD, which I'm not fully convinced on, acts a clock for pairs: one person writes a test, one person writes the implementation, flip roles, repeat.
Other XP practices: everyone works at HEAD, deploys from HEAD, retrospectives.
Small features went from discussing with customer, to writing the implementation, tests, monitoring, and deploying it in half a day.
The disadvantages of ~full pairing: remote is harder to support, I missed getting into flow, fixed working hours.