Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Being a Senior Engineer (2012)

kitchensoap.com

Post reply on HN
Print view View original

81–90 of 120 posts

Re: On Being a Senior Engineer (2012)

#81

Post by trelane »

game_the0ry wrote: post #66
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. I agree on paper that this is a great heuristic, but an employer would be more than happy to pay you a junior or mid compensation while extract senior level contribut…

> an employer would be more than happy to pay you a junior or mid compensation while extract senior level contributions from you.

The problem with this argument is that the level also gets you a seat at tables you otherwise don't get invited to. The places where the decisions get made.

So "senior contribution" is not always possible without having the senior level on paper.

Re: On Being a Senior Engineer (2012)

#82

Post by bongodongobob »

thehappyfellow wrote: post #55
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…

A frequent form of lack of tolerance for risk I’ve seen is not being able to make a speed vs quality trade-off. One example: We were rolling out a change that had a small risk that we’ll have to manually reboot a couple of machines. The total disruption to business would’ve been less than $10k for sure. I had to fight people who wanted to spend 3 months writing a one-ff tooling lowering the chance of it happening. Ma…

$10k in lost sales/product during the downtime or $10k + the cost of IT to stand things back up, verify, resync + cost of other departments manually fixing other adjacent things that broke?

People who don't work daily in infra tend to not understand that downtime like that can have massive ripple effects. That one server, unknown to you, might have tentacles that reach all over the company. It might generate 100 tickets that now need to be verified by various IT personnel over the next few days in addition to their likely already full workload. It might have fucked up backups, DFS, patching cadence etc etc.

Re: On Being a Senior Engineer (2012)

#83

Post by austin-cheney »

snapcaster wrote: post #79
austin-cheney wrote: post #60

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…

A lot of this list seems like gatekeeping as opposed to things actually relevant for most software engineering jobs

That depends upon expectations set by leadership. I wouldn’t call someone who can’t do more than copy/paste React boilerplate any kind of engineer. At a bank everyone who is more than a junior employee wears the title Vice President, but almost none of those people are even in management.

The choice employers must make is whether it’s cheaper to overpay for someone who cannot do what they are hired for or spend the extra time waiting for someone who can. So the flip side is that hiring programmers that can’t program is gatekeeping for the hiring managers.

Re: On Being a Senior Engineer (2012)

#84

Post by closeparen »

LudwigNagasena wrote: post #51
JamesSwift wrote: post #50

Earlier quoted context omitted.

You’ve semi reinvented WAR (wins above replacement) https://www.mlb.com/glossary/advanced-stats/wins-above-repla...

They've actually described the marginal revenue product of labor. In general, all of those counterfactuals fall under the concept of opportunity costs.

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

Re: On Being a Senior Engineer (2012)

#85

Post by HL33tibCe7 »

zerr wrote: post #33

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

Senior engineers generally should have a force multiplicative effect. "IC" doesn't mean "work in a silo interacting with nobody ever". But I agree that many orgs have a problem measuring this and focus on BS.

Re: On Being a Senior Engineer (2012)

#86

Post by fifilura »

fifilura wrote: post #77
game_the0ry wrote: post #66

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. I agree on paper that this is a great heuristic, but an employer would be more than happy to pay you a junior or mid compensation while extract senior level contribut…

> For example, I have seen very senior people leave suddenly (like no notice period) and the business does not even skip a beat. Maybe that senior was great at training their replacement?

Ok, I'll guess I'll double-down since I am getting downvotes and it is still on topic.

I would be proud of someone said that about me. I have introduced new technologies (that work well) but I have also spent a significant amount of time training juniors, that I now know could handle the stack without me. Much because of their hard work of course, but a little bit because of me.

Maybe I was a one-trick-pony and this is all I knew. Or maybe I would continue improving the products by introducing new ways of working or implementing great stuff in the future.

Neither of this will be noticeable in a future without me.

But the worst kind of senior ought to be people that leave suddenly, leaving a chaos behind them.

It is like the "hero" who creates a chaotic product and puts a 100 hour week of bugfixing just before the release.

Compared to the person who just plans a product and executes according to schedule without leaving a mark.

What do you prefer?

Re: On Being a Senior Engineer (2012)

#87

Post by ryandrake »

anytime5704 wrote: post #59
candu wrote: post #56

Earlier quoted context omitted.

> ...it corresponds to the ability of a person to convince others that they are at that level. One note on this: as your career progresses, your ability to convince others around you that you're at a certain level goes from being unimportant to important, and then from there to essential. After all, you need to influence others to do just about anything that involves more than yourself - and developing that power of…

Maybe this is a semantic distinction, but I’d say “your ability to convince people (period)” is what becomes more and more important. Levels really shouldn’t factor into a problem discussion beyond determining who is involved in the discussion to begin with.

> Levels really shouldn’t factor into a problem discussion beyond determining who is involved in the discussion to begin with.

Titles shouldn't matter but they very often do. Question: "How should we integrate our product X with product Y?" Answer: "VIP David mandated that all integrations use technology Z, so it's already decided."

Re: On Being a Senior Engineer (2012)

#88

Post by ryandrake »

closeparen wrote: post #84
LudwigNagasena wrote: post #51

Earlier quoted context omitted.

They've actually described the marginal revenue product of labor. In general, all of those counterfactuals fall under the concept of opportunity costs.

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.

Re: On Being a Senior Engineer (2012)

#89

Post by pradn »

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.

Re: On Being a Senior Engineer (2012)

#90

Post by charlie0 »

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 paper, yet my communication skills are below them.

I really enjoy doing the technical stuff, but now I'm not so motivated to keep picking up technical skills because I've hit diminishing returns on it and instead now have to focus on something I don't like, nor have been great at for the longest time, and those are communication skills.

I do wonder if these skills are mutually exclusive to a large degree. ie, the thing that makes my peers better at communicating is exactly the same thing that makes less technical and vice versa. I worry about never being able to level up my comms skills without also taking my technical skills down a notch.

For me, I'm resigned to just looking for a new job to get a salary increase vs doing something I enjoy less, improving comm skills.

Post reply on HN