I’m only a regular so far, but my theory is that seniors don’t have that much more knowledge or skill - they’re just much more comfortable in putting out fires and don’t get as stressed when they don’t know what to do. I aspire to become as hardened as that some day haha
It often also takes the ability to tease out what things the code is connected to and organizing that information in ways that are useful for making changes without breaking everything.
It’s all about being comfortable with not knowing when you need to act. Believing that you can learn everything upfront is pure hubris, and once you hurt yourself enough times, you just drop the pretense.
In other words, life is Bayesian, not frequentist.
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.
I’m only a regular so far, but my theory is that seniors don’t have that much more knowledge or skill - they’re just much more comfortable in putting out fires and don’t get as stressed when they don’t know what to do. I aspire to become as hardened as that some day haha
$1 for tapping the pipe, $100 for knowing where to tap
You’re not paying for my hours, your paying for my years
It often also takes the ability to tease out what things the code is connected to and organizing that information in ways that are useful for making changes without breaking everything.
Senior: “Yeah, we can’t change that because it will break everything.”
deleted by creator
It’s all about being comfortable with not knowing when you need to act. Believing that you can learn everything upfront is pure hubris, and once you hurt yourself enough times, you just drop the pretense.
In other words, life is Bayesian, not frequentist.
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.
When the worst case is to lose your job and never deal with the legacy code again.
Lol! Yep!
We try not to say that part out loud in front of the customer, though.