One of the bigger tasks I have at work is to create software libraries and systems that others will reuse. The hardest part of that task is to create something that will prevent common mistakes and/or prevent a developer from implementing non-standard software. It’s my opinion there is a missed opportunity to educate the users.
There’s an old joke about the C programming language that says it allows you to shoot yourself in the foot. And mostly that is a fair statement to make, with one caveat. The caveat is: if you don’t know what you’re doing, you will shoot yourself in the foot. And this isn’t a software programming thing. You can say this about a lot of things. But with software it just so happens that as a lesser experienced developer you are capable of creating and doing quite a number of things with the power to shoot yourself in the foot and not know it until there’s blood everywhere.
Creating libraries and systems that can be reused and won’t allow the user to do something bad (knowingly or not) is really hard to do. How do you write a recipe for a casserole that prevents the cook from burning it? Or how do you give someone directions to your house that prevents them from missing the street sign? Now imagine writing a recipe for a casserole that allows someone else to write their own recipe for a casserole? That’s what a software library should do when it’s really good.
I was reminded of this today as I was putting together a desk I bought from Target. The instructions were written with a tone of “don’t worry we’ve written instructions to all but do the work for you.” Pretty bold claims. Then I imagined myself without the experience I have with regular tools. What if I wasn’t sure what a Phillips screwdriver was? And what if I didn’t know the difference between that and a flat-head? Sure there is a picture showing both, but the screws provided accept both. Hmmm. One is certainly better than the other for this setup, but what if I didn’t know better. The problem is the instructions gave me just enough to get the work done, but not prevent blood. What was missing was experience or an education of how to use the tools and in what context they’re suited best.
It’s my opinion that what is really missing in a lot of software development is education. Not the school kind of education, but the hands-on side-by-side kind. Giving presentations, pair programming and one-on-one work are a few ways to help educate. In most cases it just takes time, sitting with a junior and showing them. Write some code. Make some changes. Explain. Rinse and repeat. It’s quite alright to develop libraries and systems that make mistakes go away. But it would be even better to educate. With an educated development crew, the libraries can focus on doing cool stuff and drop the need for all the preventative stuff. Teach the developer to prevent mistakes themselves.
Educating the junior isn’t easy. In fact it’s down-right hard. Each developer learns differently and at varying pace. But if taught there is more to gain than what a perfectly written library could ever achieve. In fact that is the crux of my thought. More juniors turned into seniors is always a better investment. A library may prevent the majority of mistakes but it will always be just a library. A developer who is educated will always be capable of producing more.