Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I find problems to solve as a staff engineer

lalitm.com

Post reply on HN
Print view View original

151–160 of 188 posts

Re: How I find problems to solve as a staff engineer

#151

Post by SkyPuncher »

9dev wrote: post #2

Funny people should have that problem. I have spent most of my career in the startup space, and my experience has consistently been that the amount of problems to solve is vastly larger than what I can reasonably achieve in my waking hours. So I don't find problems to solve, I try to assess which problems are most urgent, or which solution solves several of them at once. Learning to get that kind of prioritisation ri…

Working in startups has left me with almost the opposite problem. While there are many theoretical problems to solve, most are not valuable to solve until you have a reasonable degree of confidence that customers care about them.

Re: How I find problems to solve as a staff engineer

#152

Post by digitalsushi »

syndacks wrote: post #43

“The shape” — smells like tokens. Each paragraph is too perfect.

this is going to turn into a world psychosis eventually, smelling AI on people's breath. the damned thing is plagiarizing the 5% of us that write new text, the AI is in the middle, not the beginning

Re: How I find problems to solve as a staff engineer

#153

Post by bigfishrunning »

suburban_strike wrote: post #74
wpasc wrote: post #6

The author notes: > One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way. I wonder if the overall trend in tech is that engineers are experiencing less bottom-up autonomy and more top-down controll…

I noticed what you describe 5 years ago. Since then, not only have we lost autonomy, but there was no top-down direction to begin with. And there is none now. Nobody knows what the next incentive to chase is, so they're liquidating headcount and engaging in fraud to appear profitable. (re: fraud, I'm learning the hard way why my own employer's stock price dramatically improved-- ever since they switched to stack rank…

Lesson learned: Publicly traded or VC-owned companies should be de-prioritized when choosing an engineering job.

Re: How I find problems to solve as a staff engineer

#154

Post by rkozik1989 »

Throughout my entire career I've always basically done this to move up the ranks when switching employers. Its frankly always been common sense to me that the business rightly or wrongly weighs engineer value based on production, so what you ideally want to do is alleviate the pain points that lead to slower production or failure to meet things such as SLA agreements. To me (assuming you're at smaller organizations) this really isn't exclusively a Staff+ concept but something I expect from senior engineers.

Re: How I find problems to solve as a staff engineer

#155

Post by wwqrd »

In my last role as a senior you were siloed, with little visibility on larger company goals, cross team issues etc. It was nigh impossible to have a holistic view of things like mentioned in the article. I was lucky when the staff engineer handed me a problem to fix.

Have since moved to much smaller company, and I think the advice is valid there.

Re: How I find problems to solve as a staff engineer

#157

Post by teiferer »

sebastos wrote: post #87
CSMastermind wrote: post #46

This is all very good advice, but I would caution anyone asking the question at the start of the essay that they probably shouldn't be a Staff Eng. Unless you're at a company where that title is simply a rung on the ladder that doesn't have differentiated responsibilities (there are lots of those out there). Every person I've worked with who's been successful as a Staff+ Engineer, promoting them was normally more of…

I suspect you might hear a lot of push back on this take, but I for one fully agree. I would go as far as to say that in my workplace, this a nearly inverse relationship between quality of work and how actively that person is thinking about / talking about / acting-as-if-they-are-owed a promotion.

I came here to say exactly this. Thank you.

The people in my workplace that I respect the most and that are the most competent are the ones least interested in career politics and promotions. Heck they even often reject management responsibilities. They just want to do good work and management gets that and gets out of their way. In contrast, there is this guy constantly thinking what he could so to make an impression and talks about compensation and RSUs and cliffs and he is stuck where he already was 6 years ago and nobody would consider him for promotion ever.

Re: How I find problems to solve as a staff engineer

#158

Post by teiferer »

ronnier wrote: post #10

I think almost all of tech is bloated and massive layoffs wouldn’t phase most companies (though it would be harmful to people’s lives so it seems cruel to do this). Fewer people per teams means less context switching and devs own more. They don’t have to look for work, it will be in front of their face. In so many of these big tech companies I’ve worked at I’ve seen too many not having enough work to do. They end up…

> other wasteful things (doc writing)

I wish people would create more and better docs. Pour as much time into a meticulously written doc details as they discuss indentation and variable naming style.

But instead, just like with your attitude, it's considered second grade or even useless work, and as a result docs always suck if they even exist. They don't get that code is made for people to consume just as much as for the machine, and docs are just an extension of that. That's one reason LLMs are so popular, they actually tell you what you'd have found in the doc, had it existed. But LLMs are restricted to the what and don't cover the why. I some places that makes good docs even rarer. In others it makes them easier since the machine generates the "fluff" and the human just fills in the rationale.

Re: How I find problems to solve as a staff engineer

#160

Post by gajjanag »

bluGill wrote: post #88
wpasc wrote: post #6

The author notes: > One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way. I wonder if the overall trend in tech is that engineers are experiencing less bottom-up autonomy and more top-down controll…

You can get to be a staff level engineer doing that. However, beware that to really make it up the corporate ladder, you actually have to reject that. Note that I didn't say reject doing the things assigned. I mean reject it as in you figure out the things that they should be assigning and get those done instead. There are lots of different routes via staff and above level engineer. However, what they do have in comm…

> You will typically find your staff and higher level engineers rarely are actually writing code themselves.

Many so called staff+ engineers are basically glorified Google Docs engineers, or management who want to call themselves technical. It seems to be fashionable these days to call oneself "technical" without actually knowing anything of the problem domain.

They basically take all the "credit" for any innovation out of the team, and scapegoat other teams when project deliverables are not met.

Post reply on HN