<story><title>Developers spend most of their time figuring the system out</title><url>https://lepiter.io/feenk/developers-spend-most-of-their-time-figuri-9q25taswlbzjc5rsufndeu0py/</url></story><parent_chain><item><author>WindyCityBrew</author><text>There are other benefits,  pair programming reduces a whole category of simple bugs&amp;#x2F;typos to basically 0,  keeps people on task, offers (literally) immediate feedback.&lt;p&gt;Unlike most programming &amp;quot;best practices&amp;quot; or paradigms,  there&amp;#x27;s actual empirical evidence that pair programming is &amp;quot;better&amp;quot;.  Fewer bugs,  easier to read code,  shorter review cycles.&lt;p&gt;My guess as to why we don&amp;#x27;t see more adoption is 1) most developers aren&amp;#x27;t that fond of it, and 2) most managers do some quick gut check mental math and assume 2 programmers + 1 computer can&amp;#x27;t be equal to or greater than 2 programmers + 2 computers,  that&amp;#x27;s nonsense, actual evidence be damned.&lt;p&gt;edit to add:  I agree with commenters that pairing is more demanding&amp;#x2F;draining than solo work.  I shudder at the thought of anyone trying to pair for 8hrs straight,  or &amp;quot;all day every day 40hrs&amp;#x2F;wk&amp;quot;.  Nobody solo programs like that either though.</text></item><item><author>SomeCallMeTim</author><text>That just &lt;i&gt;can&amp;#x27;t&lt;/i&gt; be more productive over the long term, though.&lt;p&gt;Lets say, hypothetically, that you &lt;i&gt;can&lt;/i&gt; 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&amp;#x27;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.&lt;p&gt;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 &lt;i&gt;other&lt;/i&gt; issues that likely need to be addressed, because why are people jumping ship so quickly if it&amp;#x27;s such a great place to work? (For example: If it takes six months to produce an expert, you&amp;#x27;d need to have an average tenure of less than or equal to six months to &lt;i&gt;really&lt;/i&gt; benefit from pairing; anything more and the 50% performance penalty has to eat into your overall productivity.)&lt;p&gt;On top of that, I have never been at a job where it&amp;#x27;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.&lt;p&gt;Unless one of the developers is otherwise likely to produce negative productivity on their own, I suppose. I&amp;#x27;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.</text></item><item><author>gleenn</author><text>People always struggle or avoid doing pair programming, and people always think it means that the developers&amp;#x27; time now costs twice as much, but this is a total lie. When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground &lt;i&gt;flying&lt;/i&gt;. Sitting next to someone who knows the system and can answer your question immediately means you get up to speed millions of times faster than screwing around by yourself. Pointed-haired bosses and accountants will never understand this. If you pair and rotate, the inexperienced person becomes experienced quickly, and it&amp;#x27;s viral if you also do rotating pairing. A team with one expert and pairing is now a team full of experts.</text></item></parent_chain><comment><author>darkwater</author><text>As others pointed out, for many of us pair programming is much more demanding on mental resources. The way I tend to work is by doing micro-breaks, checking out other things I would not be comfortable sharing with someone else; if I don&amp;#x27;t do that and keep hyperfocused, I get drained quicker.
Also you can get a couple of programmers that will go down the wrong rabbit hole for much more time because they reinforce their wrong belief mutually. This obviously happens with individuals as well but if you get the wrong mix it can be much worse.</text></comment>
<story><title>Developers spend most of their time figuring the system out</title><url>https://lepiter.io/feenk/developers-spend-most-of-their-time-figuri-9q25taswlbzjc5rsufndeu0py/</url></story><parent_chain><item><author>WindyCityBrew</author><text>There are other benefits,  pair programming reduces a whole category of simple bugs&amp;#x2F;typos to basically 0,  keeps people on task, offers (literally) immediate feedback.&lt;p&gt;Unlike most programming &amp;quot;best practices&amp;quot; or paradigms,  there&amp;#x27;s actual empirical evidence that pair programming is &amp;quot;better&amp;quot;.  Fewer bugs,  easier to read code,  shorter review cycles.&lt;p&gt;My guess as to why we don&amp;#x27;t see more adoption is 1) most developers aren&amp;#x27;t that fond of it, and 2) most managers do some quick gut check mental math and assume 2 programmers + 1 computer can&amp;#x27;t be equal to or greater than 2 programmers + 2 computers,  that&amp;#x27;s nonsense, actual evidence be damned.&lt;p&gt;edit to add:  I agree with commenters that pairing is more demanding&amp;#x2F;draining than solo work.  I shudder at the thought of anyone trying to pair for 8hrs straight,  or &amp;quot;all day every day 40hrs&amp;#x2F;wk&amp;quot;.  Nobody solo programs like that either though.</text></item><item><author>SomeCallMeTim</author><text>That just &lt;i&gt;can&amp;#x27;t&lt;/i&gt; be more productive over the long term, though.&lt;p&gt;Lets say, hypothetically, that you &lt;i&gt;can&lt;/i&gt; 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&amp;#x27;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.&lt;p&gt;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 &lt;i&gt;other&lt;/i&gt; issues that likely need to be addressed, because why are people jumping ship so quickly if it&amp;#x27;s such a great place to work? (For example: If it takes six months to produce an expert, you&amp;#x27;d need to have an average tenure of less than or equal to six months to &lt;i&gt;really&lt;/i&gt; benefit from pairing; anything more and the 50% performance penalty has to eat into your overall productivity.)&lt;p&gt;On top of that, I have never been at a job where it&amp;#x27;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.&lt;p&gt;Unless one of the developers is otherwise likely to produce negative productivity on their own, I suppose. I&amp;#x27;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.</text></item><item><author>gleenn</author><text>People always struggle or avoid doing pair programming, and people always think it means that the developers&amp;#x27; time now costs twice as much, but this is a total lie. When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground &lt;i&gt;flying&lt;/i&gt;. Sitting next to someone who knows the system and can answer your question immediately means you get up to speed millions of times faster than screwing around by yourself. Pointed-haired bosses and accountants will never understand this. If you pair and rotate, the inexperienced person becomes experienced quickly, and it&amp;#x27;s viral if you also do rotating pairing. A team with one expert and pairing is now a team full of experts.</text></item></parent_chain><comment><author>azemetre</author><text>I don&amp;#x27;t mind pair programming but I don&amp;#x27;t have the physical&amp;#x2F;mental capacity to do it for a full work day. I can only imagine how exhausted I&amp;#x27;d get after several weeks of it.&lt;p&gt;When I do pair, I only work for 3 or 4 hours that day total.</text></comment>