It is. You might pat yourself on a back that you're "not like them", and in fact might be better than them, but if they hold the same title and earn the same amount of money – they're senior just like you.
Great article. The key things often missing in meetings discussing a vague problem is do we really understand the problem and how do we make concrete progress. Its a hard skill and often just comes through experience - being able to put yourself in the user's shoes to understand their problem, and knowing based on past experience, how to execute. That is the value of seniority.
A very important skill for Senior engineers not mentioned in the article is an ability to take the initiative on something. For example, when a dev sees a bug in an area of code they aren't responsible for and thinks "I'll raise an issue for that and mention it to the product manager so we can get it fixed" instead of "Oh, a bug", then they're starting to show that senior mindset. It's a desire to make the whole of the software good rather than just the little bit they work on good.
beware, some cultures are territorial in nature and this kind of hard ownership will make people slap you if you ever try to improve things as they come.
i'm in the camp of improving things regularly without hesitation but again this can devolve. another way it can turn sour is when the team is made of people too different from each other. one improvement from someone pov is a waste or even a regression for others .. then it's a 'who decides here' conversation.
that said when you have a cohesive group all focusing on pushing in the same direction then it's bliss
Then that's a bug in the organization. If you're senior enough you might make the correct boss take notice and signal this defect globally (no fingerpointing) to him/her. If they don't care or answer you know where you are now and know if you consider that you want to leave or not.
I like this. I more generally look for reduces chaos.
I’ve seen the pursuit of disambiguation employed to deadlock a project. Sometimes that’s the right thing to do—the project sponsor doesn’t know what they want. But many times the senior needs to document some assumptions and ship something rather than frustrating the calendars of 15 people trying to nail down some exact spec. Knowing whether to step on the brake or the gas for the benefit of the team and company is a key senior trait.
This is a yes, and to the article; building without understanding the problem usually will increase chaos—though sometimes the least effort way through it is to build a prototype, and a senior would know when to do that and how to scope it.
I think a lot of people in the comments are getting hung up on titles and missing the real point of the post. The headline probably didn’t help with that.
The post actually does a great job of highlighting a genuinely valuable skill that the best engineers practice regardless of their title. In particular, “reducing ambiguity” is something I believe would be really beneficial for many early-career engineers to intentionally develop.
There's a difference between questions of cultural / technical difference and questions of competence or character.
In the end, if a junior is repeatedly not responding to appropriate guidance or advice, then that junior should be gone from that position. Same for a senior who is repeatedly dispensing inappropriate guidance or advice.
But it requires careful analysis of the situation before such a drastic course of action: is there a communication problem, a training problem, a mistake in evaluating abilities?
A senior should be able to navigate cultural and technical differences competently. A junior should understand that that the ones with responsibility for a project also have the authority to make decisions about the project, which should be honored.
Yes but there is also a temporal component as well. A Senior should be able to do all their tasks and whatever else comes their way without needing guidance. To be able to do that requires a certain level of time in position.
Disagree, it's not _just_ practice. You can do something for 10,000 hours but never actively try to improve. Does that mean you're now more senior because you had more volume of practice?
e.g, let's say someone spends 10k hours doing just 'addition and subtraction' problems on 2 digit numbers. Are they now better at maths than someone who spent 0.1k hours but doing a variety of problems?
To grow as a software engineer, you need to have volume + have this be outside of your comfort zone + actively try to improve/challenge yourself.
Apart from this, I do agree it's not 'innate talent' that drives someone to become a senior engineer, and I think anyone with the right attitude / mindset can do so.
There is no denying practice is needed, but... I've been doing this (getting to reduce ambiguity and simplify complex problems) since before my first job in free software communities, yet really, I wasn't anywhere close to "senior" when I joined my first job at a demanding SW organization at 22 years old.
There was simply a lot I did not know, but I had the talent to do this part well (sure, one can argue that I had "practice" doing this with any problem since I was ~10 years old, but calling that "senior" would be... over the top: I think it rather qualifies as "talent").
It took me a couple of years of learning good software engineering from my wonderful and smart senior colleagues and through my own failures and successes for me to become a Tech Lead too.
idk about titles, but my basic thought is that when you are less experienced, you're paid to do things, and when you are more experienced, you're paid to know things.
But it also depends on the organization. If your managers love to micro-manage, you will be paid to do things, because someone else believes they know better than you.
I suffered with this problem quite often with my previous job. There would be something vague assigned to me and I didn't quite get what to do but I also felt like if I asked questions, it'd give off a vibe like I didn't know what I was doing so I would just start programming and making a bunch of assumptions.
That wasted a lot of time which is a lesson to be learned from.
This is very common behavior. This is where a good manager can really help. They can recognize this is happening and then provide context.
One approach to deal with ambiguity is to write a short design doc, which writes down what you are trying to do, and all of the assumptions that you are making. If you don't understand the domain, some of your assumptions will probably be wrong. The stakeholder should be able to see that and provide guidance.
I struggle with this a lot. I'm currently about ten years in to the career and technically at my org I'm a "senior".
One issue I have quite often is I'll know I have a problem with understanding something and so I ask my team but then the response can be something like "you should know X" or "you should know this because of Y context" and it can be discouraging. I think a lot of the time I notice people conflate experience level with amount of context I have with something.
I'm still struggling with these kinds of challenges and I would readily admit it could be my own weakness but I also wonder if it's a team culture issue; but I've noticed this across my current org and my last one so maybe it's more of a me-problem.
It's subtle, but I think the use of "senior" rather than "Senior" in the article is an attempt to distinguish the concept of being a senior engineer from the title of Senior Engineer. The article is focused on actually being senior, not playing title games. I'd take it further and use the term "leader" instead of "senior engineer".
Leaders reduce ambiguity, so others can operate with more clarity. The ambiguity involved can be in many different domains. It can be focused on product and tech, as in the article. Another example is ambiguity around people and organizational structure, which is more common in management roles, where some in management are more effective leaders than others. It can be around finding ways for people to understand why they might want a product, which is more common in sales and marketing roles. And so on.
Eh. Whenever someone posts something like this, you get a bunch of folks, stating how they meet that description, etc. Sometimes, they do it humbly, sometimes, not.
In my case, I met that description on my first job, and I guarantee, I was not senior.
You see, my initial training was as an electronic technician (RF/microwave stuff).
That thought process described, was exactly what they trained us to do. Debugging a wonky RF board is about as ambiguous as you can get.
So maybe there's a different definition of "senior."
One thing that I would like senior colleagues to avoid is the tendency to claim something can't be done or is impossible. Sometimes, a colleague would claim something can't be accomplished but when I do accomplish it, it can create tension and give the impression that I'm undermining them. I would prefer if senior leaders instead enumerate the reasons why it can't be done and avoid dealing with absolutes. Often, it requires research into unknowns that have real limitations such as costs or processing time. Thank you for considering it if this is useful to you.
When everyone in the room wants to go in a certain direction. And you tell the team "9/10 times i did it that way it blew up in my face.", and you don't fight them and let it play out as a lesson. And there is still a 10% chance it could work!
Can someone who worked in multiple industries clarify: is it only software that has constant identity crisis with "what makes you X" and "what is expected of Y"?
The only thing that makes a senior are years of experience, that's all. You can be a shitty senior if you only do one thing for 10 years, but you're a senior nonetheless.
I think you’re being a little pedantic here. Even if we assume "senior" is an arbitrary title, the article is still a useful description for how to be effective as an experienced engineer. The title is the least interesting part of it.
Actually it's not even years of experience, I've seen grads with 2 yrs experience promoted to Senior with a minor raise because otherwise they might leave the company.
Licensed professionals don't have identity crises, their titles and what is required of them is legally enforced. The software industry has never lobbied for the interests of "engineers", the way other professions have (taxi drivers, barbers, plumbers, real estate agents, etc formed professional groups which lobbied for laws requiring official licensing). I think it's because software developers are the laziest people on the planet, and they are happy to continue doing almost nothing in order to get hired.
> The only thing that makes a senior are years of experience
The only thing that makes you a senior in software is whatever titles the companies you've worked for happen to give out (which may be inflated for various political or hiring reasons) while you work there and there are basically completely arbitrary criteria from company to company.
In terms of official job titles, I was a "Senior Software Engineer" like 2-3 years after I started writing code professionally, and I mention this not to toot my own horn in any way but to point out how arbitrary titles can be (and we won't even get into the debate over the 'Engineer' bit).
> The moment you hand them something fuzzy, though, like ...
> “we should probably think about scaling”,
> that’s when you see the difference.
Senior engineers should ask, "but do we need scaling? And if it does, how much needed now and future?"
But I've seen a lot of seniors who jumped to implementing an unnecessarily complicated solution without questions, because they don't think about it too much, want to have fun, or just don't have energy to argue (I'm guilty myself).
I like the post but I’d add senior is also the instinct to take risks. I was once at a client in NY with an ASP.NET code base that used the compile at runtime capability (like Java used to). The C# source was being pushed to the web server.
I ran a compile and the code was riddled with errors. So I went to the PM and explained the code needed to compile and I needed a day to clean it up.
I refactored the entire project to compile and deploy that way. After that the development went very fast.
The hilarious part was the three devs who’d gone on vacation came back and thought what I’d done was “wrong”.
But the client said we (consultants) had done in two weeks what they couldn’t do in six months.
> But the client said we (consultants) had done in two weeks what they couldn’t do in six months.
I think this is more of a consultant vs employee thing than it is senior vs not-senior. There's this weird dynamic that happens where BizOps defaults to trusting and spending more on consultants, granting them more autonomy, such that they're wildly more empowered to take any risk. Employees are to be delegated to by BizOps, and BizOps doesn't like taking risks. It's paradoxical, because unless you come in with that authority or you were there extremely early, you're unlikely to acquire it, much more-so after the company's been around a few years.
This seems to me where the term "hired gun" comes from. You pay someone who's incentivized to solve a discrete important problem with their expertise quickly, whereas all of your employees are incentivized to do things for amounts of time reliably over however long, answering to product managers, implementing whatever crap to get the sale, answering to useless managers every two weeks, planning, reviewing, retrospectiving, blah blah. The consultant isn't about to go doing a broad-scale refactor if they're not paid to, and there's no reason an employee should either.
You mentioned receiving approval after providing a persuasive justification - to me it implies that you were not in the position of making the decision, rather it was up to someone else and under their supervision?
Should Senior then more correlate to the value of curating ideas, mining for conflict, gathering consensus, and execution; while operating tactfully and methodically within certain bounds of composure/temperament?
85 comments
[ 0.21 ms ] story [ 97.4 ms ] threadGood to hear it
i'm in the camp of improving things regularly without hesitation but again this can devolve. another way it can turn sour is when the team is made of people too different from each other. one improvement from someone pov is a waste or even a regression for others .. then it's a 'who decides here' conversation.
that said when you have a cohesive group all focusing on pushing in the same direction then it's bliss
I’ve seen the pursuit of disambiguation employed to deadlock a project. Sometimes that’s the right thing to do—the project sponsor doesn’t know what they want. But many times the senior needs to document some assumptions and ship something rather than frustrating the calendars of 15 people trying to nail down some exact spec. Knowing whether to step on the brake or the gas for the benefit of the team and company is a key senior trait.
This is a yes, and to the article; building without understanding the problem usually will increase chaos—though sometimes the least effort way through it is to build a prototype, and a senior would know when to do that and how to scope it.
The post actually does a great job of highlighting a genuinely valuable skill that the best engineers practice regardless of their title. In particular, “reducing ambiguity” is something I believe would be really beneficial for many early-career engineers to intentionally develop.
Senior deals with "what-if" statements.
<EoF>
- Junior - someone who can work under guidance.
- Regular - someone who can work alone.
- Senior - someone who can guide others.
In the end, if a junior is repeatedly not responding to appropriate guidance or advice, then that junior should be gone from that position. Same for a senior who is repeatedly dispensing inappropriate guidance or advice.
But it requires careful analysis of the situation before such a drastic course of action: is there a communication problem, a training problem, a mistake in evaluating abilities?
A senior should be able to navigate cultural and technical differences competently. A junior should understand that that the ones with responsibility for a project also have the authority to make decisions about the project, which should be honored.
This. Totally agree. Seniority level it’s based on the volume of practice someone has. Period.
e.g, let's say someone spends 10k hours doing just 'addition and subtraction' problems on 2 digit numbers. Are they now better at maths than someone who spent 0.1k hours but doing a variety of problems?
To grow as a software engineer, you need to have volume + have this be outside of your comfort zone + actively try to improve/challenge yourself.
Apart from this, I do agree it's not 'innate talent' that drives someone to become a senior engineer, and I think anyone with the right attitude / mindset can do so.
There was simply a lot I did not know, but I had the talent to do this part well (sure, one can argue that I had "practice" doing this with any problem since I was ~10 years old, but calling that "senior" would be... over the top: I think it rather qualifies as "talent").
It took me a couple of years of learning good software engineering from my wonderful and smart senior colleagues and through my own failures and successes for me to become a Tech Lead too.
That wasted a lot of time which is a lesson to be learned from.
I also struggled with self management.
One approach to deal with ambiguity is to write a short design doc, which writes down what you are trying to do, and all of the assumptions that you are making. If you don't understand the domain, some of your assumptions will probably be wrong. The stakeholder should be able to see that and provide guidance.
One issue I have quite often is I'll know I have a problem with understanding something and so I ask my team but then the response can be something like "you should know X" or "you should know this because of Y context" and it can be discouraging. I think a lot of the time I notice people conflate experience level with amount of context I have with something.
I'm still struggling with these kinds of challenges and I would readily admit it could be my own weakness but I also wonder if it's a team culture issue; but I've noticed this across my current org and my last one so maybe it's more of a me-problem.
Leaders reduce ambiguity, so others can operate with more clarity. The ambiguity involved can be in many different domains. It can be focused on product and tech, as in the article. Another example is ambiguity around people and organizational structure, which is more common in management roles, where some in management are more effective leaders than others. It can be around finding ways for people to understand why they might want a product, which is more common in sales and marketing roles. And so on.
In my case, I met that description on my first job, and I guarantee, I was not senior.
You see, my initial training was as an electronic technician (RF/microwave stuff).
That thought process described, was exactly what they trained us to do. Debugging a wonky RF board is about as ambiguous as you can get.
So maybe there's a different definition of "senior."
In my mind, a senior engineer knows what needs extra attention and where it’s ok to cut corners.
The only thing that makes a senior are years of experience, that's all. You can be a shitty senior if you only do one thing for 10 years, but you're a senior nonetheless.
Licensed professionals don't have identity crises, their titles and what is required of them is legally enforced. The software industry has never lobbied for the interests of "engineers", the way other professions have (taxi drivers, barbers, plumbers, real estate agents, etc formed professional groups which lobbied for laws requiring official licensing). I think it's because software developers are the laziest people on the planet, and they are happy to continue doing almost nothing in order to get hired.
The only thing that makes you a senior in software is whatever titles the companies you've worked for happen to give out (which may be inflated for various political or hiring reasons) while you work there and there are basically completely arbitrary criteria from company to company.
In terms of official job titles, I was a "Senior Software Engineer" like 2-3 years after I started writing code professionally, and I mention this not to toot my own horn in any way but to point out how arbitrary titles can be (and we won't even get into the debate over the 'Engineer' bit).
I ran a compile and the code was riddled with errors. So I went to the PM and explained the code needed to compile and I needed a day to clean it up.
I refactored the entire project to compile and deploy that way. After that the development went very fast.
The hilarious part was the three devs who’d gone on vacation came back and thought what I’d done was “wrong”.
But the client said we (consultants) had done in two weeks what they couldn’t do in six months.
That’s what a senior engineer does.
I think this is more of a consultant vs employee thing than it is senior vs not-senior. There's this weird dynamic that happens where BizOps defaults to trusting and spending more on consultants, granting them more autonomy, such that they're wildly more empowered to take any risk. Employees are to be delegated to by BizOps, and BizOps doesn't like taking risks. It's paradoxical, because unless you come in with that authority or you were there extremely early, you're unlikely to acquire it, much more-so after the company's been around a few years.
This seems to me where the term "hired gun" comes from. You pay someone who's incentivized to solve a discrete important problem with their expertise quickly, whereas all of your employees are incentivized to do things for amounts of time reliably over however long, answering to product managers, implementing whatever crap to get the sale, answering to useless managers every two weeks, planning, reviewing, retrospectiving, blah blah. The consultant isn't about to go doing a broad-scale refactor if they're not paid to, and there's no reason an employee should either.
You mentioned receiving approval after providing a persuasive justification - to me it implies that you were not in the position of making the decision, rather it was up to someone else and under their supervision?
Should Senior then more correlate to the value of curating ideas, mining for conflict, gathering consensus, and execution; while operating tactfully and methodically within certain bounds of composure/temperament?