Sign of June #1 “With checkers naked”

Sign of June #1 “With checkers naked”

Sign of June #1 “With checkers naked”

Against the background of the question of what is the difference between June and midle, the idea came to mind to take a slightly different path – to describe what, in my opinion, are signs of June. That is, those things that characterize Jun and can be markers both for those who evaluate as an employee and for those who wanted to grow from Jun. To collect them together, I add the tag #примета_жуна. It will be possible to collect them.

Consider a common story: there is a project that has already gone into production. The project can partly be called legacy, because some modules do not get away from sin because “that’s how it works.”

A new engineer with burning eyes to make the world a better place is hired for the project. He is assigned a task: you need to add one more attribute to one of the basic entities.

In general, the task is not very difficult, you can even say it is ideal for entering the project – because you will have to go all the way from adding a new field to the table to showing this field externally through the REST API.

And here, in the course of solving this task, our engineer begins to improve the places near which he is located. Small refactoring there, small refactoring sem. There I corrected the imports in the neighboring class, there I deleted the method that is no longer used. Created readable variables instead of some magic strings hardcoded inside.

And it would seem well done, because after that the project became better and cleaner. Or not?

And here, before reading further, I suggest you think for yourself. Did the new engineer do well or not?

I think everyone has already had time to think.

My answer is NO, the person did not cope with his task. Why? Because instead of doing only what he was told, he went to do something else. Wasted too much time. Or maybe this new functionality is already waiting for PRODI and the engineer’s self-activity is delaying its delivery.

Moreover, most likely, this refactoring will be of a local nature and will not solve the problem holistically, but only superficially.

It is very difficult to conduct a code review in such cases, because you need to find exactly those changes that solve the task.

Above, I assumed an ideal situation for consideration, that the additional activity was in the case and did not break anything, because this is often not the case. And this means that you need to spend even more time on the code review to understand that other changes will not break anything and we will not shoot ourselves in the foot on PROD in the next release.

And all this means that it will be necessary to carry out a more detailed regression from testing, which again burdens the team unnecessarily.

What’s more, it’s quite possible that those improvements weren’t needed at all. This happens often. And the work is done.

Here, of course, you can say, well, you are criticizing, so you suggested what can be done!
I completely agree, such things should be discussed with the team and if there is a need for improvements, then you need to create separate tasks for this and conduct them in the perspective of working with techborg.

We assessed the technical debt, sorted it according to priorities and are taking it step by step until the next sprints.

Of course, colleagues, I am waiting for your opinion in the comments)

Javist Roman | telegram

Related posts