Category Archives: philosophy

Moments

We’re told to visualize success. And when we do – when we imagine ourselves winning, it’s in a moment.

But there’s another moment we should be envisioning – the moment before the moment. The one that comes before the winning move, before the piece of code that pulls it all together, before the report is handed in to smiles and nods and thumbs up.

And there’s a moment before that moment, too.

If you plan on winning today, you might want to spare some time to imagine for a moment what it looks like in those moments before the moment where you win.

Because that’s probably where the winning actually happens.

Lose, Survive, or Win?

My teenage son has had a rough patch lately – like many teens. Getting up for school requires Herculean commitment. Being civil, let alone kind, is almost impossible.

No surprises there, it’s all part of the journey.

This morning as I drove him to school, I asked him if he was going to let the morning’s bad start ruin the rest of his day.

“Nope” came hims typically verbose reply.
“So,” I asked. “Do you plan to lose, survive, or win?”
“Uh…. survive?” he answered, clearly thrown off his recalcitrant game.
“Interesting choice.” I said, and left it at that.

But I think it’s worth asking ourselves each day. As we prepare to meet the challenges inherent in the day of a typical IT pro, do we envision ourselves losing, surviving, or finding a way to win?

Sometimes it’s not important whether you actually win. Sometimes what matters – on day 463 of your job – what your plan is.

The rest is part of the journey.

Breaking the Loop

There are times when doing it all over again can be part of a brand new discovery. And there are times (maybe MOST of the time) when it’s not.

There are times when doing it over is just busywork, repetition, your own little slice of Groundhog Day (but without getting Andie McDowell at the end, or becoming a surgeon, or anything).

Welcome to 80% of the work of IT. Figuring out a solution once and then doing it again and again and…

Hopefully, right about now, you are asking yourself “who would want to do that?”

If a response is known, repeatable, and predictable, shouldn’t it be automated? If a service stops, automatically restart it. If a disk is filling up, clear the temp directory. If the server has too many connections, clear the ones that are old, or stale, or showing no activity.

“But it’s not that simple” you say? Each solution is a snowflake, unique in it’s particulars? That’s fine. NOT repeatable or predictable happens too.

But if you find yourself locked into a circular routine, each ticket blurring into the previous one, it might be time to look for a pattern so you can break out of it.

I’d Like the Record to Reflect…

What do you do when creativity refuses to cooperate? When you have the intention to create something, but that spark, that “thing” just isn’t happening?

Author Elizabeth Gilbert (“Eat, Pray, Love”) gave a speech about nurturing creativity at the 2009 TED conference. I strongly recommend it to anyone who has 19 minutes to spare:  http://www.ted.com/talks/view/id/453

Near the end of Ms. Gilbert’s talk she speaks to the invisible externalized part of her that provides inspiration:

You and I both know that if this book is not brilliant, that is not entirely my fault, because you can see that I am putting everything I have into this […] so if you want it to be better, then you’re going to have to show up and do your part of the deal […] but if you don’t do that, then […] I’m going to keep writing because *that’s my job*. And I would please like the record to reflect today that *I* showed up for my part of the job.

As I.T. professionals, we don’t always think of ourselves as particularly “creative”. But if we are honest, we know there are moments. We actually seek them out.

When I.T. pros connect with their creative selves, “just fixing it” turns into a solution which is elegant, inspired, and repeatable.

Don’t Tell Me “It’s Complicated”

HT to my hero and writing inspiration Seth Godin. His post here got me started, and his style is something I have wanted to emulate for years now.


Please

don’t tell me that it – monitoring – is complicated.

Don’t tell me you’re a snowflake – unique in your need for 1200 alert rules.

Don’t tell me “but our company is different. WE create value for our shareholders. Not like your other clients.”

Don’t tell me you can’t do it because…

Because

I’ve been creating monitoring solutions for over a decade.

I’ve designed solutions that scaled to 250,000 systems, in 5,000 locations

I work at a company that has written millions of lines of code to do this one thing, and do it well.

So please Don’t tell me it’s complicated.

Tell me what you need. What you want. What you wish you could have.

