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.
- Promote SOLID principles.
- Produce code that you would like to maintain. aka: Do unto others as you would have them do unto you.
- Write Testable code
- Apply design patterns when they fit the problem
- 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.
Any team that feels the need to protect their junior members from any kind of “senior stuff” should review their recruitment routine, as well as their “welcome” routine. A good junior dev should be able to handle most of what is thrown at him, and should be able to say “OK, gimme some time to grok this now” or, conversely, “hey, I want to learn this cool thing I saw you doing, got a link or 5 minutes for a demo?”. If they are not doing that, they should be encouraged on doing so.
The line between “shielding” and “patronizing” can be very thin, which is even more dangerous when both senior and junior devs enter in some kind of “comfort zone” within such hierarchy, which may be fine until the time that your senior guys decide to go to work for Microsoft or start their own gig and you see yourself in a company full of juniors.
Amen.
“(but LINQ is OK for some reason…”
Probably because of lot of people still think LINQ = L2S and the wizard is easy to work with.
Oh no…LINQ is dead!
It’s funny how things happen in cycles… I started my career as a Cobol programmer on IBM Mainframes in the mid 80’s. I was trained to design “Systems” for the absolute lowest common demoninator. The assumption that someone with skills barely above drooling on themself had to maintain the code in the future (and this was actually at a company that had VERY high level hiring standards and the programmers were all very good….)
I remember having a real hard time convincing managers to allow me to use a State-Machine for parsing – succeeding only by treating it as a “block box” that could be configured by data in the database and that there would be no need to change the code…
Then the mainframe “paradigm” was replaced by client-server and then Internet – and we all had to learn new skills, that asusmption fell away and it was well understood that there would be a higher level of complexity. Essentially we were all “Junior Programmers” as the technology was considered “new” and everyone had to figure things out from square one.
Funny how now that Java and .NET have been around long enough – that the concern to coddle people with lesser knowledge is now being promoted so heavily.
At least it’s in the context of someone “learning” as opposed to assuming the average programmer can’t handle concepts taught in a CS class…
From a Junior Developer: Thank you!
There is nothing I hate more than to be told “Oh, you wouldn’t understand this. Go monkey around with something simpler while the big kids play with the big kid toys.” There is no way I am going to learn without being allowed to step in over my head, realize that I’m in over my head, and go to somebody for some answers.
>>No, my fear is actually around miss-promoted Senior Developers who are afraid to learn.
While this is a legitimate fear, MY fear is actually around mis-promoted senior developers who are afraid to TEACH. You touch on this earlier in the post where you mention that trying to teach something to someone (junior OR senior) is a great motivator to make you re-evaluate, reconsider, and reinforce your own presumptions and knowledge.
All too often the senior developer is afraid to expose their belief system to the scrutiny of others via the pedagogical process and this is every bit as stifling to the ability of others to learn (in my experience). This is why I say “I don’t *believe* anything, it gets in the way of learning.”
Nice post, BTW.
I’ve worked at a place before that would take this type of mentality and make design decisions around it. Stuff like, we can’t make that property “protected” as someone will screw it up, or a mock framework is too complex. Fun!
I agree that years of experience is a crappy metric. How many years of experience do you have eating lobster (http://thecodist.com/article/what-is-experience-or-why-ejbs-are-like-lobsters)? I’ve found people with only a few years that are amazing coders, and I know people with 20 years who can’t remove duplicates in an array. Where I work, we have a few juniors, a few “mid level” (like me) and a senior dev who is our “code master.” All the devs are highly productive and write a lot of code. However, I’ve found that when the senior dev reviews our code, he has a very insightful view of what exactly our code is meant to do, all the side effects that it may have, and how it affects the scope of the project as a whole, not only in terms of implementation but also in terms of how the core feature will affect our product as well as products that it interacts with. I’ve seen him kill features off because they’re an entirely bad idea (I wish that he were included earlier in the cycle so that we don’t waste effort like that but he’s usually right). To me, this level of insight on the product as a whole is what makes someone senior. In order for a senior dev to be hired as one, they need to have this insight, maybe not in your whole codebase but definitely in the domain in which your product lives. Coding ability has nothing to do with seniority IMHO. Also, a good senior dev will carefully consider the benefits of things like NHibernate or any other framework instead of just rejecting. They’ll typically have a good justification for why they won’t let you use it or they will have you prototype something to prove that it will be effective (that’s what I’ve seen in the past between a good senior developer and a crappy one). Anyone who blindly uses any kind of framework without having used it before and being familiar with it OR being able to prove somehow that it will be a benefit is an idiot also IMHO.
Right… that line of thinking is brain dead.
It’s simple…. something should not be added to code if it is going to cause maintenance issues for anyone. It’s nothing to do with junior/senior developers. There are good patterns of software design that improve maintainability and there are bad patterns that reduce maintainability (increasing cost of ownership of the software etc).
Good ideas shouldn’t be kept out of code because they’re new or someone might not be able to recognize/understand them immediately. That’s an education issue. If the idea is truly a good one and is well implemented, commented properly etc (i.e. maintainable), then junior developers usually don’t have an issue with it. In fact, I’d expect the contrary.
What a good senior dev brings is the ability (from experience etc) to spot these positive/negative design patterns that effect code maintainability.
I completely agree. It amazes me that you see resistance over things like TDD, Source Control, etc. because of how they would impact junior developers. The way I see it, best practices should be drilled in to a junior developer’s head from day one. It makes no sense to shelter someone from something that will make him or her unimaginably more productive.
@Tom – “something should not be added to code if it is going to cause maintenance issues for anyone.” Depends on how you define “issues”. I think you sort of clarify this in your next paragraph. 🙂
this is how i feel about the design industry as well. don’t be afraid to give it to them. they will suck it up in no time.
kenroy
Hallelujah, brother. Great post!
“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.
@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.
Excellent post. Could not have said it better myself!
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
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!
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.
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.
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’!