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."
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.
(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.
Rapid Nirvana
I'm going through the same situation, with a developer, except in this case I need his work to be completed so that he can move on to a piece of the project that i need done, He's been developing (rather trying) a servlet that will send a file to a user. He's been at this for the better part of 2 months. I'm tired of his reasons why it's not done, so today I decided to see how hard it was to develop a servlet that does what I need (I do not know very much Java) Well wouldn't you know I have a prototype that will download a file and save it to a local directory after spending 3 hours on it, most of that time was spent configuring Tomcat and designing a web page. Now I have to explain to managment why I want this guy gone!
My solution is fire him!
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.
If we don't fight for ourselves no one will.
If your project needs any small utilities or tools (such as some build stuff or file utilities) get them to do these. They can write a whole program themselves, making it a personal project they are more likely to finish.
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
Programer's SHOULDN'T be micromanaged! The programmers I asscoiate with LOVE their work and don't need guidance..give them some documentation on APIS and a couple of weeks their up to speed. I have done work which I absolutely abhored...(device drivers...bLAH! Not sexy :) )and I did putz around...but at least I was a contracter and I knew once I finished it was over. When i hired programmers, I never looked at the skill..I looked at their passion. If you have passion for something, you'll GET the skill. If you have skill, but no passion, you'll always be mediocre.
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.
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.
The answer? Make sure you (as the senior dev/team lead) get involved in hiring, and ask people to code on a whiteboard in front of you, a simple problem like a linked list etc. This will have the mildly negative consequence of weeding out some good people who get stage-fright, but it will also weed out those who just cannot write any code at all. And the people who get stage-fright are also likely to suck in code review, where being unafraid of having your code publicly disected is a crucial skill. And people who don't get much review are unlikely to be great coders.
So ask the person to code a simple data structure/utility program whatever. Make the person take their time, comment their code, and ask them harder questions, language specific questions. So for example, I am currently coding Java, so I might ask them about a clone function for the list, synchronisation, serial form etc. For c I'd be looking to ask about pointer issues, and in particular work in a question about the difference between pointers to pointers vs multi-dimensional arrays with declared sub-array sizes.
You can't change what you have, but you can sure make sure the next set are better. For what it's worth, I don't think Brooks' law applies to this situation. Replacing someone who cannot code with someone who can will cost some time, sure, but it will also generate some code. I once heard it suggested that on any project of 10 or more people, you can sack one person and the code will be better quality and delivered faster. The longer I work, the more I believe it is true. And replacing that person with someone good is always a win.
- 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.)
-- Some things are to be believed, though not susceptible to rational proof.
Comment removed based on user account deletion
The main problem I have is when I've lost focus on a project, mostly this is a internal political problem at the company, that causes a project that a developer designs to be completly retrofitted by some marketing f*ck who dosen't know what he's doing.
:).
Once that happens, the project goes downhill. It dosen't *always* happen, it just *usually* happens.
What I find is that if you give each person of a group a rough idea of what they have to work with and what each chunk of code has to return or do, it will get done. Once you start spoon-feeding it to them, they no longer care to complete the project (multiply this by 1,000,000 if the person spoon-feeding is not technically inclined).
Of course, I would have absolute faith in my employer under all conditions if they did things for me more offten, like random "take a day off", and mabye the occasional cash bonus at the finish of projects, but it just isin't going to happen and that's why most programmers are just hired guns, going to whatever job pays more. Having faith in my employer would most certianly give me a sense of purpose while listening to the mindless drivel of a marketoid trying to figure out if blue or red is a better color for a text box (actually happened to me, I interrupted the meeting and asked if I should go fetch a box of crayons for them to decide with, this didn't help
But then again, isin't some kind of faith in your job what motivates employees at most companies?
*shrug*
Just my 2 cents.
I would suggest the following as the normal way you should work with your team --- You will be amazed how much things improve.
1. When you assign some work ask them to plan and estimate their piece of the work. When they think about what they need to do, they will naturally ask questions -- and give you an opportunity to help. Stress the importance of their understanding what they are trying to do and thank them for clarifying the spec even if you think they should already have known what they asked.
2. REQUIRE absolutely that they break the job up into small (40 hours and better yet 20 hours) pieces that they can unit test (what a concept!)
3. Gently hold them to their estimates and when they exceed them, point out that developers typically underestimate by 30% until they get experience doing it. If they beat them let them know they did something neat!
4. Follow up with them on a daily basis and ask how they're doing -- encourage them to alert you to problems early and then help them through the problems.
5. Adopt coding standards. Just pick one -- the use of any standard is better than no standard at all.
6. Plan code reviews for various modules -- start with really good ones and identify and praise the good parts, then go on to weaker ones. Avoid direct criticism and don't do code reviews until you have read and practiced the methods of doing code reviews (being considerate, gentle, and framing criticism in non-negative packages are a good start)
7. AND MOST IMPORTANT - look in a mirror and tell yourself to do the same things! Look at your work and your estimates and start improving them.
Look for a way to make your co-workers succeed rather than putting effort into documenting their failures. Otherwise, you'll perceive yourself as working with "idiots" the rest of your career.
As a Computer Science student (one year left), I took a software engineering class this past semester that was basically about the different models and processes of a project. While the waterfall model and others were used and introduced, a variety of techniques like XP were taught as well. The advantages and disadvantages of different development techniques were addressed, along with material on how to find the right process for a given task.
Although acceptance can be slow, schools *are* teaching this.
Do your co workers care?
Simple point, after this project, if you have shown you are the brains and brawn(let us hope) then you will stay with the firm. Look long term. You have shown from posting your comment that u care. That is important. Many firms die to hire empoyees who care and know what they are doing.
As for your co-workers, Try and get em to take part, they may well be genuises at keeping code together after the end of a project, brilliant at making sure project bosses implement the right thing(damn good communicators), you might not like doing doing all the work, but are you a team? You say they aren't completing, I hope u are experienced enough that completing is not all.
If u are my sympathies.
Most folk I have worked with reallly did not like being shown up, but I learnt from them, I showed that I learnt from them. Then all of a sudden they were level with me. Thinking they were not just left behind, these guys/gals learnt from me, thinking that they therefore can equal him me . Some one mention
Enjoy, well never give up.
As a CTO in charge of a number of programmers, of various skill levels, I've found it's good to vary the method I use to define the problem. For really good programmers, it's enough to tell them to "solve x and produce y." For lesser programmers, it's helpful to write the steps out explicitly, i.e., "do step one and produce x1, do step two using x1 and produce x2...do step? and produce y." I personally write the steps (as comments) for these programmers. If needed, either I or one of my better programmers, will write tests for each phase to ensure the code meets the standard. You may find that, using this technique, "marginal" programmers are capable of producing good code. What they lack is the ability to see the big picture. So, break it down for them.
The world of achievement has always belonged to the optimist. -- J. Harold Wilkins