How do you motivate peers to become better developers?

Question

In my experience there seems to be two kinds of developers (if we simplify matters a great deal of course).

On the one hand we have the developers, who may do a perfectly acceptable job, but who do not really care about the computer science part of their craft. They usually know few languages / technologies and are happy to let things stay that way. For whatever reason, they don't try to improve their computer science skills unless this is required in their current position.

On the other hand, we have the geeks or the pragmatic programmers if you subscribe to that idea. They play around with other languages and technologies and usually have knowledge about several topics outside the technical domain of their current job.

I would like to see more developers, who are enthusiastic about software development. If you share this point of view, what do you do to push your peers in that direction?

Edit: follow-up question inspired by one of the answers: As non-managers, should we really care about this? And why/why not?

Answer 1

By example. Remember you cant change anyone, all you can do is be a good example and hope they learn someday.

Answer 2

In my experience you can't. You're either interested and engaged therefore up for learning new tech, or you aren't. No amount of coaxing will change that.

Answer 3

Try to be one.

When they are right, and you are wrong, accept it graciously.

Be gently intolerant of poor solutions, whenever they ask for your advice.

Answer 4

Trying to get your coworkers to learn new technologies is like trying to get your girlfriend to go the gym.

Answer 5

I think peer-reviewing is a great way of both increasing the quality of the code and sharing knowledge.

Of course this must be part of the development process. When it is, you very often learn new things every time you get someone else's (constructive) opinions on what you have just created. And I hope that applies also to less motivated peers...

Answer 6

The book How to Make Friends and Influence People by Dale Carnegie is all about this. The title is a bit weird, I agree. It has a lot of the same ideas already left in comments here and gives you concrete steps to follow to get better at doing this.

If you can get your employer to fund you attending a Dale Carnegie course on leadership that would be great too.

EDIT: Yes, as a human being I think it's important to be encouraging to everyone around you and bring out the best in them. They will notice and respect you more thereby trusting your opinion more. And so the circle continues. It's all in the book.

Answer 7

if you're the team lead, then:

1. by example
2. with a rolled-up newspaper
3. with private teasing
4. with public ridicule
5. with threats and promises
6. by replacement

if you're not the team lead, then all of the above still applies except the last one.

oh wait, you said motivate... ;-)

Answer 8

This is hard. If you have five colleagues who are satisfied with their current skills and at the end of a year one has been motivated to do better, you are doing well.

I encourage you to aim your efforts not at changing individuals but at changing the culture. For example, you could have a periodic 'tech talk' seminar in which people who are interested in new technologies talk about what they've learned. You could bring in visitors to talk. Make sure there is free food. Create a cultural expectation that all the cool people go to the tech talks. Expect this to take months.

The next step is to get your colleagues to present something at the tech talks. If they don't want to learn something new, then get them to present a technology they already know well. The talk will give everyone, especially the speaker, a better idea where the speaker stands in the group. People like to look good in front of their peers.

You can see that this is hard work that will take a long time. You will need the support of your management. But the idea is to create a workplace environment where of course it is understood that everybody will take time to learn new things and get better.

Summary: make your workplace better, and your colleagues will follow.

Answer 9

I may have been reading too much Peopleware, but it's natural for developers to want to create quality products. As long as the right conditions are set then developers will write quality code. The best way to get developers to write to the best of their ability is to form a team.

If you are part of a team your fates are drawn together. Much like with a choir you could be a phenomenal vocalist, but if the rest of the choir is out of key and sounds sick then you'll be remembered as being awful. No one ever remember that really good vocalist in the bad choir.

So yes! It is definitely your responsibility to help out those that need to be helped. The best way of doing this is to play to their quality control side. Have a talk with them, review their code and let them review yours and give them friendly and honest advice on how they could make things better (and above all, easier). If a co-worker of mine were to show me a method of writing code that'll make my life easier then I'd be damn sure to be thankful.

Here's a good example. Earlier this year I was trying to write a RSS to HTML parser in PHP when I was told by another developer that there was already a built-in method for doing this (SimpleXML). Despite this being ages ago I'll probably never forget the information I learned.

