* Brian observed that it was interesting pairing because it seemed that at any given moment he wasn’t as confident in the code and his understanding of the code as it has historically been on his own (but as long as the sum total of confidence was ok, he was ok with that). He attributed it to test first design — in the early 80s, he’d think lots about the problem before writing code and the code would just flow out, but now when he does test-first programming, he doesn’t have as full an understanding of the code because the tests understand the code for him in some ways. Mike said the understanding is still there, it’s just written down in the tests. You don’t need to keep it all in your head, and when you need the understanding you don’t have in your head, you can go back to the tests and “re-inflate” the parts you need.

* He also observed that we got caught up so that the code was beginning to drive user level decisions until he pulled the pair back. He finds that same cycle in his own personal programming — coding distracts him from thinking about what the user would want and he needs to consciously pull himself back. He asked if there was a certain art or skill to diving into the code, the code tells you what it can do, then you go back to the customer level, and back and forth, having it all come out nicely. Mike said taking breaks sometimes has been helpful for him. Bill also suggested keeping the customer in the room helps with this question of focus.

* Mike H. observed that installing stuff is a big pain in the butt. He was surprised at the number of things he had to install and configure in his work today on the install procedure. Mike mentioned an interesting thing to consider — how many projects start the install stuff in parallel with the application development. He thinks there might be some benefit to doing that.

So, now we’re breaking