21–30 of 47 posts
Some developers are just so much slower at the Difficult Problems, so that the developers that are good at them seem like 10x (or 100x or infinitely) more productive than their peers.
But I don't think they have the same leverage on the Hard Work problems.
I usually refer to this distinction as "tall" vs. "wide" problems. Tall problems require having at least one exceptional or specialized person to solve it, whereas wide problems can be cleared by most generalist problem-solvers. The time required to solve wide problems is simply one of aggregate bandwidth. Unfortunately, I think society has a ton of people who can solve super tall problems working on super wide probl…
I think a lot of wide problems could be approached as tall problems, but the incentive structure in some places is set up to measure how much "forward" movement is made each day, so you're punished for "climbing" since people think that you're staying still instead of doing work.
> there are problems that are solvable by throwing a lot of human-hours at it (“Hard Work”), and problems that are not a function of raw work hours, but rather require dealing with ambiguity (“Difficult Problems”) There's also the 3rd category of the hell of work that is easy, ambigous, but just uses up a ton of mental space to work through that mushy ambiguity. I'd solve difficult problems all day, can stomach doing…
ambiguity can be solved by random action. I've solved so many of these uncertain problems by tossing coins. Once I make a decision, everyone comes out with reasons I'm wrong and just tells me what they want. Or, everyone accepts it and moves on and it is obvious nobody actually cares.
What are folks thoughts on changing hard work into difficult problems? That seems to be the more interesting transformation. And potentially where startups thrive. What are some cases where you thought you transformed hard work into a difficult problem?
I like this distinction, and the bit about converting difficult problems into hard-work. There's one thing that occurred to me in the context of agile + difficult problems. When I think about my sprints, the vast amount of my time is spend dominated on that one "difficult" problem, which on the surface does not feel difficult. The spirit of agile development is to _try_ to transform difficult problems into hard-work…
Every now and then a coworker would say that selling cars was easy work. So I'd ask him if it's so easy, why didn't he promise to double his sales next month? Ohh.. because that would be hard.
A lot of things are easy to do casually and hard to do intensely at scale.
Earlier quoted context omitted.
I don't think that's the spirit of agile development at all. Agile is about closed loops with fast feedback. It's about communicating quickly and reacting to new information. I don't see it as having much to do with "hard vs. difficult" at all.
It _can_. The idea of having prototypes that can be used immediately but very small in scope, not thinking about what you're going to be working on next week right now, making sure you're setting up systems that can give you fast feedback etc, are immensely helpful for difficult problems. Just taking the examples that are mentioned here: > Designing an architecture for a new, ambiguously scoped system. The MVP is, ca…
As you quoted, it's a strategy for dealing with ambiguity risks, AKA solving the wrong problem. It assumes you have a lot of small problems to solve, and separates their risks so you can solve one at a time. It doesn't deal with big unseparable risks at all.
I think there's a connection here with the mythic 10x developer as well. Some developers are just so much slower at the Difficult Problems, so that the developers that are good at them seem like 10x (or 100x or infinitely) more productive than their peers. But I don't think they have the same leverage on the Hard Work problems.
It certainly does not work for every kind of work. But when that doesn't work, you don't have extremely productive developers.
> One of my favorite working habits is to have two projects on my plate at a time: one project that is “just” implementation work, and another that involves some ambiguous design. If things go as planned, the implementation work finishes around the same time the design work does, so I can start implementing the design, and pickup another ambiguous task. Ideally, this is a cycle that perpetuates itself. Since implemen…