Of course, the Peopleware definition writes more about the managerial approach to ensuring that a Team actually exists, but there's nothing stopping you from helping out those around you. In fact, it'd make your life a lot easier.

Answer 10

I would certainly think that even as non-managers, you should care about who you work with and support their attempts at improving their skills however well you can. I think all of us who care enough about our craft do prefer to work with similarly motivated people and thus have a certain expectation as to what level of continuing professional development we and others should strive to. This doesn't mean that all of us should eat, sleep, breathe and dream coding all the time; just find the right balance and the right environment, and try to be a positive influence on your environment.

That said, programming, like most other professions, has its share of people whose priorities lie elsewhere - they've got families, hobbies and potentially - I really hesitate to say this - a life :-). Mix that in with the somewhat prevalent attitude of "good enough development" and there isn't much of an external motivation to spend a lot of time on professional development, especially when you're juggling a house, 2 1/2 kids, a cat and a dog and want to be able to sleep for a few hours each night.

I find that to a certain extent, leading by example can help, provided that you are willing to both spend the additional time necessary and can teach the skills. A lot of companies do have internal training sessions - at one place I worked at, people could volunteer to hold a training session (admittedly during lunch hour) and talk about new and cool technologies, stuff they've discovered while working on something else, interesting developments they've read about etc. Now if you do this right, you can get whole teams to turn up and hopefully excite those people who would rather not spend their evening in front of Stackoverflow.

Answer 11

Yes, we should care about this as in a way we can be leaders in trying to bring in new tools, technologies, processes, systems, or thoughts to how the business operates. The 2 or 3 developers that say, "Psst... try this for version control," in having Subversion replace Source Safe is likely better than just one person constantly spewing about how he or she would like things done.

Where are the bigger effects: You on your workplace or your workplace on you? We bring our own personal culture and styles to the workplace and have to recognize that there is a role for us to play in making it better by introducing things to try to move things into a better work place.

Answer 12

Get a wiffle bat and hit the dumb developers when they try to push to production untested code or do obviously dumb stuff. I'm a big fan of the line "The beatings will continue until moral improves" and "Wall to wall supervision".

Seriously though, the fastest way to motivate the unmotivated is to make your problem there problem. I constantly would blame/kick files outs of SVN if they didn't even have the bare minimums of code comments. Otherwise I'd drag developers into open conversations about a projects architecture, avoiding making them look stupid, but trying to get them to contribute and either buy/sell idea's.

Answer 13

This is the ultimate question isn't it, how to motivate people? And many public figures charge huge mounts of money on the speaking circuit to do just that.

In the short term... Fear! If someone thinks they will lose there job or are falling behind, then they will put in more effort. Though, even then some people may just simply opt out.

The only long term solution to motivation is to breed Passion! If you enjoy what you do, you will strive to master your craft. How to do this? Well I think it will be down to the individual, although there are a few commonalities in which we all can share;

• Make it fun
• Create a community & culture of knowledge sharing
• Embrace the inner geekdom
• Expose developers to different worlds (ie ruby for a .Net shop)
• Learn to embrace new/different technologies not fear them
• Reward creativity and nurture independent thought on own time
• Do not punish or ridicule bad behaviour

These sound like things you might hear a pre-school teacher say about their 5 year old students, but it is the primal instincts we all follow regardless of age and occupation.

Answer 14

Try to make it clear that this is not a competition about who is the better programmer, but instead a team whose collective goal is to add value to the company while becoming better developers. Take everyday decisions keeping that in mind.

Reading and collectively discussing Peopleware or a good programming book might help, but no help is better than the practical example from managers and coworkers.

After that you can learn from each other: by setting coding standards, code reviews, pair programming for some new developments (when it is important to get the design and the core programming right), planning for unit tests, refactoring when it's useful, introducing design by contract...

In short:

1. Avoid the most obvious causes of teamicide

2. Build a better team every day

And always remember that 2 will be useless without 1.

Answer 15

Lead by example. If possible, don't try to motivate.

Answer 16

Personally there has to be some level of interest of the other developer for motivation to work on any level but I can think of a few things.

