I always loved this article on JoelOnSoftware called "Getting Things Done When You're Only a Grunt" . I could especially relate when I was newbie (and still feel like I will ALWAYS be one).

About #4, neutralizing the bozo's. What advice do you have for actually implementing this in real situations at work? It doesn't seem to be as easy (at least on our team) as simply logging a bug against someone's bad code. What works for all the rest of you out there?

  • 1
    Guns. Lots of them. Commented May 8, 2014 at 16:39

2 Answers 2


Permanent evaluation.

Just at the end of each day spend 30 minutes to review what they've written. If they've done something wrong, make them rewrite it.

Unless you do this, one day you'll realize that a part of your application, while seemingly being capable to do the job, is totally unmaintainable, engineered improperly, and will cause a lot of problems in the future—or even tomorrow.

Even if it will make they less productive, it will still be much better if they produced some good code against twice more in size but unmaintainable bloat of bugs.

  • 2
    Great answer. If I can just append to that, if this person is a peer, then it is best done by the team leader. That way the its-not-good-do-it-again response would be much more effective if commanded by the shop's hierarchy.
    – user29981
    Commented Jul 5, 2011 at 22:43
  • 1
    @Surfer, it's exactly the opposite. You become a team leader by doing things like this, by proposing better solutions, by caring what the team does. Not vice versa. (But, of course, getting aid from higher hierarchy levels helps).
    – P Shved
    Commented Jul 5, 2011 at 22:47
  • 1
    So the question becomes, who has the authority to make them rewrite it? I guess answer is, the moral authority of the entire team, if the problems are broadcast to the entire team.
    – C.J.
    Commented Jul 5, 2011 at 22:52
  • In the absence of a robust code review mechanism for every team member this is appropriate. It is also appropriate to ensure the bozo does not dig a really deep hole (even not worth the cost of fixing) before being told to rework it.
    – mattnz
    Commented Jul 5, 2011 at 23:10

If the person just doesn't know any better, but wants to learn, provide some mentorship and code review. Make sure they are exposed to good code.

The really poor developers are those who are set in bad ways and fight learning anything new. Your only hope is to let them suffer through maintaining their own mess or some of the more simple stuff. Ideally, someone in authority stands up and says conform or leave.

  • 1
    The attitude really counts. I usually find newbie's more humble, and open to code reviews and criticism. These people are easy to talk to. And you can easily talk to them about their weakness's. It's the arrogant veterans, who will shatter like a million pieces of glass when they are criticized over their work.
    – C.J.
    Commented Jul 6, 2011 at 17:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.