| > Mine is the exact opposite. Slowing down and explaining design firstly helps to clarify things in my own mind and the pairer will usually see things that I missed as I explain. I absolutely see value in explaining a design, and doing so with code, before you commit to the full project, but for me that step follows getting my initial design ideas down as code. I've had any number of projects where I've explained the high level design in words first, and people don't understand why it matters, and then I've put it down in code and shown the concrete benefits, and it instantly clicks. That doesn't mean that design will be set in stone and perfect, but I find it much easier to have the discussions about the design then. But that's me. If you prefer writing the initial code as well with someone, you should by all means keep doing that. > I dont really think people take to pairing or not on the basis of its prima facie effectiveness though, but rather whether they enjoy programming as a solitary or social activity. I think you're right, with a caveat that it's not for me necessarily about not enjoying social aspects of it, but about the granularity of it. I'm happy to walk people through my code, but I want peace and quiet to put in place at least the outline of the design in solitude first. > Really, I think teams should be set up to ensure people who like pairing to be together and vice versa, coz i feel just as miserable working alone all day every day as you do pairing. That is absolutely reasonable. I have no issue with people pairing. I do have an issue with teams where becomes an expectation for everyone. |