3 ms·
Pair programming is a way of transferring tacit knowledge that's literally an order of magnitude more effective than trying to document that tacit knowledge, mo
by TameAntelope 5y ago
Pair programming is a way of transferring tacit knowledge that's literally an order of magnitude more effective than trying to document that tacit knowledge, mostly because documenting tacit knowledge is extremely difficult.
But ultimately it's a culture thing -- if you're hired into a culture that values pair programming, you're hurting your team by not also valuing pair programming, and vice versa (you can't make a bunch of introverts enjoy spending hours with someone giving them guidance over their shoulder).
Honestly, being an introvert here is a hinderance to growth; it's vastly superior to run through a problem as a pair when someone has better knowledge about that problem than you do.
- corpMaverick 5y agoI had to google this one. "Tacit knowledge is the intelligence we have that is gained through the personal and professional experience you've learned both in your current role and previous jobs. It's the knowledge that's difficult to explain and challenging to document"
- erik_seaberg 5y agoPairing for knowledge raises the bus number from one to two, which doesn’t help for that long in the current market for devs. Documentation is what endures.
- TameAntelope 5y agoI worry you missed the "documenting tacit knowledge is extremely difficult" part. Tacit knowledge is notoriously hard to document in a way that successfully transfers the knowledge from one person to another. Pair programming is at least an order of magnitude more effective, if not more.
- erik_seaberg 5y agoIf two people build a feature, two people are slowly forgetting how and why until they move on, and nobody else gets it at all. It is easier than documentation (which I agree is hard enough to more than double the dev time), but it only postponed the problem a little without solving it.