How do you deal with bad programmers?

Question

I kind of lead a team of 10 here at one of the services companies. Being a lead developer, I have been asked to mentor this team that consists of individuals who are programmers but are kind of misfits. It's a mix of pl/sql, java script, html, java, python developers for a project to be developed in Java. Now, if you know the big picture of the outsourcing market, you will quickly realize what I am talking about. I see a set of problems:

1. People with relatively no experience in java - just have their basics right.
2. People who know nothing about objects - can't think in an OO way while approaching any problem.
3. People who have experience in java, but still don't understand what it takes to write good code.
4. People who have that spark, but don't have the right attitude to work.

How would you deal with such a bunch? For someone like me whose passion is all about objects and their design, delivering a project with this kind of team sounds scary. Have you had similar experiences? How have you dealt with 'em?

Answer 1

a mix of pl/sql, java script, html, java, python developers

These are not developers. Just scripters. That's how my previous manager liked to call them. I agree with him.

1, 2, 3: Will take months/years for them to get knowledge/experience to become ready to work for a large scale project and produce quality results.

4: Your real option if you find and will be able to provide the motivator.

Try to estimate whether these people have the ability to finish the project at hand. If you believe in them, you can try to work and mentor them.

If right now you are not sure about them and you feel like you have to invest time in their education before you can see whether they have the potential, then it is probably not worth it.

Now the best part: Ask to be paid per hour for mentoring them.

Answer 2

Although there are lots of issues here, including how you properly mentor people, how to deal with people who arent' really skilled and aren't likely to be, it seems to me that you have a bigger problem, which is that you have to deal with the whole range of such issues while building a deliverable. That you're probably ultimately responsible for.

I've made the mistake in situations like this of not being aggressive enough. Given what you've said, I'd suggest outlining an ironclad architecure, build setup, and code guidelines. Set very clear goals and guidelines for people, and take some time at the start of the project to make sure everyone understands them clearly. They'll also need to be monitored carefully, you may even find that you're doing significantly more monitoring than coding.

If there's any mentoring or educating to be done in a project like this, it has to happen in the context of a well-understood and shared structure.

I generally don't like to be a cop, but sometimes even that's the appropriate thing.

