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.
I am all for going the paired programming route. It gets some undeserved bad press sometimes, but I think it is very effective.
It allows you to stop those bad habits right away, and lets you show them the correct way to do things. Simply pointing at something and saying don't do that, doesn't work. You have to say stuff, like don't do that because.... Try this way instead because....
It also allows you to share knowledge of all areas of the product. If they don't know how something works, how are they supposed to use it? If you put it together with them, they have intimate knowledge and can share it with others.
It is an investment in time in the short run, but in the long run it will pay off.
(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.
Well, I never had this kind of experience, but when I was a newbie in a company (and in programming) and we were starting a project a more experinced collegue sat down with me and other programmers and defined some standards. Like code standards, and naming variables and objects standards and so on.
So we were always helping each other on each other modules, and everybody, even the newbies, could understand everyone else's code.
That was pretty helpful for me, so whenever now I'm on the other side of the role, I do the same thing: defining standards, milestones and a personal chat to each one of them, that's really importamt.
Andre "Don't take life too seriously. You're not getting out of it alive, anyway."
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.
Thank you for saying it. I've been out of a job for over a year and one of the reasons for this is because firing someone because they are not productive has somehow become not P.C. I knew so many people at my last job that couldn't code for shit, would continuously miss deadlines, show up late and were impossible to work with yet my manager refused to fire them.
One excuse I've heard is that if you don't have enough evidence that someone is not being productive and you fire them, they can sue you (WTF, I highly doubt that). Or sometimes I got the feeling that my manager didn't want to admit he made a mistake by hiring the person. Whatever the reason is, it seems like the only time people get fired is when upper management dumbasses run the company into the ground. Anyone else experience this?
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.
There are some pitfalls to this. Some people are willing to say almost anything to make thier life more easy at this point in time. Frequently make them prove what they are saying is true. One project I worked on at a previous company had a weekly meetly one how thing were going. It was a real simple two month web project. The site needed some additional dynamic content. The junior programmer assigned to this had just his hand held on an almost identical project. So, we figured he could do this one. Every week he would tell us things were going well, but the project manager never said "Show it to me". We were to deliver the final product for review to the client one a Monday morning. We need the clients check latter that week to make pay role. The project manager and my boss came up to me on the Thursday afternoon before delivery. They explained to me the financial then tried to explain how they didn't have anything working. The other programmer had made a couple a static pages and the pulled out the excuse that he thought the client wanted a mock up not a actual working product (which was complete BS IMHO). I had the project to testing with about 20 hours of my work and to the client on time. The managers make three big mistakes here. One, the took this individuals word as the truth (never make him prove he had done what he said). Second, they had someone else bail him out. And finally, they didn't learn from what happened. A month latter I was doing in a day what people though he was working on for a month.
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
1. Get yourself an Engineering notebook (with grids).
2. Every Monday have a meeting at 10:00am.
3. Randomly start with someone.
4. Put the date and their name at the top of the page.
5. Ask them what they did the previous week.
5a. Write everything down on a separate line.
5b. Mark the line with a "<" to represent last week's doings.
6. Draw a line at the end of what they say they did.
7. Now ask them what they are GOING to do this week.
7a. Write everything down on a separate line.
7b. Mark the line with a ">" to represent what they are GOING to do.
Use at least one page per person. Write only on the FRONT of the paper. Don't cram it all together.
When you meet again next week, start over. Only this time, flip back and forth between what they are saying they have done the past week and what they said they would do. If they leave anything out - don't point fingers. Do NOT say "YOU SAID YOU WOULD DO THIS!" or anything like that. Instead, say "Last week you said you would get X done. Did you manage to do so?" In other words - something non-accusatory. If they did NOT get X done just note in the "<" area they did not but then just ask them if they will be able to get to it this week. If they say yes OR no do not critize them - just enter their answer into your book in the ">" area and go on.
Do tell everyone that the ledger book you are entering everything in is what you are going to use to create your weekly report for upper management.
It is important to NOT argue with anyone about your doing this. You are not there to demand that they cooperate. BUT! Do tell them that if they do not want to participate that that will go into the report also.
This works. This is simple to do. The peer pressure of having to sit in front of a bunch of your friends and say you haven't done anything is enough to get even the toughest slacker to start doing something. Further, so long as you make everyone talk about what they are doing it is impossible for duplication of effort to happen. Since, by the end of the meeting, everyone knows what everyone else is working on these types of problems come out immediately. Also, if someone is holding up everything you have the perfect time to gently let someone know that if they can not complete the work that you will have to assign it to someone else. It also is the perfect time to reward someone for doing something right. Like completing all of the tasks they said they would do the previous week.
You also wind up with your weekly/monthly/whatever report and when it comes time to hand out raises you can base it on facts and not just what happened within the last thirty days. Which is a much better way to hand out raises than just "Oh - I like B so he gets a 10% raise but S, well, she's nice and all - but she should only get a 3% raise." Instead, you will know that B actually only got one out of ten projects done while S did 90% of her projects.
Using the ledger also allows you to note, on the back of the pages, when something happens. Like a fight between A&B. You can note on the back of BOTH A&B's pages that they had a fight and why. So you don't forget that either. Or that A comes in late three of the five days for that week. Or that they called in sick four of the five days last week but did not have a doctor's excuse. Then you can say, without a doubt, "The reason you only got a 2% pay raise was that not only did you not finish your work on time but you are coming in late a lot, calling in sick almost every week, and you are costing the business time and money." Or in other words - you have an actual basis for saying what you say.
I have used this system several times and let me tell you - it works like a dream. I had someone say, to my face, "I will not do this" and "I do not have to do this." I agreed with them. I said, "You are right. You do not have to do this. Let me just write that down in my report. 'You do not want to tell me what you did last week and left the meeting.'" They never made it out of the room. They were smart enough to realize that they were acting like an idiot in front of a bunch of witnesses. They came back and sat down and asked if they could change their entry. I just shrugged and said "Sure" and we took it from there.
There is no need to fight. Just let peer pressure and people's normal need to do the right thing lead you along. Everything else will just fall right into place.
Hope this helps!
PS: If you really want to make your employees very happy - figure out how to spend some money on them at the end of the month. Pro-rate it depending upon how much they get done and how many employees there are. After all, you can't spend a fortune just to show your gratitude that they did their work. But maybe put their picture up on the wall as employee of the month? Reward everyone with a bag of pretzels and soft drinks? Maybe a bowl of fruit? Put a list up of the top performers? But if you do the last - do not fall into the trap of using the list against those who do not always come out on top. That is a good way to lose employees. Also, if someone consistently comes in first/highest/whatever - then you will have to do something like make a golden list and a silver list. (ie: Break things up so those who do not do quite as well have a chance to succeed and become better employees.)