The Linux Philosophy for SysAdmins, Tenet 22—Mentor the young SysAdmins

Author’s note: This article is excerpted in part from chapter 24 of my book, The Linux Philosophy for SysAdmins, with significant changes to update the information in it and to better fit this format.

I have taken many training courses over the years and most have been very useful in helping me to learn more about Unix and Linux as well as a host of other subjects. But training — as useful and important as it is — cannot cover many essential aspects of performing SysAdmin duties.

All of the classes I have attended were a few days in length, usually four or five. There is just too much information to be able to cover everything you need to know just with respect to commands, procedures, filesystems, processes, and many of the things I’ve touched on in my book. And not everything can be taught in the classroom. Some things can only be taught by a good mentor in a real world environment, usually while you are under extreme pressure to fix a critical problem.

There is nothing like having the Pointy-Haired Boss (PHB) or one or more minions looking over your shoulder and criticizing your every move and decision. It happens. These pressures to provide hourly progress reports, to answer dumb questions like, “when will it be fixed,” to resist the PHB’s attempts to add three more people to a one person task, and much more, not only wastes our time, it also breaks our train of thought and reduces our overall efficiency. Most of the time we know what to do and how to do it, we just need an environment that will allow us to work in relative peace.

A good mentor will allow you to do the actual work in these situations so you can have a valuable learning experience while keeping the wolves at bay, taking the heat while you work uninterrupted. A great mentor will also be able to create a learning opportunity from every situation no matter how critical.

When I first started, I was a young and innocent SysAdmin. I was fortunate because I worked at a couple different jobs where other, seasoned SysAdmins were willing to mentor me and encourage me. None of them laughed at me when I asked what must have seemed to them to have answers that were blindingly obvious. None of these patient SysAdmins ever told me to RTFM.

As a SysAdmin, particularly if you are a senior SysAdmin, part of your job should be to help hire the right people as part of your team. If your PHB isolates you from the hiring process, you should do everything in your power to change that. Fortunately, this has seldom been a problem in most of my work life. The smart managers will get their entire team involved with hiring new members.

BRuce the mentor

I was fortunate in having a number of very fine and patient mentors who allowed me to fail so that I might learn. One person in particular, BRuce, as he liked to sign his emails, ensured that I had the necessary training, but he also allowed me put that training to use very quickly. He assigned me to difficult tasks right away, ones that forced me to use my new-found knowledge and to break through the boundaries of my own comfort and self-imposed limitations.

BRuce and I worked together at two different companies over the years, both of which required deep Unix/Linux knowledge and skills. We worked together well because we were both very good at what we did. He understood that I did not start with the same skill level that he had, but he respected the skills I did have and gave me plenty of opportunity to use those skills and learn new ones.

In many ways, BRuce was the quintessential grumpy SysAdmin — and with good reason. What I mean by this is that, when dealing with less technical people such as marketing people and the PHBs about things they wanted to do in the labs for which we were responsible, his first response was almost always a flat, definite, “no.” This was always because the projects, whatever they were, would cause problems in the lab as they were initially conceived because they were all poorly thought out with no concept of what could and could not be done. BRuce then asked the persons who made the request a series of questions that eventually led us to what they really wanted to do. It seems that most of the people making these requests were also trying to design the infrastructure to support those projects and that was our area of expertise, not theirs. They were also not very thoughtful about how their projects might affect others using the lab to test their projects.

BRuce was not being a jerk like some people thought. He was doing his job which was to ensure that the lab was fully functional for everyone who used it. Most of the initial requests that we received were significantly flawed. It was our responsibility to ensure that those flaws did not affect the rest of the lab. BRuce was just very blunt because we did not have the time to deal with problems caused by other people when it was just the two of us dealing with more than 15 rows with 24 racks each in the lab, all of them full of equipment running tests that would have had to be restarted — or rebuilt — if the Lab network were to be compromised by someone’s experiments run amok.

In that type of environment there was no tolerance for errors. BRuce and I were simply enforcing lab guidelines that had been designed to protect all of the users. As my mentor, this is also something that BRuce was trying to help me understand – that this is one of those times when the good of the many outweighs the good of the few. The lab had to be run in a manner that prevented some users from impinging upon the work of the rest.

Final Thoughts

I urge you to mentor others. Pass along the knowledge, skills, and your own philosophy. There is very little that can be more important than this for experienced SysAdmins. Our skills are amazing and we did not achieve them all by ourselves. We are amazing because of those who mentored us and the fact that they thought we had what it takes to be great SysAdmins. It is our responsibility to pass that along to the younger SysAdmins.

I had some amazing mentors who understood what it takes to learn – to really learn – and who allowed me to do so. You all gave me the opportunity to learn through failure. You helped my figure out where I went wrong and got me back on track. You are my heroes. Here’s to you, Alyce, BRuce, Vern, Dan, Chris, Heather, Ron, Don, Dave, Earl, and Pam.

And to all of you unsung mentors out there – You rock! Thanks for your support and guidance.