A personal experience: I was once hired to be a lead on a (long-running) project. As it turned out, many of the developers were fairly bad. Rather than trying to get control, I tried to just suggest better alternatives, make better tools available, i.e. characteristics of places I'd liked to work at. For the most part, however, people did whatever they were used to , management did not support bringing in newfangled tools (like source code control - we're not talking exotic here),and did things like hire people fresh out of school, told them to develop pages without informing me or the rest of the team. Also would agree to changes with the client, and set those up with one developer without telling anyone else. Gave us a nice mix of technologies and strategies in the final project-it was a wonder the damn thing even started, and the company eventually got sued. It might've worked if I'd been more aggressive in enforcing guidelines and authority, or at least helped (then again, it might've been ignored anyway).

Good luck, hope you do better than I did.

Answer 3

Try and keep them focused on their programming tasks. It can be very easy for people to begin to "wander" if they're not familiar with the language and get sidetracked.

LOTS of code review. Let them review your code as well and point as many helpful OO/Java techniques that you can think of.

Also, try and get a good grasp of the coding skill level of each of the developers. Use pair programming to balance out the ability so hopefully they can bring each other up to speed.

Answer 4

Lots of code reviews. Lots.

Answer 5

This question is probably going to get closed...smells like a dup.

However I would suggest you make use of training to fix the issues with knowledge. "Code Complete" is a good book to fix some conceptual issues. However I'd be concerned about the culture of your organization if people that have such deficiencies were able to make it through the door in the first place. Your problems may be more cultural than a personel issue. If so I'd suggest you salvage the best members of your team and bring in talent in you own "image" of what a good programmer needs to be for your team. Make clear what that programmer profile looks like and if the existing team refuses to come around you'll know exactly where to begin upgrading. Also there are a couple of StackOverflow podcast that address this very issue. Might be worth a listen.

Answer 6

If possible, pair programming may be useful in this situation. That way you can easily illustrate what you're expecting, and be able to more easily explain some of the trickier concepts.

Answer 7

Yes I have had similar experiences. However, I didn't have a team of mis-fits as much as a team that just didn't know how to do things "the right way" (subjective term here...careful).

So the best way for the lead to handle this sort of scenario is to do the following:

1. Write down your standards (naming conventions, follow SOLID principles, DRY, DDD, TDD, etc.) and then express them to the team in a binding way (email, network share, department memo, etc.) and reference them often as you find discrepancies. This is a live document and is ok to change over time!
2. Do code reviews as a team initially so that everyone can see what right and wrong is...and who is doing what. This usually will get your bad-apples in line or at least share with the team who they are which will build up your peer pressure. Then everyone will be aiming to squash the problem.
3. Invest some time in pair programming. This is where you have a senior guy site with a junior guy or with two people that have dis-similar skill sets. This will allow the whole team to come together and raise the overall skill level to something semi-equal across the board.
4. Invest some time into an automated build process and preferably a continuous integration system. The best scenario here is for a real time build and integration process per each check in. Among other things the build process will send out a status email with various build logs and whether the build passed or failed. People don't like to be associated with a build that has failed and the team will chide people that do it often. The rule that I have followed that usually works is "whoever breaks the build has to bring in bagels the next morning". Then you can have a tool such as CCTray or other real time red-light green-light monitoring tool that tells everyone the status of the build.

Answer 8

For me, it depends entirely on the nature and criticality of the project. If this is a critical project that needs to be very high quailty I would make the case to management that the wrong people are assigned and you need different resources.

Assuming that isn't the case the first thing you need to be prepared to do as a person in a leadership/management role is to accept the fact that your resources may not do the work the same as or as well as you. It is a mindset thing but if you can't get over it, you just might go crazy.

If they are inexperienced in OO development throwning them into design work would be a bit rough. Be the chief architect - make the fundamental architectural & design decisions, draw up the design documents, create the standards, etc. Make sure that you do design reviews ... let them review your work, ask questions, etc. it is a great way for them to learn something.

Assign the programming/implementation tasks - let them do the mechanics. Hold code reviews (formal or informal, whatever works), critique their work ... kindly, so they can learn something, but still enforce the design/standards/etc. ... let them critique each others work. Again, expect that they will make mistakes or that they won't do it the same as you. It's okay (assuming you aren't working on a project where safety is an issue).

If the quality and efficiency of their work is affecting the project make sure that you regularly communicate this to management ... clearly.

Answer 9

With all due respect, the situation your describe isn't limited to service shops, it's endemic to the industry. The quality of the people (in terms of skill set) that one has to work with varies greatly. I think to deal with this you need a mixture of people skills and discipline. To learn how to manage people, I really enjoyed Managing Humans, which was written by an engineer who got promoted to a team lead. In terms of developing good "software engineering" practices, I found Release it! quite useful. It distills years of knowledge almost into a recipe-like approach.

HTH.

Answer 10

The test of a true mentor isn't in what he started with. It is in what he is able to do with what he has.

A mentor is a trusted friend, counselor or teacher, usually a more experienced person.

Obviously you have your job cut out for you and you have a choice to make. You can focus entirely on the project while ignoring your prescribed role, which will lead to complete loss of respect for you and, ultimately, a failed project.

Or, you can take the role on with gusto. Be a team leader. Keep things fun and interesting. Hold weekly code reviews with POSITIVE comments and encouragement. Be willing to sit with each of them as they grow. Basically, be an example and treat them with respect.

Failure is the only option if you start down the path of tearing everything apart, while complaining loudly about your team.

Answer 11

To get them up to speed, you might want to do a few weeks of very short iterations. At the end of each day, evaluate the day, plan the next day. Teach them pair programming, test-driven development. Every line of code, you review. Explain refactoring, and let them improve their designs (slowly, step by step).

Make sure you have an automated build, and choose an appropriate architecture and frameworks to use.

Answer 12

Got Some intresting reactions here:

http://stackoverflow.com/questions/1044590/most-professional-way-to-tell-a-developer-they-are-no-good

Answer 13

A team of 10 inexperienced developers sounds like too much. Hate to say it but I'd consider canning groups 3 and 4. At least 1 and 2 are valid excuses.

Answer 14

Improving the skills of a coworker is very difficult, especially if they think that they're already good enough. You should think about the extent to which you want to surround yourself with good programmers, and then think about how you can create the environment you want. Here some options that you can explore:

• Code Review - Simply the idea of code review can inspire programmers to clean up messes, and can provide concrete examples that can be used in teaching. This is the most obvious thing to do, and likely the best idea in the list.
• Pair Programming - Pair a weaker programmer with a stronger one on a project, and explicitly tell them that what you want them both to learn from working together. This is dependent on the people you have, but can work very well if you have the right mix of personnel.
• Personnel Decisions - Some people have no desire to learn, and others are so obsessed with the idea of self-improvement that they hang out on websites dedicated to programming outside of working hours. It may be that you need to hire some new people and fire some of the weaker programmers, because sometimes people just don't change. You might not have the resources or authority to do this, but it's also an effective way to improve the state of programming around you. If you get really frustrated, you might think about finding a job with more skilled people around you.
• Reading Lists - I've learned a lot from a more senior developer who sends me articles that he finds interesting, and sometimes we discuss the articles over coffee. It's a nice way to learn. Unfortunately, for this to work people have to want to improve and the type of people who would enjoy such a thing are likely doing it already, so this is far from a silver bullet.

Answer 15

G'day,

Actually, it seems like you've got quite a few problems including your situation, and I hate to say it directly, maybe your attitude too.

"Bad programmers" just because they're not Javaheads?

Anyway, can you please define "kind of lead"?

Are you:

1. a self appointed lead,
2. an appointed lead without a clear mandate as to what you can and can't do,
3. your appointment is without the direct, publicised backing of management, and/or
4. you have been thrown into a lead position irrespective of your own wishes.

The answer to this really changes the dynamic of your position.

One thing I would suggest is, if you're interested in reading further on how to inherit teams, you buy a copy of Richard Whitehead's excellent book "Leading a Software Development Team: A Developer's Guide to Successfully Leading People & Projects" (sanitised Amazon link) Highly recommended! (-:

After being (successfully) thrown into similar situations several times, let me digest your question further and I'll update my post a bit later.

Edit: One thing you do have as a massive advantage is a bunch of people with disparate experience which means that you won't all be approaching problems from the same perspective.

You'll probably finish up with some excellent "out of left field" solutions that you wouldn't have got if everyone was "a Java girl/boy" with the same experience! (-:

cheers,

Answer 16

To really pull a "dirty dozen" story off here, you need to be a leader, in a personality sense. You have to be the Go-To guy, the Old Man. They have to respect you and want to follow you, which means that you then can take them to Hacking the Good Hack.

The art of leadership/management is very difficult. Please realize that. :-)

Now, some pragmatic suggestions...

1) Get some readable design books. Code Complete. Mythical Man-Month. And their compatriots.

2) Get some perks assigned to the team. Coffee; tea; milk; soda, etc. Donuts for meetings/Mondays. People love free food. And the hand that feeds them gets some of that love.

3) Listen to them. Really, really, listen to them. Understand them as human beings trying to make a living, and try to help them understand that if they improve, they can make a better living.

