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.
'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 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.
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!
> 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.
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.
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.
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.
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!
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.
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?"
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?"
>> 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.
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.
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?
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”.
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.
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.
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.
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.
If you have PMs answering the how of issues such as "we need to improve performance" or "we should probably think about scaling", then the senior engineer on the team is the PM, not you.
The list of example questions at the bottom is clearly not exhaustive.
Sure, those two specifically can be handed off because they involve basically no user journeys for the product and a PM can't reasonably be expected to know the technical details of performance or scaling. But any PM or engineer should be able to at least ask "is the performance bad everywhere, or only specific things"?
But a PM absolutely should be diving deeper to get more details on "users are complaining about the onboarding flow" and figuring out what should be fixed or what the ideal onboarding flow should be before involving an engineer. The exception of course is the onboarding flow has errors or is slow, which again the PM is not responsible for.
This is basically a full-time job for many senior engineers. It may as well be the job description. Thing is, most of these 'leaders' are not capable hiring competent engineers - as if they're capable of identifying competence. You do not want to end up at one of those organizations - but they are everywhere.
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.
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.
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
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.
> But the client said we (consultants) had done in two weeks what they couldn’t do in six months.
I think this is more of a consultant vs employee thing than it is senior vs not-senior. There's this weird dynamic that happens where BizOps defaults to trusting and spending more on consultants, granting them more autonomy, such that they're wildly more empowered to take any risk. Employees are to be delegated to by BizOps, and BizOps doesn't like taking risks. It's paradoxical, because unless you come in with that authority or you were there extremely early, you're unlikely to acquire it, much more-so after the company's been around a few years.
This seems to me where the term "hired gun" comes from. You pay someone who's incentivized to solve a discrete important problem with their expertise quickly, whereas all of your employees are incentivized to do things for amounts of time reliably over however long, answering to product managers, implementing whatever crap to get the sale, answering to useless managers every two weeks, planning, reviewing, retrospectiving, blah blah. The consultant isn't about to go doing a broad-scale refactor if they're not paid to, and there's no reason an employee should either.
You mentioned receiving approval after providing a persuasive justification - to me it implies that you were not in the position of making the decision, rather it was up to someone else and under their supervision?
Should Senior then more correlate to the value of curating ideas, mining for conflict, gathering consensus, and execution; while operating tactfully and methodically within certain bounds of composure/temperament?
Definitely some truth to this, but I do believe there are parallels in being a hired gun and being senior. I’ve seen both variations: mid as consultant only doing the minimum and senior employee never challenging the status quo.
That's an old ASP.NET Web Forms / ASPX thing that was IIS-based. IIS would just compile .cs files into a temporary folder when first running. So the first request takes like 5s or something.
It's not the new .NET Core AOT feature, GP was building the DLLs and packaging the website locally.
Not GP but funny enough I ran into a similar problem with a team that also didn't know compilation and was just copy/pasting into a server.
> The moment you hand them something fuzzy, though, like ...
> “we should probably think about scaling”,
> that’s when you see the difference.
Senior engineers should ask, "but do we need scaling? And if it does, how much needed now and future?"
But I've seen a lot of seniors who jumped to implementing an unnecessarily complicated solution without questions, because they don't think about it too much, want to have fun, or just don't have energy to argue (I'm guilty myself).
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.
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.
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!
This is not a positive behavior, also you should ask yourself why everyone wants to go against your position so often that you have a strategy like this in the first place.
Who are the people in the room (including you) and what are they responsible and/or accountable for? There's a time and place to say "that's a bad idea", but typically it's 1:1 or very small groups not in a broad team setting. You also can't always be the naysayer, it is political capital based on a proven track record of saying what we should do instead—not necessarily in the same venue, but if you're just a perpetual pessimist it's of no more value than the irrational exuberance of the naive optimist.
Likely these are not “lose your army level” lessons. I’ve let idiots touch a hot pan if they’ve insisted to do it. I would not let someone pour gasoline on themselves and strike a match
Some people have to learn the hard way. I haven't personally encountered this in the professional world, but in my personal life there are several close family members who I've stopped giving cautionary instructions except in the most serious cases. No point in being Cassandra unless the Greeks really are invading.
Because it's not "your army" and there's no point in fighting meaningless wars. Just make a good effort to convey your point and if they still don't listen - let them learn their lesson.
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.
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
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.
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."
It is. You might pat yourself on a back that you're "not like them", and in fact might be better than them, but if they hold the same title and earn the same amount of money – they're senior just like you.
There is no denying practice is needed, but... I've been doing this (getting to reduce ambiguity and simplify complex problems) since before my first job in free software communities, yet really, I wasn't anywhere close to "senior" when I joined my first job at a demanding SW organization at 22 years old.
There was simply a lot I did not know, but I had the talent to do this part well (sure, one can argue that I had "practice" doing this with any problem since I was ~10 years old, but calling that "senior" would be... over the top: I think it rather qualifies as "talent").
It took me a couple of years of learning good software engineering from my wonderful and smart senior colleagues and through my own failures and successes for me to become a Tech Lead too.
Disagree, it's not _just_ practice. You can do something for 10,000 hours but never actively try to improve. Does that mean you're now more senior because you had more volume of practice?
e.g, let's say someone spends 10k hours doing just 'addition and subtraction' problems on 2 digit numbers. Are they now better at maths than someone who spent 0.1k hours but doing a variety of problems?
To grow as a software engineer, you need to have volume + have this be outside of your comfort zone + actively try to improve/challenge yourself.
Apart from this, I do agree it's not 'innate talent' that drives someone to become a senior engineer, and I think anyone with the right attitude / mindset can do so.
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.
But it also depends on the organization. If your managers love to micro-manage, you will be paid to do things, because someone else believes they know better than you.
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 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.
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.
>>reduce ambiguity
Uh huh. The one thing LLMs still suck at.
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.
'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.
3 replies →
I feel this way now, but with companies.
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.
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.
Are you me?
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!
> 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.
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.
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.
2 replies →
> I wish I'd known that when I was younger...
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)
5 replies →
Yes, this is so powerful.
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
1 reply →
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.)
Eh, I'd say that's very org-cultural dependent.
Honestly, orgs that don't "get this" is why consultants exist.
Schools don't teach this to students.
Reminds me of Jason Freedman's "I don't know": https://archive.vn/Z7m9M
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.
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.
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.
I do wonder how seniors manage cultural / technical differences. If the junior is not responsive to guidance, advices, hints .. what else do you do
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.
12 replies →
The problem could also be with the senior.....
talk to their manager. If their manager doesn't respond you go to your manager or the manager's manager.
let them fail and see if they change affect
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!
That's a good functional definition. Verbs beat nouns for this kind of thing.
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.
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?"
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?"
>> 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.
"Double the size of the database server!"
"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
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.
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.
(I support licensing)
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?
Isn't a comp-sci degree the barely relevant "license" in IT?
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”.
What if your company has you doing the job of a senior without the pay (because all the actual seniors left)?
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.
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.
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.
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.
If you have PMs answering the how of issues such as "we need to improve performance" or "we should probably think about scaling", then the senior engineer on the team is the PM, not you.
The list of example questions at the bottom is clearly not exhaustive.
Sure, those two specifically can be handed off because they involve basically no user journeys for the product and a PM can't reasonably be expected to know the technical details of performance or scaling. But any PM or engineer should be able to at least ask "is the performance bad everywhere, or only specific things"?
But a PM absolutely should be diving deeper to get more details on "users are complaining about the onboarding flow" and figuring out what should be fixed or what the ideal onboarding flow should be before involving an engineer. The exception of course is the onboarding flow has errors or is slow, which again the PM is not responsible for.
> fixed someone else's incompetence
This is basically a full-time job for many senior engineers. It may as well be the job description. Thing is, most of these 'leaders' are not capable hiring competent engineers - as if they're capable of identifying competence. You do not want to end up at one of those organizations - but they are everywhere.
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.
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.
If you're skilled enough, sometimes you can even force the culture to change. It can be painful and not all battles are worth it, but it's doable.
2 replies →
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
This has nothing to do with seniority. This is a question of priorities.
I am literally not allowed to fix bugs at work. Nothing senior about going rogue and showing initiative.
In that case I would ticket the specific bug with as much detail as possible for scheduling. Is that also not possible? That would sound like hell…
1 reply →
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.
> But the client said we (consultants) had done in two weeks what they couldn’t do in six months.
I think this is more of a consultant vs employee thing than it is senior vs not-senior. There's this weird dynamic that happens where BizOps defaults to trusting and spending more on consultants, granting them more autonomy, such that they're wildly more empowered to take any risk. Employees are to be delegated to by BizOps, and BizOps doesn't like taking risks. It's paradoxical, because unless you come in with that authority or you were there extremely early, you're unlikely to acquire it, much more-so after the company's been around a few years.
This seems to me where the term "hired gun" comes from. You pay someone who's incentivized to solve a discrete important problem with their expertise quickly, whereas all of your employees are incentivized to do things for amounts of time reliably over however long, answering to product managers, implementing whatever crap to get the sale, answering to useless managers every two weeks, planning, reviewing, retrospectiving, blah blah. The consultant isn't about to go doing a broad-scale refactor if they're not paid to, and there's no reason an employee should either.
I would like to propose a counter perspective.
You mentioned receiving approval after providing a persuasive justification - to me it implies that you were not in the position of making the decision, rather it was up to someone else and under their supervision?
Should Senior then more correlate to the value of curating ideas, mining for conflict, gathering consensus, and execution; while operating tactfully and methodically within certain bounds of composure/temperament?
Definitely some truth to this, but I do believe there are parallels in being a hired gun and being senior. I’ve seen both variations: mid as consultant only doing the minimum and senior employee never challenging the status quo.
The core trait of senior is, “gets shit done.”
I'm not familiar with C# compile at runtime. Are you saying your change was to do an AOT compile locally?
That's an old ASP.NET Web Forms / ASPX thing that was IIS-based. IIS would just compile .cs files into a temporary folder when first running. So the first request takes like 5s or something.
It's not the new .NET Core AOT feature, GP was building the DLLs and packaging the website locally.
Not GP but funny enough I ran into a similar problem with a team that also didn't know compilation and was just copy/pasting into a server.
2 replies →
Senior engineers should ask, "but do we need scaling? And if it does, how much needed now and future?" But I've seen a lot of seniors who jumped to implementing an unnecessarily complicated solution without questions, because they don't think about it too much, want to have fun, or just don't have energy to argue (I'm guilty myself).
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.
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.
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!
This is not a positive behavior, also you should ask yourself why everyone wants to go against your position so often that you have a strategy like this in the first place.
Who are the people in the room (including you) and what are they responsible and/or accountable for? There's a time and place to say "that's a bad idea", but typically it's 1:1 or very small groups not in a broad team setting. You also can't always be the naysayer, it is political capital based on a proven track record of saying what we should do instead—not necessarily in the same venue, but if you're just a perpetual pessimist it's of no more value than the irrational exuberance of the naive optimist.
why would you lose your army to something as stupid as 'i told you so?' Don't let them do it.
Likely these are not “lose your army level” lessons. I’ve let idiots touch a hot pan if they’ve insisted to do it. I would not let someone pour gasoline on themselves and strike a match
Some people have to learn the hard way. I haven't personally encountered this in the professional world, but in my personal life there are several close family members who I've stopped giving cautionary instructions except in the most serious cases. No point in being Cassandra unless the Greeks really are invading.
Because it's not "your army" and there's no point in fighting meaningless wars. Just make a good effort to convey your point and if they still don't listen - let them learn their lesson.
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.
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
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”
9 replies →
How I became a staff engineer with 3 yoe making 140k/year
And making $25K less than a new grad at BigTech…
By 1 weird trick?
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
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
Is pay grade. You can look this up.
6 replies →
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.
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."
I agree. Someone can totally have this mindset while being an inexperienced developer.
In my mind, a senior engineer knows what needs extra attention and where it’s ok to cut corners.
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.
Based on a number of people I've worked with whose job title was Senior Engineer, it isn't that.
It is. You might pat yourself on a back that you're "not like them", and in fact might be better than them, but if they hold the same title and earn the same amount of money – they're senior just like you.
Sometimes that’s true. Sometimes it isn’t. This seems to be a discussion about the latter.
Until you get to a behavioral interview at your n+1 job…
What's that supposed to mean?
2 replies →
Junior deals with "if" statements.
Senior deals with "what-if" statements.
<EoF>
> this isn’t talent, but practice
This. Totally agree. Seniority level it’s based on the volume of practice someone has. Period.
There is no denying practice is needed, but... I've been doing this (getting to reduce ambiguity and simplify complex problems) since before my first job in free software communities, yet really, I wasn't anywhere close to "senior" when I joined my first job at a demanding SW organization at 22 years old.
There was simply a lot I did not know, but I had the talent to do this part well (sure, one can argue that I had "practice" doing this with any problem since I was ~10 years old, but calling that "senior" would be... over the top: I think it rather qualifies as "talent").
It took me a couple of years of learning good software engineering from my wonderful and smart senior colleagues and through my own failures and successes for me to become a Tech Lead too.
Disagree, it's not _just_ practice. You can do something for 10,000 hours but never actively try to improve. Does that mean you're now more senior because you had more volume of practice?
e.g, let's say someone spends 10k hours doing just 'addition and subtraction' problems on 2 digit numbers. Are they now better at maths than someone who spent 0.1k hours but doing a variety of problems?
To grow as a software engineer, you need to have volume + have this be outside of your comfort zone + actively try to improve/challenge yourself.
Apart from this, I do agree it's not 'innate talent' that drives someone to become a senior engineer, and I think anyone with the right attitude / mindset can do so.
“Some people say they have 20 years experience, when in reality, they have 1 year's experience repeated 20 times."
- Steven Covey
being senior is clearly about having certain abilities or skills and absolutely nothing to do with how long it took you to acquire those skills
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.
But it also depends on the organization. If your managers love to micro-manage, you will be paid to do things, because someone else believes they know better than you.
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
age
Related: Job Titles are Bullshit (2024) https://news.ycombinator.com/item?id=39511732
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
Nah