Did you happen to write code, then understand that you could make it more understandable or productive, and then you begin to process these lines of code diligently? The catch is that you are not happy with the result again, and you think to yourself: “Here you can better name a variable, it’s better to put it into a function”, and further down the list. As a result, you spend a lot of time, and the code becomes only more understandable. It turns out that you adhere to the “inverted” Pareto rule: spend 80% of your efforts and get 20% of the result. By no means do I urge you not to refactor the code while writing it, but you need to keep in mind that face of time, after which you honestly can tell yourself that you can’t do everything perfectly now and that you will move on in solving the problem, and after When you come across this code again, you may already have a different opinion on how to organize this piece of code, and then you will do it quickly.
Sometimes a programmer, after reading the article “tricks and optimizations”, begins to use the solutions found everywhere without thinking about the disadvantages of the tricks. Optimization is the opposite of refactoring, because optimizations make code easier to understand a computer, and refactoring – for a person. And each time you replace the division by two with an offset or cunningly store two values in one field, it is worthwhile to understand that you will save 1 byte of memory or nanoseconds of processor time, but you will lose the ease of reading the code, which will complicate support for the component.
Solve the performance problem as it arrives, because, possibly, no optimizations will be required. The additional delay that results from the lack of these optimizations may not be felt by the end user.
Everything is simple here: always, before solving a problem, check if someone else has solved it. Yes, writing your own is always fun, but the amount of time and bugs that you end up with is often not worth it.
IT is an area where something new appears and changes quite often. This can be new approaches to solving problems, frameworks, algorithms and much more that can speed up and simplify the work.
To avoid numbness, it is not necessary to read something about IT every day. It is enough to attend conferences or meetings every six months / year to listen to how various problems are being solved in other companies or to read thematic blogs.
"The lone ranger"
Surely you have come across or will come across a person who wants to do all the work himself and does not trust anyone else. The whole problem is that one person cannot "close" all the tasks of the project, and the throughput of the project will be greatly limited by one person. In addition, such people do not grow careers, as there is nobody to put in their place, because no one knows the specifics of this project, and the ranger does not allow anything else to be done in this project. Despite the additional costs in the form of communication, try to work in a team – this simplifies the work of both you and the project.