The Lone Sysadmin

In the last month I’ve added quite a few blogs to my reading list. One new one is “Movin’ Meat,” written by an ER doctor out of the Pacific Northwest. Besides just being interesting, some of his blog posts support my theory that IT folks can often learn things from people in other fields. The post from June 25, 2010, part four of his “Advice for Interns,” is one of these cases. When you read it (link is at the end because I want to get to my actual point before you leave to read it), I think substituting “customer/system” for “patient” in his list works nicely.

My real point is this: one thing in his list really stood out for me. It’s something that seems really obvious when it’s said, but also done wrong a lot:

“Determine the rate-limiting step and make it priority #1 in the work-up”

Figuring out what the slowest step in a project is going to be and getting to work on it right away is often key to getting a project done in a timely fashion. Especially if a large chunk of that time will be waiting for something. When you know it’s going to take six weeks for a request to make it through your purchasing department you should start that right away, especially since all you’ll be doing is waiting.

As kids we were told by our teachers to read all the instructions first, then start working on whatever we were doing. Determining the rate-limiting steps is the same sort of thing. By taking a few minutes at the beginning to look at the whole project first, rather than just starting on step #1 and going one by one until you’re done, you can often optimize things so that the longest parts of the project are done in parallel with the rest.

Links:

- Movin’ Meat: Friday Flashback – Advice for Interns Part Four

It’s an interesting thing, this life. You’re born, you live, you die. And along the way there are certain epochs, milestones, that mark the journey. Early on you don’t remember these things, like learning to walk, or, just as crucial, going to the bathroom on your own. Sometimes you do remember them, like your first kiss, or holding your own offspring for the first time. Sometimes the events are obvious milestones, sometimes it takes years before you realize they were signs along the road.

Sometimes these milestones are like the forbidden fruit in the garden of Eden, though. As much as you know they’re a part of life you’d like to put them back, take a do-over, and go back to blissful ignorance. Like the day you learn, for sure, 100%, that your parents aren’t immortal. Now, don’t confuse this with learning that your parents are human. At some point we all figure out that parents are, to some degree, human, making mistakes and being grumpy and irrational and all that. But at some point it’ll occur to you that your parents won’t always be around, and that’s a huge thought all on its own.

We learned of my father’s stomach cancer late in October 2000. Six months later he was gone. I was in denial most of the time he was dying, that it could be happening at all, that it was possible for it to happen to someone I cared about. It took me years afterward to wrap my head around the idea that he was gone. In fact, if you go with the five stages of grief, I was stuck at “anger” for quite a number of years. But I still had my mom, and while I couldn’t ask her for advice on replumbing my house she kept the immortal flame of parenthood burning in all the other good ways.

It’s been a while since I’ve written anything here. Not coincidentally, it’s been about that same amount of time since I was reminded, again, that my parents are not immortal. This time, a brain tumor. Possibly operable, likely quite treatable, but still a shock.[0] Doubly so because this is a threat to the last bastion of the old ways, the homestead, and the status quo of my family. My father’s death, and the ensuing nine years, have given me experience to deal with this sort of thing, but it’s still been this inedible lump sitting there for me to digest. And while I’ve been nibbling away at it I lost all my will to write, to do link posts with snarky comments, or to even update Facebook and Twitter. In fact, I missed my annual tribute to my father on his birthday, recycling some of his own snarky comments. I really feel bad about that, but I suspect he’d understand.

I don’t write all this fishing for sympathy or anything. I’m not. While it sucks, we all eventually go through it, and if anything talking about it helps me sort some of it out. This post is more of an apology for disappearing and a pledge that, since I’ve found some of my words again, I’ll post occasionally on the topic. After all, this blog is about technology, and a hell of a lot of it is being used on my mom, by no less than brain surgeons. Most importantly, though, this post is a plea, in the sage words of a billboard along U.S. Highway 151 between Dubuque and Madison: call your mom. I’m sure she’d like to hear from you.

It sure is an interesting thing, this life.

———————

[0] Anaplastic astrocytoma. If you Google it realize that while astrocytomas are not rare catching them in this stage (anaplastic, or WHO Grade III) is. They’re usually found when smaller or larger. As such, there isn’t a ton of data about prognoses or treatment. In fact, it was only a few years ago that they started using radiation AND chemotherapy together on these tumors, and there isn’t a lot of published data on the survival rates now, mainly because those people are still alive. Can’t argue with that. :)

Everything Sysadmin has an interesting post that ends up talking about the whole “underpromise and overdeliver” strategy.

I’ve always had a rocky relationship with that strategy, mainly because I really think people just need to stop acting like they’re heroes on Star Trek and get better at time estimation.

