A Wandering Mind

I’ve blogged a bit over the life of this site about my use of a life-management framework called GTD and how profoundly it’s affected my life. Sometimes when I talk to people about it, a common response is “but why would I want to spend so much time keeping track of what I have to do instead of just doing it?”

The answer is that having everything in those magic lists gives you a kind of ultimate peace of mind that’s, well, hard to describe for those who haven’t experienced it. Now I know that makes it sounds like some kind of hippy-ish drug-induced trip; but really, the simple confidence of knowing all your responsibilities (“agreements” as David Allen, author of GTD calls them) will be there waiting for you when you come back is nothing short of priceless.

As I was reading my blogs today I found a great entry from fellow GTD’er and SQL community member Brent Ozar (blog | twitter). I think the passage below beautifully describes this “mind like water” (another David Allen phrase) state:

At around 5PM, when I’m not on the road, i leave my home office and my tasks behind.  I walk Ernie (our dog), get the house ready for Erika’s return from work, and leave the workday problems behind.  I’ll still check email from my ozone when we’re not doing anything, and I’ll respond to quick questions, but I won’t do work.

And I won’t care.

I won’t stress out about things I have coming tomorrow, won’t get worried about what a client’s server is doing, won’t work late trying to “get ahead” – because there’s no such thing.  As a knowledge worker, I’m going to be behind for the rest of my life.  The better I am at accomplishing stuff, the more work people will give me.  At 5PM, I have to change contexts because I won’t ever be caught up in my home life either.

via GTD: Why Things Have Been Quiet Around Here | Brent Ozar – Too Much Information.

Thanks for helping spread the word Brent. It’s always great to see others having the same experience and speaking eloquently about it to the world.

Now if you’ll excuse me, I’ve been neglecting that @home list of mine.

It’s that time again, when SQL bloggers from all over join forces to blog for a common theme. That’s right: T-SQL Tuesday!

Background: T-SQL Tuesday is the brainchild of Adam Machanic (Blog|Twitter) and is described as “the SQL Server blogosphere’s first recurring, revolving blog party. The idea is simple: Each month a blog will host the party, and about a week before the second Tuesday of the month a theme will be posted. Any blogger that wishes to participate is invited to write a post on the chosen topic.”

This month’s theme: “Beach Time”, hosted by Jason Brimhall (blog | twitter). Basically, we’re being asked to write about “What do you do prior to ‘Beach Time’ to ensure that the beach time will not involve work.”

This is actually a good topic for me, as last month I took the longest consecutive vacation of my working life at two full weeks. It was challenging to get everything in order before leaving, and I did get a phone call once (ironically on the first day off), but all in all my team did great work and kept all my projects in good order while I was gone (with one minor exception, but that was at least partially my fault as you’ll see).

So how did I pull this extended absence off?

I documented the status of all my projects, including what was outstanding from others and what needed to be done while I was gone.

We have a wonderful SharePoint site where we keep all our projects listed and have detailed status notes on all of them. This means that if any one of us ever had to suddenly be out for an extended period of time, someone else could just glance over their list and pick up where they left off.

This reminds me strongly of one of my GTD habits: keep things in lists and not in your head. By forcing us (and yes, I do sometimes neglect it a little, hence my first (but only) phone call) to keep this updated, we don’t have to rely on our memory to keep track of what’s on our plates.

I made sure my runbooks were up to date.

Just before I left, I closed out a major phase of a project to build a massive data warehouse containing PerfMon data for all the SQL servers we support. It’s a complex system with multiple inputs and moving pieces. Because of this, I made sure the write up a thorough document detailing the ins and outs of the system, including architecture and troubleshooting steps. No way was I being called when I was away because this thing broke.

Now as it turns out, the system did fail while I was gone, but was unnoticed! And while my teammates sheepishly admitted that they missed the alerts and should have at least dug into them a little further, I also took responsibility for not ensuring they (the alerts) were a) urgent enough to be noticed, b) clear enough to tell the reader where to get more information.

Once I was gone, I made damn sure I was very hard to get in touch with.

While I am the first to admit I have a pretty bad addiction to my Crackberry, when I’m on paid vacation I strictly enforce the “no e-mail rule”. I go so far as to actually turn off the mail synchronization on my phone and make it clear in my out of office that I will not be checking my mail at any time during my absence. Only my teammates know my phone number and they are told they can call me if absolutely necessary, but that I may not immediately respond. While I do tend to take my work laptop, that’s only because it’s also my playground for testing SQL related things, and I do not connect to the office.

