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

Pair Programming...

[Capt_Troy]

As far as experience goes: Perhaps have less experienced people sit with you while you code, sort of like peer programming but it will be more of a learning experience for them. Encourage them to ask as many questions as possible durring that time. I think this may slow you down a bit for a while but in the end you will have more experienced developers.

Keep giving them smaller tasks ...

[rlowe69]

I'm surprised no one has mentioned this yet, but if you are working with a group of people and you don't know their abilities, divide the project up. If they don't deliver properly by their deadline, cut their original task in half and assign the other half to someone else (probably yourself), leaving them with less to concentrate on. Then rinse and repeat as necessary.

Don't accept poorly written code just because "it works". If you do, you endanger the project and don't help the poor coders become better. The best way to become a better coder (IMO) is to bang away at one single problem and not worrying about doing "your share" and ending up spreading your effort too thin. When your teammates prove they can handle more coding, give it to them.

If you do it this way, you'll inspire confidence that your co-developer can do the job right. This confidence will, in the long term, be more benificial to the project and to the company you work for.