32
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 23 Jun 2023
32 points (100.0% liked)
Programming
17314 readers
155 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
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.
Is pair programming the right way to address unknowns around implementation? It seems like a brainstorming / whiteboarding session might be a better fit.
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.