1. Try pair programming with them and demonstrate results through action
2. Introduce them to new concepts and techniques
3. Be patient, respectful and understand the level of the person you are working with
4. Provide objective constructive input during code reviews
5. Have them review your code and expect to receive and respond to feedback

Answer 17

As a non-manager I often feel that I am somewhat powerless in these situations. All I can really do is try and lead by example when it comes to produce clean code. I will of course recommend prototyping solutions with new technoligies from time to time, but at the end of the day the final decision is not mine.

I would like to do more code reviews, I've always thought that is a good forum for improving code and the abilities of myself and my peers.

There is just so much more to learn :)

Answer 18

Change the workplace culture.

Always approach any change as an opportunity for the whole team to improve. Whenever possible chose the change that will improve things for everyone. Start with small things that make everyone's day better. Don't try to change everything at once. Encourage curiousity and make learning and teaching a natural part of your team culture. Peopleware has many tips for how you can improve the workplace.

Conduct honest code reviews.

You won't improve until someone tells you to your face that your code isn't good enough. Sometimes the only way to enable honest code reviews is to identify the person most open for change in your team and perform quite brutally honest code reviews on each others code with the rest of the team present. After a couple of sessions a few more of the team will hopefully feel comfortable to join in on the review. An important aspect of code review is to have a follow up review when things get rewritten or improved that highlights why it is better and gives credit to those who did the work.

Identify different strengths.

Encourage the best at something to help everyone become better at that. Avoid singling out an individual as the generic "best developer" - it may make that one developer feel great but everyone else will eventually dislike him.

Be comitted and patient

Firmly follow through on any change you introduce and make sure you give it sufficient time to succeed.

Unfortunately some of your team members might not have any interest in improving. Depending on team and company size you may concider if they are perhaps better suited for another team. You should not cave in for the temptation of drawing up new rules that all developers must follow or any other teamicide actions that may spring to mind.

Answer 19

You can categorize developers by how much they care or how much drive they have to learn and the level of innate technical ability or skill they possess.

TYPE A: HIGH DRIVE HIGH SKILL

TYPE B: HIGH DRIVE LOW SKILL

TYPE C: LOW DRIVE HIGH SKILL

TYPE D: LOW SKILL LOW DRIVE

Firstly. management needs to vigorously avoid or jettison type D people - nothing much will motivate or improve them. Secondly, there must be enough of a critical mass of the Type A folks to be able to bring up the types B and C. The reality for most is that their teams will be largely comprised of B, C, and D people. Theoretically C people have the most potential, but even B types can be useful workhorses (albiet often frustrating because of the mistakes they make). The common excuses for a status quo of mediocrity or worse in development are:

• It cannot be done diffently in this company/environment/project
• All other ways are too complex
• There is a thousand good ways to solve a problem
• I don't have the energy or will to find another way
• I don't have the time to find another way
• I know this way and it works just fine
• Others will not be able to maintain a complicated solution,
• My favorite: I barely understand WHAT we are solving and the only way I can relieve this stress is to use a tried and tested HOW

I don't want to detract by responding to each of these excuses..there's a lot that can be said for each though! Anyhow, the most effective techniques I have seen to motivate the B and C people is plain old talking and whiteboarding with the A folks and the As leading by example (without severely hurting anyone's egos). Naturally, the type A folks have to be willing and patient to share information and not be the types who like to hammer away at code alone in a deep dark dungeon.

Do B and C know what they are doing differently? Do B and C know there are better ways that are not too hard or too complex (rather simpler and more elegant)? Do B and C know how A solves problems?

Can A share how he understands the problem? Can A share his solution to the problem? Can A share the solutions he rejected and why?

Final must have: B and C must not despise A for being a smart arse and A can talk to people without being too much of a smart arse.

Honestly, more than often, I feel the biggest problem is that people do not want to take the time to understand WHAT problem they need to solve so they are unable to effect the HOW to solve it in the right direction. I believe a culture of design simplicity and elegance and understanding problems (before you try and solve them) can be very exciting and rewarding to developers .. they just need to know it is possible (in their workplace).