7 ms·

That just can't be more productive over the long term, though. Lets say, hypothetically, that you can use it to ramp any programmer up to being an expert on th

That just can't be more productive over the long term, though. Lets say, hypothetically, that you can use it to ramp any programmer up to being an expert on the system. Maybe that takes two months? Or even six months? Once you have a team full of experts, you're now spending two programmer hours to do every bit of work that could have been done in one programmer hour by a single expert. Unless you have such incredibly high turnover that the period to transform a developer into an expert is close to or less than the average tenure of an employee, in which case your team has other issues that likely need to be addressed, because why are people jumping ship so quickly if it's such a great place to work? (For example: If it takes six months to produce an expert, you'd need to have an average tenure of less than or equal to six months to really benefit from pairing; anything more and the 50% performance penalty has to eat into your overall productivity.) On top of that, I have never been at a job where it's taken me more than a week to get up to speed on a system, or at least to the point where I can simply ask the occasional question of the experts on a team to get me unstuck. Even if the average developer took a month or two, pairing beyond that point is simply fun and not more productive than two programmers developing independently. Unless one of the developers is otherwise likely to produce negative productivity on their own, I suppose. I've worked with that kind of developer as well, and the right answer is to eject them from your team, not pay other developers to babysit them.

troupe 4y ago
> That just can't be more productive over the long term, though. While you can type a lot more by having two people type in parallel, some programming is much heavier on the problem solving aspect of things and those types of problems are sometimes completed more rapidly with two people working together than with two people working separately.
zozbot234 4y ago
True expertise on a large, complex code base does not just take a few months; competence is best modeled as growing over long timespans, not as something that quickly reaches an "expert"-level ceiling. This is all the more true when-- as is often the case-- the codebase is a complicated legacy thing, full of accumulated "technical debt" and unneeded complexity of all sorts. This is not to say that 100% pair programming is always the answer, but doing it to some extent is likely warranted.
- dboreham 4y ago
  Someone with much more experience than me once told me it always takes a year. He turned out to be right, at least over the past 25 years.
- artificialLimbs 4y ago
  This is exactly what I'm currently jumping into as a 'new' dev. I've been coding for about 3-4 years, am working on an ANCIENT php in-house ERP (we're still running v5!), and find the technical debt/unneeded complexity more shocking by the day. I've been in this position 3 months and feel like I've barely even scratched the surface of what is going on under the hood. Teaming up for training is absolutely crucial at this time.
WindyCityBrew 4y ago
There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0, keeps people on task, offers (literally) immediate feedback. Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles. My guess as to why we don't see more adoption is 1) most developers aren't that fond of it, and 2) most managers do some quick gut check mental math and assume 2 programmers + 1 computer can't be equal to or greater than 2 programmers + 2 computers, that's nonsense, actual evidence be damned. edit to add: I agree with commenters that pairing is more demanding/draining than solo work. I shudder at the thought of anyone trying to pair for 8hrs straight, or "all day every day 40hrs/wk". Nobody solo programs like that either though.
- Supermancho 4y ago
  > Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles. While I agree with that, the cost-tradeoff is not worth those improvements (which are slight). Feel free to post to the studies that you find compelling.
- SomeCallMeTim 4y ago
  "Fewer bugs" needs to produce 2x productivity over the productivity of the two developers independently in order to actually be a benefit. Code review and using typesafe languages can also catch nearly 100% of those bugs as well, without the 50% performance penalty. "Keeps people on task" seems like management-think adjacent to "butts in chairs in an office" requirements: There's a fear that someone might be "wasting" time by being distracted, when you seriously need to contemplate problems sometimes. I'd need to see that "actual evidence" that we're allegedly discarding. Two programmers with two computers clearly could produce twice the productivity if they're both strong programmers. When I've been pairing with people I simply do all the work. I might get 1-2 comments per hour about a missing semicolon that I would have discovered the moment I tried to build. The claims of the pairing advocates are pretty hard to believe, and I don't see extraordinary evidence to back their extraordinary claims. As I intimated above, the only way it would work is if the developers are junior (or mediocre) enough to be prone to contributing 0.5x or less productivity left to their own devices, so that the two developers' inadequacies at programming complement each others' and you get a 1.5x productivity out of them combined or something. And I do suspect that companies use that fact to hire less competent developers and make them at least reasonably productive; Pivotal does 100% pairing, and sells it hard, but note that they're paid per developer hour and so actual productivity per-developer isn't what they're necessarily what they wanted to optimize. As to your Edit: The exact thing I'm objecting to is 100% pairing, which is practiced at some companies like Pivotal. Or worse, 100% mobbing, which is more than two people at one screen.
