That’s an excellent framing. We have a tendency to refer to things as ‘just work’ or ‘a simple matter of coding’ to (somewhat sarcastically) describe things where we know how to solve the problem, we’re 100% sure it’s possible, it’s just a potentially unbounded amount of engineering time to do it. I think I sometimes fall into the trap that the article describes of valuing the ‘hard work’ things less than the ‘difficult problems’ bit. We often talk about ‘glue work’, which is often stuff that anyone on the team could do, but is essential to make the whole team productive, as one of the most highly valued activities for folks to do. I often think of this like toilet cleaning: anyone can do it, very few people want to do it, but everyone is (or, at least, should be) grateful to the folks that do it. I wonder how glue work and hard work compare in perceptions elsewhere.
I’d say that glue work (as essential as it is) is critically different from hard work (when they are different) in that if only glue work gets done the team still fails. If the hard work gets done the team succeeds, though they may be miserable in doing so.
Like, glue work is called glue work because it attaches other things of substance together; those other things are usually hard work. You shouldn’t build something purely out of JB Weld.
To a non-native english speaker, it is a bit perplexing to build subtle semantic distinctions on two words (“hard” vs. “difficult”) that, as far as I can tell, mean basically the same thing. I understand that “hard work” comes as a unit that evokes a specific meaning beyond just “hard”, but still: I’m not fond of the choice of name for those concepts.
I regularly use “difficulty in width” and “difficulty in depth” for the same notion. “width” is related to the cheer size of the solution we have to build (for example: reimplementing many features of an existing system). “depth” is related to the mental difficulty of each independent sub-task. These are not exclusive, a task can be difficult both in width and in depth.
“hard” generally pertains to a physical characteristic of something. It’s “hard work” because it requires force, strength, or otherwise extended labors. Just like a rock is hard, and so it would require physical impact in order to break it.
In contrast, “difficult” is used to characterize mental processes. It’s “difficult problems” because of complexity, skill requirements, or subject to many constraints.
It’s not really an English thing. Lots of writers in lots of languages will take synonyms, make up a difference, and then explain why one is better than the other. Heidegger basically always does this. Many world languages will have different influences, so in English, we can contrast an Anglo-Saxon term with a French term, while the Japanese contrast a Chinese derived term with a native term, and the Germans contrast native vs Latin or Greek, etc. It’s just a freestanding rhetorical effect, and it’s not necessarily any easier for a native speaker to grasp.
To add to what others have said, the difference between terms really isn’t in hard/difficult, it’s between work and problems, where work implies a more defined (“solved”) task than a problem.
I’m not a native English speaker so could be wrong ;)
I’d be remiss if I didn’t mention and reinforce that, from a business standpoint, difficult problems are several orders of magnitude less valuable than hard work (though their solution oftentimes means less hard work exists).
I think this is typically true right up until the point where it’s extremely not true. It’s not so much that one is more important than the other, as that they’re important at different times and hard work is more often the important one.
Most of the time, you don’t have important difficult problems to solve, but every now and then you run into a difficult problem which you need to solve in order to succeed and no amount of hard work will substitute for it.
That’s an excellent framing. We have a tendency to refer to things as ‘just work’ or ‘a simple matter of coding’ to (somewhat sarcastically) describe things where we know how to solve the problem, we’re 100% sure it’s possible, it’s just a potentially unbounded amount of engineering time to do it. I think I sometimes fall into the trap that the article describes of valuing the ‘hard work’ things less than the ‘difficult problems’ bit. We often talk about ‘glue work’, which is often stuff that anyone on the team could do, but is essential to make the whole team productive, as one of the most highly valued activities for folks to do. I often think of this like toilet cleaning: anyone can do it, very few people want to do it, but everyone is (or, at least, should be) grateful to the folks that do it. I wonder how glue work and hard work compare in perceptions elsewhere.
I’d say that glue work (as essential as it is) is critically different from hard work (when they are different) in that if only glue work gets done the team still fails. If the hard work gets done the team succeeds, though they may be miserable in doing so.
Like, glue work is called glue work because it attaches other things of substance together; those other things are usually hard work. You shouldn’t build something purely out of JB Weld.
To a non-native english speaker, it is a bit perplexing to build subtle semantic distinctions on two words (“hard” vs. “difficult”) that, as far as I can tell, mean basically the same thing. I understand that “hard work” comes as a unit that evokes a specific meaning beyond just “hard”, but still: I’m not fond of the choice of name for those concepts.
I regularly use “difficulty in width” and “difficulty in depth” for the same notion. “width” is related to the cheer size of the solution we have to build (for example: reimplementing many features of an existing system). “depth” is related to the mental difficulty of each independent sub-task. These are not exclusive, a task can be difficult both in width and in depth.
Some connotations that may help you:
“hard” generally pertains to a physical characteristic of something. It’s “hard work” because it requires force, strength, or otherwise extended labors. Just like a rock is hard, and so it would require physical impact in order to break it.
In contrast, “difficult” is used to characterize mental processes. It’s “difficult problems” because of complexity, skill requirements, or subject to many constraints.
It’s not really an English thing. Lots of writers in lots of languages will take synonyms, make up a difference, and then explain why one is better than the other. Heidegger basically always does this. Many world languages will have different influences, so in English, we can contrast an Anglo-Saxon term with a French term, while the Japanese contrast a Chinese derived term with a native term, and the Germans contrast native vs Latin or Greek, etc. It’s just a freestanding rhetorical effect, and it’s not necessarily any easier for a native speaker to grasp.
To add to what others have said, the difference between terms really isn’t in hard/difficult, it’s between work and problems, where work implies a more defined (“solved”) task than a problem.
I’m not a native English speaker so could be wrong ;)
Reminds me of: https://www.goodreads.com/quotes/6641527-sometimes-magic-is-just-someone-spending-more-time-on-something
I’d be remiss if I didn’t mention and reinforce that, from a business standpoint, difficult problems are several orders of magnitude less valuable than hard work (though their solution oftentimes means less hard work exists).
Engineers forget this at their peril.
I think this is typically true right up until the point where it’s extremely not true. It’s not so much that one is more important than the other, as that they’re important at different times and hard work is more often the important one. Most of the time, you don’t have important difficult problems to solve, but every now and then you run into a difficult problem which you need to solve in order to succeed and no amount of hard work will substitute for it.
Author here, glad you found this post interesting!