Three Non-Technical Ways to Become a Better Developer

Quite simply, how do we get better without reading a ton of technical documentation, reading code and writing code? What are the repeatable non-technical habits we can practice every day that, over time, will make us better?

1. Give a Damn

Put time and effort into what you do. Completing a task for the first time is usually a learning experience. The second time is also a learning experience; we sadly don’t treat it as such.

Congratulations, you’ve done something. Now do it better. Knowing that you can complete a task in an hour is a fantastic safety net. Take an additional hour to do some research - is there a way to better your original implementation? Were there trade-offs you accepted because it was a one-off the first time? Can you address those this time?

When you write code or documentation you’re effectively writing a draft; you’ve not committed to it. Take the opportunity to improve upon it and write a second draft if time allows.

Challenge yourself to be better every time you revisit something. Strive to make each draft a little bit better than its predecessor.

2. Solve, Don’t Fix

When first informed about this mentality, I scoffed because I was ignorant. I thought ‘solve’ and ‘fix’ were synonyms. I mean, they are, but they’re not. In context, fixing a problem is to do the minimum to get it in working order (even if temporarily) whereas solving a problem is to dig down to the core issue and resolve it.

For example, if my desk is too untidy to work on, I can fix the problem by moving some of the mess to a nearby surface. While the mess still exists, I’ve cleared some space to work. I can solve the problem by tidying up and putting things in their rightful place.

As developers, we are given problems all the time. Where possible, we should aim to identify the underlying issue (which will take time to identify) and then solve that (which may be more disruptive if the problem is at a deeper level than simply patching something near the surface).

For example, if you’ve been tasked with increasing the performance of an endpoint, don’t just take the low-hanging fruit. Are your DB queries as efficient as possible? Are you only pulling the data you need into memory? How efficient is the way you’re preparing and returning data?

By digging further than just the surface you’ll identify more complex problems. It’ll be frustrating, particularly when you don’t have time to solve the issue, but at least you’ll know where the demons lurk when your fix starts to fall apart.

3. Ask for Help

Most modern code is an abstraction on top of abstractions on top of other abstractions. There are turtles all the way down. Why not stand on the shoulders of giants? There is a limit to how much you can learn, from scratch, on a subject.

Your goal should be to obtain an understanding of the first principles as quickly as possible. Open your eyes just enough to see the known unknowns. Use those around you to accelerate that process. Does a colleague have any resources they can recommend? Do you have a senior who can give you an ELI5 in fifteen minutes?

The key is not to ask someone to mentor you on a subject one-to-one for hours on end. It is unfair to expect them to carry you to an expert level of understanding. You’re merely tapping into their knowledge to guide your path of discovery. There’s a lot of information out there in the wild, you need a little help navigating it and separating the wheat from the chaff.

The Power of Habits

The sad reality is that there aren’t any shortcuts to getting good at something, you must invest time and effort. These tips are to help you shape that time & effort in a meaningful way and help you progress as a developer. I’d love to hear from you if you have any suggestions of your own, please reach out to me on Twitter.