Main Contents

Moving a Team to Journeyman Developers

software development

Fred George has broken developers into three broad groups of apprentices, journeymen, and masters. Based on this classification our team is moving from apprentice to journeymen currently.

He defines apprentice level programmers as:

An apprentice in OOP is a effective programmer and can construct loops, methods, and classes, but is still learning how to separate the business problem into objects. Encapsulation is being learned (which means no getters or setters for the classes). Code is being placed into the appropriate classes rather in giant god class. if statements litter the code as the apprentice is still learning design patterns to eliminate them. Class sizes and method sizes tend to be larger than smaller. Code requires comments to aid in understanding, and blank lines are common in the middle of methods to group code together. An apprentice is beginning to understand the patterns of bad code (the imfamous code smells), but lacks the tools to understand how to eliminate them.

Some of our developers are still dealing with this level, especially considering object oriented concepts can take a while to bake in. Lots of if statements in some code is still a sign that we have a ways to go. The blank lines in the middle of methods are great visual clues that a developer still needs some help refactoring.

Journeymen are defined as:

The journeyman is adept in OOP techniques. The classes exhibit crisp conceptualizations distinguishing them from each other. Boundaries are clear; methods are small. Design patterns are common, and exist in inverse proportion to the number of if statements. else statements are quite infrequent, and case statements have vanished. (I write about one case statement every 18 months or so.) Given a problem and a broad outline of a design, journeymen will implement it with little need for supervision or support.

When I see the rare if statement in a code review it will be a happy day.

Ed Gibbs @ August 21, 2007

5 Comments

  1. Mariano Kamp August 22, 2007 @ 5:51 am

    >> …and blank lines are common in the middle of methods to group code together …

    And that is a bad thing? As opposed to a brazillion small private methods with parameter passing and all the other overhead generating clutter and blurring the conceptual view of the class?

  2. Ed Gibbs August 31, 2007 @ 3:55 am

    I think the point was that having longer methods where you tend to group up together lines that are related is a sign that you visually have something that could be it’s own method. As developers get up to speed I tend to see a lot of that, until they get adjusted to refactoring out into smaller methods.

    I don’t think the occasional use of blank lines in small methods is an issue at all.

  3. David Vydra September 10, 2007 @ 10:52 am

    Ed,

    I would like to personally invite you and all of Sacramento area Agile folks to http://agileopencalifornia.com conference. I am posting this here because I could not find an email for you.

    Regards,
    David Vydra
    www.testdriven.com

  4. Ed Gibbs September 13, 2007 @ 8:11 pm

    Looks like a great conference. Maybe I can grab a few PMs from work as well.

Leave a comment


Feed