
Why the Usage of Instrumentation Within Monitoring Tools Should be Implemented in Your Next Web Project
Back-EndWhen designing a web application, a strategy that has often been used is to use a monitoring tool such as Grafana or Datadog. There...
It’s late Friday afternoon, I’m angry at this problem I’ve been working on for an hour (or more), but I’m stuck. The sun is out and a cool breeze is blowing softly outside and I want to be riding my bicycle through the streets of Atlanta at full speed! Right now, I can think of nothing more than how much I hate this bug. I’m stumped.
What do I do?
At Highgroove, we’re experts at this Rails game: we have tons of experience building applications and fixing bugs, figuring out problems and crafting simple yet elegant solutions. Years of practice has fitted us with an intricate and intimate understanding of the tools we use, the methods we employ, and the goals we often aim for and achieve. Even with of all of this knowledge and experience, we don’t always have the answer. But what makes us true experts is knowing how to find it even when we don’t.
A big part of being an expert is knowing where to look when we don’t know the answer immediately. Our checklist, of sorts, often looks like:
Refer to the relevant documentation
Perform a quick search (Google or Bing, Stack Overflow, mailing lists, wikis, etc)
Ask our colleagues
Perform a more thorough search
Ask the internet (Twitter, IRC, mailing lists, etc)
Most of the time we may just need someone’s directing words to point us in the right direction. Often when we go looking for this direction, our colleague or friend has actually solved the problem recently and will know the answer. It’s important to involve your team (those that would know) soon but respect their time and don’t pester. Do your due diligence and be quick about it.
If we get to the point where we have to ask the internet, that means it’s time to get some coffee, free our mind from the problem for a short amount of time, and let the responses come in. Find something else to work on, go for a walk, stretch, take a quick nap, or call a relative. Once you’re back working on the problem, first think about your solution and other solutions to your problem. Don’t get too involved with and dedicated to your approach: it’s OK to start over if you recognize that you’ve ventured off into some rabbit hole and need to get back on course.
Before you posit your problem to the internet, make sure you evaluate what you need to know and cut out any distracting details. Break your problem down into the minimum description and context, hopefully something tweetable. Let anyone who thinks they can help ask for more context. And of course be willing to patiently work for your solution: impatience will only lead to shoddy work and won’t solve any problems.
It would be silly to pretend that we know everything, so we embrace the massive amount of information sitting so very close to us and use it as often as possible. In turn, we’re learning and gaining more experience every day.
Back at my desk, I’ve decided I don’t know enough to solve my problem so I ask my colleague who knows where to look and together we solve my issue. Shortly after, we’ve deployed a fix and I’m out the door in minutes. I kick myself for not asking them sooner, but either way I’m out the door and on my bike with the wind in my hair and more experience under my belt. The weekend is always a bit better when I’ve solved my problem quickly, I’ve gained that experience and knowledge, and added another resource to utilize in the future.
When designing a web application, a strategy that has often been used is to use a monitoring tool such as Grafana or Datadog. There...
There are several design patterns used these days in the .NET ecosystem. What are they? What are the benefits and drawbacks of each pattern?...
As a full-stack web developer, I attended SRECon to expand my thinking about the reliability and observability of the services I develop. Here are...