Over the last few weeks we’ve been exploring the different ways you can advance your software development skills. They’ve ranged from keeping motivated, and having the right mindset, to working well with others and practising good workflows.

But to really advance your abilities and increase your skills, you’ve got to do just that – build your expertise.

It starts with the tips we shared in part 1, where you get to know more code by reading, watching and listening. But now you’re going to need to go much more in depth.

You’re going to want to learn by heart to really build expertise in your niche or specialism.

The first step that any experienced developer will tell you if you want to advance your skills is to know your tools cold. Inside out. Back to front. Top to bottom.

Learning just enough to get by and topping up where needed is no longer enough. Experts know their discipline off by heart.

They learn all the features of any tool they use. They know exactly what the menus contain, and exactly what any item in a context menu does. And they’ve memorised keyboard shortcuts for everything.

A great place to start is by searching for and reading every hints, tips and tricks article you can find relating to your chosen tool.

Don’t scratch the surface, dig into every part. And then dig again and again until knowing what you can do with them becomes second nature.

You should be going as deep as possible into the architecture to realise exactly what’s possible.

It may be that you’ll learn things that are of no immediate use. You may only need top level functionality of your favourite stack – for now. But if you commit everything you learn to heart, you’ll have an expert level of knowledge for the future.

And when the problem presents itself, you’ll know that Ruby has a method you can use to solve it. Or when a new feature is requested, you’ll remember that there’s some architecture within Node that could be just what’s needed.

The same goes for language and programming paradigms. Explore your chosen ones inside out.

Take the time to learn the most important, most relevant libraries for the language(s) you work in. Which are going to be most effective for your day to day coding, for your use cases?

Find them and learn them. Don’t worry at first if you don’t understand part of them. You can come back. The key thing here is looking under the hood to see what’s going on – and what can be accomplished.

Because if you’re aware of a relevant library, you won’t need to reinvent the wheel when a problem presents itself.

While it’s easy to look at stacks, libraries and tools and learn them inside out, it’s equally easy to fall into the trap of thinking that because a shortcut exists, or because there’s code already written, that those are the best ways of doing things.

That’s not always the case.

Just because they exist doesn’t mean they perfectly do the job you need them to do. There might be three or four more efficient options.

Design patterns are superb when used correctly. But they don’t fit every task. Don’t try and use them just because they exist. You should have a clear, solid reason for wanted to deploy one. They’re not a hammer, and not everything is a nail.

Remember, code can always be improved. Rules that were once applicable can potentially be broken.

So, don’t be afraid to reinvent if you need to. Just have a go.

Software like GitBreeze can help you minimise any errors when deploying new code, if you want to experiment.

We’ll look at that experimentation and testing in the final part of our series on how to use the best software development practices.