Live data from Hacker News

Only solve one new problem at a time

bennadel.com

71–73 of 73 posts

Re: Only solve one new problem at a time

#71

This post actually doesn't resonate with me at all (and I've always respected Ben). I feel like I'm constantly solving a multitude of problems and actively look for opportunities where I can introduce new tech that hits on multiple disparate streams at once (I have neither the bandwidth as an org or the personal time to operate in a different manner), typically coupled with other new tech; even that is orthogonal to…

Particularly on large architectural changes - if they don't make multiple different things easier, there's a good chance they're not worth the effort.

I think that would depend a lot on context (like everything).

Re: Only solve one new problem at a time

#72
post #30

Earlier quoted context omitted.

I think the post is discussing building software/product not managing teams of people. Also a manager is not synonymous with a high bandwidth engineer.

How is a manager not synonymous with a high bandwidth engineer? If I told an engineer to execute on an immensely huge and complex problem (e.g. go build a new secondary market with tendrils into everything else the company is doing) by themselves and they did, how is that different than telling a senior manager to do the same? Really depends on the lens you're looking through.

Because a manager manages. Having weekly 1:1s with 8 direct reports is not “high bandwidth”. That’s normal bandwidth. 1 engineer doing all that on their own is incredibly high bandwidth.

Also, a high bandwidth engineer building all that is way more valuable than a manager building a team to do it, in terms of bottom line.

Sure managers are important and good ones produce results. But that’s not equivalent to a 10x engineer. That’s just the normal expectation for a manager.

Re: Only solve one new problem at a time

#73
post #14

As a general rule, successful programmers have been doing this forever: - It works. You added 2 things. It doesn't work. Which thing broke it? - It doesn't work. You changed 2 things. It works. Which thing fixed it? - It works. Two people changed it. It doesn't work. Who broke it? - One donut left. 2 programmers went into break room. No donuts left. Who ate it? Now change "2" to "1" in all of the above examples. See…

That can be a horrible time sink as well though. Imagine if only changing one thing means, that you need a test cycle of 15 minutes or even if it is only 5 minutes. You will need 5 minutes per change then. If you know multiple things you still need to change ahead of time, you might also go ahead and fix them all, and then fix resulting or remaining issues after only running one test cycle. I think it depends on the…

> Imagine if only changing one thing means, that you need a test cycle of 15 minutes or even if it is only 5 minutes.

Step 0: Shorten the test cycle.

Post reply on HN