There are lots of ways to improve as a developer quickly—keeping track of what’s going on in the industry, reading books, maintaining outside projects, and watching talks are some of the obvious ones. But there are a few habits you can adopt in your day-to-day work that will slowly improve a different set of skills over time.
1. Keep a Development Journal
When we run into issues in the course of software development, we frequently get lucky and find the answer to our problem in the top result on the first page of a Google search. Other times, though, it’s not so easy, and we can spend an hour or more following links and going down rabbit holes until we finally find a solution in a downvoted Stack Overflow answer on the fifth page of our fifth Google search.
The thought process that led to the answer is usually pretty intricate and full of a lot of small insights. As you try things and they fail, you’re learning something, but the garbage collector in our brains tends to throw these small lessons away as soon as the problem is solved. It’s worth taking a few moments to document these situations.
Not only will you have a documented solution to a problem that might save you or a teammate an hour or two in the future–you’ll also have a miniature detective story that might help you next time you find yourself going past the first page of search results. Learning how to follow leads and make sense of disparate and conflicting pieces of information is an incredibly valuable skill that can only be developed through experience.
Make it a point to read through your notes once a month or so to remind yourself of past successes and internalize some of the small lessons.
2. Review Your Own Code
Everyone writes code that’s less than ideal. As uncomfortable as it might be to go back and read your code from six months ago, it’s a good habit. It will expose blind spots you didn’t know you had, make it easier for you to review other people’s code, and improve the overall health of the codebase.
Every developer has had the experience of writing something complicated that made sense in the moment, and then revisiting it months later and being completely baffled by it. What’s even worse is when someone else questions you about it, and you’re unable to provide answers.
Finding these spots is instructive because it teaches you what kinds of things you tend to overcomplicate. Everyone has a different style and writes messy code in different ways. But we often can’t see our own ways until we get some distance from the code and revisit it. Try to root out these areas and fix them before you confuse yourself or someone else down the line.
It’s also good to occasionally dip your foot back into a part of the codebase that maybe you haven’t seen in a while. Doing this will remind you how it works, and it might also reveal other opportunities to refactor.
When you’re looking at old code, ask yourself how you would structure it if you were starting it from scratch today, given the lessons you’ve learned since it was written and the domain knowledge you’ve accumulated. You probably aren’t ever going to be able to throw it out and rewrite it unless it’s a personal project. Nevertheless, it’s a good thought exercise, and it might give you some ideas for less invasive ways to improve the codebase.
3. Learn a New Shortcut; Try a New Tool
The old cliche is that when all you have is a hammer, everything looks like a nail. Think about the tools and shortcuts that you love and couldn’t live without. You can probably remember a time before they were part of your repertoire when things seemed just fine. For example, before you learned that you could move the cursor forward and backward by word, you moved it forward and backward by character and had no idea what you were missing.
The editors and tools we use have so much functionality that there are probably hundreds of things out there that would become indispensable if you only knew what they were. Make it a point to seek out and explore shortcuts, configuration options, and plugins for your tools, and you will start building up an impressive bag of tricks.
With regards to point 1 I wrote an article in a similar vein. See, https://sionwilliams.com/post/making-ticketing-systems-useful/
Some developers may wish to add this to their journal too, so they can take it with them. This was born from the frustration of constantly being told “oh, we tried that, we got the same result” but never finding any record.
Great ideas, I’ll start implementing them starting now! :)