13 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.

zozbot234 5y 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 5y 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.
- fragmede 5y ago
  Therein lies the problem. How much is an avoided bug really worth? A > where really a >= is needed is theoretically going to get caught with pair programming, but how do you make that a metric you can track when we still don't have any way of measuring developer productivity. We never got past the fact that measuring lines of code output is dumb, to any other sort of metric. Even if we had such a metric (using magic, perhaps), would programmers actually welcome it?
  - Clubber 4y ago
    Not only that, but that same bug can probably be caught cheaper with a good human QA department.
- raverbashing 5y ago
  I agree with the benefits But you also have 2 developers using 100% "of their cpu" during that time, which is really unsustainable for longer periods.
  - Keyframe 4y ago
    One of threads is reviewing code as well, which would be done later on anyways.. among other benefits. I'm invoking commodore64 days for the second time in a row now - back then, during the war, as kids we didn't have much comouter lying around so few of us gathered around a single one and learned and tinkered with it. It was awesome since everything bounced out loud from multiple brains. XP in general is alright but maybe not all of the time, as with anything.
hallway_monitor 5y 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 5y 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 5y 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 5y 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.

fragmede 5y ago
Therein lies the problem. How much is an avoided bug really worth? A > where really a >= is needed is theoretically going to get caught with pair programming, but how do you make that a metric you can track when we still don't have any way of measuring developer productivity. We never got past the fact that measuring lines of code output is dumb, to any other sort of metric. Even if we had such a metric (using magic, perhaps), would programmers actually welcome it?
- Clubber 4y ago
  Not only that, but that same bug can probably be caught cheaper with a good human QA department.
raverbashing 5y ago
I agree with the benefits But you also have 2 developers using 100% "of their cpu" during that time, which is really unsustainable for longer periods.
- Keyframe 4y ago
  One of threads is reviewing code as well, which would be done later on anyways.. among other benefits. I'm invoking commodore64 days for the second time in a row now - back then, during the war, as kids we didn't have much comouter lying around so few of us gathered around a single one and learned and tinkered with it. It was awesome since everything bounced out loud from multiple brains. XP in general is alright but maybe not all of the time, as with anything.

hallway_monitor 5y 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 5y 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.