Thinking only of the Junior Developer
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.
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.