🧝🏻 ⭐️ 🤛🏾 Eight Important Programmer Habits 🙈 ⛸️ 🌈

“A person can become a person only through education. He is what education makes of him. ”
I. Kant

In my opinion, this quote is very suitable for programmers. In fact, a programmer is not just a specialist who is well versed in technical issues. A programmer is, first of all, a craftsman who creates code every day using his knowledge. Creating good code is impossible without the disciplined use of certain skills. And this regular use is what habits are.

It so happened that bad habits prevent us from living and working, and good ones increase productivity, and in general a person gets more pleasure from life. If you make an effort and start acquiring and pumping good habits, you will very soon begin to notice how you become a specialist of a higher level. But that's not all, your colleagues will also quickly notice changes for the better, and this will force them to learn and adopt useful techniques. When you work with code in a team, you can read the person’s attitude to work in each commit.

So, let's go through the eight useful habits of a programmer that will make you the best professional.

1. Do not repeat (DRY - Don’t repeat yourself)

You probably came across the fact that, looking at the next section of code, you think: "Hmm, here I already did something similar, but with different arguments, and in general there was a different data array."

This should be a call to you that this code will be repeated in the future, again with small changes in conditions and data. But if you do not pay attention to this signal or are in a hurry, then most likely you will write the algorithm again from scratch when a similar solution is needed in the future. Gradually, such algorithms will accumulate, the code will grow, and in the end you will completely lose the motivation to make edits and improvements in such noodles.

Therefore, develop a good habit of following the DRY principle (Do Not Repeat). Whenever you catch yourself writing a similar algorithm, take the time to think over several possible options with different entities. Organize a small generic function or even a class if the algorithm is complex. This will take a little longer than writing a quick solution for a specific task, but it will save an incredible amount of hours in the future for debugging and testing.

Gradually, a whole library of such blanks will accumulate in you, and you can easily use them in any project.

Programming as a whole consists of such small efforts that are performed in the process. Make yourself squeeze out a little more than what is currently required. Then you will begin to grow.

There is a whole list of similar principles that are very useful to adhere to. But, in my opinion, DRY is fundamental for everything else in the work of a programmer.

2. Once you have decided that everything is done, refactor

Most programmers, especially beginners, believe that their work is done as soon as the code begins to perform the task as intended. Only now the word "made" includes a broader concept than the trivial writing of code.

Does the code work correctly? Yes! So what's the deal?

Yes that's right. Just before you move on to the next task, review what you wrote. From the beginning to the end. Most likely, you will notice that some variables are declared in an inconvenient place and it is not clear why they are needed. There may also be a too long line that does not fit into the screen, which means that here you need to think about how to make it more beautiful. Or the function turned out to be too voluminous and can be divided into a couple of parts.
Think about the people who will read your code in the future. Whether they like this code or no beer can’t figure it out.

Make a beautiful decision, not just a working one. Just like good writers after writing a draft: they read their work several times and throw away unnecessary parts to make the reader like it and grasp the point without having to go into too much detail.

I highly recommend reading Robert Martin on this topic . An enlightening book that should be in the library of every programmer.

3. Focus on business tasks

Many programmers tend to focus on studying the technical side of their work and believe that business has nothing to do with them. The main thing is to give good technical specifications, and then I will do everything in the best possible way. Only in order to become truly a master of your craft, you must understand why what you are doing has taken the business.

If it is very rude to imagine a programmer who works purely on TK without understanding the essence, then an example can be given. The bus driver, next to which the passengers sit and tell him: "Turn left, turn right, now right." And so the passengers “drive” the bus. But if the driver takes the initiative and asks: “Where do I need to go?”, Then the passenger can simply say: “We are going to the city N”, and everything becomes much easier. The driver knows the final destination and can, using his experience, independently build a route and tell himself where and how to turn.

