Friday, February 29, 2008 10:46 AM Sean Feldman

Pair Programming And Sharing Knowledge

Pair programming is a proven technique for sharing knowledge among team members and teams. Benefits of that are felt after relatively a short period of time, boosting not just the productivity, but self-confidence of the developers (which is playing an important role even though is not admitted), and most of all, improving the maintainability of the code when it comes later. And it comes. It always comes.

But I would like to review additional alternatives to the knowledge sharing with team members (both direct team members, and those that are a part of another teams that might not come into direct contact with what your team is doing). What are the ways to share the knowledge?

From my personal experience, group lectures are in-effective. People are coming into those, hating it, and taking almost nothing valuable as they leave. Code camps are excellent, but the majority of the people who are attending those are doing it out of their own curiosity, enthusiasm, or just will to be better developer.

What I was doing in the company I work for, is a short (30-45 minutes) meetings once a week or two, hands on code. And the presenter was elected at the end to present his/her topic. IMHO this was working, but others may disagree. I think this was working for the developers who believed that it's not just a task of presenting, but a responsibility not to waste others time and let them learn from others what they would not learn on their own due to the lack of time or opportunity.

So what are you practicing if at all?

Filed under: ,

Comments

# re: Pair Programming And Sharing Knowledge

Sunday, March 09, 2008 6:22 PM by OJ

Currently we practice whatever works for the given scenario. Sometimes pair-programming works well if the problem is a tricky one, or if a really important part of the system is being created. Other times a design session away from the keyboard with more than two people works well.

Needless to say this isn't really a "true" agile environment as the rules aren't strict, but the method seems to work well as the team knows when to apply what practice.

Leave a Comment

(required) 
(required) 
(optional)
(required)