Be humble.

Architecting and designing great code isn’t some mythical ideal, it’s something that you must constantly work towards. You need to clarify in your mind exactly what makes a programmer great.

We’re always searching for ways to make our code better and to sharpen our skills, like a butcher’s knife at the chef’s table. What most people fail to cement in their minds is what exactly makes a programmer ineffective.

What are the habits that unnoticeably obstruct the path to well-designed and elegant code? This fog in your vision is what dulls that knife you’re constantly working so hard to sharpen.

Therefore, to become truly great and unique in your ability, you must first make yourself aware of the habits and nuances that keep you from progressing.

Just like the Alcoholics Anonymous 12-step program, the first step to recovery is admitting and making yourself aware of the problem in the first place.

You must develop self-awareness and humility in your own skills, in order to level up to mastery.

Here are the nine most prominent habits that make a programmer ineffective — habits you must avoid picking up at all costs.

1. Bombarding Code With Unnecessary Comments

If you have to explain every single line of code with a comment, you’re doing something wrong.

Your code should be self-commenting and intuitively designed so that any programmer can look at it and almost immediately extract the meaning and goals of your code. Comments are a sign that your code needs restructuring.

Only write comments if you absolutely have to, for example in TODO statements. Otherwise, in order to have clean code, you should remove and delete any unnecessary comments.

2. Writing Very Long Functions

If you find yourself with any functions longer than 15–20 lines, that’s a sure sign they’re doing too many things. This creates a tight coupling between your logic, rendering your code incapable of extension, and subject to too much modification when it needs to change.

Make your life easier on yourself and refactor large functions into smaller, more intentional ones. It will be much easier to understand what your code is doing, it makes it more reusable, and it allows you to pinpoint exactly where any small modifications need to be made when you come back to it.

3. Not Regularly Testing Code

It’s easy to get so lost programming that you forget to test your code. If you don’t test your code regularly, you run the risk of a surplus of unidentifiable and functional errors.

Make your life easier on yourself and test rigorously, obsessively, and consistently.

4. Following the “If It Works, Don’t Touch It” Methodology

Perhaps the worst advice that was ever given to any programmer, this mindset will only domino many other problems that you may face with your code.

If it works, that’s simply just the first draft. Just as with any other first draft, it must be edited and refactored to be the most optimal and clean solution.

5. Not Using The Resources Available

I hate hearing other programmers ask me questions that could have been easily found within seconds of a simple google search or looking through the documentation.

There’s a vast amount of information out there and we’re given seemingly limitless resources to find solutions to our problems. It’s good to figure things out on your own, but do yourself a favor and spend some time researching. Research is an important skill that all programmers must develop in order to be effective.

If you don’t know something, look it up — don’t default to borrowing your colleagues time to quickly find a solution. Only after you’ve done everything you could in your research should you then start asking for external help. All I want to know is that you tried and went against the grain a little bit.

6. Failing To Document Changes

This doesn’t mean commenting on everything, as I said above, but it’s vastly important to document your changes. It’s easy to get lost in the flow, never document your changes, and completely forget what you did. That’s not a position you want to be in.

Instead, find a medium where you can store documented changes, such as a source control repository like Github, and describe any changes that you have made so that you can easily progress on your work day-by-day.

7. Not Using an Intuitive or Specific Naming Convention

Far too often I see programmers write variables like i, j, z, num, or some other abbreviation that lacks any description or intuitive meaning.

You may have a function named in a way that has general meaning over what the function is doing, rather than what it is specifically doing. If you can’t describe what a function does with a simple name, this probably indicates that your function is doing too many things or that you may need to reevaluate the purpose of what you’re writing.

Remember, a long descriptive name will always be better than a short non-descriptive one. You must be able to look at a name and immediately understand what the purpose of that variable, function, or class is.

Just because you know what the purpose is, that doesn’t mean that everyone else will.

8. Writing Duplicate Code

This is an easy one to overlook but if you find yourself writing the same thing over and over, it’s a sure sign that you need to refactor your code to make it reusable. If you write duplicate code, you’re only wasting your time and progress.

The way to get around this is to implement interfaces, extend using abstract and virtual classes, work with programming design patterns, or redesign a function to accept different inputs.

9. Hoarding Knowledge

You have the choice of being either a knowledge sharer or a knowledge hoarder. Avoid being the latter at all costs.

The knowledge hoarder significantly impedes the progress of a project, task, or company by making any progress in a particular realm dependent on you because the hoarder is afraid that if they share too much information on how to accomplish something that it’ll make them dispensable.

We work in teams for a reason — it’s essential that we share what we know to not only help increase the skills of your colleagues but also gain multiple perspectives on approaches to a task. Teamwork, collaboration, and communication are essential to the success of any company or task.

Final Takeaway

To truly become a masterful artist, you must first understand what you should not do. Avoid all of the above points and to drive the way you program and design your code.

I can promise you that if you do this, you’ll put more thought into what you write and become a better programmer because of it.