 Sometimes my approach to a technical problem is "do stuff and see if it works" and other times it's "think about the problem for 1 to 3 years before making any moves" and I wish I knew how to articulate when to do which one. Usually the "think for 3 years" thing is what I end up doing when it's a socio-technical feature with a strong possibility of causing harm if I get it wrong 8 comments
 Think about the problem for 3 years, and by the time you come up with a solution, the problem will go away. @darius Absolutely same! It is definitely hard to articulate, but I feel like the clarity of the choice of approach came with experience for me. I work in state government, so I have the little-appreciated luxury of moving very slowly when I need to. I really value that.  @darius I am so often a champion of “you can’t learn if you don’t ship” and “build safety, then experiment constantly” approaches, which really start to fall apart when your product is basically a giant psychometric challenge trial (with no IRB, of course) on the global population. But I still feel like “stop moving because moving might break something” is just as bad when the stakes are high as when they’re not. Constantly wondering how to resolve this tension. If there's a big cost if it goes wrong - wait! If the time has come to get cracking on something, then dive in! |
Gregory's Server
@darius I wish we could spread the "think for 3 years" approach more broadly.