Hey everyone,
Recently, @dschaefer2 and I were working on a backward compatibility issue with ToolsVersion decoding in SwiftPM (PR #9828). Because this was a major change affecting how cached versions are decoded, we wanted to be absolutely sure of every aspect. When the fix was ready, Doug told me to wait because the registry tests were missing and we wanted to make sure the entire logic for that area was rock-solid first. It made sense to be cautious since it’s a core part of the toolchain, and we both agreed that filling those testing gaps was the priority to avoid any regressions.
But then the context changed and more and more developers started hitting this bug and getting blocked. Seeing that, Doug immediately shifted priorities. Instead of waiting to build out the perfect test suite first, the absolute priority was to get the fix out immediately. We even had some nightly CI checks failing at the time (I guess its because of an unrelated upstream package mismatch), but since we knew the core commits were solid, he went ahead and merged it anyway. The registry tests would just have to be a fast-follow.
This remind me that sometimes the WHY is more important than the HOW, I originally heard of this concept through Tony Fadell, who was the Lead in the making of the first iPod. As Amit Chaudhary has been quoted in Walter Isaacson’s book about Steve Jobs, that while testing a prototype of the First IPod, Steve argued that it was very bulky, he even stood up and dropped the prototype in a fish tank to prove it. As it sank, tiny air bubbles escaped from the casing showing that it still has space in there. when Fadell and his team explained that they had pushed the limits of miniaturization and it was impossible to make it more thin, they were stuck on HOW they could possibly cut even another millimeter. Jobs told them WHY, as he wanted the iPod to be revolutionary, that he wanted it to be marginally thinner than any Walkman, that he wanted to fit a 1000 songs in everyone’s pocket.
Surely having a perfect mindset of How to fix an issue is fundamental and necessary, but having an understanding of Why we are fixing it : so that many people who use these tools have a good experience, it might a common instance for an engineer to sometimes prioritize user impact over meeting every single internal metric right away, but as a beginner in this huge code base seeing that trade-off made in real-time was like s perspective shift for me.
Thank you @dschaefer2 , @jakepetroules and @owenv for these learning opportunities and always showing trust in my commits :)