Apr 19, 2019 9 min read Coding

How to Break Bad Programming Habit and Replace It With a Good One

Pick the right habit and progress is easy. Pick the wrong habit and life is a struggle. — James Clear

Your programming life is essentially the sum of your coding habits.

How good or bad a developer you are? A result of your habits.

How successful or unsuccessful you are? A result of your habits.

How productive or unproductive you are? A result of your habits.

What you repeatedly do (i.e. what you spend your time thinking about and what you do each day) ultimately forms the person you are, the things you believe, and the personality that you portray.

Months ago I’ve read a book named Atomic Habits that helped me to realize my bad habits and provided me a framework to transform my life for the better.

This book had a big impact on my personal life and at the same time on my programming life. I used the framework that was mentioned in the book to improve my personal life and then I applied the same methods to become a better developer.

Now I am more aware of what kind of mistakes I’ve made in my previous developer career and I’ve learned how to avoid them in the future.

Before talking about the framework, let’s see what exactly a habit is?

What Are Habits?

Habits are the small decisions you make and actions you perform every day. According to researchers, habits account for about 40 percent of our behaviors on any given day.

Let’s think about one of your day at work.

As a developer, while you are coding, you have to make many small or big decisions about the software you develop. The decision quality that you make is proportional to the habits you have. Or simply said:

Your software quality depends on your coding habits.

How Habits Work

There are four stages in the process of building a habit as they were mentioned in the book:

Cue (Noticing or Observation)
Craving (Wanting or Anticipation)
Response (Doing or Action)
Reward (Liking or Outcome)

My personal advise. Mark them down:)

The cue is about noticing the reward. The craving is about wanting the reward. The response is about obtaining the reward. And finally, we chase rewards because they serve two purposes:

(1) they satisfy us and

(2) they teach us.

The first purpose of rewards is to satisfy your craving. Yes, rewards provide benefits on their own. How you define the reward is important here.

Writing clever code (a bad habit) brings you a feeling that you feel smart. Coding fastly without planning (another bad habit) brings you a good feeling that you are faster than anyone at writing code.

At least for a moment, rewards deliver contentment and relief from craving.

Second, rewards teach us which actions are worth remembering in the future. For instance, when you avoid assumptions (good habit) about your software, your reward will be having simpler and clean code that is easy to change, that is easy to add new features and that can last longer. It will be maintainable because you avoided assumptions that can make your code complex and cause you to write the code that isn’t needed. This reward will bring you another benefit which will prevent you from throwing your code away and rewriting it from scratch.

When you have this reward, your brain will remember it and always chase for the same reward.

Let’s cover a few examples of what this looks like in real programming life. I will use the most popular examples that I wrote in my previous “Learn the fundamentals of a good developer mindset in 15 minutes” article.

Let’s start with the bad developer habits.

Bad habit 1: Writing Clever Code

Cue (noticing): While you write code, you remember (noticing) that other programmers in your team will read your code.
Craving (wanting): You want them to think that you are a very smart programmer. You want to satisfy your ego.
Response (doing): You write clever code that is hard to read and hard to debug.
Reward (liking): You satisfy your craving to feel smart. Writing clever (complex) code becomes associated with feeling smart.

In just a few steps of a mental process, you created a bad habit. From now on, every code you write in the future will be clever and hard to understand for others. And just because you wanted to feel smart. You want other programmers to treat you like you are the king.

Complexity has nothing to do with intelligence, simplicity does. — Larry Bossidy

Bad habit 2: Predicting the future.

Cue (noticing): While you develop your software, you notice that maybe in the future you will have to code another module that is not needed now.
Craving (wanting): You want your system to be too generic so that it can cover all future needs. In this way, you will not have to change your architecture to add a new module in the future.
Response (doing): You write unnecessary code to cover future needs.
Reward (liking): You satisfy your craving to have a very flexible, generic system that can cover everything. Writing code that isn’t needed now at this moment becomes associated with having a generic system.

You fall in another trap! Your brain acquired another bad habit. You will predict the future which will cause you to write unnecessary code to be generic.

You should know that your code will not be generic enough to satisfy the actual future requirements you will have.

Now, let’s see some good developer habits.

Good habit 1: Avoiding Assumptions

Cue (noticing): While you develop your software, you notice that you don’t have any unnecessary code in your code base. It is very simple and clean.
Craving (wanting): You want to have a software that is easy to change and easy to add new features so that it can last longer and it can continue to help people.
Response (doing): You avoid any assumptions that will cause you to write any unnecessary codes.
Reward (liking): You satisfy your craving to have software that is easy to maintain and easy to develop. Avoiding assumptions now became associated with having a maintainable system.

By having this good habit, you changed your mindset for the better.
Now while others trying to handle complex and unnecessary codes, you will focus on improving and extending your software because you don’t have to deal with issues like others do.

Good habit 2: Not measuring programming progress by lines of code

Cue (noticing): You realize that more lines of code make more trouble. Because more lines increase the defects in your software. It means you can lose control easily.
Craving (wanting): You want to keep your code base as small as possible to prevent yourself and your team members from losing control over your code.
Response (doing): To have clean code, you focus on what really matters and you say NO to any possible unnecessary code that can increase complexity in your software. You prioritize your tasks based on that mentality.
Reward (liking): You satisfy your craving by writing code that matters and brings you and everyone else more value. Avoiding more lines of code now becomes associated with having a small but effective code base that increases adaption to change.

