When did this "junior/senior" lingo get cool? I don't remember it being used when I was young. Maybe the leet code trend brought on a sort of gamification of the profession, with ranks etc..?
As a 51 year old, I hate when other old people think that “back in my day things were different”
> Evans has held his present position
with IBM since 1965. Previously, he
had been a vice president of the Fed-
eral Systems Division with the man-
agement responsibility for developing
large computing systems; the culmina-
tion of this work was the IBM/System
360. He joined IBM in 1951 as a
junior engineer and has held a variety
of engineering and management posi-
tions within the corporation
It’s way more than a “pay grade” for any company with real leveling guidelines.
This jibes with both my personal experience at BigTech, knowing the industry and various publicly available leveling guidelines. Sone are more granular
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.
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 have literally never seen or thought of this as “senior” thing. if anyone on the team regardless of their seniority does not operate this way they will see a quick exit to some other place
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.
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.
- Junior - someone who can work under guidance. - Regular - someone who can work alone. - Senior - someone who can guide others.
> Evans has held his present position with IBM since 1965. Previously, he had been a vice president of the Fed- eral Systems Division with the man- agement responsibility for developing large computing systems; the culmina- tion of this work was the IBM/System 360. He joined IBM in 1951 as a junior engineer and has held a variety of engineering and management posi- tions within the corporation
Dated 1969
https://bitsavers.org/magazines/Computer_Design/Computer_Des...
Next meme that needs to die: “back in my day, developers did it for the love and not the money”
This jibes with both my personal experience at BigTech, knowing the industry and various publicly available leveling guidelines. Sone are more granular
https://www.levels.fyi/blog/swe-level-framework.html
https://dropbox.github.io/dbx-career-framework/
The company I work for now has similar leveling guidelines, it’s also more granular.
But levels are defined by scope, impact, and dealing with ambiguity
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.
Senior deals with "what-if" statements.
<EoF>
Good to hear it