My key takeaways from the reading are:
– Others may be interpret what we say or want too literally. Following an order is not understanding.
– It’s easy to over-document. The example of nonfunctional requirement is an easy trap to fall into.
– Shared documents is not shared understanding.
– Product teams should ask who will use our product and why will it solve their problem. This helps to avoid building software that no one will use.
– Requirement is often business speak for shut up.
My experience and the article:
– I have always wondered why software teams exclusively document on text when better visual mediums like GIFs, short videos, audio clips exist. Why can’t we embed voice or video in a code editor as easily as we can do so on other platforms (like notion for instance). In my internships, I try to make short video snippets for code walk throughs for the person who will take over my project after me.
– Pareto principle is an important heuristic for me. It states that 80% results or value stem from 20% inputs. This helps me choose high leverage activities over being lost in working without being productive.
– Clarity helps in the order of doing things too. If teams can agree on what will be done first, or when will something we done, or how to get unblocked if a blocker comes, problems can be solved faster.
– Asking who and why are so important for just not products but also interpersonal growth. Asking who do I want to be and why do I think doing X is worth my time helps me to give a narrative to my grit. Otherwise, I am just another hamster running on a wheel.
