[catchclose8919]

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

[zackmorris]

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.

[bcrosby95]

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.

[zackmorris]

Hahaha that's amazing, also I didn't know there were other spellings. I was thinking about yacc as I wrote yakk but I guess it's yak. Funny how associations work. And don't forget bike shedding and cargo culting!

[jvanderbot]

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.

[ximm]

I think this comment gets to much negativity. Yes, this is often not a good approach. But it can be one tool in your toolbox that can get you unstuck when nothing else seems to work.

[catchclose8919]

> ambiguity can be solved by random action

This 100%. I've learnt the hard way that the only way to get unstuck at this kind of hellish work is random action - I'm biased to over-analyzing the problem so get stuck because I can't pick an option. A bias towards action, ANY/RANDOM action if you can't decide is what seems to help here best!

[waynesonfire]

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

[tomjakubowski]

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.

[jvanderbot]

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

[warkdarrior]

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.

[mynameisash]

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

[catchclose8919]

You're lucky. You'll see it when you step in it.

"Easy but ambigous" sounds paradoxical, maybe the terms are not correct, but it is a very very different thing totally different than the other two.

Maybe there's a better way to explain this though: there's work that would be easy if it was clarified but it's not, and at the same time you can't just think hard and discuss and clarify and make it clear befor starting to work on it, so that you can set yourself to doing it, either in robot mode (while thinking of other things), or in regular problems solving mode; you just can't, that fog and ambiguity and unclarity is just "sticky", stays there until the problem is solved and sometimes even after, making it hard to even be sure that you've really solved it; there's no reward in tackling the hard problem of fully clarifying things because you can't succeed at it, but paradoxically there's no frustration either because you don't know it's a doable tasks either; you just have to muddle through, at every step of the way doubting yourself that you've chosen the right path since there's no clear way to measure stuff and to quantify your step; and you constantly have to interrupt yourself, going in "fishing trips" for information that is stuck in god knows whos brain because it was never documented, and never getting sure enough of what you discover to have trust that by documenting it yourself you make someone's life easier; and when you get to a "solution" you still keep the bitter taste in your mouth becase the systems have no adecquate testing tools and you can never be truly sure your solution will really 100% work; and if it seems to work for know, it's never sure it will keep working in the future, or that what it does will satisfy its operators...

To take your hiking analogy: it's basically a one-foot-after-another multi-day hike, but there's fog (and fog is a meteoreological phenomenon so you can't make go away), you're not really sure which of the destinations is the right one (or if many could qualify as adequate destinations), and there's a couple landmines hidden around, with very low probability of triggering them (1-5%) but yu still know they're there, and you have no water with you and you know that the water you'll find is 90% likely to give you disentery, and you might need to ask people for directions but it's hard to know whether they'll be right.

> I frequently tell my manager/team that we have two kinds of problems

...when enough managers/leads/architects/etc. mess things up in a row, you do end up with problems of the third kind :)

[zasdffaa]

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]

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.

[catchclose8919]

Yes, this getting clarifications one drop at a time, or being unable to clarify things before doing them.

The KILLER extra topping for me is when you lack any kind of quick-iterative-feedback-loop too. Eg. maybe it's cloud infra done in a braindead way and any way to debug is to do a tens-of-minute-length rerun/redeploy etc.

I'm OK working incrementaly, and even with incremental ambiguity, but I need a FAST feedback loop to iterate.

[ochoseis]

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

[colordrops]

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.

[catchclose8919]

> the vast surface area of the project makes it hard to hold all of it in my head at once

...yep, in general one of the root causes of having to do this kind of nasty work was someone (maybe even your past self) having failed badly at decoupling a distributed system ...add some "documenting it was supposed to be milestone 3" but then priorities got restructured and it never happened, then people left and others came, and voila!