Being selfish? Maybe a little, but hey, it’s my vacation time and I’m damn well going to enjoy it and not waste it working. That being said, on this last vacation I did end up working for about 3 hours, but that was wholly my fault for not properly documenting something before I left.

I have a great, strong team around me.

While this may not have much directly to do with me, I consider it a crucial factor in vacation success. If your team can’t hold down the fort, even given good documentation, then you’re pretty much sunk. I’ve been in those situations before, and let’s be honest: it sucks. There’s few things in the world more maddening than getting called on vacation because “Mr. So and So is here and he says you told him X, but that doesn’t make sense?”, especially when your conversations with Mr. So and So are explicitly detailed in writing, and readily accessible to your teammates. That’s a real example by the way, from my time as a retail store manager. Let’s just say that individual got politely redirected to where I kept a log of all my conversations, along with a gentle reminder that I was not to be disturbed. Thankfully, this is not the case where I am now, and I am eternally grateful for the hard work and dedication of my fellow DBAs.

I think pretty much everyone who knows me would say that one of my defining characteristics is my singular focus. Once I put my mind to solving some problem or accomplishing something, I damn well poke at it until it’s finished. Now, in many cases this trait has served me quite well; it’s what allowed me to learn programming and SQL Server with no formal training or even so much as a seminar (thank you Internet and amazon.com), and why I consider myself an above average problem solver.

One of my favorite teachers once told me that at times I “missed the forest for the trees.” He went on to explain that at times my work tended to find it’s conclusion too early, then ignore all other points of view. Narrow focus is often good in writing, but not when it excludes other angles of approach completely.

The same could be said of how I function as a DBA. Take a project I am working on: the design and build of an enterprise data warehouse, storing performance data for every SQL server in our environment. It’s been fascinating and a tremendous learning experience, but also at time a real challenge.

Early on one of the requirements was to collect performance data on a second-by-second basis, essentially forming a “baseline” of data to review and use for later comparison. Now being the aggressive lad I am, I expanded upon this as follows: the warehouse should now store second-by-sec0nd data for every server at all times, with a retention of 2 years. Yes, you read that correctly. Two years of data, with points at every second for fifty plus servers. That’s a lot of data folks (think 1,800 rows per minute, per server, or around 129,600,000 rows per day).

So, I set out to prove it could be done. Here’s a brief list of some of the challenges I’ve hit along the way:

• PerfMon’s built-in direct-to-SQL functionality scales downright awfully. The structure of the tables would make any decent DBA shudder (the primary key of the main, and largest, table has a GUID as it’s first column, as an example), the use of bulk inserts (not using MS’s own optimization schemes), and statistics issues to name a few.
• After abandoning that approach we are going with dumping the performance data into flat files, which are then picked up by a SSIS package at intervals, which required a custom script component acting as a data flow source. This is due to the fact that PerfMon records its data in .csv files with a dynamic and unpredictable number and order of columns. Custom logic had to be written to essentially perform a reverse pivot of the data into a more normalized form.
• Even fully optimized, the package simply could not keep up with the incoming flood of files. They would eventually pile up and consume disk space, not to mention having stale data in the warehouse. This was attacked by custom coding a script task in a parent SSIS package that would dynamically spawn multiple threads running a child package to import one file each, up to ten at once (I’m shocked by the way that this isn’t either a standard part of SSIS or that a suitable aftermarket component could not be found). Naturally this promptly brought the server to its knees, being a poor little VM with only four CPUs. But the files did import faster!

Now, throughout all of this, keep in mind that I was going far beyond the original and still stated requirements given to me. Why? Because dammit, I was out to prove that such a huge amount of data could be handled by a little VM running SQL 2008 Standard Edition.

Well, today I cried Uncle. In an effort to actually get some usable data into the system, we’re (read, I’m) reducing our goals to only baselining one server at a time, with others collecting a mere four data points per minute. And damn, I am disappointed we haven’t gotten there yet. But you can believe I’m not giving up. But at the same time, I look back and consider all the time I spent chasing what, pride?

My old teacher was right: I need to stop staring at the one big tree in front of me and enjoy the woods a bit more. Luckily, there’s this little methodology I follow called GTD, and something tells me it’s going to be very useful in this upward movement of focus.

More often than I’d like, I get e-mails from various folks late in the evening (the record is about 11pm) somewhere along the line of: “This is really urgent and needs to be done EOD today.” Now, I have to assume that either one of two things is going on here:

1. Their End Of Day is different than mine. Not in the time zone sense (though I do occasionally deal with folks offshore), but just in the sense of they work hours beyond the normal workday.
2. They’re being clever and trying to be the first mail in my inbox the next morning.

