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

People talk about life-long learning and how that keeps one mentally alert and youthful. The same is true of SysAdmins. There is always more to learn and I think that is what keeps most of us happy and always ready to tackle the next problem. Continuous learning helps to keep our minds and skills sharp no matter what our age.

I love to learn new things. I was fortunate in that my curiosity led me to a lifetime of working with my favorite toys – computers. There are certainly plenty of new things to learn about computers; the industry and technology are constantly changing. There are many things on Earth and in this Universe to be curious about. Computers and related technology just seem to be the thing I enjoy the most.

I also assume that you must be curious because you are reading this article. But not everyone is as curious as we are.

Charlie

Let’s take a trip in my Wayback machine to 1970 in Toledo, Ohio. I was working at a chemical plant in a very boring job as a tester, along with seven or eight others. We would take chemical formulations dreamed up by our chemists, compound them into vinyl, and press it into various types of fabrics used in the automotive industry for seats and vinyl roofs. Our jobs were to test the resulting raw vinyl and coated fabrics to see if they met all of the specifications supplied by the auto company that had ordered them.

Never seen a vinyl roof on a car? Yeah, that long ago!

One of my co-workers, Charlie, was a negative sort of guy. His complaining was incessant. He would complain about the working conditions – we had lots of volatile chemicals around and it was pretty easy to get high and stay there if that is what you wanted, but it was also dangerous. He complained about the danger and about how boring the job was but we all did some of that – it was part of being in that type of job. But Charlie complained about everything from the moment he walked in until the ending whistle blew in the afternoon.

Charlie said to me one morning about 8:30am, “I hate this job. Quitting time can’t get here fast enough.”

I was getting pretty fed up with his negativity, so I responded, “Charlie, if you hate this job so much, why don’t you find another job?”

“I don’t know how to do anything else.”

So I said, “Well, why don’t you learn something new? I’ll be going back to university next term and I’m not going to stay here for long after I get my degree. I plan to get a better job.”

“That’s easy for you — you’re young. I’m old and you can’t teach an old dog new tricks.”

I asked him, “How old are you Charlie?”

“Thirty-six,” he said.

Even then, in my early twenties and seemingly invulnerable and immortal in my own mind, I knew that thirty-six was not old. Right then I vowed to myself that I would never stop learning – that I would learn something new every day. And I have kept that vow. Of course that vow has been pretty easy to keep what with both my vocation and avocation being computers for most of the last 50 years.

Curiosity lead me to Linux

Curiosity got me into Linux in the first place but it was a long and winding road. I was always curious about technology like radios and TVs which were all we had in the way of technology in those ancient days.

I was curious about how the TV worked. It was easy to learn in those days, because every electronic device came with a schematic. There were books that showed various symptoms in pictures and then listed the types of tubes that would cause those problems when they failed so I bought a couple of those. I started fixing our TV when it broke. Eventually the neighbors started asking me to help them with their TVs and radios when they broke. It was also helpful that most every drug store and grocery had tube testers with a supply of tubes. That meant I could remove the tube or tubes I suspected of being the cause of the failure and walk to a place where I could test it and purchase a replacement.

I spent the summer of 1968 at an aunt’s home in Los Angeles. My uncle worked as a computer programmer in the aerospace industry and I found a pile of old self-study manuals in their garage. Instead of going to the beach all the time as I had planned, my curiosity caused me to spend most of the summer learning about IBM mainframe computing from those old courses.

In late 1968 I was in a job that involved lots of number crunching and we were using very old mechanical calculators that could take several minutes to do a single multiplication. I was curious about the new 4-function electronic calculators that were just then beginning to hit the market. My supervisor thought this would be a good idea so he had me look into this possibility. Two of the vendors we contacted had these interesting new devices, desktop programmable calculators and I was curious about how I could program them to automate parts of my job.. Both vendors were willing to let me use demonstrator models so I could test them out in our own environment with problems I knew we would be working on.

I was able to convince the financial people that this $3,500 calculator was worth the cost, so we purchased an Olivetti Programma 101¹. I spent a few months programming it, and in my curiosity, wanted to learn more about programming in general.

I soon found that the university offered a single course in programming so I took a course in BASIC. This class was taught by the University of Toledo on a GE time sharing system, probably a GE-600² series, located in Columbus, Ohio. Terminal access was through an ASR33 teletype machine over dial-up phone lines at 300 baud.

I was curious about the mainframe computer our organization was using so asked to be transferred to IT. I began working on the IBM 1401 as a night operator where I had my first direct contact with mainframe computers. I worked this job for a few months before moving on.

In my next job I had no direct contact with computers, but I did worked nights for a band as their sound technician and only roadie. The drummer for the band had a by-mail course in electronics that he had paid for but did not have time to take, so he offered it to me. I snatched at this opportunity because I was still curious about electronic devices and how they worked. That electronics knowledge led me to a job at an audio sales and repair shop in Toledo where I learned even more.

