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

161–170 of 188 posts

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

#161

Post by NewsaHackO »

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…

The issue is stuff like job security and layoffs; it’s easy to not care about what position you have until someone is looking to fire 20% of non staff engineers and suddenly you are afraid of being on the chopping block.

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

#162

Post by zuzululu »

4lx87 wrote: post #84
zuzululu wrote: post #28

My advice as someone working at staff engineer role for 3 different employers remotely and the "let problems accumulate" resonates but different context: - don't be too proactive in solving issues that signals you are not busy to your employers. - you are not hired to sit around 9-5, what you ship and how it impacts the business bottom line is far more important. Especially true when I have to juggle 3 different empl…

How do you deal with conflicting meetings? I stacked two jobs once before and ran into trouble with meeting conflicts.

This I cannot really share for legal reasons but I will give you a hint: We cannot be at two different places at the same time.

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

#163

Post by brailsafe »

Sounds like a dream, I'd love to be in this position and thought I was for a little while, but...

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

The narcissistic CTO started looking for even the most marginal of reasons to throw me under the bus; random grievances, random new technologies to add (seemingly to add keywords to the company's blog), childish manipulation tactics, literally describing how he felt the need to "whip" his engineers and that I wasn't the only one. It was a structure where basically any risk was actively discouraged, and my contract was eventually terminated for merging a mistake in a kube config that he and the DevOps owner had explicitly approved. Meanwhile, I'd been building very good vibes woth everyone on my immediate team, helping juniors, collaborating, investing myself in the success of the company, but he couldn't let go of the moment to moment control that he tried to exert at all hours of the day from across the continent.

I don't know how to avoid this in the future, if I continue in this industry, but it's overwhelmingly the norm not the exception. Give me the space to improve things and I'll work my balls off to get it done, inside the hours of the day we've agreed to. I'll delegate what I can to fresher faces in order to help them thrive and spend my time effectively, and I'll collaborate to find effective solutions or learn about areas I'm less knowledgeable about.

Incidentally, I've been wondering why I haven't really been motivated to find new work since then, and this must be a big reason why. Who the hell wants to put up with that!? It's depressing.

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

#164

Post by butlike »

noisy_boy wrote: post #126
geodel wrote: post #115

Earlier quoted context omitted.

> Especially if management rotates and new management didn't actually create the success in the first place. Critical point, and absolutely true in my case. With change in management all past successful projects are "failures" now. Instead of using x, y, z projects uses a, b, c so leadership is kind to dismiss me with prejudice.

How will you get bonus if you don't do anything different? How will you do anything different if you don't ignore/brush-aside past successes and focus on replacing them with new things? How will you replace them without funding i.e. more budget, more power? How will you keep moving up if you don't repeat this cycle?

I don't know if you're being facetious our not. I agree that that's the current landscape, but it doesn't make any sense! Imagine a great big ship sailing the oceans in ancient times. The crew made the ship sail straight. Now imagine (for argument's sake) the crew could be replaced at will. Preventing any deviation in the course is it's own success. The ship is working as intended and producing value. So to use your questions:

How will you get bonus if you don't do anything different? You won't crash the money-maker.

How will you do anything different if you don't ignore/brush-aside past successes and focus on replacing them with new things? You won't. That discipline is it's own value.

How will you replace them without funding i.e. more budget, more power? Your maintenance budget pales in comparison to the R&D budget, so funding should be a non-issue. You're not asking to recreate the boat, only replace discrete known quantities.

How will you keep moving up if you don't repeat this cycle? Because the momentum was set at ship launch, not at ship improvement.

I honestly don't understand how this all breaks down in modern times once you introduce shareholders. Is it that shareholders literally get spooked by stagnation?

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

#165

Post by Drew_ »

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…

In my org, you’re not allowed to do work like this without the title.

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

#166

Post by BatFastard »

testing22321 wrote: post #111
ryandrake wrote: post #66

Earlier quoted context omitted.

Exactly. Everywhere I've worked had at least 3-4X more bugs than we had capacity to fix, and the bug count grew over time, net of any fixing happening. There was never difficulty finding problems to solve. Unfortunately most places don't give engineering the autonomy to solve critical issues. It's just feature cram and redesigns, over and over, and let the bugs pile up.

I actually really appreciate the mindset this has given me towards life in general, and I consider it a superpower. I find people get overwhelmed and go deer in the headlights when there is a huge amount of stuff to do. I actually feel relaxed when I say “it’s not possible to do it all. There will always be more jobs than time. The only thing that matters is that we work on the most important things” I also enjoy see…

Mostly agree, one small caveat. I always had a class of critical problems. They were rarely the important, but they were critical to things running smoothly.

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

#167

Post by entropicdrifter »

butlike wrote: post #164
noisy_boy wrote: post #126

Earlier quoted context omitted.

How will you get bonus if you don't do anything different? How will you do anything different if you don't ignore/brush-aside past successes and focus on replacing them with new things? How will you replace them without funding i.e. more budget, more power? How will you keep moving up if you don't repeat this cycle?

I don't know if you're being facetious our not. I agree that that's the current landscape, but it doesn't make any sense! Imagine a great big ship sailing the oceans in ancient times. The crew made the ship sail straight. Now imagine (for argument's sake) the crew could be replaced at will. Preventing any deviation in the course is it's own success. The ship is working as intended and producing value. So to use your…

>Is it that shareholders literally get spooked by stagnation?

Yes, 100% they do. Look at what happened to Instant Pot.

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

#169

Post by NBJack »

lalitmaganti wrote: post #22
NBJack wrote: post #14

I think the first problem may be fixing the broken mobile experience. I'm getting black text on a very dark gray background.

Thanks for letting me know; I cannot reproduce this myself on my mobile (it should be white text on a dark grey background) but I pushed a speculative fix which might improve things. Please let me know if it helps or, if not, I would love to know more details so I can fix this! Thanks!

It totally did. Thanks!

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

#170

Post by 0xbadcafebee »

supriyo-biswas wrote: post #124
0xbadcafebee wrote: post #61

Earlier quoted context omitted.

It depends on company culture, and there's as many of those as there are kinds of people. I've worked at large, medium, and small companies, in many industries, and there's no common pattern. The people in charge set the tone, and the people are all different. If there's a pattern in the people, it's that more people in charge are less capable of doing the job, because they've grown up in a culture of ignorance. The…

> That's exactly what engineers are supposed to do: listen to and enable the business. This may be the case if you're a junior engineer just crunching through individual tickets, but with the lower end of software engineering being automated away where even more junior engineers have to take more product/feature ownership, I don't think "churning widgets" is the right way to think about our job anymore.

And this is why the lack of training/mentorship is having a negative effect: somebody needs to be protecting and guiding the junior engineers. They don't know they're supposed to push back and say "I'm not the person who's supposed to decide how your product works, I'm just supposed to build it". They don't know that they need to interrogate the business and get them to commit to details. They probably don't know how to have the conversation and ask those questions.

That's what mid-level and seniors have always been for, to provide that knowledge on the job. But mid-levels and seniors are increasingly the equivalent of juniors with bigger paychecks, because they didn't have someone to show them. We need apprenticeship. In the trades, an apprentice will train for years with a master tradesman who teaches what you need to qualify for the title of journeyman. We need apprenticeship in software development, and real Professional Engineer qualifications. It helps the end-user, the business, and the engineers.

Post reply on HN