Listen to Scotty

What people said

Zenst · 2022-07 · Joke / meme

Which reminds me of the old engineering trick of saying it will take longer than it does as managing expectations is an art best explained by Scotty - [VIDEO]

Read the original HN comment ↗

dvtrn · 2020-05 · Joke / meme

My old man spent 30 years working as a mechanical engineer for General Electric in their gas turbine division and used to bring home these sorts of tales similar this with people who reported to him, which subsequently informed him on how he needed to communicate to the manager he reported to on when to expect deliverables. Most memorable from this was watching his reaction while he and I were watching an episode of Star Trek the Next Generation where his exact problem was manifested into reality by his favorite character : [VIDEO] Nonetheless, I may or may not have employed my dad’s and Scotty’s method now that I have a team reporting up to me, each with their own strengths and weaknesses in delivery. Grooming them has been a genuine pleasure, though.

Read the original HN comment ↗

Jach · 2018-07 · Reference

How are you measuring these things? 1. It's one of my dreams to work at a place using prediction markets for internal estimates. Anything else feels worthless and engineers are incentivized into the "quadruple what you're currently thinking" estimate so they more often meet deadlines -- or try to "under-promise, over-deliver" except management rightly catch on to that one immediately. (As an engineer I still want to be a La Forge and work with other La Forges, even if Scotty[0] sometimes has a point; modeling managers as demanding children has some gaping model gaps.) 2. What I've seen is that many delighters aren't that hard, but they're often treated as "polish" that goes into the p3/p4 priority backlogs and maybe might resurface if a customer ever brings up a desire for that to the product management. What delighters have you seen that weren't shipped because they were too hard? Were they actually too hard, or was it just too much to get them done by some release date alongside all the other stuff so they get shoved to the backlog just the same? 3. Are you measuring bug count based on what customers report or internal bug reports? If internal, even if people aren't gaming this directly, it's still easy to get into a bad cycle where reported bugs get ignored and go unfixed which leads to fewer reported bugs. That might be mistaken for higher quality. 4. Is this one measured from surveys? Obviously not all features are directly customer visible so let's take something concre

Read the original HN comment ↗