By now it was around 1972 and my wife and I purchased a former rental house from my father-in-law. It turns out that one of our neighbors worked for IBM. He asked if I were interested in working at IBM, but I was happy where I was so I said I was not interested.

The audio repair job led to another job as service manager of a new stereo shop and my curiosity led me to take classes in electronics engineering. I excelled in these classes because I enjoyed electronics.

When I was laid off from my job at the new stereo shop I asked my IBM friend if they were still hiring. He got me an interview and I started a 21-year career at IBM. My first job at IBM was as a Customer Engineer (CE) in the General Systems Division (GSD) repairing hardware. In 1978, IBM moved me to their facility Boca Raton, Florida, for a job writing training courses for new products. In early 1981, I was assigned to write the training for the original IBM PC³.

In order to write the training course for the PC, I needed one in my office so I could have easy access to learn about it myself. Because it was so secret at the time, the security people had chicken wire installed in the ceiling of my office and a lock put on the door. I was the only non-manager in the building with a lock on my office door. I guess the chicken wire in the overhead was to prevent some nefarious thieves from climbing over the walls of my office and dropping down inside. Only after that could I have a PC in my office. It had serial number 00000001.

While writing the training course I initially went with a more traditional IBM training strategy but that was not working for the CEs in the Typewriter division who were paid less that we were in GSD. Using CEs from the Typewriter division made it more cost effective, but it meant we had to familiarize those CEs in computer concepts and technology. I had to make sure they got hands-on during the training, but it was too expensive to have them travel to a training center.

I was curious about programming the PC in BASIC, and at the same time, I was curious about how the CEs would react to hands-on training. So I rewrote the training completely. I wrote a complete computerized training program which would allow me to author the course content and then present it to the CEs in their local branch office on IBM PCs that we shipped to the branch office for the training. And then I wrote the course itself. Although this was most definitely not the first computerized training course, it was the first training software and courseware for the IBM PC.

In order to write this revised course and maintain our schedule with the PC release date, I requested that I be allowed to have a PC in my home so I could more easily work on the class at night. After dozens of sign-offs by various high-level executives I was given a PC to take home in addition to the one I had at the office. As far as I know, I am the first person to ever have an IBM PC at home.

Of course all of this got me very curious about personal computers and how I could learn more about them. So I bought one for myself through the employee purchase program. This cost a bit over $5,000 after the employee discount. The system included a pair of 160KB 5.25” floppy drives, no hard drive, and 64K of RAM. I started hacking PC hardware when several of us at the office went together to purchase the parts for third party memory cards that we had to build ourselves.

Following a couple more career moves, my experience with the PC led to a job at the IBM PC Help Center in Atlanta, Georgia. I was very curious about operating systems during that time and eventually became one of the primary support people for OS/2.

After moving to Raleigh, NC, in 1993, I left IBM in 1995 and started a consulting company that specialized in OS/2. By 1996 it was clear that OS/2 was not going to be around for much longer. I was appalled by the thought of learning Windows NT. I was curious about Unix and decided that it was the future for me. I had not yet heard about Linux.

Around this time an friend from IBM called me one day and asked if I knew anyone looking for a job who could help MCI, where he was now working, with their OS/2 computers. I took the job with the proviso that I would get to learn Unix. While at MCI, I was able to take some basic Unix classes that got me started.

I also heard about this thing called Linux that was a lot like Unix and that I could install on one of my personal computers. I figured I needed to improve my Unix/Solaris skills but I could not afford to purchase a Sun computer and Solaris for home. So, just out of curiosity, I purchased a copy of Red Hat 5.0 (not RHEL) at the local computer store and installed it on one of my several computers. I liked Linux and after learning more about it I found that I was not progressing. I decided to make the leap and upgraded all but one of my home computers to Linux. The final step was when I migrated my web and email server from OS/2 over to Linux.

As a result of all this learning, I was able to find a job as a Unix engineer at a local ISP. They sent me to Solaris classes and I earned a Sun Certified System Administrator certification. This is where I met some of my best mentors.

About 80 of us were laid off from the ISP and I quickly found a job as a contractor where I was responsible for fixing Perl scripts running on a Red Hat Linux server. We also used some bash shell scripts that needed cleaned up. I learned a lot more about Linux and shell scripting in that job. This job made me more curious about Perl and Bash so I spent a lot of time learning both of those languages.

That led to a series of jobs that centered around Linux, in most of which I did at least some Linux training. I found that most places I worked had the need for someone to train other admins and users in various aspects of Linux. I put together several Linux classes and Lunch-and-learn sessions that were all well received.

I have found that I learn the most myself when I am teaching others whether in a classroom environment or in books and articles. My curiosity leads me to research things carefully in order to ensure that I get them right. I also have to answer questions from students about things I never considered when creating the materials so I have to research questions that I have no answers for.

And now here I am writing about Linux which requires even more research, testing, and experimentation. All of which help to satisfy my curiosity about many aspects of Linux, hardware, and computing in general.

§§§

This is only a portion of my personal road to Linux and open source. There are a lot of side trips that affected some of my decisions and altered the timing of certain events in my life so that things were in place for the story above to unfold.

