5 ms·

How Senior Engineers Lose Trust

26 points by napolux 1y ago

1970-01-01 1y ago
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.
emigre 1y ago
I was trying to read this article but could not get to the end. Suddenly, I realized. Same mannerisms. Same style. Was it written with AI?
- lexicality 1y ago
  I think it was just written by someone used to making tweet threads rather than coherent articles.
  - emigre 1y ago
    Short statement. Short statement. Dramatic conclussion.
- yujzgzc 1y ago
  Blame the game not the player. "LinkedIn cringe style" predates generative AI (though it was arguably willed into existence in part by the evolutionary process operating on a engagement-based feed-ranking AI)
- julik 1y ago
  It does seem like it - with the addition of "one sentence per paragraph", which - outside of its LinkedIn format - feels like yelling. This format doesn't incite trust in the person advising (let alone the tone).
- dsjoerg 1y ago
  Yes it’s not X it’s Y. I dont mind AI as such, but I’m tired of that specific style of writing.
- sodapopcan 1y ago
  Yes. What is it is with one sentence paragraphs? This drives me nuts. It also feels like hubris that the writer believes each sentence is so important that it deserves its own paragraph. At the same time it makes me question the writer's confidence that they may be doing this to trick the reader. Whatever it is... It drives me nuts. Annoys me. Gets on my nerves. But alas... That's the internet for you, and in the end... There are bigger things to stress about. I guess. It still get to me.
lexicality 1y ago
This is what happens when you promote people to "senior" based on time served rather than experience and career growth.
- mangamadaiyan 1y ago
  The article, you mean?
mschild 1y ago
>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).
- 62 1y ago
  [dead]
- hamdingers 1y ago
  This one's just wrong, unless the author is using a novel definition of senior. Senior engineers are exactly who I trust to "just fix it" when they notice a problem, even one outside their immediate domain. Sure the bar is higher, but that's still their job. If this was about staff or architects, then it would make sense.
  - itsnowandnever 1y ago
    I think the author didn't account for different types of engineering orgs at different points in their lifecycle. "just fix it" at an enterprise massive company as a junior is fine but a senior would know "if you fix it, you own it" and it could cause downstream issues with what your team does or owns at the company. whereas at a startup, if you're relying on junior devs to "just fix it"... good luck with that
    - mschild 1y ago
      Even at an enterprise its absolutely possible. I work for one after all. My team owns the product anyway though and my "just fix it" tasks are 99% of the time annoyances that I encounter in my day-to-day work. For example, we run a Jenkins instance for our platform that has bi-weekly production releases. We write announcements in slack when there was a release with a list of PRs and links to the tickets in Jira. That used to be manual work. At one point I was annoyed by it and took 30 minutes to write a 15 line script to automatically take the merged PRs, create a Jira link and announce it in our slack channel.
LunicLynx 1y ago
This is more an explanation for why our industry sucks in big second tier companies. They do a lot of stuff for the wrong reasons. And they don’t even care. Seen it countless times.
itsme0000 1y ago
Is ChatGPT a senior engineer because it knows everything or a junior engineer because it will do anything you ask for?
- emigre 1y ago
  It's a middle manager. It doesn't know what it's talking about, but it will talk about it with complete confidence.
quux 1y ago
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.
- rendaw 1y ago
  That's great unless you're in an organization with insecure higher rank (ex-engineer management, staff engineers, etc) who take that as an excuse to dismiss anything else you say, treat all your concerns as XY questions, etc etc.
  - relaxing 1y ago
    Friendly advice: get out as soon as you can.
  - hamdingers 1y ago
    If bad management is punishing good engineering then it's time to find the door.
  - itsnowandnever 1y ago
    commentary from first time staff engineers should be taken with a grain of salt because they can be silly trying to prove themselves. same as first time people managers with an engineering background. if they're not a few iterations through the engineering manager pendulum, they're still getting their bearings. if you're at a company where leadership doesn't understand this, do your mental health a favor and leave.
- rawgabbit 1y ago
  It depends on the context. If it is a mentoring session, of course, fire away. If it is a meeting with 10 or more people, asking a basic question can be interpreted negatively a) you are trying to embarrass the organizer of the meeting implying they are clueless b) you are trying to disrupt the meeting.
raincole 1y ago
> Follow me on LinkedIn for daily insights shared with 80,000+ incredible minds 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?
atomicnumber3 1y ago
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.
rambojohnson 1y ago
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.
mjr00 1y ago
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. Anyway this article is mainly crap, IMO.
paperpunk 1y ago
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.
- Ancapistani 1y ago
  I like this a lot :) A senior engineer has knowledge and experience. A staff engineer has discernment. In an ideal world, people should be promoted to staff and above when they demonstrate that discernment. We should always be unafraid to share our perspectives, but staff engineering is about knowing when to get involved, when to watch, when to ignore, and when to actively look away. As “Sr. Staff”, I see my job as knowing when to exercise authority far more than merely exercising it.
  - OutOfHere 1y ago
theK 1y ago
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.
alganet 1y ago
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.
28304283409234 1y ago
"I have abstracted something extremely complex in this convenient list of 5. Pay me and I will tell you more!" Meh.
PaulKeeble 1y ago
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.
roncesvalles 1y ago
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.
satisfice 1y ago
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.
- lexicality 1y ago
  > I work nights and weekends and anyone who thinks that’s weird is an idiot or a child Or possibly they've read those studies that show that overtime reduces work quality and massively increases mistakes made

