What makes you senior

Being senior, to me, is best illustrated by a story:

Me: "Sometimes I feel like I'm psychic"

Co-worker: "How so?"

Me: "Many times on projects, I can tell at either the planning stages or the very early implementation steps if it's going to go well or be a disaster. e.g. people will say they love templated configs but they don't account for what can go wrong when there is a bug in the template etc etc"

Co-worker: "I don't think that's being psychic. That means you are a senior engineer who has seen so many projects that you can quickly pattern match on if the project is going to succeed or fail based on only the first 20% of the project."

For me ego-wise I don't feel like I ever will be senior. I have worked with people who claim to be senior and are barely able to function so it's funny. I have worked professionally in some capacity for almost 10 years. Right now I'm working with cloudformation templates. I have seen myself improving over time and recognize my own older-self bad code. Learning faster. But yeah it's one of those things like I'm the quiet guy in a pack. I'm just lucky I lift so I'm big and people don't mess with me but I'm pretty meek as a person. This job is about merit, I'm not saying physical appearance should matter. But I'm emphasizing my self-esteem problem.

Counter to myself, a co-worker of mine who's been at the company I just joined longer than me, he gets to set things up, make decisions. Then he has to change directions and hands it to me, I ask him "how did you come up with this" and he says "I asked ChatGPT" and I'm like what?... But it is a learning tool and doing new things (this case was a starting point for Apache Airflow DAG work). But that's a case of "I'm senior".

I did read this article and I get the idea. I still have that problem where I ask what to do (mid) and a lot of times it's because I don't know if I can make a decision, is my choice good kind of thing. Uncertainty but again merit or ego?

I'm also fine not being anybody, stress-wise and finance. Not sure what the pay jump is where I'm at. Wouldn't mind a coast-type job as I have pretty good perks (gym, walks, beer on tap, hybrid) and I can pursue my other projects outside of work like robotics that I can't do at my day job (agentic work lately).

Alright I'll be done ranting, I have been a one-person dev for a startup that died it was a WebRTC document signing platform, damn that was a great project, had like 7 different repos of different tech even wrote a wrapper around Apple CUPS. So tragic when projects go nowhere and get shelved.

I think the best thing I have learned is to put ego aside (regarding avoiding arguments) and just go with the flow. In my tense environment anyway, I need money so I need this job. I was able to get along with my manager who I was having problems with in the beginning. He's one of those very blunt, direct people, you'd consider an asshole. But I aspire to be that you know a driver that makes shit happen. Like a Steve Jobs although I'm not really an asshole, I don't like seeing other people in pain. Back to self-esteem.

I prefer «reduces uncertainty» to «reduces ambiguity». The problem isn't ambiguous specifications, it's simply that there are too many unknowns to just do the work at this point.

The author talks about the shaping of the work, so I guess this is implicit.

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.

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.

On top of this you also need to have the skills to communicate this with others, because if you are not able to convince others, in management, you are on a sure track to a burn out. Being the only one who sees the solution and not being able to convince others is going to make you very frustrated or to simply give up.

Soft skills are always the more important than all other skills.

This shows very visibly in the devops/platform engineer/whatever-the-hell-we're calling-it-these-days world.

Often you will get a request, sometimes (or quite often) you have no idea what is driving it, like for example "reduce rate limiting for xyz service." Lots of ops guys will just blindly do this ticket shuffle, even very senior ones - maybe for their own sanity, maybe out of preservation - but the best ones I've ever worked with, will often question "Wait, why do you need that?" Then you find out there is some other really trivial solution to fix that underlying problem that doesn't involve as drastic of a change, or maybe even none at all. Especially if it doesn't involve code change on their side, you're not going to face much headwind in pushing back.

The reason this is important is that, no disrespect to developers, they often live in a world where they treat infrastructure as a blackbox (as I believe they should). The problem sometimes is they want to also control the behavior of that blackbox. So while the request may seem to solve the problem, often there is a much easier/simpler/safer/scalable way to fix whatever underlying problem got tossed over the fence to you.

The senior guys I've respected the most always will ask the "wait, why?"

the blog touches more on the management side rather than development so the term engineer seems misused.

