How to Become Better at Coding – A Revitalizing Journey

Every programmer wants to become better at coding. There is absolutely no doubt about it.

However, there are so many people who are either clueless or lack the discipline and motivation to better themselves.

This article is aimed to address the following points

  • Propose reasons why you are not improving at your desired rate.
  • Provide practical, actionable steps towards becoming better at coding.

This article is aimed at programmers that want to improve, find motivation or become better at coding by conducting a thorough diagnosis. 

I will systematically bring you through a journey where you evaluate your rate of growth, identify bad habits and practices that are holding you back from becoming better at coding.

We will end the journey with tips and advice (derived from personal experience) on how to become better at coding.  

Hopefully, this list will help you as a reader become better at coding. I plan on continuously updating the post as I continue to ponder about ways to become better at coding (and of course with your feedback as well).

Without further ado, let us begin this journey of refinement, growth and self-discovery!


1. Recognize and Accept the Need for Change

A cancer patient will only find out if he/she has cancer by recognizing the need to receive a diagnosis.

In the same way, programmers will only realize their stagnation by asking the hard questions.

The answers and discoveries may hurt, but one can only improve by recognizing and admitting to the sub-optimal nature of their current state.

Furthermore, asking the hard questions also helps shed light on what areas to improve, as well as bad habits to weed out and new concepts to adopt/learn.​

Am I Improving?

If I can be honest with you, I go through periods of stagnancy more often than expected. Periods where it is unproductive for me to code. 

During these times, as developer, you need to renew your mind, find your purpose and most importantly, recommit!

Mold grows in dark places.

If you don't identify and deal with the problem at its infant stages, it will eventually evolve and manifest into greater problems in the future.

If you are not improving, rest assured, there is always a reason.

Find that reason and don't stop until you find that reason. It is the key to overcoming your immediate problem. 

And that leads us to asking​ the following question.

Why am I not Improving?

This is the question developers ask themselves when they feel stagnant. It is a good place to start, but unfortunately, many developers do not understand how to progress beyond this stage.

Naturally, this is not an easy question to answer. If we were able to identify exactly why we were stagnating, assuming you are motivated to continue growing, we would have already dealt with it right?

Below are some questions that will hopefully lead to more questions and ultimately a clear answer and root​ cause to your problem.

Question #1 What is the purpose of my code?

​Before I start my rant, I just want to let you know that I would love to read your answers. If you are willing to share, please leave an answer down in the comments section before.

This will give me (and other people who come across this article) deeper insight into the universal question on how to become better at coding.

By doing so, I assure you that your contribution will help people worldwide!

Below is my response to the question.

  • My code exists to solve problems (both big and small) for my client.
  • My code exists to provide solutions that are easy to follow, reusable and reads like a well-written piece or written literature. 
  • The code I write is to make the life of the developers who maintain the code easier.

​Okay, some of the points are quite ambitious, but you get what I mean right?

When writing code, make sure that the code you write has a specific purpose and do whatever you can to fulfill your purpose/mission statement.

Good programmer write code that solves a specific problem without creating new problems.

Click to Tweet

It is impossible to write code that acts as a bullet proof shield that wards off all incoming bullets.

However, at the very least, your code should not introduce new problems, provided that the user requirements, demands and specifications have remained unchanged.

Question #2 Why Code?

Did you ever stop to ask yourself this question? The variety of possible answers is endless, so I will not bother clutching at straws. 

For those that are curious, below is my answer.​

Because I love solving problems. Programming and writing code is one of the way I can solve immediate problems for my clients. 

Writing code and seeing your solutions manifest and impact your surroundings is rewarding and motivating. 

To me, coding is more than just a means to generate income. It is a way and form of expressing myself.

If your motivation is something along the lines of "making a lot of money", your motivation is temporary at best, lasting only as long as your perception of programming aligns with your greater goal of making a lot of money.

Once you find another area that has greater potential than programming, who knows what will happen then right?

If you intend to code for a living, let me tell you something.

Programming is an art. And art demands lifelong commitment. 

Click to Tweet

We live in a world where technology is growing and evolving at an exponential rate. People even dubbed the era we are living in as the fourth industrial evolution. The tech industry is at the forefront and you can be that technology and the required skills will be changing rapidly. 

If you don't have a passion and commitment towards coding, problem solving and learning, I recommend quitting to avoid wasting any additional time and energy, which can be invested elsewhere. 

2. Diagnose Yourself

If this is you, I want to ask you to go through the following checklist.

  • Am I doing the same thing over and over again?
  • Do I write code automatically without putting much thought on the task at hand?
  • Am I copying and pasting solutions or code snippets blindly?
  • Do I settle down on the first solution that I come across?

If you answered yes to any of these questions, chances are, you are on autopilot mode. If you do not understand the dangers of auto-piloting, I explained why this habit is so destructive in a previous post on sharpening your problem solving skills as a programmer.

As programmers, we live or die by our problem solving skills.​ Therefore, it should make sense that

Auto piloting, or drifting absent-mindely towards a solution, is a programmer's number one enemy.

Click to Tweet

Auto piloting inhibits not only our ability to learn, but also our ability to come up with optimal problems to solutions by slowing down our cognitive functions.

These are the basic and most fundamental symptoms of a stagnating programmer. You will not improve at the desired rate until you learn to cut these bad habits out of your life.

Stop coding until you deal with each of the items on the checklist.

It might sound a bit harsh, but I mean it. The reason why you are not improving is because you continue to rely on the same bag of tricks rights? 

It is prime time to add some new tricks to your arsenal.

To become better at coding, you need to continuously add and fill up that bag, instead of recycling the contents each time you come across a problem.

When you have dealt with these issues or recognized your inability to deal with these issues on your own, it is time to move onto the next step.

3. Ask for Help or Advice

No matter how talented/smart you are, nobody has 20/20 vision.

Each individual brings unique experiences, vision, dreams and views to the table.

I don't know how this happened, but there is an unspoken stigma attached to the idea of "asking for help".

If you want to become better at coding, you don't have the luxury of worrying about what others think. In my opinion, there is absolutely nothing wrong with asking for help.

As a matter of fa​ct, I respect and admire people that are willing to lay down their pride and humbly ask for help. It makes me want to work with them even more! 

To give you some practical wisdom and knowledge on when to ask for help, I will list some cases where asking for held/advice may be a good idea.

If you have any suggestions on scenarios where asking for help is a great idea, please let me know via the comments 🙂

Take note that the bullet points are all in the context of how to become better at coding. ​

  • You have no idea on how to tackle a problem. 
  • Zero experience or knowledge of topic that you wish to explore.
  • Came up with a solution, but you want a second opinion.

When you enlist the help/advice of another individual, you are tapping into the experience, wisdom and knowledge of that individual.

I am going to talk more about experience later, but the bottom line is: we have limited time. By investing time, we are exchanging time, effort and energy for experience and knowledge.

Therefore, it would be wise to inquire and find out more about the said topic from somebody who has experience in a field before making decisions.  

Your network and pool of resources (including human resource) plays a larger part in your journey towards becoming better at coding than you know. 

Programmers often forget that the best source of knowledge is not the tutorial, but its source

Click to Tweet

I know that not everybody has the privilege of working with James Gosling, Uncle Bob or Doug Crockford. 

The point I want to make however, is that you can learn so much more from another developer in comparison to reading a tutorial.

The reason is this: people who have earned your respect leave a lasting impression.

Even if you don't respect them per say, if you are willing to open up your heart and mind, you will be able to pick up a lot of knowledge. You may even come up with new ideas for tackling a particular coding problem.

Watching videos, writing code and reading tutorials is not the only way of becoming better at coding. One great, but often neglected way of learning is to simply talk to other programmers and pick their brain.

4. Plan to Become Better at Coding

Coding is not like lotto where you get a big fat payout as a result of sheer luck. 

To become better at coding, one must sow the seeds of meticulous planning.

Aimless learning/coding will get you nowhere. Mark my words. If you want to become better, simply "working hard" is not going to get you where you want.

For example, if you are aiming to learn something new from this session, coding with a purpose may lead you to formulating a detailed, achievable, goal-oriented plan.

Write a journal entry/blog post on one new thing that I learned in this coding session.

