[HN Gopher] Mental Model: Difficult Problems vs. Hard Work
___________________________________________________________________
Mental Model: Difficult Problems vs. Hard Work
Author : dailymorn
Score : 103 points
Date : 2022-06-23 04:27 UTC (1 days ago)
(HTM) web link (benjamincongdon.me)
(TXT) w3m dump (benjamincongdon.me)
| catchclose8919 wrote:
| > 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 hard work when its requirements are clear, but god
| keep me away from the hell of "death by a thousand papercuts" in
| the marshes of easy-but-mindspace/time-sucking quai-ambiguous
| problems...
|
| Clarifying ambiguous requirements at least is rewarding when you
| achieve that clarity and help people understand what they
| actually need. But there's hellish work that is just
| unclarifiable before doing this, you just have to crawl to that
| mud of trivial but not-so-trivial-that-you-can-think-about-
| something-else-while-doing-them... 100% better to work a garden
| or serve in bar than that!
| ochoseis wrote:
| This us why I tend to stay away from front end work. Not
| particularly difficult, but way too much wiggle room and pixel
| pushing.
| mynameisash wrote:
| >> problems that are not a function of raw work hours, but
| rather require dealing with ambiguity ("Difficult Problems")
|
| > work that is easy, ambigous, but just uses up a ton of mental
| space to work through that mushy ambiguity
|
| Am I missing something here? Because I read your third category
| as being exactly this second category. Or maybe it's halfway
| between categories one and two?
|
| Solving ambiguity, and probably lots of it, _is_ the
| difficulty. Easy but ambiguous is generally not a combination I
| see.
|
| I frequently tell my manager/team that we have two kinds of
| problems: easy ones that just take a lot of work/time to slog
| through and difficult ones that may not be much actual work
| except for figuring it out.
|
| Like, many hikes are just a whole lot of one-foot-after-
| another. But mountaineering is sometimes a short distance of
| don't-fuck-up-or-you-die.
| jvanderbot wrote:
| 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.
| waynesonfire wrote:
| So can ignorance and it's hard to tell which you're solving
| with that coin. I wouldn't want to work with you.
| jvanderbot wrote:
| "Ignorance can be solved by random action"? I don't track.
|
| If alternatives are _actually_ equivalent, and that yields
| ambiguity in decision making, that 's the worst time to go
| deep diving. "Resolve it and move on" is just a bias of
| mine.
|
| It's ok, we'll probably never work together.
| zackmorris wrote:
| Ya after graduating from college, I spent 3 years moving
| furniture from 2001-2003 and consider that the epitome of hell
| work. In that time, on the paltry wage I received, I could have
| designed and built a machine to do the work for me. So I spent
| 3 years being gaslit that I should be grateful for that job and
| that it was my patriotic duty to be there since someone had to
| do it. The whole time coming up with an invention a day that
| would have made the job safer/easier/lucrative. That broke down
| my psyche to such a degree that I didn't fully recover until
| going through ego death and healing during the pandemic 20
| years later. Now when I hear people say "nobody wants to work
| anymore", I think of successful people who didn't do what I
| did, and think to myself "damn straight they don't".
|
| The yakk shaving of today's programming has become hell work.
| We need a better way, yesterday. But we're all too busy
| spinning our wheels doing hard work to make rent as the world
| burns.
|
| Edit: I want to add that I miss the days of my youth and would
| trade if I could, even taking the good with the bad. Just
| because something is stupid doesn't mean that we have to let it
| fill our reality. Turn the guilt/shame into empathy and let go.
| zasdffaa wrote:
| OMG this is so spot on. I've been putting together a business
| document without clear statement of what's needed, and I get
| the necessary info on what they want in increments, in the form
| of 'no, do it this way' afterwards, without any overview. It's
| just taken so much time, so much more than necessary, and worn
| me down badly.
| stevage wrote:
| Wow this thread is surprisingly helpful for understanding
| just what is so taxing about a current project. It's never
| difficult. It's never repetitive. It's an endless series of
| poorly specified requirements that only get clarified after
| implementation, and I don't have access to the right
| stakeholders to do anything about it.
| colordrops wrote:
| Absolutely. Though sometimes quantity becomes quality. I had to
| take over a large project with countless moving pieces, none of
| which are particularly hard, but the vast surface area of the
| project makes it hard to hold all of it in my head at once.
| namecheapTA wrote:
| I sold cars for a living and was basically top 0.1-0.2% at it
| nationwide.
|
| 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.
| lawn wrote:
| 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.
| TheOtherHobbes wrote:
| There are problems that can be solved with a clever, elegant,
| minimal algorithm.
|
| And there are problems that are tedious because there's a huge
| amount of not very well organised data, and you have to go
| through it case by case.
|
| Especially true if you're trying to fully internationalise
| something.
|
| Examples: verifying international addresses, dealing with sales
| taxes in various countries and jurisdictions, dealing with
| import/export codes. Etc.
|
| There's nothing conceptually hard about these problems. But a
| complete solution is just a very long list of nested ifs, and
| there's nothing much anyone can do about that. (Except buy/hire
| an existing solution - if someone else has done the work.)
| marcosdumay wrote:
| Every time developers are extremely productive, it's because
| they converted hard work into difficult problems. It's not only
| that they solve those problems faster, but also that most
| people won't even try to convert them.
|
| It certainly does not work for every kind of work. But when
| that doesn't work, you don't have extremely productive
| developers.
| waynesonfire wrote:
| This blog post would work just the same if "difficult" and "hard"
| were swapped. Furthermore, the same can be said about "problems"
| and "work". Interesting? And so, in the trash it goes.
| aprime7 wrote:
| 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?
| molsongolden wrote:
| Various flavors of process automation. Lots of computer-based
| work out there that is hard for humans but simple for a
| computer. Data manipulation tasks that are rote, tedious, and
| error prone can be transformed into a single click or an
| overnight script.
| mikkergp wrote:
| A third category is easy work.
|
| As someone in devops/sre/ops/etc., I think we do alot of easy
| work and most of our more ambitious work, i.e. automating tasks
| within our control or refactoring infrastructure as code is
| turning easy work into hard work. Often times in this world
| though we're dealing with someone else's code/software. A
| problem I've seen in many companies is keeping things up to
| date. Terraform Modules, Kuberenetes components, etc. There's a
| lot of hard work involved in this, and I do dream of trying to
| turn that hard work into hard problems of making it 10x easier
| to keep everything up to date; but I don't know that I've spent
| a lot of time trying to. I spend much more time automating,
| i.e. turning "easy work" into "hard work".
|
| Sometimes avoiding the hard work is more trouble than it is
| worth, but turning hard work into hard problems can be
| difficult given the ambiguity and lack of control.
| aprime7 wrote:
| Or a much more interesting question: what are some examples of
| hard work that you're laboring through right now?
|
| Most likely folks here may have suggestions on how to convert
| it to difficult problems :-).
| dinkleberg wrote:
| That is an excellent point. Creating solutions to hard work by
| solving a difficult problem is a great land of opportunity.
|
| Something that comes immediately to mind is Hasura. They've
| taken the hard work problem of building CRUD GraphQL APIs and
| made it almost instant for their users by solving those
| difficult problems.
| dannyobrien wrote:
| I actually think this (changing hard work into difficult
| problems) can be a danger on the individual level: a dislike of
| "mere" hard work means that we often seek to transform it into
| an "interesting" difficult problem. The classic example here is
| spending a day automating a task that only takes a few minutes
| of boring low-level maintenance a week.
| Existenceblinks wrote:
| Working on difficult problems that is so abstract, I find that
|
| > Strategies that can collapse the higher dimensional Difficult
| Problem into a lower dimensional form of Hard Work reduce the
| cognitive costs to solving the problem
|
| make it worse, abstraction leaks everywhere, every level of
| abstract seems exchangeable, applicable .. while it just doesn't
| work.
|
| Abstraction is a malware of thought of breaking task down to Hard
| Work.
| nullspace wrote:
| 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 (in the way suggested in the article), but I feel
| like most people don't try very hard to do that.
|
| We could improve the way we structure our work by allowing
| ourselves to be more honest about acknowledging this, as well as
| actually putting in the mental work to figure out if parts of the
| difficult problem can be converted to "hard work".
| AnimalMuppet wrote:
| 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.
| nullspace wrote:
| 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, can you take the top 2 most ambiguous
| risky part of a potential solution and script it out. Then
| present the operating characteristics. Anti-pattern: create a
| story to design an architecture.
|
| > "Improve system performance". Profile various aspects where
| you have a hunch that things are bad. Investigate theory a,
| b, c to improve performance. Are they trivial fixes or need a
| large refactor. Build up buffers for the uncertainty but
| react when things become more certain. Anti-pattern:
| "timeboxed performance improvements"
|
| > Coordinate a rollout of a backwards incompatible change
| across N dependent systems. Sometimes you can't help but do a
| very large rollout, so alright. But one essence of agile
| development is to keep your rollouts as small as possible.
|
| Just to be clear, I'm not saying these things are not
| difficult problems, but agile (with lower case a) development
| _can_ really help, if we want it to.
| marcosdumay wrote:
| The idea of having prototypes that can be used immediately
| _assumes_ you have hard work, not difficult problems. It
| doesn 't try to transform anything into any other thing, it
| just fails to work on one of those cases.
|
| 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.
| john_minsk wrote:
| I see your point and thought the same when reading the article.
| Decomposition.
| sethkim wrote:
| 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 problems, because the
| largest (and most well-funded) organizations have the widest
| problems. In some cases they have super tall problems too, but
| past a certain size the lights stay on by solving the wide
| problems.
| sheikheddy wrote:
| The way progress is made on tall and wide problems is
| different. On tall problems, you make progress "climbing", and
| don't move forward much until you reach the peak, and then it's
| behind you all at once. For wide problems, you can make a
| little headway "forward" in little increments, which is easier
| to track.
|
| 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.
| ChrisMarshallNY wrote:
| _> 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 implementation tends towards
| Hard Work and design tends towards Difficult Problems, this habit
| provides a pleasant balance of the two._
|
| That's a great idea!
|
| In my case, I often have multiple projects going, but it is
| generally one "Still under development, and as-yet unreleased,"
| and one or more that are in "maintenance mode."
|
| I've been working on a fairly ambitious iOS app (about 40
| screens, and two backends -that I wrote, and two other backends
| that someone else wrote), for the last couple of years. It isn't
| yet in the final phase, but we can see it from here.
|
| I have a number of apps, actively on the App Store, that I keep
| up to date, and a whole gaggle of SPM modules. I keep all of them
| up to date.
|
| Keeps me busy.
| anonymouse008 wrote:
| Everything you open source has been top notch - I can't wait to
| see what your 'ambitious' project becomes. (In quotes for your
| ambitious is not a mere mortal's ;)
| [deleted]
___________________________________________________________________
(page generated 2022-06-24 23:01 UTC)