4 ms·

Pair programming easily achieves the >2x speed boost though. The driver focuses on the technical details of writing high-quality code, implementation, proper v

Pair programming easily achieves the >2x speed boost though. The driver focuses on the technical details of writing high-quality code, implementation, proper variable naming and so on whilst the navigator keeps track of the overall task, provides extra short-term memory, spots silly mistakes/typos, focuses on business logic etc. So instead of one programmer juggling too much and stalling, getting bored/frustrated, losing confidence, taking shortcuts to try to keep up and making a mess, you have two programmers in a state of flow producing high-quality work. As a side-effect, you also get great shared knowledge of the code base.

mihaaly 5y ago
Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation. Myself I actually enjoy this quite a bit. For avoiding and catching mistakes is useful but not a guarantee at all especially as their way of thinking is synchronised. There are other techniques for these as well (tools, patterns, reviews, ...) allowing two people working with two things. Shared knowledge of a codebase is pretty useful. While it lasts. Also pitty it involves exactly 2 persons only. Documentation is far more reliable way of sharing code knowledge, especially long term and in changing team composition.
- mhitza 5y ago
  > Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation. Feels like a reductionist statement. When working on a large codebase (call it legacy even, as everything devolves into legacy code given enough years), it's impossible to keep all the details in your head. Code review can provide the additional context missing to the developer implementing a task, but I'm sure you've been in the same situation before; where a feature change, even small in scope would crisscross multiple files, and without testing it out you're unable to review conformance. As an example. When I was team lead on a large and legacy SaaS project in the past, I pretty often would pair with other developers on the team, and their input as well as my input had us catch situations that while developing in isolation we could have missed. Even in a standard code review. Because during development we were deeply entrenched in the code and able to often try out multiple approaches for a problem.
watwut 5y ago
It definitely does not work that way for me. No matter which role I am, a lot more effort goes into following what other person does then when I do it by myself. This is like saying that two people hugging while each is using just one leg are faster, because they have to focus only on one leg while walking.

mihaaly 5y ago

Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation. Myself I actually enjoy this quite a bit. For avoiding and catching mistakes is useful but not a guarantee at all especially as their way of thinking is synchronised. There are other techniques for these as well (tools, patterns, reviews, ...) allowing two people working with two things. Shared knowledge of a codebase is pretty useful. While it lasts. Also pitty it involves exactly 2 persons only. Documentation is far more reliable way of sharing code knowledge, especially long term and in changing team composition.

mhitza 5y ago
> Developers being unable maintaining both business logic and technical details in head at the same time are usually not hired. Actually this is their stated job description most of the time, translate logic into implementation. If this gives frustration probably better to look for some other occupation. Feels like a reductionist statement. When working on a large codebase (call it legacy even, as everything devolves into legacy code given enough years), it's impossible to keep all the details in your head. Code review can provide the additional context missing to the developer implementing a task, but I'm sure you've been in the same situation before; where a feature change, even small in scope would crisscross multiple files, and without testing it out you're unable to review conformance. As an example. When I was team lead on a large and legacy SaaS project in the past, I pretty often would pair with other developers on the team, and their input as well as my input had us catch situations that while developing in isolation we could have missed. Even in a standard code review. Because during development we were deeply entrenched in the code and able to often try out multiple approaches for a problem.

watwut 5y ago

It definitely does not work that way for me. No matter which role I am, a lot more effort goes into following what other person does then when I do it by myself. This is like saying that two people hugging while each is using just one leg are faster, because they have to focus only on one leg while walking.