And then LISTEN to what I have to say. Because I’ve seen this before. I’ve done this before. And it’s NOT complicated. It’s also not easy.

But it is simple.

Showing Your Scars

One summer I was hired to help build scenery for a local summer stock theater venue. The problem is that I had been trained as an electrician, so every task in the wood shop required that I learn new skills on-the-fly. Because this was a job not a class and I was expected to know what I was doing, I didn’t ask enough questions and ended up making about twice as many mistakes as necessary on everything. Most of those mistakes weren’t life-threatening.

But one of the times, I was working on the table saw had my first experience with kick-back (for a video of what this looks like, see here. No, that’s not me.).

Similar to the video linked above, I was lucky that nobody was hurt, but then something weird happened – everyone started showing off their scars.

Guys who hadn’t even been in the wood shop when my accident happened came down from ladders, up from trenches, and over from across the park to show me scars that decorated their arms, fingers, hands, legs, and torsos. Each one came with a story, and the stories were remarkably similar:

“I was doing this thing… I was standing in the wrong place… I stopped paying attention for a second…  and BOOM!”

This story was followed by “And that’s why from then on I always make sure I <fill in the name of the safety procedure>”.

In addition to being thankful that no one was harmed, I was grateful for them not making me feel like I was a complete numskull for letting this happen. Apparently it can (and does) happen to everyone.

But I also wondered why nobody thought to tell those stories on the FIRST day. Like I said earlier, this wasn’t a teaching environment but I could imagine some sort of first-day ritual – the showing of the scars – where everyone lists their  experiences (in effect, showing their scars) and sharing the life lessons they learned from them.

Because not EVERYONE has had EVERY mishap, but in a team of 5 or more professionals, collectively the group has seen a lot.

At the time I thought that if every scene shop adopted a custom like that, more people would learn better lessons and have fewer scars (not to mention more severe injuries) to show for it.

I was reminded of this episode in my life the other day, when someone tweeted about reconfiguring a remote network device, only to find they had messed up one of the commands and the entire site was no longer accessible. A 2 hour drive was required to get on-site and fix the issue.

Immediately after the tweet came an outpouring of advice:

“Cisco’s ‘reload in’ command is your best friend.”;
“Always test your config in GNS3 first”;
“Never update a config until another set of eyes has looked at it first”
…and so on…

It reminded me of everyone coming down to the scene shop to show me their scars.

The next time you are sitting with your colleagues at the office – maybe you have a new face on the team; or maybe it’s YOUR first day; or maybe you’re starting a new project. Think about ways you can initiate a “showing of the scars”. Go around the table and list out your worst mistakes and the lessons you learned from them.

I’m willing to bet that you will grow closer as a team; that fewer “rookie” mistakes will be made by everyone; and that even the most grizzled veterans will probably learn a few things they didn’t know (or possibly had forgotten).

More people learning better lessons with fewer scars to show for it.

The Difference Between Work & Life

TL;DR: My opinions are my own, but sometimes I gotta pay the bills. I’m also not willing to win a flame war only to lose my job.

Henri Ducad/Ra’s Al Ghul: Mind your surroundings, always
Bruce Wayne: Yield!
Ducard: You haven’t beaten me. You just sacrificed sure footing for a killing stroke.

In “Batman Begins” Bruce learned that maintaining a focus on one’s surroundings is sometimes more important than the actions of one’s opponent or goal.

For sure, one cannot focus on surroundings to the exclusion of the opponent or goal, but rather it is a constant juggling of attention, or (for the technical readers) rapid task switching if not true multi-tasking.

The reason I bring this up is because now, more than ever, I have to mind my surroundings.

My job as SolarWinds HeadGeek – my dream job, I might add – affords me the chance to write articles in a wide variety of publications, to speak at a variety of conferences, and to be active on social media as part of my job. 

I mean, how cool is that? I get PAID to tweet, blog, like, follow, pin, instagram, and more!

BUT… it comes with a pricetag – I’m expected to be professional. Which most of the time is not a big deal. I *like* being professional. I think being polite, kind, positive, encouraging, insightful, introspective, self-deprecating, and (when I’m lucky) funny is kind of my jam. 