I can write many examples but this is not the purpose of this article. I plan to write another article about good and bad programmer habits.

OK, now we know how habit works. But the real question is how can we break bad programming habits and replace them with good ones?

Breaking bad developer habits and replacing them with good ones

There are some steps that I believe you can follow to break bad habits and improve your programmer mentality.

1. Be open-minded and embrace the change

You can be a junior who is new to programming or senior programmer who spent years in the industry. Doesn’t matter who you are and how much experienced you are. There is always an open door for new things, for a change.

What you learned until now, may be wrong. You should be ready to admit it and if someone wants to show you the new thing that will change your mind for the better, you should embrace it. Change is natural. Growth happens there.

Don’t have fixed mindset. Have a growth mindset.

2. Have a solid developer mindset

When you are open-minded, you can adapt this step easily. To have a solid developer mindset, you should read books, watch videos, read articles. Follow the famous programmers on twitter.

What kind of book you should read?

You should read programming books and self-development book. You can take the right effective mindset from self-development books and you can combine this mindset with programming methods. You will see how much common values they have.

I believe a programmer should get the right mindset first. Other things will follow this. To show the right programmer mindset a wrote an article named “Learn the fundamentals of a good developer mindset in 15 minutes”. You can start getting the right developer mindset by reading it.

3. Identify current habits

One of the best ways to break a bad habit and build a good one is to identify a current habit you already do every day and then stack your new behavior on top. This is called habit stacking. Let me give you an example from my life.

Last Friday, we had a meeting about defining the deadline for a new feature of our product. We were talking about which tasks are our priority and how we should implement them in an effective way. There was a task on which we waste our time heavily. There were three ways to implement that task but somehow we were stuck. We couldn’t choose it because developers were trying to predict the future. They were starting each sentence with “What if” words.

Since I am aware that predicting the future is one of the bad habits, it was easy for me to identify this bad habit. After I explained that what we are trying to do is wrong, the answer was obvious for everyone.

4. Practicing

Once you identify your current habits and realize what is good and bad for you, it is easy to build new good habits. There is only one working way to build a habit: Practicing.

Habits form based on frequency, not time. The amount of time you have been performing a habit is not as important as the number of times you have performed it. — James Clear

Ok, but how should you practice? Is there a way for that?Yes, the following step is about that.

5. Applying the framework

I mentioned above about the framework I applied for my personal life and programming life. This method is from the book I’ve read. How does it work?

There are four laws to build a new habit:

1st Law: Make It Obvious

The first law is about making your habits more obvious, more visible, and more noticeable so you can be aware of them all the time. Write down your current habits and the new habits that you want to have and put them on your desk. Read them every day and be aware of them while you are coding.

2nd Law: Make It Attractive

Use temptation bundling. Pair an action you want to do with an action you need to do. Create a culture where your desired behavior is normal behavior. Create a motivation ritual.

For example, you can join some events where good programmers will speak so you can get inspired by their speech. You can follow some programmers on Twitter to read their lessons. You can read famous programming quotes.

3rd Law: Make It Easy

Reduce friction. Decrease the number of steps between you and your good habits. For example, let’s talk about productivity. You want to be more productive. This is your new habit. How can you make it easy?

Divide your tasks into smaller tasks. Each task implementation shouldn’t be more than 30 minutes. Start from simplest one. When you get more done, you will get motivated. It will keep your momentum.

4th Law: Make It Satisfying

Give yourself an immediate reward when you complete your habit. Make “doing nothing” enjoyable. When building a good habit, design a way to see the benefits. For example, when you remove a bunch of code from your project, enjoy with the feeling that you don’t have to maintain that code anymore. Congratulations! You eliminated a code that may introduce you a new bug that eventually you will have to fix.

Use a habit tracker. Keep track of your habit streak and “don’t break the chain. Never miss twice. When you forget to do a habit, don’t be demotivated. Just make sure you get back on track immediately.

You can use the same framework to break a bad habit: 1st: Make it invisible. 2nd: Make it unattractive. 3th: Make it difficult. 4th: Make it unsatisfying.

How did I apply this framework and how it can help you too?

I read many books, articles and watch many motivational videos about programming, and I followed good programmers on twitter.

I created a small project that can help me and other developers. I used twitter for that because Twitter is the website I visit most frequently and it fits the concept. I always tweet about that it should be a productivity tool, not social networking. Why do I think like that? Because I created a good timeline there. Whenever I visit my timeline, the people who do a great job inspire me. I learn many new things each time.

So how does the project work?

It was a fun weekend project. I created a twitter account named @developer_tips. Then I created a twitter application to tweet programmatically. I wrote a basic python script to periodically tweet developers’ mistakes and how to avoid them, bad habits, good habits, lessons learned in software development, some motivational programming quotes, advice and tips. You can see the how python script look like and you can get it to create your own Twitter app. Here is the link to the GitHub repository.

With this small project, what requires to have a solid developer mindset are obvious and visible to me and others. They are easy to get and attractive to remember because they are real lessons. They satisfy me because I apply them in my software development process.

If you also want to get some solid developer tips, follow the @developer_tips on twitter.

I hope they can help you.

Thanks for reading.