Are we missing out on true learning opportunities?
Out Of Date Warning
Languages change. Perspectives are different. Ideas move on. This article was published on April 5, 2013 which is more than two years ago. It may be out of date. You should verify that technical information in this article is still current before relying upon it for your own purposes.
“Using singletons is bad. Don’t do it, ever.”
“Don’t micro optimize your code! It’s pointless!”
“Don’t worry about performance until you have performance problems.”
“100% code coverage is necessary for your unit tests.”
“No optimization without benchmarking first!”
We’ve all said these things at some time or another to a junior developer that we were helping, teaching or mentoring. Their question usually relates to some work that they are doing or an issue they’re trying to understand. For the sake of simplicity, we make a blanket statement, assuming it will be enough to cover us and obtain the desired outcome.
But are we doing the developer we’re helping a disservice?
Amy Stephen tweeted the following on Twitter:
I tweeted back at her:
And she said:
This got me thinking about the way I write blog posts, and how we as a developer community teach the more junior developers among us.
Amy has a great point. Her point is that by using absolute statements (e.g. never, always, must), we potentially hurt the developers who are trying to learn.
There are few things that are absolute in programming (code that has a syntax error will never compile). But most things are far more nuanced than a simple “yes” or “no.”
For example, I’ve completed micro optimizations on code that would run thousands of times per minute to shave milliseconds off the process.
I’ve considered 80% code coverage to be acceptable on an application that was difficult if not impossible to completely test.
And I’ve optimized before I had performance problems, knowing that failure to do so would inevitably lead to performance problems later on.
These are all things that I’ve told people never to do, yet when the situation called for them they were, in fact, the right solution.
I believe that as developers we have an obligation to teach when a tool is bad, and when a tool is useful. Though many developer may never have an opportunity to actually need microoptimization, the fact that they might need it should be enough for us to detail the (very limited) circumstnaces when it can be useful.
Nuance in software development is a virtue, not a vice. And I intend to begin embracing it more and more as I write. Sure, it might make my articles longer. But it will also make them more useful. After all, my goal is to teach others what I’ve learned. And Amy is right: if I never show the right way, people will never know what it is when they need it.