hallway_monitor 4y ago
You are correct in that having two people both well-versed in both the system and the change they are making is a waste. However, that tends to be rare - the more common situation on a team with no newbies is that you will need to solve new problems with new methods, possible integrating with new systems. If you have a team of experts, and you want to keep them all experts, it's much more economical to have two people learning the new code as it's being written. Theories about what might or might not be helpful have very little value until tried in the field.
- pixl97 4y ago
  I'm not seeing anyone mentioning what you should do in the case where the one person that knows the code gets hit by a bus. Would anyone ever say you only need one copy of the code, because backups are inefficient?
  - toomanydoubts 4y ago
    Hire a professional to pick up where he left off?
    - pixl97 4y ago
      Right, I'm sure they'll be up to speed within minutes and your business will suffer no delays or impacts!
joshuacc 4y ago
Having worked at both a mid-size EdTech company and now in a smallish part of Microsoft, every codebase for public-facing software that I've seen would take at least 1 year to achieve actual expertise in (while guided by an expert!) and would probably take much longer.
quickthrower2 4y ago
People forget what a creative profession coding is. The assumption that programming is a factory is what is being challenged. Most companies seem to have a factory approach and so you end up with technical debt weighing everything down to the point people just can’t get stuff done and the job becomes more about explaining why you can't do stuff. To give a more concrete example a pair programming session might avoid putting in foundational code that ends up being a bad design choice and slowing down the team by 1% forever. Maybe at a cost of millions. That 1% will never show up in any OKR or KPI that just basically measures superficial stuff about the status quo (bugs raised per quarter, features delivered on time etc.) I mean it is like we forget we live in an age where still someone smart coding at their laptop can launch a million dollar business. If you can figure out a smart “hot take” way of working, like maybe pair programming it is a big competitive advantage. To the point you probably wont find a job for a company that works that way because they can more than make do with a small team.
runeks 4y ago
> Once you have a team full of experts, you're now spending two programmer hours to do every bit of work that could have been done in one programmer hour by a single expert. You’re forgetting that it’s impossible for any one person to keep all the details of even a medium sized code base in their head. I imagine the initial “planning” phase of implementing a change would benefit heavily from pair programming because it avoids the issue where you write a bunch of code to find out that it doesn’t work because of this one detail that you forgot. For the learning (“knowledge transfer”) aspect, though, I think you’re right that it’s possible to reach a point where writing the actual code (not the design) as a pair is not worth it.
truculent 4y ago
There's a trade-off between efficiency and robustness. It may not be as efficient, but it can be more productive in the long-term if you're better insulated from staff turnover, for example. Making engineers more replacable could also contribute towards lower wages (more able to hire beginners and make them competent, reduce leverage of existing staff).

troupe 4y ago

> That just can't be more productive over the long term, though. While you can type a lot more by having two people type in parallel, some programming is much heavier on the problem solving aspect of things and those types of problems are sometimes completed more rapidly with two people working together than with two people working separately.

zozbot234 4y ago

True expertise on a large, complex code base does not just take a few months; competence is best modeled as growing over long timespans, not as something that quickly reaches an "expert"-level ceiling. This is all the more true when-- as is often the case-- the codebase is a complicated legacy thing, full of accumulated "technical debt" and unneeded complexity of all sorts. This is not to say that 100% pair programming is always the answer, but doing it to some extent is likely warranted.

dboreham 4y ago
Someone with much more experience than me once told me it always takes a year. He turned out to be right, at least over the past 25 years.
artificialLimbs 4y ago
This is exactly what I'm currently jumping into as a 'new' dev. I've been coding for about 3-4 years, am working on an ANCIENT php in-house ERP (we're still running v5!), and find the technical debt/unneeded complexity more shocking by the day. I've been in this position 3 months and feel like I've barely even scratched the surface of what is going on under the hood. Teaming up for training is absolutely crucial at this time.

WindyCityBrew 4y ago

There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0, keeps people on task, offers (literally) immediate feedback. Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles. My guess as to why we don't see more adoption is 1) most developers aren't that fond of it, and 2) most managers do some quick gut check mental math and assume 2 programmers + 1 computer can't be equal to or greater than 2 programmers + 2 computers, that's nonsense, actual evidence be damned. edit to add: I agree with commenters that pairing is more demanding/draining than solo work. I shudder at the thought of anyone trying to pair for 8hrs straight, or "all day every day 40hrs/wk". Nobody solo programs like that either though.

