In a blog post from Dave Cheney, open source contributor to golang, he writes that it’s always better to talk about a bug/feature/change then writing code. This avoids hurt feelings (when a change isn’t accepted) and ensures the change lands the first time.
Generally, pull requests are the wrong place to have a lengthy discussion. Dave recommends starting with a GitHub issue or design doc if it’s more complicated. Communication early prevents misunderstandings and leads to a smoother process for everyone.
Links to this note
-
Why Product Engineering Always Feels Kind of Wrong
Something I’ve noticed about building products over the years is that it always feels like I’m doing it wrong. At the same time, it’s a clue about what’s really going on and what to do about it.
-
As mentioned in The Mythical Man Month, good system design (user friendly) requires a small (ideally singular) team of architects, separated from implementation, that decide what goes into the system and what stays out. This avoids rogue ideas making it in that muddy the overall product.
-
When building systems that require monitoring and alerting, a false alarm should be treated as a bug. If it’s not resolved quickly, it diminishes the usefulness of the alerts and trains responders to ignore it. When alerts are ignored, the potential for an actual incident increases along with the severity due to time to detection.