It helps to be a little bit stubborn, but mostly, remind yourself it’s just software at the end of the day too. So many devs are judgy and think there is only one “good” way to solve a problem, which ends up creating a sort of tunnel vision. As soon as you let that go and just know that every problem could have any solution, especially the unexpected, you see your way through faster.

It doesn’t matter if the way it was working is “right” or not, it was working, for reasons, so fixing it, is just teasing out those reasons. Be it from humans that may still be around, but most of the time, by feeling the code out.

I even see the struggle externally from afar when companies I used to work at release a new feature that touches very legacy code and, time and again, the new feature is buggy AF. The new dev likely had no idea what the old dev was thinking or why, and thusly, breakage. Neither of them is right or wrong, the solution from the past likely was obscure due to constraints that no longer exist, the new solution can be done easier due to a plethora of libraries that now exist, and getting newEasy to jive with oldBespoke trips the new dev up as they unravel what looks like pure chaos.