In our fourth post in this blog series, we shine the spotlight on Skip Grube, Senior Systems Engineer, to illuminate what he loves about his role at CIQ.
What attracted you to a career in engineering?
Playing with computers in the 90’s. A natural progression formed from DOS games -> very simple programming -> slightly more advanced programming -> discovering “Linux” and fiddling with it.
What drew you to CIQ?
I joined Rocky Linux at its founding as a volunteer release-engineering team member. My background is in systems administration with a dash of dev-ops, coding, and packaging thrown in.
I like solving problems, and was running out of them at a previous job. Lots of familiarity with Rocky put me and CIQ on an inevitable collision course!
What do you think sets CIQ apart from other organizations?
A unique (and fairly customized) gathering of expert knowledge combined with a pretty laid-back and welcoming environment seem like the winning combination to me.
What's your role in the company, and what do you enjoy most about it?
I build things, fix things, and give occasional advice to customers. The things I build and fix are often not traditional computer programs. They sometimes are, but more often than not they are RPM packages, custom (Rocky) Linux OS system images, and the like.
I know how to code, but I’m no software engineer! Traditional programming is often incidental to my work, but not usually the primary focus. I’m sort of what happens when you take a Linux systems guy and throw him into a builder role!
Describe a typical day at CIQ as a senior systems engineer.
First thing I usually do is a quick check on the Rocky Linux public project, which I remain a part of and sometimes get assigned “CIQ time” to work on things related to it. Just to get a feel for anything going on in the technical side - are there pending updates we ought to be building? Are community members complaining about an outage or a change of some kind? That sort of thing.
My typical day usually revolves around building software (packages) and fulfilling some sort of customer ask. This morning I looked at some update issues, where a customer wants to perform Rocky rpm updates but using custom repositories that we help them build. This is in relation to a custom-developed OS image we’re developing for them to fulfill specific hardware and regulatory requirements.
This afternoon I’m getting up to speed on another customer who wants to streamline their build process, and convert their custom RPM packages to Rocky 8. I need to acclimate myself to their current work and “the way they do things” so I can offer meaningful suggestions and package build recipes for them.
Other typical tasks for me often involve building (or debugging builds) for CIQ Mountain subscriptions and helping our other engineering staff to fix or improve their builds.
What's the best thing about being part of the CIQ engineering team?
There is superb technical knowledge here across the board, the likes of which I haven’t seen in past employment :-). Everyone seems to be an expert at something, and sometimes several somethings!
This combined with a relaxed environment where there’s lots of thoughtful chatter make most days pretty fun.
How do you manage work-life balance while working on demanding projects?
Oh, the usual. Alcohol, mostly. (Ok, just kidding.)
For me personally, it comes down to prioritization of tasks. Which is the thing that will have the biggest impact, the soonest? And can I break that up into baby steps, so I can get myself there and not go crazy with the work?
What do you do to stay motivated and inspired in your work?
I’m lucky, as the motivation comes naturally based on what I happen to be working on. The puzzle must be solved; enlightenment must be achieved! Makes it easier to focus on something when you’re really really curious how it’s going to work, or what the fix could possibly be.
What advice would you give to someone considering a career in systems engineering, especially at CIQ?
Be as well-rounded as possible, and have a firm grasp of the fundamentals.
By “well-rounded,” I mean being familiar not only with a particular programming language or 2, but also the bigger picture: how systems are put together, the similarities and differences between different Linux or packaging systems, and realize that there are several different paths (technologies, design patterns) you can follow to accomplish a given task. It helps to be familiar with as many of those as possible.
By “fundamentals,” I’m mostly talking about Linux, the shell, and how operating systems work in general. Converting my personal laptop/desktop over to Linux circa 2003 has probably taught me more (over time) than any course, guide, or job ever could.
Do you have any fun or memorable anecdotes from your time at CIQ that you'd like to share?
Early on, someone casually mentioned “oh yeah, and we’ve got to fix this for MegaCorp. Can you do that, Skip?” “MegaCorp.” (not its real name) is a huge company that everyone (even my parents) have heard of. I did a double take. I went and looked at our customer list, and did about 5 more double-takes.
It’s not strictly CIQ, but I often re-tell a true anecdote from when I was working in a previous position. I was volunteering on the Rocky Linux release engineering team, which is a fantastic group of folks who are all smarter than me ;-). Couple of them work for CIQ, even.
My previous supervisor was introducing me to someone: “Oh, and here’s Skip Grube - he’s our Linux Guy. He knows everything there is to know about the Linux systems!” My thoughts turned to the releng team when he said that, where I am more like the newbie dunce of the group. And I said something like “Oh honey, if only you knew….”
If you weren't a systems engineer, what profession do you think you'd be in?
Going to assume computers and the internet as we know them don’t exist for this question. Because if they did exist, I’d probably end up inventing a systems engineer position, or something close to it!
No advanced computers and Linux means I’d probably end up in finance, or some kind of industrial automation job. Something where the same sorts of problems could be worked out. I imagine there’d be a lot less open source and a lot less work-from-home in this case, so I’m happy I’m not doing that!