Also a staff engineer. This is pretty much exactly what I do.

Often it is a result of suggesting an improvement to some PR for a program or system that someone is doing some work on, and discovering that for whatever reason it doesn't quite work. This tends to lead to a deep dive of really analyzing and understanding the problem and how the piece of the system fits into the overall picture. This analysis often leads to a more structured approach to a problem, placing it in the context of wider industry or CS theory, thus enabling us to leverage prior art and other people who have grappled with similar problems.

I'm surprised there was no comment here about asking the support team what is actually paper cutting the customer.

It’s difficult to see the difference between a solution looking for a problem and vice versa.

People ask XY problems and your job is to find what issue they are having, not try to help them with the attempted solution.

Basically a StackOverflow guidance on XY problem applies to the general problem solving as well.

> “How do you find problems worth working on?”

They usually find me.

I have a different problem: I can find all the problems, but I can't solve them, because they aren't within my control. The people whose control they are within aren't interested in solving them (or letting others work on them). The political and psychological games required to get people to just let you solve problems seems like a second job.

One thing that isn't often mentioned in these discussions:

Making sure that the work was actually done.

I've been a Staff Engineer and managed engineers and it's pretty shocking what people consider to be "done".

A couple examples:

- Doing a migration to using Tailscale and an engineer claims it's done even though there is just one giant ACL for the whole firm

- Migrating from one monitoring system to another despite only 80% of the alerts have been migrated

- etc

Some of this is business folks creating bad incentives. Some of it is not creating good "success criteria" for projects. Either way, someone has to go through and make sure that both the details and the big picture deliverables landed correctly.

This being HN, I'm sure someone will say something like "just hire better engineers". I've seen phenomenal engineers make bad choices here due to poor incentive design.

A perfect example:

- you reward people for hitting delivery deadlines

- you punish people when there are outages

you might think you're pretty smart until you realize the odds of getting yelled at if you miss a deadline is 100% but the odds of an outage are <100%. The EV+ outcome then becomes to hit the deadline even if you know the code isn't ready.

Again, the job of senior engineers/engineering managers is to make sure these things don't happen by both double checking work and also pushing back on bad incentives.

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

Listen to your customers but ignore what they say. “Treat your customers like a kindergarten class. If they’re all asking for a snack they’re hungry but perhaps they really need a nutritious lunch instead.”

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 employers. I will be in a long standup meeting with company A while I am answering slack messages from company B or company C has a deadline that overlaps with another and I'd have to work on at the same time.

Previously without LLMs this was very difficult but now its manageable, especially with openclaw and hermes doing a lot of lifting. This let me discover a lot of what's discussed in the article naturally.