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."
Ironically this can cause a lot of senior engineers to double down on conservative practices and fail to innovate or take risk imo. I’ve worked with several people at a higher level than me with more work experience who were for all effects and purposes complete idiots.
Not trying to counter your post but this reminded me of this --
"Have you ever noticed that everyone who drives slower than you is an idiot, and everyone who drives faster than you is a maniac?"
Though I agree there are some folks who resist change while others who seem to jump into new things without enough care about hard lessons of the past. And sometimes you are the one trying to keep things sane and mitigate risks while majority of your team seem to treat you as a joyless guy who always sees risks and drawbacks.
'Principal' engineer here, looking to perfect being the idiot! Knowing how to do things, and being known for it, has been an endless source of heartburn. All to say, I think there's wisdom at play. Even there.
Having 'innovated and taken risk', juice is rarely worth the squeeze. Watercooler is too crowded and layoffs too arbitrary. A middling job rewards exactly as well. Reliably.
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.
My superpower as a staff engineer was having zero shame in asking questions. Anything from "what does that abbreviation stand for?" through to "what will the traffic look like when we go live?" - mostly people are worried about looking ignorant, so weirdly this makes you look both knowledgeable and confident! I wish I'd known that when I was younger...
Unfortunately it is a bit more subtle than that though:
(1) Questions reveal a lot about someone's state of mind, particularly if there are a lot of them. If someone is actually struggling and doesn't maintain a vague silence, the people around them will figure it out even faster. Arguably not a bad thing, hiding things is a weak strategy.
(2) There is a certain type of middle manager who fears clarity, because clarity leads to accountability and at some level they have identified that as a threat to their careers. It is prudent to be very careful what sort of questions to ask that manager - "what does that abbreviation stand for?" is fine, "what is the exact problem here and what do you want the solution to look like?" or "I don't understand, can you get into the details of why you think that?" can be unexpectedly controversial.
So there is a superpower in having zero shame in asking questions, but the real trick of it is being able to identify the set of inoffensive, basic questions that will move a project along. There is a large class of technically-reasonable-politically-imprudent questions that an inexperienced engineer might ask to their detriment. I've never been afraid of asking questions but if the mindset behind the question isn't fairly polished then there can be backlash and a most people learn to avoid questions rather than getting good at being mentally flexible.
While I wouldn't say more people shouldn't do this more of the time, there is also a lot of social capital you have as a staff level person that makes it "easy" to do this. (and is part of why it's important to)
One of my favorite moves is to ask a question that I feel has an obvious answer and then say "what am I missing?" Sometimes I am right, other times I am missing something.
Either way I'm modelling:
- that it's okay to ask questions to which the answer seems obvious
In general people like to answer questions - it makes them/us feel mildly superior - hopefully in a good and positive way. You have to use some judgement on how to approach and engage.
Depending on who you are engaging with, a packet of Hobnobs (other socially acceptable bribes are available) might be needed or perhaps waiting until after lunch.
Now, your next mission is getting something done by making someone else think it was their idea in the first place. It might sound counter-intuitive: "How does that benefit me, they get the credit". Crack that conundrum and you will advance to the next level.
100% this: if you go every axis of what differentiates staff from senior one will see deep down it is about asking questions: either yourself or helping others ask the right questions (e.g. mentoring, impact/are we solving the right problem, etc.)
I struggle with this a lot. I'm currently about ten years in to the career and technically at my org I'm a "senior".
One issue I have quite often is I'll know I have a problem with understanding something and so I ask my team but then the response can be something like "you should know X" or "you should know this because of Y context" and it can be discouraging. I think a lot of the time I notice people conflate experience level with amount of context I have with something.
I'm still struggling with these kinds of challenges and I would readily admit it could be my own weakness but I also wonder if it's a team culture issue; but I've noticed this across my current org and my last one so maybe it's more of a me-problem.
> [...] the response can be something like "you should know X" or "you should know this because of Y context" and it can be discouraging.
This is definitely a cultural problem. You should get clear and non-judgmental answers to questions like these, because it should be regarded as absolutely normal that you can’t keep everything in your mind, or that you may have missed some context.
In a culturally healthy org, everybody supports each other.
usually what i did is to take an abstract spec, derive thick layers / modules to decompose the problem, and then look at the deadline to see what MVP i can draw in that space.
whenever that mvp is not what was expected, if i'm lucky enough, the decomposition allows for easy adjustements to match the need
This is very common behavior. This is where a good manager can really help. They can recognize this is happening and then provide context.
One approach to deal with ambiguity is to write a short design doc, which writes down what you are trying to do, and all of the assumptions that you are making. If you don't understand the domain, some of your assumptions will probably be wrong. The stakeholder should be able to see that and provide guidance.
If juniors ignore guidance and advice, they stay in junior roles, handling simpler, less impactful tasks.
Everyone seeks career growth, but pushing for it too quickly often just leads to inflated titles without real substance.
It’s perfectly fine to remain a mid-level engineer for your entire career if it makes you happy; it’s solid, honest work that contributes meaningfully.
Plenty of people in their 60s have held the same job for decades, and that’s okay; it can be a path to genuine satisfaction.
There's a difference between questions of cultural / technical difference and questions of competence or character.
In the end, if a junior is repeatedly not responding to appropriate guidance or advice, then that junior should be gone from that position. Same for a senior who is repeatedly dispensing inappropriate guidance or advice.
But it requires careful analysis of the situation before such a drastic course of action: is there a communication problem, a training problem, a mistake in evaluating abilities?
A senior should be able to navigate cultural and technical differences competently. A junior should understand that that the ones with responsibility for a project also have the authority to make decisions about the project, which should be honored.
Yes but there is also a temporal component as well. A Senior should be able to do all their tasks and whatever else comes their way without needing guidance. To be able to do that requires a certain level of time in position.
nah, the tasks evolve as you get older. having a senior do all their tasks and whatever else without guidance sounds like free work. even the old people in the old folk's home get an assistant to help them take their pills!
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?"
>> 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."
At my company, we do not allow tickets that prescribe a solution. A ticket can only describe a problem or a need. The engineer is then responsible for starting a conversation with the stakeholder(s) to discuss which solution might work better for them. They then implement that solution.
I know that larger companies have multiple teams that sometimes create tickets in each others' queues. I think this is a mistake. In multi-team environments, requests should go through some sort of custodian or gatekeeper who is responsible for making sure the problem or need are documented fully. This person can be a product manager or a scrum master. It should not be an engineer, though.
I realized I was senior when jr. people would ask me things like "how do I make awk do this this?" and I responded with "what problem are you trying to solve?"
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've been with my org for 10+ years. Never had a promotion, people younger than me have shot up the org who joined after I did.
The thing is I prioritize health and wellbeing over any job I've had. However I've been told I'm super reliable, well liked and hard working... Although like you I'm the quiet one at the back of the room.
I recently failed an interview for a promotion, this would have been for a senior engineer. Feedback was I failed to convince the panel I had what it takes to lead a team (despite doing this everyday anyway in the org). Makes it hard to stay motivated TBH. Back to lifting weights I guess!
I am the guy that jumped around to get a salary bump kind of looks bad but also a lot of random tech stack experience, one minute I'm doing full stack JS, next I'm doing C# and Rails.
Yeah having a presence does matter. It annoyed me that manager was buddy buddy with a coworker and he was getting all the work... But now I'm friends with my mgr and I get all the work lol, almost wish I didn't. But good learning.
I suppose if you're not after money you could stay at a company for a long time. I don't know I would stay somewhere for 10 yrs just because I'd need change. But yeah I have doubled/tripled my income by jumping jobs after a couple years.
> 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.
This is the most funny part I am encountering all the time. Either one has more experience (job hopping), or one has more weight in decision making (staying longer at one company).
It is unusually hard trying to convince a manager who had their tech stack calcified the day he was promoted to manager role.
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.
Actually it's not even years of experience, I've seen grads with 2 yrs experience promoted to Senior with a minor raise because otherwise they might leave the company.
Licensed professionals don't have identity crises, their titles and what is required of them is legally enforced. The software industry has never lobbied for the interests of "engineers", the way other professions have (taxi drivers, barbers, plumbers, real estate agents, etc formed professional groups which lobbied for laws requiring official licensing). I think it's because software developers are the laziest people on the planet, and they are happy to continue doing almost nothing in order to get hired.
Licensing never happened because its effect is to reduce the size of the labor pool and restrict what the labor pool can do as individuals. Barring the very recent abberation of the glut of new grads and not enough junior positions, even without licensing, there haven't been enough engineers to fill all the open senior-level positions. Licensure would make that problem worse.
A licensure board would also get embroiled in political disputes over what is genuinely ethical. Python is a performance nightmare, should engineers be permitted to pick a language with known poor performance characteristics? Electron is a RAM hog and battery-killer, is it an ethical choice? So how could any Python or Electron shop support licensure?
> The only thing that makes a senior are years of experience
The only thing that makes you a senior in software is whatever titles the companies you've worked for happen to give out (which may be inflated for various political or hiring reasons) while you work there and there are basically completely arbitrary criteria from company to company.
In terms of official job titles, I was a "Senior Software Engineer" like 2-3 years after I started writing code professionally, and I mention this not to toot my own horn in any way but to point out how arbitrary titles can be (and we won't even get into the debate over the 'Engineer' bit).
I think you’re being a little pedantic here. Even if we assume "senior" is an arbitrary title, the article is still a useful description for how to be effective as an experienced engineer. The title is the least interesting part of it.
It’s only useful if you consider a single anecdote useful. For every OP’s example I can come up with at least 2 where you follow their advice and it goes south, most likely there are thousands engineers who can do the same.
It’s a typical pat on the back/confirmation bias article so whoever identifies with this specific opinion can feel good and close the tab with “yeah, I’m a real senior”.
Jump ship. You'll forever be bargaining for the pay rise and if you do get it and don't deliver for whatever reason you'll end up shooting yourself in the foot. As the recent justification was for more pay.
If you have contacts on the seniors who have left, call them, ask them if they like the companies they are currently working for, and whether the companies are looking for new hires.
In the job interview, give them the list of responsibilities that you have now. Then ask for a higher salary than you have now.
I was a teacher, and I didn't notice anything similar. It's just a job -- if you can do it, you can do it. You can be more experienced, you can be more comfortable with solving certain problems, you can do it better or worse, but there is not... this.
Some software developers seem to be in a lifelong dick-measuring contest. "You are not a true X unless you know this one important thing that I know." Okay dude, now do you expect Miss Teacher to come and praise you for how clever you are? You know some things that others don't, perhaps the others know some things that you don't, why is the former important for being a true X and the latter is not.
In software engineering, "senior" or not usually means you can be trusted to take on certain problems vs. others.
In US primary school (an industry I've never worked in), this might be close to something like teacher, curriculum planner, assistant principal, principal, district supervisor, etc.
As you progress further in your field and hone your skills and knowledge, the scope and impact of your responsibilities should grow.
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
beware, some cultures are territorial in nature and this kind of hard ownership will make people slap you if you ever try to improve things as they come.
i'm in the camp of improving things regularly without hesitation but again this can devolve. another way it can turn sour is when the team is made of people too different from each other. one improvement from someone pov is a waste or even a regression for others .. then it's a 'who decides here' conversation.
that said when you have a cohesive group all focusing on pushing in the same direction then it's bliss
Then that's a bug in the organization. If you're senior enough you might make the correct boss take notice and signal this defect globally (no fingerpointing) to him/her. If they don't care or answer you know where you are now and know if you consider that you want to leave or not.
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.
Readit News
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."
"Have you ever noticed that everyone who drives slower than you is an idiot, and everyone who drives faster than you is a maniac?"
Though I agree there are some folks who resist change while others who seem to jump into new things without enough care about hard lessons of the past. And sometimes you are the one trying to keep things sane and mitigate risks while majority of your team seem to treat you as a joyless guy who always sees risks and drawbacks.
Having 'innovated and taken risk', juice is rarely worth the squeeze. Watercooler is too crowded and layoffs too arbitrary. A middling job rewards exactly as well. Reliably.
And obligatory: experience and competence may be correlated, but they are not the same.
Deleted Comment
That wasted a lot of time which is a lesson to be learned from.
I also struggled with self management.
(1) Questions reveal a lot about someone's state of mind, particularly if there are a lot of them. If someone is actually struggling and doesn't maintain a vague silence, the people around them will figure it out even faster. Arguably not a bad thing, hiding things is a weak strategy.
(2) There is a certain type of middle manager who fears clarity, because clarity leads to accountability and at some level they have identified that as a threat to their careers. It is prudent to be very careful what sort of questions to ask that manager - "what does that abbreviation stand for?" is fine, "what is the exact problem here and what do you want the solution to look like?" or "I don't understand, can you get into the details of why you think that?" can be unexpectedly controversial.
So there is a superpower in having zero shame in asking questions, but the real trick of it is being able to identify the set of inoffensive, basic questions that will move a project along. There is a large class of technically-reasonable-politically-imprudent questions that an inexperienced engineer might ask to their detriment. I've never been afraid of asking questions but if the mindset behind the question isn't fairly polished then there can be backlash and a most people learn to avoid questions rather than getting good at being mentally flexible.
While I wouldn't say more people shouldn't do this more of the time, there is also a lot of social capital you have as a staff level person that makes it "easy" to do this. (and is part of why it's important to)
One of my favorite moves is to ask a question that I feel has an obvious answer and then say "what am I missing?" Sometimes I am right, other times I am missing something.
Either way I'm modelling:
- that it's okay to ask questions to which the answer seems obvious
- that it is totally fine not to know everything
Depending on who you are engaging with, a packet of Hobnobs (other socially acceptable bribes are available) might be needed or perhaps waiting until after lunch.
Now, your next mission is getting something done by making someone else think it was their idea in the first place. It might sound counter-intuitive: "How does that benefit me, they get the credit". Crack that conundrum and you will advance to the next level.
Honestly, orgs that don't "get this" is why consultants exist.
One issue I have quite often is I'll know I have a problem with understanding something and so I ask my team but then the response can be something like "you should know X" or "you should know this because of Y context" and it can be discouraging. I think a lot of the time I notice people conflate experience level with amount of context I have with something.
I'm still struggling with these kinds of challenges and I would readily admit it could be my own weakness but I also wonder if it's a team culture issue; but I've noticed this across my current org and my last one so maybe it's more of a me-problem.
This is definitely a cultural problem. You should get clear and non-judgmental answers to questions like these, because it should be regarded as absolutely normal that you can’t keep everything in your mind, or that you may have missed some context.
In a culturally healthy org, everybody supports each other.
whenever that mvp is not what was expected, if i'm lucky enough, the decomposition allows for easy adjustements to match the need
One approach to deal with ambiguity is to write a short design doc, which writes down what you are trying to do, and all of the assumptions that you are making. If you don't understand the domain, some of your assumptions will probably be wrong. The stakeholder should be able to see that and provide guidance.
- Junior - someone who can work under guidance.
- Regular - someone who can work alone.
- Senior - someone who can guide others.
Everyone seeks career growth, but pushing for it too quickly often just leads to inflated titles without real substance.
It’s perfectly fine to remain a mid-level engineer for your entire career if it makes you happy; it’s solid, honest work that contributes meaningfully. Plenty of people in their 60s have held the same job for decades, and that’s okay; it can be a path to genuine satisfaction.
In the end, if a junior is repeatedly not responding to appropriate guidance or advice, then that junior should be gone from that position. Same for a senior who is repeatedly dispensing inappropriate guidance or advice.
But it requires careful analysis of the situation before such a drastic course of action: is there a communication problem, a training problem, a mistake in evaluating abilities?
A senior should be able to navigate cultural and technical differences competently. A junior should understand that that the ones with responsibility for a project also have the authority to make decisions about the project, which should be honored.
Deleted Comment
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?"
At my company, we do not allow tickets that prescribe a solution. A ticket can only describe a problem or a need. The engineer is then responsible for starting a conversation with the stakeholder(s) to discuss which solution might work better for them. They then implement that solution.
I know that larger companies have multiple teams that sometimes create tickets in each others' queues. I think this is a mistake. In multi-team environments, requests should go through some sort of custodian or gatekeeper who is responsible for making sure the problem or need are documented fully. This person can be a product manager or a scrum master. It should not be an engineer, though.
"No."
"But we need the capacity! The website suddenly slowed down!"
"Did the user count suddenly go up 10x?"
"... no."
"You need to fix your indexes/query/n+1 code."
This has happened so often to me over the last few years I need some cutesy version of it on a t-shirt or a mug.
Edit: Gemini Pro 3 + Nano Banana Pro made me this, which is impressing me more than I'd like to admit: https://i.postimg.cc/zXcVSz3M/query-opt.jpg
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've been with my org for 10+ years. Never had a promotion, people younger than me have shot up the org who joined after I did.
The thing is I prioritize health and wellbeing over any job I've had. However I've been told I'm super reliable, well liked and hard working... Although like you I'm the quiet one at the back of the room.
I recently failed an interview for a promotion, this would have been for a senior engineer. Feedback was I failed to convince the panel I had what it takes to lead a team (despite doing this everyday anyway in the org). Makes it hard to stay motivated TBH. Back to lifting weights I guess!
Yeah having a presence does matter. It annoyed me that manager was buddy buddy with a coworker and he was getting all the work... But now I'm friends with my mgr and I get all the work lol, almost wish I didn't. But good learning.
I suppose if you're not after money you could stay at a company for a long time. I don't know I would stay somewhere for 10 yrs just because I'd need change. But yeah I have doubled/tripled my income by jumping jobs after a couple years.
This is the most funny part I am encountering all the time. Either one has more experience (job hopping), or one has more weight in decision making (staying longer at one company).
It is unusually hard trying to convince a manager who had their tech stack calcified the day he was promoted to manager role.
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.
Licensed professionals don't have identity crises, their titles and what is required of them is legally enforced. The software industry has never lobbied for the interests of "engineers", the way other professions have (taxi drivers, barbers, plumbers, real estate agents, etc formed professional groups which lobbied for laws requiring official licensing). I think it's because software developers are the laziest people on the planet, and they are happy to continue doing almost nothing in order to get hired.
Licensing never happened because its effect is to reduce the size of the labor pool and restrict what the labor pool can do as individuals. Barring the very recent abberation of the glut of new grads and not enough junior positions, even without licensing, there haven't been enough engineers to fill all the open senior-level positions. Licensure would make that problem worse.
A licensure board would also get embroiled in political disputes over what is genuinely ethical. Python is a performance nightmare, should engineers be permitted to pick a language with known poor performance characteristics? Electron is a RAM hog and battery-killer, is it an ethical choice? So how could any Python or Electron shop support licensure?
The only thing that makes you a senior in software is whatever titles the companies you've worked for happen to give out (which may be inflated for various political or hiring reasons) while you work there and there are basically completely arbitrary criteria from company to company.
In terms of official job titles, I was a "Senior Software Engineer" like 2-3 years after I started writing code professionally, and I mention this not to toot my own horn in any way but to point out how arbitrary titles can be (and we won't even get into the debate over the 'Engineer' bit).
It’s a typical pat on the back/confirmation bias article so whoever identifies with this specific opinion can feel good and close the tab with “yeah, I’m a real senior”.
Deleted Comment
In the job interview, give them the list of responsibilities that you have now. Then ask for a higher salary than you have now.
Some software developers seem to be in a lifelong dick-measuring contest. "You are not a true X unless you know this one important thing that I know." Okay dude, now do you expect Miss Teacher to come and praise you for how clever you are? You know some things that others don't, perhaps the others know some things that you don't, why is the former important for being a true X and the latter is not.
In US primary school (an industry I've never worked in), this might be close to something like teacher, curriculum planner, assistant principal, principal, district supervisor, etc.
As you progress further in your field and hone your skills and knowledge, the scope and impact of your responsibilities should grow.
i'm in the camp of improving things regularly without hesitation but again this can devolve. another way it can turn sour is when the team is made of people too different from each other. one improvement from someone pov is a waste or even a regression for others .. then it's a 'who decides here' conversation.
that said when you have a cohesive group all focusing on pushing in the same direction then it's bliss
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.