What I Did (and Learned) On My Coding Vacation

For THWACKcamp 2018, I had a chance to return to a task/skill I haven't really done much of in a while: programming. That may be a surprise for some people, so let me explain. I have done a lot in my career, from desktop support to systems administration to network engineering. And there's been a decent amount of scripting involved. But I'm not "A Programmer." As anyone will tell you, a batch file or shell script can be sophisticated and even elegant, but it's still not the same as "real" programming. What I usually say is that "nobody ever wept with joy at the beauty of my code. In fact, the most complimentary thing anyone's said is 'well, uh, it ran. I guess'." And I'm okay with that. I never aspired to be a "real" programmer. The thought of spending each and every day coding does not excite me. Again, that's okay, and if coding is your jam, that's okay too. I'm not hating on anyone. All of that said, though, there's something deeply satisfying when I—an avowed script kiddie—can bang out a few lines in something more sophisticated than BaSH and get something to run. Better yet, something that runs with consistent results. Best of all, something that does something that I don't have to do any more. So I do understand the thrill and attraction of programming. I just don't want to do it all the time. As we prepared for THWACKcamp^™ 2018, I had a chance to flex those rusty programming muscles for the first time in a while. Kevin Sparenberg offered me a chance to join him and Zack Mutchler for the session "There's an API For That," where we dug into the ways that the Orion^® application programming interface (API) could be used to bend SolarWinds solutions to your will, to help you achieve your greatest monitoring automation desires. In terms of raw programming experience, Kevin and Zack are lightyears ahead of me, which made the entire experience both awesome (because I got to learn) and daunting (because I didn't want to look like a complete noob). But it was also a great chance for me to mentally track the experience so I could tell you about it here. It took me a while to figure out what I wanted my example to DO. Honestly, this is a weird problem to have since my regular everyday problems "volunteer" themselves to be solved all the time. Here I had to go looking for a problem that was understandable to a broad audience, simple enough that I could present a solution in about 10 minutes, and was something that *I* could solve with programming. But after a few days, I finally hit on something that seemed plausible. My only challenge was that, due to travel, writing commitments, and a week-long holiday, “after a few days" put me about 4 days before our record date. So I had to work fast. I decided to do my example in Perl. As I explained in the session, I did it partly out of sheer stubborn-ness, and partly because I wanted to show that ANY language (even one that is, admittedly, NOT the best choice) will work with the Orion API. But I had one more reason: It's the programming language I know best, and like I said, I didn't have a ton of time. Coming back to programming felt like returning to a foreign country where I'd spent a summer in my teens. Back then, I was fluent. I wasn't native, but I could get around, make myself understood, and not say embarrassing things in the grocery store. But years later, all I have left are vague recollections and muscle memory. Like a spoken language, in every new line of code I encountered a, "Doesn't it work like that? Wait... let me look it up... Oh that's right! THIS is how I used to do it!" moment. The curve to get back to my old skill level was steep (because I was remembering and re-familiarizing, not re-learning), but even so, it took time. As I worked, I adopted a habit that I use in my writing, something I learned from a 2014 interview with Joss Whedon. In discussing how he gets things done, Whedon advises writing the fun part first, the part where your heart is. Then when you have to buckle down and do the hard work, the "dog's body" work, as he puts it, you're motivated because you have all this amazing stuff that's just sitting there waiting for you to connect the dots. So I wrote the fun bits of the script first. I'm not going to tell you which parts for me were fun because sometimes it was just, "Oh, I get to use this command that has a good memory for me," and other times it's, "I love this function because it's so efficient." (I have an almost unwholesome love for the "chomp();" command for that exact reason.) What I didn't do—what, in hindsight, I SHOULD have done—was write from the center. I should have gotten the core function down first, and worked outward from there. So much about the core determines what happens at the edge. In a way, that's the same thing Joss was teaching. He said "fun part" but he really meant "the meaty, important, essential" part. I went for actual fun. I should have looked for meat (I believe my fellow Head Geek^™ Thomas LaRock, a.k.a. "Bacon Man," would concur). Because all of a sudden, I got to the most important line—the one that did all the heavy lifting. It was also the piece of code that I had ZERO experience with previously. Unlike the earlier work where I was re-familiarizing myself with what I already knew, THIS was learning. This was the moment I had to go and figure it all out from scratch. And at this point, it was 8 p.m. the night before the recording. That's right, I'm baring my soul to you now. The guy you see on camera couldn't get that code running just 12 hours earlier. But you know what, that's not dirty laundry. That's business as usual for most of us in IT. It's not running, and we put in the time and the sweat (and maybe a few tears are shed, and maybe a little scotch is imbibed), and we get it working. I worked the problem until I literally couldn't see straight. And then I let it go. That's a skill that has taken me years to accept. That sometimes you have to put it down to solve it. I got a few hours’ sleep and came into work the next day, and found the best programmer I could find. Luckily, the best person I could find was also the person who more or less invented the Orion API—Tim Danner. I found him at his desk, coffee already installed, and with a spare five minutes. Let me take a momentary aside and share some important lessons I've picked up in my career.

1. Being able to ask for help may be one of the most important skills a programmer can learn.
2. Knowing WHEN to ask—meaning not so fast that you clearly haven't even tried to solve the problem yourself, but not so long that you are completely underwater—is a close second.
3. Following right on the heels of one and two is knowing WHO to ask.

I explained my issue, I showed Tim both where I was stuck and what resources (documentation, etc.) I had gone to. Tim immediately saw that I was stuck from a combination of lack of experience doing REST calls in Perl (which should surprise nobody because Perl is not exactly the go-to language for this kind of thing) and documentation. He was able to fix both of those, and my code, before the coffee on his desk had cooled off. I headed down to the studio with a spring in my step, with a working script on my laptop, and with my feelings about programming both confirmed and renewed. It's a fun place to visit, but I wouldn't want to live there. For those who are curious, you can find my post detailing the ACTUAL script here. The SolarWinds trademarks, service marks, and logos are the exclusive property of SolarWinds Worldwide, LLC or its affiliates. All other trademarks are the property of their respective owners.