Supermancho 4y ago
> Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles. While I agree with that, the cost-tradeoff is not worth those improvements (which are slight). Feel free to post to the studies that you find compelling.
SomeCallMeTim 4y ago
"Fewer bugs" needs to produce 2x productivity over the productivity of the two developers independently in order to actually be a benefit. Code review and using typesafe languages can also catch nearly 100% of those bugs as well, without the 50% performance penalty. "Keeps people on task" seems like management-think adjacent to "butts in chairs in an office" requirements: There's a fear that someone might be "wasting" time by being distracted, when you seriously need to contemplate problems sometimes. I'd need to see that "actual evidence" that we're allegedly discarding. Two programmers with two computers clearly could produce twice the productivity if they're both strong programmers. When I've been pairing with people I simply do all the work. I might get 1-2 comments per hour about a missing semicolon that I would have discovered the moment I tried to build. The claims of the pairing advocates are pretty hard to believe, and I don't see extraordinary evidence to back their extraordinary claims. As I intimated above, the only way it would work is if the developers are junior (or mediocre) enough to be prone to contributing 0.5x or less productivity left to their own devices, so that the two developers' inadequacies at programming complement each others' and you get a 1.5x productivity out of them combined or something. And I do suspect that companies use that fact to hire less competent developers and make them at least reasonably productive; Pivotal does 100% pairing, and sells it hard, but note that they're paid per developer hour and so actual productivity per-developer isn't what they're necessarily what they wanted to optimize. As to your Edit: The exact thing I'm objecting to is 100% pairing, which is practiced at some companies like Pivotal. Or worse, 100% mobbing, which is more than two people at one screen.

hallway_monitor 4y ago

You are correct in that having two people both well-versed in both the system and the change they are making is a waste. However, that tends to be rare - the more common situation on a team with no newbies is that you will need to solve new problems with new methods, possible integrating with new systems. If you have a team of experts, and you want to keep them all experts, it's much more economical to have two people learning the new code as it's being written. Theories about what might or might not be helpful have very little value until tried in the field.

pixl97 4y ago
I'm not seeing anyone mentioning what you should do in the case where the one person that knows the code gets hit by a bus. Would anyone ever say you only need one copy of the code, because backups are inefficient?
- toomanydoubts 4y ago
  Hire a professional to pick up where he left off?
  - pixl97 4y ago
    Right, I'm sure they'll be up to speed within minutes and your business will suffer no delays or impacts!

joshuacc 4y ago

Having worked at both a mid-size EdTech company and now in a smallish part of Microsoft, every codebase for public-facing software that I've seen would take at least 1 year to achieve actual expertise in (while guided by an expert!) and would probably take much longer.

quickthrower2 4y ago

People forget what a creative profession coding is. The assumption that programming is a factory is what is being challenged. Most companies seem to have a factory approach and so you end up with technical debt weighing everything down to the point people just can’t get stuff done and the job becomes more about explaining why you can't do stuff. To give a more concrete example a pair programming session might avoid putting in foundational code that ends up being a bad design choice and slowing down the team by 1% forever. Maybe at a cost of millions. That 1% will never show up in any OKR or KPI that just basically measures superficial stuff about the status quo (bugs raised per quarter, features delivered on time etc.) I mean it is like we forget we live in an age where still someone smart coding at their laptop can launch a million dollar business. If you can figure out a smart “hot take” way of working, like maybe pair programming it is a big competitive advantage. To the point you probably wont find a job for a company that works that way because they can more than make do with a small team.

runeks 4y ago

> Once you have a team full of experts, you're now spending two programmer hours to do every bit of work that could have been done in one programmer hour by a single expert. You’re forgetting that it’s impossible for any one person to keep all the details of even a medium sized code base in their head. I imagine the initial “planning” phase of implementing a change would benefit heavily from pair programming because it avoids the issue where you write a bunch of code to find out that it doesn’t work because of this one detail that you forgot. For the learning (“knowledge transfer”) aspect, though, I think you’re right that it’s possible to reach a point where writing the actual code (not the design) as a pair is not worth it.

truculent 4y ago

There's a trade-off between efficiency and robustness. It may not be as efficient, but it can be more productive in the long-term if you're better insulated from staff turnover, for example. Making engineers more replacable could also contribute towards lower wages (more able to hire beginners and make them competent, reduce leverage of existing staff).