Certainly when there’s doubt about how long something will take it’s better to overestimate, because that way the promises your customers made to their customers, coworkers, or boss aren’t lies because of you. It also helps to give yourself a little breathing room, so that if something urgent comes up you can deal with that and still deliver. The trick is just not to overdo it. People aren’t dumb, and consistent “underpromising” to the same set of people means that they will start expecting it. Do you really want people disappointed that it actually took you two days to do something when you said it would take two days? Of course not. You also don’t want them heading to your boss and complaining about how long something might take, just to discover that you weren’t completely honest with them at other times (or now). What are you, lazy? Exactly how are you spending that extra time?

In my opinion it is better to make consistently accurate time estimates and follow through on them. And, if you discover that your estimates might not be right, be honest about it, but also figure out what made you wrong and remember it next time.

One of my favorite tricks lately to make people understand how serious I am about things is to get them to sign a form.

You want to run your server without backups? I don’t recommend it at all, but I’ll do whatever you say. Just sign this form acknowledging that you know the risks, you know you could lose all your data at any time for any reason (including things I might do), and regardless of cause you don’t hold me accountable for anything.

You want to let your employee take a machine out of the building without following our procedures for wiping the drives? We have a policy against that and it’s a terrible idea, but no big deal. Here’s the form to sign saying that you take complete responsibility for all the data, sensitive or otherwise, on that machine. Why do you have to sign this? Well, this way when the data on that machine leaks out and causes identity theft, etc. I have a “get out of jail free” card. Yes, jail.

The thing is, nobody ever wants to sign these forms and put their name, in writing, on a really bad idea.

Whose fault is it?

It doesn’t matter. Get the problem fixed.

You can figure out who is at fault when you’re discussing how to prevent the problem in the future.

Seth Godin has an interesting post today about stress. His perspective is as a marketer, but his point is universal: people are stressed out almost all the time.

For us system administrators, do we ever just ask ourselves if something we’re doing, a system we’re building, even a tool we’re implementing for ourselves will create or reduce stress?

Why not?

I know some of the tools I use cause more stress than if I didn’t have them, to save very small amounts of time, gather almost useless information, or achieve some political goal. What if we could plot user stress versus time saved? Would we choose our tools, our applications, our systems differently?

Technical presentations are very Darwinian. Do a good one and you get invited to do another. Do one badly and you won’t get any more practice. I’ve survived a number of them now, likely because the audiences got such good sleep during the talk that they tell their friends. :-) Joking aside, I think these six things I do for each presentation have helped a lot. I share them with you.

1. Know your audience and talk at their level.

Before I give a presentation I ask the folks who are coordinating the event about the people I’ll be talking to. Are they advanced users or newbies? Windows, Mac, or UNIX people? Application developers or system administrators? All these help me get a feel for what I need to talk about, and how to talk about it. In a presentation about virtualization will I need to explain all the concepts from the ground up, or can I skip to the advanced topics?

If you are giving a presentation to a general audience you have to aim for the lowest common denominator. However, if you are giving a talk that is billed as advanced, treat your audience that way. Treating advanced users like beginners and vice versa is a great way to lose your audience.

2. The 10/20/30 rule is key.

I am a huge fan of the Guy Kawasaki 10/20/30 rule: 10 slides, 20 minutes, no less than a 30 point font. Keep things short, easy to read, and remember that people are there to hear you talk, not to read your slides. Think of your slides as an outline: a few words, graphics, and photos to help people understand what you’re talking about. A slide is not a bunch of notes, it’s the illustration to a story you’re telling.

I keep any notes separate so I can publish them after the presentation, but also so the audience cannot see them during the presentation. If I talk about code samples, scripts, or output from command-line utilities I’ll put short, easy-to-read blurbs in the slides but publish whole samples or URLs in my notes afterwards.

I go over 10 slides a lot of times because I always opt for bigger, simpler, more readable slides. In that regard I always make graphs and graphics their own whole slide. Since a graph’s legend often gets strange when it is 30 points I skip that and put simple labels in the graph itself. I always avoid color combinations of red & green or blue & yellow for any color blind folks.

3. Pre-authenticate & set everything up in advance.

Is part of your presentation going to be a demo, or require authenticating? Get logged in and set up ahead of time. You’ll save time during the presentation as well as confirm that whatever you are demoing can be connected to (and if you can’t connect someone else can work on the fix while you start talking). More importantly, you’ll also lessen the risk of doing something dumb while the audience watches, like typing your password in the username field. I hate when I do that, and it’s always because I’m answering a question and logging in at the same time.

4. Create another user on your laptop.

I use my laptop for a lot of different things. I don’t want to have to worry about what is in my browser cache, or sitting on my desktop (like a proposal for a client or something). To help this I created a second user on my laptop just for presentations. I set the background to black and made sure it gets its own profile in Firefox and iTunes.

5. Get a good presentation clicker.

