Tea Leaves - Issue 1

Welcome

Welcome to this first issue of Tea Leaves, the companion newsletter to Gaiwan's Tea Garden!

Whether you have been following all things Gaiwan and Lambda Island for years now, or whether you are new here, we are glad to have you. It is our hope that you come away from reading each issue of this newsletter more "in the know" and possibly even a little bit entertained. So, first things first: what is the Tea Garden?

Gaiwan's Tea Garden

For some time now, all of us at Gaiwan have been sharing with each other the stories of the challenges we face, documenting our solutions, and building up a "stack" of libraries and tools that help us get our work done. So far we've only been sharing this information internally, which seems like a waste, but we were lacking a good way to organize everything in a way that we could present it to the larger community. That's when we realized that many of the things that we have learned and written down started looking like Design Patterns. Furthermore, we realized that the way we considered, gathered, and implemented these Design Patterns in our work, formed a sort of pattern on its own. This is the fractal nature of Design Patterns.

Thus, the Tea Garden was born. The idea is relatively simple. It's not quite a wiki, and not exactly a blog, but we will be periodically adding new patterns and editing or pruning back the patterns that were published before. Eventually, it is our goal to grow a friendly and useful garden of knowledge, something you can come and enjoy if you have a spare moment to learn a new concept, or pluck a few useful morsels from the next time you are starting a new project.

If you would like to keep up with the goings on inside our Tea Garden, we will also be publishing Tea Leaves whenever there is something of note to highlight. We will let you know about interesting new patterns that have appeared, or alert you as to existing patterns that have seen significant edits. We may also share an occasional story or extra tidbit that doesn't quite fit in the garden, but we still feel is worth sharing...loose leaves, if you will.

You can also join us anytime in our channel on the Clojurians Slack. We welcome constructive feedback, suggested edits, new topics that you'd like to see us cover, or just any random pattern-related chat.

What's new in the Garden

With this, the inaugural issue of Tea Leaves, we have three new patterns to share:

• The Pattern of Patterns - This first pattern summarizes a bit of what a design pattern is in the world of software development, as well as how we organize and think of the patterns that we will be sharing in the Tea Garden
• Working with URIs as Data - A pattern on the smaller side of the scale, but an important one none-the-less, with some helpful suggestions to avoid a category of bugs that we've all been bitten by far too often
• A Development Environment Launcher - There is a tendency for projects to grow in the complexity of what it takes to get started working on them as the underlying project itself becomes more complex; this is a problem, and this pattern has helped us fight against this current

Loose Leaves - Be an Inverse Pilot

Among the chaos and angry shouting of the internet, there are still some quite spots out there where, if you know how to find them, you can observe a group of like-minded individuals conversing and sharing knowledge. One place like that is https://www.airliners.net where you can find actual airline pilots and members of the flight crew and ground support staff talking about what it takes to run one of the safest modes of transportation the world has ever known. If you spend enough time there, you are bound to run across a mantra that pilots live and survive by: "aviate, navigate, communicate".

The idea of this mantra is that, when something goes wrong, a pilot's first job is to make sure the plane stays in the air. Once they are sure there is not an imminent risk of crashing, the next responsibility is to ensure they know where they are and where they are heading (as it is hard to keep a plane that's run out of fuel in the air, and you can't land a plane just anywhere). Finally, only after these first two concerns are taken care of should a pilot worry about communicating with the tower, or other pilots, what is going on. You can actually see how this plays out in the recordings of the famous "miracle on the Hudson", as Captain Sullenberger very obviously puts communicating with the tower at the bottom of his priority list. While this is probably frustrating beyond belief for the air traffic controllers wondering what's happened to him, adhering to the principle of "aviate, navigate, communicate" is what allowed that landing to be a "miracle" and not a "tragedy on the hudson".

The thing is: we're not pilots.

In fact, in the world of software development we're more like "inverse pilots". Our mantra should be: "communicate, navigate, aviate codeiate". Unlike a pilot, who risks their own life and the lives of their passengers if they fail to "aviate", most software projects will not result in death if that one bug is not fixed right now! In fact, as developers we are surrounded by teams and a broader community that, if we communicate with them first, can likely help us solve problems faster than we can on our own.

That's the difference between a software project and an airplane. The folks in the tower, as helpful as they might try to be, cannot teleport to a plane in distress to help keep it in the air, but a software project in trouble can easily bring on more people to help out (especially if that project has a good development environment launcher). Obviously there are limits to this (see: "The Mythical Man Month"), but the rule stands. As developers, we should first communicate what it is we are working on or struggling with. Once we have communicated with our team, only then should we look around and make sure we are even coding in the right direction (as often the easiest way to solve a hard problem is to simply work around it). Finally, only after these first two concerns are taken care of, should we code.