5 ms·

+1 to XP. Pairing removes many barriers to development: * built-in code review * knowledge sharing: removes silos * helps avoids overengineering (few pairs

+1 to XP. 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.

scarface74 8y ago
Alternatively: - code reviews as part of a pull request system - knowledge sharing - design sessions for features to make sure nothing was missed and architectural overviews with wiki documentation. - avoid overengineering - again architectural “previews”.
- HandsAtTheReady 8y ago
  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.
  - scarface74 8y ago
    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?
    - HandsAtTheReady 8y ago
      > 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.
      - scarface74 8y ago
        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?
        auslegung 8y ago
        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=en https://twitter.com/kentbeck/status/253532726714580992?lang=...
        scarface74 8y ago
        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?
- jacques_chester 8y ago
  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.
  - scarface74 8y ago
    And having two developers pair programming instead of them both working on separate releasable features is more efficient?
    - jacques_chester 8y ago
      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.
      - scarface74 8y ago
        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.
        jacques_chester 8y ago
        I'm not sure what you're driving at here.
        8y ago
auslegung 8y ago
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-with-promiscuous-pairing-is-a-success/ https://engineering.itpro.tv/2018/12/07/our-first-experiment...

scarface74 8y ago

Alternatively: - code reviews as part of a pull request system - knowledge sharing - design sessions for features to make sure nothing was missed and architectural overviews with wiki documentation. - avoid overengineering - again architectural “previews”.

HandsAtTheReady 8y ago
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.
- scarface74 8y ago
  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?
  - HandsAtTheReady 8y ago
    > 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.
    - scarface74 8y ago
      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?
      - auslegung 8y ago
        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=en https://twitter.com/kentbeck/status/253532726714580992?lang=...
        scarface74 8y ago
        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?
jacques_chester 8y ago
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.
- scarface74 8y ago
  And having two developers pair programming instead of them both working on separate releasable features is more efficient?
  - jacques_chester 8y ago
    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.
    - scarface74 8y ago
      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.
      - jacques_chester 8y ago
        I'm not sure what you're driving at here.
        8y ago

auslegung 8y ago

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-with-promiscuous-pairing-is-a-success/ https://engineering.itpro.tv/2018/12/07/our-first-experiment...