Thinking only of the Junior Developer

December 27th, 2008

This is a rant.  Not an angry rant, not bemused, or disappointed. This is just a rant.

This is a rant against all of the people who say: “Don’t do that, the junior developers will never understand it”.  For this rant I’m looking at my own current and former managers, friends of mine, Billy Hollis, and myself from time to time (mostly for giving into the thinking)

I’ll state my argument right here: “How are we going to turn a Junior Developer into a Senior Developer if we don’t challenge them with Senior Developer ideas?“  And that is the point, isn’t it?  Or do we coddle them forever?  “Stay way from that code, that is Senior Developer code.  Lions, Tigers, and Bears.”

We all like having Junior Developers around, we need someone to shove grunt work off to from time to time.  But at some point, we need those same Junior Developers to turn into Senior Developers.  Hopefully from there, those former Junior Developers, can start to challenge the rest of us, bring on new ideas, etc.

Where do I hear this?  Every time I bring up TDD, Agile, Source Control (come on guys, source control!!!), IoC containers, MVP, MVC, Domain Driven Design, architecture, design patterns, Lambda Expressions (but LINQ is OK for some reason), JavaScript, and JQuery.  Pretty much every time I turn around.  The idea seems to be that these are OK for me, but make sure no one else has to jump in there.

I’m calling BS right here and now.  I’ve had it with the argument, I’ve had it with the mentality.  Programming is about learning, plain and simple.  If a programmer is not capable of learning new things, they do not belong here.  This mentality is feeding one thing: stagnation.  Not just in the Junior Developers, but the Senior Developers as well.

First, lets face the facts.  The old ways of programming are not good enough.  Heck, they weren’t good enough back then.  I’m talking about the maintenance nightmares we all own right now. In-line SQL with DataSets.  Procedures 500+ lines long.  Classes 10,000 lines long with more responsibilities than Barack Obama on inauguration day.  The crap code we shuffle off to those same poor junior developers because we are tired of it.  

OK, so can a junior developer can look at that mess and actually understand what it is doing?  This wonderful code base, simplified just so they can understand it better.  Right.  Throw me another one.  What are we teaching them by handing down code like this?  To live in terror of making code changes?  Or even worse, we are teaching Junior Developers that this is what production code looks like! This is the code they are learning from.  This is the code they are referencing.  This is the code they are going to WRITE!!! How in the world is this helping?

If you are working with Junior Developers, and you are going to be writing code that they are going to have to use, you have responsibilities.  These are not outlandish.

  1. Promote SOLID principles. 
  2. Produce code that you would like to maintain.  aka: Do unto others as you would have them do unto you.
  3. Write Testable code
  4. Apply design patterns when they fit the problem
  5. Don’t fear teaching moments

That last one is key to me.  I am a father and a teacher (of sorts…I lead users groups and development teams).  “Teach them in the way they should go” (Deut 6:7) Do not shy away from teaching a new practice to another developer.  And if you cannot explain it, then that should give you ample motivation to learn things better yourself (heaven knows I’ve had plenty of those moments).

What this is not — I am not suggesting to throw in architecture or patterns just for the heck of it.  We are talking about appropriate usage.   Do not implement pattern ‘xyz’ just because you haven’t implemented pattern ‘xyz’ before and it looks fun.  But to not implement an appropriate pattern, because it might be overly challenging for a junior developer, is equally egregious.

Please remember, the point of patterns, software design, and the like is not to add complexity, but to help manage complexity.  There is complexity in all applications — it is often call business logic, nothing is getting away from that.   But there is something to be said for knowing where an application puts that complexity.

Back to the point: best practices in software does not come naturally to anyone.  I know of no senior developers that really reached that title without help from other developers.  The transformation from a Junior Developer to a Senior Developer is not some magical over-night process.  It takes time and a lot of help from others.  Your code, the code you hand down to the next sorry sap, will be used to train the next developer down the line. 

 

Now, let us back up a few steps from this little rant of mine.  What is it that I really fear?  I’ve met many a capable Junior Developer in my time.  I throw a new concept at them and they suck it up in no time.  IoC? No problem.  MVP? Got it. Lambda Expressions?  Cool!  And they really get it.  Honestly, they do.  I took 20 minutes to explain Lambdas once to a guy next to me and he was off.  Many of these ‘hard core’ patterns and practices are not that hard to explain to any capable developer.

No, my fear is actually around miss-promoted Senior Developers who are afraid to learn.

