What makes you senior
terriblesoftware.org
terriblesoftware.org
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."
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.
[0] https://littlegreenviper.com/miscellany/thats-not-what-ships...
Said another way: the job needs 2+2, rewards poorly, and I'm too tired for Calculus.
In my case, I really enjoy coding, and making stuff that people use.
Part of the impediments that I have encountered, is other people's attitudes. As long as co-workers and technical peers thought of me as "competition," they would deliberately make it difficult for me to access the stuff I needed to learn.
LLMs have absolutely no fear of me, and gladly give me exactly what I need (sometimes, too much).
Perhaps I could use them for the parts I don't enjoy. Or I could... not.
It's all a wash, I guess is my point. While we're out here working, leagues are idling. I aspire to be more like them.
I have been learning for myself, that's a category of useless. Would've been better spent knitting; therapy for applying the useful 2%.
I guess finding a meaningful life has always been more important to me, than being rewarded in money. I know that makes me a mutant, around these parts, but that's how I roll.
That's great for you. Sarcastic this time. I truly meant well, now I don't care. To be clear: 'shareholders' was a quip at the industry, not you.
Well, you see, life has demanded I trade a certain meaning for value creation. Hence my attitude. There's that complex I told you about. Ghoulishly wanting reciprocation, or day I say, a payoff.
I'd trade half my salary/effort to live in my home town and closer to meaning... yet, I don't. Not an option. Can't avoid RTO forever or pay bills with back-pats.
Nice implication on my life meaning, bro. Sorry, sir. I lower the rim and you dunk. Well played.
Happy (Western) Christmas Eve!
"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.
And obligatory: experience and competence may be correlated, but they are not the same.
That wasted a lot of time which is a lesson to be learned from.
I also struggled with self management.
whenever that mvp is not what was expected, if i'm lucky enough, the decomposition allows for easy adjustements to match the need
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
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)
In an ideal world, juniors would all do this too, but I don’t blame them if they don’t. So it’s very important to do it if you have the social capital.
The details of how I ask it might change based on seniority, but that I ask it? No.
The idea of “disambiguation” is itself ambiguous. The way I recognize other people solving problems at a staff level is we are communicating in terms of properties, constraints and tradeoffs. Crucially, these constraints are not necessarily business constraints, but rather, constraints inherent to an architecture. For example, queuing works for ordering because it append-only, and monotonic. So as soon as you have multiple queues (such as partitioning) or try to reorder it, it also loses its ordering guarantee. Does the problem require ordering?
The first couple chapters of Roy Fielding’s dissertation goes through this. The first time I tried reading it, I did not have experience to understand. It was a slog and I got little out of it. The next time I tried reading it, it was helping me gel and articulate things I had started observing from experience. I recognized that I had previously been so focused on architectural elements and that the properties and constraints were far more important. It is this that determines what is being traded off, and antipatterns pop out. Knowing properties and constraints allows me to quickly identify problems, and start the process of disambiguation. Many of the other staff or principal engineers I have chatted with communicate along these lines.
I don’t try to ask smart questions or dumb questions. I ask questions so that I can understand properties and constraints.
(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.
But I do think that not worrying about whether people will think I'm ignorant for asking is a very important first step that I could have applied successfully when younger. Confidence is hard earned though.
When explaining stuff I've been working on to others I often tell them "what the fuck?" is a suitable question (to try and lower this barrier) :)
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 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.
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.
- 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.
At most, maybe something like "tissue remodelling" to be lean, clean and flexible, so to speak, but not "big".
That's why I'm not a big fan of recommending people to often and quickly change jobs to increase titles and pay. Their skills don't level up the same way, and they end up with a title of senior/lead developer and can't actually build maintainable systems or solve problems that nobody tells them the solution to.
If one is unable to work alone but manages to join a new company with an inflated title, people will notice. They're gonna have to keep job-hopping until they find a place that doesn't notice the bad performance anymore.
This is demonstrable by the amount of CVs with "12 jobs in the last 6 years" in my reject pile.
Any mentor type figure is going to be at least partially evaluated by progress of the mentees against some benchmark.
This is rampant in tech, where inflated titles compensate for everything from low pay to talent wars, eroding expertise and making hiring a nightmare.
We end up with a system that prioritises optics over substance, where growth takes a backseat to checkbox promotions. It’s frustrating and counterproductive.
Mentorship should inspire organic development, not force-fed ladders that collapse under their own weight!
Instead, let’s measure seniors holistically, decoupling from junior title escalations to allow people to excel at their level indefinitely. Alternatives include:
* Technical Proficiency and Individual Contributions: Use code reviews, technical assessments, or metrics like deployment frequency and bug resolution rates to gauge a senior’s direct impact, without needing to “graduate” juniors.
This focuses on their own output and problem-solving prowess.
* Knowledge Sharing and Enablement: Track things like workshops led, documentation created, or peer feedback on guidance quality via 360 reviews—emphasising team uplift without mandatory promotions. * Project Outcomes and Efficiency: Evaluate based on team velocity improvements, innovation (e.g., patents or architectural wins), or overall delivery success, rewarding systemic contributions over individual mentee milestones. These methods honour diverse career paths, letting juniors stay put if it suits them while still valuing (and evaluating) senior leadership.
Sounds like the same kind of mistake as evaluating teachers by the grades of their students. Soon people figure out the "one weird trick" how to get the highest score easily.
In either case it's an ambiguous problem that needs to be solved and just throwing your hands up and saying that you don't want to be evaluated for that is not going to help.
It's perfectly fine remain "mid" (not junior IMHO) but is not ok to ignore guidance and advice from more experienced team members.
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.
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.
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'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.
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.
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.
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”.
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 point of the licensing is to make sure they can do the job; hiring people without the licensing means you're hiring amateurs. It's not a good solution. You need more job-training programs to fix the existing lack of engineers, which still works with licensing. There's no quick fix for a lack of qualified expertise, other than H1-B's.
Sure a board can make things more complicated, but it's because they're trying to improve things. This is a positive.
> should engineers be permitted to pick a language with known poor performance characteristics?
In electrical work, you are restricted to what parts you can use for what work, based on its application/use-case. If it's touching a house or grid it needs to be UL-listed (mandatory testing). If it's outdoor it needs to be NEMA-3 (weather-resistant) or better. If it's direct burial it needs to be UF-B (resists common outdoor issues) or better. More than 3 conductors in a raceway requires derating the condutors. You can't join dissimilar metals (aluminum, copper) without some kind of tin-plated splicer (with oxidation treatment) to prevent corrosion.
I'm sure when these standards were introduced, electricians were annoyed that they were "being limited in choice". Today we take it for granted. Our safety and stability, both as individuals and as a society, is more important than the personal preferences of engineers.
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'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
ps: even beyond work, that kind of knowledge is very important, culture is a form of abstract layer over a group, and it can make or break your future
i encountered this topic many times in my life and after many years i can safely say that what makes an engineer being considered a senior is simply a talent, or learnt skill, of problem-solving without outside input. meaning, a senior engineer will find a way to get things done, just like special military guys do, without reliance on other people(as in, there is no safety net of skilled colleague who can help when needed or answer complicated or deeply technological questions). one is one one's own, so to speak. it is the same mindset, or rather attitude of not giving up and ploughing trough a problem until solution is achieved.
I’ve seen the pursuit of disambiguation employed to deadlock a project. Sometimes that’s the right thing to do—the project sponsor doesn’t know what they want. But many times the senior needs to document some assumptions and ship something rather than frustrating the calendars of 15 people trying to nail down some exact spec. Knowing whether to step on the brake or the gas for the benefit of the team and company is a key senior trait.
This is a yes, and to the article; building without understanding the problem usually will increase chaos—though sometimes the least effort way through it is to build a prototype, and a senior would know when to do that and how to scope it.
I ran a compile and the code was riddled with errors. So I went to the PM and explained the code needed to compile and I needed a day to clean it up.
I refactored the entire project to compile and deploy that way. After that the development went very fast.
The hilarious part was the three devs who’d gone on vacation came back and thought what I’d done was “wrong”.
But the client said we (consultants) had done in two weeks what they couldn’t do in six months.
That’s what a senior engineer does.
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.
I haven't worked with IIS in more than five years, but couldn't you change some setting to infinity so the thread never sleeps... or something like that? I remember the "5 second" thing being a problem with commercial IIS apps we deployed, and that's always how we avoided it.
The solution was just to compile the app before deploying, as grandparent did.
Even back then the general consensus was that "not compiling" was a bad idea.
Most serious developers skipped this goofiness and deployed compiled and tested builds.
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?
The core trait of senior is, “gets shit done.”
I've given lots of help in the past but my name never appeared on tickets. My green boxes were few and far between. Sadly when the redundancies came - my boxes were mostly white. Axed. So be careful!
I think "Senior" is a massive extent of skills - and most people aren't on the same page of its meaning.
Some would even say "Senior" is that grumpy old guy that over-engineers everything and shouts at the youngsters if they say he's making stuff 9/10 other dev's can't maintain even with the documentation.
Soft skills are always the more important than all other skills.
> The moment you hand them something fuzzy, though, like ...
> “we should probably think about scaling”,
> that’s when you see the difference.
The author talks about the shaping of the work, so I guess this is implicit.
OTOH other PMs throw vague jira-shit over the fence because they know how to take advantage of seniors who have been taught to reflexively work out the details even though it should be PM's job, just like this right here:
>So we end up with “senior” engineers who can reverse a binary tree on the whiteboard but freeze when the spec is half-baked.
The story here should be "the senior engineer is senior because they tell the person responsible for the specs to not half-bake their specs", not "senior engineer is senior because they fixed someone else's incompetence", but even then, there is likely a manager that should be demanding that before the senior does.
Some of you senior engineers are less senior than others, and what I've continually seen is early senior engineers covering for other people (like half-baked specs). Eventually they learn that maybe a PM/Design should put some effort into a spec and covering for them means more work without compensation, and they stop fixing the laziness.
The list of example questions at the bottom is clearly not exhaustive.
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.
I think saying "no" is easier in a lot of business-related problems, and then when they're the manager, thy can decide. I also accept that as a manager, if I steer the ship incorrectly, I get to fall on that sword
> 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”
You want a promotion because you want more money. Even though I have found the difference to not be that great on the enterprise dev side. But in BigTech and adjacent, we are talking about multiple six figures differences as you move up.
I work in consulting and our bill rate is based on our title/level of responsibility. It kills me that some non customer facing consultants want to have a “career track” that doesn’t involve leading projects and strategy and want to stay completely “hands on”.
We can hire people cheaply from outside the country that can do that. There is an IC career track that is equal to a director (manager of managers). But you won’t get there hands on keyboard.
On the other hand, a “senior” working at a bank or other large non tech company will probably be making less than $175K if you aren’t working on the west coast.
For instance Delta
When I talk to a senior: “hey we got this initiative, I know only little about it. Can you talk to $stake_holder figure out what they need and come back to me and let me know your design ideas, how long you think it will take, etc”.
I can do that with a few seniors and put Epics together and they can take ownership of it.
For a junior I have to do a lot more handholding and make sure the requirements are well spelled out
It's just that my code would be shit (hard to understand, hard to test...), but I learned quickly to improve that through code reviews (both getting them, but also doing them) and architecture discussions. I can't thank the team enough that put up with me in my first 6-12 months :)
When I find a junior engineer like that, I give them as little as I can, and remain available to pair, review or discuss when they get stuck. And they... fly... But I also try to develop these qualities in everyone, but it's sometimes really hard to get people to recognize what is really important to get over the finish line.
And I've seen plenty of "senior+" engineers who can't do it and go on to harp about a field in a data model here or a field in a data model there, adding weeks to shipping something. So really, it is only a paygrade.
Any of those "competency matrices" are really just a way to reject anyone from that promotion they are hoping for: it won't be a blocker if that someone has this innate ability to help the team get things done.
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
Are you saying that when you interview for one of those tech companies that they don’t level you according to your past experience?
Yes I know the answers to all of these questions from both personal experience of interviewing and hiring at one BigTech company and ignoring outreach from another’s hiring manager who I had worked with in the past.
(At 51, I would rather get a daily anal probe with a cactus than ever work at a large company again and I am damn sure not going back into an office)
What do I suggest? I suggest that big organizations have pockets of careful, competent folks. But in general a large company tends to be all fouled up. They do a lot of things pretty much randomly. Some stuff happens the way a new graduate has a right to expect, and the way many HN commenters insist it has to go.
But a lot of other shit just ... happens. People get promoted because they have another offer from another fouled-up company, or because the boss thinks they're awesome (but sometimes the boss is dumb), or because they talk the talk exceptionally well, or because they happen to get the attention of someone 2 or 3 levels up, or whatever.
Is any of that controversial? What am I missing here?
Do people not still read Catch-22? Or has it been proved wrong or something? Or take that mysterious cactus that you mentioned in connection with large companies. What's that about? Because the cactus sounds bad.
At GE? Sure things are random. But it was also just another random enterprise company where it really didn’t make sense to work toward a promotion just to make $10-$20K more. You would be better off just getting another job (which I did after 2.5 years). There were no published leveling guidelines or procedures.
But I can guarantee you that a random mid level developer is not going to walk up to their manager with a competing offer and be handed a promotion at any of the large tech companies. The manager by themselves can’t determine a promotion. There are promo docs, committees, recommendation requirements. Etc
At 51, with just me and my wife, grown kids and already had the big house built in the burbs that sold for twice what we bought it for 8 years earlier and we downsized to a condo one third the size in state tax free Florida, the juice ain’t worth the squeeze.
But if I were 22 and had a choice between wallowing in enterprise dev making 90K doing CRUD apps or making $160K out of college and over $200K at 25, I would play the game with the best of them.
My own anecdote is that outside of BigTech now, I’m a staff consultant working at a 3rd party AWS consulting company making the same as a 25 year old SA that I mentored when they were an intern at AWS and the first year they came back
“Tell me about a project you’re most proud of?” Then I’m going to start asking questions about your decision making process, how you dealt with complexity and ambiguity, etc.
If all you did was pull well defined tickets off the Jira board, you’re not going to be able to answer that question well and you aren’t the type of person I’m going to delegate a very ambiguous assignment where you have to make good architectural and organizational decisions and have to deal with “the business” to disambiguate.
The next question would be “Looking at your resume, I see you have $x years of experience, if you could go back to one of your earlier projects, what choices would you have made differently knowing what you know now?”
If you haven’t led any major initiative, what are you going to say? “I would have pulled more tickets off the board?”
I interviewed someone from AWS at my last job, he thought he was a shoo in especially after he looked on LinkedIn and saw that I was from AWS. I guess he thought he was going to be reversing a binary tree.
No matter what I asked, he couldn’t describe anything he had done of note except be on a team who did stuff. I asked him had he led any features, presented any “six pagers” internally, blog posts on the AWS site, presentations - he had done nothing.
I passed over him for a guy at an unknown company who could talk about where he “took ownership”. That’s one of the Amazon BS Leadership Principals.
Hell I had a public footprint at AWS after only 3.5 years I had been there as a mid level L5 employee.
I know I've done all of this since day 1 of my professional software engineer career (and well, before that too). I've also been "side-moted" to a Tech Lead after 2 years of starting my career in a strong tech company too.
When I was a junior, someone wanted to put a php marketing site for our product on my server. I didn't want it, saw it as a security hazard, and I had written them a custom CMS in my favorite MVC framework in two days. I had the keys, so I deployed that along side our product. It worked, they started using it, but my boss wasn't all that happy about it. It was deflating. I felt like I had moved a mountain for the company and no one was impressed. After a few months, they worked out a plan to put up a php marketing site on a server far far away from mine and everyone was happy with that.
Senior me looks back and thinks I was lucky they didn't ask for a ton of feature requests, because that would have been all my problem. I was hired to work on the product, not a CMS for the marketing team.
Leaders reduce ambiguity, so others can operate with more clarity. The ambiguity involved can be in many different domains. It can be focused on product and tech, as in the article. Another example is ambiguity around people and organizational structure, which is more common in management roles, where some in management are more effective leaders than others. It can be around finding ways for people to understand why they might want a product, which is more common in sales and marketing roles. And so on.
Say I'm working in the fintech industry, and my product is meant for financial specialists. For me to be able to come up with solutions that bring the most impact would require me to understand what a user of such systems might need. However, I'm very clearly not the intended user for my product. How do I bridge this gap? Am I looking at it wrong?
Edit: I'm not talking about strictly my product, but rather the product I'm working on, the company's product.
The thing that, I think, has given me a competitive advantage is that I put a significant amount of effort into learning the domain I'm working in. I've gone from health care system to theoretical physics to image processing to logistics to financial plumbing to electricity markets to obscure stuff for the War Department, and so on.
The value that you really provide to a customer is deeply understanding their domain and the problem they have in that domain and then translating that for a computer. If you're just taking tickets off of Jira and writing code without context you're no better than an LLM (just kidding...maybe).
So yes, I suggest that whatever field you're working in, you put the effort into learning the domain as well as practitioners in that domain. That's how you become valuable. It's not easy, but after a few iterations you start to see patterns and it becomes easier.
Maybe some of my bias is that when you have a hammer everything looks like a nail - or in my case: when you have a matrix everything looks like an eigenvalue. YMMV.
When a powerful person is lecturing about public key and forgot to address private key, and if you thoughtfully ask "but sir what about private key?", you might be shown the door. It actually happens.
Senior deals with "what-if" statements.
<EoF>
IMO this is the quintessentially most important question to ask as a developer. I probably ask this at least 3 times a week in meetings. One simple question can save you a lot of stress and wasted time realizing that the stakeholder's solution wasn't the best fit to solve their problem.
This. Totally agree. Seniority level it’s based on the volume of practice someone has. Period.
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.
- Steven Covey
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.
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."
In my mind, a senior engineer knows what needs extra attention and where it’s ok to cut corners.
From the perspective of a principal, it’s someone who knows just enough to make a big complicated mess and then feel self-important about it.
Good to hear it
The post actually does a great job of highlighting a genuinely valuable skill that the best engineers practice regardless of their title. In particular, “reducing ambiguity” is something I believe would be really beneficial for many early-career engineers to intentionally develop.
Uh huh. The one thing LLMs still suck at.