There's a classic cocktail party icebreaker related to this: when you ask the usual awkward intro question about what somebody else does, and they tell you "X", reply with "wow, that sounds really hard!". They'll almost certainly tell you "yes!", explain a bit about why it's hard, and now you have a genuine conversation going.
One of my earliest "ah ha" moments in managing software engineers is asking them to do something and the answers tended to be "that's really really hard" or "that's simple". The realization was they were actually telling me "I don't know how to do that" or "I know how to do that". Once someone figured out how to do the really really hard thing it somehow became "simple". Now when someone tells me something is "hard" I can't seem to shake the bias that they just don't know...
Conversely, non-technical business people are very highly likely to tell me some piece of engineering is "easy" or "simple" when they have no background, or knowledge, at all.
I find it helpful to use a range of descriptors. A "simple" task is easy and can be done quickly. A "straightforward" task is easy but may be larger in scope. A "tricky" task needs study to determine where it falls. A "hard" task has known complexity and is just plain hard.
I agree with this. I also like to divide things into "this requires research/invention" and "this does not require research/invention, just work".
Anything requiring invention by definition is not straightforward because its potential timeline may be functionally infinite if it cannot be solved with the tools at hand.
A task like changing all APIs to accept a different set of parameters might take 6 months, but is straightforward.
"Easy" is the one line change that has no side effects, and is uncommon in practice. After all, sometimes it is that one line change, but there are ramifications elsewhere in the system that need to be thought through.
I really like your use of "straightforward" here. Not a word I would have thought to use, but does a great job describing the nuance of something that's well-understood, but may not be quick to do.
Telling you “this is hard” is not usually saying “I don’t know how to do this”, it’s usually “I recognize this and it’s more involved than the thing you think you’re asking for”.
I hope a follow-up moment was realizing that sometimes when an engineer says something is "simple" it's that they don't yet know that they don't know how to do that.
And when an engineer says something is hard, sometimes it's because they've done it before, and it really really sucked and burned months of their life and can we please not talk through the details that still make me cringe?
And occasionally there's that one engineer who describes stuff as "simple" after watching an old Rich Hickey talk.
This hits on a subtlety that I see all the time, which is that simple and hard are not opposites.
Some things are simple, some are complicated or complex. The degree of difficulty is basically orthogonal.
Running a marathon in under 2 hours is incredibly simple. All you have to do is pick a point 26 miles away and run in that direction. But it sure isn't easy.
I think that if a non-technical business person says something is not hard, it's "someone else must be able to do this, it can't be too complicated!" Yes, it could be done, but "easy" doesn't imagine costs (time, money) enough. If I am asked that and find that I can't do it, who will then? Trying to find someone to do the "easy" thing could turn out to be more complicated than judging the complexity level of a task.
This has always been my go to and it works like a charm. I ask “and what do you do?” and follow up whatever they say with “that sounds incredible! Tell me more!”
