Saturday, April 15, 2017

Thoughts on System Administration: Creativity Part 1

Background:
I have been in IT since about 1992.  I got started later than most people I know.  I was in my late twenties with only a computer repair certification; one that included electronics training it was so long ago.  I started as a hardware tech, and eventually found my way to system administration relatively quickly compared to my total number of years in IT thus far.

Creativity:
I used to think that creativity was only the domain of people that created some kind of art.  It has been my reading in spiritual matters that has expanded my notion of creativity to the area of my day job.  It started when I realized that writing scripts helped fulfill my own need to be creative, and to especially to engage creativity in my work.  I have come to see creativity as a vital component to all areas of system administration work.

Especially in troubleshooting, creativity plays an important role.  While our digital work environment is governed by logic, creativity helps you to imagine other sources or pathways a problem might logically take to cause the issue you are trying to solve.  When building high performance clusters, or Hadoop foundations, and integrating them into customer environments, it is very common to fix one problem just to find two more laying underneath.  Or to have to have to backup through the system to find problems you did not know about yet that allow you to fix the original problem you started with.

In many instances in the past I have been struggling with a problem that defies all my attempts to resolve the effects it is having on a set of systems.  It is creativity that usually suggests another avenue of approach and ways to test possible solutions.  Typically, I can come up with one more way to attempt a fix.

Sometimes, the best move is to back off of the problem, and allow my subconscious to work on it while I do other things.  It does not matter what those other things are, but to actively engage my brain in unrelated work or play.  Once in a while the ah-ha moments hits that either supplies the fix, or at least another approach to the issue.

Many times the solution does not come from me, but from someone else I have asked for help. The constant attempts narrows down the number of people I may ask for help.  This cuts down on the number of replies that I know lead down the wrong roads.  I also allows me to include what, I hope, is enough relevant data when describing my problem.

If nothing else I can at least say to those I have asked for help, that I have attempted to solve my own problem, but have come to a dead end.

I see a lot of questions all over the Internet from people in professional positions, and the questions give the impression that no effort to solve the problem has been attempted.  I am not sure I understand how that can be since it is our responsibility to solve problems that keep our systems from working correctly.  It is not anyone else's responsibility at the end of the day. I find it very frustrating when a professional shows no initiative to solve their own problems, but simply wants the solution handed to them.  (I am sure I have been guilty of this myself since we tend to dislike in others things we dislike in ourselves.)

In this day and age, there is not really any excuse in the majority of cases.  So where do you start?  There are at least two places to begin:
  • RTFM: Read The Fine Manual.  I am still guilty of asking a question that is answered in a manual.  I skimmed the manual, and ran right over the answer.  Read the whole thing when you do not have a problem, and then use the document viewers search capability to search relevant words when troubleshooting.  Now, I will admit that there are some really bad manuals out there that are of no help at all, or cause more confusion instead of giving clarity.  I have also encountered some systems or software that have hidden information in a place where no one would look for a manual or readme files.
  • The Interwebs.  How did we ever get along before Google?  I specifically remember a problem in my early years where I was searching through the index pages of various manuals, and using Alta Vista looking for anything that mentioned the topic of the problem I was trying to solve.
To me it is very important that we try to solve our own problem by whatever means and resources are available to us.  NOT trying to first solve our own problems shows, to me, a lack of creativity, and I am beginning to consider it a major skill all system administrators need.  You could also call it resourcefulness.  I am not sure they do not actually mean the same thing in this context.

There is definitely more to be said regarding creativity in systems administration, so I may take a stab at those another day.

Monday, June 27, 2016

Why I decided to learn software development

I have worked in UNIX/Linux System Administration for over 20 years now. I have always loved writing shell scripts, and I have gotten pretty good at it. I dabbled a bit with Perl and Python, but in these later years the opportunity to write scripts has been lacking. So, my memory of Perl and Python syntax is hard to recall on demand. I spend more time looking things up and troubleshooting, than actually making progress on my script.
There are several reasons I decided to try may hand with a formalized software development program.
1. Many years ago, one of my mentors said that many SysAdmins are just frustrated programmers. That really resonated with me, and my love of scripting.
2. The landscape of System Administration is changing with DevOps becoming a more commonly heard buzzword. Most of my DevOps knowledge gaps are programming and web related.
3. As I get older I feel the need to expand my marketable skills set. It is already hard for older IT people to get tech jobs, because years of experience usually translates into a higher salary. Most companies do not want to put up the money for that, preferring to hire less experience professionals. Plus, most of my friends I started out with have either left the profession or are in management now. Not many of us want to stay in the hands-on tech roles.
4. I find it hard to consistently dedicate time to tasks that are not directly related to what I am working on at the present moment. Learning new things that do not immediately help my current work will get postponed, and eventually a lot of time passes before I get back to it. Then I usually have to start over. Taking a formal course, that cost me some money, keeps my focus on it better. I have also found some software to help manage tasks both as a todo list, but also in a kind of personal Kanban style. 5. Also, I have no idea if I write clean code now or not. I have never really had anyone critique my style or my logic, and I though some formal training might help with writing code that others could understand and follow.
The one thing I love about scripting/programming is the marriage of mathematical logic and creativity. My family things I am crazy when I tell them that math and code can be beautiful both in a visually pleasing way, but also beautiful in a logical sense as well.
I think that about sums up why I decided to dive into learning software development.