4 ms·

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

by 9dev 1mo ago

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 right to keep all teams and customers happy and productive is what I'm very proud of in my career.

markus_zhang 1mo ago
You probably pivoted your career towards the startup space so you found it effortless. For others it is basically a castle with a 20m wall.
esafak 1mo ago
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.
- 9dev 1mo ago
  Yes. He also says: “How do you find problems worth working on?” a senior engineer I mentor asked me recently. My point is that I'm working in a whole different environment, and the challenge - to me - is never finding interesting problems to solve, but identifying the most important problem out of a large pool of known problems.
  - alpinisme 1mo ago
    That still sounds like it chimes with the quote you shared. The question the senior engineer was asking may have been exactly your last sentence. As in, among the “pool of known problems,” how do I find the ones worth working on? “Worth” may not mean “interesting” but “of lasting value”
- hyperhello 1mo ago
  “Can be a superpower” is so empty. What does that mean outside of trying to proliferate some cliche?
  - aleksiy123 1mo ago
    Just means it can be powerful or useful technique that can feel “magical” when employed. I wouldn’t overthink this.
    - hyperhello 1mo ago
      Not overthinking can be a superpower, but writing eloquently can be a superpower, and not trailing cliches behind your pen can be a superpower.
      - xandrius 1mo ago
        Now everyone is a bloody writing critic and everything is a piece of master literature that needs to be criticised as such.
        hyperhello 1mo ago
        No, but I’m getting really tired of seeing things that took less effort to write than it does to read. People have to process this AI-influenced LinkedIn-influenced SEO-optimized Reddit-template dung heap of worthless content-style and get past it, because even though expectations may be low, it’s in bad taste to the point that it’s starting to embarrass on a cultural scale.
underdeserver 1mo ago
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
tikhonj 1mo ago
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.
- hinkley 1mo ago
  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.
Geof25 1mo ago
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.
- hinkley 1mo ago
  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.
devmor 1mo ago
It’s the same in a large corporate environment. I have a “personal projects” doc of ideas I’ve had to make development experiences better at my current role - it’s a couple hundred lines long. I managed to get a couple of smaller tools out recently thanks to having copilot available to churn on them while I spend my time on prescribed work, but it would consume all of my time to even make a significant dent in it.
sandeepkd 1mo ago
I think this is more relevant reality. At Staff and Principal you have visibility into a lot of fires going around you. What helps is understanding the relative importance of what fire to douse and be at peace with the ones that you cannot control.
ryandrake 1mo ago
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.
- therealdrag0 1mo ago
  The challenge is finding problems that are “worth” solving as a staff engineer. General “bugs” are not staff worthy. Staff need to convince leadership to fix an architectural problem that removes a whole class of bug.
  - rckclmbr 1mo ago
    If a bugfix has big impact, even if it’s a one-liner fix, it’s still a staff problem
    - bluGill 1mo ago
      Sometimes the biggest impact you can make is just changing the spelling of T-E-H to T-H-E on a very visible page. Hopefully that's not a staff level problem in your company. I get your point. Staff levl engineers should be working on really hard problems that will make a long-term impact, but they often aren't very visible at any one moment. It's only when you look over long-term and you realize that things have slowly gotten better that you realize the impact. At least I hope they've gotten better. I've made some decisions over the years that I wonder if they really made things better or not. And it's really hard to say since there's no control where you can say, well this is what it would have been a different way.
  - DanielHB 1mo ago
    The amount of pushback I get when I do a refactor to make a certain class of bug never happen again is huge... Fortunately this kind of refactor is a lot easier nowadays with LLMs, but the QA is not improved and often what takes the longest.
xtiansimon 1mo ago
> “… the amount of problems to solve is vastly larger …” Are those problems in your “assigned“ lane? I’m curious if you’re saying something else—that your organization somehow permits, encourages, shares its tasks/problems. Or what % of your job is management?
SkyPuncher 1mo ago
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.
hinkley 1mo ago
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.