Now in the case of #1, obviously they’re not readers of my blog. Otherwise, they’d see my prior post where I was pretty clear about my policy with regards to working after hours: high value and emergency work only. That’s not to say there have not been some cases where the work met one or both of those criteria; just merely that most of the time it doesn’t.

In the case of #2, for one I’d laugh because with the sheer volume of e-mail I get, no matter where you end up it’s most likely not at the top of anything. That, and even if you do somehow manage to be the first thing I read in the morning, that in no way affects where in the queue of actions you’ll end up. Guess they’re not subscribers to the GTD style of organization, huh?

Recently I was chatting with my sister-in-law, who happens to be a product owner at a rapidly growing startup company. We were talking about the nature of “flow” and how important it was for people to be able to focus on doing their work without being interrupted. Partway through the conversation she had a great quote (paraphrased roughly here):

Google has a great description for the role of managers: they should be sh*t umbrellas for their team. Their most important role is to protect their team from all the sh*t that comes flying at them so they can focus on doing their job: writing code. That’s my job in a nutshell and I take it very seriously.

The best reference I could find to that term is here, where GMail product manager Todd Jackson was quoted as saying “You can either be a sh*t funnel or a sh*t umbrella.” The article goes on to describe how a good manager protects their team from unnecessary garbage, in effect being an “umbrella” to the storm of things (requests, questions, stupid meetings) that rain down on their staff. But some managers take on more of the role of being a “funnel”, in that they simply filter and then pass on the things that come at their team.

I suppose one might say, “Well at least in the case of the funnel, the people aren’t directly exposed to the onslaught of sh*t.” That’s true, but I’d counter that depending upon how the manager passes on the stuff they deal with, the end result could be the same. If at once-weekly meetings everything that’s been triaged is laid out and assigned, that’s fine, and in fact I’d argue that’s really playing the umbrella role. But, on the other hand, if the manager simply sends everything off towards their team with the convenient “FW:” tag, well then what’s the point of the filter at all?

Personally at work I’d love to have some way of shielding my team from the daily barrage of (mostly) crap work that comes our way. I still believe the idea of a “handler” and holding designated office hours would provide immediate and noticeable relief. In effect, the handler becomes the umbrella, handling the collecting and triaging of incoming requests and only interrupting the rest of the team when absolutely necessary. Hopefully we can get some buy in from management on the idea, and time will prove our strategy to be one that greatly increases our ability to get work done.

So how do you shield your team from flying sh*t? Are you a funnel, an umbrella, or some combination thereof?

So as I previously wrote, the new gig is turning out to be a little bit more intense than I expected. And while I’d love to say that I have it all under control, that, in truth, would be a flat out lie.

The last few days I’ve done my best to keep track of how many interruptions I get on a given day; today I lost count at over ten. Ten in eight hours of work! That means I averaged more than one interruption per hour. Of all of them, only one was actually worthy of breaking my concentration. The rest were either simple questions or related to non-emergency work, such as ongoing testing or requests in queue.

I have to say, I’m at a loss how to put an end to these, or at the very least, reduce their volume. I’ve tried gently redirecting people to send the team an e-mail, forcefully redirecting them (which is usually met with a resentful glare or a “but it will only take 30 seconds”), even putting on my headphones and doing my damndest to ignore anyone who walks up to my desk. It’s gotten so bad that my senior DBA has called a SWAT meeting next month with all of my unit’s team leads to discuss how this situation can be rectified. Without something on the side of a drastic change, my team is going to have a really hard time getting things done.

Even trying to triage everything in queue is difficult, because inevitably, everyone argues valiantly (and rather stubbornly at times) that their issue is the most important and must be looked at first. And most have valid reasons: client impact, loss of functionality, etc. The problem is, there are so many to pick from at a given time that we simply cannot take “My problem has client impact so it must be looked at ASAP” at face value. Otherwise, we’d be constantly shifting in work and never able to focus on our larger goals. Here again, I’m really hoping next month’s meeting will help to clarify and ease this nasty task. At the very least, we need to have some kind of objective framework by which to determine the true priority of requests / issues, similar to the various trauma scales I learned years ago as an EMT.

Yes, I really did just compare my work to dealing with traffic accidents, gunshots, and various other forms of critical illness. The way things are around here, you’d think we were really dealing with life and death scenarios, instead of mere dollars and cents.

Before I was a DBA I used to bother them. It always seemed like they never had time for my work, never wanted to come to my meetings, never wanted to be a part of my projects. It was awful and I cursed them.

