> Learn about Chesterton's Fence. Then, actively resist altering a given situation before you understand the reasons why it's remained unchanged for so long. T

> Learn about Chesterton's Fence. Then, actively resist altering a given situation before you understand the reasons why it's remained unchanged for so long. This is probably the most important advice for developers who start a new job, or have to work with existing code. Trying to refactor code or replacing it with a new micro service requires that you understand the old code. If you are not willing or able to take the time to understand it, you do not know enough to replace it. I have made this mistake several times in the past, but it has taken time for me to learn this lesson. I have complex data flows and error handling and thought I could simplify it or rewrite it as a new service. I would later find out that the old code handled scalability, edge cases or unknown external dependencies that my new code did not. These issues appeared in small "drips" over time, so it was easy to focus on the individual bugs instead of noticing the larger pattern. This led me to believe that the next rewrite would turn out better. The real lesson is that I did not know enough about the existing code and made assumptions that turned out to be incorrect. Sometimes you need to make changes because the old system has started to "rot", which makes it hard to add new features. Just make sure that it is accidental complexity and not necessary complexity.