Why Not Just Fire All Of Your Programmers? 14
Then no software would get written, but at least we wouldn't have any crap software...
My friend Jay posted two blog entries yesterday on the subject of raising the standard for programmers in our industry. I left a comment about it on his blog and talked with him about it on IM, but I figured I'd expand a bit on my thoughts on it here.
First things first, I completely disagree with him.
I don't think that 50% of programmers should leave the profession. I've worked on a lot of projects with a lot of different teams and I can't ever remember thinking "man, this project would be a lot easier if I got rid of half of this team."
I can also only think of few Net Negative Producing Programmers that I've worked with and most of them usually leave pretty quickly.
Most of the time, I've found that when a person isn't performing up to par, it's because of a management failure. I think that it's up to the development leads to analyze their teams and figure out how everyone can best contribute and make sure that people are performing at the top of their game.
Too often I've seen people fall into the trap of always being assigned to, or always choosing to work on, the easiest features in the project. They then do a half-assed job because they're always working on the boring part of the project and don't feel like a valued part of the team.
Maybe, for a change, we should assign those people the hardest part of the project for a few weeks. Sure, they might not so the best job, but they will work harder because, for once, what they're working on is challenging and exciting. Plus they know that the entire team is depending on them and is there to help them. That's how you bring people back into the fold and make them a productive, happy member of the team.
The point that's neglected in Jay's arguments is that experienced programmers shouldn't just be responsible for writing code. It should also be the job of experienced programmers to take those who are less experienced or interested and pull them up to our level.
Forcing them out of the profession is just as much of a failure on our part as it is on theirs.
Well said!
I disagree with your proposed solution to unmotivated/underperforming employees, as it kind of implies a waterfall top-down method of software development.
I've worked in a few different companies over the span of my career, each with fairly different styles and "managerial" flow. One company was 100% sales driven - to such an extent that my day literally consisted of me talking to our sales reps (who by chance were the president, ceo, and owners) and implementing feature x in a matter of y days so that we could secure client z. Yea, that company isn't around anymore, to say the least.
In a couple other companies it was very team focused, but assignments were handed down by a project lead. There were a lot of assignments as the product was growing at a break neck pace, and there were a lot of areas within the software that you could chose to work in. But the smaller, more granular tasks within each area were dolled out by higher ups.
The new company is nothing like the others. we're practicing SCRUM, and we're trying to adhere to it as strictly as possible. We have 30 day cycles. At the start of each cycle the entire team gets together and goes over all the issues that we've logged in our issue tracking software. We start saying what goes into the new iteration, and what gets postponed to a later iteration. After that we all pick what we want to do and assign those issues to ourselves.
The result has been an incredibly self motivated team. Everybody is empowered to carve out their little nook in the product, and as a result we have no motivational concerns; our velocity is through the roof.
I do agree with you, however, when you talk about how the more senior developers should be held accountable for the distribution of knowledge. I'd take that 1 step further and say that ALL developers, not just the senior ones, should be responsible for distributing knowledge. There's a metric tonne of stuff kids coming out of school today know that I don't, and vice versa. The question is, of course, HOW do you spread that knowledge. The absolute best way I've experienced, so far, in spreading technical knowledge, is code reviews. You fix a bug? The issue isn't closed until at least 1 other developer has reviewed it. Feature complete? Not if it hasn't been code reviewed. Etc.
Good post. You made me think and illicited a response, and for that I thank you.
I disagree with "It should also be the job of experienced programmers to take those who are less experienced or interested and pull them up to our level." because that is what a Project/Team Manager should do.
Experienced programmers are not tutor/consultant unless are hired to do so. Managers are responsible to make his team work and programmers are for make things work.
Yeah, I think it is important to make a distinction between experienced programmers and passionate programmers, that way you can qualify experienced passionate programmers, as those are the types that are best suited to mentor less-experienced but equally passionate programmers.
Disagree on the management fault part - I am a lead, and tried assigning complex projects to one of my guys who is not performing, guess what happened? Management can only do so much, motivation has to come from the developer and if there is no motivation then no manager can change that
Well said mate. just assign the super boring programmer to the hardest job. sure they will get back to their performance.
well, I am a really bad programmer and therefore I agree!
I agree! Its not easy for the management to see if people perform good or bad acutally! Because that would require switching implementing positions regulary! I n that case the management is highly responsible, sadly in reality many programmers just miss that part because they have to do soemthing they are "good" at.
Hopefully I'm not off base with my comments, but this topic has struck a rather raw nerve with me.
I'm currently on a team struggling with the burden of an underperformer. An individual who has been referred to as a cancer by other team members. An individual who continuously abuses the knowledge of his teammates for his own personal gain. We've even had other team members quit and cite Mr. Cancer as a contributing factor to their decision. The job of a project lead (if given enough authority) or other manager is to recognize that there is a problem, attempt to solve it diplomatically, but learn when to cut the cancer out and hire someone else. Team morale is at stake if management fails to listen and recognize a bad seed. The gig's up once you're team has lost trust in your managing capacity.
Most programmers are willing to assist others, some only if asked, others more proactively. But if your knowledge base programmers detect they are being abused by an underperformer who is either unable or unwilling to utilize knowledge gained as part of the team, then it absolutely is management's job to eventually nix that individual to help bring the team back into balance. Otherwise you are just going to continue growing discontent within the team until you lose the ones doing the real work and all you are left with is Mr. Cancer.
I believe the blame should lie solely upon the experienced developers. I think top-down knowledge transfer is crucial to the success of any team, and there's a simple means of accomplishing that goal. It's called pair-programming.
I've only been doing software development for a few short years now, but the times from which I gained the most were when I was working with knowledgable, experienced developers who were willing to sit down and knock out some code with me. Even of there as no code written, just sitting down and explaining the why's and how's of some particular area helped me tremendously.
I can read books and blogs all day, but what really works for me is a little one on one with someone who's been around the block.
I've only once had a manager/lead who could give me that.
Rather that assign them to the harderst part of the project, I rather give them the opportunity in a management role so they can experience the difficult decisions that have to be made between business goals and development process.
Regards,
It's a fallacy that everyone has the same motivation. I.e. give them a hard job and they 'magically' gain the motivation to become 'better'. It's not the job of the more experienced developers to develop everyone junior to them either; though knowledge transfer should exist in one way or another.
A manager's job would be to develop his/her team. If that means providing formal training, technical books, pair-programming, etc it is up to the manager to understand the person's motivation and provide an environment that is conducive for them to get productive.
Just MHO, of course
What you say implies that companies are interested in creating highly skilled employees. If they did that, then they'd have to pay them differentially depending on their skill level. Some people might become very skilled, and be worth a lot more than other people. That's called permitting a market for talent to evolve.
If you let a market for talent evolve, then companies become a hostage to that talent. It's what my IT Management instructor told us the first day of class- when you take over a department, the first thing you do is seek out that one developer that the company absolutely positively cannot function without, and you fire him (or her).
Companies are not going to be held hostage to talent- period. What they want are development schedules, project scopes and cycles that are predicated on the idea of the interchangeable programmer. An IT burger flipper, operating in a McDonald's -style business plan.
If you want to see where the market for talent goes, look at sports and Hollywood. Multi-million dollar salaries with "superstars". That's not going to be permitted to happen at the worker level. That's reserved for management only- CEOS CTOs etc.
No, we don't have an apprentice / master tradition in our industry- that's by design. We've agreed, through a kind social signaling that no one is ever going to be able to come after us with a RICO suit for, to only create products and services that can be created by 1st through 4th year programmers. Beyond that, it's to worth it to us in the long run.
We need to keep the talent level down, and we need to agree not to compete on talent, or it's the programmers who are going to earn the real money, not management.
Get with the program.
tsk tsk tsk I see that you don't permit opinions other than those you yourself hold to be voiced. ... nothing like having a little kingdom to bring out the autocrat in the everyday man.