Oddly enough, but many programmers do not bother to understand the purpose of the project. And, on the one hand, you can understand this point of view, because programming is a very difficult mental work. Sometimes knowledge of your instrument occupies such a large part in the mind that there is simply not enough resources for everything else. So it turns out that programmers, like drivers in a tank without a viewing window, can only turn the knobs when the crew commander hammer on them.

Also, understanding the business problem will not let you plunge into the development of something completely unnecessary at a given time. For example, if the task is to make a function that helps to compile statistics when passing the tests, then, knowing that this is not a performance-critical task, you no longer need to spend time on unnecessary optimization and speeding up the algorithm. All the same, this will not affect the final result. Tests will only be run by developers, and only once a week.

Another example, if the program has a function that all users run several times every day, it makes sense to spend more effort on working out the ideal version of this function and its ideal accessibility in the interface. Here you can already spare no time.

But, you see, from the point of view of a programmer who is not familiar with business tasks, both of these tasks will seem equivalent.

For a better understanding, I advise you to read the book “Start with Why” by Simon Sinek .

4. Small commits

The fact that a programmer needs to use a version tracking system, I think, is obvious. I want to talk about another very useful habit - this is to make commits as often as possible and in as small portions as possible. At the same time, add meaningful and useful comments to each commit.

Often, beginning programmers and even more experienced ones just at the end of the day make one push with all the changed files and some kind of useless comment like “fix issue29”. Or "fixed a bug in the request." No one from such a description will understand what was done specifically. And when the time comes to merge such a large commit into a common branch, the owner of the repository, firstly, mentally obscures the lazy developer. Secondly, if a conflict occurs during the merger, it is likely that the owner will simply roll back this commit and not accept it. Who wants to get a portion of bugs from the fact that he misunderstood which condition turned out to be superfluous when manually resolving conflicts.

On the other hand, if you regularly push your changes once an hour and provide each commit with a more detailed description, so that in the future it’s easy, without looking at the code, to understand what you changed and what considerations you had about these changes, then you will reach a new level of understanding of the general philosophy of writing code. Now you will not just “repair the primus”, now you will become part of the creative team and will communicate with your colleagues through your commits, just like in a chat. This will be a meaningful dialogue.

As a literature, I highly recommend reading at least the first chapter from the book “Git for a Professional Programmer” by Scott Chacon and Straub Ben. When you find out what wonderful functions there are in Git and what it is capable of, then it remains only to commit more often, and the rest can be settled with the necessary tools.

5. Count the time

Any work has a beginning and an end. The effectiveness of a programmer is measured in the number of hours necessary for him to solve certain problems. The faster the tasks are solved, the better. This is quite obvious and does not require any explanation.

But there is another side to this evidence, which often eludes programmers - you need to accurately calculate the time spent on the solution. Not what you feel when you sit at work from nine to five, interspersed with seals and meetings. And the present is your work.
At the very beginning, I developed the habit of counting time by simply writing down reports about what I did during the day and figuring out an approximate time. Even then, I roughly calculated that I only get 4 hours out of 8 to work effectively.

And then he installed special programs that counted the time automatically. At first I used www.rescuetime.com . Thanks to this program, I saw that social networks, although it seemed like a minor waste to me, actually really spoiled my performance picture. In the end, I decided to disable access to some sites completely during working hours. For this, there are also special plugins in the browser.

The next step in time tracking was required when I decided to fix the exact time of work with the program code. For this, I first tried hubstaff.com . As it turned out, a rather expensive solution if you use it when working in a team.

Then tried wakatime.com. And it turned out to be that silver bullet. This service has the ability to integrate into all popular IDEs, as well as integration with github. As a result, you can determine with accuracy up to a minute how many useful minutes you spent programming. In addition, there is a binding to commits. It’s just wonderful when you can see not only the commits themselves, but also find out the time spent on this commit.
An amazing collection of recipes for the correct organization of time and work on projects is in the book "Jedi Techniques" by Maxim Dorofeev .

