1. "You have to know how things work on a starship..." (Star Trek II)
2. "A no-win situation is the possibility every commander may face." (Star Trek II)
3. "The needs of the many outweigh the needs of the few... or the one." (Star Trek II)
4. "Mr. Scott, have you always multiplied your repair estimates by a factor of four? Certainly, sir. How else can I keep my reputation as a miracle worker?" (Star Trek III)
5. "The fancier the plumbing, the easier it is to stop up the drain." (Star Trek III)
6. "Sometimes the needs of the one outweigh the needs of the many." (Star Trek III)
7. "Perhaps 'because it is there' is not sufficient reason for climbing a mountain." (Star Trek V)
8. "An ancestor of mine maintained that if you eliminate the impossible, whatever remains, however improbable, must be the truth." (Star Trek VI)
9. "People can be very frightened of change." (Star Trek VI)
10. "One of the advantages of being a captain, Doctor, is being able to ask for advice without necessarily having to take it." (ST:TOS "Dagger of the Mind")
11. "Power is danger." (ST:TOS "Balance of Terror")
12. "Leave bigotry in your quarters; there's no room for it on the bridge." (ST:TOS "Balance of Terror")
13. "The more complex the mind, the greater the need for the simplicity of play." (ST:TOS "Shore Leave")
14. "Insufficient facts always invite danger." (ST:TOS "Space Seed")
15. "Either one of us, by himself, is expendable. Both of us are not." (ST:TOS "The Devil in the Dark")
16. "If I can have honesty, it's easier to overlook mistakes." (ST:TOS "Space Seed")
17. "No one can guarantee the actions of another." (ST:TOS "Day of the Dove")
Kirk's
old enemy, Khan, took command of the Reliant, a Federation starship.
When the Reliant approached the Enterprise, Kirk hesitated to
raise his shields. This gave Khan the opportunity to attack
and
severely damage the defenseless Enterprise. Kirk retaliated
by
using his superior knowledge of Federation technology to remotely order
the Reliant to drop its shields, allowing Kirk to launch an effective
counterattack. When asked how he knew the strategy would
work,
Kirk remarked that (if you're the captain) you have to know how things
work on a starship.
Similarly, if you're a Windows System Administrator, you have to know how PC hardware works and how Windows itself works if you're going to be very effective. Since becoming a Windows administrator, I've had to dig deeply into the Registry, crash logs, technical references, and programming guides to solve some of the more challenging issues to come my way. The more I know about how things work (or how they're supposed to work), the more effective I tend to be.
Similarly, if you're a Windows System Administrator, you have to know how PC hardware works and how Windows itself works if you're going to be very effective. Since becoming a Windows administrator, I've had to dig deeply into the Registry, crash logs, technical references, and programming guides to solve some of the more challenging issues to come my way. The more I know about how things work (or how they're supposed to work), the more effective I tend to be.
2. "A no-win situation is the possibility every commander may face." (Star Trek II)
In
Starfleet Academy, the Federation tests potential officers by putting
them in a simulated situation that they cannot win. This is
done
to see how they react to the pressure and inevitable defeat.
Having just "failed" this unpassable test, a cadet asks Kirk
why
they are put through it. He says that a no-win situation is a
possibility every commander may face at some point (though Kirk himself
cheated his way out of it and won the "no-win" scenario).
In system administration, there are problems that will come your way that you simply can't fix. Maybe it's a system that's been hit by too many viruses, a Registry that's too corrupted to be sorted out, or hardware that just doesn't work. You can spend hours or days trying to fix a problem like this without ever really solving it. You have to know when you're facing a "no-win scenario" and cut your losses by walking away from the problem. That might mean wiping the system and reinstalling everything instead of spending hours correcting a series of problems, tossing out a piece of hardware that "ought to work" but somehow doesn't, or giving up on software that simply doesn't do what it's advertised to do.
In system administration, there are problems that will come your way that you simply can't fix. Maybe it's a system that's been hit by too many viruses, a Registry that's too corrupted to be sorted out, or hardware that just doesn't work. You can spend hours or days trying to fix a problem like this without ever really solving it. You have to know when you're facing a "no-win scenario" and cut your losses by walking away from the problem. That might mean wiping the system and reinstalling everything instead of spending hours correcting a series of problems, tossing out a piece of hardware that "ought to work" but somehow doesn't, or giving up on software that simply doesn't do what it's advertised to do.
3. "The needs of the many outweigh the needs of the few... or the one." (Star Trek II)
Spock
gave up his life at the end of Star Trek II to save the Enterprise and
her crew. When asked by Captain Kirk why he did it, Spock
replied
that the needs of the many outweighed the needs of the few, or the one.
In other words, Spock knew that by giving up his life he
could
save many others.
In system administration, you're probably not going to be faced with a "life or death" choice like this, but almost daily you're faced with situations where the needs of your end user community ("the many") dictate actions you ("the one") take. For example, you may find yourself at the office after hours, sacrificing your personal time in order to complete a software upgrade, patch a server, or otherwise do something that would inconvenience users if you tried to do it during the work day. Chances are, you're also probably "on call" to help those same users if they have problems late at night or on the weekend, and you're expected to help them. The needs of the many, in this case, outweigh your own needs.
In system administration, you're probably not going to be faced with a "life or death" choice like this, but almost daily you're faced with situations where the needs of your end user community ("the many") dictate actions you ("the one") take. For example, you may find yourself at the office after hours, sacrificing your personal time in order to complete a software upgrade, patch a server, or otherwise do something that would inconvenience users if you tried to do it during the work day. Chances are, you're also probably "on call" to help those same users if they have problems late at night or on the weekend, and you're expected to help them. The needs of the many, in this case, outweigh your own needs.
4. "Mr. Scott, have you always multiplied your repair estimates by a factor of four? Certainly, sir. How else can I keep my reputation as a miracle worker?" (Star Trek III)
Mr.
Scott admitted to Captain Kirk in Star Trek III that he had always
multiplied his repair estimates by a factor of four. This
gave
him the opportunity to take all the time he needed to solve a problem,
while still completing the task more quickly than the captain had
expected. As a result, he was seen as a miracle worker by
Captain
Kirk.
In system administration, you're often asked how long something is going to take. While I don't recommend multiplying your estimate by four, I do believe that you should always practice the principle of "underpromise and over-deliver" when dealing with others. A task that looks like it should be a one-hour job can easily become a 2-3 hour job if things go wrong, the system begins responding too slowly, an emergency arises that you need to address first, etc. If you tell someone something will take an hour and you aren't done two hours later, they're angry. But if you tell them it will take two hours and you're done in 90 minutes, you're a miracle worker. I'm not suggesting that you make a habit of lying, but rather that you give yourself a little breathing room to allow for things you might have forgotten, things that take longer than expected, or unexpected circumstances.
In system administration, you're often asked how long something is going to take. While I don't recommend multiplying your estimate by four, I do believe that you should always practice the principle of "underpromise and over-deliver" when dealing with others. A task that looks like it should be a one-hour job can easily become a 2-3 hour job if things go wrong, the system begins responding too slowly, an emergency arises that you need to address first, etc. If you tell someone something will take an hour and you aren't done two hours later, they're angry. But if you tell them it will take two hours and you're done in 90 minutes, you're a miracle worker. I'm not suggesting that you make a habit of lying, but rather that you give yourself a little breathing room to allow for things you might have forgotten, things that take longer than expected, or unexpected circumstances.
5. "The fancier the plumbing, the easier it is to stop up the drain." (Star Trek III)
In
Star Trek III, Captain Kirk and the crew of the Enterprise essentially
"stole" the ship in order to save Spock and Doctor McCoy. Mr.
Scott expected the Federation's newest, fastest, fanciest ship (the
Excelsior) to be given the task of pursuing the older, slower
Enterprise. He removed a handful of critical computer chips
from
the Excelsior's system while working on it, preventing the ship from
being able to give chase. When asked how he managed to
sabotage
the Excelsior in a way that they didn't detect, he replied that the
fancier the plumbing was, the easier it was to stop up the drain.
In other words, the systems on the Excelsior were so
complicated
that it was easy to screw them up.
System administrators often have several ways to deal with a situation. Some ways are simpler than others. You should always be wary of any solution that has too many potential "points of failure". While an elaborate Perl script might push out an urgent security patch to 10 systems simultaneously from the comfort of your desk chair, you could over-think the script and end up accidentally applying that patch to 100 systems you didn't want to apply it to. Sometimes it's better to keep things simple, because it can reduce the chance of failure or allow you to respond more quickly. Similarly, you can "over engineer" a solution to a problem and spend more time architecting a clever solution to something you could fix manually in a few minutes.
System administrators often have several ways to deal with a situation. Some ways are simpler than others. You should always be wary of any solution that has too many potential "points of failure". While an elaborate Perl script might push out an urgent security patch to 10 systems simultaneously from the comfort of your desk chair, you could over-think the script and end up accidentally applying that patch to 100 systems you didn't want to apply it to. Sometimes it's better to keep things simple, because it can reduce the chance of failure or allow you to respond more quickly. Similarly, you can "over engineer" a solution to a problem and spend more time architecting a clever solution to something you could fix manually in a few minutes.
6. "Sometimes the needs of the one outweigh the needs of the many." (Star Trek III)
When
asked why the crew of the Enterprise risked their lives and their
careers to save Spock in Star Trek III, Captain Kirk told him that
sometimes the needs of the one outweigh the needs of the many.
In
other words, Spock was their friend and they were willing to risk
themselves because he meant more to them than their lives or careers.
In systems administration tasks, sometimes you have to do things that make a lot of people very unhappy. For example, when pushing out security patches it is often necessary to reboot someone's PC to complete the installation. Naturally, if that person has documents open in Microsoft Office when you reboot them, they're not going to be happy about it. Multiply that over a large organization, and that simple reboot action can upset a lot of people. However, as a system administrator, you're responsible for protecting your network from malware. While "the many" users' needs may dictate that their PCs not be rebooted, your responsibility as "the one" who protects the network must outweigh theirs. This is not to say that you're more important, or that you should be fine with mid-day reboots as a matter of practice, but rather that there will be times in the job where you've got to risk the wrath of the users for a greater good.
In systems administration tasks, sometimes you have to do things that make a lot of people very unhappy. For example, when pushing out security patches it is often necessary to reboot someone's PC to complete the installation. Naturally, if that person has documents open in Microsoft Office when you reboot them, they're not going to be happy about it. Multiply that over a large organization, and that simple reboot action can upset a lot of people. However, as a system administrator, you're responsible for protecting your network from malware. While "the many" users' needs may dictate that their PCs not be rebooted, your responsibility as "the one" who protects the network must outweigh theirs. This is not to say that you're more important, or that you should be fine with mid-day reboots as a matter of practice, but rather that there will be times in the job where you've got to risk the wrath of the users for a greater good.
7. "Perhaps 'because it is there' is not sufficient reason for climbing a mountain." (Star Trek V)
In
Star Trek V, Captain Kirk is attempting to climb a mountain when he
slips and begins to fall off. Spock saves him at the last
second.
Later, Spock tells Kirk that perhaps "because it is there"
isn't
a good enough reason to risk your life climbing a mountain.
There are times in system administration where there is something that you can technically do, but which isn't a good idea when examined more closely. Maybe you have a script that could update all the company's computers with the latest Windows Service Pack overnight. You might even be tempted to do it, since your management's asking you about when you're going to get the job done. However, just because you can roll that Service Pack out in a heartbeat doesn't mean that's the right thing to do. You could come in the next morning and find out that the Service Pack you pushed out last night broke the salespeople's contact management software, the accountants' general ledger program, and the CEO's favorite screensaver. Suddenly, instead of being the miracle worker you thought you were going to be, you're on everyone's hit list. There are times in system administration when caution is needed, and experience will often help you know when climbing the proverbial mountain is a good idea and when it isn't.
There are times in system administration where there is something that you can technically do, but which isn't a good idea when examined more closely. Maybe you have a script that could update all the company's computers with the latest Windows Service Pack overnight. You might even be tempted to do it, since your management's asking you about when you're going to get the job done. However, just because you can roll that Service Pack out in a heartbeat doesn't mean that's the right thing to do. You could come in the next morning and find out that the Service Pack you pushed out last night broke the salespeople's contact management software, the accountants' general ledger program, and the CEO's favorite screensaver. Suddenly, instead of being the miracle worker you thought you were going to be, you're on everyone's hit list. There are times in system administration when caution is needed, and experience will often help you know when climbing the proverbial mountain is a good idea and when it isn't.
8. "An ancestor of mine maintained that if you eliminate the impossible, whatever remains, however improbable, must be the truth." (Star Trek VI)
In
Star Trek VI, when attempting to figure out who assassinated the
Klingon Chancelor, Spock began investigating his shipmates to identify
the assassins. When he came up with a seemingly incredible
solution, he uttered the famous line above (which is paraphrased from
Sherlock Holmes).
System administrators are often called upon to troubleshoot the strangest problems. Sometimes the solution to those problems can be counterintuitive, and may even sound "impossible". Here's a real-life example from my Windows 98 days. The company had just implemented a new application in the Marketing and Finance areas. For some reason, the laptop users in Marketing were getting a lot of "out of memory" errors when trying to use the application. They requested more RAM. We installed it. The out of memory errors became even more frequent. I started doing some research online and learned about a table kept by Windows 98 that was used to manage the available RAM. My research indicated that the table had a fixed size and under certain conditions could "fill up" on the user. One way you could free up space in this table was to remove some RAM. I tried this on the Marketing laptops and, sure enough, the "out of memory" errors went away. So, as impossible as it might seem, removing memory from the machines cleared up an "out of memory" error.
System administrators are often called upon to troubleshoot the strangest problems. Sometimes the solution to those problems can be counterintuitive, and may even sound "impossible". Here's a real-life example from my Windows 98 days. The company had just implemented a new application in the Marketing and Finance areas. For some reason, the laptop users in Marketing were getting a lot of "out of memory" errors when trying to use the application. They requested more RAM. We installed it. The out of memory errors became even more frequent. I started doing some research online and learned about a table kept by Windows 98 that was used to manage the available RAM. My research indicated that the table had a fixed size and under certain conditions could "fill up" on the user. One way you could free up space in this table was to remove some RAM. I tried this on the Marketing laptops and, sure enough, the "out of memory" errors went away. So, as impossible as it might seem, removing memory from the machines cleared up an "out of memory" error.
9. "People can be very frightened of change." (Star Trek VI)
In
Star Trek VI, the Klingons suffered an environmental disaster that
threatened to destroy their civilization. As a result, they
sought peace with the Federation, a change from their long-standing
policy of conflict and subjugation. In both the Federation
and
the Klingon Empire, there were people who had hated their rivals so
much, and for so long, that the prospect of peace between the two
governments was something they couldn't stomach. It was said
that
such people were frightened of change (the coming peace).
This is very true in the Information Technology (IT) world. When system administrators are about to make any kind of a signficant change, they're often required to document, justify, explain, and test the change well in advance of making it. Inevitably, you will eventually change something that causes a problem. Perhaps some Excel macros quit working after you upgrade Microsoft Office, or the new version of Internet Explorer doesn't work with an application used in Human Resources. Those unfortunate consequences tend to make organizations as a whole resistant to change, even fearful of it. As a system administrator, one of your responsibilities is to introduce change in a manner that allows you to control the potential negative impacts.
When we planned to roll out Windows XP Service Pack 2 (a while ago), I helped test as many of the applications used around the company as possible. I would try to identify if Firewall changes would be needed, if the application required one of the "compatibility mode" options, if it would need to be patched, etc. The point of all the hours I put in doing those things was to minimize the disruptive effects of upgrading to Windows XP Service Pack 2. By all accounts, our hard work paid off and there were few, if any, complaints once the software began rolling out across the organization.
This is very true in the Information Technology (IT) world. When system administrators are about to make any kind of a signficant change, they're often required to document, justify, explain, and test the change well in advance of making it. Inevitably, you will eventually change something that causes a problem. Perhaps some Excel macros quit working after you upgrade Microsoft Office, or the new version of Internet Explorer doesn't work with an application used in Human Resources. Those unfortunate consequences tend to make organizations as a whole resistant to change, even fearful of it. As a system administrator, one of your responsibilities is to introduce change in a manner that allows you to control the potential negative impacts.
When we planned to roll out Windows XP Service Pack 2 (a while ago), I helped test as many of the applications used around the company as possible. I would try to identify if Firewall changes would be needed, if the application required one of the "compatibility mode" options, if it would need to be patched, etc. The point of all the hours I put in doing those things was to minimize the disruptive effects of upgrading to Windows XP Service Pack 2. By all accounts, our hard work paid off and there were few, if any, complaints once the software began rolling out across the organization.
10. "One of the advantages of being a captain, Doctor, is being able to ask for advice without necessarily having to take it." (ST:TOS "Dagger of the Mind")
In the
original Star Trek series, Captain Kirk often sought the advice of his
senior officers. Even though he sought their advice on how to
deal with a problem, he did not always heed it.
Systems administrators typically work in teams. Members of teams typically have one or more areas of expertise, and other areas where their expertise may be less extensive. As a member of the team, you should always be willing to seek the advice of your teammates when you're about to do anything that might reflect negatively on the team if it goes wrong. Just because you ask for a teammate's advice, however, doesn't mean you have to follow it. Sometimes your own expertise or experience may "trump" the advice of a teammate, however well-intentioned and intelligent the advice might be. The key lies in knowing when to take advice and when to ignore it, which is something you learn with time and experience.
Systems administrators typically work in teams. Members of teams typically have one or more areas of expertise, and other areas where their expertise may be less extensive. As a member of the team, you should always be willing to seek the advice of your teammates when you're about to do anything that might reflect negatively on the team if it goes wrong. Just because you ask for a teammate's advice, however, doesn't mean you have to follow it. Sometimes your own expertise or experience may "trump" the advice of a teammate, however well-intentioned and intelligent the advice might be. The key lies in knowing when to take advice and when to ignore it, which is something you learn with time and experience.
11. "Power is danger." (ST:TOS "Balance of Terror")
A
commonly uttered security mantra is that you should give users only the
amount of administrative ability necessary for them to do their jobs,
and no more. If users don't have a business need for
administrator access to their systems, they shouldn't have it.
In
this way, if those same users introduce malware to your network via an
infected floppy, CD, USB key, etc., that malware will have a hard time
spreading. Having no administrator access will also prevent
them
from installing unauthorized or pirated software, shutting off their
computer's firewall, or doing other things that could compromise the
security and stability of your network.
Similarly, as a system administrator you should always be careful and deliberate with your actions when you're using administrator permission on a machine. Don't do indescriminate web browsing with the administrator account. Don't run untested scripts against lots of end user machines. Don't delete files you aren't sure about. In short, recognize that your "godlike" powers over the computer make you dangerous, and always use those powers sparingly and carefully.
Similarly, as a system administrator you should always be careful and deliberate with your actions when you're using administrator permission on a machine. Don't do indescriminate web browsing with the administrator account. Don't run untested scripts against lots of end user machines. Don't delete files you aren't sure about. In short, recognize that your "godlike" powers over the computer make you dangerous, and always use those powers sparingly and carefully.
12. "Leave bigotry in your quarters; there's no room for it on the bridge." (ST:TOS "Balance of Terror")
System
administrators tend to be the kind of people who like to tinker with
things. Even though we may be Mac administrators, we dabble
in
Windows or Linux. If we're Linux administrators, we can't
resist
the urge to fiddle with a script on OS X or a batch file on Windows.
Because we have a lot of experience, we can sometimes become
opinionated about technology, to the point of bigotry. In a
corporate setting, this kind of bigotry can be suicidal. If
your
response to every Windows problem you're asked to resolve is to launch
into a missive about how this wouldn't be a problem on the Mac, you're
in the wrong job. Unless they happen to ask for them, users
don't
want your opinions about the technology they're using. Most
of
them could care less whether they're using Windows, OS X, Linux, or
something else. They just want to do their jobs, and they
need
you to fix the problem that's keeping them from working. You
may
have a long list of reasons why the company should dump Windows and
move to Linux or OS X. They might be very intelligent, objective, and
thoughtful reasons. But if you're being paid to administer
Windows, you should keep those opinions to yourself unless asked for
them. You'll just create unrest and friction with your co-workers, and
that doesn't help anyone.
13. "The more complex the mind, the greater the need for the simplicity of play." (ST:TOS "Shore Leave")
Most
people adorn their offices with a few well-chosen artifacts.
Perhaps they're pictures of loved ones, awards they've won,
or
souvenirs from their travels. System administrators have
those
things too, but they also tend to like little toys. For
example,
I've often got a netbook, an MP3 player, and some other gizmo keeping
me company. They might be expensive gadgets to other people,
but
they're fun toys to me, and it helps me to reduce my stress to play
around with
them occasionally... such as on my lunch hour. Systems
administrators tend to be fun, playful, and funny people (once you get
to know them). The complex web of information we have to
master
and use on a daily basis tends to make us seek out "fun" when we're not
working or need a break.
14. "Insufficient facts always invite danger." (ST:TOS "Space Seed")
In
the original Star Trek, Captain Kirk freed Khan Noonien Singh and his
crew from an extended hibernation. Khan and his crew were
evasive
about who they were and what they were doing on the ship they were
rescued from. Both Spock and Kirk did their best to extract
information from them, but got very little. Kirk noticed that
Spock seemed uncomfortable with their new guests. When asked
why,
he explained that they knew little about them, and that this lack of
knowledge could be dangerous. Later, Khan and his crew
attempted
to take control of the Enterprise. Spock was right not to
trust
them.
System administrators who are willing to jump in and start working with something they know little about often learn through (bad) experience to become more cautious. In handling security patches, for instance, I'm very careful. When a new patch comes in, I have no way of knowing if that patch will break a critical business system, prevent systems from booting up, or force a reboot in the middle of the CEO's presentation to the executive board. Before I release the patch to anyone else, I try it on my own system first to see how it behaves. I then try it on my teammates and nearby co-workers. If it doesn't cause a problem for them, I begin slowly fanning it out to the rest of the company. Once I learn that the patch seems harmless I will then allow it to make its way on to large numbers of computers. I make every effort to learn as much as I can about the patch before letting it "run loose" on the network.
System administrators who are willing to jump in and start working with something they know little about often learn through (bad) experience to become more cautious. In handling security patches, for instance, I'm very careful. When a new patch comes in, I have no way of knowing if that patch will break a critical business system, prevent systems from booting up, or force a reboot in the middle of the CEO's presentation to the executive board. Before I release the patch to anyone else, I try it on my own system first to see how it behaves. I then try it on my teammates and nearby co-workers. If it doesn't cause a problem for them, I begin slowly fanning it out to the rest of the company. Once I learn that the patch seems harmless I will then allow it to make its way on to large numbers of computers. I make every effort to learn as much as I can about the patch before letting it "run loose" on the network.
15. "Either one of us, by himself, is expendable. Both of us are not." (ST:TOS "The Devil in the Dark")
It's
not uncommon in system administration for there to be one person who
handles a specific task, with another person serving as backup to that
person. The logic is to ensure that if the primary person
gets
sick, goes on vacation, takes a job elsewhere, or is hit by a bus, the
team can continue to do the things it is responsible for.
It's a
bad idea for the primary and the backup to be out of the office at the
same time, and should be avoided if at all possible.
Inevitably,
the day you're both out of the office there will be a major crisis in
your area of expertise, and no one there who can resolve the problem.
16. "If I can have honesty, it's easier to overlook mistakes." (ST:TOS "Space Seed")
Sooner
or later, you're going to make a mistake. Maybe you
accidentally
deleted some critical files from a server. Maybe you meant to
adjust the firewall settings and ended up turning it off. It
might be something relatively minor, or heart-stoppingly major.
Whatever mistake you make, be willing to own up to it.
There's nothing to be gained by lying to your teammates or
management to cover up a mistake. If you own up to your
mistakes,
people will respect and trust you. If you lie about them,
they
soon realize they can't rely on you and begin to resent you for the
time they spend uncovering the truth. Demand honesty from
your coworkers, but deliver it in return.
17. "No one can guarantee the actions of another." (ST:TOS "Day of the Dove")
As
part of system administration, or indeed any job, it can be necessary
to make assumptions about how people will react to something and
predict how they'll deal with it. But just because a
particular
reaction seems logical, reasonable, and expected, don't assume everyone
will do it. Always make allowances in your plans, your
scripts,
and your procedures for your end users to do the illogical, unexpected,
and "wrong thing at the wrong time". Build in the safeguards
you
can to prevent as many problems as you reasonably can, but realize that
no matter how hard you try, there's likely to be someone who does
something you didn't plan for.
