[flagged]
How I find problems to solve as a staff engineer
131–140 of 188 posts
Re: How I find problems to solve as a staff engineer
#132The 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…
It's funny you highlighted the 'one caveat' line. I literally came here to post 'One caveat:' (and nothing else), as claude code seems cli to revel in adding an apparently obligatory 'one caveat' blurb at the end of every response. (viz. https://www.reddit.com/r/ClaudeCode/comments/1vbsr2m/one_cav... )
Struck me that the staff engineer 'finding problems to solve' might be (whether for better or worse) manifesting that same tendency.
Re: How I find problems to solve as a staff engineer
#133I 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.…
I’m in my 4th dev job of the last 12 years and every one of them has been wildly different in terms of structure, culture, tooling, work style, etc.
Re: How I find problems to solve as a staff engineer
#134The 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…
In my experience (35+ years), it is the opposite now. It used to be massively top down, and now it is more and more bottom up, at least with the companies I have experience with.
Do you mean this applies to other engineers who are less experienced than yourself or only to you?
Re: How I find problems to solve as a staff engineer
#135The 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 think this is largely true. Theoretically it follows that mature industries would become this way more and more.
In my software engineering jobs there was always strong top down product direction. In my AI research jobs people are often staring at me blankly waiting for me to tell them what we can do.
A young industry the only people who really understand the potential of what the technology can do are the experts and practioners.
Overtime all the best ideas get picked off, and the general population who are non practitioners gain enough knowledge that they can understand what the technology can do better than the experts how can impliment it.
Re: How I find problems to solve as a staff engineer
#136I have tried this approach of finding problems and solved them.
I have done a massive code cleanup, abstracting out huge code that made it extremely readable and maintainable etc but such problems are never a problem to the upper management. For them these are red flags and a pain that they fear will cause regression and extra efforts to every other team.
So it entirely depends on the area that you solve the problem.
Also, it depends on the organization that you are working with. Especially the WITCH one's rarely care for code quality.
Re: How I find problems to solve as a staff engineer
#137Earlier quoted context omitted.
Yep, and if this happens you need to get promoted quickly out of that or you’ll get stuck at it. It’s great fun, and you’ll learn about every project your company has going on by doing it.
>It’s great fun If you don't set hard boundaries it's also the fast track to great burn out.
As a European that’s a great way to get paid for a two year holiday.
Re: How I find problems to solve as a staff engineer
#138Earlier quoted context omitted.
I'm sort of in this area, and I'm fighting the same struggles because I desire "productivity", not autonomy. I asked my manager if I should be creating tickets for the work I'm coming up with, and he answered a question I didn't ask, saying he doesn't count sprint points. So I clarified, shouldn't I at least be creating tickets so that we're accounting for it in our sprint planning? And he didn't seem to care. IMO, i…
I always include sprint points or at least some metrics to track, because even in areas that don't care about it, there is some chance a new CTO/manager/buyout or whatever jumps in. Day 1 asks for metrics and then retroactively judges people's output on it. I've annoyed my team previously in demanding jiras and sprint points (and helping build it out as much as I could to not take too much of their time) because I co…
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.
Re: How I find problems to solve as a staff engineer
#139I 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…
Isn't this just true for 90% of professional service industries?
Re: How I find problems to solve as a staff engineer
#140[flagged]