Motivating Your Co-Developers?

3flp asks: "We've heard all about those coding projects where 90% of the code is done by one person. Unfortunately, on my current project it's me :-(. It's a comms DSP project with a lot of C & some assembly. My team of 4 will hopefully produce about 20k lines of code. Now comes the problem: we just got to our first small integration stage (we do try to do them early & often), and it turns out the other guys have got nothing. No code. I want to ask Slashdotters, people who have the experience with small software projects, how would you go about it? How to bring other less experienced coders up to your level and beyond? Or at least how to make them suck less, and if they get stuck on something, to just come and bloody ask for help?" This is something almost every developer has had to deal with. For those of you who have experienced this, what did you do about it and how did things turn out?

"Deadlines are super-tight (what else is new)... but all 'my' parts are ready on time, and I enjoy what I'm doing. After about a month of design and two weeks of coding, I've got about 50% of my software features. The others definitely do understand the requirements and the design, because we had plenty of discussions. 'All right, lets get what you've got so far, we'll just try the interfaces, even if your code doesn't do anything much yet.' 'I haven't tried to compile it yet.' Then I looked at the little code they've produced, and it's a disaster (abhorent coding style, serious logical mistakes, etc). Obviously, these guys understand the 'domain' problem (I would think that's the hard part), but suck at coding (which is apparently the really hard part for them).