6. Stability is a sign of mastery.

As you probably already understood, you can endlessly develop your skills and abilities. What you did a year ago may seem ridiculous and unpretentious in terms of your new experience. You, of course, will have improved ways to write complex expressions.
But among all this, you must develop the habit of sticking to certain rules. Even if they do not seem to you completely worked out, use these methods of work everywhere.

Using the code example: if you decide to use a specific scheme for naming variables or use spaces instead of tabs, then follow this principle constantly. You don’t need to try a new style every week and try to apply new advanced practices. So you just lose your focus.

The problem with inconstancy is that time destroys any software product. The longer a few people work on the program, the more changes are made in the process, which ultimately create chaos. If each of the team members does not adhere to a specific agreement.

So what needs to be done to abide by the principle of constancy?

The first thing you need to adopt is to adhere to a definitely style in the code. At JetBrains editors, I really like the tool that indicates the quality of your code. I used to be scared of so many warnings, but when you start to follow the advice of a linter in a disciplined manner, then the code becomes clear and aesthetically pleasing.

Also study the literature on how to name classes, methods, and variables. I recommend the book "Perfect Code" by Steve McConnell.

At one time, I read this book for half an hour in the evening, when everyone else was already leaving home. The book was in the office library. Just a couple of months later, I saw all the horror that I had encoded before that time. I had to gradually introduce new techniques and conduct refactoring.

7. Do it once

“I'll fix it a little later.” Each of us pronounced this to ourselves when we encountered a bug in our code or an insufficiently correct condition for processing in a loop. And each of us knows that this "fix later" and then remains in the code in the form of commentstodo. And when you yourself see code comments in the styletodo, it only means that someone does not follow the principle of "do here and now." At the moment this comment was written, the programmer most likely very well understands what the problem is and how to fix it. Because it is in the context of the current task. But if you return to this section of the code later, it will be more difficult to understand why such a reservation was required.
Therefore, make a very important habit for yourself - to work out the solution from scratch until the task is completed in full. The most complete - because it is really unrealistic to cover all the options with one hundred percent. But at least don't leave room for thesetodo-comments. After all, if you came up with and took the time to comment, it means that for the next step - implementation - there is very little left.

A good way to understand that you really have finished this piece of code is to create a test to check for several incoming conditions.

8. Never stop learning

This, it would seem, is an obvious skill needed by any specialist, not just a programmer. But, unfortunately, many forget about him. Sometimes, I ask my friends who is involved in programming, what books they have read recently. Often, many begin to recall with difficulty what they read a year or two ago. At the same time, they mastered a couple of tricks at the university or at some courses and use it all the time.

However, if in such a rapidly developing sphere you stop at least once a month to get acquainted with a new tool, technology or an interesting concept, then after a while you may find that you literally do not understand what is happening in the present.

This happened to me once. I developed one successful product and sold it for a while. Of course, I heard stories about new frameworks, but I did not pay much attention to them. He was deeply immersed in the development and support of his solution.

Only when the flow of customers decreased did I realize that my product needed to be modernized. And then I ran into a huge barrier. I used to use only PHP and very rarely AJAX functions. And to understand the modern React, Angular, Vue JS frameworks, I needed to urgently spend about a year to study them through books. The most interesting thing is that if I had devoted enough time to training before, then my product would not lose competitiveness. It was just that instead of supporting old functions, it was necessary to learn new ones and introduce technologies gradually, and not in such an emergency mode.

Conclusion

Even if you are one hundred percent confident in your skills, remember that there is no limit to perfection. Do not stop asking yourself provocative questions. Admit to yourself that in some areas you have insufficient training or you do not know the subtle points in the familiar frameworks, but you would like to know them. Spending a couple of hours and running the test version directly from github on the local server is now very easy.

In such small experiments, you will train your skills and develop all important habits.

Eight Important Programmer Habits