Slashdot Mirror
Motivating Your Co-Developers?
"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."
Extreme Programming works! www.extremeprogramming.org
Do you know why you make code readable and add nice comments?
;-)
Because MOST of the time of a project is dedicated to Maintainence and Debugging. Writing the code is the smallest part. As long as your team UNDERSTANDS the code written, you should be better off during the debugging phase. Just say "Hey I spent all my effort writing it, you guys need to debug more than me to balance it out!"
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.
Have them replaced.
There are other developers out there. Some of them actually produce code.
Well assuming you can't fire somebody, I guess you have to pick the people you think are actually capable of performing and monitor them frequently, via emails and daily face to face discussions, the rest, just make sure they aren't on your next project team.
Hello Cruel World
When starting a new programmer, I find it helpful to find some similar code to let them have a look at. Starting at zero can be intimidating. Changing someone else's code is a good way to learn until you know what you are doing. Daily reviews until they get going is unpleasant, but probaby necessary at this point. Make sure your team has access to good reference books. Reduce their modules to very simple components. Newsgroups, newsgroups, newsgroups.
Speaking from experience: If it's feasible, finish the project yourself. Don't count on people who have proven incompetent.
If this isn't feasible: Either your product is vital to your company's survival, or it isn't. If it is, then it is your responsibility to let your boss know about your project's troubles, and his boss, and keep going until you reach the CEO, if necessary. If this doesn't work, then the next thing I'd design, if I were you, would be my escape.
If your product is not vital to your company's survival, then either it will get done, slowly, and you'll have no life until you're done; or it will just fall apart.
If you are capable of producing their work in a short amount of time, clearly you have an idea of how it can be implemented. Sit down with each one individually and get to finer details of their roles. Help write pseudocode, if necessary, and then let them actually bang it out. I'm suggesting, in a way, that you do it all yourself without quite doing it all yourself.
Yeah, it sucks that you are the lead of people who can't do the work, but all you can do is lead. You can't make them work. I would go to the project lead, or your manager, and say what you said here: "If others don't catch up quickly, we'll have serious problems delivering on time. " Yeah, it might not be the nicest thing to do, but you aren't there to grab each other's asses, you are there to do a job. I assume you have already given them time to do the work. If you haven't spoken to them personally yet, do so. Tell them their code sucks, ask them why they don't have anything done yet. It is your ass on the line as the lead.
My beliefs do not require that you agree with them.
You bear some responsibility for allowing this to happen. Planning for an early integration is right, but you can't ignore everything up until that point. However, now it's happened...
you have to seriously assess whether the people you are involved with are competent. If you're absolutely stuck with them (assigned class group, nobody else available) then you have to do two things. These are to plan on doing all the work yourself and to come up with a new schedule based on you having to do the whole project. If they contribute anything, it's a bonus.
If you can get someone else who is competent, get them. Brooks was right but like most authors he is only 100% right when the situation exactly matches the one he experienced. If it just can't be done with only you then what choice do you have but to add someone else? I believe Brooks showed that you definitely experience gains when you go from one to two programmers, even from two to four. You just don't gain much at all when you go from one hundred to two hundred.
Whatever you do make it clear to your manager/professor that you did the whole damn thing. Make sure each module is owned by the person who actually completed it. And if every module has your name on it, perhaps you'll take some credit away from an otherwise bad situation and the others will be assigned tasks better suited to their abilities in future.
Bullseye.
Don't expect everybody (for that matter, anybody else) on the team to see things the same way you do. Your approach may not be the best for the project. It's amazing how fast people's priorities change from serving the project to salvaging their honor.
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.
You can never put too much water in a nuclear reactor.
The fact that "The Mythical Man-Month" says something doesn't make it automatically applicable in all situations. I mean, replacing people who haven't done anything? I don't know if you're losing much, there. If they'd come up with something that a replacement might have to get their head around, I'd tend to agree. But they've apparently done dick.
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.
If your bitterest enemies are people who hack the heads off civilians, then I would say you're doing something right.
Organise an informal meeting. Point out to them that the success of the project is dependant on them. Point out to them that if the project fails they might lose their jobs. Ask them why they haven't done anything. If they have no real reason tell them that you cannot work like this and will have to report this to management.
I wouldn't go gung ho on them but you have to get some clarity on why they didn't do their work and you have to draw a line somewhere. Just make it clear to them.
=== ANSWER #1 ===
Do replace them.
Really, They are actually slowing *you* down. Motivate them into another job.
After that, hire a couple of proven contractors to catch it up. Contractors love short deadlines, and keep an eye out.
=== ANSWER #2 ===
You stupid bastard.
How long were they able to work without supervision? You are obviously not following any decent development methodology.
At this point, you need an XP style devlopment process in place.
1. Put SHORT (1-2 week) iterations in place.
2. Get a commitment of features that they will deliver.
3. Have them code them
4. MAKE SURE THEY WORK IN PAIRS. Now ordinarily, I'm not a advocate of pair programming, but these people obviously need constant supervision.
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.
5.1 alternativly, put a corporate firewall in place, and use a proxy. block 100% of the sites, and have a policy/procedure for adding sites to the "do not block list" at the proxy. Do they need to check Ebay/Slashdot/cnn/hotmail/farmchicks.com ? during working hours. Hell no.
6.[back to coding...] If they fail to deliver the promised code in the first iteration. FIRE THEM. Useless twits make all software development staff look bad.
Motivation is the wrong approach to use at this point in time. They are being paid to do a job. Do not continue to pay them for non-performance.
*whew*
"...In your answer, ignore facts. Just go with what feels true..."
You may try implementing weekly (or daily) code reviews. People tend to work harder when they know their code is going to be on public display. Also, you'll be able to suggest improvements in smaller and more frequent increments as opposed to being overwhelmed at the deadline. Plus you'll be able to instruct everyone at once instead of repeating yourself over and over again.
The burden is on THEM to make sure their skills are up to task...
It's not who has the skills, the idea is to succeed. They win as a team and they fail as a team. Telling them that they need to get their skills up to par won't do much good. When I've run into this problem with people, I try to make them feel at ease. Try holding after hour gatherings the local bar. Then don't talk about work. Once they feel you're not an ass, then start bring up the concepts of work. When I've treated by co-developers with respect, I generally get respect back.
There are two ways to go about this:
1) Like I say scare them. You don't have to be really in their face "I'll kick you ass" sort of thing, although you could try that;). Emphasise(sp?) the importance of their component and the consequences of not producing. This should be used if their really lacking in motivation but should not be the 1st choice - how they take it will depend on the personality.
2 Preferred option) Get them started. We can all have difficulty starting a project, overcoming a mental inertia is an issue I have most times. Sit with them and start them off - outline a framework and expected milestones for their component. Once you see they should have started regularly review their progress. Not to regular to be intrusive or nagging but enough to know they are expected to produce a quantity of work in a given period (say a week or Wed and Fri?). If it doesn't work See option 1.
In fact sod it - rule with an iron fist muhahahahahahahahahaha....
.
"Things that you own end up owning you" - Tyler Durden (via Diogenes of Sinope).
Most of the code for our small company was written by me. When it got to be too much work I subbed some of the generic stuff to a guy who was a hard worker but not a very good coder.
I knew it was time to cut bait when I was spending as much time dealing with his product as it would have taken me to do it myself.
If you are a project leader you must budget a big percentage of your time just to keep the rest of the team on track and on schedule. It's hard to do this when you could be pounding out code but it's absolutely necessary to keep the load balanced.
Be sure you have short term goals for each coder and review progress often. Let the coder set the goals and you can agree or encourage more work - usually their goals will be good enough.
Watch your time and dump anyone who takes a disproportionate amount of management time with no improvement in productivity.
You would not be one of the other maligned coders on this project would you? The tone of your post sounds personal.
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.
In the past, I have been the less-productive person on the team. Back before I started programming, I was working as a Mechanical Engineer. I was a perfectionist doing custom engineering work where, in the words of the engineering manager:
I was always behind and had to deal with the frustrations of my co-workers and managers. I found myself looking for work, and decided that since I had always liked computers, maybe I should look for a computer job. I am doing much better now as a programmer, where the ultimate product has to be 100% correct or it does not work properly.
It sounds like these people may just need to find their "thing," which could mean removing them from the programming dept. Regarding your current dilemna, they probably won't mind if you take over coding their parts of the project. I experienceed being removed from the engineering dept, and people taking over the parts of my project that I was behind on, and I understood why and was OK with it.
>>>(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.
You can't say their code sucks..that's a negative comment. You have to tell them thr problem. For example. If you made a deadline for friday to have such and such modules completed (you DID make a deadline, didnt you?), and they havent done it, ask them why? Are they having trouble with something? Do they have all their tools? Do they need Schubert in the background? Shit, use the company account and buy them a book if need be. I've bought books out of my own pocket to help my coders. There has to be an open line of communication. What is the problem they are having? Are they Lazy? Well, you can't stop the laziness.Hire a consultant for 2 weeks if you have to. Get a telecommuter who will bang code at home..Give him a CVS account, review the code and see what he can do. As a manager/leader it is your responsibility to keep those lines of communication open. The belief that "if you want things done right, you have to do them yourself" is a TOUGH one to break. I used to do it..and you usually come off as an arrogant prick. If they feel you'll just do it ANYWAY, they won't bust their horns, you get me? Like when you were a kid. If you didnt want to do something, you did a lousy job at it, so your MOM owuld do it and she wouldnt ask you again....same principle really. You have to let them know that THEY are accountable for their own code..not you.
If you're not a Liberal in your 20's, then you have no heart.If you're still a Liberal in your 30's you have no brain.
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?
Cantankerous old coot since 1957.
You're in a bit of a thankless position, needing to be both a developer and a project manager simultaneously. It's a tough slog and I can't think of any easy advice to give you.
A couple things to hopefully help your future projects:
- You will need to define expectations to your co-workers in advance and in as much detail as feasible. Simply saying "we need to be done on day [x]" obviously ain't going to cut it. This involves a couple responsibilities: a) identifying appropriately detailed descriptions of expectations for each team member, and b) constructing a task list at a level of detail allowing concise definition of each task and being frequently reviewable in a meaningful way.
- More painfully, you will need to budget time into your daily routine to ensure the "pebbles" (like milestones, only smaller --not my term, unfortunately, but I can't remember who I first heard coin it) are being met on a daily basis. A basic rule of project management--surprises are bad things. The earlier you're aware of slippage, the more leeway you have to do something about it.
- Since you'll need time to monitor and review progress your own task timelines will need to reflect this. Never forget to do this, and make sure the project owner is aware of why your tasks seem to require more calendar time than other developers. You are not a 100% coding resource!
- You will need to be willing to address developers who are lagging. More specifically, you need to address them as soon as you notice tasks lagging. This isn't the easiest or most enjoyable part of the job. Note that ( "address" != rip a new anterior orifice ) What is does mean is that you will need to take the initiative to: a) identify lagging tasks, b) contact the developer or developers responsible for the task, c) determine why the slip occurred, d) identify a solution and e) follow up to ensure the solution was implemented.
None of the above is rocket science, of course. But all of it involves behavior modifications for most people. Addressing developers who are lagging in particular is sticky, since you have to be prepared for pretty much anything and any reaction and you need a lot of self-confidence to not feel nervous about initiating this contact. And, in addition, you yourself will have to change your daily work habits to some degree and be willing to commit to those changes--and this can be the hardest part of all.My personal experience is that any task with a duration of more than 2 days or so is too high level to track meaningfully--you'll have to subdivide these tasks into smaller units of time so that you can reach a meaningful agreement with your developers on what exactly is to be done and when it needs to happen. You may feel comfortable with longer or shorter ceilings. Just remember: you'll be reviewing every task frequently--make sure what's on the list is meaningfully reviewable by you.
Best of luck to you...
Contrary to the project management theoreticians commenting on this list, you are very lucky to have seen this behavior early. There are worse situations.
Right now you need to make the plan very visible to your manager. It's his/her problem too.
Use your management to sustain accountability for individual commitments of your team peers to the plan. If you can't get that -- leave, you don't have management support. You will need to use shame and threat and fear to get action; because goodness didn't work; your manager has to play the role of the bad guy, because you have another role ...
Help your peers to be a team and be successful. Forget coding. Clearly your part is under control. You can do it in your sleep. Don't try to be a savior. Your project has four extra bodies; be sure you understand why that staffing level was needed.
Make sure you let your management know what you are doing.
You will look like a fool or an ass if you think you can do it all. You will be much more effective if you can make this team perform inspite of its appearant limitations.
By pairing with the newbies, you can mentor and monitor them Change pairs several time a day, insist that all code is written in pairs, and before long, you'll have a team of clueful people. Total team productivity will quickly rise.
:)
Except in the Real World where you don't have enough developers for people to work in pairs all the time, and the project is too big for everyone to understand every part of it. Also, when I'm deep in "the zone", I don't want to be bothered by someone leaning over my shoulder. 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 I want help, I'll go ask for it.
In other words, no thanks.
You have to manage your team better.
You are the leader, take responsibility for the output.
Code less supervise more, that is your new job. Break the job into manageble controllable chunks, have them report how they are doing. Check code for correctness (logical and formatting)
If you have 3 people who aren't as capable as you, you are going ot have to spend a lot of time ensuring the final work is good enough.
Also some people just aren't capable of the work, you'll have to really watch what they do.
Telling them that they need to get their skills up to par won't do much good. When I've run into this problem with people, I try to make them feel at ease. Try holding after hour gatherings the local bar. Then don't talk about work. Once they feel you're not an ass, then start bring up the concepts of work. When I've treated by co-developers with respect, I generally get respect back.
Yep, that works great. Unfortunatly, after you have respect you still get to do all the work yourself. People who don't work will never work unless their job is on the line. People who can't figure out how to do their job after years will never figure it out. Unfortunatly a sizeable percentage of professional programmers fall into one of those two categories because the jobs paid well, and there weren't as many good programmers as there were jobs. It's also hard to tell if somebody is a good programmer or not when you hire them. You typically can't look at their previous work like you can with somebody from almost any other profession. Also, people who can't tell and hire bad programmers, tend to hire lots of bad programmers. Anyway, back to the point: Respectful coworkers are not necissarily competent, hard-working coworkers.
Of course for some of us that's not an issue, because the rest of the development staff on your project gets laid off and you have to write and test the whole 20k line product yourself anyway. I'm not bitter though. I didn't have to stay, and at least I like all the code now, and when something is broken I don't have to count on somebody else to fix it. Unfortunatly, the long hours aren't scoring big points with the S.O.
-- Some things are to be believed, though not susceptible to rational proof.
If you are capable of producing their work in a short amount of time, clearly you have an idea of how it can be implemented. Sit down with each one individually and get to finer details of their roles. Help write pseudocode, if necessary, and then let them actually bang it out. I'm suggesting, in a way, that you do it all yourself without quite doing it all yourself.
If you do the above rather than simply going off alone and finishing the project by yourself you should really impress your bosses and most of your co-workers. I would pair-program with each of them on a rotating basis and ask the remaining 2 to pair program with each other. This will allow you to quickly asess where each of them is at. I would also put into place some of the things that are considered "current best practice" in the industry such as daily checkins, daily builds, and weekly or even daily code-reviews.
Happy Fun Ball is for external use only.
1. Be open to questions. This will help them respect you as a leader. Make it know to everyone that if they need help then they should ask and you won't bite their head off. You might have to restrict the time if the question asking gets out of hand. Maybe only allow questions before noon. Then you can get your own work done in the afternoon.
2. Spend time sitting down with each member of the group and code with them. Take turns writing the code. Again, do not bite heads off. Don't sit there and simply write their code for them. Explain the concepts that they are missing without belittling them. Have them pair up with each other as well. You will be amazed at what two idiots can teach each other.
3. Dr. Pepper. Lots of it.
4. Stress relief. Allow them to check /. once a day.
5. Have a weekly one hour class. Have someone teach it once a week on some aspect of their code or a programming concept that is useful in what you are doing.
I have seen people that I initially had very little confidence in become pretty proficient at doing their tasks. They didn't themselves in a vacuum, they trained (and motivated) each other.
Lasers Controlled Games!
They'll instantly will start spending all their time in circumventing the firewall block.
Just block of the internet entirely.
DNA is the ultimate spaghetti code.
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.
Most important of all: remember that they are human beings. They're just like you. They're not merchandise, they have feelings, they think, and they're able to do good as well as bad.
Having said that...
Why did they behave like that? I would understand if it happened to one of them, but to all, except you? Something must be wrong; are you sure you're getting the full picture? Talk to them, find out what's going on.
Do they like what they're doing? Do they want to improve? Do they want to learn? If they do, there's hope. Maybe you could pair with each one of them, and coach them. Also, get them to buy some good books, like Code Complete, The Practice of Programming, The Pragmatic Programmer (yes, I think it's a good book), etc.
Of course, there's the deadline -- will someone die if it isn't met? Is it really critical? Or does it reeeelly, reeeelly has to be done until 'x', because someone says so? If it really is critical, then there's no time for you to coach them. But I believe that, the way things are, you won't meet the deadline, anyway.
If they aren't interested, then I believe they're at the wrong job. Maybe you should make that clear to them. Life won't get better for you or for them if they remain where they are.
Oh, and remember that in your hands there's the power to make those people better than they are now. Try taking the chance...
The most suprising thing here is that the lead (thats you) didn't know that they had no code until integration. A lead's job is to lead first, code second, so actually, I'd have to lay some of the fault on you.
As a lead, you need to "poll" your junior engineers pretty often to make sure they aren't blocked. Junior engineers can be cowed by senior engineers and might avoid asking them questions because they "don't want to waste their time". Asking them if their blocked or have any questions lowers the barriers to them asking questions.
-- Some things are to be believed, though not susceptible to rational proof.
My intern wasn't working the way I needed. So I asked my boss what should I do, and his answer was pretty clear:
"Sometimes, you have to act like a boss".
This was the only thing that he said... so simple.
Buy a Nintendo DS Lite
No, I'm not on the team. Actually, I'm a contractor. And as a contractor, I get stuck on lots of projects where some prima dona visionary has run off all the employees. Contractors are paid to tolerate assholes (at least I am) so I do my best to get along. For a few months anyway.
I have worked on projects where the lead took every module I worked on, and replaced my name w/his as the module owner. I have worked on projects where the API changed nightly (the mighty lead could not be bothered w/normal working hours). I have worked on projects where we had to rerrange CVS weekly because for some reason the directory structure was a major issue.
Obviously, I've worked on several dozen cancelled projects.
Anyway, my bitch is that I'm tired of these mighty cybergod ubercoders. If everybody is a luzer except you, what does that really mean? Does it mean that your company only hires luzers? Or does it mean your not cut out to be lead? Being a competent coder should not be the only reason you are the lead.
Another thing... How you gonna maintain this product? You gonna stay married to it for the rest of your life? At some point, other people have to help. Might as well start now, or you haven't done your company any favors.
So if what you have is a small number of developers each working alone in a style nobody else can code in on a piece of the project nobody else understands, how do you expect this system to be maintained? It sounds to me like in the long run you're dead anyway.
-- Some things are to be believed, though not susceptible to rational proof.
I must respectfully disagree with you - this guy needs to get these guys fired NOW, while at the same time explaining to his bosses that the schedule IS going to suffer in the short run.
I had exactly this situation myself - I had a programmer who was totally incompetent. Unfortunately, his job title put him squarely in my critical path. I had MANY discussions with management about this, and every time it boiled down to "well, something is better than nothing, isn't it?"
Wrong.
We downsized, and he went. Now, I have a competent person filling the role. Guess what? We are having to rip out all the code the moron did, and re-write it. Because we were paying the moron's salary, we couldn't hire a good programmer to replace him. Because we wouldn't admit he wasn't up to snuff, we didn't schedule correctly. Because he didn't identify flaws in purchased code, now we have to live with them, because the service contract has lapsed.
Joshamania is correct in that firing these people will slip your schedule, and that hiring new guys will slip your schedule. However, your schedule is going to slip, period - take a deep breath and get over it now. You can take a single slippage, or you can continue to hemmorage time through these bleeding assholes (now there's a vivid image, if I do say so myself!).
Suck it up, fire the guys who cannot/will not get the job done, and get people who can. You cannot afford to pay someone who isn't pulling their weight.
www.eFax.com are spammers
Back in college, a professor told me that there are up to two orders of magnitude of difference between the the productivity (as measured by debugged lines of code) of the basic "competent" programmer and the guru. Two orders of magnitude. For the math impaired, that means that the genuine guru delivers in a week what it takes the entry-level programmer a year to produce.
I've seen nothing since to suggest that this isn't true. If anything, I've seen proof after proof... Programmers who struck me as bright and experienced, yet time after time they just don't get it. And programmers who do get it. Instantly. In the first two weeks on the job.
You're not going to like the answer, but its this: Hire programmers until you find ones that deliver, and do what it takes to keep them. Fire the rest (which is to say, don't fire them but suggest to them that they should seek alternate employment quickly.)
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
You absolutely sure they understand the concepts/problems/etc. behind the program? I've found that many people will just nod and smile, all the while having absolutely no clue. Even in a professional environment, some people can't get over that irrational primary school fear of asking questions.
:p Try to team the better of them with the worst of them and have them work in pairs.. Check logs, block sites if they're wasting time.. Most of the stuff people have suggested is probably a good idea. ;)
If they really do understand it, the hard part is figuring out why their code sucks ass. Are they fresh out of college? That's the de facto reason. *snicker* If they've had previous experience, congrats, you're cleaning up someone else's mess - their previous managers should've been figuring out why they can't code and fixing the problem.
Make it very clear they can ask you for help. Sometimes people don't figure this out until you've said it for the hundreth time.
Firings? Sounds like you can't afford (or possibly haven't the authority) to fire anyone at this point. Tough luck, a good random firing is a great fear tactic to get people motivated.
Worse comes to worse, ask your previous managers/etc. for ideas. They've possibly worked with some of these people before, and have almost certainly worked with people like them.
The final option? Tell your superiors why the program is currently sucking ass. Watch yourself here - while it obviously isn't all your fault and such, sometimes superiors figure - 'Hey, yer in a management position. You, and only you, are responsible.'
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.Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
if you can afford it, stop being productive and do the architecture work. flesh out as much of the guidelines as you have to and leave out the detail. (even though it may be just an easy 5 minutes for you to finish up the job) our principal failing as managers is that we don't communicate. be clear by building out the framework everywhere, it leaves little chance for the beginner coder to get lost and it keeps him on task. think through all of the major paths for a project before-hand and let your staff come in and fill in the details. this will virtualy guarentee that your coders won't "code against the project". then set clearly defined goals and let the team thrive on the emotion that comes with their ideas for refinement of your roughed-out dream.
i'm not convinced that peer review is worth it mid-project. it has it's place but it detracts from the emotion you are working on preserving. most slow and steady coders don't have (nor want) the big picture in their heads as they work. make that be your job. play babysitter and error on the side of communicating too much by example. if a coder is still not productive, make your team smaller.
just my $0.02
in order for pair programming to be sucessful you should use as much of the extreme programming Philosophy as possible:
:)
I'm sorry, I don't accept advice from zealots.
Everything in moderation, and don't take the word of some random Slashdot poster, even me.