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

Don't be an ass.

[joshamania]

Number one, don't be an ass. I've been on projects where I've been treated as something less than human for asking questions. That is not very conducive to productivity.

If you truly want to bring the "lesser" coders up to speed, you're going to have to make an investment of time. You may even want to consider pair programming for a period of time. Not only will it make the other coders familiar with your style, but it may make them aware of many "tricks" that aren't documented in your standard learn-to-program-in-21-days piece of garbage college course.

Re:Don't be an ass.

[Manitcor]

Your method sometimes works however is not fool-proof. I had a similar situation a couple of years back and tried to work every possible angle. When it came down to it he was a nice guy but was dumb as rocks when it came to coding.

Turns out he was just really good at getting hired and then talking others into doing the work for him.

Of course people like him ended up getting fired every 2-3 months and moving onto some other company to leech off of.

Fact of the matter is becasue of the boom, everybody and thier dog decided it would be a great idea to get into tech (coding, networking, whatever)

Companies were so starved for labor that they would hire anyone who even sounded like they knew what they were talking about.

now that we are bottoming out and IT budgets are getting slashed only the best techs and the best of the bullshitters will get through.

My advice: dont let these bullshitters continue on, send them packing and hopefully they won't sucker some other company (if they do hope its your competitor).

I would like to feel sorry for all the people who have been laid off and fired during these times but from what I've seen many of those (there are of course exceptions) who have were worthless anyway and the teams I'm beginning to see now are more focused, better trained, more expierenced and know what its like to deal with the real world.

Of course there are still many fakers out there and I only hope that we can weed even more out over time.

And before you go off ranting about people who are just starting to learn: I have no problem if you are new and just learning, what I have a problem with are those who know the buzzwords and can code some scripts then talk a big game. However when it comes down to the wire and you have to go live in 3 weeks and still have a week and a half of Q&A and you still havent learned the API of the application youve been coding for the last 6 months then I have a problem.

Do I sound bitter??

and yes my spieling and grammer sucks.

Re:Don't be an ass.

[joshamania]

Exactly. A good bunch of idears there...

I wasn't specifically thinking of eXtreme programming, but pairing two of your lessers will certainly add motivation. It's much harder to play freecell if you have another person sitting there watching you be a dipshit.

Its a tough job and a somewhat dangerous one..

[cOdEgUru]

(1) People hate other people tell them that they suck at something. Whether they tell you that they are open to constructive criticism or not, they still would hate you.

(2) Sometimes its just easy to laterally move developers from one project to another if they are not being productive, than bringing the whole team and the motivation down. This could be done without raising any suspicions and with diplomacy.

(3) Sometimes constant probing helps, sometimes it doesnt. Reminds me of the dibert cartoon today where the guy wont do a thing without some sort of threat. He may not need to be threatened but send the PM to him every couple of hours anyway. Sometimes this could be detrimental to his position, but atleast he might realize somethings wrong.

(4) Theres shit happening everywhere and in every other company. This guy could just be freakin out about his job, his family, his wife, his parents and everyone he has to support if he loses his job. And hence instead of working hard to sustain his job, he might do the other, by wasting time getting more tense day by day. Its better to have the PMs or someone else from the team he confides in, to talk to him. But then again, that just might shoot his stress level through the roof.

(5) There are some people who just suck at certain stuff, it could be coding, communication or inability to gather requirements from the right people, and in turn building stuff that theres no need for. You will have to address these issues from the team leader level, keeping your team focussed towards the common goal

(6) These are people we are talking about here. Sometimes nothing works. Thats the way it is.

Your boss should recognize the efforts.

[Real World Stuff]

I have seen this happen before. The project manager, or the Department Head will eventually recognize who have not pulled their weight. This is what we managers cover in "milestone overviews". These are Pre-planned development gauges to ensure that collaborative efforts synchronize. Additionally, they provide hard data at review sessions and for salary matrixing. Motivating your co-developers is not your job, leave that to the manager. That is what s/he gets paid for. Do your part, collect your pay, and just gut it out. Eventually the less apt and inconsistent performers will be out the door. Hell, in this market there are 10 COMPETENT developers waiting for a shot.

Re:Use XP

[ultima]

My suggestion as well; in particular because extreme programming encourages one practice that improves productivity. Check out the website here - and pay attention to the concept of "pair programming" where programmers work in a team. Putting a good programmer with a bad programmer for a moderate period of time will often raise the bad programmer's productivity (though obviously, it kills the good programmers productivity and maybe his attitude). So keep rotating the programmers around until things have become suitably efficient.

The whole concept of XP is a bit awkward and works best in either a teacher/student model, or using expert programmers who know eachother well. Nowhere close to panacea.

Not to mention the acronym sounds evil and M$-ish :)

Heres what to do.

[Ironpoint]

Your colleagues will never live up to you, so I suggest quitting now. When you say you are the "de-facto" team leader, I'm guessing this means you are not the real team leader. You've got prima donna syndrome written all over you. You can either

1. Quit now
2. Slack off a bit and see if the others pick up. (Your not in charge, what are you worried about?)

But you will probably do

3. Continue doing your own thing and keep telling yourself how crappy your teammates are until your ego explodes and you get fired or quit.

Truthfully, in programming this is the most important thing to overcome. People become so attached to their work. Now imagine you are on a team of professional toilet cleaners. Without the galmour theres no ego involvement. No one ever said, "I'm such a good shit cleaner, my fellow shit cleaners can't keep up. What do I do?" Its just about getting the job done.

By doing most of the work, you are fucking yourself. Your superiors are the only ones who can rectify the problem. But they won't if they expect 90% of the work from you. And you can't just reduce the work you get done because it looks like you are slacking and you take shit for it while in reality you are doing the same amount as everybody else. The only thing you can try at this point is soft delegation. Ask people how things are going, ask them about their code, hound them, not like a boss, but like someone who is interested. You can't tell them what to do but by continuously putting the focus of things in their mind, they will respond.

Probably the best solution is go on a two week vacation.

Sounds like you need some project management...

[st. augustine]

You need someone (not you) riding herd on those developers and making sure they're actually getting work done. The company I'm at uses a lightweight process called SCRUM, where features (or "stories" in XP terms) are divided into small tasks, each developer is responsible for taking on and providing estimates for a fair share of tasks, and every morning there's a (short -- ten minutes, max) meeting where each developer has to go over:

• which tasks they worked on yesterday
• how long they've spent on each task
• how much more time each task will take to complete
• what they're going to be working on today
• any blocking issues they might have

(Any design, problem solving, etc. is deferred till after the meeting, and only the people that need to be involved in those discussions are pulled in.)

The project manager (who is not a developer and not a manager manager) is responsible for keeping track of the tasks and the hours and making that information available. It's always clear who has responsibility for what and who's blocking whom from getting their work done.

This does a great job of keeping developers productive, and since developers get to make their own estimates (and the total amount of work that can get done in a development cycle is based on 40-hour weeks), it also does a good job of keeping them sane.

(It works well with eXtreme Programming practices like pair programming and story-driven design, too.)