Category: Editorial

I wrote recently about a bad first day for an intern. He/she was fired, without cause in my opinion, when a production database was damaged while following a document for developer setup. The situation felt like a mistake, and one that wasn’t necessarily the fault of the individual. To me, this was extremely poor handling of the situation from a CTO.

In the discussion for the piece, someone pointed out that it might not just be a new employee that makes a mistake that causes downtime. Certainly an unexperienced employee could have caused the issue, but I know there are people with lots of time in a position that make similar mistakes. It could be that someone that has been there a long time followed a poorly documented procedure, or applied the procedure to the wrong situation.

In sports and the performance arts, I’ve heard a saying that says: amateurs practice until they get it right, but professionals practice until they don’t get it wrong. It’s the difference between just gaining a skill that you complete and continuing your learning to ensure that the execution of that skill is ingrained into your being. You internally build the muscle memory and skill to complete a task correctly over and over with practice.

In the database world, this might be the difference between someone that has restored a database (the amateur) and someone that regularly practices restores of not only full database backups, but differentials and logs, tail log backups, filegroup restores, and more (the professional). The former has a skill, but the latter is confident and likely to complete the skill in a variety of situations without error.

Practice won’t prevent mistakes, especially under pressure, but lots of practice does help us learn how to perform better. We learn what options are available, what issues might arise, and which choices we should be making. Just as professional athletes and musicians can make mistakes, we can as well. However, those mistakes should be rare. We should get most things right as the product of numerous hours of working deeply in, and understanding, our craft.

Steve Jones

The Voice of the DBA Podcast

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

I’ve worked as a technical person for most of career. I’ve often been responsible for building or managing systems, and ensuring they operated according to some set of requirements. If things didn’t work, I’d have to fix them, but often there wasn’t the threat of losing employment unless I was grossly incompetent. If I made a strong effort, I’d get other another chance, or maybe be shuffled to work on some other application or system.

Throughout my career, I have worked with various salespeople in different companies. Either they were my customers/clients or they were just co-workers. However, they operated under a different mindset. Most salespeople are expected to make a certain amount of sales in a time period, and if they don’t, they may be let go. In fact, in quite a few companies, a salesperson couldn’t miss their target more than two time periods in a row without finding themselves out of a job.

I realize that sales isn’t like the creative work that developers do, or the tedious work of managing systems, but what if we were treated like salespeople? Do you think you’d want to work in an environment where you had some quantifiable measurement, such as uptime for a quarter, plus tickets closed, and if you couldn’t meet the goals, you’d be let go from your DBA position?

Imagine if you were a developer. You might have the demand that you meet the expectations for delivery and you are held accountable for estimates within some amount of variance. Perhaps as a developer there would be a requirement to complete xx amount of stories in some time period. I don’t this would work well. I think we’d try to make longer estimates and more granular stories to better define out work, but I’d also expect the business might press back and put more pressure on us.

In plenty of organizations, there are these pressures. I certainly see developers working harder to get things done, not because of the threat of their job, but because many of us that choose technical work feel a sense of pride and responsibility in the work we do. We work long hours to meet deadlines, sometimes because we’re afraid not to, but usually we do want to complete our projects in the best way we can.

I think we’d all be worse if we were treated like salespeople, and likely many of us would have more job changes. I also think our organizations would suffer more, with higher turnover and a lack of detailed institutional knowledge among those that build systems. Certainly some high performers might thrive, especially if we received large bonuses, like salespeople often do, but I also think we’d find shoddier work overall, with applications even more cobbled together with patches and prayers, with the hopes that our workload doesn’t overwhelm our systems.

I know I wouldn’t like working in that type of environment, and why I’m not sure I’d ever want to go into any sales role.

Steve Jones