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?
Productivity enhancing development strategies for small teams
productivity;management;teamwork;team
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. Then if someone has an interest in learning something new it can be a good opportunity there, for example finding out about javascript patterns or unit testing javascript so you can present back to the team on how they can be adopted. I'm currently spending a bit of free time learning Red Gate's SQL Test and in a week will be having an hour session with the team in which I hope to show them why we should start writing unit tests in the database. What I've found is that when you have to teach something it lifts your game; I teach martial arts and when I learned a technique for a grading I thought I understood it, but when I had to teach it to someone I had to see it from their perspective and think of ways they could understand it. The same has been true when I've mentored developers too; they ask different questions than I did when learning that feature so I had to really understand it.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)