i encountered this topic many times in my life and after many years i can safely say that what makes an engineer being considered a senior is simply a talent, or learnt skill, of problem-solving without outside input. meaning, a senior engineer will find a way to get things done, just like special military guys do, without reliance on other people(as in, there is no safety net of skilled colleague who can help when needed or answer complicated or deeply technological questions). one is one one's own, so to speak. it is the same mindset, or rather attitude of not giving up and ploughing trough a problem until solution is achieved.

Always been a "Dev"..... "Senior" is often a trap for longer hours, less pay, and more responsibility for nothing. I do like helping other people out with their code, and giving them ideas for alternative easier/better to maintain code. I love talking to our end users about their experience and needs. So often the Jira ticket isn't matching the users "Vison" (however rare users having vision is.... if you ask the right questions, they DO often know what they want, just not how they want it)

I've given lots of help in the past but my name never appeared on tickets. My green boxes were few and far between. Sadly when the redundancies came - my boxes were mostly white. Axed. So be careful!

I think "Senior" is a massive extent of skills - and most people aren't on the same page of its meaning.

Some would even say "Senior" is that grumpy old guy that over-engineers everything and shouts at the youngsters if they say he's making stuff 9/10 other dev's can't maintain even with the documentation.

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.

This article could have been a sentence: a senior engineer does engineering and does the work of the PO/PM too.

I've had good PMs answer most of this themselves. Only if there's a technical detail they don't know about do they then ask specifically.

OTOH other PMs throw vague jira-shit over the fence because they know how to take advantage of seniors who have been taught to reflexively work out the details even though it should be PM's job, just like this right here:

>So we end up with “senior” engineers who can reverse a binary tree on the whiteboard but freeze when the spec is half-baked.

The story here should be "the senior engineer is senior because they tell the person responsible for the specs to not half-bake their specs", not "senior engineer is senior because they fixed someone else's incompetence", but even then, there is likely a manager that should be demanding that before the senior does.

Some of you senior engineers are less senior than others, and what I've continually seen is early senior engineers covering for other people (like half-baked specs). Eventually they learn that maybe a PM/Design should put some effort into a spec and covering for them means more work without compensation, and they stop fixing the laziness.

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.

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.

  > The moment you hand them something fuzzy, though, like ...
  > “we should probably think about scaling”,
  > that’s when you see the difference.

Leveling and what qualifies as senior has been different at every stop in my career. So, yes, ask questions and look for clarity before you start working on something and while that’s an excellent approach, it’s not that simple.

Recently, I have had this thought as well. For a project or a task, it needs to be continuously broken down, clarified, and set with a schedule and acceptance criteria, so that it can be completed.

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.

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!

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.

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.

>>reduce ambiguity

Uh huh. The one thing LLMs still suck at.

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

Knowing which road is going to take you to a deadend and which one to the destination as early as possible.

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

Junior deals with "if" statements.

Senior deals with "what-if" statements.

<EoF>

What this article describes is less "what is a senior" and more "what is not a junior." My observation, juniors have something to prove. We've all been there. We get a problem, we want to show we are as good or better than the seniors, and we dive into it head first. Sometimes, it works out. Other times, it goes very poorly.

When I was a junior, someone wanted to put a php marketing site for our product on my server. I didn't want it, saw it as a security hazard, and I had written them a custom CMS in my favorite MVC framework in two days. I had the keys, so I deployed that along side our product. It worked, they started using it, but my boss wasn't all that happy about it. It was deflating. I felt like I had moved a mountain for the company and no one was impressed. After a few months, they worked out a plan to put up a php marketing site on a server far far away from mine and everyone was happy with that.

Senior me looks back and thinks I was lucky they didn't ask for a ton of feature requests, because that would have been all my problem. I was hired to work on the product, not a CMS for the marketing team.

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

Pretty sure my age makes me senior.

> What problem are we actually trying to solve?

IMO this is the quintessentially most important question to ask as a developer. I probably ask this at least 3 times a week in meetings. One simple question can save you a lot of stress and wasted time realizing that the stakeholder's solution wasn't the best fit to solve their problem.

I know how to set the right expectations.

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

Good to hear it

This is so right

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

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.

When someone calls you senpai

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.

[dead]

[dead]

[dead]

Bro thinks this is unique to engineers.

age