We all don't like to look at the code that we wrote half a year ago. More than that, we don't want to work with code that someone else wrote. This article is about the fear of refactoring someone else's code that some developers have. It's my observation and thoughts based on work with different people in different teams. I will try to answer questions: why some developers doubt against refactoring, why is it wrong, and how to overcome it. Small spoiler - team lead is responsible for this.
The article may be useful for self-doubt middle SE and team leads.
Sooner or later, we all find ourselves on a project that has already been partially written. It can be at the production stage; the person who started the project can already not work on it. Some people will quickly start to change and figure out the new code. But there is another type of people: if they do not understand something, they simply pass by this section of the code. They do not notice flaws in the code, and even if you show them that something can be improved, they don't want to do it.
I want to talk now about the reasons behind such behavior. After all, such an attitude will not lead to anything good.
I have seen such excuses:
#they know better or code-trap
Seeing a strange, incomprehensible code, they are trying to justify it somehow, come up with sometimes weird reasons why it is written in such way and that if they touch it, the application will fall apart like a house of cards.
#i'm not that good
or if you exaggerate, the thought "I don't know anything," an inferiority complex, an impostor syndrome. Call it as you want, but it does not change anything: you doubt yourself, your knowledge, and experience. At the same time, you think all others are smarter than you. And most importantly, you believe that person, who wrote that code, is a better developer than you. This is all because the new project is not yet familiar to you, codebase seems complicated, and the person, who wrote this code, obviously looks like a genius.
#laziness
There's no need to explain; often, you don't want to touch any part of the code because it will take some time to rewrite and test it, even if it will take a really short amount of time. And the developer eventually ceases to see problems because he does not want to.
The following two reasons are the lack of team lead.
#we were not told that it is possible
Sometimes developers are afraid to take a step to the left or the right of their task, because nobody told that it is welcomed and allowed, and sometimes even necessary to refactor code, that you see and touch, while you are doing your task. In small steps reducing technical debt and making the code easier to understand for yourself.
#fear of reducing their productivity
As you don't know if you can or not refactor code, you don't want to spend some extra time improving something, as you don't want to look like low-performer in team lead's eyes.
What will it all lead to:
#black box
Without dip dive into code, you will not figure it out, and some parts will be a black box for you. If you don't know how it works, then this is fraught with pitfalls during the development of new functionality.
#eternal code
Such code lives for a very long time, and fixing and refactoring it becomes more and more difficult.
#chaos
Such code may begin to grow with crutches; you fix errors with workarounds, introducing even more chaos into the codebase.
#the technical debt in itself will not be fixed.
The way out or how to improve the situation:
#team leader should do his work
The team leader should be the main driver, it is his task to straight people in the right direction and set up processes.
He should share with developers, that refactoring is not bad, that fresh ideas are good, that you can change written some time ago code.
The team lead should make it clear when you can spend 10-20% more time refactoring the code that accompanies your task.
#you should eradicate your impostor syndrome
Accept that everyone has some experience, and even geniuses can write imperfect code.
#you should be proactive
With each code change, make it a little better than it was before. No one forces you to redo the whole application. Just understand the incomprehensible code, make it more readable, even this is enough.
#conspiracy theory does not exist
Do not search for the deep purpose of the weird code; in most cases, it is the result of a compromise between "make it quickly" and "make it work".
#write it down
If it's not possible to refactor it now, do just a little - document it. Once created, a ticket will help you know the amount of technical debt and know the weak or gray parts of the project. Also, such tasks can be suitable for a beginner to start to understand the project code.
#your code your responsibility
Do not treat the code already written before you as something alien. You are now on this project, so now this is your code, and all bugs are your responsibility.
In the end
Every leader's task is to establish processes and let the team members know that they can refactor the code. The responsibility of the developer is not to be afraid to do this. For you, the code that your predecessors or current colleagues wrote is one big technical debt, and you need to figure it out.
Write a code, overcome fears.
P.S.: What do you think about it? Have you ever observed such situations in your teams?
Top comments (0)