Never the less, there are things that push my buttons. It could be an act (whether personal or corporate) that I see as un-just; or an event that touches on a cause that is important to me; or a technical choice that rubs me the wrong way. 

Or maybe I’m just ornery that day.

The challenge is that the trade-off for getting to write and speak and tweet is that I represent more than just me. If I lose my cool and call someone a flaming jack-wagon on Facebook, it’s not just Leon’s opinion (no matter how many “opinions are my own” disclaimers I put in my profile). Effectively, I and the company I represent have just called someone a flaming jack-wagon. 

And that is what we call in IT circles a “Resume generating event”. 

SO… this is a reminder (which I will link to on social media from time to time) that:

  • I am me. A person with opinions about life, religion, politics, food, operating systems (Linux!), tabs vs spaces (SPACES!), and whether it’s the network’s fault (it’s never the network)
  • I am also (and, I should add, PROUDLY) a HeadGeek for SolarWinds

Sometimes my public activity will be part of “paying the bills”. In the middle of a social event you’ll see me tweet about the next episode of SolarWinds Lab. Or I may be strangely silent about the thing everyone is talking about. 

That doesn’t mean I’m a shill for the man, or that my account is operated by a soul-less corporate robot. It just means that I have to mind my surroundings, and make sure that I’m not sacrificing the sure footing of my platform and support for the fleeting glory of a temporary victory.

Net Use: It’s Geek-Speak for “I Love You”

This year, SolarWinds started publishing a video series called “Geek Memories”, where the Head Geeks and other IT Professionals share flashbacks from their past, moments which defined or exemplified their geekiness and showcased a lesson that we who have made our careers in technology can relate to.

One particular memory of mind appeared recently, and I wanted to share some additional thoughts about it. You can watch the video here.

It’s no secret that I love language. I collect words and phrases the way some people collect colorful shells at the beach. I love the connection between language and culture, how one defines the other and vice-versa.

In looking back at the way “Net Use” has become a secret phrase between my wife and me, I realized this is a phenomenon that all IT Pro’s should be aware of and use to their advantage.

What I mean is that language is, first and foremost (and perhaps only?) a bridge between two parties. The golden rule of communication is not “communicate unto others as you would have them communicate to you”. Instead it is “Communicate unto others as they want (need) to be communicated to”.

Saying “Well, I prefer email, and therefore I will only use email to communicate to the other teams.” is as poor a choice as saying “Well, I prefer to speak French, and therefore I will be using French in all of my conversations.”

That idea applies to everything from the mode of communication (email, sms, face to face, phone) to the length of the conversation to your use of graphics or not. You must Know Thine Audience and tailor your information accordingly. After all, you wouldn’t ask Notepad to open and edit a Photoshop file. Don’t ask your (accounting) customer to speak fluent OSI model.

This concept also means avoiding un-necessary jargon when possible, or defining it (repeatedly if necessary) when it’s unavoidable. This is such a simple thing and yet I find IT pros who think this is tantamount to lobotomizing the entire discipline they’ve devoted years to becoming experts in. Trust me on this one – not using your favorite buzzword or acronym doesn’t make you any less of an expert. In fact, the real experts are the ones who can explain a concept, design, or plan without resorting to any specialized words. Don’t believe me? Check out “Thing Explainer: Complicated Stuff in Simple Words” by Randal Munroe (creator of XKCD) for a fantastic (if comical) example.

Recently, Seth Godin commented on the comic that inspired that same book. In that essay, Godin points out that using words, even if they exceed the 1,000 most commonly used words (or the 20,000 word vocabulary most of us have) is a one of the things that identifies us as a true professional.

I couldn’t agree more. I’m not talking about whether or not you know a word, command, programming function, etc. I’m talking about whether you can put those words into context for the listener. Can you give listener a meaningful frame of reference so that they remember the ideas you are sharing because you’ve made them relevant, have impact, and connect to their own experience?

