"Houston here. We're looking for somebody to blame for your problem, 13."

Fix the Problem, Not the Blame
It doesn't really matter whether the bug is your fault or someone else's—it is still your problem, and it still needs to be fixed.

--The Pragmatic Programmer

I highly doubt that was the response to Jim Lovell after the line, "Houston, we have a problem." However, in our world of software development it still seems to be the first reaction to any issue that comes up.

I know in projects past, I've been a huge offender of looking for, "It's not MY fault," rather than fixing the problem at hand. Todd even nicknamed me Blameosaurus on one project because I got so good at looking for the blame. So, I'm not exempt from my own post here.

I've been a consultant for one company or another for over ten years now, and we're constantly thrown into burning buildings to get something working. There are a plethora of issues on day 1, and all too often those of us on the team spend too much time bitching about the issues and not enough time rolling up our sleeves to get things squared away. So, day 2 rolls around and we're in the same boat, and the same problem still exists.

That said, sometimes there is a right time to track somebody down that created a problem. Don't do it as a way to shame them, but rather for more clarification. Who knows what the situation as like at the time they made the error, and maybe it's a good time to help somebody learn something new.

I feel I'm still an offender of whipping out the blame thrower a bit too often, but I'm making a conscious effort to quit and move on with the solution.

GROK Talk Slides

For all you who sat through my record timed performance of a GROK talk, here are the slides.


Pragmatic Programmer Sermon

I apologize for ripping through it, but the gift exchange loomed. The subject didn't really lend itself to Q&A real well, though I think all the points are important. If you haven't read/borrowed/stolen this book yet, do so today. For the time being, here's the list of tips from the book. I worked off about 20 of them.

Post GROK

A friend of mine recently purchased a restaurant in town. After the Quick festivities I headed there to discuss reworking his website. (I'm working for beer...it's a win, win.) This particular friend spent about 15 years in the local IT market, so he has some contacts.

While I was there a group of four guys strolled in to celebrate the end of the work week. Turns out these four guys were in IT, my buddy strikes up a conversation, since they were buying beer from him and all. They work for a small consulting firm (that I'd never heard of), and were very intrigued to find out that I was a developer. So, they asked the standard sales/recruiting questions...where are you, what do you do, etc. The requisite, "You don't sound so happy, here's my card, we'll pay you more," came out and I smiled politely.

Then they sent over one of their developers, at least they introduced him as such. He struck up a very non-technical discussion about the .Net Framework, PHP, MySQL, and some other buzzwords. I managed to not laugh uncontrollably, and continued to smile politely. Honestly, as soon as he attached "Framework" to .Net, I was done. I would have easily been the most senior person in their shop...probably by a few years. Then it hit me: Do I want to be the mostest seniorest person in a very junior body shop, or a senior member of the development environment I am currently a member of?

Without gushing too much...I'm not going anywhere. The IT talent collected around me at this point is amazing, and Quick keeps bringing it in. The whole, "We'll pay you more!" argument is intriguing, but how much more would it take? I'm in a pretty good position at this point. The advancement within the group is no easy task, but the advancement professionally is as good as it gets.