Possible Duplicates:
How do you start Knowledge Transfer?
How to get Developers to Share and work together

What are the best-practices to make developers learn from each others technical experience?

One could start reading a book, but that's only useful if you have one particular problem or field of interest. I am looking for techniques, which can be integrated within the developing process, so that developers constantly learn from each others during work.

For example, I learned that code reviews and lectures by other developers helped me getting better.


I don't understand you. The question was closed again altough it is not a duplicate!

Looks like SO is just for fixing code and not about professional development.


The best way to do this is to be intentional. Periodically reflect on your practices as a team and decide to add (or drop, if it's not working) a particular technique. Give your developers time and opportunity (conferences, classes) to learn new techniques and have them recommend them, if appropriate, for adoption. Choose 1 new technique per reflection period (1-3 months) and give a try until the next period. If the technique is successful, then adopt it permanently. If not, then discard it.

Also, you can use your reflection times to have your developers talk about what they are working on and showcase their developments, especially any new technology they've used or unique feature that they've developed. Brainstorm on how you could apply this together. You may event want to do this more often than your reflection intervals.

The key, I think, is to develop a culture of learning. An expectation that you learn and share what you do, that you are always striving for improvement. Adopt that philosophy personally and come up with activities for your team that encourage and reward learning.

Oh -- and I'd drop the idea of making them learn. I don't think you can force anyone to learn, at least not in a way that has a positive result. At best you can encourage and reward people for trying to improve in their craft. This starts by hiring people, if possible, who already have that mindset. Once you have them on-board, develop/maintain a culture of learning through your attitude and practices. This means that the time you set aside for learning opportunities is nearly sacred, only to be discarded in the extremest of circumstances. If you don't provide time, resources, and opportunity for learning, it won't happen unless the individual is self-motivated toward it anyway.


Pair programming


I think you have already mentioned the most important one yourself: code reviews.

In our company, we also try to have at least one monthly presentation where someone has used a new programming language or technique in the past weeks and shares this knowledge with the rest of the developers. It's not as good as code reviews, but at least it can enthousiast co-workers to try out language X or framework Y, or tool Z.


Subject the whole dev team to 40 lashes each time a bug is found.


There are a few different ways that have worked for me along with pair programming and other ideas already mentioned:

  1. Bring in help to adopt new habits - As opposed to ordering everyone to suddenly do something, temporarily bring in some consultants to show some techniques that can help things dramatically. I had this where I work where ideas like using Mock objects and how to organize some things were shown and eventually adopted mostly.

  2. Work with a good team - Seeing others do things differently that works better can inspire one to try things and adopt the good. A couple of principles from "How to Win Friends and Influence People" apply here like "Throw down a challenge" and "Give them a fine reputation to live up to" for ways to improve a team. "You're the Average of the 10 People You Spend Time With" has more about this in a sense.

  3. Experiment - This can be tricky as sometimes things don't work out but until one tries which may be seen as a waste of time in some ways. Do the developers have the freedom to do things differently if they find what they believe is a better way? Are they empowered enough to have this autonomy?

There was a "Standards and Practices" meeting but that has been abandoned as it wasn't really being used. Appealing to someone's greedy motives may also help here in some ways.

  • Pair Programming

    IMHO it is a way to learn from others while coding on an "active way"

  • Code Review

    IMHO it brings you a passive learning of coding

Besides learning from code, some good ways to know about planning/estimating is the use of daily meetings and retrospective meetings.

Even with that, the most important is (see @tvanfosson post) "to develop a culture of learning"


Use pair programming if you can, and very detailed code review techniques. One team that I have worked on has a very effective policy for code reviewing when they first bring new people onto a project. They use Crucible, and they typically just review what a person has changed in the code. But for new people on a project, they review the whole contents of each file that they have committed and assign code improvements to them based on that. The principal and lead software engineers get very involved in this process and really make sure that the other developers on the team do what the organization expects them.

Books are very helpful, but there's no proper substitute for just being given an assignment in a new language and told to work on it. Developers really need to learn new skills hands-on. Ideally, there should also be someone else on the team who has experience with the language or development tool and can pass that knowledge along to the person that is learning it effectively and understandably. This contributes heavily to the "culture of learning" that this team has had.


One place I worked had their people give monthly "brown bag lunch" talks about things they were working on or tools they had mastered.


As said before the key of learning lies within the communication between developers. If you have a new idea, talk about it and discuss whether it's usefull or not.

You might like the idea of having a tool which you can use to instantly communicate ideas to your team-members. We are trying out a product called Yammer which is something like a Twitter-clone for business reasons. You can use this kind of technology to state ideas and "what you are working on" and everybody can see and reply to it. Maybe this could be an approach for you in order to increase your developer-communication :)


In my opinion, it is the environment itself that fosters learning between developers. A company with open work groups where developers can lean over and see what others are working on, as well as an open door policy will go a long way to create an environment where developers learn from each other.

Pair programming and peer reviews are both good ways of learning, however they should be part of a whole, and not "the technique we are using" to learn from each other. I believe the most important thing is to have an open and cooperative workplace where developers are not afraid to ask each other for advice when struggling with a particular problem.

This is all very philosophical, as is most things concerning interpersonal relations.


If possible, Request different programmers or group of programmers to develop the same piece of functionality . The results will be amazing. That should make a good learning.


It seems to me that you can do all sorts of things that will make it possible for the team members to learn - I learn tons from participating in code reviews. The most important thing you can do, though, to get your team to learn is to hire people who enjoy learning. If they don't want to learn anything, they won't, even if you force them to sit in code reviews or make them do pair programming.