Hello again, stranger! Today, I’m back with an update on the first project I ever wrote about here. The app was initially created to streamline a small bit of my daily work, but alas, its home remained on a third party site, rather than having a cosy, Devops managed spot within my current company’s code base.
I set out to change that this summer.
And what an adventure it turned out to be! As an operations-centric employee, my formal exposure to the lands of Devops was limited to… well, none. I had heard the names of our internal and third party tools in passing, but that was the extent of my knowledge. I determined to change that, but I wasn’t sure where to start. Naively, I figured I’d just dive into our documentation.
In a revelation that will surprise no one, it wasn’t as easy as that. Philosophies on documentation are many and varied. One I recently learned to admire and emulate is TAGRI – short for They Ain’t Gonna Read It. In short, the intent is to write useful and readable documentation, rather than necessarily thorough and extensive documentation. After all, it’s meant to be read, right? And most probably it’s being written for the benefit and accessibility of the reader.
For the majority of cases, I see the strong value in this approach. If a developer needs to deploy a new service and gets stuck along the way, why force them to skim through pages and pages of how-tos and step-by-steps? Why not simply create a short and easy-to-find page on their specific issue? Awesome. Except when a brand newbie like me wades into the endlessly interconnected net of pages, all of which seem to hint at a unified and easy approach that remains tantalizingly out of reach. Where do I even start? For third-party tools, I can put my Google-Fu to work on unfamiliar terminology, but what about internally built infrastructure?
After a few weeks of increasingly discouraged sifting through the same stack of what was clearly a very helpful set of documentation to those who have had the benefit of an introduction to the tools and their use, I wasn’t much closer to an internal deploy than when I started. That’s when I realized the key piece I had missed. What was stopping me from joining the ranks of the aforementioned users who have had the benefit of an introduction? One wouldn’t have had nearly the same success pre-introduction as post- in Victorian England, and neither was I. But that didn’t mean I had to remain so!
In a serendipitous turn of events, my company happened to be rolling out a mentorship program right around the time I came to this conclusion. I’ll skip past the details of mentor matching and meeting and right to the immeasurable value of my mentor’s contribution to my problem. By virtue of having worked with our Devops ecosystem in their core role, my mentor was able to give me the high-level knowledge I needed to get started, as well as directing my attention to the appropriate and harder to document areas of our deployment tools (such as where on the blocks of console logs I should look to see why my build might have failed.)
In the end, my mentor helped me accomplish in a mere couple of hours the feat that I had been stuck on for weeks of documentation wading and reading. I’ve always been a believer in trying to help oneself first before asking others to help you – otherwise, how might you learn to find the answers to a similar but non-identical issue in the future? An expert’s time is valuable, no matter what they’re an expert on. The adventure with my internal deploy showed me the other side of this coin.
I learned that there’s a place, a time, and likely a time-limit on self-directed searching. When returns have diminished beyond usefulness, it may be time to seek out a mentor. I was fortunate to have a formal avenue to do so, and I highly encourage other businesses to streamline such pairings too, but it doesn’t have to be quite so formal – sometimes just posting on a Slack channel for help will get you there, and you don’t have to feel like you’re wasting others’ valuable time to do it. After all, your time is valuable, too! My next aspiration is to be as helpful to a newbie in a field I’m confident about as my mentor was to me.