I guess it is a plan. But a real crappy plan if you ask me. You need to be more specific.

Programmers don't stagnate because they plan to stagnate. They stagnate because they fail to plan effectively.

Need an example of more complete plan? Well, here it comes!

Lets say for example, I want to learn about ES6 Arrow functions. ​My action plan may look something like the following. 

Sample Action Plan for Learning ES6 Arrow Functions

​1. Take Maximillian Schwarzmuller's course on ES6. Afterwards create a list of items on ES6 to read through. Naturally, you will create a physical/electronic document containing an actual list.

2. Start compiling a list of differences between regular JavaScript anonymous functions and ES6 arrow functions.

3. Start building a functional programming utility module using ES6 arrow functions (and possibly other ES6 features).

4. Afterwards, compile that into a written document that discusses and examines cases where it is more suitable to use arrow functions over regular anonymous functions and vice versa.

5. Lastly, write about what you learned from studying arrow functions. It doesn't necessarily have to be about arrow functions. As long as what you write is about coding or software architecture. ​

Albeit not a fully formulated, bullet-proof solid plan, this should give you a general idea on how to construct one that will help you achieve your goal of becoming better at coding. 

5. Unlearn Bad Programming Habits

Now that you are out of auto-pilot mode and in the right state of mind to critically assess your situation, the next step to become a better coder is to unlearn bad programming habits!

If you have read up to this point, when you have time, I recommend also reading my article on identifying misconceptions about learning programming. It should set you free from some doubts or misconceptions that you may have subconsciously adopted as truth. 

Here are some ​bad programming habits that you can weed out of your life.

  • Copying and pasting code thoughtlessly.
  • Not asking for help when you need it.
  • Coding immediately after hearing user requirements.
  • When tackling a complex problem, not processing your thoughts, assumptions through explicit means such as drawing a diagram or documentations.
  • Not writing pseudo code for logic that requires some thinking.
  • Relying only on past experiences to write code. 
  • Re-inventing the wheel all the time. In another words, writing code for something you have done like 100 times previously. You are throwing time away.
  • Meeting only the minimum requirements.

6. Learn how to THINK like a Programmer

​Notice that I didn't say learn good programming habits.

Often coined as best-practices, programming habits are ones that will help you throughout your entire life as a software engineer or programmer.

I intentionally bold-printed habits in the previous sentence to drive home a point. Care to guess what that is?

I am not saying that good programming habits are bad. Writing meaningful comments, automated tests, and any other good programming habits that you can think of help you write better code.

The more important question is:

Does my perception on best practices/good programming habits hinder me from becoming better at coding?

​With this, I want to highlight the dark side of habits that is often swept under the rug.

Habits (even good ones) encourages impulsive behavior and stifles critical thinking.

Click to Tweet

When solving problems, every programmer needs to weigh the possibilities and embrace in-depth critical thinking. 

The one constant in software engineering that you can constantly rely on is


If there is one good habit every programmer should adopt, it is the habit of thinking critically.​

This is why I think design patterns are a double-edged sword. The immature programmer (I have been guilty of this myself) will take the design pattern and copy and paste the exact same code or concept into their immediate problem. 

Design patterns are not silver bullets.​

Other times, more often than not, a copy and pasted solution will yield disastrous results, because of the subtle differences in the problem domain between the one that the copy and pasted code addressed and the one at hand. 

How does a Good Programmer Think of and Come up with Solutions?

Okay, we talked a lot about how NOT to think. Please feel free to disagree with me here, but this is how I think a programmer should think.

Programmers exist to solve problems via code and technology right? 

Therefore, good programmers are excellent at identifying core problems around them.

A programmer's way of thinking should be like water: easily adaptable, but solid in certain conditions.

Click to Tweet

A programmer lives by his or her ability to learn new concepts. This means that we need to keep an open mind and be willing to go out of our comfort zones.

Prime examples includes learning a new framework or adopting a new approach towards a problem, tweaking the existing system architecture. 

At the same time, we need to be uncompromising about your core values as a software developer. These core values can be both personal or universal to developers.

Lets look at an example.

If you are a programmer employed by a company, you write code to solve the company's problems or the problems of the company's clients. 

