I’ve often heard statements like, “Why would I need to create internal documentation? The code tells you everything you need to know.” when pushing better documentation practices inside of a group I’m working with. It’s true that the code tells us what it’s doing but, like the earlier statement, it doesn’t tell you why the code is doing what it does and context is very important. Without understanding the reasoning behind past decisions, we risk similar mistakes similar to those we’ve made in the past.

The health endpoint is a vital, yet often overlooked piece of a service. It is usually seen as a simple endpoint that doesn’t provide much value to the overall operation of a service. But, health endpoints can be expanded upon and provide valuable information to the user in an easy to read or machine friendly manner. Kubernetes environment extended health checking for many people by introducing multiple health checks to the world for services.

There are times when we need to do the same thing, over many different pieces of informatin but the action is scary. Scary actions include doing something like deleting a set of resources. We’d want to make sure that we are doing what we need to while trying to do it as safely as possible. So, in our example let’s say that we have a tool that will creates a new Kubernetes namespace along with a set of resources.

Custom tooling is very helpful in any software engineering group. Making the lives of others inside of your organization easier by automating common and shared problems can help everyone get more work done. But, providing these tools to our internal users is not always easy. Especially when a we fix bugs or add new features, internal users might not know that there is a new version available to download. The Go programming language allows us to easily build a cross-platform binary that can be installed by users without requiring addtional software such as making sure the correct runtime or dependencies are installed.