Looking back at my old code is something I like to do fairly often, it is encouraging and shows me how far I’ve come. It is also good to be reminded of the projects I have worked on in the past. There have definitely been points where I could not understand it, but it happens less often than I would think. The biggest/most important thing I’ve learned about good code and good comments is you don’t put what the code does in the comment, you put the reasoning for why the code is there to begin with. This has helped me tremendously. As for bad practices, I think the worst of all is when a code base forever grows in complexity, especially when teams are working on it. I often see that instead of taking time to re-do code that is no longer serving a team, it is often just expanded or split into another branch of logic that then also needs to be updated every single time once there is a change. This happens at work where there are multiple Jenkins files, because there was a point where the versioning was causing issues, and now once something is changed it needs to be updated in 4 different places and is always a headache. Which could have all been solved by taking a few extra minutes to refactor and simplify the original code.
