Take three steps to your right to advance to the next slide

Demos – you can shove those, too. People complain when the code doesn’t fit on the screen or when my resolution is too low or when they have some kind of vitamin deficiency and they can’t look at the color #0f0015 for more than 32 seconds without suffering from a migraine. I’ve spent hours coming up with the perfect demo code only to have someone poke holes in it over and over again. I see this all the time on speaker feedback.

No more. You will no longer have this opportunity. PowerPoints are done. Demos are over. Speaking? That’s right out, too. Greek pornography… The jury’s still out on that one.

So here’s a note to everyone who is expecting me to speak at their event in the future: I won’t. I’ll be there, but I will not speak. I need you to secure velvet ropes for my “room”. I will be available for hushed conversations, but I want my work to speak for itself. I need dim, dramatic, lighting and access to numerous power sources so I can light my “slides” in a variety of ways.

Speaking of slides… They have been carefully painted on using oil or egg tempera paints. A few paintings contain other, non-volatile, material when I was experimenting with a different style of art work, but I cannot promise that everyone will like this.

Presenting is an artform and this is art. You don’t have to like it. You don’t have to understand it.

This is art, goddamnit!

Fact: the earliest recorded use of cloud computing was ancient Greek porn

Anyway, it is rumored that Io was attractive. So attractive, in fact, that Zeus, lord of the perverts, saw her taking a bath and got more than a little bit aroused. Zeus then behaved in a way that would end up in a savage beating and restraining order back where I come from – he pestered Io for nookie until her father drove her out of the house – probably because some horny lunatic who could shoot children out of his forehead was bothering his daughter. Io, being a bit strange in the head, relented. Or something. My records aren’t 100% clear seeing as how they’ve been written on pottery. The point is that Zeus turned into a giant cloud and turned Io into a cow (no, your hooves don’t make you look fat).

Somehow Zeus’s wife got involved and there was bondage involving a cow tied to a tree or something. Eventually Io gets turned back into a real live girl and gives birth to Zeus’s son. Which brought about an ethics probe into cross-species cloning.

Disk… disk… oh yeah I already mentioned that the ancient Greeks were clearly insane and thought that the world was a giant metal plate floating on a huge river name Oceanus all of it encased in a hemisphere with clouds and the sun and the moon and stuff painted all over the inside of the hemisphere.

What’s outside of the hemisphere? Shut up, that’s what. It’s turtles all the way down.

There’s a bit of humor thrown into your T-SQL Tuesday

Blog memes are great. They give me an opportunity to pretend to be inventive and creative, take someone else’s great idea and spin it in a centrifuge to extract the good stuff and then pass the detritus along to someone else to deal with. As a career developer turned developer berating apparatus, I have seen my fair share of cobbled together dung heaps. In fact, I would be proud to have someone call some of my solutions a cobbled together dung heap.

Bad Process? Just Add Software

Many years ago I was asked to put together a simple proof of concept application showing code movement using VSS automation. The phrase “simple proof of concept” should have sent me running. Of course, I’m assuming that the me of 5 years ago had any sense in his head.

I’ll back up a minute and let you see the whole situation. This organization had a complex development lifecycle. Developers were frequently developing several releases into the future in a combination of major and minor releases. Hot fixes would go out in production and when the next major release went out the icon be cornflower blue but the hot fix would be nowhere to be found. The hot fix would be hot fixed into production and the icon would be back to alice blue. The situation was, in short, a nightmare. What makes the nightmare worse was that it was a process nightmare: development practices in this organization dictated that multiple releases be developed simultaneously by separate teams.

Think about complex, line of business, software. Important software. Software that is core to your business. Imagine that three separate teams of developers are actively developing new features and fixes at the same time in three separate source trees. This is exactly what was going on at this organization. My job was to automate the problem away with software.

Bad Software? Just Add More Software

This organization was heavily invested in using Visual Source Safe. For those of you young enough to have worked with modern version control systems (such as a team of scribes working around the clock), let me tell you about VSS. VSS exists entirely on the client computer. VSS’s source control mojo operates through a network share using a combination of black magic and pure luck. Like all things that work with luck, it fails. It is safer to print your source code, shred it, and burn the paper shreds that to keep your code in VSS.

Despite the pain of VSS, VSS was the platform. How do you automate a platform when there is no server-side component? You install a VSS client on a server and you begin automating it. Thankfully VSS supplied an API – a poorly documented COM+ API.

I created a proof of concept application that showed code motion through various stages of development in VSS. The client was happy. The client signed a statement of work. We took their money and strode purposefully towards what appeared to be a set of rotating blades.

As the project unfolded it became very apparent that no amount of software could solve this problem. The problem was process, not software. Valiantly, foolishly, 26ishly, I soldiered forward. I worked 14 hour days. I build a cobbled together GUI that attempted to model a software development process that was beyond complicated. The GUI was cumbersome to use and brittle to code. A small change in one line of code meant that 17 other bugs showed up in various parts of the program. There were easily 100,000 lines of code in what should have been a simple management application. Edge cases lead to other edge cases. After one marathon 24 hour programming session (after four 18 hour days) the GUI tool finally worked. The users could configure a process. A process that potentially didn’t work.

Throwing Worse Code After Bad

The actual automation was a supposed to be easy. The users could apply VSS labels and the automated software would, in theory, pick up the changes within 15 minutes. The automated software would pick up the changes on a regular basis but it frequently exploded in a fiery error when confronted with real world problems. When two teams are actively developing against the same code base, code merges don’t go very well.

The process was intrinsically human but the client wanted automation. Being young and stupid, I didn’t know enough to say no. I cobbled together a working knowledge of text parsing and attempted out outfox the people who wrote the VSS Merge Tool. Armed with a fistful of academic papers, articles, and APIs I attempted to build a better merge tool using existing libraries.

At the end of the day, the tool built a log of errors using the unified diff format (which no human can read), collected the log and emailed a copy of it to the developers who committed the conflicting files. Or, it would have had anyone used the software.

Didn’t You Read the Manual

I actually wrote a software manual. It was actually a good manual. Want to know how I know? I gave the manual to the project manager and had him create instructional videos. They worked.

The project sponsor was promoted before the project was completed. The primary users transferred to another department. The new users were too busy to read the manual and expected the software to work easily and obviously. Who wouldn’t, right?

The GUI tool looked like the directory structure in VSS, but it didn’t reflect the changes in VSS, it simply let the users configure how the tool should behave. Sound confusing? It was.

At the end of the day, I had written a complicated manual for a complex piece of software that actually worked. It was a cobbled together solution built out of several hundred thousand lines of buggy .NET 1.1 code sitting on top of a buggy COM+ API intended to solve a buggy process. It’s a miracle that this software abomination wasn’t fueled by the shattered dreams of orphans.

Silent Rage Would Be Better Than This

I said that was the end of the day. It wasn’t. I got one support call about the product about 3 months after it had been delivered, signed off, and paid for. I went back to the client’s location and sat down with the current team to learn their problems. None of them knew how to use the software. No original team members were around who had been involved in the original project. All of the original documentation had been lost in some kind of bit rot tar pit.

My beautiful, cobbled together, duct tape and baling wire solution would never see the light of day. It may have been ugly, but it worked. There’s nothing like feeling the triumph of having saved the day and then having that day get flushed right down the toilet.

Calling Other MacGyvers

Since Brent Ozar stole my default victim, Matt Nowack, I’m going to have to find more victims. I’m going to point the finger of shame at TJay Belt, Grant Fritchey, and Alex Moore.

Like Jack, I think I could approach this in a number of different ways. I think I’ve already answered the professional route that I took. If I haven’t, it’s probably because my professional route isn’t all that interesting and it’s also all available on LinkedIn. You can, and should, fill in the job changes on my resume with something interesting like “After being attacked by a bear in the janitor’s closet at CareWorks Technologies, Jeremiah decided to take a safer job at HMB (they have no bears on staff as janitors).”

Anyway, you asked for it, you got it: how the hell did I get here?

I’m a Rock and Roll Machine

I love being on stage and in front of people, even though it terrifies the crap out of me. Apparently, I like that adrenaline surge. I’ve been playing guitar since I was 13 years old. When I was 23 I answered an advertisement and auditioned for a band. I got the job after 5 minutes.

Being a musician takes a lot of hard work, dedication, and practice. You work for hours and hours as a group, and hours and hours on your own preparing for a show. At that show, you’re going to walk up on stage and try to steal the attention of a room full of people who would, frankly, rather be doing one of a million other things – playing pool, talking to friends, hitting on that girl across the bar – than listening to you. As musicians, it was our job to get their attention, hold it for an hour, and make sure that they were happy about it. That job gets even harder when you’re in a band that only plays original material.

What seemed really fun – being in a band – turned out to be a lot of work – practicing three nights a week for four hours a night with the band and then practicing even more on my own. I learned a lot about myself – my tolerance for bullshit, how to get attention, and how to act in front of a crowd of people – while I was in the band. I also learned a lot about how to budget scarce resources – money and time – while still getting the job done – getting to the show.

The band eventually fell apart, as most do, but I learned many valuable lessons that I carry with me – time and resource management, performing skills, and how to make an ass of yourself and be okay with it. Most importantly, I learned that passion alone isn’t enough. You have to work for something if you really want to be good at it.

Everything to Everyone

The fact is, I’m not everything to everyone. But for a long time, I thought that I could do it.

Before and while I was in the band, I was married. The band took up a lot of time and it took a lot of time away from my marriage. While being in a band didn’t cause my eventual divorce, I’m sure it contributed to it (I quit the band about a year before my ex-wife and I quit the marriage). I remarried pretty quickly and that marriage ended almost as fast as it started.

Throughout all of this, though, there’s a huge undercurrent – I was trying to make everyone happy. I was trying to be a good husband, musician, developer, friend, son, brother, step-father, and about a million other things. I stretched myself thin and I broke.

These days, I know that I can only be me and that I’m the only person I need to make happy. There’s a reason why I work with SQL Server but I program with Ruby, why I listen to old school hardcore punk but I play a bizarre blend of folk and country, why I devote more time to my friends and family than I have before – these things all make me happy. If it doesn’t make me happy and I don’t need to do it to live, I don’t do it.

Self-Fulfilling Catastrophe

A couple of paragraphs ago I said “I stretched myself thin and I broke.” I really do mean that. During the first divorce, I moved into a tiny house on the ass end of Columbus, stopped paying most of my bills, and ended up living on as little as $20 a week. The funny part, though, is that I always found the cash to go out and party, or to stay in and party. This became a bad habit even once the divorce was done and I should have been back on my feet. Over the next 4 years everything spiralled completely out of control.

I’m pretty sure there were more than a few times I nearly lost my job. I frequently called in “sick” from the crowded patio of a bar at 1:30AM, had my car repossessed, racked up so much debt that people were calling my family members to find out where I was, and I partied seven nights a week. I lost a lot of my friends and damaged most of my remaining friendships irrepairably in the process. Throughout this ordeal, a few of my friends stood by me. They didn’t give up on me despite my ardent attempts to turn myself into a drooling train wreck of a human being.

In June of 2008, I gave it all up. I realized that I was a total train wreck and that everything around me was completely out of control. My career was stagnant. I was sliding backwards as a person. I wasn’t meeting any of my goals for myself because I was too busy slowly killing myself.

I stopped drinking. I got the help I needed and I began the long, painful, process of pulling myself up by my shoelaces. I dried out.

By August, I had completed the SQL Server 2005 MCITP: Database Developer certification. I started the Columbus chapter of PASS in October. I started paying back all of my bad debt (only a few months left to go). Nine months after I quit drinking, I quit my one to two pack a day smoking habit (sorry about that one, Mom and Dad) – I never would have thought I could end my 13 year addiction to nicotine.

I have a great relationship with my family and friends now, it’s better than anything I could ever hope for.

I learned a lot of things from this.

1. I can be horribly selfish.
2. There’s nothing better than not being that selfish.
3. I can do damn near anything I want to do if I put my mind to it.
4. There are some things in life that are so important you can’t afford to overlook them.

Afterward

This summer, one of my friends (someone who met me at my lowest and stuck by me through everything) is giving me the greatest honor I could ever hope for: on June 19th I’ll be officiating his wedding. Like a lot of people, I wouldn’t change a thing about my life.

What is it?

You’re probably asking yourself “What’s a Log Reader Award?” Well, dear reader, a Log Reader Award is an award created by bloggers (myself, Andy Warren, and Brent Ozar) to recognize other bloggers for their excellence in writing across a number of metrics including style and technical knowledge. (Ability to recognize an Oxford comma is a plus, but not required.) We realize that it’s important to recognize people of all skill levels and that what makes a great introduction to a topic is not the same thing that makes up a deep dive into a single feature of SQL Server.

To make this easier, there are multiple categories: Book Review, Business Intelligence, CLR, New Blog (less than one year old, at least one post a month), Professional Development, Series (Multiple Posts), Server Management & Automation, T-SQL, and Unusual (it’s great, you love it, but it doesn’t belong in a previous category).

How does it work?

Well, you go to the submission form and enter your details. On October 17th, we take your list of submissions and review them. Keep in mind, though, that we’re only going to review the last two posts you submit. This is how we’re going to stop you from voting Chicago style. Only posts that you’ve written between October 15th, 2008 and October 16th, 2009 are eligible. You can’t submit your doctoral thesis on relational design that you wrote 15 years ago. We’re looking for current articles from active bloggers.

Your RSS subscription will look like this

What do you get?

The satisfaction of a job well done.

No, seriously, what’s the reward?

In addition to the satisfaction of a job well done, you will also receive the praise and admiration of your peers. We’re working on ways for award recipients to show off that they are an amazing blogger. Oh, and we’ll be announcing the winner at PASS. In front of people. So it won’t just be me telling the coat check crew about you… everyone will get to know how great you are!

You might now be wondering “How can I get some free learning?” Well, I’ll tell you how: The Internets.

By using the internets you have access to a ton of free training. Crazy Helpful people just write up blog posts and give presentations via LiveMeeting out of nothing more than kindness so that you can get your learn on for free.

Understanding Execution Plans On Tuesday, August 11th at 1pm EST Grant Fritchey will be sharing some of his execution plan knowledge with everyone! This is a LiveMeeting and audio will be provided via the computer, not your telephone, so bring headphones to work if you want to listen in.

Quest Connect 2009 Brent has a great article up on his upcoming speaking engagement at Quest Connect, which will also feature Tim Ford and Tom LaRock. Brent was also kind enough to include links to multiple other sources of free training.

24 Hours of PASS Starting at midnight GMT on September 2nd, there will be 24 hours of PASS presentations available for the world to see. Check out the list of sessions and speakers. This is a great free event, don’t miss this opportunity to learn from some incredibly sharp people. Ready for the best part? The speakers will be available to take your questions while you watch the presentation. So go ahead and register. You can learn while you eat corn flakes.

There isn’t a lot of time left, but you still have a chance to win your PASS Summit registration, hotel, or one of a number of other cool prizes. If you don’t win, you can still go to PASS and spend time with me, or Brent Ozar, or Tim Ford, or Thomas LaRock or Blythe Morrow (Blythe is part of why PASS works). But, if eating waffles, bacon, or having treadmill races isn’t your cup of tea, there are a number of other reasons you might want to go to PASS this year.

Allow me to enumerate:

• More than 160 top-quality sessions scheduled across 5 tracks and 14 pre/post-conference seminars (I’m an alternate presenter, bet you didn’t know that!)
• Great chances to network with awesome people. There are even sessions to help you improve your networking skills like this one with Don Gabor.
• A great lineup of top experts, authors, presenters, thought-leaders, and community influencers, including Kalen Delaney, Paul Randal, Kimberly Tripp, Itzik Ben-Gan, Kevin Kline, Greg Low, Louis Davidson, Steve Jones, Andy Warren, Brian Knight… and the list goes on and on (look, I stole that last line from some PASS copy, it’s 12:05 AM Eastern time, I’m not going to be all that original).

So, here’s how the contest works:

1. Write 250 words or less about the best thing you learned at PASS.
2. Send your submission or a link to your blog to contact@sqlpass.org with the subject line ‘Best Thing I Learned at PASS Summit

It’s really that easy. Check it out if you don’t believe me.

Point is, I’m going to be there.

Now, to find out how much time you have left, you need to

1. open up SQL Server Management Studio (Express Edition works just fine).
2. Open up a new window and paste the following code into the new query window:

   SELECT DATEDIFF(dd, GETDATE(), '20090701');

3. Press F5 or CTRL + E or click Execute

You can enter three times, so enter three times. Three chances to win!

If you need help convincing your boss to send you, check out this great ROI or send them a letter or just send them the link to the conference agenda.

One thing I learned at PASS: it’s possible to include references to Krull, ballet, ice cream, and bacon in the same conversation.

On July 23rd, I will be presenting at the Central Ohio .NET Developer’s Group. The fun starts at 6:00 PM. I strongly suggest you bring large piles of money to throw at me.

What will I be speaking about, you might ask? (You’re probably not asking yourself this question because you already know I’m going to tell you.)

From Tables to Objects: Making Your Database Work With You

Time & Location

July 23rd at 6:00 PM, at Central Ohio .NET Developers Group located at the Microsoft building on Polaris Parkway in Columbus, OH

Abstract

A database is far more than a persistent object store for your application; it is capable of data validation en masse, aggregations, and creating different projections of data. By working with your database, rather than against it, it is possible to leverage all of the capabilities of a relational database to provide rich, high performance interaction with your application through an ORM. This presentation will discuss the finer points of building a full-featured data access layer using an ORM and the features of a relational database.

Goals

1. Teach attendees about database features that make development easier – including views, sparsely populated tables, and user-defined functions and types.
2. Empower the audience to solve object relational impedance mismatch using data modeling techniques and database features.
3. Demonstrate how to integrate the database and object oriented software using a custom designed data access layer.

This is going to be my second PASS Summit, so I’m not an expert on picking sessions, but I have an idea based on what worked well last year. Last year, I had an exhaustive list of sessions picked out. Then, when I arrived at the Summit I marked them all on my program, which I promptly lost. Brent was kind enough to give me his program. I drew stick people on it. I also didn’t attend a lot of the sessions I was planning on attending.

1. I grossly underestimated my own abilities and ended up leaving sessions because I thought I could gain a lot. Don’t underestimate yourself. Challenge yourself. Pick sessions that you think there’s no way you can understand them. I attended Jimmy May’s presentation on Disk Partition Alignment with Brent. I thought I would be completely lost. Then I realized that a lot of the low-level disk information bore at least a passing similarity to inode structures in the ext2/ext3 family of file systems on Linux systems. Once I translated that knowledge I was able to follow along, roughly, and be challenged in my thinking.
2. A lot of very smart, really great people gave me suggestions on sessions to attend. The friends I made at PASS helped me find sessions that would better fit what I wanted to learn about. They were right.

What am I going to different this year to make sure that I get the most out of the Summit? How can you do the same?

1. Ask someone who has the job you want. Say you’re a database developer and you want to be a database architect. Find one. Ask them which sessions you might benefit from. Better yet, ask them “I want your job. Which of these sessions will help me get there?”
2. Pick something you don’t know anything about and attend it. If you want to learn about something, learn through a trial by fire. But, like I said earlier, don’t underestimate yourself. If you know even the slightest bit about SSRS, an introduction to Report Builder 2 is probably going to bore you. Take a gamble and go to an intermediate session.
3. Make a back up list. Make a list of sessions that sound like they would be very valuable to advancing your career path interesting. Pick things that sound cool. Pick features you haven’t played with. Learn some Business Intelligence mojo.

Honestly, I’m going to do all three of these things. There’s a lot that I want to learn. I know people who are already there. I’m going to pick their brains for how to get there. Just remember that you’re going to the Summit not just to learn, but to interact with your peers. Make sure you socialize, too. I still think I learned more sitting on the floor talking to Brent Ozar, Donald Farmer, and a few other people than I would have if I had gone to whichever session I originally planned to attend.

What’s a give camp? Basically, to paraphrase the about page, a give camp is an opportunity for developers to give back to the local community by contributing time and effort to create custom software for non-profits.

How can you help?

• Volunteer your time
• Let a charity know
• Sponsor the event with food or software licenses or plain old piles of cash

Why am I plugging this?

1. It’s a cool idea
2. I designed and built the database
3. I plan on being there

What are you waiting for? Head on over to Columbus Give Camp and volunteer!