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

171–180 of 188 posts

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

#171

Post by geodel »

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?

All items true. I dug my own grave by telling management look, we can already do all new features by reusing same system at much less expense.

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

#172

Post by OJFord »

JauntyHatAngle wrote: post #142
OJFord wrote: post #138

Earlier quoted context omitted.

Doesn't that just effectively make you that person? The alternative is surely simply saying we haven't historically tracked that, should someone join and want it.

Not quite sure what you mean by that, I'm not the one making decisions of who to cut. That's one to many levels above me. Your stated argument would make sense if you're dealing with reasonable people. Which is sometimes. But I'm talking specifically when shit hits the fan and people levels above me put down a mandate across many divisions. As it is if they're making cuts they'll grasp whatever metrics they can and c…

Sorry, I was referring to your first paragraph, about someone new coming along and caring about metrics retroactively not previously cared about.

My point being that by proposing the solution 'so we should care about them, in case that happens' you effectively are (or are equivalent to) that person, you're making it happen sooner (and for sure).

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

#173

Post by hinkley »

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…

You always are going to have coworkers who don't see half the stuff you see. Sometimes convincing people which problem to let you solve in peace is the hard part.

So many places only fix a problem after they've already reaped the majority of the pain of having the problem. Like they want to experience hitting every step on the way down.

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

#174

Post by hinkley »

tikhonj wrote: post #16
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…

There are a lot of known problems... but there are also a lot of unknown, or at least unrecognized problems. Some of those unrecognized problems are going to be more useful and higher-leverage than recognized problems. The same "being a sponge" approach still helps.

I find there's some overlap between being good at Root Cause Analysis and realizing that 3 of your most common problems are really all a 4th problem, some aspects of which have not hit you yet.

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

#175

Post by hinkley »

Geof25 wrote: post #21
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…

I am doing exactly same thing of creating a solution which can be applied to multiple problems at the same time. Sometimes coworkers does not like that because they don't see me working on the problem, but on a tool which will resolve the problem and similar problems from our backlog.

Some people either want to solve a whole problem or none of it.

There's art in knowing what parts of a problem can be solved now without screwing your chances of fixing the rest later when you actually fully understand the problem, and have discovered a proper fix.

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

#176

Post by luciana1u »

fishfasell wrote: post #95
luciana1u wrote: post #94

The honest version of "find problems to solve" is usually "find the thing you keep complaining about in meetings, then realize you have the mandate to just go fix it." Half of my best work was annoyance I finally got sick of voicing.

Making life easier for yourself and your team is a big one for me, so I totally agree with you. Some times people don't complain about things they should be complaining about, because they don't know they can change them. I find that most big ticket items that unblock devs aren't code related but organizational which can in effect turn to coding issues.

[flagged]

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

#179

Post by nicedaylucas »

I started as a developer and now run a small company. For the past 5 years I've been spending most of my time on planning and product decisions.

About a year and a half ago I started using AI heavily in that process. What used to be endless searching and asking around is now me debating problems with AI and shaping direction together. It's also great for building quick prototypes to communicate with developers and designers.

Since execution got so much faster, I can focus on the business itself. We even shifted our whole process from long-term planning to short-term cycles. It's been very effective.

But it's hard. There are just so many things I've never done before.

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

#180

Post by suttontom »

OJFord wrote: post #172
JauntyHatAngle wrote: post #142

Earlier quoted context omitted.

Not quite sure what you mean by that, I'm not the one making decisions of who to cut. That's one to many levels above me. Your stated argument would make sense if you're dealing with reasonable people. Which is sometimes. But I'm talking specifically when shit hits the fan and people levels above me put down a mandate across many divisions. As it is if they're making cuts they'll grasp whatever metrics they can and c…

Sorry, I was referring to your first paragraph, about someone new coming along and caring about metrics retroactively not previously cared about. My point being that by proposing the solution 'so we should care about them, in case that happens' you effectively are (or are equivalent to) that person, you're making it happen sooner (and for sure).

The alternative is that they lay off everyone because the entire team doesn't have metrics for the work they've done. The kind of person to single someone out who hasn't been tracking their work may not be likely to just up and forgive the entire team if they've all done it that way.
Post reply on HN