Now that I am a DBA, however, I’m finding the roles starkly reversed. My inbox is being pounded with requests to attend meetings; people are constantly walking up to my desk insisting that their project is the most important thing on my schedule, and that I must look at it immediately. I’m quickly developing a ruthless demeanor when it comes to these types of things. The hard truth is, I have to be ruthless, or I would never get anything done. I truly believe that is the case, and I have a whole new level of respect for the other guys on the team because of what they’ve had to deal with.

The good news is I have a good base of skills with which to wade through the river of work and choose what to do in a methodical and measured fashion. I’m becoming even more disciplined with my “not in my list, I don’t do it” rule, and I have mini reviews several times per day at a minimum. If at any point I’m feeling flustered or out of control, I simply take a deep breath, refocus, and look through my lists once again. It’s so simple and yet so effective; why do anything else?

His heart was pounding, racing at a pace that surely would make any competent doctor raise an immediate concern for the safety of his patient. Beads of sweat rolled slowly down his forehead, wiped away by a hurried swipe of a forearm, only to be replaced by fresh ones. He was hunched over his keyboard, fingers flicking over its surface in a frantic blur of activity. His eyes gleamed with fury; two dark spots whose glare was entirely focused on the screen before him.

It was anything but an elegant fight that they waged, the operator and his silicon-based opponent. They darted back and forth, each one probing the other for any sign of weakness. Even as one seemed to gain the upper hand, the other would counter with a move both swift and unexpected. It was a war of attrition waged by two stubborn parties: one driven by his need for dominance, the other because it did not know how to do anything but respond in kind.

Words and numbers trailed endlessly across the screen, a seemingly meaningless stream of nonsense, uttered by a mind bereft of all reason. Yet to the operator it all made perfect sense; perfect nonsense, that is. As his nemesis endlessly spewed chunks of data, his eyes sprinted back and forth, trying as best he could to collect and analyze it all. But try as he might, it seemed always that his enemy held the upper hand. Just as he gleaned a tiny bit of understanding, some small nugget of progress, a new wrinkle would appear, more confounding than the last.

As his frustration grew he felt his temples begin to throb; gently at first, but increasingly as time passed. It was as if his body was trying to tell him “Back off, you’re in dangerous territory.” But he was past all reason, so completely consumed he was with his task at hand. On and on he pushed, till the throbbing became outright agony. He flung open the drawer to his right, digging feverishly through its contents until a small bottle was found. Pawing it open, he quickly extracted two small white pills and swallowed them hurriedly, without water. They offered little hope of relief, but perhaps they would give him the edge he so desperately desired, no, needed.

So, I’ll give you three guesses around what the above narrative is about. A piece from my first attempt at an epic sci-fi perhaps (yes, that is very much on my someday list)?

I’ll give you a hint: been following the saga of Urban Meyer, the embattled yet highly acclaimed football coach of the Florida Gators? If you have, you know that he’s basically been told by his doctors that the very thing that makes him one of the most successful coaches in history may also cause him to prematurely leave this Earth: his singular focus and intensity.

When I first read this story, my immediate thought was “Wow, that could be describing me to a T, minus the arachnoid cyst pressuring his skull and all.” I am probably one of the more driven individuals you’ll ever meet; when my mind is set on solving some problem, it’s a nearly useless task to try and pull me away. Just ask my wife, she’ll be happy to oblige you with all sorts of evidence supporting that statement.

On the one hand, this trait is an asset: it lets me persevere when others would stop, long discouraged by setbacks and seemingly insurmountable challenges. It’s probably the major reason why I’ve been so successful in a field that, up until around three years ago, I knew nothing about. But there is a dark side to this unending focus. It manifests as the (not so at times) occasional splitting headache, the missed personal responsibility, the midnight awakenings when nothing short of a blow to the skull will seemingly quiet my mind.

Faced with the prospect of enduring this escalating chain of physical and emotional malaise, I’ve made the decision, much as Meyer did, to step back. No, I’m not taking a leave of absence, but I am engaging in a concerted effort to become more aware of my emotions and the physical manifestations thereof. Journaling, reminder alarms to “check in” with my state of mind, even asking others to notice when my symptoms begin to show themselves.

I love my work, but I love my family and my health above all else.

A Brief Recap

In part I of this two-part series we talked about the first form of what I call “Racing Brain Syndrome”, the “Stress Induced” variety. To briefly recite the main points:

