If you're joining a big/complicated/legacy project, and want to make changes (or even get anything done), Chesterton's Fence applies. https://fs.blog/2020/03/chestertons-fence/ There will be many things that don't make sense or look wrong initially. Its possible that they *are* wrong, and you can improve on them. The key to productivity is being able to demonstrate that your prospective changes don't break anything,…
"Hey this looks weird"...That's because I wrote the code at 4am after production being down for 12 hours. It was meant to be a quick fix, but no one wanted to touch the code and I was sent to another project for 6 months. So yup, my stupid hard coded code is still there, and yes it breaks on leap years on February 28th...I put it in the story I wrote.
For some reason my worst code ends up being used the longest. That solution I wrote code for about 14 hours straight to save about 100 hours of wasted dev time per week. I put a note with a date "yell at me if you see this in a month", because I meant to improve it...but re-priorities took me away. Three years later I am fixing it, most of the code is trash, bad decisions made, some horrible configuration assumptions. Part of it was inexperience. Now I know any code I write might remain in the code forever...