Indeed. Probably like, what, 10-20% of our time? Maybe 25%-30% on a good week?
I'll even argue the opposite: there are many ways to write code slowly that yield better results.
- sometimes, you are 'thinking slow'. A pause between two snippets is invaluable in pre-forming the logic in your head anyway, which rules out 99% of the supposed 'efficiency' of a l33t-script-kiddie.
- pair programming is literally 2x slower in terms of man-hours, and actually even worse if we consider that talking to someone is much slower than thinking to oneself. And yet... it produces great code and makes your programmers better.
> - sometimes, you are 'thinking slow'. A pause between two snippets is invaluable in pre-forming the logic in your head anyway, which rules out 99% of the supposed 'efficiency' of a l33t-script-kiddie.
This is precisely why I never learned to type faster. The time between my thinking and typing is spent auditing my thinking.
> - pair programming is literally 2x slower in terms of man-hours, and actually even worse if we consider that talking to someone is much slower than thinking to oneself. And yet... it produces great code and makes your programmers better.
Ehhh. A lot of programming is creative and imposing my creativity onto someone else (or having someone's styles/preferences imposed upon me) usually doesn't help much. Any time I've pair-programmed (~6 years of professional programming) my productivity dives down to 1/3 while my quality sometimes increases marginally. It's a low ROI in my experience which is why I'll never advocate for it. But I'll play ball if the org I'm working for embraces it. There are social/team-building/ other nontechnical benefits to consider as well (although I'd argue that tasks built specifically for these purposes would be more efficient).
“The time between my thinking and typing is spent auditing my thinking”
Apparently this isn't limited to code for you, what an eloquent way to put it. I'm definitely stealing this, thanks! ;)
“creative”
I hear you loud and clear, I tend to be the same. But pair-programming has its uses, imho, which become more obvious as a lead tbh. One fundamental premise for me: voluntary participation only, it's usually bad to force it on people.
Briefly and imho, there are two kinds: "true pair" as equals (or close enough), and "asymmetric" (more like mentor-mentee). Let's tackle the latter first:
- To onboard a new team member, it's invaluable in helping them build confidence fast, learn the codebase, and integrate the team's standards and "best practice" — more to-the-point and pleasant than reading a bunch of docs: have a co-worker tell it to you, like it is, on-the-fly and on a need-to basis. Saves loads of time searching in the dark. Typically short-term (first few weeks).
- Transfer: it dramatically raises the operational level of the mentee. It effectively 'multiplies' the mentor's superiority, 'spreads it' throughout the team so to speak, as other people pick up the good stuff directly from the mouth of the lion(s).
This can be long term, depends on who you've got. I love when juniors are free to pair-prog with a willing senior, you get them out of the green zone in months as opposed to a year or more.
The benefit compounds over time, if you're building a team, it's really second-to-none (no bootcamp, no code review, no nothing comes even close). You do 'lose' one member for some time, few hours per week, but it's often a welcome walk in the park for the senior, and a really good time for the junior. It's everything you can never get in school, because it's ad hoc training both for the job and the company/team's culture/standards.
Now for pair-prog 'as equals'. Again, as a free association between two people who choose each other.
The idea here is that in terms of human brain you've got twice the 'RAM' (attention, memory, etc) and twice the 'CPU' (raw 'intelligence'). So it works ideally like a distributed system (not a failover/HA!) where each person focuses on different aspects. There is typically not much room for 'style' or 'creativity' insofar as it's decided before we write, through discussion. When one writes, the other should not interject for small details like “why not inlining here? why this name and not that name?” unless it's not just preference but mistakes or architecture etc (“did you know you could avoid all that and just write <some idiomatic thing>?” — or “this is correct but here's how we'd rather write it: ..., because it's more readable / idiomatic”)
The point is to share the thought process, and then have one set of eyes writing while the other thinks. It's thinking even slower, using two brains if you will, not at the same level — one, writing, is bound to think 'closer' to the code, while the other, watching, is free to roam-think around, look up some other file, specs, etc. Even write docs as we go, which may save time later (there is no 'rule', I only care for what actually works in practice and everyone's different so...) E.g. I don't like pattern-shoving but finding one is a common 'eureka' by the observer.
(I'd typically want a common 'pair' machine + both bring their own laptop, if doing this in person, so that each is free to do stuff. Sometimes we just off the pair prog to go faster (when human goes monkey because we have to).
What I find is that:
- explaining my 'plan' before anything is written helps make it clearer, and spot mistakes early on.
- others generally have half the good ideas seen in the final code.
- working with someone who knows a language/framework/whatever tool better makes me better with it; but it works both ways, as explaining/teaching also makes me better.
- as you said, some tasks are well-suited for this exercise, others not so much (it's usually obvious once we start).
And it's really that, an "exercise" more than anything else. It's slow, like 2-3x slower, but you feel very solid. I don't have numbers but I'd say easily 50-75% less mistakes in the final code, and most importantly code that's almost certainly readable by others.
It gets really good when domain knowledge is much wider, e.g. I know http server stuff, and you know microservices well... you can see where this takes us quite naturally — hence, again, free association, let people talk, get to know each other's forte and weaknesses, and work in complementarity.
Sorry for a long piece. I just found so much benefits in pair programming that I have to share this stuff. More than skill, it builds self-confidence and awareness. You're not the same after pair programming for 'some time' on a regular basis (and by 'you' I don't mean the programmer, I mean the entire person). Because you've realized everyone's just as limited and capable as you, and suddenly there are much less artificial barriers in your mind. “I can do this” — why? because you've seen others do it first hand, picked up from them, saw them do the same with you, and eventually we feel more like humans just trying our best instead of doubting our every commit.
I am absolutely in love with this response. Thank you for taking time to produce this. This could be a blog post.
Your post has me looking back at the opt-in samples of my experience and realizing that when they were opt-in, I never considered them to be "pair programming". It's always just been "healthy onboarding" or "healthy collaboration". My current org's obsession with enforcing PP for its own sake as a measured performance metric has conditioned me to squirm when I hear the term, but that's just a branding/emotional response problem. Thank you for the beautifully articulated check.
Oooh! Can I copy the body of your comment into a post on my little project and credit you with a link back to this thread?! It should be seen and discussed by more people! I can do the same as a reddit post if you'd like, too.
If you wanted to set up a little blog beforehand in case people want to follow you, I can wait. whistles
I suppose you can always copy out your best or longest comments and post them as blog posts as is, and then later go back and update them appropriately. For any comments that overlap, just throw them all together into a single "blog post".
I'll even argue the opposite: there are many ways to write code slowly that yield better results.
- sometimes, you are 'thinking slow'. A pause between two snippets is invaluable in pre-forming the logic in your head anyway, which rules out 99% of the supposed 'efficiency' of a l33t-script-kiddie.
- pair programming is literally 2x slower in terms of man-hours, and actually even worse if we consider that talking to someone is much slower than thinking to oneself. And yet... it produces great code and makes your programmers better.