Senior engineering and junior engineering are called different things for a reason? You don't hope the senior engineer can get things done, you know it. It's the opposite for a junior. If you cannot deliver the goods, you are sending a message that you are not senior.
>1. “I’ll Just Fix It”. As a senior: it’s reckless.
For the sake of my own sanity and enjoyment of my work, I have realised that I sometimes have to do this. I'm not talking about massive 2 week tasks but rather something done in 30mins - 1h. I call them pallet cleansers and when there is a particularly hard task that has me stumped I'll do one of them to give my brain some time to passively process the more difficult one.
I have also told my manager point blank that they can get on board or start looking for a new engineer because I would leave otherwise. Thankfully, they're a good manager and are completely fine with it as long as my main work gets done on time and I somehow communicate it (standup, slack, jira, etc).
I'm going to disagree with the "Asking a Lot of Questions" section. One of the best engineers I've ever worked with, who was at the Principal level, was completely unafraid to ask questions, no matter how basic one might think they were. Turns out he was rarely the only one who wanted to ask that question, and he was able to get understanding of a system or problem much faster than if he'd kept his questions to himself.
In the years since we worked together I've adopted his "there's no such thing as a stupid question" philosophy and it's served me really well.
Pretty spot-on. Describes several people I know quite well.
I do think these are the symptoms, but TFA doesn't completely call out the cause. They do say it a couple times though, to their credit.
The core issue is that at senior, and especially at staff+, you need to have more impact (as the article states) and you will be fundamentally unable to do so if you spend all your time doing the symptoms you see in the article. It's all "low-impact" work and in some cases is simply distracting (constantly gushing about, or potentially even churning integration, of new techs/frameworks etc).
I had an EM who helped me grow a lot. They told me, racecar drivers have to look 100'+ ahead, because if they look right in front of them, they will crash. You have to tape over the bottom half of the windshield to help yourself look far enough ahead.
And that's really what it comes down to. E.g. for #1, jumping into random problems yourself means no triage/priorities and you're probably depriving a teammate of an opportunity to grow and learn more of the stuff your team owns (much higher-impact outcomes for your team). Plus the opportunity cost of what you could've been doing instead (pointing a mid-level eng at a problem with some sage pointers is a lot less time-consuming than DIYing it. higher-leverage).
I do want to remark on "asking lots of questions". I know then attenuate this by saying it's perhaps not "less" questions but "more surgical". I think really though, I would describe it not as surgical, but as guiding. Your questions will change from being mostly informative for you and move to being more informative to the person you're asking the question of. Similar to the socratic method. It's all about internalizing what the person you're helping currently knows, and then give them questions that, if answered, will move them forward. I find often the other person will be both capable of answering, and delight in answering, such questions. They just didn't know to ask it in the firstplace.
more AI slop in the style of navel-gazing LinkedIn garbage. so nauseating. is there no escape from this? also, since when is asking clarifying questions a problem? this article is absurd.
tbh none of this sounds like "senior engineer" qualities, and leans more toward "working at larger companies/in larger teams." From my perspective at startups/SMBs:
> “I’ll Just Fix It”
Yes please. Diving into unfamiliar areas of code and being able to fix problems outside of your wheelhouse is critically important. This doesn't mean stepping on people's toes or subverting processes e.g. design/code review, but just being willing to take ownership and not just shrug and say "not my problem".
> You’re expected to build fences.
Again, this is a big business thing and not a senior engineer thing. As a senior engineer in a team of 250 there are more barriers, but a senior engineer in a team of 20? You shouldn't be building very many fences.
> Working Nights and Weekends
This is a cultural thing that comes from the top. Goes beyond the scope of just senior engineers but I'll say that in my experience, if you're at a startup nobody is going to complain about you working nights and weekends. Again, this is a "large company" thing where slow and steady is more important than fast results.
> Asking a Lot of Questions
Dumb. I mean yes, if you're a senior engineer and asking questions like "what's a for loop" you'll raise eyebrows, but all of the best engineers (and managers for that matter) I worked with at Amazon etc all asked questions. In fact asking questions--extremely pointed and insightful questions--was basically all Jassy did in AWS meetings when I was there.
I feel like I could very easily write this list in the opposite direction.
1. I'll just fix it – as a junior you can get away with not working on something unless you're told to. As a senior you're expected to take ownership. Cut through organisational malaise. See a thorny bug not being solved because it sits slightly across team boundaries? Fix it.
2. Working nights and weekends – as a junior you can expect to just turn up during your work hours and nobody will bat an eyelid. As a senior sometimes you'll have to make sacrifices. Stay on late to deal with that incident. Monitor a vendor migration over the weekend.
3. Asking a lot of questions – as a junior you can get away with being shy and avoidant. As a senior you're going to need to push through the discomfort and ask the important questions, challenge people, and have gotten over your fear of looking stupid to ensure you always have the right information.
4. Being "Extra" Helpful – as a junior you can very much just focus on your project work. As a senior you're expected to find impact beyond what is given to you in JIRA tickets. You need to review other PRs, manage other projects, unblock team members questions. Your job is beyond just closing tickets now.
5. Loud enthusiasm – as a junior you are not likely to have the political capital to get your org to take a risk on a new framework, language, tool. As a senior you are expected to have the experience to be able to take those risks when they are appropriate for the situation.
It's true though that you need be thoughtful about whether your behaviour is what is valued in your job. Regardless of seniority, different managers, different companies can value traits that other companies punish, and visa versa. You can really suffer if you're not aware of what it is your managers actually want from you.
Reading the whole thing I find myself jumping between agreement and disagreement. Yeah sure the way an experienced engineer contributes impact is different to how a young junior would go. But its neither black/white or specifically isolated to being experienced. Often the environment or the persons this third you will expect a certain mode of engagement regardless of seniority. This is not two dimensional.
It should have been separatd into "new hire" and "long time employee", regardless of technical experience.
You should expect new hires (of any seniority level) to jump in and try to fix things. It shows they're invested, willing to embrace opportunities.
You should expect new hires (of any seniority level) to ask lots of questions. They need to learn this new environment, quickly. That's the best way to do it.
You should expect new hires (of any seniority level) to try to be extra helpful. They still don't know exactly where they can help the most, mapping the ground is a good sign.
You should expect new hires (of any seniority level) to be enthusiastic. It shows they value being there, and are on board with trying new approaches. In other words, it shows they believe themselves to be useful in that new environment.
It has absolutely nothing to do with being a senior, but being in a new environment. Of course, to juniors, every environment is new and they should do that all the time. Seniors should do that when they change environments, or when the environment changes for them.
If anything the real flip is recognising their are no absolutes and no hard rule that things have to go one way or the other but rather accepting the need to find the right fit at the time. Each of these options the reverse might be true and it really just depends.
There is a very distinct moment in your career when you realize that staying late is not a sign of enthusiasm/energy, it's a sign that you're struggling. Going home early is a power move. It means you're on top of your shit. It means you have a life outside of work. It signals efficiency.
Half of this is nonsense, to me, and I am pretty senior. This indicates that probably this guy has a different technical culture than I do, but he’s talking as if his culture is the only kind.
I work nights and weekends and anyone who thinks that’s weird is an idiot or a child, OR they have a different technical culture from me, WHICH IS OKAY. I don’t impose my culture on everybody else, except people who work for me.
19 comments
[ 3.0 ms ] story [ 39.3 ms ] threadSame mannerisms. Same style.
Was it written with AI?
For the sake of my own sanity and enjoyment of my work, I have realised that I sometimes have to do this. I'm not talking about massive 2 week tasks but rather something done in 30mins - 1h. I call them pallet cleansers and when there is a particularly hard task that has me stumped I'll do one of them to give my brain some time to passively process the more difficult one.
I have also told my manager point blank that they can get on board or start looking for a new engineer because I would leave otherwise. Thankfully, they're a good manager and are completely fine with it as long as my main work gets done on time and I somehow communicate it (standup, slack, jira, etc).
They do a lot of stuff for the wrong reasons. And they don’t even care. Seen it countless times.
In the years since we worked together I've adopted his "there's no such thing as a stupid question" philosophy and it's served me really well.
Nothing screams Senior Engineers more than this! (/s... or not?)
But anyway if the expectations of seniors are exactly the same as that of juniors, than what's the point of hiring seniors?
I do think these are the symptoms, but TFA doesn't completely call out the cause. They do say it a couple times though, to their credit.
The core issue is that at senior, and especially at staff+, you need to have more impact (as the article states) and you will be fundamentally unable to do so if you spend all your time doing the symptoms you see in the article. It's all "low-impact" work and in some cases is simply distracting (constantly gushing about, or potentially even churning integration, of new techs/frameworks etc).
I had an EM who helped me grow a lot. They told me, racecar drivers have to look 100'+ ahead, because if they look right in front of them, they will crash. You have to tape over the bottom half of the windshield to help yourself look far enough ahead.
And that's really what it comes down to. E.g. for #1, jumping into random problems yourself means no triage/priorities and you're probably depriving a teammate of an opportunity to grow and learn more of the stuff your team owns (much higher-impact outcomes for your team). Plus the opportunity cost of what you could've been doing instead (pointing a mid-level eng at a problem with some sage pointers is a lot less time-consuming than DIYing it. higher-leverage).
I do want to remark on "asking lots of questions". I know then attenuate this by saying it's perhaps not "less" questions but "more surgical". I think really though, I would describe it not as surgical, but as guiding. Your questions will change from being mostly informative for you and move to being more informative to the person you're asking the question of. Similar to the socratic method. It's all about internalizing what the person you're helping currently knows, and then give them questions that, if answered, will move them forward. I find often the other person will be both capable of answering, and delight in answering, such questions. They just didn't know to ask it in the firstplace.
> “I’ll Just Fix It”
Yes please. Diving into unfamiliar areas of code and being able to fix problems outside of your wheelhouse is critically important. This doesn't mean stepping on people's toes or subverting processes e.g. design/code review, but just being willing to take ownership and not just shrug and say "not my problem".
> You’re expected to build fences.
Again, this is a big business thing and not a senior engineer thing. As a senior engineer in a team of 250 there are more barriers, but a senior engineer in a team of 20? You shouldn't be building very many fences.
> Working Nights and Weekends
This is a cultural thing that comes from the top. Goes beyond the scope of just senior engineers but I'll say that in my experience, if you're at a startup nobody is going to complain about you working nights and weekends. Again, this is a "large company" thing where slow and steady is more important than fast results.
> Asking a Lot of Questions
Dumb. I mean yes, if you're a senior engineer and asking questions like "what's a for loop" you'll raise eyebrows, but all of the best engineers (and managers for that matter) I worked with at Amazon etc all asked questions. In fact asking questions--extremely pointed and insightful questions--was basically all Jassy did in AWS meetings when I was there.
Anyway this article is mainly crap, IMO.
1. I'll just fix it – as a junior you can get away with not working on something unless you're told to. As a senior you're expected to take ownership. Cut through organisational malaise. See a thorny bug not being solved because it sits slightly across team boundaries? Fix it.
2. Working nights and weekends – as a junior you can expect to just turn up during your work hours and nobody will bat an eyelid. As a senior sometimes you'll have to make sacrifices. Stay on late to deal with that incident. Monitor a vendor migration over the weekend.
3. Asking a lot of questions – as a junior you can get away with being shy and avoidant. As a senior you're going to need to push through the discomfort and ask the important questions, challenge people, and have gotten over your fear of looking stupid to ensure you always have the right information.
4. Being "Extra" Helpful – as a junior you can very much just focus on your project work. As a senior you're expected to find impact beyond what is given to you in JIRA tickets. You need to review other PRs, manage other projects, unblock team members questions. Your job is beyond just closing tickets now.
5. Loud enthusiasm – as a junior you are not likely to have the political capital to get your org to take a risk on a new framework, language, tool. As a senior you are expected to have the experience to be able to take those risks when they are appropriate for the situation.
It's true though that you need be thoughtful about whether your behaviour is what is valued in your job. Regardless of seniority, different managers, different companies can value traits that other companies punish, and visa versa. You can really suffer if you're not aware of what it is your managers actually want from you.
You should expect new hires (of any seniority level) to jump in and try to fix things. It shows they're invested, willing to embrace opportunities.
You should expect new hires (of any seniority level) to ask lots of questions. They need to learn this new environment, quickly. That's the best way to do it.
You should expect new hires (of any seniority level) to try to be extra helpful. They still don't know exactly where they can help the most, mapping the ground is a good sign.
You should expect new hires (of any seniority level) to be enthusiastic. It shows they value being there, and are on board with trying new approaches. In other words, it shows they believe themselves to be useful in that new environment.
It has absolutely nothing to do with being a senior, but being in a new environment. Of course, to juniors, every environment is new and they should do that all the time. Seniors should do that when they change environments, or when the environment changes for them.
Meh.
I work nights and weekends and anyone who thinks that’s weird is an idiot or a child, OR they have a different technical culture from me, WHICH IS OKAY. I don’t impose my culture on everybody else, except people who work for me.
Or possibly they've read those studies that show that overtime reduces work quality and massively increases mistakes made