What is a good balance for having developers learn at work

Question

So now I am the manager.

One of the things I always promised myself I would do is have the other developers focus on learning new stuff. In fact I even want to force them to read a couple books that really helped me learn to program.

However now I am also accountable for the product getting finished. I have this vision of everyone reading books instead of working and me getting fired.

What is the best way to work learning into the developers schedules, especially for the ones that just don't care to learn. How much time should be spent on learning in a work week?

Answer 1

What about taking a page from Google and going for 20% time?

Just make sure they have something to show for it.

Answer 2

Give them challenging work that requires them to learn to complete it. Learning in a vacuum is hard to motivate yourself for and you don't learn so well.

If they are learning in the process of completing their work, you do't have anything to worry about.

Answer 3

I think learning is not olny about reading books (which of course is a good thing). I think a good idea is to make your team discussing all problems with each other - this will help to share their exprerience. Also I think you should consider code reviews.

Answer 4

Definitely not requiring learning (though I agree with LW that challenging problems should help). I would love it if I could take programming classes for free.

Answer 5

I think regular code reviews may be a suitable solution, that way people can learn from others as well as suggest other things that they can learn in their own time.

It really helps to let a fresh pairs of eyes look at your code, they can spot ways of improving things that you never would of thought at first glance.

Reading documentation and books is always a good step for learning, perhaps setting aside a portion of time a week to do this might be a good idea? Even incorporating it into a code review session might work, then again I've never been in a managerial role so I'm not familiar with typical deadlines etc.

Answer 6

As mentioned earlier, challenging work doesn't always exist, and you can't force people to learn something if they just don't care. So the best way I see is to keep them in a high level environment. Psychologically speaking, people behave differently in groups. Logically, people surrounded by smarter people tend to learn more.

If you can't afford paying a whole team of genius, you need few that fit and are disposed to teach others during work time. These teachings should preferably be related to work, but not strictly. And even better if they occur like in a school class.

Invite all members to share knowledge using this process, and if affordable, reward the best presentations. What could be better than that? :)

As for your last question, the amount of time spent on learning depends exclusively on how much your company can afford. You may start with a low percentage of time, and raise it according to measured benefits.

Answer 7

Learning should be done within problem solving context. If I was the CEO I would hate to pay employees just to read books :)

Answer 8

You can't force anyone to read the books you found helpful. I don't really know if you'd want to, isn't diversity even better?

However, I think there are some ways you could subtly steer your slaves team to be more what you want them to be.

1: Barriers to entry

The first thing to do is to remove all 'barriers to entry'. I.e. don't make them buy these expensive books from their salary. For example: make sure there is a fund for each developers with which they can buy their learning material. failing that, a 'library' of sorts could provide books which they can borrow to read at home, new books could then be requested by your developers and acquired by the company for all to use. I do not think you should let them read books under worktime, unless directly related to what they are doing. Good developers have at least one programming book at a time on their nightstand (Right next to the Hitchikers Guide of course).

2: Use a carrot

The second part of the plan is to add a little motivator. Be clear that you want your team to grow as developers and make it an important part of their periodic assessment. They'll get a better evaluation if they have shown growth, and will get a bad evaluation if they do not. A salary increase should be coupled with this assessment which is only logical, a growing developer increases his value to the company. (And again, because it in the end is about making money, make sure they know about this!)

3: Get better people

The third part is hiring the right people. Every new person in your team should be one that is willing to learn, obviously! This has two advantages, not only do you have someone that is willing to learn but someone that will lead through example. Not learners will hopefully see that this new whippersnapper (and every old member that does take up a book or two) is climbing the ladder relatively quickly in respect and eventually in salary, which should motivate those still resisting.

4: Remove the bad people

The fourth and final part of the master plan is to remove the bad apples. Developers that do not want to learn even after all barriers have been removed, subtle pressure has been applied and saw what could come from applying yourself, should not have a place in your company. The negative assessments they will have accrued by now will help you to build a case to fire them. Although firing someone is not a happy occasion (well...there are those instances... ;-) ), you will have removed a bad influence and as a bonus you now have a place to hire one of those whippersnappers.

