It's better to do it _right_ than to do it _right now_


This discussion, started by Rob Pike, is an interesting read:

I realize everyone wants to get their hands on the fun of the new language feature, and is looking forward to fixing some of the issues in the core libraries that will be less clumsy once it arrives, but I strongly believe it is best to take it slow for now. Use, learn, study, and move cautiously.

Dijkstra reminds us (in an essay aptly called The Humble Programmer):

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility.

In other words, however smart and capable one or two individual Go programmers might be, they can’t necessarily anticipate what kind of programs a million Gophers will want to write, or how they’ll write them. Even the beautiful, pragmatic designs of the standard library are occasionally found to be wanting in some minor respect. I think Dijkstra would have approved of Go, because a kind of humility is built into it. We all need reminding of the value of humility once in a while (he said, humbly referencing his own blog post).

This approach reminds of some thoughts from Evan Czaplicki, the author of Elm.

  1. Be kind.
  2. Learn from everyone.
  3. Collaboration requires communication.
  4. Not every problem should be solved with code.
  5. Communication is contribution.
  6. Understand the problem.
  7. Explore all possible solutions.
  8. Pick one.
  9. Simplicity is not just for beginners.
  10. It’s better to do it right than to do it right now.
  11. It’s not done until the docs are great.
  12. Take responsibility for user experiences.
  13. Make impossible states impossible.
  14. There are worse things than being explicit…

These values are why I use Go and Elm in the Simple IoT project – at least for now :slight_smile:

1 Like

I completely agree with Rob here. Go’s compatibility promise is a strong one, so it doesn’t make sense to rush things in the standard library. Good stuff. I’m really excited for 1.18!

Yes, Go’s stdlib has been a joy to use!

I’ve thought about this a bit more – perhaps this is not a universal rule – on the other side of the coin, you have the MVP philosophy that focuses on getting stuff out, learning, and iterating. So perhaps its important to use the right approach at the right time (kind of like the right tool for the job …) – changes that are in core libraries, data structures, or APIs that are far reaching need to be designed and changed carefully. Features in an unreleased product is where the MVP approach is more appropriate and should be perhaps be implemented early and released often. In released projects, a more conservative approach may be needed as whatever you release, you might have to live with forever. Open source languages, like Go and Elm, are at the far end of the spectrum where changes are far reaching and features need to be considered very carefully.

This “right” theme is what defines successful architects/technologists:

  • right technology at the right time
  • right approach and methodology for the team/project phase
  • right tools for the job

One size does not fit all!