20 rules for developers: An antidote to mediocrity

5 minute read

This post is a perpetual work-in-progress therefore I don’t expect I’ll ever truly finish it as I myself grow and learn. I want to share what I believe are fundamental rules for being successful in a career as a developer.

Some of these are obvious, some are probably hard truths, others are hopefully something akin to enlightening. I’ve learned almost all of these the hard way so I don’t pretend for even a second to be perfect.

I’ve been told I should write something like this a few times by different people though I’m not entirely convinced that they haven’t just been pulling my leg. Well… who cares. Here we go!


  • Know your IDE or at least don’t let it stop you or others from doing their job
  • Learn to use Git effectively
  • Don’t rob yourself of an opportunity to learn deeply
  • Actively practice writing readable code
  • Feel at home on the CLI
  • Know when to ask for help
  • Know how and when to test
  • Know at least one language extremely well
  • Know when and how to automate a task
  • Aim to not create extra work for the people that you work with
  • If you can’t automate it, don’t ask someone else to do it
  • Be honest about what you don’t know to others
  • Have a well thought out opinion, don’t be afraid to change it
  • Know when to take the unbeaten track
  • Don’t underestimate how much you know
  • Don’t overestimate how much you know
  • Work smarter and smarter
  • Repeat yourself
  • Take pride in your code. It is ultimately a reflection of you.
  • Get crippling burnout once

I was asked to elaborate on these as some of them aren’t clear from just the rule alone. I hope to write a more in depth paragraph or two on each of these and add them below this post as I make the time.

Know your IDE or at least don’t let it stop you or others from doing their job

Many years ago when I first started programming I remember (almost nostalgically) trialing a myriad of IDE’s and code editors in a desperate attempt to find the one that would allow me to be the fastest, most productive developer. It was, however, a mostly fruitless endeavour and it wouldn’t be until an embarrassingly long time later that I realized that it wasn’t the IDE that was stopping me from developing the tier of apps and games I dreamed of, it was me. I’ve thankfully learned a great deal since then.

You will need to settle on an IDE or editor eventually. You don’t have to stick with it for life, but there is going to come a time when you do need to use one, and when you do finally converge upon some semblance of a rational decision - learn it, and learn it well.

A Chef will know how to use a knife. Carpenters know how to safely use a hammer. A Doctor will know how to administer a needle. A Developer better bloody know how to use their IDE and they better know it well.

Learn to use Git effectively

Git is one beast of a tool. I’m not embarrassed to say that I still remember having once kept instructions in a text file on my desktop of commands to run when I was finished for the day. But you can’t keep this farce up for ever. eventually you’ll need to learn what Git actually is and what it does and how to use it effectively. It’s another fundamental tool after all. Conceptually it’s not that difficult, just abstract.

Here’s a few things you need to know about your use of Git, especially on a project with more than just you or where there is a chance someone will one day look at your git history and need to know what took place. Lest they be forced to pick apart a sea of cryptic merges and 30+ consecutive commits with the useless and infuriating message; fixed.

  1. Learn what a rebase is and when to use it.
  2. Never submit a Pull Request that includes merge commits.
  3. Commit messages should say what the result of this change is, not what you did - your code explains that for you.
  4. Know how to refactor commits in your Pull Request. Spot a typo shortly after submitting a PR? Start getting used to running git add --all && git commit --amend --no-edit && git push --force instead of burdening your colleagues with a stream of fix typo commit messages.

Also, it doesn’t matter if you use the CLI or a tool like SourceTree, Kraken or some other GUI. At the end of the day, the PR’s all look the same.

I could go on, but I think I’d rather allow you to venture into the wilderness. It’s dangerous to go alone, take this!

Don’t rob yourself of an opportunity to learn deeply

It’s fairly standard in the industry to search online for answers to a technical problem and hurriedly click on the first Stack Overflow post to appear in the results. There is a lot to know in software development. I would never blame anyone. Even if you know how to solve a problem it isn’t at all a terrible idea to periodically search for a solution simply to see if there isn’t now an obviously better way to do it.

However, the habit of copying and pasting someone elses solution from the web or from a Slack message ‘from the dev who knows that stuff’, without finding out what it actually does eventually needs to be destroyed. Most developers that I know grow out of this as their career progresses, but some hide it like they’re harbouring some shameful secret. It’s a prime example of how you can rob yourself of a learning opportunity. In the long term it’s untenable and the only person it hurts is you.

When faced with a problem you don’t know how to solve, first find a solution then learn everything you can about it. If you’re running short on time, write it down and come back to it on the weekend. If you don’t establish a routine of learning what it takes to do your job and do it well in an ever growing and fast paced industry you will you will struggle to reach the places you likely want to go. Don’t let it happen to you - you got this!