Talk Then Code

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.

Read the blog post

  • Conceptual Integrity

    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.