• It is usually caused by underlying anxiety about some aspect of your life, be it work, home life, or just plain keeping stuff in your head about things you’ve committed to doing.
• This “stuff” can be either real or imagined (i.e. you’re going to get fired for writing a personal e-mail at work, once)
• It is best remedied by either:
  • writing things down and clarifying all the details of what you need to do to take care of whatever is bothering you (best for dealing with the former “real” source of anxiety)
  • practicing a little psychological technique called cognitive behavior therapy, which teaches you to examine and refute irrational thoughts using logical techniques.

Now we’ll talk about the second form of RBS, called “Excitement Based”.

It’s, well, due to excitement (duh)

Yeah, that does seem pretty obvious, doesn’t it?

In some ways this form of RBS can almost be seen as a positive thing, in that it means you have some good positive feelings about your life. Think about it: if you were bored and depressed, would you be waking up at three in the morning with some fascinating new take on that problem at work? At the time you may find yourself more annoyed by your brain’s utter refusal to quiet down, but if properly harnessed, these midnight revelations can actually greatly add to your productivity and creativity.

The trick to properly capturing these sudden bursts is to do just that: capture them

“Huh?”, you may say. Well, think about it this way: the very reason why your mind is refusing to let you drift off is because it’s saying “Hey, I have this great idea, but if you go back to sleep, you’ll forget me and I’ll be lost forever!” In a way it’s almost a built in self defense mechanism, designed to keep your late night brainstorms from slipping through the cracks.

To convince your brain not to concern itself with retaining this newfound wisdom, I suggest you follow the same basic tenet of GTD we used to combat the stress-induced variety of RBS: get it out of your head, now. Write it in the notebook you keep by your bedside table (you do keep one there, right?), send yourself a quick e-mail on the CrackBerry (yes, I’ve been known to do that in the wee hours of the morning), even scribble it on a spare Kleenex or other handy medium if you must.

You might think this behavior will just exacerbate the issue, since it will likely make you more fully awake. While that’s true, I would suggest that until the thoughts rolling around in your brain are properly captured and accounted for, you’ll likely find yourself tossing and turning restlessly anyway. This way, you’ll at least get things recorded so that you’re not battling that inner voice, nagging you about unfinished business. Trust me, that’s a battle you’ll come out on the losing end of every time.

We’ve all had this happen to us at one time or another. You wake up in the middle of the night, thoughts rushing through your head at a mad pace. You try to take the zen-like approach of “letting them go”, but it’s hopeless. You toss and turn, but the harder you try to sleep, the more awake you are. This, friends, is what I call “Racing Brain Syndrome”.

There are two main forms of this nasty little bug, which we’ll call “Stress Induced” and “Excitement Based”. In this post, we’ll look at the first variety in more detail.

Stress Induced

As the name implies, this version is caused by an excess of built up stress that has yet to be dealt with. Common symptoms (not inclusive of the other variant of this syndrome) include racing pulse, pounding heartbeat, cold sweats, and possibly (in extreme cases) delusions of persecution or general paranoia.

Now stress, as you well know, can come from many sources, including the practice of keeping things in your head, nagging concerns over projects left un-planned, fear of upcoming regulatory audits (a favorite of us IT folks), and of course the ever present conflict between the Ego and the Id caused by an underlying need for affection, complicated by an Oedipus complex.

Whoops, I must apologize for that last one. This post has me reverting to my old psychobabble style of writing. Ignore that one, will you please?

When dealing with this variety of RBS, one’s best course of action is tri-fold:

1. Determine if the cause of the stress is a rational one. That is, are you feeling stressed because you’ve fallen off your good practice of keeping things out of your head, or are you suddenly having a sinking feeling that you’ve left your torrent bot up and running at work, and the folks from InfoSec are, at this very moment, hot on your trail? Ok, that’s an extreme example, but you get my drift.
2. If the former, your best bet is to take a few minutes and put some thoughts down on paper around what is bothering you. You don’t have to answer every question out there; just make sure every question is written down so you are confident it won’t get lost in the shuffle.
3. If the latter, you would be advised to fall back on a technique I used to teach to the children at the mental health clinic I worked at out of college, called (in it’s most complex form) Cognitive-Behavioral Therapy. The basic idea is that you write down the thoughts that are causing you discomfort, such as “I’m afraid the ninjas from security are after me”, then examine them in a critical, analytical fashion. For instance, what evidence is there that you’re really about to be attacked in your sleep? Do you even have a torrent bot on your work computer? These techniques are usually used by patients with more severe mental health issues such as depression or anxiety disorder, but they serve RBS sufferers equally well.

On a sidenote, if you’re actually interested in a more clinical view of CBT, I’d heartily recommend the book The Feeling Good Handbook by a fellow named David Burns.

Next time we’ll examine the milder, and perhaps more pleasant variety of RBS, “Excitement Based”.