Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Letter to myself as a junior developer

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.

  • John Ruxton

    What do you consider junior developer?

    Many so-called seniors I’ve worked with still don’t understand most of this.

    • John Barker

      In this context it’s simply a literary technique for addressing someone who might appreciate the ideas I’m sharing. I don’t think you magically become a senior developer when you understand these ideas, but (for me at least) many of these coincide with revelatory ‘ah-hah!’ style moments. I feel when I began to appreciate these ideas I had made a much bigger leap than all the time spent learning various languages and tools combined.

  • Dan Galipo

    Great article Johnny B!

  • Dean

    It is a great article indeed, and I bet in 5 years time you will be able to write another one to tell current you what your new future you would do differently. I think we are in an industry where you never stop learning, and never stop bettering yourself.

  • Great article John! It really made me think about myself and others!

  • I really appreciate what you’ve written.

    I’m curious if you considered including ‘find a mentor’ or ‘find a community’ or other advices not specific to reading/writing/understanding/reviewing code.

    I would also add, be aware of fads and trends for languages, software, and techniques. Some ideas that are all the rage now will cause you pain if you try to apply them ‘just because everyone is now saying you’re doing it wrong’. I often this of this article on Shu-ha-ri

    Don’t over-engineer. e.g. Maybe this app will need a SOA in 6 months, but right now it will work fine as a vanilla Rails app. Star with the golden path, and move outwards.

    Ask yourself what problems you’re solving, if you’re solving it, and what are the possible outcomes of mistakes. e.g. Not testing everything is okay.

  • nextime

    No, not everyone loves kittens. I hate kittens. I love all the other animals, but really hates kittens, they are just a parasite.

  • Great article, I can relate to everything you mentioned here. Being able to write some code that does the job is just the beginning.

Share This