Best Coding Habits to Start Now

Alex Hyett - Mar 24 '23 - - Dev Community

When you teach yourself a new skill we all have a tendency to pick up bad habits.

The problem is that unless you have someone to tell you that you are doing it wrong, the habit tends to stick. It might not be a problem now but in the future, you will find yourself reaching a ceiling and won’t be able to progress further until you fix your bad habits.

For example, I have been using a computer since I was about 7 years old but I never learnt how to touch type. Over time my fingers have learnt where most of the keys are so I don’t need to look at the keyboard but I am only using a couple of fingers on each hand.

Because I didn’t start with the correct technique, my typing speed is stuck in the 60 - 80 wpm range and I am having to learn how to type properly so I can get better.

The same is true for learning to code. In this article, I am going to share the 5 coding habits that you need to develop if you don’t want to limit yourself later on in your career.

1. Plan First, Code Second

I have seen this time and time again from junior and even senior developers. When given a problem their first instinct is to open VS Code and start building out a solution.

I get it, we became software developers because we like solving problems with code. However, it is very rare that we fully understand a problem when it first presents itself.

It is important to look at the problem properly first and try and work out what the best solution would look like before you start coding.

It might be that the problem is really just a symptom of another issue. It is much better to ask yourself why the problem exists first so you can solve the root cause rather than just adding a sticky plaster to the problem.

Once you are sure you understand the problem, then plan out your solution on paper or a whiteboarding app. Think about how your application is likely going to need to change in the future so you don’t end up digging yourself a hole you are going to have to climb out of later.

Every time a developer jumps straight to writing code there is often a lot of rework that needs to be done.

2. Make Code Templates

Professional software development might seem exciting from the outside but in most cases, it is actually quite boring.

There is a lot of grunt work that goes into every new project. You have to set up the API, the database, logging, the CI/CD pipeline and all the infrastructure.

I have lost count of the number of APIs and lambda functions I have built over time. Even though they all did something different the structure of each application looked much the same.

You can save yourself a lot of time and become a more efficient developer if you build out templates that you can use later on.

In an ideal world, you type in the name of your API, select the technologies that you want to use and then click a button and everything would be set up for you. Then all you would need to do is write the business logic for that function.

Some companies do exactly that but at the very least you should have a few templates set up so you don’t have to write the boilerplate code every single time.

3. Don’t reinvent the wheel

In the same way that using your own templates can save you time it is important to use the work of others when building out your application.

Chances are if you are trying to solve a problem, someone else has problem had the same problem before you and written something you can use. There are so many frameworks and libraries that you can use in your applications to save you from having to write them yourself.

I see a lot of developers waste time trying to reinvent the wheel because they think they can do it better. Just leave your ego at the door and use an existing library you will save yourself so much time and headaches in the long run.

There are some things like password hashing algorithms that you should never attempt to write yourself. Just use a library and get on with your day.

4. Explain it to a friend or colleague

It doesn’t matter if you are a senior developer or a junior developer we all get stuck from time to time.

The difference is that senior developers know when to ask for help rather than spend the whole day stuck on one problem.

In most cases, the person you ask won’t have the answer but in many cases, just the process of explaining the problem through with someone else helps me come up with the solution.

I have solved many programming issues by talking to my wife. She isn’t a developer and doesn’t understand most of what I am saying but to be able to explain something to someone else I have to think about the problem in a bit more depth and that is usually enough to help me solve it.

So next time you are stuck, ask someone for 15 minutes so you can explain the problem you are having. If you are lucky they might know a solution but chances are that it will help you solve it yourself.

5. Keep a developer journal

Lastly, it is important to keep a developer journal. Most people don’t have an eidetic memory.

You might think that the next time you have this problem you will remember it but chances are it is going to be in 6 months’ time and the only thing you will remember is that you managed to fix it last time but you haven’t got a clue how to do it now.

By keeping a journal of everything you are learning you can go back and remind yourself how you did something.

You don’t even need to go into masses of detail in your notes. Usually having a note is enough to jog your memory and remind you of what you were doing.

There are a few ways you can do this. Keeping a notebook on your desk is the simplest way. Whenever you solve a problem or learn something new jot it down.

The downside of this is that you will fill up quite a few notebooks over your career so it isn’t really practical to carry them all around.

The other option is to use an application like Notion or Obsidian to store all your notes. I tend to use a combination of all 3 in my note-taking.

If you want to learn how I do that then you can read my article on How I Take and Organise Notes.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .