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

51–60 of 120 posts

Re: On Being a Senior Engineer (2012)

#51

Post by LudwigNagasena »

JamesSwift wrote: post #50
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…

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.

Re: On Being a Senior Engineer (2012)

#52

Post by valenterry »

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 developer cannot magically give a better estimation. What they can do is communicate better, understand the value of POCs and which parts of a project to tackle first to reduce uncertainty as early as possible, as well as correctly describing uncertantity (e.g. NOT with a single number).

Re: On Being a Senior Engineer (2012)

#53

Post by thehappyfellow »

baq wrote: post #46
thehappyfellow wrote: post #43

Earlier quoted context omitted.

I think you are basically right, in many organisations you get a lot of influence based on your title and not on your skill.

Skill is hard to verify. Title is used as an easy to verify proxy by design . It's a feature. How the feature is implemented in different organizations... is a different topic entirely.

I get that, but even if titles were an amazing proxy for skill, that will only correlate with some subset of skills and say nothing about the rest (e.g. some staff engineers are amazing technically and only pretty good as team leads or vice versa). Even assuming that title correlates well with some notion of skill, there are organisations which won’t allow someone with Fancy Title to make a decision requiring skill C if they’re bad at it - and some would have no way of stopping them.

Re: On Being a Senior Engineer (2012)

#54

Post by Chyzwar »

fhd2 wrote: post #28
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.

When I ran bigger companies in the past, I gravitated towards defining whether someone is entry level, junior, mid level or senior _entirely_ based on experience measured in time. And their salary was a function in which that was the primary factor. The problem with any internal definition of "senior" is that it's misaligned with the market. If you pay someone less than their market value, they're likely to leave for…

Some people never reach Senior level, both on skill level and impact. Judging someone level purely on time is a sure way to promote incompetent and lose talent that is developing faster than average. Organization promoting mediocrity, where people are awarded with random bonuses instead of opportunities.

How can you expect anything substantial from senior developers if you promoted them purely on experience measured in time?. How anybody would be motived if they can just wait for promotion? How can hire people on senior positions if you do not have internal metrics for these positions? How can you get rid of underperformers?

Re: On Being a Senior Engineer (2012)

#55

Post by thehappyfellow »

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

Re: On Being a Senior Engineer (2012)

#56

Post by candu »

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…

> ...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 influence is very much a skill in and of itself (see [1] for instance: it takes a lot to deliver even a simple, clear decision effectively!)

[1] https://randsinrepose.com/archives/mandate-dissect/

Re: On Being a Senior Engineer (2012)

#57

Post by perrygeo »

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…

Fairly common, especially with mission-critical infrastructure like databases. There's an implicit assumption, by engineers and managers alike, that 100% uptime is the gold standard and anything less is a failure. It takes a rational engineer (in the context of this discussion, usually a "senior") to point out that a) SLAs never promise 100%, b) the rest of the infrastructure that comprises the system has only a few nines of availability anyways, c) the engineering cost of getting from 99.99% to 100% is orders of magnitude higher than getting to 99.999%. In other words: senior engineers should be able to contextualize engineering work and do tradeoff analysis; they provide value not by doing more work but by skipping the expensive, low-impact work.

Re: On Being a Senior Engineer (2012)

#58

Post by axus »

baq wrote: post #46
thehappyfellow wrote: post #43

Earlier quoted context omitted.

I think you are basically right, in many organisations you get a lot of influence based on your title and not on your skill.

Skill is hard to verify. Title is used as an easy to verify proxy by design . It's a feature. How the feature is implemented in different organizations... is a different topic entirely.

The word "title" makes me think of noble titles. Hard to earn, but easy to hang on to.

Re: On Being a Senior Engineer (2012)

#59

Post by anytime5704 »

candu wrote: post #56
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…

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

Re: On Being a Senior Engineer (2012)

#60

Post by austin-cheney »

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.

Post reply on HN