Seasoned Pros

$1 for tapping the pipe, $100 for knowing where to tap

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.

Seniors should have more experience, which equips them to comfortably dive into fires and stay cool under pressure. The value is the "seen this, been there, fixed that" factor.

You get that hard when there is no one else coming to save you. The systems need to be up, the company is losing a million dollars a minute, and everyone is turning to you to formulate the strategy to fix it.

I think you’re right. I’ve been a lead dev/architect for a while. I am not better at coding than my co-workers who are junior to me. In many ways they are better than me in that they come in with a fresh perspective, new ideas, and lots of enthusiasm.

In my mind, the main differences between the roles come down to soft skills, getting comfortable with and staying calm with uncertainty/gray areas, and being good at asking for feedback and listening. These are all things you just end up learning.

Here are some of the things I’ve had to do a lot more of as I got into a more senior position:

• Getting a “feeling” for how technical decisions will weather over time given past experience.
• Being able to effectively listen to stakeholders and really understand their needs. Asking good follow-up questions and communicating my understanding in non-technical terms they can identify with. This often involves coming up with differing scenarios and seeing if the behavior the system would have is what they really want.
• Getting comfortable working in grey areas.
• Seeking feedback and ideas from the engineering team and stakeholders. Iterating on a design and incorporating the feedback.
• Trying to tease out the best direction for the architecture that will be most likely to meet current and future needs, stand the test of time, and be less likely to accrue too much technical debt.
• Staying calm when external circumstances change in unpredictable ways. Planning how to adapt to the changes in the most effective way. Determining whether future changes in a certain area are likely to occur given company direction. Guiding the architecture to more easily be able to accommodate those kind of changes in the future, if they seem likely.
• Being a mentor for the engineers. Trying to always make myself available to help. Being willing to dig into the weeds to figure things out. Feeling invested in their success.
• Coding. I still code a lot as well. I think this is important. First off, I like coding and making things. Architecture designs are great, but they’re just an idea, not something that can readily be used. Additionally, architectural decisions that don’t take into account the actual experience of coding them are not likely to lead to good outcomes. Sometimes, I can come up with something that sounds great. Then, when I try to scaffold it, it turns out there is a better way that will be much more pleasant for all involved.
• Being humble. I don’t know everything. I’m not always right. We are successful as a team when everyone is involved and listened to.

I hope this helps. My career path kind of just happened and I learned along the way.

Part of being a senior developer is knowing when to act. Can you do it? Probably. Is it worth the time and money? No.

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.

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.

When the worst case is to lose your job and never deal with the legacy code again.