3 ms·

> people can still contribute zero (except their presence). That's not how pair programming works. Pair programming is not sitting and doing facebook while th

> people can still contribute zero (except their presence). That's not how pair programming works. Pair programming is not sitting and doing facebook while the other person churns out code. Infact, in pair programming, that is exactly what you cant do. Once you understand this, you intuitively understand why mob programming is so much more efficient.

chrshawkes 7y ago
This is an amusing comment to me. Maybe I'm burned out come to think of it? Your comment screams lack of experience in the corporate world, at least based on my 10 years in it. I think most companies have no time to have 2 or more programmers working on the same thing even if it produces some decent, soon to be legacy code. The constant, this is the only way to do it from so called seniors in this industry is so so frustrating.
- subhobroto 7y ago
  > The constant, this is the only way to do it from so called seniors in this industry is so so frustrating. Apologies if I came across saying there is the only way to do it. Let me rephrase - if there are multiple stakeholders in a product, I have found it really valuable to have them, physically or virtually in the same space as the work gets done and feedback gets provided in real time dissipating confusion and questions as soon as they arise. In my experience, fixing an issue at the source is cheaper than discovering it later and running to fix it then because the wrong assumptions were made just because everyone is too busy banging out code. Creative blocks as real. Rubber ducking is effective and real too. > I think most companies have no time to have 2 or more programmers working on the same thing even if it produces some decent, soon to be legacy code 1. Why do you think that is? If this question totally flummoxes you, a narrower question could be "what is the objectives of these companies with the code", but try answering the broader question if you have the time 2. Do people generally solve problems better when working in isolation or as a team? Now, did the companies you have experience with not have more than the programmer who wrote the code review it? Or test it? Who wrote the requirements? Who checked whether the deliverable(s) met the requirements? In my experience, more than one person ends up touching the code in one way or another until it actually reaches the customer. I have found, the overall quality is much better when everyone is working together instead of in a waterfall model, in strict sequence with lots of back and forth and meetings with subset of stakeholders until the product actually behaves the way its expected to. Reliably. The risk of this happening goes up as removed the programmer is from using the product themselves. So if dogfooding works on your projects, by all means do it. Looking forward to your thoughts.

chrshawkes 7y ago

This is an amusing comment to me. Maybe I'm burned out come to think of it? Your comment screams lack of experience in the corporate world, at least based on my 10 years in it. I think most companies have no time to have 2 or more programmers working on the same thing even if it produces some decent, soon to be legacy code. The constant, this is the only way to do it from so called seniors in this industry is so so frustrating.

subhobroto 7y ago
> The constant, this is the only way to do it from so called seniors in this industry is so so frustrating. Apologies if I came across saying there is the only way to do it. Let me rephrase - if there are multiple stakeholders in a product, I have found it really valuable to have them, physically or virtually in the same space as the work gets done and feedback gets provided in real time dissipating confusion and questions as soon as they arise. In my experience, fixing an issue at the source is cheaper than discovering it later and running to fix it then because the wrong assumptions were made just because everyone is too busy banging out code. Creative blocks as real. Rubber ducking is effective and real too. > I think most companies have no time to have 2 or more programmers working on the same thing even if it produces some decent, soon to be legacy code 1. Why do you think that is? If this question totally flummoxes you, a narrower question could be "what is the objectives of these companies with the code", but try answering the broader question if you have the time 2. Do people generally solve problems better when working in isolation or as a team? Now, did the companies you have experience with not have more than the programmer who wrote the code review it? Or test it? Who wrote the requirements? Who checked whether the deliverable(s) met the requirements? In my experience, more than one person ends up touching the code in one way or another until it actually reaches the customer. I have found, the overall quality is much better when everyone is working together instead of in a waterfall model, in strict sequence with lots of back and forth and meetings with subset of stakeholders until the product actually behaves the way its expected to. Reliably. The risk of this happening goes up as removed the programmer is from using the product themselves. So if dogfooding works on your projects, by all means do it. Looking forward to your thoughts.