My advice on becoming a better coder

[Writer’s note: I made a comment at a meetup about the “right way” to learn to code, and a colleague emailed me afterwards to ask what I meant. While it sounds initially dogmatic, in the end it’s very practical. This post is my effort to deconstruct what those loaded words translate to in reality.]

Ideally, everyone learns from a mentor or teacher who’s an excellent developer, reads things on the internet that align with best practices, and grows to form their own efficient way of coding. This is of course usually not the case.

Describing what makes a good coder is similar to describing what makes a good writer. There’s no precise formula, but there are some general rules that allow everybody to build artfully from the same foundation. People will develop different styles and preferences, which is great. No one way is right, but some ways are messier, less efficient, easier to break, or slower for the computer.

When you’re starting out, it’s difficult to determine if you’re learning from sources that are “good” or “bad”, so you just try your best. Price here is not a measure of quality, sometimes it’s the exact opposite. When in doubt, a language or framework’s own tutorials are a good place to start.

Everybody is bound to run across a Stack Overflow page that suggests a hacky way of doing something. You’ll hopefully come to discover later that some of the things you learned are hacks and there are “better” ways to do things. “Better” here means more efficient, readable, performant, reusable, modular, and not exploiting any bug of the system.

I say “hopefully” because noticing where there’s room for improvement in your code is the first step to being a better coder. If you stop once you’ve achieved a desired result, your learning will eventually hit a wall. Especially when technology inevitably moves on to new languages and approaches.

Over time, if you’ve developed good habits, you’ll be able to identify “bad” code by how it’s architected. In good code you’ll generally see:

• less steps
• readable logic
• minimal looping or nested conditionals
• a contextually appropriate amount of reusability

If you see the same code repeated over and over, that’s a good place to start making improvements. Here are some other things to look out for. Even if you’ve learned everything “wrong” from the start, don’t panic. It’s certainly not a career killer. Unlearning “bad” habits and relearning good ones can help you become a better coder in the end by giving you a greater foundational knowledge of why to make one choice over another.

While brevity is not always better, good coders may find over time that they prefer deleting code to adding code. This is often a sign that you’re able to problem solve in a more modular and reusable way.

The best way to be a good coder is to always be working at becoming a better coder. You know best where you haven’t quite hit the sweet spot in your code. Refactor the bits that give you trouble, or the ones you hate editing for fear of breaking something. Look to the parts that you might describe as “fragile” and see if they can be made stronger. Dig deeper into the methods you don’t fully understand.

There are exceptions and reasons why code might have to be a certain way, but they could also be opportunities for refactoring. The same goes for code that seems too long or complex, or any code that you come back to months later and wonder, “what is going on here?”

As long as you’re continually learning and striving to write cleaner, more efficient code, that makes you a good coder.