Thomas Limoncelli - Time Management for System Administrators

—David N. Blank-Edelman

Preface

" Time Management for System Administrators ?"

Uh-huh.

"You mean, like, how to use PDAs, vCal, calendar servers, and stuff?"

No, not at all. System administrators should be able to figure those things out without needing a book.

"So why shouldn't we just buy one of the other 10 zillion time management books out on the market?"

Because they suck. Well, they don't suck . They just don't speak to "us." They speak to some generic person you and I can't relate to. I'm a geek. A system administrator. A networking wonk. My home life looks a lot like my work life—you should see the killer server I've set up at home. Once I've finished tweaking it, I'm going to set up the same thing at work. Very few occupations are like that. Brain surgeons don't come home excited about trying a new technique on their cat, hoping that it works so they can try it on patients.

(Shoos cat out of the room.) "I'm not letting you near my cat anymore."

Listen, what I'm trying to say is that system administration is not a job. It's a lifestyle. We need time management books that speak to our lifestyle, in our own words, and solve our problems.

"Lifestyle?"

Lifestyle, workstyle, whatever. No other job pulls people in so many directions at once. Users interrupt us constantly with requests, preventing us from getting anything done. Computers have their own needs that pull is in many directions. Our managers want us to get long-term projects done, but they flood us with requests for quick fixes that prevent us from getting to those long-term projects!

In our field, good mentors are rare. If our boss is technical, he can mentor us on technical issues but not on time management. If our boss is nontechnical, he can't mentor us because he "lacks clue" about the demands of our job.

"And what makes you so qualified?"

Well, first of all, a long time ago I took a bunch of time management training and realized that 80 percent of what was taught didn't apply to SAs. But I retained the 20 percent that did. Then, over the years, I've refined the techniques, developed a lot of my own, and even started teaching seminars on the topic. This book captures what's in that training.

"Well, you still haven't convinced me."

Let me give you an example. You know the difference between an interpreted language and a compiled language, right?

"Sure! Interpreted languages are slower because they have to reinterpret each line of code every time they see it. Compiled languages spend a lot of time up front processing the entire program and turning it into machine language, which then can run much more quickly than the interpreted counterpart."

Exactly.

"So you want me to compile my life?"

That would be cool, but no. But we can learn a lot from compilers—spend a little time up front so you don't have to repeat a process multiple times later. For example, at a previous site, it was my job to change the backup tapes. This was before inexpensive tape jukeboxes eliminated a lot of that work. We had three main servers in the computer room, plus eight small servers scattered around the building. A tape didn't need to be changed if there was "a lot of room" left, but it took a long time and a lot of guesswork to predict if I could skip changing the tape for that server. If I misjudged how much free tape would be needed to complete tomorrow's backups, some of them would fail. Failure was bad—I didn't want that! The process really stressed me out. Then I realized that I was acting like an interpreter revisiting every step each day, stressing out over each detail. I needed to do the analysis once and stick with those decisions.

The first decision I made was "tape is cheap, my time isn't." So, rather than try to optimize every bit of tape, I was going to waste a little tape and gain a lot of time.

The next decision I made was "don't sweat the small stuff." The data in those eight small servers scattered around the complex were a lot less important than the data in the computer room. Yet, I was stressing out about them. I had to stop caring (and stressing) about the things that didn't matter. SAs have trouble setting priorities.

I decided I needed to do analysis once and reuse it every day. I needed to be like a compiled language instead of an interpreted language: precompile a decision and use it over and over. My analysis was that the servers in the computer room needed to be changed almost every day. Therefore, I would change them every day without doing any analysis of how much space was left on the tapes. If I wasted a little tape, I wasn't going to care.

However, the smaller, scattered servers rarely needed changing. I would change those tapes every Monday, plus the day after any of the backups failed due to a full tape.

"So you decided that failure was OK."

Yes. I stopped worrying about perfection where it didn't matter. Perfectionism is often overkill and a real time waster.

The inventors of the Internet were brilliant at this. They realized they'd never get anywhere if they waited for the underlying communication links to be perfect, and so they developed protocols that worked around imperfections.

"But my boss expects perfection."

Actually, your boss has priorities, too, and she realizes that tradeoffs must be made. We'll talk about managing your boss in Chapter 8.

"Please tell me that all your advice there won't relate to compilers and interpreters."

Oh, I promise. Not everything will be an analogy. However, you will see some important themes:

Keep all your time-management stuff in one place.

Use your brain for what you are working on right now, and use external storage for everything else.

Develop routines for things that happen periodically.

Pre-compute decisions by developing habits and mantras.

Maintain focus during project time.

Improve your social life by applying these tools outside of work, too.

"Are you going to work that into some cute acronym?"

I promise I won't. What's important to know for now is that I have constructed each chapter to group together particular problem areas for system administrators. They build on each other.

Preface

An introduction to the book and the topics covered in it. You're reading this right now.Chapter 1, Time Management Principles

What makes us so special? It's mostly the volume of interruptions we get and the huge number of simultaneous projects we're asked to do. But there's more to it than that. This chapter introduces the principles that will be used throughout the rest of the book.Chapter 2, Focus Versus Interruptions

This chapter teaches you how to deal with an interrupting customer without sounding like a jerk. You won't be able to accomplish much without managing your interruptions.Chapter 3, Routines

This chapter shows you how to turn chaos into routine. Our jobs are full of chaos—anything we can turn into a routine means a little less chaos and a lot less stress. When we develop routines for our tasks, they become habits and we're less likely to forget them.Chapter 4, The Cycle System

This chapter introduces you to my "Cycle System," which is a way to manage your to do list. It teaches you how to juggle many demands without dropping anything. Even if you have 100 hours of tasks on your plate, you can manage them all and still work only 8 hours a day.Chapter 5, The Cycle System: To Do Lists and Schedules

This chapter focuses upon the actual day-to-day work of putting The Cycle System into practice, creating your schedule and to do list. It also gives you tips and strategies for dealing with too much work.Chapter 6, The Cycle System: Calendar Management

SAs have lots of meetings and appointments. If we can manage them better, not only do we no longer miss appointments, but we can schedule more fun into our social lives. In this chapter, I extend The Cycle System to include our calendar.Chapter 7, The Cycle System: Life Goals