This sounds cool but reality is much more boring than that. If your work title says "Senior" then you're Senior.

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.

Oh, so it isn’t about know to solve any leetcode?

Good to hear it

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.

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.

It's just a pay grade. Please folks stop trying to analyze "junior," "senior," and so forth. It's just something management told HR to write down.

When someone calls you senpai

Bro thinks this is unique to engineers.

age

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.

Junior deals with "if" statements.

Senior deals with "what-if" statements.

<EoF>

Related: Job Titles are Bullshit (2024) https://news.ycombinator.com/item?id=39511732

Meanwhile the industry standard definition since the 80s:

- Junior - someone who can work under guidance.

- Regular - someone who can work alone.

- Senior - someone who can guide others.

> this isn’t talent, but practice

This. Totally agree. Seniority level it’s based on the volume of practice someone has. Period.

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.

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.

I also struggled with self management.

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!

age

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.

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

Isn't that just called "being put in charge"? The causality seems reversed to me here, as in, you're not senior because you're reducing ambiguity, but you've either explicitly been made senior or just have tenure and now others come to you with questions about what you think makes sense. Consequence rather than cause

Or maybe that's just in egalitarian companies, like in tech where I'd ask a second opinion or technical input of just about anyone, whereas in other lines of business it's different? I imagine a water treatment facility has a lot more niche constraints to work with than we do and so expertise goes much deeper and you're not immediately prompted for advice

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.

That’s what a senior engineer does.