Showing results for 
Search instead for 
Did you mean: 
Create Post

What I Did (and Learned) On My Coding Vacation

Level 17


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.


Being a fairly project oriented person myself, I completely understand about the "use it or lose" aspect, as I've been there several times myself. I tend to "learn" (figure out is probably a better term to use) what I need for job A, then I move on to a different project afterwards, which may not use any tools from the previous. By the time I find a new project that requires a previously used method/tool, I find myself in that "hmm... yeah... that looks familiar... I think this goes there, but I need to look it up again..." area.

Looking forward to your THWACKcamp session the most! (There's an API for That: Introduction to the SolarWinds Orion SDK )

You really had me when you discovered/remembered you really need to write from the core of the program if you want success at the edge.

I find that to be true in my daily network analysis tasks, and ALSO in my musical performance.  I had the good fortune to perform two gigs this past weekend with an excellent Elvis impersonator, and it was great to see and hear someone who'd focused on the core performance:

  • Look the look
  • Walk that walk (swagger, crouch, pose for Kung-Fu moves)
  • Sing well, with great impersonation, great pitch matching, and remembering all the lyrics
  • SMILE! 
  • Pose for pictures with every single person who approaches you.  You've made a great impression on them, made them smile, made them unconsciously react very positively to your act, and they want to show you their appreciation--and boast about meeting "Elvis" and hearing him sing.

In music, the core includes all of the items above, but the performance goes even further.  While a good Elvis impersonator might have loads of "moves" with the pelvis/hips/feet/eyebrows/etc., a good background or solo performer has to play appropriately to the style of the song--and NOT go overboard.  Sometimes playing loads of notes and demonstrating one's technical proficiency is a BAD thing--it doesn't enhance the song, it detracts from it.  Staying true to the original music (e.g.: not playing a latin style pattern on the bass or drums when playing a jazz ballad or rock & roll tune is worse than playing fewer notes and more rests) is critical.  If I weren't talking about music, I'd even say this is "key".

And so it comes all the way around to programming.  You may remember seeing kids, or even yourself, tweaking Windows to use giant or weird fonts, to use cursor/pointer trails or pointer fingers instead of arrows, or even writing HTML with loads of animations that simply consume users' bandwidth and processor or memory resources without improving performance of your web page--in fact, you've probably decreased its performance.

The core of the need must always remain your focus.  Whether it's making people smile and enjoy old music and gaudy jump suits, or having a web page that loads quickly and works well, or writing shell scripts or full-blown programs that do the job elegantly and efficiently, focusing on that core is what can help you trim away the unnecessary bits and make a better product.


Level 16

"Use it or lose it" also applies to I wrote it 10 years ago and totally forgot about it and how it works.

Level 13

Thanks for the honesty adatole​.  I'm sure it resonates on so many levels for a lot of folks, I know it does me.

One of the things that I've always found somewhat humorous/ironic about our profession is we almost never have the answer to a problem ready made.  So many of the folks I've helped over the years (end users I mean) think we're brilliant and have this all down cold when in fact we're improvising pretty much all the time and have to take by faith that we'll get yet another revelation/solution after hammering on it a while.

I also can relate to going to bed with the problem still unsolved and a deadline looming.

Level 13

Oh, and BTW - really looking forward to the session on the API.  Sounds interesting.


Level 12

You don't know how much I relate to this adatole​, not a "real programmer" either, but there really is a certain wonder and bliss every time I get to make a few lines of code to work for Solarwinds and other tools. Kudos to you for revisiting that "place" while being a busy head geek for us thwackies.

Looking forward to your Thwack session with Kevin and Zack as well!

Level 14

I appreciate the honest insight here!  Thanks for the write up. 

Level 20

You chose right with tdanneradatole​!!!  I think instead of perl I would have chosen python... but that's just me Leon.  Ever since getting my CIS degree I always felt python was really pretty handy for network related things.

About the Author
In my sordid career, I have been an actor, bug exterminator and wild-animal remover (nothing crazy like pumas or wildebeasts. Just skunks and raccoons.), electrician, carpenter, stage-combat instructor, American Sign Language interpreter, and Sunday school teacher. Oh, and I work with computers. Since 1989 (when you got a free copy of Windows 286 on twelve 5¼” floppies when you bought a copy of Excel 1.0) I have worked as a classroom instructor, courseware designer, desktop support tech, server support engineer, and software distribution expert. Then about 14 years ago I got involved with systems monitoring. I've worked with a wide range of tools: Tivoli, Nagios, Patrol, ZenOss, OpenView, SiteScope, and of course SolarWinds. I've designed solutions for companies that were extremely modest (~10 systems) to those that were mind-bogglingly large (250,000 systems in 5,000 locations). During that time, I've had to chance to learn about monitoring all types of systems – routers, switches, load-balancers, and SAN fabric as well as windows, linux, and unix servers running on physical and virtual platforms.