← Older Comments
  • http://www.silverlighthack.com Bart Czernicki

    “I took 20 minutes to explain Lambdas once to a guy next to me and he was off. ”

    Wow, what a VERY POOR practice. You just give your jr developers the concept in less than an hour and they are off throwing lambda expressions around? So you feel comfortable with a jr developer throwing delegate based expression around, which is what lambda expressions are?

    I agree with the concept of having smaller teams of higher paid professionals over a larger team of varying skills. This way there is no one left behind.

  • http://www.elegantcode.com Chris Brandsma

    @Bart: Take your pick: 1. Have the jr developer write his own sorting/filtering code for a generic list, or 2. Have the jr developer write one line of lambda that does the same thing.

    I’ll take 2, every-single-time.

    Lambdas are not a cure all, but when half of the methods in the generic list call for them, I see that as a reason to know how to use them.

  • Adam Smith

    Excellent post. Could not have said it better myself!

  • MP

    I was very pleased reading this post. Pleased because there are some senior developers out there who realise a junior developer is not a waste of time. Pleased because with this post “I feel there is some hope for junior developers”. I am rather disappointed with some of the other comments, it seems these guys have forgotten that they were once junior developers and very likely they found a developer in their way who had the time to teach and show them the way, so they were not left behind. What a weak memory, shame on them

  • http://www.hexagon-global.com The OberGruppenFuhrer

    A common pattern that I see (and it may not be the case in your organisation) goes like this:

    Senior dev/ architect/ teamleader is promoted due to longevity of tenure.

    This person likes playing with new stuff, is an uber-techo, dislikes spending time on other people who slow him down. May also like to hoard their skills and superiority, rather than share them.

    Consequently takes as little part in coaching, mentoring, explaining as he can get away with, and complains lots about how much of his precious time is being eaten up by these thicko’s. Delivers no presentations or courses on technology approaches to the team.

    Stays in his office coding up a storm of un-maintainable, out-of-control brilliance.

    Forms a network around himself of cognoscenti who ‘get it.’ Everyone else complains that they don’t get the support that they need, and continue writing not-very-good code…

    Conclusion? This team is broken. This organisation has a problem. and techos who don’t like people so much, don’t believe in teamwork, don’t understand that the more you coach, the happier and more productive everyone becomes, should never be put in any sort of leadership position. Including technical leadership!

  • http://geekswithblogs.net/seanfao Sean

    I couldn’t possibly agree more. I have actually taken it upon myself to encourage junior developer growth by challenging them to think in terms of reuse. I’ve seen code written by “senior” development staff that was outright disgusting (300 line methods in dire need of refactoring and absolutely no consideration to reuse) and this is the code that I had to maintain when I was a junior developer. It frustrated me badly to think that these same people were working on new assignments, creating the same monstrosities.

    Designing code right the first time means applying design patterns, where appropriate and following best practices. Doing so will lead to fewer lines of code, fewer bugs and code that is generally easier to maintain. Less code means less for the junior developer to have to jump into and learn. Less ramp-up time means that you can get them in there sooner being productive members of your team.

    Breaking old habits is difficult. Start them off early.

  • Tex

    Surely the term “Junior Developer” is just another term for a graduate??

    I started developing after years of being in system support, and I was never referred to as a junior.

    I guess to summarize you have “Developers” and “Senior Developers” within a company, the difference being “Senior Developers”, apart from having more development experience, are senior only through promotion/company experience/procedures etc?

    Further, even though I have developed for 5 years, I can always feel happy enough to ask a developer of 3 months for advice etc. In todays development/programming world, with huge resources/info through the internet etc, we cannot all be expected to know everything, there’s just not the time for this. So if I think it’s worth asking, whatever their experiences, I most certainly will.

  • http://www.BeatThePuzzleMaster.com ActualRandy

    Junior “Regular Expression Programmers”

    So – I could summarize your argument as follows:
    – Advanced techniques take time to learn
    – They are harder to understand for those who haven’t mastered the topic yet
    – Nonetheless, they save time and overall make the code better
    – Thus, complex code is worth it, even if it has a “learning curve” or looks “nasty” to the uninformed.

    If you agree with my summary, are you ready to reconsider your opinion regarding regular expressions? Because I know you have decided to avoid regexes.

    Your same logic applies to regular expressions, i.e. they have a learning curve and look nasty, yet they to save time and are easier to maintain, at least for those who are not ‘junior regular expression programmers’!

← Older Comments