Which brings me to my next point. The story about me and my wife and “Net Use” is cute because our experience informed the phrase with meaning. I’m not saying that you should go to work and start using arcane technical commands in place of common every day ideas (“hey boss, grep s/hungry/lunchtime/”). Instead, I believe we need to understand and appreciate how experience informs understanding. It’s not enough to give a definition of RAID1+0 or EIGRP or hybrid cloud. It’s far better to allow people to experience those things in some way and then provide the term to describe the experience they are having.

As Thomas LaRock said in an article titled “Telling Ain’t Training: How to transfer IT Skills”:

“Having knowledge is good. Sharing knowledge is better. But applying knowledge and sometimes adapting it to other scenarios is the best way to train yourself when it comes to new technologies”

That’s not always possible, but you would be surprised how many opportunities there are to link an experience to a concept and term. It is about, as professional educators say, finding ‘teachable moments’. Sometimes those moments come during a weekly department lunch-and-learn. Sometimes you can turn a routine problem ticket into a chance to say “Hey, people, check this out. I want to show you something I see all the time.” And sometimes the opportunity comes in the middle of a Sev1 emergency call. You need to take the opportunities as they present themselves.

It takes practice to find the right balance for your personality and work environment, but if you are able to do this consistently, you will find your ideas are better understood, your initiatives get more buy-in, and elusive tasks like “cross-training your coworkers” becomes infinitely easier.

After all, you are now speaking a common language.

#BlogElul Day 29: Return

RETURN is one of the most basic of all constructs in IT. Whether you are a programmer, sysadmin, network engineer, Virtualization architect, or something else, there is an almost 100% likelihood that you have needed to find out the RETURN code from one of your systems at some time in the past.

For that reason, I love that this is the last prompt for this series. It’s a way of saying “We’re all done here. Run garbage collection, write to the log files, and close this puppy down.”

It’s been a great run – by far my most successful participation in #BlogElul. Not only did I complete each and every one of the prompts this year, I did it twice – once on this blog and once on EdibleTorah.com.

For those who are long on time and short on inspiration, here’s a review of each of the essays.

Thank you for coming along on this journey with me.

RETURN 0
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

// Every good programmer leaves an easter egg or two
// Here’s where I would like to thank a few people:
// First, I am blessed beyond measure to have had the chance to marry my best friend.
// without her, I would be lost adrift in the sea of madness and chaos.
//
// Second, thank you to Phyllis Sommer (aka “Ima on (and off) the Bima”) for kicking this // event off year after year and generating both writing prompts AND enthusiasm
//
// Third, to Rabbi Raphael Davidovich. This was his first year participating in #BlogElul, and
// I tried not to ape his thoughts too much. or without attribution. But like a good partner
// at the gym or a good chevruta (sorry, CHEVRUSA) at yeshiva, his work pushed me to do
// my best as well even when I might have been more lenient with myself.

#BlogElul Day 28: Give

If you work in IT, there are a few things which I know are true about your job even if I’ve never met you:

  • You are busy. You have enough work for you, your clone, and your clone’s cousin. Same goes for your coworkers (and their clones and cousins).
  • You know things. Maybe a lot of things. If you have worked in IT for more than a month, you have a few tricks up your sleeve that other people who “know computers” will never have heard of.
  • You hold the things which are known – by you, your coworkers, their clones, and cousins – in very high regard. The things you know are what make you valuable as an IT professional.

Knowing all of that, I understand how what I’m about to say may shock you:

Give. It. Away. All of it.

Despite being busy. Despite the fact that the person you are going to give away all your hard-won knowledge may not have “put in their time” or “earned their stripes”. Despite the fact that if TWO of you know the tricks, there’s a chance that you may not be as valuable. Despite all of that.

Because I know something else: You are wrong.

You are not too busy to give your knowledge – to write or podcast or vlog or just sit someone down and TELL them (ewwww! How ANALOG!). You are not too busy for that.

Because in sharing what you have, you will gain. In spreading what you know, you will never lose. In giving away for free the things which cost you in the precious coin of time and sweat and tears you increase rather than decrease the value of it.

In fact, giving may be the greatest gift you ever receive.