First of all, in order to think like a problem (AKA a darn good problem solver), you first need identify your clients.

In this case, who is/are your clients? The business? The client of the business? 

If you guessed either or both, you are half right. You forgot another key client: The other developers you work with.

​A good programmer solves problems right? Writing code to meet an unrealistic deadline will likely result in technical debt. Not meeting the deadline will likely incur the wrath of your employee and possibly their client.

At this time, what would be the right decision?

A good programmer will assess the main problem at stake and the non-negotiable requirements of the stakeholders involved to meet them at the middle in order to minimize the losses for the company (both tangible and intangible).

Easier said than done right?

Every case is unique. Therefore your ability to gather information and identify key user requirements is what makes you a great programmer/software engineer. ​

The reason why I mentioned all of this is because this ability can and should be applied while coding!​

If you are interested in this side of software engineering, Uncle Bob wrote a great book called

The Clean Coder: A Code of Conduct for Professional Programmers

I highly recommend readers to get this book, as it is rich in knowledge of how professional programmers should conduct themselves and has great real world case studies that will train coders to think critically.

7. Code Code Code with Purpose!

In order to become better at coding, you need to code. 

Just as a writer writes to sharpen his/her skills, programmers write code to sharpen theirs.

You can read all the books, videos and tutorials you want on riding a bike. But you will never actually be able to ride one until you practice riding. 

Like any other artist or athlete, programmers also need to develop muscle memory!​

With that being said, if I only want you to remember one point from this sub-section, it would be this.​


Before writing even a single line of code, make sure that your purpose is clear.

  • What am I aiming to get done during this coding session? 

Even when you are coding for fun during your spare time, make sure you have a purpose. Naturally, when you code during your free time, it is usually for the following reasons. If I missed out on any common reasons, please leave a message and I will add it ASAP.

  • To build something meaningful and/or useful
  • Learning something new
  • Building up a portfolio
  • Writing up a tutorial (I find myself doing this a lot these days)

With each of these reasons, your goal or purpose will differ. Apply your critical thinking skills!

​This is where your will begin reap the fruits of some of the difficult planning that you did in step #4. 

8. Write Clean Code

Clean code is a universally hot topic within the programming community. As long as humans are writing code, this topic will continue to be relevant.


If humans write code, it is natural to assume that humans will also read code. 

To machines, variable names don't matter. Unfortunately, as human beings, we cannot interpret code like machines and need to rely on each other to accelerate our ability to read, analyze and understand code.

The compilation of well-known and common methods/patterns for maximizing readability and performance are known as best practices.

Becoming a better programmer is not just about getting features to work. It also involves crafting code that reads not only like a well-structured essay, but also runs like a well-oiled machine.

Even if the feature is amazing, if you are the only one who understands how it works by reading the code, that feature becomes difficult to modify or extend.

Other individuals who read your code act as perfect judges.

For example, co-workers.​

Gradually over time, if your co-workers comment that your code is becoming more easier to follow, easier to extend and update without breaking other code, you are writing cleaner code than you did in the past.

This provides you with a great way to benchmark your performance to check your progress and ensure that you are gradually improving over time.​

Now, do!

Okay, that was a lot of information! I hope that this post was informative, thought provoking and eye opening. 

Now that you have gone through the list of ways to become better at coding, the next step to take is to pick a couple of items from this list and start doing!​ While educating yourself is great, all that knowledge is wasted without a healthy dose of application.

If it makes you feel any better, I am currently in the process of evaluating my learning methods in order to become better at coding. These items act as a constant reminder for me to develop my skills and constantly seek to improve.

I also wrote an article on sharpening your skills as a programmer, so if you are hungry for more, feel free to check it out.​

Needless to say, there will be a lot of growing pain. But no pain, no gain right? 

If you have any points you would like to add or constructive criticism, I am all ears! Please let me know via the comments below. I am looking forward to evolving this page so that you and the other readers get the most out of the contents posted on this page. ​


About the Author Jay

I am a programmer currently living in Seoul, South Korea. I created this blog as an outlet to express what I know / have been learning in text form for retaining knowledge and also to hopefully help the wider community. I am passionate about data structures and algorithms. The back-end and databases is where my heart is at.

follow me on: