"What goes up must come down. Ask any system administrator.”

(anonymous)

Ain't that the truth. Ever have one of those days where things start out okay, quickly go sideways, straighten themselves back out, then take another turn for the worse? Even days like today, ones where none of the problems I had to manage was what I would call “a big deal,” can wear on the nerves... Kind of a when-it-rains-it-pours thing I suppose. One thing's for sure: The level of complexity in troubleshooting sideways systems is exponentially related to the complexity of the system itself. I spent a few harrowing hours fighting a Blackberry server today that was doing nothing short of driving me crazy. I ended up rebuilding the app server, after doing some serious registry hacking, but all was recovered and well in the end. At times, when I see the level of st00pididity that goes into designing certain systems, I can't do much more than shake my head in utter disbelief, noting that somewhere along the way my disbelief was replaced with the occasional cynical disgust.

I don't like feeling that way. People will laugh when they read this, but I am actually not a cynic at heart, and I don't like acting or feeling that way. It's part of why I left my job in law enforcement a few years back and went on to other things (of course the paycheck helped in that decision, too). Today was just one of those days when I found myself frustrated, then content, then cynical, then calm and cool, then just ready to give up, and finally something I can only describe as triumphant.

I guess it's just one of those days when you're the passenger (or the kid on the hood of the car, as the case may be), someone else is barreling down the road, and all you can do is hold on tight and scream at the top of your lungs (metaphorically of course) and hope someone hears you and stops.

Of course, it's also days like that that make the good days look better.

Chris Pratley talks about Program Management, and in the process proves that he truly understands The Way Things Are:

Some years ago I realized that as a PM, my definition of vacation was not just going somewhere to have fun (work is quite fun most of the time). Vacation means getting to an environment where no decisions have to be made. I used to drive my friends nuts, since I would go visit them, and they'd say "what do you want to do?", or "where do you want to go?", and I would simply say "you decide".

Amen, brother.

More kudos to Scott and also to Stuart - Thanks to them I now have colored search results in dasBlog... Try it out in the search box over there in the menu bar. It makes the page that dasBlog spits out more meaningful, for sure.

One thing I noticed it does though - and I will have to bug someone to help me figure this one out - is that if you search for text that is, say, part of a URL, the results get returned as well. Need to adjust so if you search for XML, for example, it doesn't return results where “XML” is in some part of the blog entry other than the displayed body text.

But hey - highlighting is nice.

Not because it has to be (Excel can be a great tool when used correctly and in the right places). But go ahead, look me straight in the eye, tell me you've never run into some rendition of this:

http://neopoleon.com/blog/posts/434.aspx

Rory is hillarious. I've been reading his comics (and site) off an on for a while. He hits this one right on the head.

First of all, people should know that I am *not* a programmer - not even close (in fact, the people that work with me are reading this and laughing at the fact that my name now appears in the same paragraph as the word “programmer”). But, being the IT-Geek-Person-That-People-Think-Knows-A-Lot (guess I got ya all fooled, I do ), I am often asked to try to explain things I know only a little about. When I explain I don't really know much about some subject, for some reason most of the people I associate with tend to look at me like I am simply avoiding the conversation. They must assume I just don't want to talk about work-related stuff outside of work (and they are right, but still - the real problem is that I often don't know jack beyond the simple basics of what they want me to explain).

For example, take XML. Sure, I have a basic rudimentary understanding of XML, how to write it, how to work with it, etc. It's not exactly rocket science, after all, and I have to know the entry-level basics in order to hold a “meaningful” conversation with many of my colleagues. Plus the new Office System 2003 applications I am spending a lot of time with make use of XML in ways past versions could not, which is cool. But, that just means I need to learn more about it.

SideNote: Back in - get this - 1996 or so, I was a sweat-equity partner in a company that was building an online service for small businesses to respond to requests for quotes put out by the federal government. That was my first exposure to XML, back in the day, when it was pretty much brand new. I remember one of my friends, John Turner, back then telling me this XML thing was the way of the future, and I should just wait and see if I didn't believe him. JT was always right.

I have two main resources I can leverage to learn about geeky things like XML. One resource is the people I work with, and Travis and Scott from work are awfully good about humoring me and teaching me the salient details of what I need to know in order to be able to understand what the heck they're talking about on a daily basis. And for this I am grateful.

The other place I find the information is by scouring the web, RSS feeds, and other resources for *good* links to useful information. In this case, it was on the MSDN web site, in the Office Developer Center: The article, which ends up discussing XML in the context of the Office tools, actually spends most of its time introducing the reader to XML data, schemas and trasforms in general.

For those of us who yearn for someone to explain things on our level, this is an XML gem, and Bill Coan (the author) gets my vote. Anyone can understand this stuff (even me), and Coan does a pretty darn good job of showing the reader how XML is structured. So, if you're one of those people who are always asking me about this-technology-or-that, and if you have always wondered what the heck this XML stuff is, take a few minutes to read up, and you'll know almost as much as I do.

My friend and colleague, Scott Hanselman, showed me long ago the value of making sure people can see what's on the screen when you are presenting. I spent this week giving talks about some new web-based apps we are rolling out, in a large room, and toward the end of the week I actually remembered something Scott had told me, and something he recently posted on his blog.

Fact of the matter is, between my marathon presentations every day this week and the rest of the things I have to worry about/deal with/etc., some of the people who had to sit through a few of the presentations were short-changed somewhat by the fact that the amount of information required to be on the screen at any point in time was large, the fonts were small, and therefore it was hard to see what I was referring to.

Toward the end of the week, I tried the tool Scott mentioned recently - UltraMagnifier. And it's pretty cool. Using this, I was able to highlight the things on the screen in the magnifier window that were otherwise difficult to read. I can set the magnification level and a myriad of other settings too numerous to mention, and it worked like a charm. It will take some getting used to on my part to really be able to use this tool effectively in my presentations, just because it's a change that requires me to re-wire my brain, but it's a good change so I will put the energy into it.

And - for anyone who gives presentations (even just now and then) - This is for you. Read it, learn, use it. Scott is the best damn technical presenter I know (and I am not ).