Answer 9

One approach you could take is to share knowledge amongst the team. Where I work, we introduced the notion of "Coffee Break Presentations". Take a developer who already knows a subject well and have them give a brief informal presentation on that subject to the whole team. Get them to demonstrate the subject and impart any wisdom/tips/tricks/gotchas gleaned from working with it. Encourage a team discussion after the presentation. Supply biscuits, and get everyone to take a drink to the presentation to promote the informal atmosphere.

If nobody in the team has any specialised knowledge, pick someone who has an interest in self-learning, give them some time (ie. a day or so) to learn something new, and get them to present on it. It works better if the subject matter is related to the work, but not always.

The important thing is to keep it brief - nobody wants to sit through a long, boring presentation, and it will eat into schedules if the whole team is taken away from development for a long period.

Additionally, working on new and challenging problems always requires some learning, but this is highly dependent on the work available.

I think it's hard to say how long should be spent each week as it will vary week-by-week, and most learning will come from actually doing work and finding out how to do things. The "coffee break" technique has worked well for us without taking too much time out of the development schedule.

Answer 10

What my company does now is give employee the opportunity to pursue some pet project of their own, for one work day per month. It doesn't have to be something closely related to work - whatever you always wanted to look into - you get a day per month to do so.

Once every three or four months, those who did take that time come together amongst their peers and present their endeavours - show off some cool code, report about investigating some technology and finding it to be unsuitable for their needs, or whatever - doesn't matter.

I like this approach - those who are willing and interested in learning and experimenting with new stuff are taking the chance to do so and will come up with some great stuff, and those who are not too motivated to learn aren't being man-handled into doing something if they don't feel like it.

Answer 11

We do 10% (one afternoon a week).

We also attempt to come up (between management and devs) with training topics that can benefit the project/company as well as the individual.

For example:

• "spend the training time researching [multithreading] and present the other programmers with a brief report that summarises the key points you have learned, or a couple of URLs that were the best resources you found on the subject"

• "Investigate how to use [Technology X]. Write a tutorial app or introduction to help other programmers learn this new technology"

• "write a library class that provides [helpers for parsing CSV strings]"

The idea is that the programmer does something that will help them learn new tricks, but also that provides library code the company can subsequently use, or reference material that other developers can read to help them learn things too.

Just saying "go off and do whatever you feel like for the afternoon" tends to result in people doing stuff that they want to do, not stuff that will necessarily improve their skills or benefit the company. (I think the Google approach works if you have money to burn and enough programmers that one or two of them will come up with a hot new killer app that you can convert into an income stream that offsets the developers who will just browse the web or play about with out-of-domain technology)

Answer 12

Here are a few questions I'd have about this:

1. What is the purpose of the learning? Is it merely exposure to other technologies and ideas? This is a question of the motivation as otherwise one could just go through the motions which isn't what you want I'd think.

2. What proof of the learning would be needed? Should there be some end result to show that, "Yeah this really was absorbed and applied here?" This is looking at it from the management's view to some extent.

3. How are different learning styles accepted? Not everyone can read a book and do what is suggested, as some may prefer an audio book, others may want a group activity rather than learning solo, etc.

A flip side to this is to have the developers consider how well does the current methodology and tools work at doing the work. Are there new things that could be added? Are some things that may be worth cutting out? These are some other ideas to consider in terms of what could fall under learning as there are various tips and techniques one can discover in applying Agile principles.

Answer 13

You can't make people do it. What you can do is support and foster those that do. have lunchtime show-and-tells perhaps. Start with your own.

People are different and their brains work differently than yours. You cannot expect people to work like you do. Your expectations are setting you up for disappointment and failure.

What I would do is learn what each of your reports' interests are (outside of work as well as work-related interests)