Hi John, it’s me: future you. You think you know everything about writing software, and you’ve been told this same thing by countless others. But take it from me: you know so little you don’t even know what you don’t know.
You think you’re pretty clever. You always use a language’s cutting edge features or get the most done with the fewest lines. There’s one problem with clever code – somebody else has to read it. That someone else is not somebody who just doesn’t ‘get’ your genius. It’s future you. You see: if it was hard to write, it’s even harder to read.
Exhaust all blame on yourself before you blame someone else. It’s far more likely that the code you just wrote has problems in it then the industry standard, heavily tested and heavily used code is at fault.
Your professors will consistently insist on excessive comments, you’ll get marks for every method that has an appropriate comment describing how it works. You’ll spend time writing nauseatingly large comments at the beginning of every file. But they’re wrong. Most comments are a waste of time. What’s the best way to communicate with other developers? Naming and self documenting, intention revealing code. Naming is hard, but spending a little bit of time thinking about appropriate and consistent names almost always pays off. Instead of comments; make sure each procedure, object or module has a single purpose and name it appropriately to reveal what that purpose is. This doesn’t mean abandon comments, but look to them as a last resort.
Don’t swear in the code – one day your boss will find it. Or it’ll appear in a demo, in front of the customer. Make kitten references instead, everybody loves kittens.
Don’t be so judgmental when you read someone else’s code. You won’t always know what conditions it was written under, what the requirements were or what the state of code was when those changes were made. Maybe it was written under duress or maybe it solves a problem you just haven’t encountered yet. As they say in the movie business: where were you when the page was blank?
Read the source code. If it’s available it’s usually easier to understand than you think and it’s almost always more accurate than the documentation.
Don’t be afraid to remove code. You may have worked hard on the code, but you have to remember that all code requires maintenance and all code rots. More often than not if you need it back you’ll understand the problem better and write it better. Realizing this can be liberating.
Make interfaces that are easy to use correctly and hard to use incorrectly.
Understand every single line of code you write. If it’s there, it has a purpose and you need to be certain it’s doing the right thing. It can be tempting to sometimes copy code from examples or put things in until it just works. But if you make even the tiniest, trivial mistake – the computer has a license to do whatever it wants to.
Automate everything. If you have to do something more than a couple of times, take a step back and see if there is a script you could write or a tool that could make those steps reliable, repeatable and most satisfyingly of all: fast.
Research first. Someone has usually solved the problem before and they’ve probably done a better job.
Most of all, be aware of what you don’t know, seek knowledge, practice deliberately and expand your horizons beyond what you are comfortable with. These are some of the lessons I’ve learnt over the years that weren’t taught to me in any computer science course, that I had to learn for myself. They seem obvious, almost self evident at times but they require work. Perhaps, once you appreciate them, you will no longer be a junior developer.
About the Author
BiographyMore Content by John Barker