Get a weekly 1-2 hour programming topic meeting, each week having a different topic.

Have it presented by a different member each time.

This will get the presenter to know about the subject, and should help them with presentation skills to boot.

The most important thing will be to keep them synchronized. If one of your developers knows everything about everything, that does you absolutely no good. Get them to work and learn together. And since the best way to learn is to do, techniques like eXtreme Programming ^[1] and Scrum ^[2] work great.

If you want your team to learn something completely new, then I think you should consider a small-sized (5 people at the most) study group. This group can pick a topic and gather sufficient knowledge and practical skills to be able to recommend whatever it is they're learning for a project, or not.

In my experience, ficticious development never works. And in that category I put reading blogs for the sake of keeping up-to-date, trying out new technologies in ficticious projects, etc. One person may have a genuine interest, but it will be very hard to propagate that knowledge to make it usable in actual development.

How about getting them onto stackoverflow for a half an hour a day.

They would learn a lot, help and lot, and when they needed to know something ...

Also bear in mind that people learn differently, and for different reasons.

Some people quite like reading, others prefer being taught face-to-face, and there are those who would prefer to muck around with things and see what happens.

There is also the issue of why people learn. Some people don't see the need to learn things they are not using, while others like to learn new flashy stuff, and so on.

My real point is that the real danger is being too prescriptive.

You can also check out this: http://www.codinghorror.com/blog/archives/001004.html

The best way to keep your devs up to date with the latest and greatest is to actually implement it in your products. In my experience it is great to learn about new stuff, but the effect of the learning is limited if you are not actually putting it into practice. Not to mention that you are also limited by the teaching/presenting capability of the person doing the teaching, and the aptitude of the people doing the learning.

I've worked in a company that promoted a once-a-week learning session, and it was largely ineffectual. The idea is great, but putting it into practice is harder than it might seem. I resented taking an hour out of my already very busy schedule to be at these sessions, and i hated it when it was my turn to present because it can take a few hours to put together a decent presentation.

You also have to bear in mind that different devs have different aptitudes. Some learn very easily and will love finding out about new technologies, they will have 300 different feeds loaded up in their blog reader. Some will be quite content to stick with the stuff they learnt in the 80's, they don't care about F# and MVC and MVVM and IoC and WCF and REST.

One way that may be productive for you is to have your most senior/knowledgeable devs do regular code reviews with the other devs. Keep the reviews short, non-competitive and informative, that way tips and techniques can be passed on in a one-on-one situation, and as the "learning" will be in the context of some actual work the devs will remember it a lot easier. The key to this is keeping it fun, and being able to relate the concepts/techniques to something real.

Another thing to try is to have 6 monthly reviews, and set some objectives during those reviews. An objective can be to learn something about XAML and WPF, or to write a simple Hello World that retrieves text from a WCF service, or to study for and pass an exam. Make sure the company is in a position to assist them with this by buying books or paying for exams, etc., and you will very quickly be able to single out those who want to learn and those that are just content to get by with what they already know.

I was working in a company that did 1 hour per week a small course with company related topics. Topics were for example:

• handling existing technologies better
• tips & tricks for your IDE
• getting started guides for new technologies
• ...

This is IMHO a good approach. One hour per week is not much and when the course is always at the same time, people can simply keep their schedules clean in that time frame to avoid collisions with other appointments.

Before starting down a path of learning new technologies it's important to understand what motivates people.

I would suggest that you start but getting your developers write down a learning plan. The learning plan should include the 5 technologies/patterns/practices/frameworks that they want to become more knowledgeable in. It should also include the technologies/patterns/practices/frameworks that they aren't interested in. You'll find it much easier to motivate people when they are learning things they are interested in as opposed to learning what someone else believes is important for them to know.

Once you understand how to motivate your team you could put like minded developers’ together (say in teams of 2 or 3 depending on the team size) and get them to present one of their technologies per month. Each presentation should be attended by the entire team and include code samples, examples and when/where to apply the findings.

I am of the belief that you don’t really know something until you have to teach it to someone else. To make learning an integral part of your team speak to management about including learning plans into your yearly performance appraisals/KPI’s.

I think to a certain extent this is only possible with developers who have a keen interest in their field. If this is the case then those developers will keep themselves up to date anyway, and although to a certain extent you can encourage this (webinar / conference attendance etc...) IMO it has to be a developer-led activity - you can't force new technologies down the throats of developers who aren't interested.

Update: On the topic of bzlms suggestion of "keeping developers synchronized", a neat idea I saw from Joels blog ^[1] was to rotate the build controller so that everyone had experience with the builds. I think this, and more generally the concept of keeping people multi-skilled, is a brilliant idea - if you have a "systems developer" who only knows back end technologies / C++ then they will be less likely to get interested in fancy new technologies like Silverlight WPF, and so will probably hear less about the new technologies that do affect them.

You could create a newsfeed where everybody (or only you) can post interesting blog entries (e.g. articles from Reddit, interesting questions from stackoverflow, technical news from heise, ...). The developers can subscribe and read everything that seems interesting.

Mine does care dogs more than my development skills. I wish I was a dog..

I try to keep myself updated as much as I can , but what I found out is , doing a OSS / project is the best way to learn new technologies and warm up your existing skills.

If you are not practicing , you are not learning imho