by 9dev 1mo ago

markus_zhang 1mo ago

You probably pivoted your career towards the startup space so you found it effortless. For others it is basically a castle with a 20m wall.

esafak 1mo ago

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.

9dev 1mo ago
Yes. He also says: “How do you find problems worth working on?” a senior engineer I mentor asked me recently. My point is that I'm working in a whole different environment, and the challenge - to me - is never finding interesting problems to solve, but identifying the most important problem out of a large pool of known problems.
- alpinisme 1mo ago
  That still sounds like it chimes with the quote you shared. The question the senior engineer was asking may have been exactly your last sentence. As in, among the “pool of known problems,” how do I find the ones worth working on? “Worth” may not mean “interesting” but “of lasting value”
hyperhello 1mo ago
“Can be a superpower” is so empty. What does that mean outside of trying to proliferate some cliche?
- aleksiy123 1mo ago
  Just means it can be powerful or useful technique that can feel “magical” when employed. I wouldn’t overthink this.
  - hyperhello 1mo ago
    Not overthinking can be a superpower, but writing eloquently can be a superpower, and not trailing cliches behind your pen can be a superpower.
    - xandrius 1mo ago
      Now everyone is a bloody writing critic and everything is a piece of master literature that needs to be criticised as such.
      - hyperhello 1mo ago
        No, but I’m getting really tired of seeing things that took less effort to write than it does to read. People have to process this AI-influenced LinkedIn-influenced SEO-optimized Reddit-template dung heap of worthless content-style and get past it, because even though expectations may be low, it’s in bad taste to the point that it’s starting to embarrass on a cultural scale.

underdeserver 1mo ago

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

tikhonj 1mo ago

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.

hinkley 1mo ago
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.

Geof25 1mo ago

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.

hinkley 1mo ago
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.

devmor 1mo ago

It’s the same in a large corporate environment. I have a “personal projects” doc of ideas I’ve had to make development experiences better at my current role - it’s a couple hundred lines long. I managed to get a couple of smaller tools out recently thanks to having copilot available to churn on them while I spend my time on prescribed work, but it would consume all of my time to even make a significant dent in it.

sandeepkd 1mo ago

I think this is more relevant reality. At Staff and Principal you have visibility into a lot of fires going around you. What helps is understanding the relative importance of what fire to douse and be at peace with the ones that you cannot control.

ryandrake 1mo ago

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.

therealdrag0 1mo ago
The challenge is finding problems that are “worth” solving as a staff engineer. General “bugs” are not staff worthy. Staff need to convince leadership to fix an architectural problem that removes a whole class of bug.
- rckclmbr 1mo ago
  If a bugfix has big impact, even if it’s a one-liner fix, it’s still a staff problem
  - bluGill 1mo ago
    Sometimes the biggest impact you can make is just changing the spelling of T-E-H to T-H-E on a very visible page. Hopefully that's not a staff level problem in your company. I get your point. Staff levl engineers should be working on really hard problems that will make a long-term impact, but they often aren't very visible at any one moment. It's only when you look over long-term and you realize that things have slowly gotten better that you realize the impact. At least I hope they've gotten better. I've made some decisions over the years that I wonder if they really made things better or not. And it's really hard to say since there's no control where you can say, well this is what it would have been a different way.
- DanielHB 1mo ago
  The amount of pushback I get when I do a refactor to make a certain class of bug never happen again is huge... Fortunately this kind of refactor is a lot easier nowadays with LLMs, but the QA is not improved and often what takes the longest.

xtiansimon 1mo ago

> “… the amount of problems to solve is vastly larger …” Are those problems in your “assigned“ lane? I’m curious if you’re saying something else—that your organization somehow permits, encourages, shares its tasks/problems. Or what % of your job is management?

SkyPuncher 1mo ago

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.

hinkley 1mo ago

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.