How to prevent (junior)developers making the wrong decisions/bad code?

views:

588

answers:

+7 Q:

How to prevent (junior)developers making the wrong decisions/bad code?

Short of hovering over the developers and question all decisions they make/code they produce.. Architectural choices, massive codefiles (5k loc), no code commenting or documentation, ..

I'm using some Check-in policies in TFS2005 like Changeset Comments Policy, WorkItems, regular code reviews.

What works the best in your company?

So far:

Code reviews (by most)
Mentoring/Teaching
Pair programming

But nobody mentions the possibilities like check in policies, code analysis, code metrics. Does anybody use this as a method to teach juniors?

+19 A:

Code reviews

If you do code reviews, they will learn faster, see the best practices and so on. On your end, you will be able to see what they are doing and keep more control over it to make sure that they are not destroying everything. Finally, if they know that their code is going to be checked, they will work harder to make it better.

There are a lot of posts about this here on SO, take a look!

marcgg 2009-09-21 19:18:45

Hmm .. that sounds like actual management.

Peter M 2009-09-21 20:13:00

Code reviews are great, as long as they don't become "critic/whine-fests." Make sure you have someone who is willing to shut down this type of "feedback" leading the review.

JasCav 2009-09-22 00:14:10

That's true. The question http://stackoverflow.com/questions/89163/how-to-conduct-a-successful-code-review has some helpful pointers on how to conduct a code review

marcgg 2009-09-22 14:58:37

The book "Code Complete" has a great chapter on code reviews. People have different roles such as moderator, scribe, observer, etc. Management? No way! This is for the benefit of the developers. The quality of code in your organization will increase by orders of magnitude if you conduct productive code reviews. Remember, it's a code review not a peer review. You are reviewing the code not the person.

Loki Stormbringer 2009-09-28 15:35:45

+1 A:

Teach them the benefits. I'm sure code reviews would help too. Also, let them learn from their mistakes.

Daniel A. White 2009-09-21 19:19:29

+4 A:

You can't prevent it, short of keeping a hand on their terminal's power cable. If your VCS supports branches, consider code-reviewing junior developers' branches periodically to make sure they're on the right track. "Periodically" will depend on the size of the assignment and that developer's history.

John Millikin 2009-09-21 19:20:28

+1 A:

When estimating the timescales for your projects allow for the experience of your development team. Let them make mistakes, rectify them and learn from it.

Pete Kirkham 2009-09-21 19:20:51

What percentage you would allow for juniors to learn within a 7 person devteam?

rdkleine 2009-09-21 19:29:22

How fast people learn or work highly variable - you have to get to know them rather than putting a blanket figure.

Pete Kirkham 2009-09-22 09:24:17

+5 A:

Why prevent? It is important junior developers would make their own mistakes to learn from. What you actually want is a way to prevent these mistakes from having serious effect and this is generally achiavable though rigorous code reviews.

shoosh 2009-09-21 19:22:13

+2 A:

Code reviews (as mentioned by marcgg), mentoring, pairing with more experienced staff, training.

Give them a chance to learn and even make mistakes but in a way that they feel supported.

klabranche 2009-09-21 19:23:22

How much time would you(r company) spend on mentoring on average per person?

rdkleine 2009-09-21 19:31:14

I don't have a percentage but this is very important. Everyone learns including the experienced developers. You could also give them time on their own to learn. I give my team 4 hours a week for just this.

klabranche 2009-09-21 20:00:16

+7 A:

You could try paired programming.

pair the Jr. Dev with someone more senior, that would help with the code issues as well as getting the newbie "indoctrinated" into the culture, standards, etc. of his new home.

Muad'Dib 2009-09-21 19:24:11

Haven't given that a try yet (not on a regular scale though).

rdkleine 2009-09-21 19:27:40

+3 A:

How much time would you(r company) spend on mentoring on average per person?

3-6 hours (introduction to the software/product) on their first day.
1-2 hours per day (answering questions) for the next week or two.
2-4 hours per week (code reviews) after that, for the next months.

