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

Re: On Being a Senior Engineer (2012)

#111

Post by valenterry » Thu, Aug 22, 2024, 7:04 AM UTC

feoren wrote: post #108

valenterry wrote: post #52

Earlier quoted context omitted.

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

Now you have copied the blueprint, but not the bridge. (and before you complain that software is also just a blueprint, the difference is: in one case you estimate the blueprint and not its execution, in the other case both (or even just the execution)

Re: On Being a Senior Engineer (2012)

#112

Post by fhd2 » Thu, Aug 22, 2024, 9:39 AM UTC

Chyzwar wrote: post #54

fhd2 wrote: post #28

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

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…

Exceptions exist. Sometimes I might want to hire someone with a lot of experience who doesn't provide value relative to that, I can still do it, but be very transparent about that with them. Experience in itself is valuable regardless of whether or not I can find a little system that quantifies that for me. And another important question is: Should seniors really earn that much more than juniors? Those are the kind of questions I ask myself before making exceptions.

If you have someone very experienced with a high market value who doesn't really pay off in terms of what value you can extract from them, it can make sense to look into an exit - or an exception.

With the amount of people I managed in the past, I rarely had to make exceptions. Your mileage may absolutely vary though, and there's certainly no one-size-fits-all solution. Management is hard, easy solutions and "best" practices rarely exist.

Re: On Being a Senior Engineer (2012)

#113

Post by fhd2 » Thu, Aug 22, 2024, 9:43 AM UTC

usrusr wrote: post #36

fhd2 wrote: post #28

Earlier 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?

I generally didn't pay pay seniors all _that_ much more than the juniors. And I happily hired people >60 in the past. It's not linear, it someone has 10 years, 20 years or 50 years experience, they're in the same senior range. Depending on how much they can bring to the table, I can increase their salary within that range, not purely based on age. Experience in years just tells me what range to put them in, not where in the range. I fear I haven't made that clear at all in my parent post, sorry about that.

Re: On Being a Senior Engineer (2012)

#114

Post by fhd2 » Thu, Aug 22, 2024, 9:51 AM UTC

chiefalchemist wrote: post #31

fhd2 wrote: post #28

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

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

Absolutely! But I also see a fourth option: Just make an exception. Just because you make exceptions doesn't mean your system sucks. If you make exceptions most of the time, it probably does, but I had to make them rarely.

It doesn't sound like good management, and perhaps it isn't, but I did have people that didn't entirely meet my expectations stay, without gratuitous raises of course. I'd be open about this with them: "I think it'd make sense for both of us if you worked elsewhere, and I can help you figure out where that could be and how to get there. But I'm also gonna offer you a path here if you want it."

Sometimes that turned out to not be a good decision. Sometimes it was. But I felt it was a humane solution to the problem, that exceptional situation. No manager is all-knowing enough to understand to 100% what value they're getting out of each individual employee, so it's not the most illogical thing to involve them in that decision. But more than anything, I'm not a fan of changing a system that works for the general cases to deal with rare and varied edge cases. That's premature generalisation, and I think both in software and in organisations, that is the root of all evil.

Re: On Being a Senior Engineer (2012)

#115

Post by chiefalchemist » Thu, Aug 22, 2024, 10:16 AM UTC

fhd2 wrote: post #114

chiefalchemist wrote: post #31

Earlier quoted context omitted.

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

Absolutely! But I also see a fourth option: Just make an exception. Just because you make exceptions doesn't mean your system sucks. If you make exceptions most of the time, it probably does, but I had to make them rarely. It doesn't sound like good management, and perhaps it isn't, but I did have people that didn't entirely meet my expectations stay, without gratuitous raises of course. I'd be open about this with t…

Great point. Come to think of it, it always bothers me when an outfit is very particular about hard skills set.

Do they not want ppl able and ready to learn? Does the market not change? Is the dynamics of the org that ridgid?

Sometimes ya just gotta go with what ya got (and toss in some individual and team development). It will never ever be perfect.

Re: On Being a Senior Engineer (2012)

#116

Post by pradn » Thu, Aug 22, 2024, 3:50 PM UTC

titanomachy wrote: post #110

pradn wrote: post #89

Earlier quoted context omitted.

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

You're right that the roles are somewhat flexible: somewhere between raw technical output and technical/design leadership and "program/project management".

Re: On Being a Senior Engineer (2012)

#117

Post by Chyzwar » Thu, Aug 22, 2024, 7:33 PM UTC

fhd2 wrote: post #112

Chyzwar wrote: post #54

Earlier quoted context omitted.

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…

Exceptions exist. Sometimes I might want to hire someone with a lot of experience who doesn't provide value relative to that, I can still do it, but be very transparent about that with them. Experience in itself is valuable regardless of whether or not I can find a little system that quantifies that for me. And another important question is: Should seniors really earn that much more than juniors? Those are the kind o…

> Exceptions exist. Sometimes I might want to hire someone with a lot of experience who doesn't provide value relative to that, I can still do it, but be very transparent about that with them. Experience in itself is valuable regardless of whether or not I can find a little system that quantifies that for me. And another important question is: Should seniors really earn that much more than juniors? Those are the kind of questions I ask myself before making exceptions.

Seniors can do things that are hard or impossible for juniors. A good senior developer can bootstrap a project to MVP, establish best practices, onboard and mentor juniors/mid, communicate effectively with stockholders. Senior can manage technical debt and help with estimation and roadmap. Even on purely technical output, they can be few times more efficient than juniors. Many people will fail to learn these skills even after many years working as developers. Experience is important, but overall it is a smaller part of the overall skill set of a developer. I know plenty of people of 10+ years of experience that are just mid level developers and will stay this way.

> If you have someone very experienced with a high market value who doesn't really pay off in terms of what value you can extract from them, it can make sense to look into an exit - or an exception.

If you do not have metrics other than experience, then how you can know what value to expect? I get the feeling that you hired senior developers and then put them into mid/junior level roles and responsibilities. Value that you get from senior developers depends on opportunities that you give them.

> With the amount of people I managed in the past, I rarely had to make exceptions. Your mileage may absolutely vary though, and there's certainly no one-size-fits-all solution. Management is hard, easy solutions and "best" practices rarely exist.

That there reason why software in Europe losing to US. You decided on an easy solution to measure developers by experience in years instead of actual output. You want to extract value instead of create a value. Furthermore, you also do not want to pay senior developers because you do not understand the unique value that they can bring to the table.

Re: On Being a Senior Engineer (2012)

#118

Post by usrusr » Thu, Aug 22, 2024, 8:29 PM UTC

fhd2 wrote: post #113

usrusr wrote: post #36

Earlier quoted context omitted.

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

I generally didn't pay pay seniors all _that_ much more than the juniors. And I happily hired people >60 in the past. It's not linear, it someone has 10 years, 20 years or 50 years experience, they're in the same senior range. Depending on how much they can bring to the table, I can increase their salary within that range, not purely based on age. Experience in years just tells me what range to put them in, not where…

The way tech worker ageism works is that many employers would never consider offering someone with a few years of experience (even if it's just life experience) little money. It's either a generous offer of the full package or a pass. And if previous employers skipped on the titles game ("my job description said 'programmer'"), the chance for anything other than "pass" is miniscule at employers who take titles as a given (and where people could not possibly imagine a world without).

That's what i meant: the titles don't have to mean anything in your company, but if you don't hand them out, even if only as a meaningless formality without any consequence, you're making life unnecessarily hard for employees when they need to look elsewhere. That's why i called it lead handcuffs: it makes leaving more difficult. And i don't get the impression that it's an intentional strategy ("yay, less fluctuation! Let's call them all junior janitors!"), that's why i was pointing out this aspect of "no junior or senior".

Re: On Being a Senior Engineer (2012)

#119

Post by drumdance » Fri, Aug 23, 2024, 3:46 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…

This encapsulates a hunch I've had lately: that you could probably tell a lot about a potential hire if you could read their emails and slack messages.

The best co-workers are good at communicating without being annoying or a jerk, they have a good sense of what the important issues are, and they don't let ego or trivial concerns get in the way of solving problems.

Re: On Being a Senior Engineer (2012)

#120

Post by MrDresden » Tue, Aug 27, 2024, 6:20 AM UTC

malfist wrote: post #4

The article opens with a standard trope of "the generations after me are bad" and builds their arguments from there. Not sure much value should be placed on this article

The only mention of generations in the article comes from an initial quote, which describes how the quoted party has anecdotally experienced many of a specific generation wanting to climb the seniority ladder in a very quick time.

The rest of the article then goes on to explore what the depth of knowledge and maturity of behaviour should preferably be for anyone claiming to be a senior engineer.

It does so without ever referencing generations again.

I think this is a worthwhile read.