Understanding Engineers | Hacker News Reader

Understanding Engineers

fishbowl.pastiche.org

62 pointsadamc9 comments

So there is no necessary relation between a task being trivial, and how long it takes.

I wish more non-engineers could grasp this. It's so annoying when people say, "It's not done yet? But you said it would be a trivial feature to add!" I am then forced to explain all that means is I know how to add it and can visualize the general diagram in my head, but since I am not regurgitating the precise implementation from memory it isn't merely a matter of rote data entry.

This may be a problem caused partially by us, too; I don't care about implementation time because the implementation is the trivial part; it'll be done whenever it's done and I'm not really bothered by that since the problem itself is already solved. Hell, most of the time I don't even have an interest in fully implementing a solution to a problem I've already mentally solved.

I guess I should note this doesn't apply much for me at the moment seeing as how I co-own a company, but it's an annoyance when it comes to dealing with clients.

If you use a word in a way that most people don't, how can you be surprised when they misunderstand you?

I use "straightforward" to describe trivial problems, when I can see the implementation path clearly. "Trivial" implies easy and quick to most people. It's not hard for them to grasp, you just have to communicate more clearly.

Reminds me of Richard Feynman. "mathematicians designate any theorem as "trivial" once a proof has been obtained--no matter how difficult the theorem was to prove in the first place. There are therefore exactly two types of true mathematical propositions: trivial ones, and those which have not yet been proven. "

http://mathworld.wolfram.com/Trivial.html

There's trivial to implement, then there's trivial to implement in our product without breaking everything else.

Also, they missed a category: Stupid. As in: I could do that, but it would be Stupid.

My wife is annoyed by my reluctance to speak in absolute terms. Expressing an estimate of likelihood seems much more precise to me than rounding a probability to "always" or "never."

Just integrate over longer periods of time: "yes dear, that always happens -- just so long as we live forever." ;-)

I mitigate this issue by gambling with myself. I make my best estimate and if it is close enough to never or always I use those words. I benefit from this because more often than not if I'm wrong it's because my mental estimating model is wrong -- not because I got unlucky.

My wife's pretty forgiving, so I don't have much to lose by being wrong or getting called on things, but that might not be a good course of action for everyone. :)

Title is incomplete. It's "Understanding Engineers: Feasibility."

I do like how he framed out the difficulty of problems into categories.

Engineers are tuned to think in terms of RIGHT or WRONG and MBAs think in terms of PRIORITIES.

Reply on news.ycombinator.com