Five Habits Every Programmer Should Take On

And how to properly take advantage of them for success

Picture this:

You’re sitting at work on a Saturday near the end of a long shift. Your boss comes over and tells you that you need to have the updates for the new company web-app published by the end of the night! You’ve been working as fast as you can, but there’s still so much more that you need to do and there is no possible way you can get all of it done on time. As you sit at your desk, crying over your old computer blaming everything but yourself, you think: “Is there anything I could have done differently to get done on time? Is there some genius out there who can tell me important things I should be doing in order to reach my goals faster?” And through those questions, you find me! Me and this amazing blog post about how to increase your programming productivity and workflow.

Habit One: Focus on the Company

It is very common for programmers to get lost in their code. They focus on creating the best possible thing in their minds, forcing their mindset into the technical processes of creating and managing code they can be satisfied with. While this is a good way to think, it is not the best solution when working on/for a business. Instead, a good programmer should think about how their code is helping the company. Think about what the code is being used for, what impact it will have, and why it is even needed.

While working on code, instead of going deep into details and sidetracking yourself with “bonus features” that you think the company would like, you should think to yourself “Is this worth my time? Is this actually something that the business needs? How can I write the best solution possible to solve this problem while avoiding any excessive code that is not required?”

All of these thoughts will prove very useful when working through company code. Do what is needed, nothing extra, nothing less. Any extra work you throw yourself into when it was not asked of you is only going to slow you down and cause you to drag the company behind schedule.

Know what is required of you.

Habit Two: Do NOT Repeat Yourself

This may be one of the more commonly known processes in programming, but it is still very underused. Don’t Repeat Yourself, or DRY for short, is the principle that there should never be any code that is repeated or reused. Why write something twice when you only have to do it once?

Writing DRY code can be very simple if the process is done right! Before you code, think what you will need and how you can achieve it. Will a complex equation need to be used multiple times? Turn it into a function. Is this variable going to be used in multiple places? Make it global. When writing code, one of the best and most important practices should be minimizing repeats and ensuring that the code is clean. A program that is constantly using the same methods inside of different functions is going to be longer, messier, and slower than if those methods were turned into a single function that can be called numerous times.

It’s easier to edit one line than thirty.

Habit Three: Comment, Comment, Comment

It’s absurd how often you will come across code with no context about how it works, why it’s organized the way it is, or what purpose it has. Although comments are such an obvious feature, nobody uses them! You don’t have to use them everywhere to explain every little detail in your program, but there shouldn’t be zero description of what code is doing either. There is a balance to it.

Explain why you are choosing to use this method instead of one that might be better. Describe what a function is doing if it seems like it might be complex. Think not only for yourself, but as a co-worker. What if someone were to be reassigned to your project with you and had to jump into your code? Could they easily understand every line and function? If not, it’s time to throw in some explanations!

Every comment will be useful, no matter how simple.

Habit Four: Strategize

There’s a major tendency for programmers to just jump into their task, coding as they think and fixing as they go. While this may work for some, it is not the best way to get things done. Planning as you go is not only slower, but it also creates more road bumps down the line that can cause numerous problems you have to go back and fix.

If you plan out your entire task, piece by piece, segmenting it into easy to do sections, the job will be so much easier. Know what needs to be done, decide how you can properly meet this requirement, and then you can set out to complete it.

When planning, make sure to section out your tasks. If your plan only consists of one big step, it will seem more daunting and harder to take on. The smaller and more concise you make each individual task, the more it will seem like you are doing. Completing each part will fly by and let you know how far along you are so you can have a more accurate time frame of when you will be done.

A great creation starts with a great plan.

Habit Five: Never Go Back

Now this fifth and final habit might sound a bit strange or even flat out wrong, but hear me out first. Everybody gets stumped on a problem or bug at some point in their careers. They’ll always say “Oh I’ll go back to it after I finish all of my other code first” or “Yeah I’ll fix that later”, but will later ever come?

Code should be worked on from start to finish. Bouncing all over the place in your programs will confuse you, slow down the process, and in the end create more bugs than if you had gone through piece by piece. Keep your focus on finding a solution rather than putting the problem away for a later date.

Each section of your code should be written, tested, refactored, then tested again before you move on. Doing so will ensure that there are no bugs or issues and allow you to focus completely on the next segment without worrying that the problem is coming from any previous lines. If you were to bounce around going back and forth between different functions, how would you know what the root of the problem is?

It’s better to take a short break than to skip over the issue.

TL;DR

I know you’re lazy. You are a programmer after all. If you’ve found this blog too long or tedious to read, here are the key takeaways to make yourself a better programmer for your workforce:

1. Work for the company — Work on what should be worked on, don’t write excessive programs when they don’t need to be, and think: “Will this improve the business?”
2. Don’t repeat yourself — Code should be simple and easy to understand. Avoid rewriting anything when it only needs to be done once.
3. Make comments — Think about your code from a third party’s point of view. Would you understand it if someone just sent it to you with no context?
4. Plan ahead — Don’t go into things without thinking. Create a well thought-out strategy before you tackle your project.
5. Finish your code — A good programmer should never go back in their code. Bugs should be fixed as they arise. Work in sections, writing, refactoring, and testing each before you move on.