I think one of the best ways to learn and become a better programmer is to share knowledge gained from working on personal or work projects with others. One way to do this at the workplace is to set aside an hour or so a week and let one or several team members present their progress on the part of the code base they have been working on. This is especially helpful when each team member has a specialized skill set. What are some other useful practices that managers can institute to increase team cohesion and improve productivity?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
I've used "Training Tuesdays", though you could move it to a Thursday and keep the "TT" title, as an opportunity for the team to share what they know. I borrowed a few katas from Code Kata and worked through them as a team, they provide nice little programming scenarios that allow everyone a chance to think about a problem then propose a solution; one person might suggest LINQ another a for loop... then you've got a good ground for a discussion about the various benefits of each approach. It's not "mission critical" so the pressure is off and it's ok whatever you suggest. So if you've got good database skills you might see the problem in a particular light, explaining that to someone who's a good OO programmer means you both need to understand the other language to some extent.
I also used the excellent Summer of NHibernate / Autumn of Agile screencasts by Steve Bohlen in the sessions to bring in an understanding of ORMs and Agile processes, the Autumn of Agile shows advantages of agile over waterfall approach and it was good having that visualised for us.
We also gave mini-presentations on subjects we each were strong on; so there was a guy strong on UX and accessibility in the team and he showed what that involved and worked through some forms we had and highlighted good and bad aspects.
Pair-programming could also help here; over time everyone works with everyone else on something, whether it's your core business or on a fun Friday afternoon project or even just on "hey lets have a look at that crazy rail's thing everyone's on about", when we've done this not only is the code we write better (you don't tend to cheat when you know someone is watching) but you have discussions about how to do xy or z (which is what happened with the code kata in the team, only here it's just 2 of you). So if you try to pair seniors with juniors the juniors get to work with someone who can help guide them and prevent them making mistakes. The seniors get someone asking "why, why why" and that makes them have to explain / teach and therefore question their understanding and deepen what they know, or pick up new ideas from people who aren't already set in their ways (I'm guilty of this, thought I knew all I needed to and stopped learning, new approaches came in and I was behind the times)