Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mental Model: Difficult Problems vs. Hard Work

benjamincongdon.me

Post reply on HN
Print view View original

11–20 of 47 posts

Re: Mental Model: Difficult Problems vs. Hard Work

#11

Post by ochoseis »

catchclose8919 wrote: post #2

> 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…

This us why I tend to stay away from front end work. Not particularly difficult, but way too much wiggle room and pixel pushing.

Re: Mental Model: Difficult Problems vs. Hard Work

#12

Post by zasdffaa »

catchclose8919 wrote: post #2

> 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…

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.

Re: Mental Model: Difficult Problems vs. Hard Work

#13

Post by colordrops »

catchclose8919 wrote: post #2

> 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…

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.

Re: Mental Model: Difficult Problems vs. Hard Work

#14

Post by mikkergp »

aprime7 wrote: post #6

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?

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.

Re: Mental Model: Difficult Problems vs. Hard Work

#15

Post by nullspace »

AnimalMuppet wrote: post #7
nullspace wrote: post #5

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…

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, 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.

Re: Mental Model: Difficult Problems vs. Hard Work

#16

Post by jvanderbot »

catchclose8919 wrote: post #2

> 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.

Re: Mental Model: Difficult Problems vs. Hard Work

#17

Post by zackmorris »

catchclose8919 wrote: post #2

> 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…

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.

Re: Mental Model: Difficult Problems vs. Hard Work

#18

Post by mynameisash »

catchclose8919 wrote: post #2

> 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…

>> 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.

Re: Mental Model: Difficult Problems vs. Hard Work

#19

Post by molsongolden »

aprime7 wrote: post #6

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?

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.

Re: Mental Model: Difficult Problems vs. Hard Work

#20

Post by ChrisMarshallNY »

> 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.

Post reply on HN