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."
Block "http://www.slashdot.org" at the firewall :)
-JT
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.
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.
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.
I know from personal experience that this is a good motivator.
(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
See www.pairprogramming.com . If you haven't tried it (and many people haven't) your reaction will be "that would never work, and I'd hate doing it." The truth is that it works very, very well, and people like it when they try it.
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.
As I said, if you haven't tried it, you're almost certainly going to think it's a bad idea; turns out it's not. Anyone tempted to follow up with "that would never work, PP sucks" please go off and try it for a week, first.
Cantankerous old coot since 1957.
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.
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.
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
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.
"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). "
Allow me to introduce you to the term "At Will" employment. That means that one is employed at the will of the employer. If the employer loses the wiil to employ someone, they can be let go with no reason whatsoever.
HOWEVER...
Thia only applies if one is male, white, under 40, has no disabilities that fall under the scope of the ADA, and (in some states) straight. If you are not one of these, you fall into a "protected class" and, although one can still be fired, the employer needs to document it REALLY well.
"As God is my witness, I thought turkeys could fly." A. Carlson
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.
Have a coding contest...
1st place is a new Cadillac
2nd place is a set of steak knives
3rd place is "you're fired"...
It's worked before...
q:]
MadCow.
I used to have a sig, but I set it free and it never came back.
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.
Block "http://www.slashdot.org" at the firewall :)
Personally, I just complain about my co-workers on the front page of Slashdot... they all get pissed and quit, and then I can replace them with new people who know what they're doing. Seems to work....
Sometimes the best solution to morale problems is just to fire all the unhappy people.
I certenly feel your pain, I am currently the driving force in a 60,000+ code project. We (three of us) have speent a year on this project, and as of today, I have written 52,000 lines of code... and debugged all of it.
:) it is a brutal tactic, but so is the business...
Now, I am the project lead, which means that the 5 month late period falls directly on MY head. Looking back on my mistakes, I have enough information to fill one of those "What NOT to do" management books that you have on your shelf... but here is what I have learned...
1) Make short, small, and precice yet reachable goals which every team member of your team must meet. If they cannot meet these deadlines, make it known that their job is on the line if they dont have a damn good reason.
2) Make it a habbit of looking over sholders. NEVER trust that the self touted code guru has what it takes... look at their code ever few hundred lines, or every few days.... it dosent take long to glance at code to know if its good or if its crap.
3) In large groups, impliment a peer review type system. Every week, pick one guy, and pass arround a few hundred line of his code. Pick the code randomly, and you might not want to tell the group whos code it is, there will be no anger direction that way... I found that helps. If the group can follow it, (they dont have to know exactaly what it does, just follow it), then ok... but out of a group of 5, there will be one that gets it just right, 2 that thinks its ok, and 3 that thinks it needs work. Have everyone present constructive criticizem of the code format, codeing methods, commenting, and structure to the group as a whole. The whole group will learn from it, and so will the author.
4) HAVE WELL DEFINED AND DOCUMENTED CODE STRUCTURE PRACTICES!!!! I cant type that in caps enough... if everyones code looks the same, and acts the same, then if you DO have to kick one of them off the team, anyone can pick it up and run with it.
5) If you choose to pick up all the work, then people will let you do it all... the trick is to EXPECT them to do the work! Make them accountable for missing a major deadline.
6) If payment for this project is dependant on meeting deadlines to the client, then make payment to the developer dependant on meeting project deadlines. You have no clue how hard people will work when rent is on the line.
7) Just remember that your not 'Uber Coder... no matter how good you are, your not going to carry the whole project yourself and get it in on time. But if you can make your coders accountable for their own work to the whole group... then you just might make a better group.
Thats my humble advice, now... as for my saveing grace... I have had to carry my project because I learned these lessions the hard way... but the client is pleased with my work, and now, I know.
Pre-Sig : My spelling sucks because Microsoft hasnt implimented a spell checker into IE.
The Code Ninja is swift with his tool, precise in his delivery, and deadly accurate in his execution.
I agree with some of your points, but I completely disagree with this one. From my POV, people have to be motivated somehow. Usually (or at least usually for me) it's because people have professional pride, somehow they feel what they do is important and/or interesting. Hopefully both.
If they go to Slashdot instead of getting something done, it's not because they can go to Slashdot (or if that really is the problem, they are weak spineless losers who should be fired right away). It's because they prefer that over working. Preventing them access there won't boost motivation or morale. You'll just be plucking small holes in the dam, to no end. On the other hand, if they do deliver and then browse weird web sites, who cares?
Programmers are not factory workers. They don't avoid doing job they like. But if they don't like their job (whatever the reason is -- from jerk boss to boring assignments to incompetent coworkers), they may well do something else. But this something else is usually "anything else", not just specific things you need to block.
In short, motivation is the key. Motivation, skills and experience -- threats can only gain minor temporary motivation ("I can't afford to lose this shitty job"), and never improve their skills (nor constitute useful experience).
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
.... this motivational speaker for developers:
ballmer
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