I use a Logitech Presenter and it’s easily the coolest device for doing a presentation. First, it’s RF-based so I can wander around. I hate standing behind a boring desk or lectern just so I can advance my slides. Second, it has a timer in it that vibrates, so you know if you need to speed up or slow down. Last, it has a laser pointer. A picture may be worth a thousand words but being able to point at the screen to explain something, especially when answering questions during demos, is priceless.

6. If you feel like you’re losing the audience stop and take some questions.

Stopping for a short Q&A part way through is a great way to wake people up and find out if you’re above or below their technical level. If nobody asks any questions it might signal that they’re lost, the presentation is too basic, or they’re asleep. In my experience if you’ve got good content someone will ask a question and you’ll know where you stand. At the very least a short pause will give you a brief chance to take a deep breath, drink some water, and regroup.

There are lots of other great resources out there. My list here is no substitute for some of the great tutorials, checklists, and tips from people that are professional presenters. Here are a few I really like:

• Garr Reynolds’ Presentation Tips. He also runs the blog “Presentation Zen” which I read. I especially like his analysis of Steve Jobs’ presentations.
• In addition to the aforementioned 10/20/30 rule, Guy Kawasaki has a lot of good material in his blog. I really like his tips on “How to Get a Standing Ovation” and “The Art of Schmoozing.”
• Lifehacker often has articles about presentations. A good one is their recent “Rock Your Presentation with the Right Tools and Apps.” Just don’t forget that like everything else in life, the more complex your presentation gets the more likely it is that something will go wrong.

Some reasons I think lying on your resumé is a bad idea.

People, in general, aren’t good enough at lying to get all the details right.

One little lie ends up needing a whole network of lies to support it. Especially during an interview. You said that you’ve run large mail servers at your previous job. What software did you use? What did you do about spam? Viruses? If you lie about your experience you need to lie about all the details of that experience, too. That gets tricky, because it all has to mesh perfectly.

Even if you can get all the details right you’ll act funny or seem like you’re lying when people ask you about these things. People, in general, are not good enough at lying to mask the “I’m lying, please bust me” body language. You know what? Humans are really good at reading body language, even subconsciously.

Your prospective employer actually knows the truth, or knows someone who knows the truth.

A lot of people working in IT know each other. We talk to each other, run into each other at conferences, and go drink beer together. A lot of times we’ll have worked together at companies, done consulting together, or even have the same hobbies. And once in a while the topic turns to “hey, a guy you work with is applying for one of our open positions. What do you think of them?”

I will never hold the desire to go find a better job against someone, sabotage their chances if the person if I think they’re an asset to our organization, or tell anybody at their current employer anything. I’ve been in that position and it sucks, and as a result I am often a big advocate for the person. Everybody should have the option to go somewhere else if they don’t like quite what they’re doing now.

It gets tough, though, when in the course of conversation it is determined that the person is lying on their resume. In one memorable case it was someone taking credit for something I had done, and the friend that was asking me knew I’d been the guy that did that work. Now, I don’t know all the legalities of hiring someone (that’s what HR is for) but I do know it gets a lot harder when you’ve lied to someone who knows the truth already.

You don’t know who will read your resume. It could be a former coworker, a friend of your boss, or a complete stranger. You don’t know what they’ll know about you already, or what they can find out. So keep the fiction to a minimum.

A background check will show information that conflicts with your story.

Did you fudge dates, overstate your education on your resume, or try to hide something in your past? If it is a matter of public record it is easy to check, and it is better if you explain it up front than appear like you’re trying to hide it. Remember that during a hiring process people are asking themselves “would this person be a good asset to the team?” If people think you’re hiding things you aren’t going to get hired. Instead, find a truthful way to explain it that makes you look good, or at least indicate you learned something.

Heck, even just making up a story about falling in love with a traveling nurse and moving with her to Hawaii to surf for six months is a better way to go. Of course, that might get you in trouble, too, should you run into someone who lived in Hawaii…

At some point you’ll have to do what you claimed you can do.

If an employer is asking questions about things on you’re resume it is probably because you’ll have to do them as part of your job. If that’s the case, and you lied about being able to do something, people will know that right away. You might be able to get away with it if it is simple and can be looked up on the web, but if you are hired to do an HP OpenView implementation and you haven’t ever used OpenView you are probably in trouble.

The big downside to this, aside from getting fired, is then having to explain all of this to the next interview committee.

You just don’t need to lie.

Lying is a house of cards that, more often than not, comes tumbling down. Even if it doesn’t come tumbling down right away there is always the chance that someone in the future will discover the lie. With all the open source software out there, with freely-available server operating systems like Linux, FreeBSD, or even Solaris, and with free developer access to software like Oracle, there is no reason you can’t put a little experience behind your claims.

Besides, training is easy. Most employers know that they can always fill a technical knowledge gap with a book or a training course. Hiring someone who has the right mindset and will fit into the company is the real challenge. So instead of lying be truthful, be honest, be confident, be that person they want to hire, even if you aren’t perfect. Nobody is.