4) Believe in them, too. I've been in more dysfunctional social clubs trying to get stuff done than I can remember, and the tendency for failing groups is to have the leadership go all Drill Sargent on them, which will certainly cause an adverse reaction. Drill Sargents have a place; it's probably not in a non-military environment.

It would also help if you had fire-power over them, so if they insisted on not improving/working with the team, they could be let go.

edit: Also, object-oriented/Java is not The One True Way of coding. You should remember that.

Answer 17

I think your biggest problem is the group 4. Basically, if they don't care about their job, they don't need it. Get rid of the laziest ones if you can, firing 1 or 2 people would probably improve the attitude of the rest but they must understand why these guys have been canned. Tolerating people who are lazy and ignore their job duties demoralizes the whole group.

I wouldn't worry about 1. much. Java is easy to learn. Get them some books about Java, or at least point them to http://www.mindview.net/Books/TIJ/

You can teach them the basics of OO relatively quickly. The difficult part of OO is the design. You will have to sit with them and hold their hands or present them with a ready-made design, in very clear and strict form (specs with class diagrams). As they progress, they will need your help less and less. I would try very hard to get at least one more competent person in the group and appoint them a mentor to share the load with you. It would be very good if this person was actually smarter than you. You will have to do a lot of designing for the little ones and having another person at least at your level will do you good.

