views:

1226

answers:

22

Hi,

This is more of a developers management question, but since most of you here are developers, you probably have some insights on this.

I got in charge of planning how to keep our developers updated with new tech and trends. Since they are a diverse population, simply saying read blog X won't do any good.

Some ideas we had:

  1. A day/week of book reading
  2. Assigning learning projects with no real goal
  3. Mandatory courses (besides those they ask to go to)

I know every person has their own way, but how does your company help your developers stay updated?


Similar Q&A:

  1. http://stackoverflow.com/questions/57893/how-to-keep-your-developer-team-educated
  2. http://stackoverflow.com/questions/201189/what-do-you-do-to-keep-learning
+15  A: 

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 and Scrum 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.

bzlm
As much as this is a good idea. It won't work for 20+ developers. But we might be able to something similar with an internal wiki/blog. As for the XP, good idea.
Am
@Am Scrum and XP work great for 20+ developer. I've seen teams go from "so-so" to "excellent" using techniques like Scrum, Agile, XP, etc. This is the topic for another question, but please don't think that 20+ is "too large" a team to keep synchronized.
bzlm
XP is amazing, I'm willing to work with it soon. I guess that its "daily meetings" feature is one thing that would definately suit your case.
born to hula
I would say that Scrum scales a little easier than XP, but that's my opinion. From what I've seen, processes are processes, and every company uses them differently, but the one thing I've noticed is that XP works best in a culture where people don't make a step without getting input from someone, and Scrum works better in an environment where the teams keep their heads down and code in parallel. Coordinating teams becomes harder in XP with 10+ people, but in a Scrum you can divide the team easier, assuming the "Chickens" remember to stay hands off.
NateDSaint
It's not OK to treat all developers the same. Some will always know more and they'll feel demotivated if they're treated the same. Think about the Dreyfus model of skill acquisition.
Jordão
+10  A: 

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.

Patrick Cornelissen
You assigned an different employee to be in charge of that course every week?
Am
Depending on the topic. Either people suggest a topic and they do the course or the "guided" schedule is continued and you select the employee who is most qualified for that (and has enough time left to prepare the course)
Patrick Cornelissen
JuanZe
ALternative is to select someone to do the presenting who needs to learn the topic. Having to present a one hour course is a great way to get someone to learn something new. I did this at one workplace, we created a schedule of topics and then I assigned some topics to everyone, some were easy things they knew and others were more of a stretch. But make sure everyone has to do the presenting. Our sessions were not mandatory, but anyone who wanted to attend could come and that worked out well for us, but might not in some other workplace.
HLGEM
@HLGEM yes, that's a good approach too. But this depends on the topic and the amount of time that is necessary to get started. Sometimes it's better to get an introduction by someone who is familiar with it.
Patrick Cornelissen
It works best if you have junior devs who aren't experts on anything yet to help them grow or if you have senior devs who aren't interested in learning new things to force them to do so. Doesn't work with all topics, but it helps to approach it this way to ensure that more than two or three people are assigned the topics as well. If only the two senior devs do all the training, they are going to start resenting it.
HLGEM
+19  A: 

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.

Oded
+1 I'm familiar with that, it really motivates people.
born to hula
Yes, I've also seen this kind of thing work. Remember to have e.g. some food service at the meetings; something tasty, like candy and fruit. :)
Jonik
In my experience, this presentation is only useful if people listening can *immediately* embrace the topic. Otherwise people will nod politely, but forget quickly. Perhaps if topics were chosen out of actual interest it could work, but I haven't seen that in practice.
bzlm
+1 this happened about twice at work, and it's the sort of thing I'm always looking forward to (and maybe I should get it going)
Tshepang
+9  A: 

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.

Kane
In my experience, these presentations are meaningless. People who aren't interested won't pay attention, and people who *are* interested will soon have forgotten everything that was said during the presentation. If you have different actual experience, it would be nice if you could elaborate!
bzlm
+10  A: 

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

Phil Wallach
Dangerous idea, they`ll get suck into it for way more then half an hour, and I'll be fired for dropping productivity by 50%...
Am
It's dangerous, true, but I have to second this. I've learned more about "what's up" here than ever anywhere else.
Pekka
@AM So you can spend your day on SO, but your team can't. That sounds unfair. :)
bzlm
@Pekka, same for me, I was just kidding.
Am
@AM, I think workplace usage of SO can be a real problem to a certain extent in times your employees' concentration level is low. You answer a question... you do some research because you don't want to embarrass yourself... you test your code suggestion locally to make sure... and oops, there's 15 minutes gone, well, not out the window, but not doing any billable work, either. On the other hand, SO is a community to *hugely* benefit from, and asking something here can save hours of own research and testing.
Pekka
@Pekka there's also the ancillary benefit of knowledge here can frequently be applied to your billable work even if a question originally seemed unrelated there's been lots of AH-HA moments I've had just using SO and something connected on other topics at my work.
Chris Marisic
Absolutely, I've had the same effect often. All I'm saying is, if you allow or encourage the use of SO in the workplace, be careful with it and watch closely what happens (not in terms of watching people, but watching the overall productivity trend).
Pekka
+5  A: 

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 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.

Kragen
This is true only to some extend. If we build a "get up to date" culture at work, new workers will also attach to it, and we all earn.
Am
+10  A: 

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.

slugster
The code review is an excellent approach, (and one we use today)
Am
A: 

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.

Am
This is a good practice. The challenge is in getting the developers to 'buy-in' to it.
Cuga
+1  A: 

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.

Viktor Klang
I don't want to force, I want to encourage and assist. The salaries cannot be affected by this, it can lead to bad syndromes, like the famous bug bounty - http://bexhuff.com/2009/07/a-modest-proposal-for-bug-bounty-bonuses
Am
+2  A: 

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.

AndiDog
A: 

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.....

Sruly
+1  A: 

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

Bahadir Cambel
A: 

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.

High Performance Mark
Even old tools have new insights...
Am
haha, tools....
Steve
+1  A: 

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.

Cuga
+1  A: 

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. :-)

joseph.ferris
+1  A: 

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

Gregory
+1  A: 

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.

naivnomore
+1  A: 

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.

Graphics Noob
This is often used in the academic world, too. We used to do one presentation of research + one presentation of paper / week.
temp2290
+1  A: 

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.

JB King
A: 

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.

Paul
A: 

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).

djhworld
A: 

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

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.

Jordão