On Being a Senior Engineer

A bit of a cynical take (on Hacker News no less) but after being in the industry for a while, my view is that the best definition of “level” is self-referential: it corresponds to the ability of a person to convince others that they are at that level.

I also have a definition of what I think level should ideally represent: the marginal contribution of a person’s influence on the outcome of a company, relative to the counterfactual situation where that person never worked there, adjusted for a specific threshold of risk tolerance.

In other words, you can consider two hypothetical futures for a company: one with a specific person and one without that person. You then have a probability distribution defined over the difference in outcomes. For someone at a very high level, the absolute area under this curve is large—they have a big impact on the company (whether positive or negative). For someone at a lower level, their impact is small.

Someone who is good at their job should hopefully lead to positive impact, but you can certainly adjust this for risk. Perhaps you bring in a CEO who has a 90% chance of tripling the company’s revenue/growth and a 10% chance of leading the company to failure. That might be acceptable for a hypergrowth startup. For a larger and more mature company, you might have a different risk profile.

> In general, mature engineers are comfortable with working within some nonzero amount of uncertainty and risk

Just to take that sentence as a snapshot. I find the opposite is more relevant in the software field. Essentially, being solicited for an estimate on something where the certainty and predictability on what is being built is approaching zero.

There is no doubt the "softness" of software engineering as opposed to other forms of engineering is very distinct. To the point where there is an overarching question on whether it is engineering at all. This has resulted in the iterative Agile development process competing with, if not overtaking, the Waterfall development process that exists in other engineering disciplines.

And in software "engineering" the practical steps of construction are as intellectual an activity as the design. Where in other disciplines the design is considered an intellectual activity and the implementation is not.

I'm not going anywhere particular with this train of thought - other than surfacing the risks in comparing software development to traditional engineering.

To me being a senior software engineer means that when your production system goes unstable from gremlins or cosmic rays or other mysterious sources of chaos and the business that pays for your food is in jeopardy, there's nobody to pass the buck to. You just have to buckle down and figure it out or update the resume and start working on your excuses or apologies to newly unemployed coworkers and their families.

>Avoiding responsibility for estimates is another way of saying, “I’m not ready to be relied upon for building critical pieces of infrastructure.”

There's potential for significant nuance in such a scenario and to reduce it to this silly quote hurts the piece, IMO.

I've skimmed over the article and much of it appears to be what was pounded into our (student) heads in college - it just took us time to start applying it.

Anyway, I have my own definition and it's "a person who realized that they've already forgotten stuff they used to know by heart in their junior years and approach every problem with appropriate humility stemming from said realization".

My "knowledge window" is, as I discovered, 9 years the skill that I've lost which established this was the ability to write an SQL statement - even a simple one.

One common misconception about senior engineers - akin to "promotion to management", some assume that seniors should be non-ICs (non-individual-contributors), should "multiply" their force "upon" others, organize and attend lots of meetings, "across departments", work on PowerPoint presentations, mostly do such non-coding tasks, because "only coding is so junior"... This is a good way to alienate real senior engineers who just enjoy engineering. It is perfectly valid to be IC senior/staff/principal/fellow engineer.

The article opens with a standard trope of "the generations after me are bad" and builds their arguments from there. Not sure much value should be placed on this article

I like how this article is still relevant after 12 years. It gave me some ideas why I have some problems working with my colleague (as well senior level engineer).

One very unfortunate thing when it comes to title inflation is the concept of a terminal level. Bigger tech companies don't let you just sit around and write code unless you're at a certain level, usual senior. This turns senior engineer into a de facto "this employee is competent enough not to fire if next performance review is meets expectations" title.

With experience and full-stack development, everyone is becoming a solo, individual contributor. They only collaborate, when necessary, due to time constraints. This leads to developers becoming isolated and superior, making them special and different. They are the only ones who have built things, while others are just there to support them. I've seen this phenomenon in many companies, where senior developers are not bound by the 24-hour clock and are always available. This is the reality of progress, where individuals become so skilled that they are the only ones who can do certain tasks. However, I respect the competition, but having multiple senior developers in a product company can lead to conflicts. I don't why it is but it is everywhere and making things tough for others to take decisions where you are only at the quest of these such Sr Devs.

Level ends up depending on two things:

Skill - Do you have the raw skills to do the task at hand.

Scope - What scope are you doing that task at.

Example:

- Setting up a single file server for your team, pretty easy, low effort.

- Setting up a file server / SAN to hold corporate data.

- Designing file servers for the core of your business operations.

- Doing that for a vendor, where your software and architecture choices will impact possibly impact N companies.

(Ironically the last two are closer than you think.)

But it isn't about setting up the file server software, it is about the scope, the size of the team you are likely leading, the impact of the decisions etc. Automation, repeatability, etc... Actually architect the thing instead of winging it...

The bigger the numbers get... the bigger the title, and the better, you better be, both as an engineer and as a human, willing to accept that you are wrong, and find that better answer... People are relying on you to deliver.

In my experience, especially in web development, senior developer just means excellent with boilerplate and an awareness of many tools. Thats it.

The problem is nobody bothers to define competency and very few people can actually program for the web. I mean almost nobody. Countless times here on HN I have had hiring managers tell these people don’t exist.

The way I would define competence in web development is super simple:

* Can you program in JavaScript. I do not mean React, Vue, jquery, or other abstraction bullshit. I actually mean can you program in that language, as in writing original software. This eliminates about 95% of developers.

* Can you program outside the browser in any language? This can still be JavaScript via Node or Deno but it could also be Go, Python, or Java.

* Do you understand transmission debugging for HTTP, WebSockets, session management, and messaging as an event?

The problem is most developers can at least half way accomplish the second bullet point and then attempt to fake the rest. It’s like toddlers playing pretend, which is why everything in both the startup world and corporate world are generally the same copy/paste spa app. Copy/paste is about all the developers can do.

There are many developers that can do much more, but work culture often seems hostile to originality and so they keep it to themselves for side projects.

Needs (2012) in the submission title

Many "senior engineers" are BS and are just posturing. To be honest, this idea alone has been really, really hard for me to understand personally. I learn a lot by watching other people work, and I spent way too much time seeing people posturing when I really should've been watching kind, responsible, vulnerable, open-minded people with values.

> The tl;dr on trade-offs is that everyone cuts corners, in every project. Immature engineers discover them in hindsight, disgusted. Mature engineers spell them out at the onset of a project, accept them and recognize them as part of good engineering.

And if you are that "mature" engineer, you need to remember and realize that many relatively junior engineers and non-engineer stakeholders won't always understand why you're saying X, Y, and Z.

So you'll have to figure out how to get sufficient shared understanding, or at least a lot of blind trust in your judgment.

the forever - hamster. I don't want to be senior engineer. I want to be an owner.

I hope one day we all can realise that all of the pontification about the defining qualities of a 'senior' engineer, or the height at which the bar should be set, whether the bar has slowly been lowered over time, etc is all pointless. Senior or not senior is a lens useful only to HR and insecure engineers.

Senior engineer is like a fuel efficient car - it's a meaningless marketing term used to distract attention from what matters - the pricetag and fuel consumption in hard numbers.