Four Key Reasons to Learn Markdown
Back-End Leveling UpWriting documentation is fun—really, really fun. I know some engineers may disagree with me, but as a technical writer, creating quality documentation that will...
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.
Writing documentation is fun—really, really fun. I know some engineers may disagree with me, but as a technical writer, creating quality documentation that will...
Humanity has come a long way in its technological journey. We have reached the cusp of an age in which the concepts we have...
Go 1.18 has finally landed, and with it comes its own flavor of generics. In a previous post, we went over the accepted proposal and dove...