Useful developer habits

Thanks to which you will become better as a programmer

Each developer has habits related to writing code – both harmful and useful. But if you make the right habits, it will help to seriously improve the efficiency of working with code. Such habits will affect not only you, but most likely your colleagues as well.

As Denis Waitley said, “You cannot get rid of a bad habit, but you can replace it with a good one.” Therefore, I offer you a list of seven habits that I think will help you become better as a programmer.

Translated to Alconost

1. Do not repeat

Surely this has happened to you more than once: you look at a piece of code and see that it very similar to the fragment that you once wrote.

This is a bad omen: repetition should be avoided. Duplication of code is a bad tone, because such code becomes more difficult to maintain over time, as corrections have to be made in several places. As a result, the likelihood of errors creeping into the code increases.

It’s good practice to follow the principle of “DO NOT REPEAT”, or DRY (eng. “Don’t repeat yourself”): if you start writing code that is already in another part of the system, then most likely you need to refactor it. Divide the code and logic into smaller reusable blocks and call them where necessary.

2. Wrote – refactor

Most programmers, especially those with little experience, think that if the task is completed, this means that the code works as intended. But in order to “complete” the task, it is not enough just to jot down code that implements a new function.

But if the code works, what else is needed?

Well yes, it works. But before moving on to the next task, you need to refactor: this will improve the readability of the code. Indeed, this fragment is probably not the most accurate and obvious of the ones you wrote: something may be immediately understandable to you, but how will this code be seen by others? Be critical of your creation.

In addition, refactoring helps reduce code complexity, which simplifies maintenance. And in the future it will pay off.

3. Focus on business objectives

Developers, as a rule, are so immersed in the study of the technological stack that they lose sight of the tasks of the business – however, we must not forget about them. Remember what purpose Do you have a project you are developing?

Some developers are only interested in the technical aspects of their work. They are not concerned about business and economic factors, the presence of which, in fact, gives them work.

What is your working time spent on? Do you benefit the business – or spend too much time on the fact that in fact it is not very important? Ask yourself this question more often.

4. Small commits

If the scope of the commit is small, this allows you to give it a clear description. Everyone understands that “a couple of errors have been fixed” is bad description yes?

Small commits simplify debugging: you can roll back to the previous commit and check if there was an error in it. And if there is not much code in the commit, then it will be easier to search for an error.

If the commits are large, the result can be various troubles and inconveniences. If changes in one commit affect a lot of things, then it becomes unclear what exactly has changed.

But someone will have to check this code, and he (or she) will be scared to do the merge, because too much in the commit can potentially disrupt the rest of the code.

Therefore, in the case of small commits, code verification is greatly simplified: checking one change at a time, it is easy to figure out what has actually changed.

5. The main thing is uniformity

If you decide to name variables in Camel Style, do not back down from this rule. Want to use spaces instead of tabs? Forward! But no matter what you choose, stick with it everywhere.

Over time, it becomes more and more difficult to understand written software: the longer a project exists and the more people work on it, the more clutter in the code. Therefore, lack of uniformity creates problems.

What can be done to maintain uniformity?

Firstly, you need to choose a certain style of design and stick to it. You can use code analyzers – linters – which will check what is written for compliance with the chosen style.

Secondly, stick to the uniform naming of variables, methods, and classes. More on how to give good names is in my article.

The main thing – remember: the convenience of maintaining the code base is very much dependent on the uniformity of the code!

6. Do not leave “for later”

“Okay, I’ll fix it later,” sounds familiar? We all know that such “later” often turns into “never”. If you see the comment “TODO”, it means that someone left something for an indefinite “later”.

Work on a code snippet or user story from scratch to completion.

But what does “before completion” mean?

First of all, this means that the code has been refactored, as mentioned above. In addition, the code needs to be tested. And testing for most developers is perhaps the most unloved part of the job. At the same time, it is not enough to go through a scenario that includes only the provided actions – be sure to check other options as well. And you can make a little more effort and write a couple of automatic tests.

And the last one is the documentation. Do I need documentation for this particular function? Have you explained to the tester how to test this feature? Does he (or her) need to know about any preconditions?

7. Do not stop learning

New technologies appear every day. Sometimes it may seem that keeping up with all the trends is impossible. However, you cannot stop learning new things: as soon as you stop learning, you will stop growing professionally.

Learning the new is the only way to remain relevant in the labor market in our technological era of constant change.

“You will not grow if you do not try to do something beyond what you already know perfectly”
– Ralph Waldo

About the translator

The article was translated by Alconost.

Alconost is engaged localization of games, applications and sites in 70 languages. Native-language translators, linguistic testing, cloud platform with API, continuous localization, project managers 24/7, any format of string resources.

We also do promotional and educational videos – for sites selling, image-building, advertising, training, teasers, expliners, trailers for Google Play and the App Store.

More details

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *