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).
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.
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.
if you're at a company where leadership doesn't understand this, do your mental health a favor and leave.
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.
On the other hand, seniors who think they know it all are dangerous. Bad decisions come with bigger impact at that level.
Content of the question does matter ofc.
Rather that asking questions, or reading code, when confronted with something new they will state "I don't understand X" or "I don't know what a Y is."
And then expect someone to jump in and fill in the gaps.
It's incredibly obnoxious and grating on a personal level and makes me not want to work with this person despite their other, genuinely valuable skills.
I can see myself saying exactly that in a meeting where we’re trying to explore a problem space to plan or make decisions - in which case I’d want to make it clear that I’m coming at that part of it blind, and am seeking enough information to identify tradeoffs.
What I’m not doing is expecting someone else to do the work of learning so I don’t have to. It’s limited to the topic at hand, and if it’s something that I expect I’ll encounter again I’ll spend time afterward diving in and learning enough to answer those questions for others in the future.
I’m perceiving your comment as you considering their actions to be laziness or disinterest. Is that accurate? If so, then yeah, that’s a huge red flag that could mean that this person isn’t suited for their role and expectations. If not, then it might be fruitful to sit down with this person to understand why they’re asking those questions and what they’re trying to accomplish. It could be that they’re simply not communicating their intentions.
For context: I’m in my early 40s, have been in a technical role for ~20y, and have had a “SWE-equivalent” title for about 15y. My current role is Sr. Staff SWE.
Your comment resonated, though:
> as an introvert all my career I have been afraid of looking dumb
I remember feeling this way very early in my career. I wasn’t so much afraid of looking dumb, but of exposing to my colleagues that I lacked some critical knowledge, likely as a result of my not having a traditional CS education (or a degree at all).
A few years into my career I began to see that people were interested in what I had to say not because of who I was, but because of the way I presented the concepts. If I came at a problem openly, was clear about what I was and was not confident in, and spoke in terms of tradeoffs and balance, others would mirror this behavior and jump in to fill my gaps.
In moving into the staff engineer role, I focused on why some orgs I’d worked for were more effective than others. I came to the conclusion that it was cultural, and therefore also concluded that the way I could make the biggest impact was through building and guiding that culture.
I make it a point to ask “dumb questions”. Often I already know the answer, but have identified that if I were wrong there it would have an outsized impact - so I explicitly challenge those preconceptions and ask for argument.
I’m constantly telling people at all level (but especially those more junior who seem to speak up less) that asking those questions is important. I reach out to them early and directly, and offer to always be willing to ask questions that they’re afraid to ask on their behalf, and without attribution. If it ends up making a positive impact, I immediately and publicly give them credit. If it’s not well-received, I own it. There have been a couple of times that I’ve refused to tell leadership who a question like that originated from because they were looking for a scapegoat. I actually lost a job by doing that before I reached “staff” level (or perhaps before staff engineers were a commonly-understood concept?), and don’t regret it.
These days I work for a company whose culture doesn’t look like a good fit for me at all. I’m in a very red state, steeped in that culture (though not the politics - long and irrelevant story), and expected quite a bit of friction. What I found was that I could lean in to the “blameless/egoless” paradigm and make it work for me, and in the process make it a more effective organization as a whole. Now I find my self saying things like “I know you’ve hear this before, but I mean it: you can treat this as a safe space. I want to help our org succeed, and I want to help you succeed. I’ll do everything I can to protect you from the politics, help you grow as an engineer and as a professional, and be happy. If that means tapping my network to find places fro you to interview because you’re not happy here, I’ll do it.” - and I’m saying it as a big bearded dude with a deep Southern accent and absolutely no shame.
To put it another way - I’ve reached the point in my personal and professional life where I know exactly who I am. I’m not threatened by what others think of me, and am confident in my abilities to the point that I want to be aware of and clearly communicate my shortcomings so I’m as effective as I can be.
We all have moments where we don’t know (or can’t remember) something we should know. I’ve gone from being ashamed of that as a junior to seeing it as an opportunity to demonstrate that it’s normal and an accepted part of our company’s culture at the staff level.
The more senior an engineer is, the more important demonstrating difficult but necessary actions becomes. It makes you more effective as an individual and is essential for building effective teams.
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.
emigre•2h ago
Same mannerisms. Same style.
Was it written with AI?
lexicality•2h ago
emigre•2h ago
Dramatic conclussion.
julik•2h ago
dsjoerg•2h ago
yujzgzc•2h ago
sodapopcan•1h ago
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.