While this article is geared toward senior system administrators taking a more active role in the development of newer team members, those readers who are new might find interest in a different view of the world of working with newer systems administrators.
As a system administrator who has been in the role for a long time, it’s easy to shake a proverbial cane at those newer team members who bother you with inane questions lacking the technical detail needed to provide a complete answer. It would be so easy to gruffly utter a few words to get them to go away, or point out the lack of specificity of the question in such a way as to make them feel so small that they won't talk to you again. I’ve been there, and—being frank—done exactly that.
I was recently reading a discussion forum where there was an administrator who appeared inexperienced and, apparently, all on his or her own to figure things out. That caused me to think back to my first system administration job, and realize how thankful I am that when I started, I had someone senior who was willing to invest time in helping me become better. This better didn’t come in the form of drilling me with commands or syntax, but with a more Socratic method to help me develop skills that I use almost every day.
When I first started with the group, whenever I hit an issue, I would go down to Chris’ office with my notepad and pencil and ask him about the problem (sometimes multiple times a day). After about a week of this, I came into his office, as usual, to ask about a system call or something. He didn’t look at me and put his hand up, signaling me to stop.
After he finished whatever it was he was working on, he turned to me and said, “What research have you done about this question? Man pages? Google searches? -h output?”
I said, “No, I just came down here to ask you.”
His response set the tone for the rest of our relationship: “Right. Well, from now on, you are to do research to try and answer your own questions. If, after you’ve exhausted your other options, you still don’t have an answer, or you have further questions not answered by the man page, article, or whatever other sources you’ve looked at, then come see me.”
He then sent me on my way to research my own question. From that point on, whenever I came into his office, if I didn’t start with what I had done to research my own inquiry, his very first question was: “What research have you done on this?” If I had done none, or had not looked in the right place, he’d send me on my way to do more research, or would point me at a man page or article to read.
When I was mostly self-sufficient, we could then talk about refinement. For example, one day I groused that I was spending a ton of time trying to find the right man page because keyword searching returns more matches than I wanted. He then spent time explaining that the man pages were organized into sections and that for programming stuff, I probably wanted those keyword matches in section three, whereas for commands I likely wanted to look at section one or eight. (A filter criteria I still use when looking for commands or information in man pages.)
After two to three months of this, I rarely asked him anything. If I did, I came in with a basic understanding of what I was asking about, so that it was not him telling me things, but instead us having a discussion about the topic so that my understanding of it improved. This one change in how I interacted with him made the interactions deeper, and more fulfilling for both of us.
It all started with him making me try to solve my own problem first. That developed, in me, the ability to do my own research to troubleshoot or resolve my own issues, which has been invaluable across the course of my career.
Looking back on this early period, I realize how truly lucky I was to have someone like Chris to be my senior and, ultimately, a mentor. I also now see how that same care and feeding is not being applied to many new system administrators today.
Personally, I try hard—and mostly succeed—at not replying with links like lmgtfy, but instead something more constructive like, “I can’t answer that because you haven’t provided XYZ data, and here’s why you’d want to look at that data…”
In any event, someday I won’t be doing this work anymore. Whoever comes after me will, and it’s incredibly powerful to think that I can shape that next generation that replaces me. If you’re a senior system administrator, now is the time to impart that vast, encyclopedic knowledge you’ve accumulated over your career to the next generation of systems administrators!
This article started as a conversation on learn.redhat.com.
