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

11–20 of 188 posts

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

#11

Post by underdeserver »

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…

This is not distinct.

Even in a big corp there are always problems to solve. The point is to find problems that both:

1) are hard enough that someone junior won't be able to solve them alone, and

2) actually provide value to the company / users

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

#13

Post by zug_zug »

Eh, I'm not going to say this is wrong, but pretty much like all advice, it's kinda cheap without data. Like Dale Carnegie may be very famous and have a book and say "Use people's names all the times and your conversations will be great" but who actually knows if that makes a difference without some controlled outside study.

I see a lot of people really eager to tell other people how to staff, but a lot of them sure do seem to disagree, and most people I know get to staff anyways without any particular skill after a certain age (title inflation?) including myself.

My smell test for an engineer is -- are they trying to quantify the size of everything in terms of impact, or are they just reacting to whatever customer knocks on their door?

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

#15

Post by dominotw »

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…

yea this was the case even before ai. fighting for scope is 80% of the job now. Ppl like OP dont really need to "Act like a sponge" and figure out "problems to work on" if there is natural demand for stuff they are building work will present itself.

There is also crazy ladder climbing with all these titles and difference in payscale. So ppl like the author are trying to optimize what a role X is supposed to be doing. Everyone is just the same thing everywhere.

Everywhere you go its the same ppl, same ladder , same tools same sucking up to boss blah blah. Cant wait to get out of this shit.

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

#16

Post by tikhonj »

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.

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

#17

Post by austin-cheney »

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…

Most of my career has been spent in JavaScript and then MuleSoft. I have only ever seen top-down authority in about 20 years of doing this, except for when I was at Travelocity early in my career.

The general perception is that JavaScript work in the corporate world is for young people who have no idea what they are doing and lack the maturity to write original solutions. This perception is common from developers who do other work, management, and developers who primarily perform JavaScript work. If I want to be creative or have autonomy to do anything more ambitious than putting text to screen I have to save it for personal side projects or do unrelated work.

MuleSoft work was just more of the same with all decisions funneled to strict silos of a select few and everybody else was just a keyboard pressing stooge.

Yes, that does sound dreadful, but what's worse is that it amplifies the personalities of people who will throw others under the bus for attention and potential rock stars who perform their most diligent work at hiding from that attention.

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

#18

Post by aleksiy123 »

hyperhello wrote: post #8
esafak wrote: post #4

Earlier quoted context omitted.

He says: That taught me to let potential problems pile up. Listening the way I do leaves me with far more of them than I could possibly solve, and not all deserve action. Most don’t need to turn into projects the first time I hear about them; waiting can be a superpower.

“Can be a superpower” is so empty. What does that mean outside of trying to proliferate some cliche?

Just means it can be powerful or useful technique that can feel “magical” when employed.

I wouldn’t overthink this.

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

#19

Post by hyperhello »

aleksiy123 wrote: post #18
hyperhello wrote: post #8

Earlier quoted context omitted.

“Can be a superpower” is so empty. What does that mean outside of trying to proliferate some cliche?

Just means it can be powerful or useful technique that can feel “magical” when employed. I wouldn’t overthink this.

Not overthinking can be a superpower, but writing eloquently can be a superpower, and not trailing cliches behind your pen can be a superpower.

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

#20

Post by intoXbox »

The part I find challenging in the senior-staff twilight is that having deep technical knowledge means I can solve short term problems, just as requests, fast and effectively. The author mentions that you should spend time understanding the frustrations from other teams, but that takes up loads of time and I don’t like being the person who talks and talks but doesn’t push code and ship features. I’d love to hear how others have experienced that
Post reply on HN