I can see where you're coming from but personally I don't like the idea of grading the seniority scale equivalent to how much help you need/ask for. Requests for advice and assistance are not good indicators of intellectual weakness - the expert marshalling of additional resources in resolving an issue is a good thing when utilized appropriately. An example would be an engineer toiling in silence through a difficult problem on their own even though the organization has a competent expert that can expedite the process.

In my mind the difference between a junior developer and a senior developer is the ability to recognize tasks/issues and accurately prioritize them in alignment with organizational objectives. In particular I've found that when left to their own devices junior engineers tend to focus on irrelevant items and metrics such as lines of code or genericness for genericness' sake where senior engineers target important bugfixes and features that bring highest benefit to the company and customers. There are parallels with this statement and the premise of the parent comment but I think the latter draws with too broad of a brush.

> Requests for advice and assistance are not good indicators of intellectual weakness - the expert marshalling of additional resources in resolving an issue is a good thing when utilized appropriately. An example would be an engineer toiling in silence through a difficult problem on their own even though the organization has a competent expert that can expedite the process.

Intellectual strength isn't the same as senior developer. There might be correlation but it's probably not super strong. I agree that someone not asking for help is definitely junior. But I might also argue that someone who does need to ask for help probably isn't as senior as you seem to think they are.

In an ideal world, this is probably the case. Unfortunately, there are a lot of non-ideal codebases in the world.

Even the worst developer can eventually develop fluency in a poorly-designed codebase and seem much more competent than they actually are, compared to a new hire.

I think grandparent meant specifically taking the CTO's time, not a peer's time.

A lead developer starts the fire by gathering kindling.

A principle engineer invents new kinds of fire.

"Do people want fire that can be fitted nasally?"

(Douglas Adams, https://books.google.co.uk/books?id=YKHJ6WQKD3YC&pg=PT142&lp... )

And someone in AWS gets the 2AM pager wake up call.

Kindle. Fire. I'll see myself out.

Product manager calls for more wood.

Sales figures out how to pitch the fire as a feature.

Lawyers provide a solid defense from the locals who for some reason don't enjoy being neighbours of the new wood-burning power plant.

That metric strongly discourages asking questions - which is a critical part of a Senior Engineer's job.

When someone is at the level of SE, they have proven they have skills beyond slinging well-formed code - that's entry stakes for second-tier. They demonstrate a wider understanding of how their work fits into the overall product development, an understanding of customer perspective, and many other attributes. Most if not all of these derive from knowing the right questions to ask, the right people to ask them of, and the right time to do so.

The biggest differentiator is that the Senior developer should know when she needs to ask questions to proceed.

I disagree. I think everybody needs assistance every now and then, and it's important that you will ask for assistance when you need it. I strongly prefer a programmer who asks for assistance over one who will get stuck on his own for days or even weeks.

But a senior will definitely ask when he needs help, and won't wait until someone comes to him. And even without the right help, he'll still figure out some way to move forward. Usually, he can figure out his own problems while also offering assistance or guidance to others.

I can't quite put my finger exactly on what it is, but it feels like there's a difference between the kind of assistance that a senior developer asks for and the kind that a junior developer requires.

I mgiht guess that a senior developer asks for assistance when it will save them time - they could work it out, but it'll be more efficient for everyone involved if they get some assistance - whereas a junior developer would be lost without it.

I think the difference is that a senior developer will ask for help when it is a multiplier on productivity, whereas a junior will ask/need help when it is a linear gain in productivity (ie the difference is knowing how useful that help will be).

To some extent, absolutely. A junior is more likely to not know where to start, or to get stuck on a wrong path. A senior is more likely to need someone to bounce architectural ideas off, or some pointers on how to get started with some new technology.

But ultimately, anyone can get stuck hunting for a typo causing an inexplicable problem. Sometimes you just need someone to explain your problem to, just to help your own head to solve it.

> A Senior Developer should only require assistance when the building is on fire.

Senior developers require assistance all the time. Once problems are complex enough there isn't much that can be done as a solo ninja.

By that definition I should have been a senior dev when I was 22 in my first job

Well, there's also a difference between "able to solve a problem" and "able to solve a problem correctly, in ways that won't cause future pain". The latter one is the only one that can be trusted to work on a problem themselves.

That said, it's totally possible you were there, yes. The pacing of promotions vs the abilities needed for them are not always correlated appropriately.

Some people are senior when they are 22. Some people are senior when they are 44. Some people are never senior.

Age is not a good predictor.

So basically there is no way to ever become a senior developer if you work for a control freak micromanager.

Leaving and being hired as a senior may be the easiest way out.

Yes, Dice.com / Glassdoor.com / Linkedin.com