'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.
