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.
A couple of months ago, SolarWinds held their 4th ThwackCamp – a completely free, completely online conference. In the keynote, Head Geek Patrick Hubbard spoke to an interesting dichotomy in the life of an IT Professional.
“(In IT) we’re always fixing things. […] but fixing just eventually wears us down. So stop fixing things, and start to solve things.”
More than just semantics, Patrick highlighted both a mindset and an action plan. Fixing things is merely the act of making the problem go away. Maybe permanently, but that’s not part of the job. It’s just to make the pain/alarm/complaining stop.
Solving things goes deeper. It speaks to the root of the problem and to a willingness to address both the symptoms and the core cause of the issue. Solving means changing architectural or organizational issues. Solving means building a better system based on everything we’re learned from the old one. Solving means playing a long game.
If you are sitting in the hot sun, fixing the problem means dumping some water over your head. Solving the problem means planing a tree for shade.
Over the last month, many of my daily thoughts have spoken to action. What do we intend, plan, hope, or pray to do. What do we believe? How will we start (or end)?
Today I want to suggest that DO-ing is the same as FIX-ing. It’s a good start, but it’s not the whole story.
Beyond asking ourselves what we’re going to DO, we should think deeply and seriously about what we are going to CREATE.
The question is not about having the ability, or intention, or permission to create. You already have those. The question is what you are creating right now, what you will create tomorrow.
So as we look ahead to the coming year, don’t settle for just fixing things. Look at ways you can start SOLVING them. And don’t just get caught up in what you are going to DO.
Decide what you are going to CREATE.
There is a popular saying about the road to hell. It may equally apply to the road that leads to a system outage.
- If we intended to back up our servers, but never requested the SAN storage…
- If we intended to patch the application, but never cleared time for the change control
- If we intended to upgrade the network, but never included it in the budget
- If we intended to get that certification, but never scheduled the class (or exam)
It’s fair to say that when something goes wrong in IT, it is rarely because that was the intent of the people responsible.
So why do we let things like that happen? After more than a half-century of modern IT operations, you would think most of this would be utterly and unquestionably standardized.
Part of this is that things appear to change (something I’ve written about elsewhere) and therefore we fool ourselves that the methods that provide stability somehow don’t apply any more.
But part of it is that we intend to do it, but allow other things to get in our way. From the manic (“we have to inventory and integrate 3 new acquisitions this quarter”) to the mundane (“someone said something factually incorrect on Facebook!”) there are plenty of compelling reasons to postpone that change control request or certification exam.
At least, until it’s setting off alarms. Then we realize our intentions were just more fuel for the fire.