ChrisW 2009-09-21 19:40:26

You seem to imply that the code reviews should stop at some point. I strongly disagree. Code reviews should continue forever, for everyone. Yes, that also means the senior guru or whatever their job title is.

Gerco Dries 2009-09-21 19:59:23

I'd stop doing code reviews when I stop finding bugs or anything else to comment on in a person's work.

ChrisW 2009-09-21 20:09:06

@ChrisW - In other words you will never stop code doing reviews

Peter M 2009-09-21 20:13:54

No, it has happened; senior developers learn/know to review their own code, and how to test it before it's reviewed.

ChrisW 2009-09-21 20:18:06

@ChrisW - While senior people (and I am one) can perform things own their own, they still operate under their own set of assumptions as to what is the correct way of doing things. Part of a code review is to shine the light on those assumptions and see if they are valid.

Peter M 2009-09-21 20:20:47

@ChrisW - it is a sign of arrogance to assume that you know all and that what you do is perfect.

Peter M 2009-09-21 20:22:44

@Peter - Do you mean that, you agree on a spec and a design with someone (a teams leader, architect, peer, or customer) before you code? And that you're responsible enough to take the initiative and ask if you find something/anything you're uncertain about during coding? Because if I have literally stopped finding anything to critique in a person's finished source code, then that's nice but IMO it's no longer cost-effective for me to code-review their code.

ChrisW 2009-09-21 20:30:09

I think reviews can be more cursory for senior staff. However, it's good to keep the reviews up as the code-base matures... E.g., "Did you know that Bill added a function to do this part three weeks ago? You might see if you can re-use it."

steamer25 2009-09-21 22:15:24

@steamer Opportunities to reuse code ought really to mentioned/identified before coding (during the specification/design stage) ... and developers ought to know the APIs of the components which they're supposed to use/reuse ... but I was using "code review" to mean an intensive and detailed inspection of the code-level implementation (and not just the API-level interfaces), in order to find bugs, to suggest improvements in that implementation (and especially any *necessary* improvements), and to find things which the original developer doesn't know and which I can usefully tell them.

ChrisW 2009-09-21 22:39:01

Having a quick look at what a developer has checked-in, e.g. to see what new classes and new methods they've created, isn't what I'd call a "code review"; and in any case that may not take 2-4 hours per week per developer, and neither is it really "mentoring". But anyway, yes, it isn't black-and-white, and the time does tapers off but not all the way to zero.

ChrisW 2009-09-21 22:43:46

@ChrisW .. The simple fact is that people of all levels make mistakes or have oversights, and that past performance does not let you off checking future work. Would you disable unit tests for a developer (of any level) because in the past 12 months you noted that their defect rate dropped to zero? What you are suggesting with code reviews amounts to the same thing. There is an adage that comes from Islam - "Trust in God but tie your camel"

Peter M 2009-09-22 00:00:53

"Would you disable unit tests?" -- Would you be a "back-seat driver", when you're a passenger and someone else is driving? I'm not suggesting that the developers and the QA people should stop testing. I'm saying that it has happened, historically, that I reckoned it longer profitable for me to spend hours crawling through / inspecting their code when they already did so when they designed, wrote and tested it themselves. If you're working with, say, 20 other developers, then you can only afford that many hours per week of "mentoring" for the new/junior hires who (temporarily) need it the most.

ChrisW 2009-09-22 00:40:04

+1 A:

FxCop used with check-in policies and/or Continuous Integration can help. It's no substitute for manual code reviews and mentoring, though.

TrueWill 2009-09-21 23:49:22

+2 A:

Get a copy of Code Complete and tell each junior developer to spend at least one hour per day reading it.

No, even better, do this for ALL developers.

Konamiman 2009-09-22 06:55:37

+1 A:

rajesh pillai 2009-09-22 07:06:46

I'll take a look at these books, thanx

rdkleine 2009-09-22 19:43:44

ansaurus

tags:

views:

answers:

How to prevent (junior)developers making the wrong decisions/bad code?

related questions