[deleted]
On Being a Senior Engineer (2012)
41–50 of 120 posts
Re: On Being a Senior Engineer (2012)
#42Earlier 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.
> It was wildly inefficient. Spoiler: Minecraft Java Edition is still wildly inefficient despite having a trillion dollar company backing it for 10 years.
Wildly? I'm sure the code might be inefficient in many ways, but there have (as I understand) been performance improvements such as in chunk loading and map generation.
Even the latest (apparently controversial) recent redstone update is meant to take account of performance - https://www.minecraft.net/en-us/article/minecraft-snapshot-2...
"The performance impact of Redstone wire (connected blocks of Redstone Dust) has been improved"
I've no idea how true that statement is, of course!
Re: On Being a Senior Engineer (2012)
#43A 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,…
I think you are basically right, in many organisations you get a lot of influence based on your title and not on your skill.
Re: On Being a Senior Engineer (2012)
#44I 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.
[deleted]
Re: On Being a Senior Engineer (2012)
#45A 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,…
Yeah, I hesitated to mention that as the post was already getting a bit long. I’ve always wondered what would happen if you took a random high performing junior engineer and just immediately gave them control over a large part of the company. Or vice versa—a level 8 engineer pretends to be a junior engineer and joins another company at level 3.
I suspect the degree of comfort and familiarity that people have in these situations has a lot to do with their potential to influence company outcomes. The junior engineer would still have very little impact when immediately given a VP role and likely proxy their decision-making through others at that level, but they would learn to adapt much quicker than someone going slowly from level 3 to 4 to 5, etc. (assuming the pressure didn’t cause them to quit). There’s a reason people say joining a startup accelerates career growth at the next company.
On the other hand, the level 8 engineer would immediately get themselves invited to discussions at a higher level, because they already have the social skills required to interact in those meetings. It’s not that most junior engineers can’t set up these meetings on others’ calendars—it’s that they don’t want to because they know they’ll stand out like a sore thumb in the discussions.
There’s definitely an element of luck involved with being in the right situations so you have the opportunity to make a larger impact, and once you do, you’re more comfortable with putting yourself in situations where you can do that again. So it is self-fulfilling in a sense. But there’s also a personality component, as more ambitious people (at least within the context of a corporate environment) are willing to take on more risk of embarrassing themselves by potentially failing at a higher level.
Re: On Being a Senior Engineer (2012)
#46Earlier quoted context omitted.
>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,…
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.
Re: On Being a Senior Engineer (2012)
#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 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.
Re: On Being a Senior Engineer (2012)
#48Earlier quoted context omitted.
> It was wildly inefficient. Spoiler: Minecraft Java Edition is still wildly inefficient despite having a trillion dollar company backing it for 10 years.
Wildly? I'm sure the code might be inefficient in many ways, but there have (as I understand) been performance improvements such as in chunk loading and map generation. Even the latest (apparently controversial) recent redstone update is meant to take account of performance - https://www.minecraft.net/en-us/article/minecraft-snapshot-2... "The performance impact of Redstone wire (connected blocks of Redstone Dust) ha…
> performance improvements such as in chunk loading and map generation
True but the general game loop is still (wildly) inefficient; hence the multitude of performance mods (Sodium, Lithium, FerriteCore, ImmediatelyFast, etc.) that are considered basic mods for anyone wanting to play the game without dipping down to tragic fps.
All of that functionality could (and should!) have been folded into the Minecraft source years ago. But Microsoft didn't buy Minecraft to give people a good experience - they bought it because it generates a non-trivial amount of money from things like Bedrock IAPs, merch licensing, etc. Updating the games is just a necessary evil that keeps the money flowing.
(Bedrock, on the other hand, is much more optimised because, IIRC, the core game was written in C++ targeting mobile devices and needed to be efficient to even work.)
Re: On Being a Senior Engineer (2012)
#49Earlier quoted context omitted.
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?
> the slim age bracket in which they would be accepted at anything below senior
What is that age bracket, in your opinion?
Re: On Being a Senior Engineer (2012)
#50A 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...