4 ms·
My approach to that has always been to make sure I'm calling my assumptions with a possible option, usually that's either the use cases we care about or the sca
by _heimdall 2y ago
My approach to that has always been to make sure I'm calling my assumptions with a possible option, usually that's either the use cases we care about or the scaling/infrastructure concerns.
I learned pretty early on that its really easy for that context to be lost and that miscommunication go missed. Its so much easier to catch miscommunication early when a few extra seconds or minutes are spent calling out the context and assumptions that make one option best.
- hakunin 2y agoThis is good sometimes, other times it risks losing the audience. Extra info works better when they're ready (i.e. asked for it). This is why it's such a difficult balancing act. You don't want to preemptively answer questions that people didn't realize they should ask yet.
- Atotalnoob 2y agoI usually have my assumptions written, so I can flip to them quickly if there is any confusion
- _heimdall 2y agoFor sure, I was mainly thinking about later stage discussions where decisions like tech stack, architecture, or infrastructure should really be made. Early on its often all about use cases and users you're trying to reach. If microservices versus monoliths becomes much of a debate that early engineering is probably getting too far ahead of the product IMO.