Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 8 down vote favorite
3

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?

share|improve this question

2 Answers

up vote 8 down vote

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.

share|improve this answer
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 Jul 5 '11 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). – Pavel Shved Jul 5 '11 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 Johnson Jul 5 '11 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 Jul 5 '11 at 23:10
up vote 5 down vote

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.

share|improve this answer
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 Johnson Jul 6 '11 at 17:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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