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
Beer. Lots of beer.
The Blaster Master Fighting for Truth, Justice, and Evil Pie since 1979
I've never had to deal with this. Not once! Ummmm....
Extreme Programming works! www.extremeprogramming.org
Kinda sucks to be in that situation, you can't really make people even mediocre programmers in a short period of time, just come from experience.
In this job climate, it shouldn't be all that hard.
Code or you're fired!
Money works wonders. Or, at least the promise of money.
I'm happy to let you, oh superior being.
You want some help? Then we need to agree on some API's and a schedule.
If your idea of a project is to just free associate and then get grumpy cause nobody else shares your 'vision' then you might as well right the whole thing and STFU.
Otherwise, do some engineering and some planning which involves the rest of your 'team'.
de-facto : another word for "scapegoat".
guess who management is going to fire first ?
yup. start handing out your resume. NOW. DO IT.
hire me. i can code like a demon and i can understand the domain space.
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.
Easy - if they are doing nothing - get them fired.
It's your ass or theirs in this economy.
It is lazy-assed slackers like your workmates that caused this recession in the first place.
Programmers already have a bad name in corporations and you are contributing to the problem by doing nothing about it.
If you're doing 90% of the work, you better be getting 90% of the wages and/or profits. 90% is close to 100%, do it all yourself, and take the credit. Just keep in mind blame comes with that too if something goes wrong
In college, really poor, need a flatscreen.
Have them replaced.
There are other developers out there. Some of them actually produce code.
Fire they asses!
Get somebody in there with the fire to make
things happen!
Damn!
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.
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
Pick up the biggest wooden staff-like object that you can find, then threaten to bean them with it if they do not produce.
Sure your'e not serious, but they don't know that.
Give them the boot..... and get new guys.. yeah new guys from school :) Teach them not to suck they will ask, they are right outta school. You have to make them feel part of the team.
Try to AC post at slashcode. The slashdork crew disabled it because the lameness filter doesn't work.
Try to AC postWhen 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.
From the article:
Hiring new people this late in the project won't work, as anyone who has read 'The Mythical Man Month' knows.
I don't blame you as much as the moderators, though.
Let them know someone will get laid-off, and it's basically up to them to decide who. There's people outside lined up for their jobs, I hope they know.
M@
Krispy Cream is people
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.
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.
Well every Friday have a lunch meeting. Make sure
no one is spinning there wheels and that they
have the resources they need. Set daily/weekly
goals for them. If they don't turn out code in a
couple of weeks, let them go because they don't
know what they are doing.
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.
As far as experience goes: Perhaps have less experienced people sit with you while you code, sort of like peer programming but it will be more of a learning experience for them. Encourage them to ask as many questions as possible durring that time. I think this may slow you down a bit for a while but in the end you will have more experienced developers.
Fire their sorry asses, then ask for a raise. Then fire the incompetent bozo who hired them.
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.
The key to victory is human relationships.
As a team leader you will be working for two men: one is usual programmer and another one is manager. You HAVE to plan your work, define stages, checkpoints, deadlines and so on. You have continuously control (read: help and fix their bugs) your other coders.
And yes, you NEED shared idea, mission: psychological motivations are the best ones.
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!
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 don't think it's easy for them to "just come my and bloody ask questions" if your opinion of them is "suck" (from the "make them suck less" part). i mean... if you want the less experienced developers to feel comfortable asking questions and actually *care* about what you care about, then you'd better damn well care about them too instead of acting like (i am not accusing you of, but you may want to check if you are) an elitist who think they are just dumb ass drones.
now -- i would say first is to set intermediate goals (divide project into smaller portions) and get daily updates. spend 15 min every day and see if they ran into any trouble with today's work, etc etc. this way deadline is always 8 hours away, and there won't be any CS-101 "i will wait till the night before the project is due" symptoms
two -- get together with them and do some stuff -- be *friends* and THEN work-partners. an activity that requires no social interaction and gets a lot of bonding is 1) drinking. 2) drinking at a strip club. or golfing or whatever. when you guys are buddies, 1) they will feel at ease about seeking your help, and 2) they would hopefully get your vibe on the urgency of things. sidenote: be friendly but draw the line if people start to take advantage of this relationship
3) plan for the worst and be prepared for extreme measures. "kill a chicken to demonstrate to the monkeys" is a badly translated old chinese proverb. if it's necessary, fire somebody and be prepared to take up the slack. if everything else fails this should get people into a more productive mode.
well... that pretty much covers everything from holistic to draconian... so...
My life in the land of the rising sun.
I have written a an RFC on this very subject. It is definitely one of great concern. The RFC is called RFC1OUCH. Basically the idea behind this RFC is that motivation is required for a person to work/learn/produce. My choice method of motivation is digit removal. Now by digit removal I am not reffering to taking numbers off their pay, but rather removing thier digits. I would first recommend getting what I call a "chopping block." This will serve two purposes. The first is to provide a flat area in which digit removal can occur, and the second is to provide a bloody reminder of why it is easier to type with 10 fingers rather than 9 or 0. Several people have raised concerns saying stupid things like "Well if you cut off their bloody fingers how are they going to type and produce code faster with less fingers?" But you said you have a team of four? Correct? What you will find is in the end you should end up with somewhere around 1 coder with 0 fingers, 2 coders with 1 finger, and one really f****** coder with extremely good motivation. In most cases this is always a more ideal senario then the alternative. One suggestion is to make an example right away without warning. The best way is to tell everyone to gathering around the ol chopping block, and tell them you are going to show them a magic trick. The convince someone that it's alright to put thier finger on the block, that it's just an illusion. When he screams in shock and so does everyone else, then you can tell them "now get to work." I hope this helps you. By the way I do offer consultation services in this area. I have my own chopping block that I would be glad to bring to your site as well as an assortment of digit removal tools. I have a demonstration I can provide to your company with proper notice and consent forms. Oh and also I need a volunteer. Ssmoimo
It has been my experience - either you can code, or you cant. Ive met people that have been in this business for tens of years and they still cant code worth shit. Same at Uni, some could, others just did not get it.
If these guys arnt newbees, then I suggest you do it yourself. Everything else is futile.
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.
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.
You should stop coding and force them to get their hands dirty. Do code review with each of them on a daily basis - use that to teach them how to write good code.
You should also set task deadlines and adopt a "no surprises" approach -- it's ok to change a deadline, but to do so they need to give you advanced warning of the obstacle and ask you for help up front. You should set the deadline based on how long you think it *should* take. Give them lots of feedback on how they are doing, which means not putting up with any crap. Challenge them.
Communicate to your boss that the others are struggling and that you are going to have to spend serious time mentoring. Managing up is very important, so spend a lot of time communicating to your boss on the tasks and progress of the others.
If you've got to integration and discover that some people haven't produced what it said on the plan they were going to produce you have already screwed up. That is not how to do project management.
How to do project management is covered in many textbooks, but they'll all tell you to monitor what is going on, so you don't have a surprise on delivery date to discover that nothing has been produced, and take corrective action when you discover a problem.
In a competently managed project you simply can't arrive at the position you describe. Sure, you can get useless programmers, but you should have discovered this and dumped them months ago. (Or, if you personally don't have the power to dump them, you could have screamed enough at higher management that you don't even need to say "told you so".)
Well, I can't relly call it my method, but here's a visual description.
-- The unsig...
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.
Fire them. Do the work yourself and then work to hire people who you've interviewed and seen their coding ability. I'll assume these people weren't hired with your input.
Suck it up for now, and make sure you aren't stuck with them on the next project. Get friendly with your managers so you can pick your next project.
love is just extroverted narcissism
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.
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.
Open source is for weenies. Using the word "project" to describe software makes you sound amateurish.
If each person in your group is going to be evaluated on the work they are responsible for, then make sure you you get the work you are responsible for completely done before you start helping others. Otherwise, when the project fails and nobody has their work done (including you) you'll look just as bad as the rest.
The laser to motivate your developers.
=== 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..."
On one hand, you could do the whole project yourself and then get a pat on the back. But 99 times out of 100, the slackers will be told how good you are, all you get is a pat on the back, and no reprimands for those who do not work.
On the other hand you could go to your boss and say "Boss I'm doing all the work, this project will NOT get done unless those helping me pull their weight. Without help this project is going in the toilet." Then you have your ass covered because you have a lot of work to show, and then the other coders begin to code and do the work. In the beginning you get praised, but then the lazy coders turn out crap code, the entire group gets blamed, your contribution is diminished, and the project fails anyway because they can't turn out quality code.
In either situation, you get frustrated, angry, and head to Monster.com to search for a new job where the managers know how to higher decent working coders.
"All great wisdom is contained in .signature files"
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.
First, assess peoples skill and motivation levels. Senior, well-motivated people can be checked on every month or so. Less competent or motivated people may need to be checked on every day.
Give people as much respect as they deserve, but no more. If some people don't do a very good job, make sure that you have frequent code reviews. If they are unwilling to accept criticism from the more experienced people and do the job right, don't be afraid to yell. With an ideal team, motivation is not a problem. With problem cases, don't let it slide. Don't be afraid to point out to them that there are hundreds of more qualifed unemployed software people who would be happy to have their jobs.
Make sure that you have a good process in place. I don't mean anything bureaucratic, but make sure that you do design reviews and code reviews. Make them write something up. Get a definition of the api for the module. Review all code that is written. Require that a test plan, and possibly test code is developed. By implenting a system of reviews, mentoring can be done, and teamwork developed.
As the administrator of the Mac GPG Project (http://macgpg.sf.net/), I've found that the person who usually needs the most help is me. :-)
;-)
I'm a good coder, but because I spend my time managing the project, I don't always have the time to research on how to fix every oddity that shows up in my code. I often post to my developer's list saying "hey, there's this weird bug in my code; someone please take a look at it" and, usually, I get some much needed help that probably would have caused me to bang my head against the wall for a long time with no results. This is what's great about having a team; things that would have stopped development when you were on your own are easilly fixed by someone whose experience is different than yours.
As for motivation, you usually have to find motivated coders. For example, when low level stuff needs fixing in GnuPG to work on the Mac, the worms come out of the wood work and I'm given patches for all sorts of things while I'm still trying to get GnuPG just to make. Also, most of our code comes from just two or three developers, but on several occasions someone came along and said "hey, I'm working on project XYZ and we could use your library if it had these bug fixes. Mind if I do them for you?".
The trick seems to build up a community and then that community will come to help. I don't really know how to build the community, since my community found me, especially after NAI officially EOL'd PGP, but also because we're the only game in town and encourage the work of others who are not part of the project to provide software for users of specific MUAs.
At any rate, for the story's submitters situation, I'd recommend helping these developers along. The best thing to do is tell them to ask any questions they might have, no matter how basic they might be, on your developers list and then answer them, even if they can be found elsewhere in common sources (or at the least point to those sources). Once you get a few good developers, then you can go back to being less tolerant of incapable programmers.
-- Gordon Worley
You don't say much about the culture of the place you're working--maybe projects are expected to take 6 months, and you're screwing things up by moving in real time? If so, there's not much you do about it unless you're prepared to do all the work yourself.
If you think there really is opportunity to effect change in people's coding practices, try to gently lead people in the right direction:
Have a code review--of *your* code. Be sure to accept a few suggestions even if they're a bit suboptimal. Reviewers will be exposed to better coding practices, and will be less hostile to suggestions about their own code.
Team up developers. I'm not talking about XP here, but how on earth did six weeks go by without you noticing a lack of code? Create two 2-person teams, pairing a code-skills person with a domain-skills person. On your team, spend more time exploring the domain space, and set small goals daily or at least 2 or 3 times a week. It's not micromanagement, its setting the tone for how to work. If you don't have a 2nd code-skills person, maybe you need a personnel change.
Managing isn't as much fun, but that's why you get the big bucks (right?)
Remain calm! All is well!
I think you have your own set of personal problems when you can't even see that you have duplicated entire sentences in different paragraphs within your post to /. Quite funny.
"During times of universal deceit, telling the truth becomes a revolutionary act." - George Orwell, 1984
If you're in a position to get rid of them, fire them. They didn't do any work, they don't deserve to be there. Call me a bastard, but it's simple 'employment darwinism'.
If you're not in a position to get rid of them, leave (or threaten to leave) your organization. There is another company out there that will compensate you for your hard work. If there is something you can't put on your resume, it's "almost did big project X, but fell through because of idiots in my group".
Your professional career shouldn't suffer because of poor hiring.
Are you the boss? Is there a supervisor above you? Someone you report to for all these deadlines and such? Why not go have a talk with them? You can't let work attitudes like this get entrenched, or else you'll be doing everything just to keep the place going, while everyone else plays quake. I know this, it happened to me. Management was too "afraid" to let go the slackers (read: children of management in some cases) and so I couldn't even correct it.
At this point, give them two weeks' notice. If they get their part of the project done in the two weeks, they can keep working there. If they continue to slack off, they're gone. Either way, you'll be rid of them in two weeks since none of them will want to stay.
"I'm going to set the building on fire."
If you feel you are the strongest programmer let them pick stuff they want to do (usually they will pick what they know how to do). Then if they need to be doing more work give them something you can explain without getting upset at them. Because they will most likely ask questions. And most importantly as many people have said be nice to them. Not just don't be mean. Don't be condesending or act incrediulous when they don't get something. Remember we all started out knowing nothing.
It's amazing how spiritual an elaborated beer commercial can be. -- Philip K. Dick
It sounds like you're doing your job.
As long as your bosses know that delays aren't your fault, then you can try to motivate them. The truth is, if they aren't doing their work probably nothing you can say or do will change that.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
Is this not why managers exist? They should be dividing tasks and setting dead lines for each of developer.
Come now, you really didn't think the typical manager spent the entire day struggling to create the perfect powerpoint presentation or flooding eachother with scathing emails now did you?
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.
One thing I've noticed is that when people have been on a project (and usually producing) for a while, they begin to suffer from burnout, especially if you've gone through several change orders, or other modificaitons that manage to require a fair amount of redesign.
Switch people around a bit. If you give them something new, sometimes it offers a breath of fresh air. Of course, if they've never been producing in the first place, then you're still screwed.
If it's really an issue of the work just isn't getting done, talking to your superiors, and several layoffs or threats are probably in order. You could also have a meeting saying, "if this isn't done on time, we're looking at outsourcing the work and laying people off." Even if it isn't true, it will make people understand that dicking around has consequences.
- Sighuh?
In the past, I was tech-director for a big company, assigned to a videogame being developed at an external dev. house. There were eight programmers, maybe one or two of them worth a damn, but the others, including THEIR internal tech lead, continuously f-ed the project.
When I was brought in to the project, I evaluated the developer, and my conclusion was either a) cancel the project, b) change developers, or c) bring it "in-house" for me to finish.
Well, the mother company voted for d) do nothing, except assign me to supervise the impending train wreck.
A year and several million later, the mother company finally saw the light and yanked the project, to be finished in-house.
Guess who finished (read: re-wrote) the game code, and suffered great agony from the spaghetti mess induced by over a year of the random neuron firings of idiots?
The moral of the story is: make the hard decisions NOW. If your so-called programmers currenly have no code, no amount of cajoling (or beer) will make them produce code later. Programmers program. Slackers slack.
It isn't a memory leak. It's an object life-span issue.
My experience is that this is a matter of project management. Someone has to be recognized and empowered by management to do the following essential tasks:
1)understand the skills of each team member
2)break up and assign the project according to skill sets and get people the mentoring they need.
3)understand dependancies
4)build in accountability and enforce it
5)Manage the cycle of development
You could always replace them with better people... Me, for example. Sure, I may not be the world's best C programmer (though I'm not bad), I atleast have enough common sense not to sit on my ass and do nothing in a job I would be lucky to have in this crappy job market.
I thought that maybe cheerleaders would provide the necessary motivation to get my coworkers coding. Unfortunately the boss didn't see how they would help. I'm not really sure either, but it certainly couldn't hurt.
What I'd do is call these guys and maybe get some of these lasers.
Hope this helps.
I have given this lots of thought. Here is what I would do in that situation. First off require all code checked into the version control every Wednesday evening. Then write a script which checks out the code and compiles the number of lines of code for each developer. Then send with your weekly status reports the number of lines of code developed that week for each developer. You would also note if they did other tasks, like documentation for that week.
A good lead developer keeps on top of their team. Review your team's work at least weekly, visit them for a quick chat once or twice a day, offer help/advice at every opportunity, and keep in close communication with the Project Manager/business end of things. The sad truth of the matter is that 20-50% of your time is going to be spent taking care of your team; get used to spending entire days without writing a single line of code on your own. If your developers are under-developed, you're doubly responsible for guiding them as best you can from the very beginning, or pressuring the PM to get them training at earliest convenience (and, in any case, keeping PM informed of the fact that the developers are really lagging and that the project is going to have trouble hitting deadline.)
As for the predicament you're in now, there's not much you can do besides busting your balls to help the developers (yeah, it'd be nice if they came to you, but it's the lead developer's job to go to them,) and talk to the PM about damage control. Look at what has happened, learn from what you can, and make sure not to repeat it on the next job.
Note to editors: Yeesh. This passed as front-page? This is barely readable, much less first-draft quality. Sure, it's an important issue and well worth posting, but at least clean the danged thing up, or send it back to the submitter to do so!
Obliteracy: Words with explosions
But back then our peer reviews went to our instructor.
What I found as both a project lead and just a team member is that status checks, often, are good motivators. Nothing's more motivating than someone watching over you. Now I'm not saying hover all day, you have to work too, and no one likes that.
You've designed all your components, and broken them up, and handed out pieces to everyone. You have to go back and see how it has progressed, just ask a few questions, ask to see a demo. This isnt a code merge, it's just a status demo, do it 2 times a week, 2 times a month, however often you feel you need to just to make sure that everyone else is progressing at a proper rate.
At the same time, if your coders arent asking you questions, ask them questions, make sure they know whats in your head and vice-versa.
If people aren't asking questions, they don't understand it enough.
sounds like your project belongs on sourceforge!
Do you even lift?
These aren't the 'roids you're looking for.
First, find out from them what the problem is. Do they actually know how to code? If not, you might ask (management) why they were put on the project. Do they really understand the items they are trying to address? Are they overwhelmed with the amount of deliverables they are responsible for? Is this their first project?
Second, notify your management AND the project leader/sponser. The sooner they know about possible delay issues the easier it is to figure out how to correct the situation.
This is a hard question to answer. Is it motivation they need, or do they just not know what to do? If you are responsible for their contributions, you might be wary of contacting management before finding out what all of the issues are. If you aren't, then a mangement update is in order.
There are probably two reasons for their lack of completed work. 1) They are not doing their jobs, or 2) they do not know how to do their jobs (ie they do not understand how to work on a project, or they are not technically qualified. Either way, they should be removed to do something they are capable of doing).
Good luck.
I don't advocate micro-management, as that is normally counter-productive. However, have you had them break their projects down in to small parts and attempt to provide time estimates (best/worst cases)? If everything is clearly designed, then this should be relatively easy, although dependent on experience levels. By breaking down their tasks, it's possible to identify potential problem areas that might need extra time for prototyping, etc. Also, having a list of small tasks makes the project seem less large and daunting, and allows for a feeling of accomplishment throughout the course of the project. Finally, weekly status meetings allow people to report what tasks they've acomplished, and for you to keep a handle on the project schedule. They also provide a good opportunity to code review if anything on that front has been accomplished.
The one that worked for me in small groups was an antagonistic anarchistic model, better code produced through taunting and humiliation. If you give your partners a hard time and tell them their code sucks, they will ether make better code or move out of the way.
-- Phase 1: Collect under pants Phase 2: ? Phase 3: Profit
I have just been in a situation such as this. First of if you like me don't have the authority to fire or even rain anger on someone for not doing their job, then go to your superior. If he doesn't help you (like mine didn't), then there is very little else to do. I tried the calm way to offer every support I could, talking, teaching, helping with code, taking over most of their tasks. And all it did was burn me out faster than a candle burning on both ends. Keep in mind this was a huge project (very large HR and education system for banks from scratch) so my experiences would differ from yours, but I have learned stuff:
- Some programmers will do anything to shift blame from themselves to others including down right dirty manipulation and backtalk.
-You can't teach someone proper techniques within a project, you need seminars, strict and ENFORCED guidelines for everything from design, to even the naming and structure of your code or the fast and loose (or is it loser) programmers will trample all over the system leaving unmaintainable crud all over the place.
-No amount of extra help with out the preparation of the rest of the team will help and the "oldtimers" on the team are very hard to get to help the newtimers.
-There should always be two leaders. One closer to management and the customers who handles Administrative tasks and One technical benevolent dictator (that was what I became to get everything done in time). And they should both have executive decision power over the team.
-Don't ever expect to meet early time estimates. Only the updated ones made after full understanding of the domain problem sets in can be used, so if you're consultants on a preestimated cost contract and the project runs late then you're shit out of luck.
As for my tips to you now is. First of all:
Blow the whistle on your teammates not pitching in. Not to admonish them, but you all have a goal as a whole so you should sit down and find out why the others aren't making it in time or getting things done like you are.
Don't measure people by yourself, you will always either over or underestimate them.
A person is smart, people are deeply stupid
You might want to give pair-programming a try. Although it certainly doesn't feel natural at first, with a little practice, it's possible to use this to spread knowledge and maximize code efficiency across the code base.
If you are the most experienced developer, it gives the other developers a chance to see how you begin solving problems, and a chance to see your code as it emerges. It's important however, that you don't do 100% of the coding in your pair. Spend approximately half the time letting your partner code. This provides an opportunity for them to generate code, and gain some confidence in their abilities.
After a period of time, you should mix up the pairs, so everyone has a chance to work with everyone else.
As I said, this method of working feels extremely counter-intuitive at first, but with a bit of practice can really make a difference (especially on teams with widely disparate skill levels.)
As an added bonus, developers are less inclined to slack when they've got someone working with them, meaning you'll tend to get more productive hours out of each developer/day.
Check out this link for more descriptive info, and some discussion.
I think this falls under the somewhat bastard-ish things to do, but I think it does actually motivate. If you write a little script to post CVS statistics (Assuming you use CVS, or another management system.) to the intranet site (or some other highly visible location) and make sure everyone can see who is doing what that needs to, generally people will perform better. If no one is looking over their shoulder, people tend to slack off (*checks over his shoulder*, good, lets continue).
Another way to do it is use a project tracking tool that has percentage completed goals in a nice display. IPM does this (Search Freshmeat for it) in a nice easy to see display. Shows a little graph of percent done per project and it allows multiple users.
Show them you are waiting for them. If 1 or 2 people are waiting for 3 more, the 3 should start feeling awkward. That and you have a conclusive tool to show the boss man that the rest of your team sucks. You can also post little notes, "Stuck? Ask someone for help." and such.
I got stuck with a developer who couldn't write one javascript function in 2 weeks. It was absurd, the boss didn't fire her because they both came from the same town in India and enjoyed to talk about life back home. We just cut her out of the loop. She received no projects. When my boss would ask me, I'd tell him she couldn't finish and to prove it would give her some minute task that wasn't important and after a couple weeks wouldn't have it finished. No biggie, don't rely and you don't get disappointed.
Dacels Jewelers can't be trusted.
Have each team member send out weekly status reports before noon on friday to all the team members and also the group manager if it's someone else. That way each person has a good idea how much everyone is doing and it motivates people to do their jobs so they actually have something to report each week.
Also, make an actual schedule using some program, like MS project or whatever. Assign people specific parts with deadlines. It may feel like the freedom that you are used to as a software engineer/code monkey is being taken away but it really helps you meet your final deadline and if it's documented it pushes people to actually work.
-Flamesplash
"Not knowing when the dawn will come, I open every door." - Emily Dickinson
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.
I'm in the same spot. I was the sole developer for a big Perl app for a year. Then we started hiring on programmers to ease the burdon off of me. In the beginning it's really rough. They're almost useless for a month or two while they "learn the ropes." (We all telecommute 100% so that's more difficult than you may think)
I've had some really good guys (ok, one) who learned the ropes really quickly and they're now my right hand. I've been through 5 other programmers trying to find my left hand but haven't had much luck.
I will say this though, unlike the problem you're facing I've never had anyone who can't program from a spec. However finding a programmer who can CONTRIBUTE to the spec is a whole different animal.
I think a big part of it is asking for help. A lot of programmers don't. They'll sit there and read through 100,000 lines of code when a 5 minute phone call was all they really needed. And they'll even gripe about doing it when it's their own fault to begin with.
Now, training too isn't a cut and dry process. I've got two programmers at OSCON right now. One is LOVING it. The other has found only two classes to be of any value. OTOH, he will completely devour a thick book and walk away a master of the subject. Some people learn differently, you just have to find their sweet spot.
Honestly though, and I know it doesn't apply to your situation, I'd get rid of them and find others. A good programmer (the only kind you want working for you right?) will not have these problems. They will tell you how they'd prefer to learn. And most importantly, they can write good code from a spec.
anyone who has done lots of team work has encountered this before. my approach (it has been successful since college) is to let my boss know of the situation, and have him reward me for extra help that i give to his employees. be a good guy, but if you aren't getting rewarded, you're a good dumb guy. if your boss doesn't play ball, start looking for one that does.
Jump in front of them and start screaming:
E LO PERS!DEVELOPERS!DEVELOPERS!DEVELOPERS!
DEVELOPERS! DEVELOPERSDEVELOPERSDEVELOPERS!
DEVELOPERS!DEVELOPERS!DEVELOPERS!DEVELOPERS!DEV
-
Lameness filter encountered. Post aborted!
Reason: Don't use so many caps. It's like YELLING.
(what slashdot says in all my posts)
That's easy. Fire them, hire me. I can do just as little as the next PFY, AND in half the time!
This is my sig. Its pathetic.
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.
Here's a good thing for you to do:
1) Dont tell the other guys anything about
your doubts about their code.
2) Write down good design. (keep it yourself)
3) start giving small tips. One tip a week.
Something so small that makes the other
people think they invented the solution.
4) Make sure everyone has someone else that needs
to use their code.
5) Make sure everyone relies on someone elses
code to do their work.
6) Make sure you (or anyone else) never
hide problems.
7) Write "document templates" that can
be copy/pasted to get good code.
8) Write enough good "examples" and make sure
people can copy/paste them.
9) Write working example code.
10) Make sure everyone has database of examples
and code on their hard disk for copy/paste.
11) Write interfaces; make sure you have plenty
of code _using_ the interface. Let
someone else implement it.
12) Write test cases and a script that finds out
whether a test case passes or not.
13) Publish results of test cases every week;
with people's names attached to the list
of "fail"'s. Use colour coding for pass/fail.
14) Make sure people understand they are
responsible not only for their own code,
but everyone elses too.
15) Make sure people think the quality
requirements are very strict.
16) Make sure people thinks the end result will
be the best software on earth.
I can't believe that no one has brought up Extreme Programming yet!
Many have mentioned pair programming, which will definitely help. But beyond that the prioitize, estimate, produce, analyze, repeat cycle will surely help as well.
When you miss your deadline you will have a. done all you can do and b. something that has 100% functionality on the top x% of features instead of something that has 100% of the features x% of the way to working.
Good luck.
"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." This is probably the most common problem anyone faces in development projects as they move up the food chain. I hate to say it, but you set yourself up for this by putting yourself in a leading position, but letting yourself get sucked into the technology and ignoring the coding progress of the rest of the team. Unfortunately, for many people inertia is a state of mind and unless someone is looking over their shoulder stuff just doesn't get done. Without someone acting as the control and center, it looks like the rest of the team spent their time reading slashdot... Personally, I think in this case you will just have to suck it up - and do the work yourself. From a corporate point of view, just make sure that you make it clear that you were the team leader here and responsible for the job getting done (unless it crashes and burns). Notch it up as a learning experience and remember next time that your management part of the task is (here comes some heresy..) MORE important than your programming if the team is larger than three people. The larger your team, the less important your own programming contribution becomes if you are the team leader - especially if your experience is greater than the rest of the team!
I'm surprised no one has mentioned this yet, but if you are working with a group of people and you don't know their abilities, divide the project up. If they don't deliver properly by their deadline, cut their original task in half and assign the other half to someone else (probably yourself), leaving them with less to concentrate on. Then rinse and repeat as necessary.
Don't accept poorly written code just because "it works". If you do, you endanger the project and don't help the poor coders become better. The best way to become a better coder (IMO) is to bang away at one single problem and not worrying about doing "your share" and ending up spreading your effort too thin. When your teammates prove they can handle more coding, give it to them.
If you do it this way, you'll inspire confidence that your co-developer can do the job right. This confidence will, in the long term, be more benificial to the project and to the company you work for.
----- rL
This book gives good reasons and real-world data for things that good software developers find intuitive (e.g. don't create high-pressure artificial deadlines, etc...). A must read for any manager I report to, and any employee that reports to me.
If they just CAN'T do the work for any reason including training, motivation or knowledge, then you need everyone to be clear about what the situation is, and get them kicked out/off of this project; you probably can't do 3 other persons work for them.
There might be ways to reorganise yourselves that might work. For example can they unit/integration test the code you've written, write test specifications etc?
However, I think your project is going to be late... Some projects (more projects than you might expect) can survive being late. Now is the time to start informing any customers you have... better start with the internal customers, e.g. the managers.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"What I've noticed with myself is that if I'm working something I don't really find interesting I tend to just sit and do nothing, then suddenly wake upp do 15mins of coding then again nothing and continue ad infinum.
However if I've got someone to work with at the same computer to talk to about algorithms, different design issues, implementation approaches etc. etc. I produce large amounts of code. Also when working in pairs, it usually isn't possible to just sit and do nothing and you also tend to create less bugs or those trivial stupid mistakes that take you an hour to find later (you know what "WTF are you doing?" comment from your coworker).
One of the best things to do to keep you focused is to do sports. I worked at a software company where we had a ping pong table where we used to play one match every one hour or so. This was extremely good as that little 10min of play made you 100% focused for the remaining 50mins. Working 100% for 8*50mins each day is alot better than working at 50-75% for 8 hours each day. However this company was bought by a large telecom and because they noticed our team of programmers were very productive, they began to move us to different projects to give them a boost. At the same time when our team was broken we lost our good atmosphere and now I probably produce 50% of what I used to just because I'm pretty damn bored. Our new managers want us to sit down and be focused and when I told me what I used to do, they just began to talk about how many hours less we would work then... (ever wondering why at school you have a little break every hour or so?).
After a flood of trolls hit the site, AC posting has been disabled. It looks like this is the best lameness filter they could think of. It will happen here next.
Emebedded system, C and assembly? The other developers can't write code fast enough? If youre company is in Austin, TX, may I suggest that you fire one of them and hire me instead? I can assure you, you won't regret it.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Let me guess. You all have the same finish date. Most managers these days have no concept of dependencies. They give everyone the same end date regardless of the fact that some parts can't be done until other parts are ready. I can't tell you how many times I've received stuff from the DBAs the Thursday before a Friday deadline. But they got their part out on time. If the managers were smart enough to plan a schedule right this wouldn't happen. The holdups should be evident early and can be handled without causing major delays. There should be incremental testing of the project as it is built from the bottom up. That way faulty or missing parts are identified early on, not at integration time. Having a bunch of people out there working on different parts and then trying to integrate at the last minute is a recipie for disaster no matter how much time you spent on the initial design. (design time, wow what a concept).
Reading the question, the point that sticks in my mind is that you admit to having even less project management experience than they have coding experience. Remember that as you think about replacing them with experienced people who know how to do the job they've been assigned. It seems to me that you need to stop doing their jobs and start learning how to do yours, which, like it or not, is being team leader and project manager.
Organization is also key. Read the last half of your second and third paragraphs again and tell me that you sat down and carefully organized your question. It's a careless error, but for someone who is complaining about their coding styles, it indicates a potential double standard.
What impresses me the most is that you seem to understand the solution needs to be found in management and methodologies but you don't discuss what (if any) methodologies you're using (although I'm suspecting waterfall right now).
Don't make them come to you. You're the leader. Be there for them, stay out of their way, and build trust. If you show leadership then they'll come to you. If you show tyranny, disgust, annoyance, or anything else, then they'll be happy to continue not producing anything in a vacumn.
Six weeks into a project with a tight deadline is not releasing code "early and often". In our world, six weeks is two iterations, each with their own deliverables, and a major iteration coming to a close. "Early and often" to many people means multiple code releases with full tests on a daily basis.
Remember, coders are no better than their enviroment. While you may have created an enviroment that works for you, it sounds like, as team leader, you've failed to create an enviroment that works for them. Perhaps it's time to put away 'your' piece of the project and start fixing the real problems.
No Zen is good zen
If you do go, as so many of the /.ers have suggested, and fire the incompetant programmers, make sure you have documented that their incompetance in their employee file. This is to cover your own ass and prove that they really did "suck". If you have no documentation of the incompetence, and they decide to sue, remember, it's your word against theirs that they were derilect in their duties.
DRINK DUFF (responsibly) DRINK DUFF (responsibly) DRINK DUFF
In a word, YES.
Code reviews can be very constructive. And even if they are "vicious" in terms of the minutiae they cover everyone learns. My favorite thing to do is to A) invite my office mate to my inspections- since he doesn't know any ADA he asks a WHOLE lot of questions- very good if you can answer them all, andif you can't, why not?
and now I invite B) the software architect. True he's a busy man but he goes through that code with a fine tooth comb!
In addition, frequent code reviews can also show what good code does look like. Start by reviewing YOUR code (the one that's 50% done). Then they have a model to work from.
Software Engineers don't code from scratch, they copy and modify!
In the future, I would want to not be isolated from my friends in the Space Station.
See if there's someone in your organization who can play the role of project manager: working with all four of you to break down the effort into pieces small enough to measure progress against (my rule of thumb: half a day to two days), who can track progress, who can be told about roadblocks and try to remove them.
... I guess assign busy work to any developer or developers you can't count on, document why you did so, get as much done as you can, and look for a new job. None of which is easy.
"The role of project management" for a four person project is not a full time responsibility! Someone with project management experience ought to be able to do it in 30 to 60 minutes per work day.
Sell it to your management this way. There are three roles: development, technical leadership, and project management. You have time to do two. At this rate, if you do the last two and ignore the first, the project is doomed. The last one is the only one an outsider might possibly help with.
If that doesn't work, then you need to be the project manager. Try really hard to be empowering and helpful. On the other hand, negotiate the following with your boss: "If any of these three is contributing zero or negative progress, I want the power to get him or her out. Transferred to another project, laid off, whatever; but not in my way."
If neither works
Good luck!
Stupid job ads, weird spam, occasional insight at
I've done my fair share of DSP programming. There is a fairly high psycholofical bar when developing code for most DSPs.
First, you have the custom compilers, with their custom interfaces. It can take days for a new programmer just to learn the proper way to organize their files and on-board resources to get a "hello world" equivalent LED-lights flashing program working. Then the implimentation of C may not be completely correct, or severely nonstandard compiler errors start showing up. It isn't easy for a newcomer to just get over that and continue coding like nothing happened. All this is assuming that the documentation is halfway decent.
Next, there's the assembly layer. Oh, the assembly languages. Riddles wrapped inside enigmas, with structural assumptions that make answers seem impossible to give. It's just going to take a while, not to mention a LOT of sample code for a programmer to understand the extremely tight flow of specialty registers, limited instructions, stacks, alignments, and how they mix with the on-board implimentation of C functions and the like.
Then, there's debugging and using the DSP tools. Half the tools I've ever used on various DSP projects have been much flakier than anything you've ever seen from Microsoft. One of the first things that I had to do when getting a new DSP is to just port a set of Standard IO routines over, because so many DSPs would be out-and-out unreliable when transferring data to the PC for debug and the like. I probably spent just as much time ensuring quality communication between the DSP and the PC than I did on any one project - but this is just one of the illustrations of why starting work on a DSP that is new to you can seem such a uncertain, slow process.
I definetly agree, that if these people started at the same point as you did, then they REALLY need to do their homework, bite the bullet, and just make mistakes to get some code down to revise later. In that case though, unless you just want to call them lazy to look better than them, you really should get an O.K. from management, then take some time to teach these people what you've learned. In most projects, I'd agree that these people should at least get half the work out that you did - but on a DSP-oriented project, I'm not at all shocked that one person out of many would be able to *get it* quicker than the others... but now to get some large-scale work done, you really should see what they know, then get everyone up to speed if you can.
Ryan Fenton
Seriously, there should be a team leader or project manager somewhere that has a schedule of when certain things should be done, and these guys are not ready. As it is with all projects, certain people have the task of making sure other people are getting their stuff done and if they aren't then that first group of people are there to assist. On your project the first group wasn't paying attention.
Now, you're not a tattle-tale for going to management and informing them that other people aren't keeping up if it ends up reflecting on you. The newbies should have people keeping tabs on them until they're more experienced; maybe it's an immediate co-worker, maybe it's a project manager.
Just make sure management knows why you don't meet your deadline...
Q-
Anonymous Cowards are at -6...
You're just working too hard to get your own part finished! Go sit next to your collegues, look at the work they're doing, give them a lot of comments and show them every miskate they make. Managing developers is like guiding a child across the street. Hold their hands, look in all directions and help them to move forwards. ;-)
And if this doesn't work? Well... Some spanking might solve the problem too...
In other words, keep an eye on them 24 hours/day, 7 days/week and make sure they make the deadline in time... Remember, as project leader you will be held responsible for their mistakes...
Life isn't fair...
Attach bonuses to major project milestones.
A large chunk of it is repeated twice.
Luckily for you, the Slashdot "editors" applied their excellent language skills to your post and... completely failed to correct the problem.
First and foremost, you're their team leader, act like one. Address the problem. Talk to them and try to understand where the road blocks are. Do they just suck at coding and can you help them get past it? Are they getting distracted by other less important tasks? Or are they just taking up space? If you can't address the problem by yourself or you don't see any improvement after you talk with them, take it to your manager. He/she is paid to deal with these kinds of problems. Communication is the key to solving personnel problems.
Sometimes no matter what you do you can't bring others up to your level. There are just some bad coders out there and until they get more and more experience they wont get better. You can try teaching them about do's and don'ts, but you can't make them do and don't.
If the coders are good then often I have had to resort to pressuring them saying things like I am waiting on 'so and so's code' at a staff meeting. Basically getting manegement to step in. Sometimes you have to do that. Yes it sucks, but that is the job of a manager. In this econemy it does not pay not to work as there are plenty of people that they can be replaced by and I know of some people who would love that chance to out shine you (me ;-)).
Only 'flamers' flame!
Are they meeting the schedule set for them, or are they not? If they aren't producing any code, what are they being paid for?
Don't you have a project plan? Some kind of schedule? Work allocated to different people?
No?
Guess who's going to go out of business.
Software engineering group project at uni.
A couple of other memebers of the group were considering giving up on the project, i motivated them to hang in there, i ended up doing most of the project... we passed barely the project.
Whilst i was coding the others must have been studying, because they passed to exam and the subject, i didnt.
Groups suck, be an individual.
Since life is giving you lemons, Make lemonade and squirt it in thier eyes.
If that's the case, wouldn't you think that it would be an infrequent problem, as almost every developer would be "just as non-sucky and motivated" as "we the good ones"?
Ain't gonna happen any time soon. There's only one way to learn how to code well, and that's experience. But if they won't even try (because they can't), then they're not going to learn.
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
Programming is not something that everybody can do. The problem is not: How can I make these people into programmers?, because that might not have a solution.
The right question is: How do I select good programmers to hire?
Hiring the right people may be the most important part of the job, for a manager of software developers. It is also usually neglected. There are people who have received a salary as programmers for years, who just can't program.
By the way, IMHO the "Extreme Programming" fad (people programming in pairs) is just a way to halve the productivity of the capable programmers while hiding the fact that the rest of the team would be better employed in other occupations.
Here's what i've seen:
The most important thing is that each developed must be important. Not just feel important, but _be_ important. Delegate design decisions, and encourage people to try multi-pronged approaches and to experiment. Let them make design decisions about parts of the project that fall in their individual areas of expertness. Let them make mistakes and correct them.
I think you have to make the problem engaging to keep people motivated, you have to give your team a chance to all get their hands dirty and think about the problem and design stuff. If you do all the design, code the interresting parts, and hand out the menial labor to your team, you can bet your ass they won't be motivated.
---
Play Six Pack Man. I
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.
This August 6th, join me and the rest of the world in celebrating Co-Developer Appreciation Day! Buy them a mouse pad couch, or maybe a beer.
And remember, if you don't appreciate your co-developers on August 6th, the terrorists have already won.
Tell them you're going to hire me, a real coder, to take all their places if they don't shape up. Then tell them they'll have to start coming in on the weekends, staying late, and skipping lunch. For positive reinforcement bring them krispy kreme donuts every morning, and have daily read out loud sessions from Kernigan & Ritchies book on C.
--
digitalox
On this project, I have a de-facto role of a software team leader
De-facto team leader? Where's the real lead programmer? This sounds like the problem.
You're a guy who likes to code and is obviously good at it, and can obviously self-manage. It sounds like the other team members aren't so good at the self-management part. This doesn't make them useless, it just means they need to be managed. Many excellent programmers fall into that category.
The way to keep programmers productive is to cleanly specify (and by "specify" I mean really, formally specify) what you need, give them the tools/equipment they need, then get out of the way. This is the job of a lead programmer, or other manager. Not a team-mate, except in a dysfunctional project.
BTW if they really need to ask that many questions re: the spec, then you did a bad job of specifying the task.
All IMO, of course!
grib.
maybe
Besides 'The Mythical Man Month' there is also I think its called Code Complete form m$.
I started on a team that the main guy talked a good talked and bug him for a month at that time he told me he had nothing except for the stuff he had wip up that was nothing.
MMM is 1e100000000000% correct NEVER EVER add people to a problem project. Have seen it in person where it does everthing that was described in the book.
Also NEVER try to do it all your self. Saw one time where a team did that and litterly the single guy went mad!
If you are team leader you have a two edge sword. One is your boss. You must tell him and keep him informed. Good and esp bad but most important what you are doing to fix it. He may have some ideas. 2nd you must manage the team to get them to produce the max that can. It may take switching people around, or remove all distraction that could affect them. Or a go over exactly what is nessary but not the code to do their sections.
If you deside to do it all yourself you proabbly have a 10% chance of finishing. At best.
On thing is do they have the nessary skills. Are they in the right slot? But mostly, do they really understand the problem? If you dont understand the problem and the solution you will generate weak code. I had a prof that started on the first day of his class with "I want you to Program the world". Dead quite! Then the moan and groans started. Esp since this was a compressed one month class! He did this just before we had a break. When we all pile back in the room after some real grouching from the class, when we all came back in I and another ask ok please spell out what world etc. We want the details. He said to us the odd of you two finishing are excelent the odds of the rest finishing the project are bad. Because they see a block walll etc. We saw the finish. We wanted to know the exact problem to solve and the prameters to complete it.
From your description they have no firm grasp of the problem and the solution. You can lead, coax, inform, pitch in but NEVER do it all your self or beat the stuffing out of. If its late then you need to restructure, rethink and redo. Else will fail.
There is a section in MMM covering the surgial approack where you cut other help. That may work but the other must be informed that you can do your part and manage but it also up to them to get there parts done. This is not a let you sink but inform them that this is real and they must do their work.
Good luck!
If Tom Landry's hat doesnt motivate you, then I dont know what will! -aaahhh, the Simpsons
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...
are computer programmers going to be forced to conform to certification standards? I have seen a lot of "computer users" try to (and sometimes succeed in) getting jobs as "computer programmers" -- in a lot of cases this involves a certain amount of lies and or embeleshments on the old resume. Imagine if Doctors or even Lawyers were allowed to wander around the job market without ever having to truly learn their skills. "Uh...I don't know how to fix compound fractures -- I thought I would only have to put casts on simple breaks and take x-rays..." I am all for written and verbal testing during the resume process. (You would not believe how many resume's and interviews I have done with people who claim to "be an Oracle or C++ or whatever" expert -- and some of them can't even do simple tasks. During the .com boom it was amazing how many people who had "mastered" HTML and Javascript walking around calling themeselves programmers. (* Most people out of work now can't program at all -- they just complain on /. about being an "out of work techy" -- We still have the same need for programmers as we ever did. Just now we need the real professionals and their is not enough overhead for the wanna be programmers.)
(+1 Funny) only if I laugh out loud.
Possibly the easiest way to get things going is this:
1. Plan the architecture. Sure, some things can be more difficult than others to get going from the start, but design as much as you can in one go, and iterate.
2. Design interfaces to match the architecture; whether it be pure virtual classes in C++, a slew of function prototypes in C, or a set of interfaces in Java.
3. Pass interfaces out to developers, based on functional areas of the code. Tell them that they're responsible for this chunk of the app, and that their job is to code up stuff behind the interfaces. If they're worried about not having other stuff to connect to (ie. it's not done yet), tell them to code up stubs that just return error codes in the right way for their own testing.
It helps if you ask everyone what areas they want to work on, and spread the load out that way. If they buy into it, then they'll work harder for you. But laying down the basic infrastructure and then delegating specific interfaces to code up is the easiest way to get others up to speed. At the very least, you can point to that person at the end of it and ask them why they haven't finished it.
Simon
Coming soon - pyrogyra
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.
Wow, I'm astonished at the unanimity of "crack whip" as a response.
I'm going to take the questioner at his word: he doesn't know why this is happening, and has never been responsible for other coders (or other employees) before.
There's many reasons people might be turning out insufficient or inadequate code. Whether or not you think them good reasons is your call. But you need to find out what they are. It may just be that they are lazy good-for-nothings, in need of "motivation". But maybe:
Some other project has been imposed on them, and the other manager(s) are squeekier wheels? Maybe they've been working their buns off on another project. Or worse, they're saddled with administrative duties ("please restore my drive from backup!") which are absorbing their time. First check to see if something has been competing with you for their time.
They are angry at you or the organization, and they are expressing their anger in the only way they feel they can? Did you piss these guys off? Did their employer piss them off? Are the brushing up their resumes to jump ship, and just going through the motions while they job hunt?
They not coming to you with help because they think you have priorized their being self-sufficient over getting things done quickly? Do they know what your coding standards are (e.g. variable naming protocols)? Do they know you're disappointed?
They've never had to cooperate with another coder before? They are used to pulling a heroic all-nighter and handing it in, interoperability never before required?
In other words, use your problem solving skills. If there is some thing (e.g. other project) getting in their way, remove that thing. If they are having a problem you can solve, solve it. If they lack clue, impart clue. All that may be insufficient in the end, but until you investigate, you'll never know.
And ask people in ways which give them outs. "I had expected more from you by now. Have you been very busy with other things? If so, how can we get this project pushed up your priority queue?" allows someone who was slacking off a chance to realize that they were slacking off and pull their act together, without being shamed or losing face.
-*- Any technology indistinguishable from magic is insufficiently advanced -*-
Dilbert
"Did you write that code for me yet?"
"No. I'm one of those people who needs to be threatened every day, or else I won't do anything"
generally the programmers/engineers/scientists are a egotistic bunch. When preditory behavior combines with egotism, it tends to cause alienation and fragmentation within the group and situations that is being described here can result. Before you rant about how you are doing the most of the coding, ask your self the following; are you being too aggressive in insisting things get done your way? do you tend to put down and ignore suggestion from others? do you mis-trust others to do the right thing where only you seem to know what "right" is?
I mean I'm really not a manager. If I had been appointed the team leader, I'd have this same problem.
To me it sounds like the problem is that the team leader is a coder, not a leader. If it had been just one or two who hadn't done anything, I might buy that they were poor coders, but that's not what's being described here.
Without having seen what was going on, I can't say what really happened, but here's a very wild guess:
The team leader told the others what they were going to do. He understood what he was saying. It was clear to him. So he drew boxes, and put labels on them that meant something to him. Then he said, "I'll take this part", and picked the part that he had clearly specified. Perhaps he divvied the rest up, perhaps he just let them pick. Now he took a large section of the specs. But it was also the only part that he had really detailed. And nobody had clearly specified the APIs. So he said: "OK, now let's get to work!" And he did. And they went back to their offices, and tried to figure out what they were supposed to be doing. And whenever a question came up, he would either brush it off, or call a group meeting. At which nothing would really be clarified.
Everyone was doing their best, but the team leader was coding, which he could do, instead of leading, which he didn't know how to do.
Remember: I warned you that this was only a wild guess. But it's what would happen to me, even though I know better.
I think we've pushed this "anyone can grow up to be president" thing too far.
Many people think managers are not needed, and they can save money by not having them. You can see where this gets you...
I'd just like to say
HAHA.
That's right. You would never hire me for this project or any other. Of the few managers that do interview me, none would ever consider me for any kind of coding job. Why? Because they're obviously too busy picking winners like your co-workers!
HAHA. BWAHAHA. BWAHAHAHA HAHAHA.
Sometimes, life only sucks a small fraction of the amount it usually sucks. I live for those moments.
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.
...is to make design choices that are the opposite of what they want. If they say "Why did you do it this way? It's stupid!" respond with "Because I'm smarter than you." They'll go fix it themselves.
First off, make sure you have a lot of visibility going both ways. We have had good luck with having short meetings 2-3 times a week. This is a forum for anybody who has questions to ask them. It also is a status-update thing. Let everyone know where you are and what you have beend doing. A schedule is almsot a must here. Everyone needs to know what they need to do and when it needs to be done by (this is not as easy as you would think-a good schedule is hard to make up, especially if you start working on the project before the schedule!).
Also, create an atmosphere where everyone knows it's okay if you don't know the answer. Someone else might. This is easier in small groups than large ones, but should be possible in any case.
Another thing you can do is to have design and code reviews. If they know that their peers will be critiquing their code, especially some of the more experienced programmers, they will be more likely to get into the habit of writing legible code. You could even come up with coding style guidelines for your project, maybe even the entire devision. Most languages I have worked with don't force any part of a style on you (the closest I've come to a language forcing a style on me was Fortran77 or Prolog), so it's really easy to code like they do here : http://www.ioccc.org/ (The International Obfuscated C Code Contest). You just have to be sure to do these reviews-it's too easy to just say "the stuff works, we can skip the review to get the product out on time" (See recent news story, I think it was on slashdot, about how software sucks).
The bad news is that these are things that need to be done from the get-go. It's too late to save the project you're on now, the schedule has slipped too much. But you now have some experience. The best thing you can do is to learn from the mistakes made on this project by all involved, and when you are put in charge of another project, fix those mistakes, or at least attempt to.
Against stupidity, the gods themselves contend in vain.
If you are the best developer you should be developing the interfaces (this means detailed documentation for each interface), and the less experienced coders should be writing unit tests based on the documentation, and then filling in the implementation. This assumes you are good at interface design. This is different than being a good coder (but being a good coder is a required condition of being a good interface designer). You shouldn't be doing much implementation, but you should be reviewing the unit tests and implementation of each interface. Designing interfaces is both the hardest and most important part of the job, and probably where they are stuck, and where they will fail. Without good interfaces your project is dead in the water. Interface is everything. If you don't have much experience designing scaleable, usable, re-usable interfaces hire someone who does, ASAP.
Then they should be professional, and understand that they need to be productive or they're fired.
I'd just give them all a frank speech that begins "You need to suck less, and if you don't have a fucking clue, ask me..."
dmarien
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.
Post to Ask Slashdot and when they are slacking off they will read it and realize you are talking about them....
Stop coding and dedicate 110% of your time working with your coders to get them uptospeed. Work with them until they "get it".
Establish frequent meetings to oversee their progress, encourage them to come and ask you RIGHT AWAY, if they have problems with their work, actively stick your nose in their business until they get it.
It looks like the project doesn't include effective control measures to catch problems like this earlier. Two weeks and these people have no visible progress and you didn't know about it, that's very bad. Establish procedures that will catch that sort of stuff earlier.
Have the others submit daily status reports or set up a status meeting every morning before work starts or before work ends, if that's what it takes.
In Soviet Russia, I ruled you
At my company, no project starts without someone going through an writing up a memo with a list of all the tasks that need to be accomplished, and who's working on them. Now this document isn't put on the webserver and left alone, it is constantly updated to reflect changes; people ahead/behind schedule, new tasks, ect. Every new version is published, in pdf form, on the webserver, so that anyone can see what goals need to be met.
For each of the tasks that is non-trival the programmer doing that task creates a spec for it so that we can reuse items (if there is a similar spec on the webserver) and that everyone knows how their portion of the project should run.
Also, we have a perfect project bonus. If you get a complete project done, on time only (becuase if you mis-estimate, you cost the company money, even if it such that you get things done faster than you said,) you get a 5x to the regular bonus for new products. This motivates the project leaders, and their programmers fairly well.
With this, it is required that each programmer have a measure of flexablity in how they get their portion done, typically we create a suite of tools and then glue the suite together with a controling program (it is the project leader's job to make that program, as they should know what each of the parts do.)
When I'm not working, I have hit the same problem with some opensource software I'm writing. I have taken it upon myself, as the other person cannot help much, to write everything my self. I've decided to do it that way, so that I know the code is correct and in the same style.
Sometimes you have to do it all yourself, but if you are paying someone to write code, then they better be doing what you are paying them for.
=================
Unix is very user friendly, it's just picky about who its friends are.
alocate a mililitre of Jolt Cola per line ratio of reward ;-)
Where I work, I was 1 of 3 developers. I was in my own depatment, to do certain tasks and work with thte other departments to create entire projects. I am soon leaving and 2 more people were hired to take over my position. They are supposed to be "up to speed" by the time I leave but they just sit there and browse the web all day. I can't get them to do anything. So In a way, I know what you speak of.
Just don't hire any more ex-microsoft employees, you'll be better off! ;-)
...is to give them loads of weed. Works all the time!
.
"Emancipate yourself from mental slavery, none but ourselves can free our minds !"
Just try motivating Raster and the developers to come up with a game plan for E17 release wise...not easy
Cattleprods.... BIG cattleprods
Problem solved.
As a project leader perhaps you are not delegating responsibility efficently enough. You sound like a self starter, these people most likely had very good GPA's in school because they could follow a book well, now they are screwed. Write them a book and they will be able to do it, but only after they sneak off to the library to do the test together.
Compare the code against the requirements and coding standards (if you have any; if not GET SOME). Read through their code line by line. Point out any actual mistakes or violation of the coding standards, and write them down. DO NOT COMPLAIN ABOUT ANYTHING THAT WORKS BUT ISN'T THE WAY YOU WOULD HAVE DONE IT.
Check that the list of problems are fixed. Start integrating...
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Maybe I'm naive (probably, in fact), but how did your co-workers get hired in the first place? Did they lie effectively in the interview? Are they truly idiots at coding? This is a fairly important thing to figure out, because if they're crap coders, throwing them out on their asses is not the worst thing in the world for your firm.
You need to _talk_ to them and find out what's wrong, not just assume they're idiots. Perhaps they're not so hot at DSP programming, or don't have much experience at C. I know I find it much more difficult to code in C than C++ (ie, function-oriented vs. object-oriented) not because I'm stupid, but because I got taught in school to think of programs in terms of objects. I _can_ program in C - I just don't enjoy it as much and am not as good at it.
In other words, find out what your programmers are really thinking.
-Erwos
Plausible conjecture should not be misrepresented as proof positive.
Get to know them, take them to lunch.
Some people have a hard time coming up with original code. Give them a skeleton to work with.
Help them do the design, in a very concrete way. Your goal in this part is not to do it, but to lead them in doing it. Remember it's their code, not yours, so they need to come up with it, as painful as it may be to you.
Don't think that just because they say the right things, they actually understant what they say. Too many people know the right words, and can even put them together in sentences.
Despite what some others have posted (cover your ass, by making it you're bosses problem), show some initiative by solving this yourself.
Don't think you're boss isn't aware of this. He either can't think of a solution or is seeing if you can solve it.
Spend your free time working on their part of the problem, then the working day helping those get their part done, in their own way. Yes this is a lot of work, but it will enhance your skills at leading projects. Eventually you'll learn to do this without actually doing the work before hand.
If all else fails, start to yell and scream. Sometimes a boss has to be an asshole.
I'm a student at BYU and last semester I was one of five members of a senior project team that designed and implemented a software radio on an FPGA. It was a big task and we all underestimated the work but most of us were determined to get the thing done and working. However, there was one member of our team that just wouldn't do any work. We had weekly meetings to check our progress on our modules and he always said he was thinking about it but hadn't done anything. He's a great coder, just not very responsible.
What we ended up doing to motivate him worked to a degree. First, we started mentioning in team meetings how important it was for everyone to finish their part because integration would be a big issue. Later, the four of us wrote that guy an email expressing our frustration because we were getting so close to the deadline. Also, we mentioned the problem to the professor supervising our team. He couldn't do much, but he talked to the guy and explained that if he didn't work like the rest of us he couldn't receive as high a grade either.
We ended up having to do some of his modules for him at the last minute and he only did one. The result was we couldn't finish the modules he dumped on us and therefore couldn't integrate the module he actually did to see if it worked. So, it wasn't a total success but the four of us felt good about the work we had put in and tried not to be too bitter at the guy that sabotaged our senior project.
So, our techniques worked to a degree but we should have talked to him sooner and taken over some of his responsibilities then so that we might have been able to get them working.
You need some business hammocks. There are a few places you can get them: Hammock Hut, Hammocks-R-Us, Put-Your-Butt-There, and Swing Low Sweet Chariot. It's the hammock complex on Third...in the hammock district.
Also an autographed Tom Landry hat never hurts.
Any good programmer knows the answer to this!! Give them smaller more manageable tasks. Check them more often. Even if that smaller task is,"go code these methods to do these couple of things. These are the paremeters that you will be given and this is what the callnig code expects back." When done, give a slightly bigger task. At each point professionally critique style and efficiency. C'mon!! This is an easy question!! The poster must be a real isolationist loner jerk.
Get some interpersonal skillz!!
Consider writing unit tests for the code for which they are responsible. Then they write code to make the test work. Hopefully the accomplishment of "made another test work" will provide them the breadcrumbs to lead them out of the forest.
It's for the project leader/manager to take care of developers' output. You are not leading the project so it's neither your responsibility nor do you have the authority to change it. Make sure you are doing a good job and that everyone knows (like someone already posted 'ensure visibility') This is what I would have done. Sorry I did not answer your question (how to make co-developers work).
I copied this sig.
The code metrics are intended to show you are paying attention and to generate a bit of friendly compitition rather than to measure programmer productivity. Make an internal project development web page and post the metrics weekly.
Answer any complaints about the metrics not measuring anything useful with; "Yes I know, I'm just trying to establish some baseline statistics"
massive quantities of free caffine?
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
just threaten to fire their asses and then follow through with one immediately if needed. I ran construction crews before I ran networks and it WORKS. If you are not willing to come to work completely ready to fire someone you have no business managing.
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.
beat the guy doing the 90% until he is doing
110% and leave the other coders alone.
at least, that's what has happened everywhere
i have ever worked...
sometimes the non-productive coders get to go
on vacation, or get sent to conferences in
bali or tahiti as well.
I've been in projects where my superiors arent totally forthcoming with info. Info was given out at a need to know basis. And he thought himself such a badass that he kept most of the 'hard stuff' to himself.
Now I'm not saying that you're this way, jsut that this story's just from 1 POV.
Communications skills are vital, if there's a problem early on you need to address it. If you're the lead then you need to make the damn milestones or whatever clear. If the other folks arent producing then you figure out why together, that way-- early on you can either work it out or find replacements. Gun hoe'ing it and taking it on all by yourself and then bitching and complaining about it afterwards-- well you're jsut as much to blame if you're the lead and you let the problem get that far. Involve people.
Of course this is worst case scenario and probably doenst apply. Best of Luck!
There you go. All your problems solved as soon as I walk through the door.
Seriously, if anybody is looking for an ABAP developer in the LA area, let me know. mstore1 at yahoo - you know the rest.
You dont say who your fellow coders are...are they programmers/designers/domain experts?
If they are not PROGRAMMERS then obviously the training that they have recieved is insufficient for the project and realistically the short term answer is that you should finish the project yourself and in the long term they need more training.
However if they ARE "programmers"...well I was going to say "follow many of the excellent constructive suggestions given by others" but on second thoughts I say sack them and make sure your company doesnt hire any more muppets. If they do...walk. Trust me on this one.
Having been a PM for 4 years, I second this suggestion. Raise the issue IMMEDIATELY. If no action is taken, well, you've at least raised the issue.
Reminds me of a saying I live by: if a manager ignores an issue and hopes it goes away, the issue won't go away but the manager will.
Been true for every project I've ever worked on (even before I was a PM).
http://www.extremeprogramming.org/
-- of the twelve XP practices, pair programming makes hiding away from coding impossible. integration is continuus.
I have a motivator mounted above my desk.
36 inches of hickory Baseball inspired motivation.
or you could just threaten to fire their asses...
Set up some sort of project plan or some sort of blueprint of the code that needs to be written for each of the features of the project. If you have already gone through the exercise of writing requirements and a detailed design for the features, this should be a breeze. Once you have this setup, as the lead of the group, you should have a weekly meeting to get status of each of their items on the plan. This way you have everything organized and accountable. During these meetings, you should get the status of each person's sections. If they are late, ask them why and how much more time will be needed for each section. If it lateness still continues, you seem to have a personnel problem and should deal with that accordingly. However, at least now you have a good way of tracking what's going on.
First lets face the abvious. YOUR SCREWED. So now you have to take some action.
First you have to delegate new tasks. You tell your coworkerless that there has been an shift in the project and they are getting new tasks. Give them something meaningless and has nothing to do with the project to keep them occupied from noticing that you have taken on the tasks they failed to complete.
Now that they are off on a skycrane search, you complete the project completely under your control then had it to your manager. Don't tell him anything just let him belive whatever he want to believe.
Your coworkerless can remain clueless and continue to waste their time on the skycrane project.
Last step, MOVE ON to your next project and request a new set of coworkerless. Then just chuckle on your way home.
"Your having a bad day when the voices in your head put you on hold"
- 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.
Well, there seem to be a lot of *fire them* posts in here. That's just stupid and immature.
... it's a heated debate catalyst). Nobody will want to admit that they haven't finished their bit when everyone else has, which means they'll be actively trying to solve the problem your dealing with; they'll try to make themselves more productive, which is infinitely better than if you try to.
... it's much easier to see other people's mistakes than your own.
;)
The reality of development, like any other professional field, is that 90% of people are collectively as capable as the 10% which are adept at their jobs.
Clearly, and logically, if 4 developers are demonstrating the same problem, it's unlikely that all of them are bad workers. More likely there is a breakdown in the development process which is stopping them. This isn't necessarily the case, but we'll posit it's truth for now.
In my experience, these sorts of failures are usually due to a lack of organization and transparency. Nobody likes to feel like their in the dark, and in the absence of a development process that motivates employees, they generally won't acomplish much. While you may be a better programmer, I would wager that the difference in productivity between you and you peers is because you are able to self-motivate, whereas they are not.
Here's a really simple solution that's worked for me several times:
First and foremost, you need someone in a PM role. This sounds like it's you right now, but your not doing it so well if you were 'surprised' to find that your peers were not keeping up. If it's your cup of tea, then do it, otherwise pick one of your peers who is very organised and nit picky (i.e. the guy with the really clean desk).
It sounds like you have done pretty good front-end planning, but many people make the mistake of writing a bunch of design documents, figuring it out, and then just going off and writing code. You need to integrate that front-end planning into the process of writing the code. One approach that has worked for me is to get a bug tracker (I like Double Chocco Latte) and get everyone to breakdown what they need to do into tasks. Task in this sense should be at a level of granularity where you can finish at least one task a week without any trouble. Just the simple act of ticking something off when it's done really helps people get motivated.
Now once a week, buy a case of beer (expense it), or go to a local bar with printouts of all the tasks (expense it), and make sure people are making progress, discuss the problems they're having, and get happily wasted while talking about code. This is fun, makes sure everyone knows what everyone else is doing, and gets a friendly bit of competitiveness going (the hidden motivation for the beer
Finally, if their code is really _that_ bad (and bear in mind that to an experience eye, not-that-bad code often looks really horrible), then you need some level of quality control. I've found code review to be incredibly helpful here. If your using CM software like CVS (and if you aren't please get some quickly) then institute a policy that nobody commits to the tree without having someone else review their code. Initially this can often be you, although you want them to review each others code as well. Peer review provides a great avenue for knowledge sharing, and will get people to ask you questions they wouldn't otherwise. Additionally, if they review eacxh other's code, they'll start to learn about the aesthetic of good code
Not surprisingly I also like to do code review from printouts over a pint. Again, lubricates the conversation.
This may all sound a little corporate, and well yeah, it is somewhat. But coding teams are like cardinality, you have one coder or many, and the exact number is pretty irrelevant. You need some process as soon as you have more than one developer, and well, big corporations have spent a lot of time figuring out how to make teams work effectively. Please don't think I mean you should institute core hours and a dress code...
Cheers,
Xenophile
Getting rid of these other developers is not so evil. Perhaps they will be excellent programmers some day, but they need time to grow, and the need supervision. It doesn't sound like you have the time to mentor and educate junior developers, and finish this project on time. Production assemebly programming is not a good place for novices to start. They start out scripting for the web site, or maintaing existing code.
These guys are obviously starting their coding careers from scratch. They need simple tasks and a lot of supervision. Your experience and speed at programming, combined witht he urgency of this project, is probably intmidating them. You may be under too much stress to comunicate your goals properly. I doubt you have time time to teach basic programmnig skills. Do you have time to do pair programming, or code reviews, or other types of hand holding?
Have them reassigned. If you want to work with other people on a DSP written in C and assembly, get really good programers with years of experience. Or go it alone.
Your waving Brooks Law around shows a lack of understanding. The notion is that in order to bring a new person onto a project, those who are currently programming must spend time educating that person about the project. Currently, you have four people working with you from the start, and you have been unable to explain the project to them. You are the only one coding, and now you are asking slashdot about how to rally these other programmers who are obviously in over their heads. Don't you think that this time would be better spend explaining the project to a verteran assmebly programmer who doesn't need mentoring? Brooks warns about the drawbacks of increased communication. Replace these four with one darn good programmer and you have reduced communcation requirements, not increased them. (You aren't adding, you are reducing.)
Strip the team down to one crackerjack developer, and hire one other crackerjack developer. A second person capable of writing the code all by herself. Give that person the salary of the four guys who have been reassigned. If you can't get productive work out of a hand picked, veteran C programmer who's getting paid a kings ransom, then you need to step down from the role as project lead.
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!
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.
Some people should not be programmers, but are. Some people are pretty good programmers, and some are natural programmers. The natural programmers take care of themselves -- you only need to visit them once a week, and they will probably visit you anyway to show off or ask questions. (I'm assuming your're a team leader.) A "visit" means you drop by their cube and ask what's going on.
Most people who are programmers should not be programmers. Programming became far too popular of a field over the last decade. There is not enough aptitude to fill the slots. These people are fairly easy to spot. Whenever you visit them they have nothing to show really, and they are working on a bug. They do not come to you to ask questions. There is nothing you can do about these guys, except try to find a non-programming task that fits their aptitude -- business analysis or documentation or something.
Most of your effort should go into the pretty good programmers. These will visit you occasionally to ask questions. When you visit them they have made progress, but sometimes it seems tangential. These are the people who benefit the most from long informal design discussions, and direct "have you tried this and that" help in debugging. Visit these guys everyday and it will pay back a lot. You may even want to get a little Extreme with them and sit down next to them, or (best of all in my experience) trade modules. Actually give them the code you are working on and work on their code for awhile.
What you must do is, write all the code yourself. Otherwise you'll be debugging the code of others line by line which takes longer than doing it entirely yourself. The only up side of all this is that you get to badmouth the rest of your team all term...
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 am going to assume that they are newbies, and getting paid as newbies should. Fix that first because you care most about your company's bottom line.
When I was a newbie in a small consulting shop I faced many of the problems your co-workers have. I had no clue about the librarys I was working with (in-house, ObjectARX, MFC,..) and was too stupid to ask for help and spent all day in with my head in a book trying to catch up to speed. As long as they are newbies you become the mentor. Break projects down 1-2 day chunks that they can work on without too much trouble. Meet with them a few times each day to see if they are stuck on anything and encourage them to ask lots of questions. Also, since you have a group of them it might be nice if you split them off into pairs for some projects so one could research questions they have while the other codes. Rewards are also good. If they produce some good code show it off to others. Sometimes newbies have an attitude that they don't want to screw things up, and a little confidence goes a long way towards them beliveing in themselves.
bash-2.04$
bash-2.04$yes "Don't you hate dialup connections?"| write USERNAME
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...
We recently encountered a similar event on our software project at work, where we have been developing a behavioral modeling package. However, we did not have our faculty supervisor in the country for about a month before our release date due to attending conferences in Montreal, Australia, and China, respectively. Therefore, the task for motivation and monitoring fell upon me, the interim project manager (and an undergrad at that).
Basically, I found the best way to keep everyone working was to schedule a time (usually about an hour) every day where I would stop by the lab and ask to see what they had done that day. It would usually embarrass them to say that they didn't have anything to show for a day's work, so they started working harder. If they had any questions about how to do something or what they needed to be doing, I was there to answer in whatever gory detail it required. Therefore, I was able to expect a certain degree of progress every day.
These daily sessions were supplemented by a weekly group meeting. During this time, we would give definitive goals for the week and group lessons on programming in PyQt (our chosen language).
Give praise when needed and force deadlines when necessary. Always be willing to answer questions and respond quickly to keep them on task. Unfortunately, you will spend less time coding, but the quality of their code will eventually pick up once they get going. Just remember that being heartlessly negative will only amplify the problem.
There are two types of people: those prepared for the zombie apocalypse and those who will be eaten.
I hope no one on your team reads slashdot; if they do I hope your name is not really Cliff. Even if you made up a fake name, your staff can probably recognize the situation you just described and your style of writing or speaking.
Your rant provides a good example of why top talent does not always produce top coaches. You sound like you have got promoted to management but haven't learned yet about how to be a coach.
I give you some sympathy in that it sounds like you inherited your staff instead of hand picking them. Top that off with the fact that you are still expected to be a producer yourself. In your first manager role it is better if you aren't expected to write code yourself so you can focus on coaching your team.
I am sorry to say it sounds like a deathmarch situation. How much confidence and trust do you have in your immediate boss? Sounds like this might be his/her screwup.
Cattleprod.
--
E_NOSIG
Quite some people have suggesting various kinds of threats, "show them the door" etc. to get the other's to realize the problem. Bad coding suggests inexperience rather than lack of interest, and I really don't think an inexperienced person will perfom better just because he's threatened.
What to do depends a lot on what your personal goal is, and what you're trying to save.
If you want to be doing design, coding etc., just stick with what you've been doing, and don't care about the others. Review your _actual_ responsibilities, not implied. Are you an appointed PM? If not, just go on, design and code, report your part as done as usual, mention the problems with integration tests for the PM etc. Your PM will recognize you as a good SW engineer, especially when he realizes the other's problems, and that will become his problem.
If you want to become a true PM, then your job will become solving these kind of problems. Learn from the situation, and just get used to it! Remember, a project without problems doesn't need a PM!
So, for the assumption you want to do something than just doing your part of the job, the next question is: What do you want to save? The project, or the company?
Even if you're very good, taking over the other's part probably won't help, unless they are only producing less than 15% of what you're capable of (remember that you're most likely going to throw most of their code away and restart, since if they still can't get it to compile, they are probably having major design problems as well).
Getting more resources are too late, you say. So did I at a project I was working on, but we were somehow always able to find isolated parts that could be done by external personell with fairly little support. Surely, support will be needed, so tell the PM that you're willing to sacrifice your own kloc-productivity, to concentrate on support. However, new resources can't rewrite existing code in an effiecent way. You will need to find parts that has little or none existing implementation.
If it's just the project you're wanting to save, make the new resources take parts of your fellows code, and let them work on small, well-isolated fragments of less importance.
However, this approach might intimidate them, and some might even start hating you. If they leave (or are forced to leave) that will be good for the company, but if they stay, productivity between you and them will be even lower whenever you need to cooperate again.
If you're thinking larger, make sure your colleguaes start seeing you as the mentor. Work with them and let them (mostly individually) ask for your guidance or asisstance. Offer to do boring work etc. Let them grow and give them confidence. Let any extra resources do what you used to do.
This is a larger risk for the project, but it will be the PM's job to convince management of that. However, your colleguaes will grow and become more productive in the future.
Also, remember that the program produced is a mix of time, resources, features and quality!
So, if there is too little time to introduce new development resources, try getting them at the test stage; Do integrations and builds as often as possible! Get testers to test whatever's done. Get testers to write unit tests, and perform intergration tests. Make sure they produce written step-by-step instructions of what works and what doesn't, so that the developers don't have to chase the bugs, just fix them! Let the testers re-test everyting that used to work (and everything that didn't work) with every new build.
I hope you all succeed in producing your application!
Software Designer
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.
About motivation and or firing people who aren't doing their jobs. What happened with sitting somebody down, looking them in the eye and telling them that they are causing harm to the project and asking them what they need. It sound to me from the post that you are obviously not satisfied with the quality/quantity of their work so then its up to you to bring them up to speed. Its not hard to talk to somebody about what may or may not be bothering them. And in the five minutes of conversation you might better learn what they CAN do instead of bitching about all that they cannot. Take notes of your conversations and when somebody above you asks for a status report from your project, refer to your notes as per your conversations with the other "engineers" Not only does that cover your ass from the who's running this thing department it might actually offer some feedback to the people that you are talking about.
Try to remember that you once sucked at something as well and try to keep an open mind.
I was once in a situation like this when I came on board a project. All the work that was supposed to have been done was trash, and the two programmers I was supposed to work with were incompetent. Instead of fighting it, I put them in charge of "QA" (after I had tested, debugged, etc), to make them feel useful, rewrote all that they had done, and continued the project on my own from there. No sense in fighting it, if you can do it quicker.
Seriously. Ignore them.
You don't want people like this writing code anyway, you'll just have to go fix it yourself.
Try to get them cycled out and eventually (hopefully) decent people will cycle in.
The ideal situation is to have someone around who is good at giving these people something useful to do (writing manuals, testing)
This shouldn't be you though, you should be coding. Someone has to
Comment removed based on user account deletion
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.
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.
You could steal their red stapler. That always seems to motivate people.
Electroshock Theropy
Who made the estimates on your little project, you? Did the sessions go like this:
"Ok, this part is so easy, so very easy. You just need to do blah blah blah blah. Get it?"
"Umm, yeah."
"Ok, how long will this take?"
"I'm not sure."
"Lets say 2 days."
"Ok."
Lo and behold, they don't have it done in two days.
The very fact that your idea of an easy solution is just to code it yourself says loads about you.
You say that its very obvious that they understand what to do, because you've had "discussions". There's a little thing that we real engineers (Yes, thats engineers or developers, not "coders") like to do. We write "specifications". If you had written specs, or had them write specs, these problems would have come up early.
No, I know you very well. You had lots of "discussions" where you basically came up with a clever system all on your own, using terminology and technology you were familiar with. Then you disappeared for two weeks into your cube, eating potato chips and rocking to mp3s on your noise cancelling headphones. Then you popped out, and were shocked that nobody had coded the design in your head as well as you had.
And although being "in the zone" is fun, virtually all code written while "in the zone" sucks. Many nifty pieces of software have an essential core written by someone who was "in the zone". That core provides much of the "wow" factor of the software. It also provides many of the unexplained bugs, and most of all, it always provides the nail in the coffin when it comes time to modify the original functionality, because nobody, including the original programmer, can understand it.
As a 20 year veteran of a large number of big projects, I now strongly feel that I'd rather take three times as long to code something by really understanding it, than to code something quickly while high on caffeine, sugar, and lack of sleep, then spend a month debugging it.
Cantankerous old coot since 1957.
fire them and hire me!
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
You started your supervising too late. Good communication is a constant thing. It takes work, but it pays off.
Sitting down with each person and asking, "What's you plan of attack?" is a good way to start. Prima-donna's will get offended. Cooperative players will be happy to go over their approach, and even look for the logical errors early.
Remember, finding problems early in the cycle pays bigger dividends.
Oh, and ready, "How to win friends and influence people." It's a great book.
My experience has been that if someone has achieved some modicum of success over the years (e.g., he or she hasn't been fired), then nothing short of harsh action is going to change that. There are lots of people who will totally coast whenever possible, and lots of jobs where they can get away with it. Once ingrained, nothing short of fear for his or her livelihood will change that.
At my last job, I kept vouching for a co-worker whom my boss felt wasn't worth keeping around. After initially giving him the benefit of the doubt more than anyone else (I was really the only one actually working with him), after a while I came to realize my boss's impression was correct and I had lots of talks to my co-worker about his productivity, etc. I ended up being appointed his supervisor (we were first hired as equals) but even that didn't work. He ended up giving notice the day I recommended he be canned. In general, I think I put up woth a lot more than I should have because he was a nice guy and generally seemed to be trying hard and the project we inherited was the worst code either of us had ever worked with (discounting perhaps the 1000-line dBase routines written by the boss's nephew I had to untangle at my first job in the late 80's), but given that we were swamped with work and I could never count on him to get anything done, and _then_ he started doing things like not showing up and giving lame excuses, I had no choice to recommend replacing him, and believe me, it was not an easy decision to make. Anyhow, it's clear he hated it there (so did I, and I left 6 months later), and him staying was doing no one any favors.
Once crisis-mode hits, I'm afraid to say that based on my experience it's too late to fix problem workers.
You are in a maze of twisty little passages, all alike.
Read "Atlas Shrugged" or "The Fountainhead" by Ayn Rand. Anyone who's ever been in this position will easily relate to both these novels.
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.
Seriously, best advice is to take a good hard look at your situation and surroundings and make an honest assessment about whether you can succeed in that environment. If you come to the conclusion that you are doomed to fail cut your losses and get out if you can. Don't throw away good time after bad.
Hopefully the rest of the advice on this page works for you and you can ignore this. Please don't just discount it out of hand though - you sound like a the honest hard-working type and I hate to see good people wasting their time and damaging their careers.
Davo -- Free speech, free software, AND free beer.
But that's water over the dam. You have a project you need to get back on track -- and fast. The first step: have you told your boss? I'm not talking about blaming the other guys, I mean expressing a concern about the project schedule. If he finds out the hard way, he's going to be peeved at the project lead. (That would be you.) If you warn him now, he might actually be able to help. Perhaps he can assign additional resources, change project schedules or at least warn his superiors that there is trouble brewing. Any manager worth his paycheck realizes the value of having employees who give him a heads up when there is a problem that needs to be addressed.
Next, sit down with your coders and talk out the problem. Again, don't let it come across as blame or they'll just get defensive. Make sure they understand the schedule and what the problem is. Maybe they can work extra hours or maybe there are problems they haven't mentioned. In either case, try to come up with a work plan that meets the schedule or comes as close as possible. Include some form of accountability so you'll know if the schedule is going to slip again.
Finally, you're probably going to be clocking in some late hours. Keep an eye on that and make sure you leave the office when you have to, regardless of the schedule. Killing yourself won't get the project done and will just make the schedule slip worse in the long run.
Illegitimati non carborundum. (Don't let the b******s wear you down.) :-)
Good luck.
===== Murphy's Law is recursive. =====
If you're the leader, you need to lead. Let your direct manager know that the project may be in trouble. The only downside is that he will know that you haven't been watching your project closely enough. Let your team know that the projects in trouble. Lay out the remaining tasks that need to be done and give them hard milestones. If they miss em' fire em one by one.
I agree about pair programming. In fact, *YOU* as the lead should pair with the other developers, so that you can guide them and maybe find out what the problems are. Spend a day or two with each guy/gal.
The other thing is to make everyone write unit tests, and if possible setup a continous build that compiles everything and runs tests everytime someone checks code in (you are using source control, right?). There are many OSS tools that do this and send email when things break (compile or tests).
Then everyone will get a feel how the project is going.
Don't hog the good work for yourself, just because you think you're much better. Somebody else should know the code too, or else you'll never get any vacation.
...richie - It is a good day to code.
.... this motivational speaker for developers:
ballmer
First off, if this is the first time you have reviewed your friends' productivity, I'm not sure why you'd call this project "late". If you feel you are late, and you have just gone through your first review, you have to come to terms that you will be behind schedule. Either way, a reorganization is necessary. That does not necessarily mean people -- it could be time -- either way, you better take some serious action soon.
'nuff said
1984 was supposed to be a warning, not an instruction manual.
Okay, it sounds like what you really need to do is implement weekly status meetings, where at a particular time and place every week, everyone gets together and shares what's going on. The meeting doesn't need to be very formal, and trust me: doughnuts can help keep people in a good mood, and don't cost a lot.
But at each meeting you should have everyone go around the table and describe what they've worked on that week. Describe where they are in the code, how they're doing, any difficulties that have arisen. The meeting should never be judgemental; instead if someone is taking longer than expected, see if others can offer solutions or help. The whole theme should be group coherency; no-one is an island and no-one gets left behind or allowed to sink.
If you do have these meetings, it may be best to place them on a Thursday; that way people are motivated Tuesdays and Wednesdays to do something so they have something to show. And that way, they feel like they can have some breathing room Monday and some time Friday to either catch up or slack off, depending where they are in the project.
But always have them; insist everyone is there, and insist everyone share where they are. The meeting itself, if handled weekly for a small group of people should take no more than half an hour, so there is no excuse for the thing sucking down an entire day. And for God's sake, no presentations! Just an informal chat with the entire team there over doughnuts to discuss progress on the project.
From the description of this particular situation I would have to say this is 90% a project management issue.
Are there no schedule with individual milestones? Keep in mind that the designer (not coder as any schlock can lay down code) should provide input on time lines (e.g. sure, that date is reasonable for that goal...etc.).
Projects also have to be monitored and have schedules updated to reflect reality and/or make necessary changes in work division.
Also, use a tiered design approach; ie. high to low level. This way yes, the requirements & application domain are spelled out, but each design documentation layer brings the next level of gritty details to light. So, in terms of S/W design, a high level design document for the overall architecture. This makes it clear as to how components are connected and related. Then go down to document the individual module designs. These highlight the intent of how a module will perform it's function. With this in hand coding almost becomes trivial.
Now a documentation trick that I picked up from a great mentor in DSP was to use different levels of pseudo code in module design documentation. High level stuff that is to be implemented in high level languages and is not too harry (ie. not some convoluted DSP algorithm) can use a very general level of detail in the pseudo code. E.g. Enable echo canceller AND run state machine Y. However, if one is documenting something to be implemented in assembly (particulary harry DSP algorithms) then use a detailed level of pseudo code that is equivalent to say C or some other high level language. The idea is that the intent of the implementation becomes easier to verify prior to ever writing a line of code. Overall, this also means that people have thought out how things will work in great detail and this has been reviewed; ie. at the design documentation level. This also simplifies & improves the effectiveness of code reviews since the design intent is well documented.
Which reminds me: code comments should describe the _intent_ of the code and not what the code actually does.
As for bad code, that is what code reviews are for. Now bad code in DSP can be very nasty, particularly in assembly as one incorrect shift can cause huge problems and be very difficult to find.
BTW, I'd recommend simulating the code after a code review and it's fixes, to help ensure code sanity.
I've also seen enough DSP and other "interesting" domain code from people with Masters and even PhD's that is pathetic as far as good code is concerned. I have also worked with brilliant people with this kind of background that seriously put us mere mortals to shame.
If your designers are really that poor at coding and you do have the skills then I would suggest a frequent level of mentoring. A positive atmosphere and some mentoring can go a long distance in terms of improving a designer's abilities.
Anyhow, good luck!
Knowing the tendencies of most /.ers, I'd say some sweet hot man-candy would fit the bill just nice.
Who the hell hired those idiots? There are too many GOOD programmers looking for work to accept this excuse. Whoever hired them should take the responsibility as being the principle cause of the failure, and replace them on the spot. GOOD programmers can pick up on a project fast. Afterall, this is only a 20K project. That's relatively small. So this will set you back at most another month. Just do it. Please don't encourage BAD programmers to stay in the field.
now we need to go OSS in diesel cars
... should be hard to read.
Words to live by.
eXtreme programming only works if all members of your team practice proper hygiene.
The point about programmers believing their work is in vain has got to hit close to home for a lot of people. Imagine working 60-hour weeks for a couple of years on a game that's probably going to be killed by its publisher, and you can see why so many coders spend all day on Fark and Slashdot.
It's easy to say it's the coder's responsibility to find a more motivating project, but with the job market the way it is, a lot of people end up feeling both lucky (to have a paycheck) and guilty (for surfing all day) at the same time.
I just post my gripe to /. with enough detail so my coworkers will see it and be shamed into 1k-lines per day productivity. Works every time.
My experience comes from managing a small (8-person) team. There are a couple of things I learned.
First, I assigned tasks. If an employee failed to complete a task, I often broke it up into simpler/smaller tasks, and requested them one at a time.
Some employees were self-starting, some required more hands-on. All required positive feedback. Even though we were about the same age, they seemed to look up to me for approval. I don't know why.
So, managing a team can mean a lot of work and coordination. I would say that in your situation, you have become the leader.
Torsten
You must be at a big company, because only big companies can tolerate incompetence - small companies usually go under from incompetence.
So odds are good you're working at a big company.
My advice, is to just give up and slack off. Where do you think you're going to go in a big company? And if you're going nowhere, what's the point in getting there any faster than you have to?
It's probably too late to be an underachiever at your present job, but in the future, you might want to think about underachievement as a survival strategy.
Unless you want to go into management, in which case, I pray for your soul.
Actually, he said "co-developers" and "de-facto role of a software team leader."
What this really means is that Our Hero's manager is weak, a guy who wants to limit his own accountability by blurring the lines of management. He won't acknowledge Our Hero's management role with an actual managerial title or compensation, yet he will continue pushing project responsibilities onto the poor, inexperienced guy.
This allows the manager to take credit if it works and to avoid blame if it doesn't. Been there, done that. In the long run, no matter how this project turns out, Our Hero will still have the same bad boss, and he'll be in this project situation again and again until he gets a different boss or redefines his role up (into management) or down (back into coder-only).
He looked at me and said, "Kid, we don't like your kind, and we're gonna send your fingerprints off to Washington."
... unless you have a really backwards hiring process I doubt you'd have 3 people end up on the same team that are as useless as you describe them.
One in 5, yes, but 3 of 4?
Perhaps there is a problem with architecture or maybe there is too much irrelevant documentation to solve the tasks. The more uncertain people are about a software interface the less probable they are to ask questions about it, at least in my experience.
I think you will need to work with them, either paired programming or whiteboard programming (yes, doing code in handwriting) and dedicate a large amount of your time to "lead" the team. Make an example of a programmer by asking him what his task is and ask him how he intends to solve it describing everything in detail.
Being the one who is most familiar with a project also requires that you have the social skills to make others work in a team, teamwork rarely happens by itself.
It is very simple. You are a mapper, they are packers. Go to www.reciprocality.org for more info.
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.
I know how I would react. I would ignore that everyone else wasn't doing anything, let the project run over, and eventually do all their coding myself. Single person projects are so much easier than multi person projects.
In my experience, working in pairs with someone taking initiative on most of the project (yourself) works wonders in getting people with different skill levels and styles on the same page.
When you map out and start a project, think of the most complicated functions within each class/object/module and discuss how you plan on implementing them with the team.. even if they are doing all of the listening, they will understand the goal and how you are going to do it (even if it is over there head).
Work on the classes that are going to be used throughout the entire application (the ones you see as being important to reducing development time and increasing efficiency) - and as soon as you are done, do one or two implementations of this class.
Pair/group up and demonstrate how your class is actually implemented--you can touch base on the actual class again, but don't spend too much time (beyond talking about any trouble you ran into, or the cool parts of it) -- concentrate on the actual example of implementation.
Suggest a location for them to implement this, and that if they have any questions, you're just a few feet away and that you're about to begin on the next class. Touch base on how you plan to do the next big class, and repeat the above steps with question/answer breathers after they have finished implementing the previous class everywhere (or atleast to the point where they think they are comfortable with it).
You are obviously the most skilled of the bunch here, so they should be (and will be) following your lead and welcoming your guidance. (if they don't welcome guidance, they will never be real programmers. fire them now.)
This really has worked for me well on smaller projects that I lead, where there is a significant gap in skill level or initiative.
A lot of good comments here that really do work on bringing someone up-to-speed -- not so much with a project, but on how you as a leader operate and think. Get them into this rhythm, and they will soon have confidence enough to take initiative themselves (with you checking over work still).
Best of luck!
Jason Fisher
This sounds easy. Involve your manager. Have him/her involved in the integration stage. That ought to motivate them. You sound like a good coder. Get somebody else to motivate them.
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.
Never let anyone go off and code on some large single task without keeping a good eye on them. Micromanagement is often a dirty word, but to manage multiple coders that are supposed to be all working on the same project, you need clearly defined and intricate goals. There should be meetings and code reviews at least once a week. Integrations should be staged, as you said, "early and often" that means at least weekly, up to daily if applicable.
Any slackers then show up early and they will end up being hounded (maybe by you, or the rest of the team). They either shape up or get replaced. There aught to be plenty of people looking for jobs these days.
One would hope that the idea of remaining an employee would be enough motivation to start pulling their weight. Beyond that, generally a coder works better if they believe in the project and believe in their team mates and bosses and have a generally friendly atmosphere. But I got to say, these days that luxury just isn't as prevelent as it used to be.
Also, even if they are coding. Keeping good track records of performance and code quality is also important. Basically, if you've got lazy programmers they will get away with what ever they can. Just don't let them get away with anything for any length of time. Don't wait until it can even be a problem.
Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
Unfortunately, the best coders don't always make the best managers. I've seen extremely good coders fail to manage efficiently, usually for two reasons: (1) They spend too much time coding, and not enough time managing, or (2) they simply aren't good managers.
The original poster is in a bind, as he's being forced into a position to wear two hats without adequate resources to manage both. My suggestion would be to put the ball back in mgmt's court: Make it clear that you will either play the role of developer, or the role of team lead, but not both (unless adequate resources in time and pay are allocated).
Continuing down this track is simply giving mgmt what it wants: Two job descriptions filled for the price of one. Your performance suffers, while the bean counter who made this ludicrous decision wins, at your expense. You are being used, plain and simple.
Just say no.
It sounds obvious but when you are the lead and/or you have juniors you *must* keep in touch with them, you must show an active interest.
Daily meetings: Walk up to them, ask them how they are doing, ask if they have anything to demo, ask to see the code/design, ask if everything is okay, if they have problems etc. This should take no more than ten minutes each person - time yourself to ensure you don't squander massive amounts of time discussing time travel or quake strategies (is there such a thing?)
Show them the way: Periodically (every few days) drag one of them from their cube so you can share some brilliant insight into how things get done. Explain the problem you had and the magical solution you figured out. Ask them how they would have solved it. Get *them* involved in your bit so they understand the one true way.
Code reviews: Review one of the other developers code *really* harshly and then have him review someone elses etc. Reviews work wonders especially when they are *very* harsh and if you set the bar really high they will try much harder - possibly exceeding your quality/quantity level. Do this periodically and also force them to review your code.
When they are slow/late/buggy: Make sure they know it. Have a post mortem at every event. If they are early figure out how come they worked so fast so it can be reproduced. Make sure everyone, including you, learns from each event.
Encouragement: Doesn't matter how small their achievement make it BIG. Everyone loves to hear "That's great, well done" so make sure they hear it from you. Also, encourage them to read more books, buy the books and hand them out (after you have read them)...then ask for opinions on the books and discuss them briefly.
Do less coding: Sadly, when you have a team to run there is less time to do the fun stuff. It's a fact.
Over the years I've noticed that there are more 'career developers' than those that do it for fun. I find these are the ones that need the most attention, the most encouragement (and also produce the crappiest product).
fuck 'em. do it all yourself.
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.
I've been a manager for several years and a consultant for more. It is far more likely that ability is the issue than motivation. But whether ability or motivation it is the MANAGERS job to correct the problem.
The problem is that most managers will not effectively solve this sort of problem. Furthermore Human Resources people tend to think that if the programmer can find the office then somehow productivity amoung programmers will be somewhat similar and typically somewhat in line with their credentials. Simply put - these ideas are totally flawed.
Productivity between university educated programmers on the job can vary more than an order of magnitude between people on similar tasks. In addition, the highly productive programmers tend to be highly productive on all tasks and the unproductive programmers similarly tend to be unproductive on all tasks.
One solution is that if you write 1/2 th code for a project then you deserve 1/2 the salary budget. (in fact you might merit more than 1/2 the budget since the management overhead will tend to focus on the unproductive drones) Of course - this sort of fairness rarely happens.
A better solution is to just quit and hang out your own shingle so to speak. If you really are good, then you will develope a reputation rather quickly. You can earn more than 2x per hour compared to employees doing the exact same work.
Some of the pitfalls that I ran into during my days as an employee:
1) a co-worker suggested I stop working so hard because I was making "them" look bad.
2) co-workers tried to black list me from the informal office "good guys" because they resented my abilities. It turned out _all_ those co-workers quit save one and I ended up running the project.
3) co-worker tried to sabatoge my project team. This was quite subtle.
4) co-worker was assigned the task of developing a critical subsystem. After more than a year of pork barreling this co-worker had not written a single line of code and in fact was not technically able to do the job. This got to a very critical junction in the project and the chap was clearly counting on arguing to the managment that when we failed the reason for the failure was "my" specifications on how this subsystem had to function and not "his" inability to do the task.
In fact in this case there was a LOT more going on because head office was planning on deep sixing the whole project if we failed. There were more than 50 jobs at stake.
I grabbed my top programmer and wrote that subsystem while management was on the plane to Houston with a demo planed that of course needed this critical subsystem. It took us Friday til 2 am and part of Saturday afternoon and the subsystem was up and running and fully functional. This for a job the co-worker had sat on for more than a year.
The demo was a great success and it saved the whole project which employed more than 50 people. My co-worker's response was to go to the VP and claim I exceeded my authority when we developed the subsystem. He tried to get me fired! That backfired in his face because at the time he was on holidays and I had in fact been put in charge of his division as well as mine so I did have the authority to do his job.
So there are some of the dirty tricks that _some_ people will pull to get competant programmers out of the company. A highly skilled competant programmer is a threat to less skilled technically and usually more skilled socially brown nosers who are looking to climb the promotions ladder.
So if you are writing 50% or more of the code on a project then beware... typically there is a LOT more going on than recognition of productivity. You can't be brown nosing and office politicing if you are writing code.
I dunno how this might help for real, but here's a bit of info: I don't even work in the IT industry, yet I face the same scenario on an almost daily basis. Hence, I conclude that the problem is probably more social or political than anything (assuming the co-workers can be proven competent in their fields). If not competent, then it's time to have a few words with your hiring dept., HR, or whatever you call them...
C|N>K
These are all not unreasonable suggestions in certain scenarios. A lot of it has to do with the tradeoffs involved in your deadline. I'll tell you this: you undoubtedly need to meet with your manager at some point in time. Lay it out calmly and cooly and explain whether, in your judgement, the team has potential or is beyond hope. Discuss how you can still meet the deadline, or explain that you need to push this deadline a bit because there's going to be ramp-up time associated with getting this team up to speed.
You can be a team leader without being a full-time manager. In fact, you should be, in my opinion. A lead developer for a team needs to be concerned with project design, deadlines/scope clarification (from the technical side at least, though you don't have to spend all your time in MS Project to represent the tech team in this regard). It's better that the lead developer not be directly responsible for HR concerns, schedule reporting, and shouldn't have to be the primary negotiator with the business/requirements side.
That aside, firing people who are continually nonproductive is reasonable - but I'd push that decision up to your manager and let him/her decide that - and generally, unless this is a small startup, people get more than one chance to screw up. Personally, I think they should get two, not five or six. And they should be told that they've been screwing up - ASSUMING that they are supposed to be mid-level or more experienced developers. If these guys are junior, or this is their first job out of school, they need to be cut some slack, and your manager shouldn't have given you a team with four new kids as your first gig as a development lead.
So this leaves pair programming and mentoring. I don't think there's much of a difference, but I'll say this - pair programming is helpful even if two junior/dumb/mediocre programmers are working together. And if you are working with each of them in turn (swapping out) they WILL improve over time, unless they are ROCK stupid. I can't judge whether these fellows are rock stupid, or just inexperienced, or not good at thinking in the logical manner that programming dictates. I have seen people improve in certain ways, but I've never seen a revelation in which a shitty programmer became a key contributer.
If their egos get in the way of effective pair programming (or mentoring - well, hell I think you'll need to be doing rounds and mentoring as well as practicing pair programming as much as possible), then you will need to exercise a bit of leadership skills, and make clear to them that they are partially responsible for the team falling behind and that you all need to work together to get things up to speed. If they still resist, take them aside and explain that they are blocking progress, and you'll have to push that up the management chain.
As for the rest of extreme programming methodology - well, I agree with posters who suggest you might want to try instituting pair programming first, and seeing how that works. If you feel comfortable with that, then instituting the rest of XP for future projects might be a good idea (though I don't know how adaptable some of the methodology is to embedded systems development - it is really geared toward end user app development, IMHO). For other ideas and perspectives check out the book Rapid Development from Microsoft Press (I know, we all hate Microsoft, but there have been some good ideas for software team organization and development methodology to come out of their shop). Plus, it's definitely easier to sell management on organizational ideas from Microsoft than something like XP (though you can certainly find XP success stories out there as well).
Tell them, "It is possible that you might not be able to handle this on your own. Please come to me as quick as possible if you need help." I was placed on a big project. I didn't know how to fail. I failed anyway, and it hurt myself, my department, and the company. So I left in order to save face for myself and my department.
A developer should never assume that their management knows exactly what they're capable of, or what kind of project they aren't (yet) suited to. I didn't know that for myself, and it cost everyone.
I spent several years working in a VERY large organization. Whenever anyone from tech support came around to 'upgrade' my computer, I'd say, "OK, but first, leave 3 fingers from your left hand as security."
If they were new, they'd laugh, and I'd say "Yes, three fingers." They wouldn't quite believe it, but they'd start to get concerned.
After a couple of iterations, I'd get to "How else do you propose to ensure that this 'upgrade' doesn't have negative consequences?" The ones who had no ideas were sent away. Most started to think:
Backup.
Spare parts.
Step by step documentation.
Employers look at this and say "What!? You want to dedicate 10% of our programmers' time to looking at code?" But they miss the point.
With code reviews, people become accountable for their code, and it quickly becomes apparent who is and isn't producing. This motivates people who don't want high visibility as slackers, and makes it easier to prove a case when you approach management about replacing somebody.
Says the RIAA: When you EQ, you're stealing bass!
If you're the project leader, the blame rests squarely on you when your superiors ask you why it's not completed! As such, there are two things you can do to make sure the project is moving along:
Show me three useless programmers....
And I'll show you two testers and an aspiring manager!
Opinions on the Twiddler2 hand-held keyboard?
In infantry units like Recon and SF, they say,"There is no such thing as bad teams, only bad LEADERS!" And these people build teams like most developers can't believe. These guys can finish a sentence that another one started. They aren't just saying that to be gung-ho tough guys. It's true.
I've found that to be true in software as much as anywhere else.
--Stupidity is Self Curing!
I see this from a different angle than basically all of the responses posted here so far: I'm a (what I would consider) mediocre coder, who comes from the domain side, like I suppose the people are you're working with. I know a lot about the domain I'm working on, but have not had enough exposure to Java and coding in general - it comprises about 20-30% of my job, not enough to get _really_ up to speed. However, I'm the first one to admit my need for tutelage.
So, your answer is in the above: Tutor them, implement some of the XP stuff mentioned above (Pair Programming, code reviews, frequent builds, unit tests), and feel free to take over some of their assignements.
Of course, if I misread this and they're just lazy buggers, threaten them with management... and look more often over their shoulders.
Hurricane Application Group, Dept of Meteorology Control, Ministry of Proactive Defense
I agree with your insightful comment. I wish the moderators would mod yours up.
"God is dead." - Frederik Nietzsche
Having been in your situtation, trying to carry everyone elses weight, I've learned a tough lesson. The longer you do their work, the longer you delay the day that everyone gets screwed over. Then, FINALLY, the coders, managers, etc, all learn their lessons. Bite the bullet now, and just stick to your coding. When everyone's asking why the final product isn't done, your bosses will discover a real problem, and they'll do something to fix it. They'll either fire the programmers who didn't pul l their weight, or they'll hire new programmers, or whatever. Either way, with your current team, that terrible day will come. Get it over with now. If you don't, your bosses will continue worrying about other areas of the business, knowing full well that you're constantly maintaining and carrying the weight of a "smaller" problem.
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.
Between an inexperienced developer and an incompetent developer. If it is because they are fresh out of school, but you can see they "got it", that they are brilliant, feed them with all the code and the algorithm etc etc that you can. If they are freshies, and they want to learn, they will grasp things really fast and will learn new concept at an inimaginable speed, becoming productive pretty fast.
If they are just incompetent, ("senior" VB developers who can't even subclass a form or "senior" java developer with "10" years of java coding who have never heard about design patterns for exemple), then you are just in deep sh1t...
I'd rather be sailing...
They'll just telnet to their home linux box and use lynx so it looks like they're coding.
The function worked in a while loop -
while [[ `sed -n '1p' do
taskA
taskB
done
We couldn't share code with the other team, either; the project specified we share information on what our functions did by using a text file to hold all game data and such.
My group of three split up tasks - I would do initial read in of rules, the file format, quitting, and base of the main function. One teammate was to do rule checking, and the last teammate would do the writing to the file. I left comments for them for where to put this code. Unfortunately, they never saw the comments because they didn't touch the file until the very last night, where the submission came in late and we were lucky the professor was a nice guy to accept our ill-begotten submission.
Luckily, the grades were based on perceived effort, and all my RCS logs showed I had put nearly all the effort into this project.
shut up chess buttfucker
Your professor underestimated. On many projects a "just" competant programmer will not succeed in a lifetime.
But your comment is good and I agree with what you say. Rather than "fire the rest" how about simply compensating on the basis of productivity. No productivity - no pay.
It sounds ruthless but I always liked the idea of paying the people that do the work and letting the others find something else to do.
First, become the lead and make it official by the manager. If you are doing teh work, you should at least have the title. Then try the following:
1) Assign each code a section or sections of code to complete. Be sure to explain in detail what that code should involve. Only assign a few sections at a time. Once they complete that section, assign more. Start with simple sections and get progressively more difficult.
2) Encourage questions. Don't be negative, give only compliments. Make sure that they solve thier own problems but check up on them. Don't criticize thier work, but give complements whenever it is rewarded. Give guidance to help them get a good response from you. Don't repeat guidance more than once. They should learn from thier mistakes.
3) If they really blow it, reprimand thier action but not themselves. Tell them why you think they blew and how it impacted you. Then tell reinforce the good points they have. Don't start with reprimands when they first start going.
This concept is based on Pavlov(sp?) Dogs.
1) Give them a clear and easy goal to reach then expand the role.
2) Reward good behavior
3) Punish bad behavior (but don't punish the person, only the behavior)
Also, don't hold them to your own standard, they never'll never catch up to the amount of experience you have while you are working with them.
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.'
I don't think they do. Coding is the process of explaining to a computer something that you already understand.
If you have THREE programmers, presumably with some experience and an understanding of their tools, with NO useful code, then you have a communication problem.
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
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
Obviously they should be promoted to management!
One question: was the writeup in italics actually your presentation of your perceived problem?
If so I would strongly suggest you improve your communication skills. Your description, assuming it was yours was repetitive in content and wording. It appeared as if a single paragraph was sliced and diced then put back together to repeat the very same thoughts in a more muddled fashion than the first pass.
If indeed your post was butchered, you have my apologies; otherwise I strongly suspect you are neither easily approachable nor understandable.
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
The problem I have had is that if one gets the juniors to ask questions, the questions end up being more or less, "can you code this for me so i get credit?" ... the critical thinking process is being sorely neglected in Computer science instruction, i'm afraid.
sir_haxalot
stuff |
I think you pretty much hit it on the head, right there. Management who are not programming literate are all too likely to use a bad metric (such as number of lines of code written) to judge a project.
It's true that a top hacker might produce code at a rate several times faster than Steady Eddie. Far more important, though, is the quality of the code written. A really good guy will probably spend most of his time thinking and experimenting, rather than writing final production code. Only when he's got a rough design that he's pretty sure is workable will he write the code itself. It's quite possible that this production code will actually be shorter than what Steady Eddie would have wound up with, because he's got a cleaner design and implements it efficiently. The good developer's faster rate of production comes from the speed with which he gets to the end point, not the volume of code he produces.
The task before the management team -- who are really the guys responsible if this sort of mess happens -- is to adopt effective metrics for judging the competence of their staff at the various tasks involved in the project. Only after doing so can they redirect their resources to where they are most useful, or if really necessary, take steps to get rid of the incompetents or prima donnas who are genuinely doing more harm than good.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Sustained long hours working is never productive. This has been shown time and again in studies on the subject. Anyone who thinks getting programmers to work 50+ hours per week is going to produce more than the same team doing a comfortable 35-40 is just suffering from wishful thinking. You can flog a dead horse, but it still won't get you there any faster.
And of course, a heavy overtime culture is damaging to everyone in your company, good guys included. I immodestly consider myself an above average developer; I get the jobs done that are asked of me, and I try to do them well. I accept that in this industry, sometimes deadlines happen and a bit of extra effort is needed to make it. I also expect that if I make that extra effort, it will be recognised, and I will be compensated for it. To a point, I don't mind whether this is with shorter hours after the deadline or some sort of reward as a thank-you; it's the principle that counts.
An employer who treats me well will get my loyal service and the best work I can produce every single day. I consider this my professional responsibility, and I take pride in my work. OTOH, the day any employer tries to take advantage of my good will (or force me to act on a contract clause that claims they own my soul) will be the day before my resignation notice prominently hits the desk of the most senior person I can find, with a detailed description of why I am leaving. I have been told by worldly wise fellow employees in the past that I'm just being complacent or arrogant in making such claims. They still work for shitty employers, while I work for a place where the respect is mutual. I think I'm winning.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
i/ Structure the project such that your part clearly depends on deliveries from other people. Ensure it is clear you can not proceed further without the other developer's deliverables. This first part, you *must* do, otherwise who's stupid here?
ii/ Now, only bother with the second part if you are willing to try to lead the team, as opposed to just complaining. The essence of these early stages of leadership is being helpful and understanding. People like to be led by helpful and nice individuals, and resent the opposite. Come to work earlier than others, leave later. Practice the Pair Programming techique. Try to come up with ways of helping people to deliver - daily builds, write interfaces, write simple 'smokescreen' tests that will be run after daily builds. Ask people to sit in on code reviews of your code. Look for tools to simplify the tasks of the group. Encourage, cheer people up, give helpful answers, avoid putting people down.
After some time of practicing leadership, you will see that you are spending A LOT of your time away from your desk, talking to people. You will also see that the team will break down into two groups: those who want the project to succeed, and are willing to work for it, and those who don't. Don't waste your time with the latter group, and focus on the work with the first group.
And, finally, after a year or two of doing this, you can sit down and ask youself: do I really enjoy being a leader? Do I want to go into management, perhaps take some courses in Project Management and People Management? Only at these latter stages do you get to make major decisions. Or do I prefer technical work?
Good luck in your journey!
Programmers are born, not made. People don't like to hear that, but its true.
Do you make them feel stupid or get impatient when they come for help? There's not that many techies out there that are approachable. Big egos and a competitive edge are the faux pas of us nerds.
if you are the lead then you should be doing regular merges of your coworker's code :- a merge tells all - it show them how little work they are producing, and gives you a chance to offer feedback about crusty programming style. You should be in their face offering to help at all times of the day. You should have 100% availability and be ready to drop any of your own work to immediatly help one of your team. You should also monitor if they are getting stuck, if they are stuck for more than 2 hours, *you* move in and help. If you do daily merges they will be very embarrassed to show you that they have written two lines of code in the diffs.
In short, if you can't get work out of your team then *you* are not doing your job properly. If you are not the lead, then your boss is not doing their job properly, in which case you need to tell them so, or leave the company or both.
consider coffee a lubricant that helps one penetrate the coding zone
Have only read a couple dozen posts, but...
Why not just ask them what the problem is? You say they understand the domain problem, because you've had plenty of discussions - maybe they think _you_ understand the domain problem, and are afraid to appear stupid?
So, in 2 weeks they got nothing done. Possible causes:
1. Lazy.
2. Assigned tasks over their heads.
If it was #1, then your management gave you a bunch of losers for the project. If it was #2, your management probably suffers from #1.
Death by management failure. Very common.
I faced same cases before, It is very hard to have all the programmer produce same high quality code. Various quality code will casue trouble when intergation...
:)
Component designing make such life much easier, The major isusses will be solved in design phare -- just defining componets and its interfaces... and then ask those guys pick/be-picked up components they like/assigned.
The beauty of Componet designing are:
1)It does not require every one know the whole the system, most guys only need to deal with simple context (defined by interface). so it is very easy to assign such component to a new guy, or jonior programmer.
2)It provide a lot of flexiblity at intergation pharse, if a component sucks. just replace/rewrite
it.
3)If your boss push you too much, you can assign a compont to him to help
Hope this helps.
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.)
Coosing a balanced team in the first place is crucial
1. Team Leader...controls the bulk of the framework of the code
2. Maths Guru....handles all the abstract programming requirements...sqeezing the most out of every cycle
3. Interface.....handles all the GUI requirements (dialogs, windows, check boxes etc)
4. Project Manager....Ensures everything is on track, plays King Solomon and does all the other things such as communication to outside parties, testing, documentation and feedback.
snester@viewbuild.com
A shrubbery
Unskilled coders are a hard thing to fix quickly (let's face it, what you're looking is an instant extra few years of experience) but motivation is something that can be addressed a bit more quickly.
First off, you need to start coding *less*. This is very difficult when you can see deadlines looming and you know you are the most skilled coder there, but if you want to get more out of the rest of the team, you need to adopt a more managerial style.
This means spend your time planning the work, doing or reviewing design, and breaking the project out into packages of work you can give out to other people.
Hold regular meetings - daily is best, at least weekly. These meetings have two purposes.
It gets embarrassing to say, 'Well actually I haven't done anything' every time, and most people will make an effort to have something to report. If they won't, they're beyond all hope.
Do code reviews, post them to the whole team if you can (don't tear people to shreds) This will help you set project-wide coding standards, and is one of the best ways to mentor people.
Set milestones within the project and make sure you celebrate hitting them! Even if it's just a long lunch and pizza. See your line manager and find out if you can get a budget for that sort of thing.
In my experience any project that recognises work done with a bit of a party now and again gets a whole lot more out of its coders. You need that positive reinforcement.
Over-communicate
By this I mean hold a meeting and discuss your goals/milestones/requirements/etc. Make sure everyone understands them. Then send round a summary in an email to the whole team. Then print it out on a big piece of paper and pin it to the wall during all your meetings. Make sure it's at the fore-front of people's minds all the time.
Hope some of this is useful.
Never trust a man in a blue trench coat, Never drive a car when you're dead
At my old company, the way they motivated poor developers was to make them senior engineers or program managers and then lay off all of the good engineers who now worked under/for them.
Darryl L. Pierce "What do you care what people think, Mr. Feynman?"
OK, well this post is much too late, but possibly the author might find it and read it.
You say you're the "de facto software project team leader". Who is the "de jure" team leader ? Who is meant to be doing the work you're doing ? If you have someone who's meant to be managing the project or providing technical leadership, and they're not doing their job, you need to make sure their boss knows about it. Have a few words with them first about your concerns, and if they don't act, go to their boss. I know it sounds harsh, but I've been in your situation, and it is a hiding to nothing. Noone gives you any credit for doing a job if they don't know about it.
If your place of work is relatively unstructured (as mine now is - I prefer it that way), and noone has an official leadership role, make sure your ultimate boss knows what you are doing. Once again, you don't get any credit for doing a job if noone knows about it. You're an employee (I assume), and ultimately the success or failure of the enterprise isn't your responsibility, although, of course, your job is.
If you're pretty confident that you have the responsibility of sorting out your project, then you really do need to sort out the problems you are having with your cow-orkers. It sounds to me as if they're either lacking in motivation, or not very good coders.
There's a judgement call to be made here as to whether these people are redeemable. They might not be. Some people just aren't up to programming, others require so much effort to train up that it is not worth the investment, others are unmotivated, due to personal problems, in such a way that you can't help. The only answer is to let such people go. This is why you need to be in a position of authority acknowledged by your boss. I don't necessarily mean that they need to be hurled bodily from the doors, but they need to be moved to work that they're capable of doing. When it comes to hiring new people, make sure you're involved in the process.
However, the only way you're going to find out whether your cow-orkers are redeemable, is by trying to help. If at the end of that process you,ve acheived nothing, then proceed as above. In order to help, I'd suggest some or all of the following:
1. Make sure people are motivated. They need to know what your project does for the company. They need to know what they, personally, can expect to gain from success. If - as is common is technical organisations - there's not real career progression opem, you might want to try to fix that.
2. Make sure they know what is required. That is: what must be delivered and when. They should feel that it is a team goal, and that it is acheivable. They should feel personally responsible for their bits.
3. Track what people are doing, on a day-to-day basis. Go from desk to desk and ask. Help with problems. If people have gaps in their knowledge or misunderstandings, talk them through it, rather than just telling them answers. If there are problesm with the rest of the organisation, try to sort them out.
4. Institute code reviews or pair programming. Make sure you are involved, but encourage them to critique one another's work and improve on it.
5. Change the way you're scheduling work to make tracking easier. Expect people to deliver demostrable units of functionality every at least week or so.
6. Never lose your temper or act in a condescending manner.
It's possible that your design or execution of your part of the program makes it difficult to write the others. Not for you, since you know all the tricks and hidden invariants of your code, but for others, who don't understand what you're doing. The key to successful team programming is carefully defining modules and interfaces between them such that they can be implemented with minimal interaction and understanding of the other programmer's code.
Anyway, I am probably just guilty of giving the benefit of the doubt to your co-workers, but don't overlook the fact that your personal code output is not the only measure of how good you are for the project.
If you need a quick fix, I suggest taking a few hours with each other team member and getting them started on their code in a pair. Programming in pairs (the best idea in 'XP') is pretty good, and it usually results in high knowledge transfer and low bugs.
Your project is doomed. Start looking for another job. Seriously, unless you want to code the whole project which to me sounds like what you will be doing.
Life is to short to be doing other peoples coding.
And what wonderful accounting scheme do you have that can tell when 10KLOC can be more profitable 10 years later than another 20KLOC?
Management can't even evaluate people, let alone code.
--
Marc A. Lepage
Software Developer
And sit back and relax at your current one in the mean time. Y'all are screwed, and when the project doesn't get done it's doubtful you're going to be spared.
other guys didn't want to do their work, or share information with me that I needed to finish mine. I got fired, they still have their jobs.
Actually, 90 percent of the programmers haven't experienced the problem of being in the 10 percent who do most of the work. They have, by definition, been in the 90 percent who do 10 percent of the work.
Eternal vigilance only works if you look in every direction.
Only thing I would add is the use of code reviews, first as a teaching tool (review the better coders' work first), then to improve the lesser coders quality after they've gotten accustomed to the review process.
Another advantage of code reviews you missed which is very relevant here: it lets everyone know how much progress is being made by other developers. If developers are falling behind, it becomes blatantly obvious...
Being a good programmer does not make you a good manager. In fact, nine times outta ten, you're a bad manager. I would spend a little time looking into some basic managerial skills. Off the top of my head: .maybe a pat on the back. Don't just always say negative things. Don't say negative things to one employee about another. This might create . . .
Don't focus on your co-workers weaknesses, but rather their strengths. They were hired for some skill set.
Motivation - learn how to reward employees . . . not just monetary rewards . .
Mistrust - Trust is essential in any relationship . . . and that doesn't exclude a boss and his employees. You need to trust your employees and your employees need to trust you.
Empower - make your co-workers feel as if its their project and their ass if it doesn't get done on time. Then, don't micromanage, but rather, keep everyone informed on the process of the project . . . maybe weekly. Which bring us to . . .
Communication - your employees need to feel that your door is always open for anything. That means . . . LISTEN. You don't have to necessarily agree, but at least act like you're listening and considering someone's else's opinion fairly. Explain your side . . . objectively.
Again, try looking at some management resources, or attending a training class because the entire scope of being a good manager cannot possibly be included in one email.
Good Luck!!!
Hello. I'm an intermediate level programmer who doesn't do much anymore. I'm not alone in my organization either.
I've always needed some external motivation to move me along. The thing that motivates me most of all is a sense of community which just so happens to be seriously lacking in my current place of employment. What once was a realm of creative collaboration with mentoring and open design processes is now a place of closed doors and heads down coding. The most senior programmers now do all the design work, and leave little else besides typing for the rest of us. They carve up the projects how they see fit and don't share the birds eye view that is hatched behind those closed doors. They want the rest of us to type the code, document it, and test it. In short all the rest of us have become coder bees.
Sure, I could work hard and over the years prove myself worthy of getting better scraps and hope to join their elite ranks or that things will change back to the way they were. But for some reason it's so much easier to do the bare minimum, let them sweat the deadline, and at the last moment cranking out some code that meets the specs.
If you're coworkers are anything like me there's really not much you can do to motivate them, except maybe get them involved in the whole process. Who wants to work hard in a place that develops a caste system and treats them like unimportant or even non-members? So until I find my next gig, I'm all for coasting and driving my lead crazy.
it's difficult problem.
but basic bottom line is,
if they have desire to do something,
trust them and give them some works even though they are not
much experienced.
if they don't,
fire them.
Or even mediocre managers ? The "team lead" role is the worst position to be in - you have a whole load of resposibility, and almost no authority.
I'm guessing you haven't got the authority to fire your team (and I don't think it's the right solution anyway), hire more team members (ditto), change the scope of the project (this is more likely to yield results), or change the way you're working (bingo ! give the man a cigar !). You can't exert much formal control over the team, and you have to be careful with running to the senior management team, because they usually don't like to hear bad news.
So, I would suggest that you get the team together to do a semi-formal project assessment, compare actual to plan, that sort of thing. If things are as bad as you say they are, the team will likely recognize this; you can then declare an official "state of emergency" - note that you should do this without involving the managers at this stage. Suggest that you all spend a couple of hours brainstorming ways to get the project back on track.
Sneakily, look into eXtreme Programming and / or Scrum - there are a couple of easily digest books available on both methodologies from your favourite patent owner.
I would suggest that in the brainstorm meeting, you steer the discussion towards ensuring progress visibility is the key priority. If the project is in trouble, you need to know how badly, what the backlog is, and what your current estimated delivery date is - it's the only way to measure your progress. This can be as simple as a spreadsheet on a file server with tasks and status (hint : accept only binary completeness indicators - otherwise you end up with lots of projects at "90% complete" status which turns out to be 30%. A task is complete or incomplete - final).
I would also suggest revisiting the original plan. I have found that it is usually better to allow people to make their own estimates and prioritisations, so ask everyone to adjust the estimates and dependencies, see where you're at - if you're gonna slip, find out today, rather than 2 days before shipping.
Next, you might want to discuss introducing iterations, ie complete, running, shippable software implementing one or more new features into the product. I've never worked on embedded products, so this may not work in your environment, but it really helps to improve the visibility of your progress when you know that you'll be delivering a complete application every 4 weeks or so. If you promise management/the customer/your mom to do a demo, it helps even more. It also ensures you don't have any last minute bugs to deal with on shipping day.
Work out - with the team - what you're going to do, and then do it. Don't tell anyone until you know it's gonna work. Make sure you stick with the changes, and enforce them. Review the situation after a week or 2; tune, repeat. If you find you're in such deep trouble you can't see a way to fix it, tell your boss the moment you know for certain you can't recover.
There are no magic bullets; stuff I can pretty much guarantee won't work are adding more people to the project (except if you have an exceptionally well-defined design and a lot of repetitive drudge-work to do). Bullying people and threatening to fire them is a surefire way to get them to spend their time honeing their curriculum vitae and surfing the job sites. Stuff that usually helps but may not be enough is improving visibility of project status, increasing the level of detail in the plan to binary 1-3 day tasks, and increasing the team's level of ownership of the plan.
Welcome to management. Coding's more fun.
It's all very well in practice, but it will never work in theory.