On Being a Senior Engineer (2012) • Hacker News Board

Re: On Being a Senior Engineer (2012)

#101

Post by austin-cheney » Wed, Aug 21, 2024, 7:09 PM UTC

OrigamiPastrami wrote: post #93

Xcelerate wrote: post #35

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…

> 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. I realize these are hypothetical numbers, but they're so clearly backwards. It's more like a 10% chance for tripling the growth with a 90% chance of failure, and even that is being optimistic.

That depends on the changes proposed. Many places I have worked at could apply simple bits of internal automation and training that easily allows for trimming, or repurposing, half or more headcount. Keep in mind software is a cost center, so changes to tech teams will never result in greater revenue but they can greatly reduce expenses.

Re: On Being a Senior Engineer (2012)

#102

Post by spacephysics » Wed, Aug 21, 2024, 7:19 PM UTC

consf wrote: post #61

delichon wrote: post #5

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.

So is it not just about coding but also about owning the issues?

To me senior means ownership above everything else.

Owning a part of the system implies that you’ll do (or organize) the risk analysis of new features, cost-benefit of bug fixing, coding (or at least outlining the design), support via documentation, communicating to product owner/stake holders/support.

Elevating from senior to staff (or principal etc) would be projects with larger scope, moving parts, and higher risk/reward.

I think its easier to see a junior to senior (if say we have two buckets).

After senior it gets tough. Does their role involve purely tech lead/coding? Or some managerial politics, pushing engineering culture/direction in whichever way is best for the company.

Really depends on the company itself, which I think is why it’s hard to standardize.

CTO at my own startup? Really a glorified senior dev with some communication and business mixed in. Upper senior dev at Netflix? Most likely masters or PhD level (not necessarily with the degree) understanding of some C.S. concepts that matter at that scale.

Re: On Being a Senior Engineer (2012)

#103

Post by philipov » Wed, Aug 21, 2024, 7:41 PM UTC

cma wrote: post #38

locuscoeruleus wrote: post #34

Earlier quoted context omitted.

On the flip side, the code that he originally wrote would never scale to a billion dollars. It was wildly inefficient. Someone with a bit more experience as a game developer, someone a bit senior if you will, was necessary to turn the idea into what it is today.

Who? They only did have a handful of people when they sold for $1 billion. Were any senior devs?

I think it would be fair to call Jens the Principal Engineer on Minecraft. Is that senior enough?

Re: On Being a Senior Engineer (2012)

#104

Post by ozim » Wed, Aug 21, 2024, 7:47 PM UTC

charlie0 wrote: post #90

Xcelerate wrote: post #35

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…

>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. This is right here is one of my biggest concerns at the moment. I know my technical skills are just as good as (if not better than) most of my peers with more YOE on p…

I think what you are looking for is what interests people.

Skills are not mutually exclusive but I suppose you are much more interested in technical stuff and to learn communication you have to become interested in other people.

I am also mostly interested in learning technical details of some software or system and not that much in what someone did with his time last weekend.

So what makes people better communicators is mostly that they are interested about other people and other people opinions and other people mood.

Re: On Being a Senior Engineer (2012)

#105

Post by charlie0 » Wed, Aug 21, 2024, 8:56 PM UTC

ozim wrote: post #104

charlie0 wrote: post #90

Earlier quoted context omitted.

>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. This is right here is one of my biggest concerns at the moment. I know my technical skills are just as good as (if not better than) most of my peers with more YOE on p…

I think what you are looking for is what interests people. Skills are not mutually exclusive but I suppose you are much more interested in technical stuff and to learn communication you have to become interested in other people. I am also mostly interested in learning technical details of some software or system and not that much in what someone did with his time last weekend. So what makes people better communicator…

Yes, this is exactly what I'm getting at. In theory, those two are not mutually exclusive, but in practice they very much are due to personal preferences and that will shape what you become good at.

Of course, there are definitely people who excel at both, but they are outliers. Most will only get/want to excel in one of those two things.

Re: On Being a Senior Engineer (2012)

#106

Post by sokoloff » Wed, Aug 21, 2024, 8:59 PM UTC

ryandrake wrote: post #88

closeparen wrote: post #84

Earlier quoted context omitted.

Isn't the counterfactual there an N-1 headcount, rather than a replacement-level worker in the same slot?

It probably doesn't matter as long as you keep it consistent. If the counterfactual was N-1 instead of a replacement worker, then almost everyone would represent positive value, and you're still comparing multiple positive numbers. Yes, there exist people who are net negatives and the company would be better off without them, but not THAT many.

I think there are many employees who are net negatives (who create less value than their full cost to the company). Sometimes this relates to the employee; many times it relates to the circumstance the employee finds themself in. (In almost any spiraling downward company, there are many employees in this situation, through no particular fault of their own.)

There are far fewer who are gross negatives (who contribute negatively overall, before compensation and other costs).

Re: On Being a Senior Engineer (2012)

#107

Post by gumby » Wed, Aug 21, 2024, 9:12 PM UTC

Xcelerate wrote: post #35

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…

> 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.

This is of course not just in "the industry" -- for an extreme example there are a lot of elections arund the world in 2024 and almost all of them have at least one candidate trying to convince the hiring team (i.e. the voters) that they are qualified to do a job they've never done before.

Re: On Being a Senior Engineer (2012)

#108

Post by feoren » Wed, Aug 21, 2024, 11:21 PM UTC

valenterry wrote: post #52

aswerty wrote: post #47

> 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 oppose…

The difference between software developement and "other forms of engineering" is that you can copy software rather easily, but you cannot copy a bridge. If you could engineering would have the same issues in estimation. In fact, take any engineering project that cannot be copied (like a new, big, custom airport) and you'll quickly see how much worth those "classical engineering estimations" really are. A mature devel…

> you can copy software rather easily, but you cannot copy a bridge

You can copy a bridge just as easily as you can copy software: just print another copy of the blueprints. Just change the header from the name of one project to another, and you're done with the engineering at that new site. What's that, the span length is different? The soil is different? The traffic patterns and weather patterns and political climate and regulations are different? Of course they are. And when you copy source code, the use case is different, the hardware is different, the database is different, the inputs are different, the client is different. Every engineering job is custom. Software and bridge. The two disciplines are not as different as you say.

Bridge engineering also undergoes an "agile" methodology as the plans are repeatedly changed during conversations with the client, discovery of new regulations, ground-truthing, etc. Remember: the outcome of engineering is plans, not a finished product.

You're talking about differences in constructing the thing, after the engineering is complete. That's largely irrelevant to the engineering cost.

Re: On Being a Senior Engineer (2012)

#109

Post by dasil003 » Thu, Aug 22, 2024, 5:59 AM UTC

roenxi wrote: post #26

000ooo000 wrote: post #10

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.

It links to a similar problem of measuring engineering productivity, which the industry cannot do. Notch wrote Minecraft when he was around 30. He didn't have 15 years experience in professional engineering and it seems to me he mostly just mucked around writing games in his professional life. He's now recognised as creating more than a billion dollars in value. Is a "senior" engineer doing better than that at creati…

I generally agree, but I think it's more subtle than that. Levels and titles aren't really about productivity per se either, they're about defining role expectations and conferring authority to ICs in a corporate environment where there are hundreds or thousands of developers, and they are inextricably linked to the communication needs that dominate productivity in large organizations. They often don't even map between departments, let alone different companies, and especially at smaller companies that don't have the headcount for any meaningful calibration to exist.

From that lens, Notch's "level" when he created Minecraft is pretty much undefined. He obviously had technical and entrepreneurial skill, which gave him huge credibility, and is a fast-track to a certain title / level at acquisition time, but that says very little about his ability to meet the expectations of a Microsoft engineer that worked their way up to that level through promotions.

Re: On Being a Senior Engineer (2012)

#110

Post by titanomachy » Thu, Aug 22, 2024, 6:14 AM UTC

pradn wrote: post #89

strken wrote: post #65

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.

Google changed their terminal level to L4, which is a level where you can be do designs with guidance, and implement big chunks of projects on your own. The previous terminal level was L5 ("senior"), where you're expected to own multi-quarter long projects and be a tech-lead of ~5-10 people. Oddly it does end up being structured as a pyramid - lots of L3/L4 folks than L5 folks.

This used to be accurate, but is out of whack now that the big players have scaled back junior hiring so hard. My team (like many others around me) is all L5/L6, everyone writes code and there is less opportunity to lead/direct others since everyone is quite independent.

Even a few years ago, many L5s were more like rock-solid ICs than what I would consider “tech leads”. And an L5 tech-leading 7-10 people I would consider to be an L6 who just hasn’t gotten promoted yet.