You cannot force people to become interested in learning new stuff. If there is no interest in keeping up to date, you'll have to communicate that keeping up to date with tech is something that the company values. Perhaps that means that those who show interest and learn new stuff actually gets higher raises, more high-profile jobs etc. (depending on their needs/wants)

But most importantly, create an atmosphere where people can learn from each other.

Communication among each other is key. I've learned more by interacting with other developers I've worked with more than I ever did in classes or by reading.

Code reviews are great at facilitating this kind of communication. Good project organization that brings developers together is also a good idea. Something like Scrum where all developers are brought to talk about what they did, problems they're facing, and what they plan to do each day.

Set up a weekly "Developer Workshop". Same place and time every week. When I ran them, an hour was a little short. If I am in a position to do them again with my new employer, I would probably double the length and spring for lunch (of course the feasibility of this is variable on team size and if your company will let you expense it).

A possible agenda might run something like:

• Old business / new business - Let the developers voice concerns about what is going on in general. It often opens the door for new opportunities in finding creative solutions to problems. Giving them a forum to do this lets problems be addressed and more time dedicate to coding activities. Often, there are architectural/implementational issues discussed which are good points for future meetings - i.e. a problem area of the code base might be addressed by use of a tool or technique - use that for the main presentation of the next meeting. Keep the old business / new business short - shooting to timebox it at no more than ten minutes. In a tight team, this often will be skipped completely.

• Main presentation - Someone should present the topic - obviously. Shorter topics might mean that one person could present multiple topics or multiple people can present. Talk to any local development groups you might have in your area and see if you can get a guest speaker, too. It also is not a bad idea to get a web cam and record it. You can then put them up on a team wiki, or similar, and have a reference to them, plus they can be there for people who join the company at a later date.

• Q&A - Always close with a question and answer section. People will have the most relevant questions immediately after the presentation. The length would probably vary based within the complexity of the presentation.

This may or may not work for you. It did work for my team, though. As always, YMMV. :-)

Formal things usually do not work in such cases, you need a technology-leader(s).

These leaders should start using new technology and involve other people in this.

Later the leaders can share interesting technology news with the team, so people will be better prepared when something new will come.

And, definitely there are psychological issues one should not forget about, f.e. - people should feel proud for result they have - it should be constructive and cooperative communication between leaders and other team members - people should clearly understand benefits of using new technologies

etc

I have worked on smaller teams as a member developer and also as a lead & I have always found the following to be useful when it came to keeping the developers up to date and motivated. We always did periodic code reviews that benefited all the team members & brought them all together onto the same page. Code reviews always help understand the business more clearly & will also provide ample opportunities to discuss new technologies. Additionally, you could also assign members a technology assessment/evaluation tasks from one of your future release plans for discussion and presentation. What I mean by this is, say, on your future release plan, you would like to add some "xyz" support to your application, then you could assign few of the members on the team to go study the latest & greatest of "xyz" and present them to the team.

A place I worked previously used to have weekly meetings where:

• Someone would pick a paper (academic, article, etc) and give it to the rest of the team.
• The person who picked the paper at last weeks meeting would make a short presentation about the paper they had picked, after which everyone would discuss it
• The person to select the next paper would be chosen.

That gives everyone a week to read the paper so they can contribute to the discussion, and gives everyone a chance to pick a topic they would like discussed. Not only did it help keep people on the team current, but for me being new to the team I learned a ton from those meetings, especially from the resulting discussions that would take place.

What about flipping this question around for a moment: What does the team currently do to stay on top of things? Have you asked what they would like but they don't have at the moment? This is just a thought and may be similar to some other answer here.

There could be some that have ways to keep on top of things so that the key then becomes distributing that knowledge within the team which is different from a general, "Everyone, we will now be doing things differently..." death-like march.

Lastly, don't forget that there may be other groups to consult for some things as some trends, like cloud computing, may require a bit more work and buy-in before jumping into using I'd imagine.

I've been a dev for 12 years and I can safely say I have gained very little from programming training courses (most seem to be created for absolute beginners).

To get up to date about technologies, and to increase enthusiasm and inspiration I would recommend conferences about the latest stuff, for example Microsoft Mix.

Is the company willing to pay on company time for this training/self improvement? Telling developers they need to keep up with current trends is all well and good but many won't bother if it's not fully endorsed by the company.

I personally don't bother learning technologies applicable to my work in my own time, instead I enjoy developing my skills in other areas (for example my work is mainly Java, but at home I'm spending my time learning Objective-C).

You can apply a holistic view at this problem by following something like the Construx development ladder ^[1].

Every individual has different needs, depending on which level they occupy in the ladder. Development ladders like this will take that into account and suggest a number of things to help the individual improve, including books, coaching, projects, etc.

I'm posting an answer just to hear your opinion about it:

Keeping a company wiki/blog, where every one can post interesting tech/updates/tips.

2 things

1) Lead by example. Show that you as the lead are always up to date and try to entice them to keep up with you.

2) Make it fun! Send them to conventions, make some coding games and challenges. Learning is fun as long as no one tries to force you to learn. Think about children and how much they love to learn. Then they go to school.....

Why update your skills ? Stick with Fortran. All these fads (C, Python, the Web, Haskell, etc) will fade, only Fortran, Cobol and Lisp are eternal. Learn some old skills.