This post originally appeared on SolarWinds GeekSpeak
“Oh Geez,” exclaimed the guy who sits 2 desks from me, “that thing is ancient! Why would they give him that?”
Taking the bait, I popped my head over the wall and asked “what is?”
He showed me a text message, sent to him from a buddy—an engineer (EE, actually) who worked for an oil company. My co-worker’s iPhone 6 displayed an image of a laptop we could only describe as “vintage”:
(A Toshiba Tecra 510CDT, which was cutting edge…back in 1997.)
“Wow.” I said. “Those were amazing. I worked on a ton of those. They were serious workhorses—you could practically drop one from a 4 story building and it would still work. I wanted one like nobody’s business, but I could never afford it.”
“OK, back in the day I’m sure they were great,” said my 20-something coworker dismissively. “But what the hell is he going to do with it NOW? Can it even run an OS anymore?”
I realized he was coming from a particular frame of reference that is common to all of us in I.T. Newer is better. Period. With few exceptions (COUGH-Windows M.E.-COUGH), the latest version of something—be it hardware or software—is always a step up from what came before.
While true, it leads to a frame of mind that is patently un-true: a belief that what is old is also irrelevant. Especially for I.T. Professionals, it’s a dangerous line of thought that almost always leads to un-necessary mistakes and avoidable failures.
In fact, ask any I.T. pro who’s been at it for a decade, and you’ll hear story after story:
- When programmers used COBOL, back when dinosaurs roamed the earth, one of the fundamental techniques that were drilled into their heads was, “check your inputs.” Thinking about the latest version of exploits, be they an SSLv3 thing like ‘Poodle’, or a SQL injection, or any of a plethora of web based security problems, the fundamental flaw is the server NOT checking its inputs, for sanity.
- How about the OSI model? Yes, we all know its required knowledge for many certification exams (and at least one IT joke). But more importantly, it was (and still is) directly relevant to basic network troubleshooting.
- Nobody needs to know CORBA database structure anymore, right? Except that a major monitoring tool was originally developed on CORBA and that foundation has stuck. Which is why, if you try to create a folder-inside-a-folder more than 3 times, the entire system corrupts. CORBA (one of the original object-oriented databases) could only handle 3 levels of object containership.
- Powershell can be learned without understanding the Unix/Linux command line concepts. But, it’s sure EASIER to learn if you already know how to pipe ls into grep into awk into awk so that you get a list of just the files you want, sorted by date. That technique (among other Unix/Linux concepts) was one of the original goals of Powershell.
- Older rev’s of industrial motion-control systems used specific pin-outs on the serial port. The new USB-to-Serial cables don’t mimic those pin-outs correctly, and trying to upload a program with the new cables will render the entire system useless.
And in fact, that’s why my co-worker’s buddy was handed one of those venerable Tecra laptops. It had a standard serial port and it was preloaded with the vendor’s DOS-based ladder-logic programming utility. Nobody expected it to run Windows 10, but it fulfilled a role that modern hardware simply couldn’t have done.
It’s an interesting story, but you have to ask: aside from some interesting anecdotes and a few bizarre use-cases, does this have any relevance to our work day-today?
We live in a world where servers, storage, and now the network is rushing toward a quantum singularity of virtualization.
And the “old-timers” in the mainframe team are laughing their butts off as they watch us run in circles, inventing new words to describe techniques they learned at the beginning of their career; making mistakes they solved decades ago; and (worst of all) dismissing everything they know as utterly irrelevant.
Think I’m exaggerating? SAN and NAS look suspiciously like DASD, just on faster hardware. Services like Azure and AWS, for all their glitz and automation, aren’t as far from rented time on a mainframe as we’d like to imagine. And when my company replaces my laptop with a fancy “appliance” that connects to Citrix VDI session, it reminds me of nothing as much as the VAX terminals I supported back in the day.
My point isn’t that I’m a techno-Ecclesiastes shouting “there is nothing new under the sun!” Or some I.T. hipster who was into the cloud before it was cool. My point is that it behooves us to remember that everything we do, and every technology we use, had its origins in something much older than 20 minutes ago.
If we take the time to understand that foundational technology we have the chance to avoid past mis-steps, leverage undocumented efficiencies built into the core of the tools, and build on ideas elegant enough to have withstood the test of time.
Learning new technologies is a constant challenge, but it is one that IT pros need to overcome to ensure a networking career remains relevant.
This post originally appeared on TechTarget SearchNetworking
Back in December 2014, Cisco filed a lawsuit against Arista Networks because Arista’s network device operating system, EOS, was too similar to Cisco’s beloved IOS.
This caused Tom Hollingsworth (a.k.a. “The Networking Nerd”) to speculate that this action presaged the ultimate death of the network device command-line interface (CLI).
Time will tell whether Hollingsworth is right or wrong and to what degree, but the idea intrigued me. Why would it matter if the command-line interface went away? What would be the loss?
Now, before going further, here’s a little background on me: I tend to be a “toaster” guy when it comes to technology. I don’t love my toaster or hate my toaster. I don’t proselytize the glorious features of my toaster to non-users. I just use my toaster. If it burns the toast, it’s time for a new toaster. Sure, over the years I’ve built up a body of experience that tells me my bagels tend to get stuck in the upright models, so I prefer the toaster/oven combos. But at the end of the day, it’s about making good toast.
Jeez! Now I have a craving for a panini. Where was I? Oh right, technology.
I use a lot of technologies. My phone is Android. My work laptop runs Windows 8.1. My home desktop runs Linux. My wife lives on her iPad. So on and so forth. I’ve come to believe that learning technology is like learning to play cards.
The first game you learn is new, interesting and a little confusing, but ultimately thrilling because of the world it opens up. But the second card game, that’s the hard one. You know all the rules of the first game, but now there’s this other game that completely shatters what you knew. Then you learn your third card game, and you start to see the differences and similarities. By the fifth game, you understand that the cards themselves are just a vehicle for different ways of structuring sets.
I believe that’s why people are concerned about Hollingsworth’s prediction of the death of CLI. If you only know one game — and let’s face it, CLI is an extremely comprehensive and well-known “game” — and you’ve invested a lot of time and energy learning not only the rules of that game but also its nuances and tricks, finding out that game is about to be discontinued can be distressing. But when it comes to CLI, I believe that distress is actually due to a misplaced sense of self. Because you aren’t really a CLI professional, are you?
Sure, you know a lot about CLI. But really, you’re a networking professional. Being able to configure open shortest path first (OSPF) from memory makes your job easier. But your job is knowing what OSPF is, when to use it versus enhanced interior gateway routing protocol, how to evaluate its performance and so on.
No, the concern about the death of CLI is really rooted in the fear of personal obsolescence. I’ve heard that notion repeated in conversations about the mainframe, Novell networking, WordPerfect 5.1 and dozens of other technologies that were brilliant in their time, but which, for various reasons, were superseded by something else — sometimes something else that is better, and sometimes not.
And a fear of personal obsolescence in your networking career is ultimately false, unless you are digging in your heels and choosing never to learn anything new again. (OK, that was sarcasm, folks. As IT pros, we should be committed to life-long learning. Even if you are two years away from retirement, learning new stuff is still A Good Thing™.) As long as you are open to new ideas, new techniques and yes, new systems, then you won’t become obsolete.
I’ll be honest. I think there are a lot of employers that exploit this insecurity. “Where’s a Perl script-kiddie like you going to find this kind of role?” they whisper — usually implicitly, although sometimes much more explicitly than any of us prefer. Or if we’re interviewing for a new job, they ask, “I see you have a lot of experience with AIX, but we’re a Windows shop. Do you really think your skills translate?”
I’m not here to talk about interviewing skills, salary negotiations or career improvements, so I’m not going to get into the potential responses, but I will say that the ultimate answer in each of these cases — and many others — is “Yes.” Why? Because it’s not about whether I know the fifth parameter of the gerfrinkel command in CodeMe version 18.104.22.168, which was deprecated in 22.214.171.124 in favor of the unglepacht function. It’s not about any of that. It’s about my experience on when to use certain commands, when to look for a workaround, how to manage an environment of this scale and scope and so on.
To play off the old joke about the copier repairman, a small part of your paycheck goes toward turning the screw; more of it is based on knowing which screw to turn.
As IT pros, we are paid — and are valuable — because we know how to find out which screw to turn and when to turn it. So to speak, of course.
As we tip over from the mad rush of December and prepare to ease into another year, I like to take a minute to appreciate the hush and calm that comes after the rush and bustle of various holidays.
This week after New Year I like to take a few moments to pause and regroup before diving into the new year. A chance to take stock, reflect, and think.
And so I’ve held off until now to officially promote the fruit of a few of my 2015 labors. If your resolutions for 2016 include making time to do some reading that doesn’t break your stretched-too-far-after-all-those-gifts budget, I want you to know that I’ve got a few eBook recommendations for the busy IT Pro. Each is available for Kindle (on Amazon) and also as a free PDF download.
Despite the relatively maturity of monitoring and systems management as a discrete IT discipline, I am asked – year after year and job after job – to give an overview of what monitoring is.
This book is my attempt to address that question in a more structured form, published with the assistance of the amazing folks at SolarWinds.
Intended as guide to help bring new team members (often fresh out of college or a technical program) up to speed with monitoring concepts quickly, this ebook (or portions of it) can serve as a good introduction for a variety of audiences.
“Technically, These Are Some Random Thoughts”
Around September every year, Jews all over the world celebrate Rosh Hashana, the Jewish New Year. However, it’s not – to put it in business terms – a year-end review. It’s a job interview. the month before Rosh Hashana (called “Elul” in Hebrew) is the time for getting one’s balance sheet in order. To help with that, a bunch of folks from all walks of life participate in #BlogElul: A daily prompt provides the theme and people riff on that – sometimes a few hundred words, sometimes an image, sometimes a poem or just a single sentence. It’s something I’ve done for a few years now. I thought I’d add a twist and also do an I.T. Professional’s version of #BlogElul and post the essays on my technology-specific blog: http://www.adatosystems.com. A reflection on each of the daily prompts and what they mean in an I.T. context. You’re probably thinking “Leon, this is a Jewish thing and completely outside the scope of my experience or interest as an I.T. Professional.” To which I emphatically reply: Yes and no. If you have worked in I.T. for more than 15 minutes, you’ve likely been involved in a large development project, system roll-out, or upgrade. And as the date for the big cut-over approaches, there are usually daily status updates. Consider this the notes from my status updates before the roll-out of “TheWorld v.5776”.
4 Skills to Master Your Virtual Universe
For some IT administrators, virtualization might not be a primary responsibility. Without the opportunity to learn and gain experience as part of their daily routine means these admins are getting a late start in the virtualization game. So why should IT admins, who don’t consider virtualization to be a critical part of their job description, care about virtualization? Because virtualization spans every data center construct from servers to storage to networking to security operations. Add in the fact that it is used in practically every IT shop and you have a perfect IT storm. So while you might have been hired to administer one of those systems, virtualization’s dependency and abstraction of those resources means you’ll need to bridge the
virtualization knowledge gap.
In this book, my fellow SolarWinds Head Geek Kong Yang describes the 4 key skills needed to gain mastery of your virtualized environment.
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.
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.
- Elul 1: Prepare
- Elul 2: Act
- Elul 3: Search
- Elul 4: Understand
- Elul 5: Accept
- Elul 6: Know
- Elul 7: Be
- Elul 8: Hear
- Elul 9: See
- Elul 10: Count
- Elul 11: Trust
- Elul 12: Forgive
- Elul 13: Remember
- Elul 14: Learn
- Elul 15: Change
- Elul 16: Pray
- Elul 17: Awaken
- Elul 18: Ask
- Elul 19: Judge
- Elul 20: Dare
- Elul 21: Love
- Elul 22: End
- Elul 23: Begin
- Elul 24: Hope
- Elul 25: Intend
- Elul 26: Create
- Elul 27: Bless
- Elul 28: Give
- Elul 29: Return
Thank you for coming along on this journey with me.
// 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.
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.
As I’ve been writing each day this month, I’ve come back repeatedly to the idea that – if you choose a career in IT – it is important to find a niche (both in terms of the company where you work, the company you keep, and the work you do) that you love.
I realize this is far easier said than done. But just because it’s difficult doesn’t mean the effort is not worth it.
That would have been hard for me to prove until recently. I’ve been blessed this past year to have found a place as Head Geek at SolarWinds. It’s a job that engages so many facets of my experience – from my theatrical training in college to my love of writing to my years as an IT generalist, and of course my passion for monitoring. But it’s also a job that allows for the facets of my life which are not work related but equally important to me – my religious convictions, my family, and even the city where I’ve chosen to put down roots.
So I’m not going to drag this out. I have found my blessing in this work that I’m doing.
I hope in the coming year, you do, too.