Like most everyone who works hard in our industry, I’ve run into more than a few conflicts trying to balance work and life. Personally, the further I progress in my career, the blurrier the lines become between work time, family/me time, and just plain lazy downtime. It’s quite easy to say that you’re going to spend X hours at work, and the rest of the time is mine, but the reality is that that this rarely occurs as planned. Systems break down, executives create last-minute projects, direct reports need attention, and a thousand other things have a way of derailing your plans to be home in time for The Office. Further, it’s terribly easy to keep working even while physically separated from the workplace; VPN and mobile connectivity are great tools but make it very easy to forget you’re actually at home.
To help me make sure that I get a sufficient amount of downtime, and frankly, to keep myself out of the doghouse at home, we’ve set up two family nights a week. Wednesday and Saturday nights are now sacred, reserved for the members of my real “core team”. We have agreed, barring any real work emergencies, to disconnect completely on those nights and spend time together playing games, going out for the evening, or just hanging out. This is a new approach for us, one that I am optimistic about, and I’ll be glad to share the results in a few months.
I’d be interested to hear any other strategies to deal with this. How do you keep your bills paid and your career moving forward while reserving enough time for yourself and your family?
When I talk to other SQL Server professionals, I’m often surprised at how many do not have any involvement in their local SQL Server user group. As best I can tell, the problem is not limited to SQL Server types – many technical pros do not even know that there are user groups in their area, much less participate in any of them.
Local user groups are incredible and underutilized resources for technical professionals. Most active user groups meet monthly, generally in the evenings or on weekends, and most are free. These groups are not closed social groups as some may perceive, but are quite accepting of newcomers. In all but the largest user groups, everything is run by volunteers, so there are opportunities to get your hands dirty if you feel led to give back to the community. These groups offer a venue to share ideas, socialize with fellow techies, and some informal peer technical assistance. If you are looking to improve your presentation skills, most groups are open to new speakers at group meetings.
If you’re not already involved, I encourage you to check out one or more local user groups. I’ll take the opportunity to plug my local group, the North Texas SQL Server User Group, which meets at the Microsoft headquarters in Irving on the 3rd Thursday of each month. The PASS website also has a domestic and international list of recognized chapters of SQL Server users.
I was tagged by Grant Fritchey (aka Scary DBA) in the latest get-to-know-you question. This one asks, “What do you wish you had known when you started?” I could go on for hours about the things I wish I hadn’t had to learn the hard way, but here are the highlights. Apologies to those who were tagged before me if I repeat their points.
It’s OK to make mistakes. It’s also OK to admit it. There are two types of people in this world: those who make mistakes and fess up, and those that make mistakes and try to cover it up. Everyone – everyone – makes mistakes in their jobs, and in life in general. While there are some high-profile mistakes that are notoriously noteworthy (airline disasters, medical errors), the vast majority of us are permitted, and even expected, to make a few errors here an there. As long as you can learn from your errors and not continue to make the same mistakes, it can be filed under the “Valuable Lessons Learned” heading. Further, those whom you work with and for will have more respect for you if you admit your errors up front, especially when you deliver a plan for resolution.
Technical skills are not enough When I started out, I had my mind set on simply learning a craft, fine-tuning my skills to become one of the best in the field, and keeping my head down and working hard for the next 40 years. While it is important to grow and learn hard skills, today’s economy is not friendly to the stereotypical technical geek working in a dark basement and slinging code (or monitoring logs, or building desktops, or whatever). To be successful, you’ve got to break out of your technical world every now and again and interface with nontechnical people. Spend half a day shadowing one of your end users to see how the systems you build/support help them to do their jobs. Spend time with senior management and executives to find out what big-picture goals they have, and how you help get the organization there. Have coffee with someone unfamiliar with technology and learn how you can ease them into the digital age. Most importantly, get to know the overall goals of your organization/clients/customers – you’ll be far more successful in the long run.
You are responsible for your own career development Technical careers require constant learning. Training, college, and conferences/trade shows are great ways to learn and network, but many companies can’t or won’t fork over the cash for these career development events. The bottom line is, it’s up to you to take charge of your career. A few thousand dollars for conference fees can be painful, but it could be argued that you’ll easily recoup that investment over the course of your career. For those who truly are budget strapped, there are tons of free career resources; user group events, online references (even videos!), libraries, and volunteer opportunities are all cost conscious ways to build your network and skillset.
Don’t try to be an expert in everything There are generalists, and there are specialists; nobody can be an expert in all things technical. Find something that you enjoy doing (that statement alone should be a bullet point), and become an expert in that thing. You don’t have to specialize to the point that you’re a niche player, but you can limit your scope such that you can be known as an authority in your chosen area.
Don’t take things too seriously I almost didn’t type this last one for fear that I would portray myself as having a lackadaisical attitude toward my career; nothing could be further from the truth. We’re all human (see #1 above) and are limited by a number of factors, including emotions, limited energy, family commitments, and natural abilities. Don’t be a stickler for absolute perfection; accept that some things are part of live and unchangeable. When obstacles block your path, don’t freak out or become the voice of negativity; take a breath, smile, and know that, if it was easy, everybody would be doing it and our skills would be far less valuable. Address problems or deadlines with a sense of urgency, but don’t let your commitments consume you to the point that you spend all of your time working.
Again, I could go on for pages on this topic, but these are the lessons I’ve learned the hard way that stand out in my mind. Now, to keep this thing rolling, I’m going to tag Jack Corbett, John Magnabosco, and TJayBelt – not sure if TJay reads my blog, I suppose I’ll find out shortly :)
I’m on Day Two of the Get Fit in February Developer Challenge. This month-long competition boasts around 200 participants who are vying for some nice prizes to the fittest of the fit. Judged in 3 categories – total weight lost, percentage of weight lost, and most active participation – the winners can claim one of two Zunes or an MDSN subscription.
So I’m committed to this thing… here’s my starting point. I’m at 183 as of last night, which puts my BMI squarely at 27, making me technically overweight. My goal by the end of the month is to lose 12 pounds, which would land me at 171 by the time March arrives. Beyond that, I’d like to trim down to an even 160, but we’ll reevaluate and set further short term goals once this challenge is done.
My plan goes something like this:
So I’m a full day into this thing and, excluding last night’s Super Bowl party, I’m doing quite well. Tonight’s dinner was Special K cereal and a banana, and I pounded out 20 minutes of 10 degree climbing on the treadmill.
Now this is a technical blog so I’m not going to post all of my weigh-ins or notes here; I will follow up here with a single final results post at the end.. If you’re interested in my progress or the event as a whole, visit to the Facebook group for this challenge.
I’ve seen a good deal of coverage recently that is geared toward those who have recently begun a career as a database professional. Brad McGehee posted this week about some potential topics for a book for new SQL Server developers, and Craig Outcalt is publishing a series of articles on SQLServerCentral.com aimed at new DBAs. Brent Ozar also has a meta page on his site that has links to a number of publications that are helpful to newbie database gurus. Good information all – in fact, one of Craig’s articles was so good that it was plagiarized earlier this week.
There are a lot of folks interested in careers as database professionals, and for good reasons. For starters, experienced DBAs and database developers earn well above average wages: the annual Redmond Magazine Salary Survey reports that that the average base salary for a DBA or Database Developer is $81,495, while Salary.com reports the median salary at just over $84,000. Next, anecdotal evidence suggests that the number of opportunities for experienced database professionals will continue to increase, recession notwithstanding. In addition to the tangible benefits and growth, a career in database management can be highly fulfilling given the right circumstances. Although the hours can be long at times, DBAs and database developers generally work in comfortable and safe environments, and are presented with an interesting array of challenges that keep the job from getting stagnant.
So from the outsider’s perspective, how does one get started as a DBA? How does one make the jump from helpdesk/analyst/cashier to a career in database management? If you ask ten people that question, you’ll likely get ten different answers. Like many jobs in IT, there is no clear-cut career path to becoming a DBA. A college degree always helps – in fact, many employers will only consider degreed candidates. Also helpful is a solid understanding of underlying technologies, including networking, DNS, hardware, OS, and web architecture, among many others. Of course, experience is king – even the most junior database professional must have at least some experience actually performing database administration tasks.
I’ve been asked a couple of different times recently how I got into “the biz”. In my next post, I’ll share my experience in the hope that it can help someone else crack into this industry. In a later post, I’ll share my recent commitment to take it to the next level, an ongoing process that will hopefully lead to many good things down the road.