Muddle Through

I used to work in the restaurant business. I got started after my first year at college, landing a job waiting tables in a new hotel. It was eye opening for me to see just how stressful and difficult that job can be. However, I wanted to earn money and jumped at opportunities. When we needed room service waiters to pick up shifts and elevators didn’t work, I carried trays up staircases, taking advantage of the opportunity. When a bartender didn’t show up, I volunteered to take the lunch shift. I had no idea where things were in the bar, I was 19 and didn’t know how to make drinks, and I’d make less money, but it was an opportunity that I knew would pay off at college.

It did, and at the next three jobs, I wound up me getting hired, starting work, and having either no one to train me that day or a very busy shift where I was mostly on my own to survive. I had to muddle through and learn on the fly. The ability to do that, without panicking  being overwhelmed, or giving up has served me in quite a few positions since then.

When I started working for various companies as a developer or DBA, I found myself in similar situations. Problems would arise, often the day or week I started, and I’d have to solve them. Usually with DBA positions,  I was the only one there, so I couldn’t depend on anyone else. It was  a good thing as I often found that sysadmins or developers were not managing or configuring databases in an efficient way. As I gained experience, I could make more and more of a difference earlier on at each organization.

Kevin Feasel wrote a bit about his experiences with Lucerne (near the bottom), muddling through the need to write queries. I’ve seen similar stories from other friends working with SSIS, SSRS, Redis, Azure, and more. They don’t know a lot, but they dig in and learn, making mistakes, but getting tasks done for their employer.

The ability to work through adversity, have some confidence, learn quickly, and be effective are valuable skills. Those data professionals that can do so often find more opportunities, challenges, they grow their skills, and get more compensation. Those that find reasons to avoid learning, that lack confidence in their ability to find a way to solve a problem, or are unwilling to tackle challenges often stagnate a bit. I’d like to think there are more of the former than latter in this business, but I constantly seem to find people that just look to repeat the same work they’ve done over and over for a long time.

It can be mentally difficult to start a project using technology with which you have little familiarity. It can be disconcerting to have someone ask you a question that you can’t answer because you’ve barely begun to learn. That ability to muddle through, to keep learning, accepting that you don’t have answers but can find them, knowing that some of your answers will be wrong and you’ll need to backtrack. That ability to muddle through will serve you well.

I’d urge you to develop it.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.0MB) podcast or subscribe to the feed at iTunes and Libsyn.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

2 Responses to Muddle Through

  1. Chris Fair says:

    I’ve always thought that the ability to muddle through things was almost a required trait of an IT professional. Like you, it’s something I’ve tried to cultivate in my career and has served me well in my numerous positions, and I take pride in that ability and make it one of my key selling points when I’m looking for a new position. I’m never going to have all the answers, but I have plenty of ways to find them and the tenacity to stay with a problem until it’s solved. And once it’s solved, I try to do a personal debriefing and learn more about what happened, how and why the solution works, and look at it as an opportunity to grow professionally.

    • way0utwest says:

      I think it’s required, but I’ve seen so many people that are hesitant to muddle through, almost as though they think they need to be completely qualified before tackling some new project/technology.

      I guess that’s what separates those that have more success from those that have less.

Comments are closed.