Getting a job in Linux was not something that could have been planned for while I was growing up or in school because neither Unix nor Linux nor open source existed when I was in high school and my early years at university. The choices I made, the people I met, the knowledge I gained, the places I lived, the series of jobs I had, all led to the place I am now because I chose over and over again to follow the things that I enjoyed and about which I had a deep curiosity — technology, computers, operating systems and Linux. My choices, whether conscious or not, took me along a path that was driven by curiosity. It was enjoyable and rewarding in many ways.

Follow your own curiosity

I have already mentioned more than once that you should explore the many aspects of Linux and go wherever your curiosity leads you. It was only by following my curiosity, first about electronics, then computers, programming, operating systems, OS/2, Linux, servers, networking, and more that I have been able to do so many fun and interesting things.

You may have specific personal and career goals in mind and that may fuel your curiosity by taking you to places that can help you meet those goals. You may also be an innately curious person and more inclined to be curious about things that are of particular interest to you without being attached to a specific goal. It does not matter how your curiosity is driven. It just matters that you follow it and that you not allow anyone or anything to dampen that curiosity.

Be an author

I currently write many articles for Both.org and, no matter what I write about, I always learn something new, even about things I am already familiar with. Every article I have ever written, be it for Linux Journal, Linux Magazine, Opensource.com, or Both.org has been an opportunity to indulge my curiosity and learn more about Linux.

Writing my books has not been an exception to that. Even as I research various aspects of those books I have learned more about commands that I already know and I have learned some new commands. I have allowed my curiosity to take me down paths that would never show up in my books just because it is fun to learn new things about Linux and there is so much to learn.

Finding topics about which I want to write is almost never a problem. I typically use recent events as the subjects of my articles. Things to write about are always happening. It is just a matter of recognizing them and putting the story into words. A number of things happened during the writing of my books that became part of them.

Sometimes, as I occasionally struggle to translate into words this philosophy of mine, I learn more about The Philosophy and about how I have used it and how it has helped and guided me. I have learned that in many ways, my Philosophy is about more than just Linux.

Failure is an option

“I have not failed. I’ve just found 10,000 ways that won’t work.”

— Thomas A. Edison

Thomas Edison was a curious person and that’s what led him to develop the light bulb and hundreds of other devices. Although the failure of thousands of specific combinations of individual materials and fabrication technologies during testing did not lead to a viable light bulb, Edison continued to experiment. Just so, the failure to resolve a problem or create code that performs its defined task does not mean that the project or overall goal will fail. It means only that the specific tool or approach did not result in a successful outcome.

I’ve learned much more through my failures than I have in almost any other manner. I am especially glad for those failures that have been self-inflicted. Not only did I have to correct the problems I caused myself but I also still had to find and fix the original problem. This always led to a great deal of research which caused me to learn much more than if I had solved the original problem quickly.

This is just my nature, and I think it is the nature of all good SysAdmins to look upon these situations as learning opportunities. As mentioned previously, I have spent many years as a trainer and some of the most fun experiences were when demonstrations, experiments, and lab projects would fail while I was teaching. Those were fantastic learning experiences for me as well as for the students in my class. Sometimes I even incorporated those accidental failures into later classes because they enabled me to teach something important.

Just do it

Everyone learns best in their own way. As a trainer I saw this every time I taught a class, regardless of the subject. Following our curiosity is the same – we all have that spark that leads us to discover more. Our methods may not be the same but they will lead us all to greater knowledge and skill.

I started by installing Linux on all of my computers at home. This forced me to learn Linux and not look back. So long as I had a means to go back to my old and well-known way of doing things, it was never necessary for me to truly learn Linux. This is what I did when I decided I wanted to learn Linux, and it has taught me a large part of what I know. I had several computers and created a complete internal network in my home office. Over the years my network has grown and changed and I have learned more with every alteration. Much of this was driven by my curiosity rather than any specific need.

To me, curiosity is the driving force behind learning. I can’t just sit in a classroom because someone says I need to learn a particular thing and be successful at it. I need to have some interest in the subject and something about it needs to pique my curiosity. That propensity to work harder on the subjects I liked was very evident during my school years as I did well in the subjects that intrigued me.

Summary

By using my home network for indulging my curiosity I had lots of safe space in which to fail catastrophically and to learn the best ways to recover from that. And there are lots of ways to fail so I learned a lot. I learned the most when I accidentally broke things, but I also learned a great deal when I would intentionally bork things. In these instances I knew what I wanted to learn and could target the breakage in ways that would enable me to learn about those specific things.

I was also fortunate because I had a few jobs that required or at least allowed me to take classes on various aspects of Unix and Linux. For me, classroom work is a way to validate and reinforce what I learn on my own. It gave me the opportunity to interact with – for the most part – knowledgeable instructors who could aid and clarify my understanding of the bits and pieces that I could not make sense of on my own.

Be the curious SysAdmin. It worked for me.

1. Wikipedia,Programma 101, https://en.wikipedia.org/wiki/Programma_101 ↩︎