26 points by napolux 1y ago

1970-01-01 1y ago

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.

emigre 1y ago

I was trying to read this article but could not get to the end. Suddenly, I realized. Same mannerisms. Same style. Was it written with AI?

lexicality 1y ago
I think it was just written by someone used to making tweet threads rather than coherent articles.
- emigre 1y ago
  Short statement. Short statement. Dramatic conclussion.
yujzgzc 1y ago
Blame the game not the player. "LinkedIn cringe style" predates generative AI (though it was arguably willed into existence in part by the evolutionary process operating on a engagement-based feed-ranking AI)
julik 1y ago
It does seem like it - with the addition of "one sentence per paragraph", which - outside of its LinkedIn format - feels like yelling. This format doesn't incite trust in the person advising (let alone the tone).
dsjoerg 1y ago
Yes it’s not X it’s Y. I dont mind AI as such, but I’m tired of that specific style of writing.
sodapopcan 1y ago
Yes. What is it is with one sentence paragraphs? This drives me nuts. It also feels like hubris that the writer believes each sentence is so important that it deserves its own paragraph. At the same time it makes me question the writer's confidence that they may be doing this to trick the reader. Whatever it is... It drives me nuts. Annoys me. Gets on my nerves. But alas... That's the internet for you, and in the end... There are bigger things to stress about. I guess. It still get to me.

lexicality 1y ago

This is what happens when you promote people to "senior" based on time served rather than experience and career growth.

mangamadaiyan 1y ago
The article, you mean?

mschild 1y ago

>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).

62 1y ago
[dead]
hamdingers 1y ago
This one's just wrong, unless the author is using a novel definition of senior. Senior engineers are exactly who I trust to "just fix it" when they notice a problem, even one outside their immediate domain. Sure the bar is higher, but that's still their job. If this was about staff or architects, then it would make sense.
- itsnowandnever 1y ago
  I think the author didn't account for different types of engineering orgs at different points in their lifecycle. "just fix it" at an enterprise massive company as a junior is fine but a senior would know "if you fix it, you own it" and it could cause downstream issues with what your team does or owns at the company. whereas at a startup, if you're relying on junior devs to "just fix it"... good luck with that
  - mschild 1y ago
    Even at an enterprise its absolutely possible. I work for one after all. My team owns the product anyway though and my "just fix it" tasks are 99% of the time annoyances that I encounter in my day-to-day work. For example, we run a Jenkins instance for our platform that has bi-weekly production releases. We write announcements in slack when there was a release with a list of PRs and links to the tickets in Jira. That used to be manual work. At one point I was annoyed by it and took 30 minutes to write a 15 line script to automatically take the merged PRs, create a Jira link and announce it in our slack channel.

LunicLynx 1y ago

This is more an explanation for why our industry sucks in big second tier companies. They do a lot of stuff for the wrong reasons. And they don’t even care. Seen it countless times.

itsme0000 1y ago

Is ChatGPT a senior engineer because it knows everything or a junior engineer because it will do anything you ask for?

emigre 1y ago
It's a middle manager. It doesn't know what it's talking about, but it will talk about it with complete confidence.

quux 1y ago

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.

rendaw 1y ago
That's great unless you're in an organization with insecure higher rank (ex-engineer management, staff engineers, etc) who take that as an excuse to dismiss anything else you say, treat all your concerns as XY questions, etc etc.
- relaxing 1y ago
  Friendly advice: get out as soon as you can.
- hamdingers 1y ago
  If bad management is punishing good engineering then it's time to find the door.
- itsnowandnever 1y ago
  commentary from first time staff engineers should be taken with a grain of salt because they can be silly trying to prove themselves. same as first time people managers with an engineering background. if they're not a few iterations through the engineering manager pendulum, they're still getting their bearings. if you're at a company where leadership doesn't understand this, do your mental health a favor and leave.
rawgabbit 1y ago
It depends on the context. If it is a mentoring session, of course, fire away. If it is a meeting with 10 or more people, asking a basic question can be interpreted negatively a) you are trying to embarrass the organizer of the meeting implying they are clueless b) you are trying to disrupt the meeting.

raincole 1y ago

> Follow me on LinkedIn for daily insights shared with 80,000+ incredible minds 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?

atomicnumber3 1y ago

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.

rambojohnson 1y ago

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.

mjr00 1y ago

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. Anyway this article is mainly crap, IMO.

paperpunk 1y ago

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.

Ancapistani 1y ago
I like this a lot :) A senior engineer has knowledge and experience. A staff engineer has discernment. In an ideal world, people should be promoted to staff and above when they demonstrate that discernment. We should always be unafraid to share our perspectives, but staff engineering is about knowing when to get involved, when to watch, when to ignore, and when to actively look away. As “Sr. Staff”, I see my job as knowing when to exercise authority far more than merely exercising it.
- OutOfHere 1y ago

theK 1y ago

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.

alganet 1y ago

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.

28304283409234 1y ago

"I have abstracted something extremely complex in this convenient list of 5. Pay me and I will tell you more!" Meh.

PaulKeeble 1y ago

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.

roncesvalles 1y ago

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.

satisfice 1y ago

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.

lexicality 1y ago
> I work nights and weekends and anyone who thinks that’s weird is an idiot or a child Or possibly they've read those studies that show that overtime reduces work quality and massively increases mistakes made