Yesterday I began to compile a list of bad habits in which I would say that we have all fallen once and that they act as “brakes” in our goal of improving as developers. That is to say, in this article you will find a series of attitudes against which it is advisable to be prevented but that it is often difficult to identify: after all, it is usually a lonely job to develop and it is not usual that someone is pending to correct us. In addition, the sooner you are able to recognize them, the sooner you can get rid of them; You know how difficult it is to get rid of customs that we have been doing “all our life”.

So I hope this article helps you avoid the bad practices or shortcuts that I am going to talk about and that in the end, the only thing they serve is to delegate the mess to our “I of the future”.

Let’s see them!

“My code is the best”

There is nothing more that the ego swells us than that moment in which we are with other developers and it is our turn to talk about our code or how we would solve a problem (in our own way, of course).

While it is true that I am one of those who defend that the fair dose of ego (seen as self-confidence) is a positive value, I also believe that an excessive ego often causes us to be unable to improve (and there is a lot of this I think we tend to see our code as a kind of son that nobody can criticize.)
Therefore, if we enter into the dynamic of always believing ourselves better, we will be unable to value other points of view that provide solutions other than those that would occur to us, something that always brings:

• new knowledge
• greater openness of mind, that is, if we are able to see how others think we will have more resources when looking for solutions.

As the saying goes:

Your learning ends the day you start to believe that you have nothing new to learn

I do this “in 5 minutes”

We love to take “shortcuts”. If we can do something in one hour instead of two we probably choose the first option even if we have to sacrifice quality. This situation is often aggravated if where we work productivity is measured in lines of code or, worse still, in solved tasks. Does the concept of “technical debt” sound to you? Well, taking shortcuts is one of its causes.

I think that being a good programmer and in general a good worker (whatever the sector is) implies knowing how to distinguish situations in which it is necessary to sacrifice quality in favor of time and vice versa. That is, sometimes there is simply no time to write a code that respects all SOLID principles and is 100% reusable, but beware! The more you get used to reserve time to find the best solution (which is often not the fastest), the higher the quality of the code you develop and, above all, the less time you will have to invest to maintain them.

So if you have caught the bad habit of using shortcuts constantly breathe and get used to spend time thinking before writing. That or change company. 😝

“I am lazy to document”

The other day I came across the following phrase by Dick Brandon that he has little left to become a meme:

“Documentation is like sex; when it’s good, it’s very, very good, and when it’s bad, it’s better than nothing.”

As far as I am concerned, I have met few developers who like to document their code. Moreover, it is not the first time I have heard on the networks that many people do not document their code in order to feel irreplaceable and that nobody can do their job.

However, I think we should all get used to explaining all those parts that seem “magical” and whose raison d’être does not seem obvious from a first glance. This practice should be adopted by both other developers and by ourselves as:

• we will probably have to go back there at some point and there is nothing more tedious than searching the whole reason for a calculation or a certain check.
• Our job is to add value to our team and make things easier for the rest of our classmates, not to put obstacles to “feel better”.

Of course, as Robert C. Martin says in his book Clean Code: A Handbook of Agile Software Craftsmanship do not be tempted to write comments on any line (“silly comments”), but learn to identify the most complex parts and He explains the reason for having solved it that way.

Therefore, get rid of the habit of not writing documentation and set aside time to document your applications, APIs or write comments in those most confusing parts of the code. And please keep that documentation updated. 😌

It wasn’t me!

Let him raise his hand who has never exclaimed that phrase. When a fault appears there always seems to be an excuse instead of being mature enough to recognize that it was our fault.

Really, nothing happens if you fail. Nobody is perfect.

If we want to grow we must get used to fail and let ourselves be taught so as not to fall back into the same error. There is nothing better if we want to get stuck at work than to take the habit of blaming the cobblestone when a problem arises. “It was not me”, “the user is not doing well”, “nobody had told me that” are excuses that we have to abandon if we want to focus on improving and being more respected within our team. After all, nobody likes to work with someone who keeps throwing balls out as if nothing were with him.

I encourage you to remember this phrase:

“The sooner you admit your mistakes, the more time you will have to learn and solve them.”

It’s done

I think it is very common that we take for granted tasks that from the point of view of the client or the user are not yet resolved. We must not forget that because of our profession we are at the top of the pyramid that represents the skills to face a computer application but not everyone has that facility to move through menus or windows. Moreover, a great UX designer that I know whenever he says that all his interfaces are tested with his mother to know if they are valid.

Therefore, I think that we should get rid of the habit of thinking that as we have done it is the best solution and start listening to the rest of the world: the amount of information we can obtain from them is usually very valuable in order to address similar problems and It is another way to acquire new knowledge.

This of course also applies to “code reviews” and “pull requests”: we have to get used to hearing that something is not yet finished or could be implemented in another way.

Final thoughts

I think the best way to finish the article is to highlight a word:

Balance

Balance when assessing our code, receiving opinions and criticism from others and even when documenting our developments.

Going to extremes is an attitude that does not usually give good results. Learn to place yourself in the middle when it comes to a key aspect of your daily life and you will see how improvement and progress come alone.

Related articles