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

That wasted a lot of time which is a lesson to be learned from.

I also struggled with self management.

- Junior - someone who can work under guidance.

- Regular - someone who can work alone.

- Senior - someone who can guide others.

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

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.

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.

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.

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

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.

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

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

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

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.

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.

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.

Say I'm working in the fintech industry, and my product is meant for financial specialists. For me to be able to come up with solutions that bring the most impact would require me to understand what a user of such systems might need. However, I'm very clearly not the intended user for my product. How do I bridge this gap? Am I looking at it wrong?

Edit: I'm not talking about strictly my product, but rather the product I'm working on, the company's product.

When a powerful person is lecturing about public key and forgot to address private key, and if you thoughtfully ask "but sir what about private key?", you might be shown the door. It actually happens.

Senior deals with "what-if" statements.

<EoF>

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.

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

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

From the perspective of a principal, it’s someone who knows just enough to make a big complicated mess and then feel self-important about it.

Good to hear it

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.

Uh huh. The one thing LLMs still suck at.