Group 3. can be a problem, if somebody's dumb there is little you can do about it. See my advice about 4.

Answer 18

10 poor programmers under 1 lead sounds like a problem in corporate structure or hiring practices to me. All other answers have covered most how to train inexperienced programmers. If your issue is truly "bad programmers" or "bad employees". Fire them, I know it sounds harsh but this is an employers market, work with HR on hiring practices to improve the quality of the people you get.

Answer 19

These are my two cents. First of all, I am assuming that you have a requirements document. I don't want to start a debate about documentation in software project management, but I think a Requirements Document is a great helper. If the SRS was given, then you need to review it line by line with your team.

• Assign use cases to developers so they have to study them and present them to other team members. These people will be like "Use Case(s) owner". If you want develoeprs to have accountability, then they also should have ownership. In this way developers will start to understanding the team idea and will feel like something depends strictly on them.
• Each Use Case owner will provide a view on how he/she will probably implement each Use Case based on whatever technology you choose. In this way you will start the debate of ideas between team members. (Be aware that nobody have written a single line of code at this point).

MOST IMPORTANT

• Set the pace
• Get yourself some simple Use Cases, analyzed them and provide your view on how you think they could be implemented and open the floor for suggestions. Don't discourage comments, and no idea its dumb. If you are a good lead, you should be able to handle these sections pretty good.
• Be the first to implement your UCs and be the first to do the Code Review, Unit Tests, etc. Yout should have to set the standards. Everybody will now have a bar to reach.

Monitor, Monitor, Monitor

• Set short meetings (no more than 15 minutes long) each two days and ask developers how they are. If it is a lazy developer you will notice it right away. In these meetings you should not discuss implementation issues, that will only be discussed with the interested parties. Use these sections for risks indetification only.
• All tasks should be done on a timely manner, good developers could do a lot of work in no time, others are slower. You should identify each of them (and I think you already area) and give tasks accordingly.

Answer 20

Not an enviable position to be in, but you are not alone. Corporate IT shops are filled with situations just like yours. There's no easy answer, but you of course have to get some work done. Possibilities:

• Use the truth. As someone else mentioned, don't fall prey to trying to cover up the situation to managers and project managers. Tell the truth about the situation. If they care, they'll help you change the situation by restaffing. If they don't, or if they're the type that can't hack the truth, then they'll drop you or you'll know you're in the wrong place; either way, you might end up leaving.
• If you end up staying and have to work with what you have, I can't fault many of the previous suggestions: standards, code reviews, pair programming, monitoring etc. Those will help some, but I think your problem, as another poster noted, isn't just with inexperienced programmers, it's also with experienced bad programmers who don't want to change. In this case, I would look at two things:

