More like unknowns about implementation details. Defining in brainstorming sessions how we want a solution makes sense, but I don’t imagine talking about details.
I was referring more about discussing the details inside of an already defined solution, like, for example, trying to use a library, which one we use, or how would be implemented in detail something.
I’ve always felt that pair programming is more useful on early stages of a task, where there is enough doubt about implementation details and discussing them is worth.
This way it felt more of a meeting between two persons discussing details first, while testing them live to check if we were on track second, instead of programming first and discussing second.
By the time we stand on the screen without talking too much we just stepped aside and separate the task if needed.
Any other kind of forced pair programming feels wrong, either because the task was already planned enough to no create enough discussion, or because it was small enough and the discussion was not worth. I’ve found myself on situations where “we needed” to make a task in pair programming and was dull as you say.
OpenSUSE Tumbleweed, because it’s stable enough while also beign a rolling release distribution. I wanted to remove the hassle of updating debian/ubuntu once in a while to jump through LTS versions.
Curiosity. It began while trying to play around with programming, and finding a lot of talk and resources about Linux, and then trying it. 3 broken Debian installations just for messing around, then Ubuntu as a more permanent install, all of this alongside Windows.
Then I began using less and less Windows until I just deleted the Windows partition because I needed more space.