However much time and effort you put into advancing your software development skills, there’s always more to learn.
That’s the theme of the seventh and final part of our series sharing actionable advice on how you can become a better software developer.
We’ve looked at:
Ultimately, you’ll improve by doing. By constantly coding, over and over. By practising, by experimenting, by trying something new, and then by doing it all over again.
The best software developers know they should always be testing. There are always improvements to be made, always new skills to learn. So that’s what they do.
They test and tweak constantly. They don’t let it get in the way of deployment, as there’s always a balance of too much testing holding up a project (vs. too little and a release that isn’t up to scratch).
Instead, they test after deployment. Here’s how:
Code doesn’t need to be broken to be worked on. Flimsy workarounds, rushed jobs, outdated methods – they can all be addressed.
Go back to old projects and see what you can update. Even with a short break away from your most recent project, you’ll return with fresh eyes and see what could be done differently. Read through line by line, identify what each piece does, and think about how it could be improved.
Perhaps you could replace string concatenation on database CRUD with proper parameter queries. Maybe you could add a logging framework to improve error handling, instead of "writelns" and "console.log". You could try a template system instead of hard-coded HTML.
There are lots of opportunities to fix what isn’t broken. You might just want to play around with your own version of a common tool or program – like a game, a calculator or an editor – just to improve your learning.
The point here is that the code is not the finished project. That’s not the goal. The goal is what the code does. The outcome. Detach yourself from the code by fixing and experimenting, and you’ll bring improvements to the project and to your own skill set.
As well as fixing what isn’t broken, when you’re reviewing the code you’ve written, you should always be looking for ways to tidy it up.
You’ll need to be able to understand it when you return to your code in a few weeks or a few months. And others should be able to read it easily too.
As the saying goes: “Always write code as if the person who ends up maintaining it will be a violent psychopath who knows where you live,”(Attributed to John F. Woods). Make it as simple as possible to decipher, even if someone is in a hurry.
Reorganise your code wherever possible and re-name variables and functions. Choose names that are clear and consistent.
Writing reusable code is a great skill to have, and it can make your life easier in the future, but it’s not always the best option.
Test other approaches and consider hardcoding as part of your review.
Reusable code can often become too general and too flexible. Jack of all trades, master of none. It becomes harder to monitor, maintain and fix if bugs develop.
Take the time to see where generic code can be refined. Make sure each function only has one purpose and you’ll improve your code massively.
Finally, and perhaps our most important tip from this entire series, try new things.
Try new languages, new paradigms, new lines of code, new projects – whatever. It doesn’t matter what, the key thing here is that you’re pushing yourself.
The last position you want to be in when you’re trying to improve your skills is doing the same thing day in, day out. It doesn’t matter if you’re brilliant at that, you won’t be advancing your abilities. You won’t be realising your full potential.
Experiment. Test. Try new things.
Step out of your comfort zone, work on usual projects, code something different.
Keep doing that, month after month year after year, and you’re guaranteed to improve your software developer skills.
And to help you experiment and test, we created Vershd. It’s the effortless Git GUI that spots errors and prevents accidental deletions – so you can safely try new ideas without worrying about overwriting or losing your work.
If you’ve missed any of our tips, check out the full Best Software Development Practices series.