1) If you have time, do a good job with the requirements and technical specifications. I have used detailed tech docs to serve almost as instruction manuals on what objects and methods are needed for a task. I have used this technique before and once things were set up, it greatly aided my ability to execute by enabling me to delegate some tasks to less experienced developers. Delegate is a key word here; you will burn out if you try to do everything yourself; but guidance through the specifications, assuming the developers adhere reasonably well to it, is one way to leverage your vision.

PROS: You are setting the direction for the structure of the code. The internals of what a lesser coder delivers might still be ugly, but it's compartmentalized ugly, which will make future refactoring (probably by you) significantly more accessible. Combining this with code reviews will help.

CONS: This takes time, and lots of it, since you are going to have to be the writer of all this instruction, and of course time is usually a constrained resource. That, and of course that most developers don't like writing documentation. People might criticise this approach as too manual, or too much like waterfall, or doesn't respect the developer's initiative, or whatever, but more advanced methodologies require a more advanced class of developer, and it sounds like you're short on those.

2) Application partitioning and project management. If you can, try and move the resources to places where you can take advantage of any skills they do have. For example, you mention some PL/SQL knowledge. In a database application, certainly there will be some back-end needs? Move people where they can work best, and vice versa: structure the application so that some of the logic is centralized in stored procedures. Let your javascript, html, and python guys work on the front end. The web kids on the site here will give me flak for suggesting logic in the PL/SQL, but whether it's in an application server object or a database server object, I think we ultimately agree that centralization of logic is compatible with DRY principles and forms a more workable foundation for support and refactoring, of which it appears there will be much need. Careful distribution of tasks also lets you give tasks that need more initiative to the better developers and the better defined, less fungible items to those that need stricter direction.

---

Just as a good developer can salvage some of a poorly managed project with weak business requirements, a bad developer can compromise a well managed project with good business requirements. So, your project sounds like it's going to deliver an app that's got plenty of logic spread disparately through GUI objects and lots of quirky scripting and poor error handling...in other words: the average corporate app! But if you can't deliver a world-class app, with some effort you can try to prevent total disaster.

It is tough when you are the only one on the team with a passion for quality, but the best you can do is explain your position. If you're lucky, one or two will catch on and join the cause. If you're unlucky, all of them will ignite and you'll have a team of prima donnas that only want to do design and won't do support. But seriously, you'll probably end up with the typical corporate app. If you're getting paid well, then remember that it could be worse.

Answer 21

Ideally, they wouldn't have been hired in the first place. Great software companies don't hire people who don't know OO to write OO code.

But you're beyond that point. What you've got to do is take a band of random people and get them to do passable specialized work. This is hard, though not impossible, but I wouldn't look to SO for answers, because it's not a technical problem. It's a social problem, and not at all unique to programming.

I'd probably go hunt down my old orchestra conductor for advice. Musicians (and probably other artists) are great at this because (1) there are a zillion types of music so chances are decent there's somebody who doesn't know the first thing about your style, (2) there's a fixed date when it (something) has to be ready. (You've got 10 musicians who play only jazz and latin music, and you've got to perform a Brandenburg in 2 months. What do you do?)

Answer 22

I'm coming into this late, so I'll try to be brief and not repeat what has already been said.

In a normal shop, there is a variety of skill and experience levels, and this is a good thing. The problem is rarely that a particular developer writes bad code, but rather that bad code is allowed into production. After all, it is the job of the lead to use reviews, standards and all the other methods that have been mentioned here to ensure that the quality of the product is not determined by the weakest skill of the weakest programmer.

The key is to make lemonade out of the lemons you're given. Less skilled programmers can be inspired to sharpen their skills and less experienced programmers thrive on new experiences. Find a role for each person that allows them to contribute and grow, instead of complaining that everyone else but you sucks. Yes, sometimes there's a truly bad apple that needs to be pruned, but you can only know this after you've exhausted your other options.

I could rant on forever, but I think I've said what I need to.