Hiring new people this late in the project won't work, as anyone who has read 'The Mythical Man Month' knows. On this project, I have a de-facto role of a software team leader. Before, I've always been just a coder, not responsible for others. So okay, I'm doing fine with my part of coding, but that's no use. If others don't catch up quickly, we'll have serious problems delivering on time. I need to stop hacking on 'my' part of code, and help elsewhere. They definitely do understand the requirements and the design, because we had plenty of discussions. 'All right, lets get what you've got so far, we'll just try the interfaces, even if your code doesn't do anything much yet.' 'I haven't tried to compile it yet.' Then I looked at the little code they've produced, and it's a disaster (abhorent coding style, serious logical mistakes, etc). Obviously, these guys understand the 'domain' problem (I would think that's the hard part), but suck at coding (which is apparently the really hard part for them).

Obviously, I need to look into some way of helping or motivating, but without putting them off. I could just take over someone else's module and code it in no time. But if anyone did that to me... well that's out of the question."

Comments

Bad programmers don't change.

[sllort]

My experience is that while some new programmers are destined to become good programmers, experienced programmers who don't write code rarely improve. My advice is to make sure there is tons of visibility and documentation early as to who is actually doing the work - and make sure management has access to this visibility. From that point, it's the responsibility of management to do their job and manage the resources they have. Taking this role upon yourself is usually a mistake.

Re:Bad programmers don't change.

[msobkow]

After 15 years in the industry, I'd say there are three classes of software developers:

1. The natural coder. This is the person with an intuitive grasp of technology, who sees the similarities in software architectures and reuses concepts across disparate technologies. Alas they are rare, maybe 1/10 qualify.
2. The "steady Eddie" programmer. The vast majority of support staff, documenters, etc. are "steady Eddie" types. They do the job, they follow instructions and designs, but are not necessarily creative or intuitive about it. They're the people who form the corporate infrastructure, and about 7/10 fall in this category. They are much slower than the natural coder, but do get the job done.
3. The clueless wannabe. Fortunately there aren't too many of these on projects I've worked on, but there are still more of them than natural coders -- I'd say about 2/10.

The original poster's commentary indicates that it's a relatively young/naive developer who is either a natural coder or a steady Eddie with an overblown ego doing the writing. Either way, I am guessing that he is quick to grasp concepts and ideas, and gets easily frustrated with people who don't -- and it shows. Even if such people try to be understanding or are "open" to questions, the way they phrase their answers is often intimidating to their peers.

You need to make sure people understand the project is truly a team effort, not a blame game, and encourage questions. If no one is asking questions, check with them daily to see how they are doing, but handle it as an offer to help out or clarify specs rather than just getting their status.

Learn the skills of your people. Those who can't code are often good at other things -- debugging, screen layouts, build management, etc. Very few people are actually useless, they just aren't necessarily good at what has been assigned.

When working with a team of juniors, start out by creating the outline of the code -- makefiles, interface headers, and stub code. Don't get into the details of your code -- make sure the overall project has been outlined. It helps juniors a lot to have a solid interface they are expected to implement, and it helps to modularize the system code.

When people ask questions, don't give them the answer, even if you know. I'm serious! Guide them with questions that lead to the answer, but let them come up with the solution if at all possible. This helps them to learn how to think (your questions show what they should be asking and thinking about), and they gain confidence by coming up with solutions "by themselves."

Ignore all the postings you've seen about beer, pizza parties, and threats of layoff or termination. You'll never succeed with a project if you are wasting your time and budget on frills and turning your staff into nervous wrecks.

If you do encounter a truly useless clueless "developer" who just doesn't "get it", make sure they're working on something non-critical and that their access is restricted. If you have to keep them on the project, try to use them as testers or for "grunt work" like build management. Even the most clueless person can follow a checklist to test software or compile code, and sometimes they can actually become quite good at it. Believe it or not, you need people who will be happy doing the mindless work -- most of the work on a large project is mindless.

Don't create your schedule on the assumption that everyone is going to code as fast as you. Be realistic, and then double the time allotted. Sad to say, I've often found that still doesn't allow enough time for some people.

If you find anyone on the team playing the blame game, snuff that thread. If someone complains about weak specs, redirect the discussion to suggestions about how to improve the specs. If someone is blaming other people for being late with interfaces they "need", redirect to a discussion of modular programming and how the interfaces can be designed without a full implementation. Whatever you do, don't let people get away with blaming others for their own shortcomings.

Perhaps most important, don't use the "big stick" of layoffs and termination to encourage people to work. If they are any good, you'll just scare them into finding another project, leaving you without resources. If they really are useless, no threats will improve their skills and you're going to turn the team into quivering, terrified blobs who would rather chew their own arms off than ask you for help or guidance.

Failing all of the above, make sure that management is aware of delivery issues and potential schedule changes early on. Even if you think you can recover lost time, make sure management knows the time has been lost so that it isn't a surprise if things don't turn out as you hope. Ensure that you've got a feature prioritization so that you know which features to sacrifice if it's critical to get "something" out for a given date.

Finally, keep smiling and keep it light. When all is said and done, it's just another project, not your life, and you'll only get ulcers by stressing excessively. More often than not things don't work out as you'd like, so learn how to manage them in the direction you need when they take a turn.

Being an arrogant SOB myself, it took me years to learn to be more gentle with my coworkers. Rather than bluntly stating my disappointments, I find it's much better to provide them with the interface headers (potentially with stubs), and let them code from there.

Re:Bad programmers don't change.

[0WaitState]

Best Post! This guy gets it. Only thing I would add is the use of code reviews, first as a teaching tool (review the better coders' work first), then to improve the lesser coders quality after they've gotten accustomed to the review process.

Fire them.

[Spud the Ninja]

I could just take over someone else's module and code it in no time. But if anyone did that to me... well that's out of the question.

It's not out of the question, it's the answer. Not doing the job you were hired for is a fireable offense.

Show them the coding standards that are to be followed. Show them the requirements. Show them the deliverable date. If they can't make those 3 things come together to the degree neccesary, show them the door.

Mentoring...

[CommieLib]

I've mentored a number of number of programmers, successfully, at least in our collective opinion. I think the key lies in the idea that "a question well-asked is half answered."

Most new programmers tend to come to me with nothing more than a vague sensation of "it doesn't do what I want it to." The proper reply for this is "come back to me with a good question." Until they can do that, they cannot be helped.

Once they have a good question, don't give them an answer; give them the other good questions that lead to / issue from that question.

Once someone knows how to ask good questions, they're halfway to becoming a good programmer.

Different working styles

[Nomad7674]

One point many of the posts so far have ignored is the fact that some of these programmers may not really be so bad, they may just have a different working style from you. My own personal style for creativity is to absorb information en masse for a period of time and then output a mass of stuff in a very short period of time. For my coworkers who spec, diagram, and plan out each microstep of their work, it can sometimes seem like I am doing nothing. They feel they have pages 1 thru 7 of their spec complete and I have nothing. Then suddenly three days later I am done and they are only on page 10.

The critical thing to manage different working styles is to clearly communicate your expectations. If your coders see a general project plan, they may well assume that the milestones you have set are "guidelines" and not requirements. If so, they will instead be aiming at whatever they consider to be the drop-dead milestones. But if you clearly get across that every milestone must be met then each person can manage his/her own working style appropriately... even if they may have to come to you and explain that the deadlines you have set will not work for them.

That is my 2 cents. It is also possible you just have an unmotivated, unskilled team and all of this "work style" stuff I am saying is irrelevant. But I find too many managers (both newbies and veterans) assume people are identical plug-in replacements which work the same way they do. Humans just don't work that way.

Re:Pair Programming

[HisMother]

> if all you do is implement paired programming you will fail

Well, no. That's not true at all. In fact, XP advocates universally recommend what Kent Beck attributes to Don Wells in the first XP book:

1. Pick your worst problem.

2. Solve it the XP way.

3. When it's no longer your worst problem, repeat.

You shouldn't and actually can't adopt XP all at once; you have to start somewhere. And for this guy, pairing is the place to start. You certainly can't recommend that these folks who can't squeeze out any code at all by themselves be encouraged to styart refactoring his code, can you?

Typical geek responses

[joshamania]

One of the big problems with geeks is that they can be assholes, as you may witness by some of the replies to my first post.

Did y'all even read the whole original story? This guy has a problem that he needs to fix right now . Firing people for two weeks of uselessness isn't going to solve the problem. If you haven't read The Mythical Man Month, go read it now. Bringing on new programmers half way through a job often makes the job take longer. Firing the old, less effective folks, and bringing on new folks is going to do just that. At the very least, the programmers that are there know the company and know what the project is and know all the other people on the project.

The original poster did not ask "what should I do?", he asked "how do I make these people more effective?". Hiring replacements can sometimes take months, and when you do so, you're not guaranteed that the new programmers are going to be any different than the folks you just fired. So let us focus on how to solve the problem, not make it worse.

Re:Pair Programming

[st. augustine]

Except in the Real World where you don't have enough developers for people to work in pairs all the time

This is a common fallacy, and a lot of us at the company where I work believed it until we'd had a few weeks of exposure to pair programming. Over the long term, two developers working in a pair will be at least as productive as they would be working alone -- first, the code they produce has fewer bugs; second, there are now two people who can maintain that code, so you've lowered your truck factor; and third, while they're pairing they can't be reading Slashdot.

and the project is too big for everyone to understand every part of it.

We thought that, too. But you don't need everyone to understand every part of the project. What you do need is for more than one person to understand each part of the project. I'd estimate that with most areas of our software, there's one person who knows it inside and out, one person who's at about 70%, and two people who are at 20-30% and could get up to speed quickly if they had to. (For reference, this is in a development team of ten, with a large multi-tiered cross-platform Java/C++ project containing about 1200 classes.)

Also, when I'm deep in "the zone", I don't want to be bothered by someone leaning over my shoulder.

No offense, but I hate trying to debug really tight code written by someone else who was deep in the zone. Unless we happen to think a lot alike, it's often a real bastard to try to understand what in hell they were doing. Pity your fellow developers and allow them some insight into your thought process. :)

And when I'm following a very careful train of thought while trying to debug a once-in-a-while seg fault, I definitely don't want to be interrupted.

If your pairing partner was with you when you started the train of thought, they wouldn't be interrupting you.

If I want help, I'll go ask for it.

Yes, but will you ask for it when you need it, or only several hours later when you've given up on figuring it out on your own?

Re:It's been said, but..

[Doomdark]

5. Install Web-tracking software on their PCs and/or the firewall. They are obviously losing the time somewhere, and it's probably due to web browsing.

I agree with some of your points, but I completely disagree with this one. From my POV, people have to be motivated somehow. Usually (or at least usually for me) it's because people have professional pride, somehow they feel what they do is important and/or interesting. Hopefully both.

If they go to Slashdot instead of getting something done, it's not because they can go to Slashdot (or if that really is the problem, they are weak spineless losers who should be fired right away). It's because they prefer that over working. Preventing them access there won't boost motivation or morale. You'll just be plucking small holes in the dam, to no end. On the other hand, if they do deliver and then browse weird web sites, who cares?

Programmers are not factory workers. They don't avoid doing job they like. But if they don't like their job (whatever the reason is -- from jerk boss to boring assignments to incompetent coworkers), they may well do something else. But this something else is usually "anything else", not just specific things you need to block.

In short, motivation is the key. Motivation, skills and experience -- threats can only gain minor temporary motivation ("I can't afford to lose this shitty job"), and never improve their skills (nor constitute useful experience).

*Why* aren't they coding? Good/bad?

[billstewart]

What we have here is a failure to communicate. If you're surprised, it's not just a problem with them....

You need to understand why they're not coding. Here are some possible reasons:

• They're still trying to clarify the requirements. Some projects have well-defined requirements, but many real ones don't, and maybe their parts are fuzzier than yours, or maybe they need help understanding them.
• They're still designing interfaces and test plans, and are wisely not writing code until they know what it should do and how to do it right. Maybe your part has more obvious interfaces than theirs, or maybe they need some help defining them, or maybe you're rushing off writing code before you've done your critical design work. Writing code is only the middlish 10% of the job.
• Maybe they're trying to build tools they need to build their real code. This could be forward-thinking planning, or it could be they don't realize the resources they've got available and need help finding / getting them.
• Maybe they're underskilled and over their heads and don't know how to do the job - but apparently you haven't been communicating with them, and also apparently they haven't been communicating with you.

So talk with them first and find out what's going on. If you can't come to an understanding, find a manager to help -- I don't mean a Boss to tell them what to do, I mean a Manager to actually manage the project and people. You probably need one of those anyway, and sometimes programmers can do that but sometimes they don't have the people skills to do it.