A Wandering Mind

A short while ago, I read a great post by Kendra Little (@Kendra_Little on Twitter) on how using some common consulting tricks can be useful even for those not in a consulting role. One item that resonated in particular was the idea of tracking your time, for the purposes of finding places where your time is probably not being used wisely (Kendra uses the example of not planning for disaster recovery, a clear “must-do” for a good DBA). I’ve tried various methods of tracking my time before, including everything from home-grown applications (I suck at GUI programming on a side note) to simple notepad paper. Everything failed miserably for one of two reasons.

It Was Too Hard To Use

My cruddy GUI programming skills aside, I had never found something lightweight enough that I could really use it consistantly without slowing down. In my work I am constantly switching tasks, so whatever method I used needed to not require ten clicks to switch from one task to another. If it was anything less than really easy, I would simply give up after a few days.

It Didn’t Give Useful Data

Recording time is one thing, but of equal importance is the metadata associated with that slice of time. What project was I working on (if there was a defined project, not something that’s always true)? For what client? What “tags” or other little flags were associated with a piece of work (for instance, was my time spent dealing with a “walk-up”, or was it unplanned troubleshooting)? Without this enriched data, simply knowing that I spent from 8 AM to 9:45AM working on task ‘XYZ’ really isn’t very useful.

Well, thanks to Kendra’s suggestion, I’ve finally found a tool that I’m sticking with. Toggl is nothing short of fantastic! It’s easy to use, quick, and allows me to easily tag and classify work without a lot of extra effort. It’s been downright fascinating seeing how my time is really spent, and I’m finding it’s often quite different than what I perceive. I might feel like I’ve spent every waking moment working on a particular effort, only to find that my judgement is skewed simply because I find that particular work unpleasant (nothing to throw off your gut feeling like hating what you’re doing).

Most importantly, it’s enabled true, accurate (at least mostly so) transparency with my superiors and customers. When I report weekly to my boss, I can say with integrity what I have (and conversely, have not) been spending my time (and therefore the company’s money) on. It’s been invaluable in tweaking my workload to better suit our client’s needs, but also in identifying easy automation / delegation opportunities. Clearly a win for both sides!

One of the challenges that I’ve never quite figured out is scheduling myself for projects at work. When teams come to me for help, they usually want to know when I can get to them (which usually turns into an argument over why I can’t do it that same day). As a result, I have to develop some method of keeping track of the projects on my plate, who they’re for, how long the various tasks are going to take, and when I’m going to do them.

Interestingly enough, this is one area where I’ve found GTD somewhat lacking. The framework is great for keeping track of ad-hoc “Stuff” that can be done whenever time is available, as well as the “waiting for” and “someday” lists, but it just doesn’t seem to work for the kind if date-based scheduling I usually find myself doing. If I just put something on the list without considering how long it will take to do (i.e. “Install SQL Server cluster (6 hours)”), then plotting out when I have time to do it, I wouldn’t be able to give even a whiff of timelines to the consumers of my services. Naturally, that wouldn’t work very well in a deadline driven environment.

What I’ve been doing as of late is simply blocking out time on my Outlook calendar as projects arise, then letting folks know when I’ll be taking care of their work. It’s fairly simple, and works decently. I would like to figure out a way to make it a little more transparent than it is (I obviously don’t want to share out my calendar to everyone in the company) and easily reportable.

Ultimately though, the biggest problem is that the damn thing just fills up too quickly. Even fully reserving Monday, Wednesday, and Friday for project work (I pre-block out my calendar to prevent meeting invites, or at least discourage them), I’m usually booked solid around two plus weeks in advance. Teams generally aren’t too happy about that, though I have to place some of the blame on their shoulders; you can’t realistically expect a skill resource like a DBA to be able to undertake 10+ hours of work on two days notice. But despite reminding folks of that nearly constantly, they still complain and don’t plan, and I’m left in a bind where either one of two things happen: 1) Their work gets done as scheduled, despite their continued whining, or 2) someone higher up gets involved, priorities are shifted around (which is its own headache), and their work gets done sooner.

If I’m having this much trouble scheduling my own time, I can only imagine what it must be like doing it with multiple resources. Thankfully I’m not there yet, though if this work volume keeps up it might just be the justification (along with the gradually increasing din of complaints) to make my “team of one” a little larger.

How do you schedule your time if you’re a project based resource? How to do handle the inevitable emergencies that arise as well?

Recently I switched from using the web-based GTD tool Tracks to the simple, text file system called todo.txt. It’s based on a text file, with several interfaces, such as a command line tool, and an Android app. Naturally, one could also simply open the text file and edit it as well.

Initially the switch was made for a practical reason: the web filtering software at work happened to suddenly decide that parts of the Tracks website should be blocked, making it extremely difficult to use. But in time I’ve found that the new approach works quite well for several reasons.

First, it’s incredibly simple. I use the command line client (along with Cygwin) to interact with my todo file, with two aliases set up. One (the letter ‘t’) I use for keeping track of work items; the second (the letters ‘tp’) I use for personal items. That keeps the two separate, work versus personal. That way I’m not tempted to knock off some work related item when I really should be cleaning the kitty litter.

Let’s say I want to add an item called “Followup with Dave re laptop status”, with a context of “@computer”. I simply type t add "Followup with Dave re laptop status @computer", and the item is added. I’ve always been a CLI junkie (in no small part because I really suck at GUI design), so I’m really loving it.

