Although developers know the best practices for good code, I keep seeing some fresh code that is the exact opposite: difficult to understand, with unexpected side effects, not documented, insufficiently tested. This becomes a problem once we have to change this code again to add new features or to fix bugs. In addition to the effort to make the actual change, we still have to invest time to understand the code and make sure we don't accidentally change other functionality.
In this talk, I share my experience in dealing with legacy code in uncharted territory. I'll show approaches to decipher code you don't understand, how to make code testable, and the three principles I follow for every code change. With this you can start tomorrow and make your legacy code future-proof, even if management doesn't give you time for refactoring.