Comment by _ktx2 | Hacker News Reader

Comment by _ktx2 | Hacker News Reader

Parent Full thread

Being a senior engineer is weird when looking retrospectively. I remember being a junior and experiencing what the author is talking about with respect to puzzlingly staring at my seniors when they could answer obscure questions.

Now I do it and do the same things they did with me: facilitate my thought and troubleshooting process rather than give me answers. I think the people that are successful in Senior+ engineering are that way because of certain technical and character traits they've developed.

One is a willingness to be right in the long run. When I was a young engineer I would make my cases hard with data. As a senior engineer I sit back and let the machine mull for a while because I know that's what the engineering machine will do regardless of how technically right I may be. Another is knowing that right isn't always right. Sometimes the right answer is technically wrong, or the learnings of wrong need to be made before we collectively can be right. Another is a lot of patience; patience for myself, patience for others. I recently admitted I was behind on work because my power was out for three straight days. Young me would've found a coffee shop and worked those days with a single monitor down to the bone. Senior me took my dog to the park.

Not everyone makes it to senior, had I not forked my path in certain places I don't think I would have. My advice, relish your time as non-senior and ask lots of non-technical questions. The technical stuff comes over time and by necessity.

> Not everyone makes it to senior

As a someone who isn't a junior, having two years of game development (in-house game engine dev) and five years of enterprise (mostly web-based internal tools & some data engineering with big data) development under my belt, but hardly a senior either, what do you think as the alternative to not "making it to senior"? Asking out of curiosity.

Being in the "optimal zone" I think. The best dollar-value-to-expectations is probably at the mid-level. Senior+ you take on a lot more responsibility, need to know a lot more, and you're not always compensated for all that knowledge. Having been at senior and above for a while now I can say that the juice isn't always worth the squeeze.

Nothing is wrong with optimizing for actual life things. It's hard to not be a company man when you reach the higher echelons. Generally, your real life suffers some. Especially since the invention of pagerduty.

Note that this can make employment in your 50's and 60's more difficult though, even if it shouldn't.

Also, I once worked for a military contractor and one of the lead engineers told me the company valued people who wanted to remain engineers instead of moving into management. It was the path he'd followed himself as one of the founders of the company. I believed him and avoided management, only to find eventually that there was no such path to becoming a senior engineer who did no management. So I quit, which caused me a lot of trouble, but it also denied the company the benefit of many years of my learning on the job (there are few ways to prepare for a career in top secret military contracting because you have to get a clearance first before you can start studying many of the things they work on, so a trained employee is much more valuable than in many other jobs.) The senior engineer had the right idea, but he'd never actually checked that his career path was viable for anyone who was not a founder. I think this is a mistake that many companies make, essentially forcing people into management. It is very similar to the idea behind the "Peter Principle", that people rise until they reach their level of incompetence and then remain there. Engineers rise until they are forced into management and have to stop doing what they do best.

This is extremely well put! As a youngster, I never understood why my father, who is an incredibly talented engineer and perhaps an even better organizer/leader, made no particular attempt to climb the management ladder (he, frankly, was tons more qualified to be an IT exec then any of the various folks he reported to through the years). However, the older I get and the more time I spend in my carrier, the more I realize that I love the "optimal zone"! I think where that zone is varies between persons, but, for most of us, there is absolutely a point where the expectations and responsibilities start to outweigh the benefits of the job (both the tangible and the intangible ones).

In my career, I quit my corporate job and I am now focusing on engaging myself with meaningful engineering work where I can collaborate with other passionate people to solve real problems. Just like my Dad, I could be making more money climbing the ladder, but I guess I learned from his example that there is a whole lot more to life then that....

strongly concur

Staying mid level. Although the "senior" title of yesteryear is closer to the "staff" title of today, even at the top tech firms.

I'd say Amazon L6 is a good bar of what senior used to mean. Many newer (or older) companies lowered the bar to try and make people join them because dumb young people sometimes want the ego of a title rather than purely looking at the company's trajectory and compensation packages. In a way either intentionally or unintentionally there tends to be more tiers in the lower ranges of companies now, which can be a good thing for progress?

A lot of intermediates used to be stuck in this limbo zone, but some companies entry level "senior" now is basically what high-band intermediate used to mean. Worst case - paid the same, more ego. Best case - the pay band start to cross over to higher realms without going that far into the "hardcore senior" zone.

Pretty much most big tech companies have levels Junior, Mid and Senior (and above). It gets confusing because many companies skip the mid level and call anyone with 1-2+ YoE Senior. However most often Senior eng at Big Tech is a bigger deal (think coordinating the delivery of complex systems involving more than 1 team). You could easily spend the rest of your career cranking up solid code as a mid level dev if you wished.

> Another is knowing that right isn't always right.

Right isn't always correct. Being correct is being free of error. Being right is being free of blame. We should be correct in the technical, and right in the moral. If the problem involves both we should make it someone else's.

Reply on news.ycombinator.com