Whether you are writing a competency matrix or a job description, or maybe you are a junior engineer and you want to grow into a senior role, it's sometimes kind of difficult to know exactly what the differences are between a younger junior engineer or associate engineer and a senior level engineer. In this episode and in some upcoming episodes, we're going to talk about the traits of a senior engineer, the traits of a senior engineer. Of course, I want to make a big disclaimer here that just because you might fulfill some of these traits does not mean that you are fulfilling these for your particular job, for your particular company. These traits are some of what are common, but not necessarily exactly what any given company is looking for. That's a big disclaimer. And some of the reason for that is that despite being a very large industry, software engineering has not really standardized entirely on levels. Some companies may have a senior level engineer or even a staff level or principal architect or something like that. At another company, that same person might be dropped down to a senior one or not even a senior engineer. So there's a lot of different criteria that go into this. But the important thing to recognize here is some of the themes that we'll be talking about, typically, they typically only start to show up in the more senior roles. Now, importantly, some of these themes might be something that takes time or experience, but most of what we're going to talk about in these episodes are things that you can start practicing. No matter what level you are, right? You can start doing these kind of senior level activities or portraying these kinds of senior level behaviors, no matter what level you are currently as an engineer. The first trait that I want to talk about, and we're going to kind of contrast this, the move from a junior level to a senior level, the kinds of things that you would see a junior versus a senior doing, that move goes from static. To dynamic understanding of situations. Static understanding to a dynamic understanding of situations. Now, situations in this case does a lot of the heavy lifting. We're talking about decisions. We're talking about problems. We're talking about software. We're talking about people. These are all different kinds of situations. And if you have a static understanding of a situation, that means you're taking kind of a snapshot. And the. Senior engineer thinks about why that thing came to be the way that it is. And more junior engineer may have, you know, no inclination to think about this. But a senior engineer knows that someone decided something for this code to be this way, or this person has gone through something in a past role or in their life that has kind of shaped them to be the way that they are. Additionally, the dynamic part of this. This is not just looking to the past, but also kind of trying to extrapolate out into the future. What is the trajectory? What is the trajectory for this code? What's going to happen most likely? And what are the possible risks that we that we can kind of foresee in the future? With people, they might be looking at a given person's skills or abilities and extrapolate out into the future. Does this person have the capacity to gain the skills that we would need for them to be 100% in this role? Maybe they're. At 90% and we need to get them to 100% more junior engineer might look at that 90% and kind of label that person with that 90%. In other words, they may not see them as qualified for a role. And you can see quickly how this becomes valuable. Another dynamic way of viewing situations is to zoom out of the details and look at the bigger picture. Now, at the risk of sounding like, you know, typical buzzword business speak, this really just means seeing how things fit together. Seeing what where does this particular decision or this particular piece of software, where does it fit in the bigger scheme of the whole software environment that it lives in? Where does this person fit in in the team and where does the team fit in in the company? And you can think about this dynamic model as kind of this three axis way of thinking both the past, the future and the zoomed out present. And you can also move. On the past and present axis at any zoom level. In other words, you could say, okay, we have a problem that we're trying to solve with the software today and more junior engineer might look at that problem and only think about the types of solutions that they know how to implement. And we're senior engineer might think about their problem and zoom out a little bit and say, how does this problem fit in with what we're trying to do more broadly with this with this service or, you know, with this particular interface. And then they may also. Zoom forward or backward in time and say, okay, at this level of thinking, not down at the level of that specific problem, but thinking about how this service fits in with the overall landscape. What happens in the next six months to a year? And how can that inform how we change the way we think about this problem, this specific problem or this problem and other problems like it. So as you begin to adopt the behaviors of a senior engineer, this is a very important one. Try to think on that three axis model. Think, you know, what, where did this situation come from? What is, what is the history of the situation? What happened before that may have led to this? Think into the future. What are the likely outcomes? What are the likely points in the future that we're going to see? Not just one future, but many possible futures. Right. And then of course the zoom out axis or, or kind of moving up away from the problem. How does this situation fit in? How does this situation fit in with the overarching situation that it's a part of? This is one behavior that will ultimately lead to many kind of cascade into many other senior level behaviors. And it dovetails nicely with many others as well. And we're going to talk about a lot of those in upcoming episodes of this show. If you don't want to miss out on that, go ahead and subscribe and whatever podcasting app you're currently using. You could do it right now because it's free. Subscribing to this podcast is totally free. It costs you nothing. And I hope that it is. Uh, giving you something anyway, uh, that is really the only thing that we request re we request is that you subscribe, uh, and you can skip the episodes. You don't really find that valuable. That's okay. Because we produce a ton of content. We're already at a 1,150 something episodes will easily surpass 1200 episodes this year. So there's a ton of content and a lot of it is probably relevant. If you're a software engineer, it's probably relevant. It's probably relevant to your career and something, even if one thing on this podcast helps you 1%, I can almost guarantee that's worth your time. Now if you want to gain the most value out of this content, I encourage you to do one of two things or, or both, uh, first discuss it with somebody else. This is a very important part of engaging with content like this, not just this podcast, but other podcasts you're listening to as well, because you begin to integrate the concepts that we're talking about. Now into your language. In other words, you start to think critically about what I'm saying. You start to find places where you agree or disagree with what we've said on the show. Uh, and that integration into your language is very important for this to actually become as valuable as it can in your career. The second thing is join the developer D discord community. This is another way that you can integrate this language into your kind of intellectual vocabulary. You can join that discord at developer t.com slash discord.com. That's developer t.com slash discord. Thanks so much for listening and until next time, enjoy your tea.