Live data from Hacker News

On Being a Senior Engineer (2012)

kitchensoap.com

31–40 of 120 posts

Re: On Being a Senior Engineer (2012)

#31
post #28

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…

> Is that person perhaps just not a good fit for what we need?

That's The Critical question. That is: the situation needs X (read: combo of hard tech skills and soft skills). Can they deliver X and then some?

If not, there's three choices:

1) Develop them to fill their deficiencies, if they're interested.

2) Communicate with them that the biz has evolved and the fit is a misfit. This happens with founders who evolve into CEOs and don't have the chops for that role. It happens.

3) Do nothing.

Note: A seasoned employee will always be asking the same questions. That is: is this the place for me. Should I stay or go?

Great leaders and managers are aware of the mutualness of the relationship and approach it from that pov

Re: On Being a Senior Engineer (2012)

#32
post #30

Earlier quoted context omitted.

You'd be surprised at how it's a great developer of latent narcissistic behavior. I know a couple of solid developers who immediate turned into outright jerks on promotion to senior.

> I know a couple of solid developers who immediate turned into outright jerks on promotion to senior. I know a guy who became significantly more short-fused and less friendly when he was promoted into management. I don't think he liked management work, particularly when it involved both that and fulfilling outstanding responsibilities as an IC because he was the sole SME for a variety of different products/systems w…

Yes, exactly! Thank you for posting. I tried to get at this in my [now-deleted] peer post... but failed to be nearly as effective. Was a shameful wall of text.

Seniors are juniors with a label and expectations applied. It's incredibly subjective of course. To your point, I find the conventional expectations of 'Senior' too high.

I have spent decades perfecting my technical skill. Literally since childhood. My personal skills have suffered, neither I or you want me to be a talking head.

The story of the Junior who doesn't get enough help is a bit self-fulfilling/lacking in context. How much has been given/stuck/to who? Hearing 'not enough' can either raise someone to the challenge, or create resentment.

A bit of closing irony. I was fine with providing on-site training as a Senior until RTO was ham-fisted so poorly... that I found an even more illustrious 'Principal' title, and expectations, elsewhere.

Re: On Being a Senior Engineer (2012)

#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 engineers who just enjoy engineering. It is perfectly valid to be IC senior/staff/principal/fellow engineer.

Re: On Being a Senior Engineer (2012)

#34
post #26

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…

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.

Re: On Being a Senior Engineer (2012)

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

Re: On Being a Senior Engineer (2012)

#36
post #28

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…

> As for titles, I usually didn't put "junior" or "senior" in them at all as far as I could get away with it

So instead of golden handcuffs, you apply lead handcuffs, forcing them to lie in their resume if ever they have to apply elsewhere after the day they age out of the slim age bracket in which they would be accepted at anything below senior?

Re: On Being a Senior Engineer (2012)

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

Re: On Being a Senior Engineer (2012)

#38
post #26

Earlier quoted context omitted.

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…

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?

Re: On Being a Senior Engineer (2012)

#39

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…

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

Doesn't this tie back to the self-referential nature. If you can convince others of your "level", then you can also affect more change, making the level self-fulfilling, too.

Re: On Being a Senior Engineer (2012)

#40
post #26

Earlier quoted context omitted.

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…

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.

> It was wildly inefficient.

Spoiler: Minecraft Java Edition is still wildly inefficient despite having a trillion dollar company backing it for 10 years.

Post reply on HN