Live data from Hacker News

Mental Model: Difficult Problems vs. Hard Work

benjamincongdon.me

31–40 of 47 posts

Re: Mental Model: Difficult Problems vs. Hard Work

#31
post #21

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.

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

Re: Mental Model: Difficult Problems vs. Hard Work

#32

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

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.

Re: Mental Model: Difficult Problems vs. Hard Work

#33

Earlier quoted context omitted.

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.

So can ignorance and it's hard to tell which you're solving with that coin. I wouldn't want to work with you.

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

Re: Mental Model: Difficult Problems vs. Hard Work

#34

Earlier quoted context omitted.

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.

So can ignorance and it's hard to tell which you're solving with that coin. I wouldn't want to work with you.

As long as you don't ship your decision without review, and you're willing to change your mind if it's wrong, what's the problem? Like OP, I often find that people are reluctant to discuss anything that's ambiguous, until someone has made an attempt at implementing it, and presents it to them. Then, suddenly, every ambiguous choice that was decided wrongly (in someone's eye, anyway) in that attempt comes out of the wood work. It's an extraordinarily good way to spark discussions people don't want to have.

"Write one to throw away" is the greatest advice I've heard for our field. You will rarely fully explore the problem space by just talking about it ahead of time.

Re: Mental Model: Difficult Problems vs. Hard Work

#35

Earlier quoted context omitted.

So can ignorance and it's hard to tell which you're solving with that coin. I wouldn't want to work with you.

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

Alternatives are almost never equivalent. If at decision time there is still ambiguity, it means that some criteria that separates the alternatives is not being considered.

You are suggesting to not search for that additional separating criteria and just use a coin flip to decide. Apparently you prefer a coworker that would flip a coin in order to move forward with a decision as soon as possible.

The other poster is saying the flipping a coin is the same as staying ignorant of that additional separating criteria. Apparently he'd prefer a coworker that wouldn't stay ignorant by choosing to flip a coin.

Re: Mental Model: Difficult Problems vs. Hard Work

#36
I was just talking to a friend about a similar mental model. The way I see it a task falls into one of three buckets: easy problems, hard problems, and stupid problems.

Easy problems are "hard work" and hard problems are an exact match for "difficult problems". Stupid problems are just difficult problems that are only being implemented because the business (marketing, sales, C Suite) and development teams suck at communicating.

Re: Mental Model: Difficult Problems vs. Hard Work

#37

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

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 ;)

Thanks!

It will be pretty cool. It has a very narrow demographic, though, and it will be a free app, so I won't be announcing it here. The last thing it needs, is a couple of thousand curious geeks, signing up accounts that they'll never use.

I also will probably not be allowed to publish the source (but it uses quite a few of my SPM modules, and the BAOBAB server -modified, so there is still a fair bit of OSS involved).

Re: Mental Model: Difficult Problems vs. Hard Work

#39
post #21

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.

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…

The tough thing about the problems that are just a long list of ifs is the shape of the data. It’s usually not clear till you’re very deep in the problem what the “right” data structures are. That’s problematic because those are the difficult things to change. I think it’s a very valuable skill to be able to sniff those out early.

Re: Mental Model: Difficult Problems vs. Hard Work

#40

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

I always have to look up yak shaving when I read the term. I find it hilarious that Wikipedia seems to have two definitions for it, which are practically the exact opposite of each other.

So to use this great term to it's fullest extent, I would guess a lot of programmers think they're yak shaving when they're really just yak shaving.

Post reply on HN