The second reason actually started out as an annoyance. Initially, I found reading the long text file rather cumbersome; sorting out projects, priorities, due dates, etc, wasn’t nearly as intuitive as it was in Tracks. Instead, I had to really scrutinize the list and read things over one at a time before deciding what to do. I was becoming quite frustrated when it dawned on me: this is actually a good thing, because it’s forcing me to explicitly examine everything on my plate whenever I look at the list. No more glancing over things without really seeing what they are.

If you’re into simplistic (yet elegant) solutions and also happen to be a GTD junkie, I’d highly recommend checking todo.txt out.

Lately I’ve seen several folks on Twitter talking about “updating their 30, 40, and 50,000 foot GTD goals.”. This made me realize that while I’ve really been cruising along in the day-to-day arena, I’ve pretty much neglected some higher level thinking. When you’re working 9 hour days and the to-do lists are always full, it’s pretty easy to lose sight of considering larger goals and visions. Or at least it is for my ADD riddled brain.

50,000 Feet – Life’s Purpose

If I talk about my big time life goals, I would say at the moment they reside in three categories:

Be a wonderful father and husband (and son) for my family

I want to provide us with enough to live comfortably, but not work so hard as to interfere with spending time with my son and wife. Family time is extremely important to me.

Become a well known and respected member of the SQL Server community

After knocking around for years in various technical roles, I really feel that I’ve finally found my niche. I love working with SQL Server; the internals, the various moving pieces, the never ending amount of information to learn. And as I’ve continued to learn and grow, I’ve really become enamored with the SQL community; not in a weird man-crush kind of way, but in a “wow the combined amount of knowledge and experience present here is amazing” kind of way. I really want to become more engaged in being a part of that.

Become a published author

Ever since I was a kid I’ve loved writing. It’s always been a dream of mine to write a best selling novel. Not one of those cheap drug store romance pieces, but something really deep and dark, that gives its readers a real emotional reaction. I’ve picked up more books this year than any year since high school, and the end result has been a real return of that hunger to create. When I read stories like Ender’s Game and The Deathly Hallows, and watch some phenomenal visual narratives like Battlestar Gallactica and Lost (except for the last season, which I think overall was pretty bad), I’m continuously left with a feeling of “I want to write that.” By no means an easy thing to do, but I’m keeping it on the list.

40,000 feet – 3-5 year goals

Present at least once at a SQL community event

I still consider myself very much a rookie in the SQL Server realm, so I’m giving myself a couple of years yet before I start expecting to be at a level where I can present. I’m constantly coming up with ideas, which are getting filed away in a safe place (i.e. anywhere but my brain) for later use. That way, when I feel I’m ready, I’ll have plenty of material.

MCITP Certification

I’ve only recently begun studying for my 70-433 and 70-432 exams, and while in a lot of cases I’m finding that I already know the material, there’s also a lot to learn. As you’ll see later I’m hoping to pass those two exams within a year, but to get the full MCITP certs I’m giving myself a little longer, both for experience and financial reasons (at least for the moment it looks like I’ll be paying my own way).

Take on some side consulting work

Make no mistake: I love my job and the company I work for, and I’m not looking to quit and move into full time consulting. But I would like to start entering into that world, both for experience and, to be totally honest, the extra money. I don’t know how feasible this will be, since I won’t be able to commit to anything more than 8-12 hours per week. I’m hoping I can find some “Remote DBA” style opportunities, and maybe some performance analysis / tuning ones.

30,000 Feet – 1 year goals

Servers at 100% Patch Level

When I inherited my current environment of around 35 SQL Servers, one of the first things I did was to assess their health. Overall I found them in pretty poor condition, especially in the realm of patch level. Many were at least one major service pack behind, which is completely unacceptable. This year, that will change.

Build a complete replica of production

Right now our development environment is scattered and disjointed; some servers have many components (i.e. Analysis Services, Reporting Services), while others have only the Database Engine components. This does not make for valid testing, since it looks nothing like production. By the end of the year, that will change, and I will have a complete setup (including network topology) mirroring our production systems.

Start a SQL community at work

Because I’m very much a “teach a man to fish, don’t catch the fish for him” kind of guy, I want to start helping to empower the folks around me to be better SQL Server users. I’ve decided to do this via series of learn-over-lunch sessions where we’ll all get together and study up on the latest trends in SQL. Sometimes we’ll just be viewing webinars, others we might jointly look over some troublesome code and decide how to fix it. Having already had one such session the response so far has been very positive, and I’m excited to keep on learning.

---

That’s about it for now. I’m sure things will come on and move off over the course of the year, but I’m really going to try and tie my actions to these higher goals as much as possible. From time to time I think I’ll check in and see where I stand, maybe once a quarter.

What are your big goals for the year?

I’m horribly prone to distraction. It seems like every day I’m finding some other shiny little aspect of life to become interested in. Most recently (as in today) it’s Powershell remoting. I saw this video from TechEd and immediately exclaimed “Oooooohhh… I have to try that!”. And naturally, by “try” that I mean delve into it with absolutely focus and intensity.

Why might this cause a problem? Well, because I’ve got many many other things that I should be learning about, like Full-Text indexes, and the Entity Framework. And if I keep on finding more things to take my attention, I’ll never be able to keep track of them all, right?

Wrong. See, that’s where my old tried ‘n true lists come in. As I find things to study, I add them to my lists:

There they’ll sit, waiting patiently until I’m ready to return to them. I can also review them on a weekly basis, and make sure that I’m not going too far off the reservation, and neglecting things I ought not to be. And I know this with certainty, so I can feel totally comfortable giving in to those pretty butterflies that keep coming my way.

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.

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.