Voice of the DBA

Category: Editorial

  • Accept Failure

    Failure is sometimes an option

    We don’t expect ourselves to be perfect, do we? Is there ever any project you tackle that you might not complete? Is there a doubt that it might not work as expected, or that it may need substantial rework? I think that the vast majority of projects I undertake have some level of risk involved, and while I might understand that, I’m not sure I ever believe I will ever fail.

    Most things that I’ve built in technology don’t work the first time, and in fact, I expect that. I have learned from mistakes, corrected the problems, and usually finished them with some level of success. That’s the way that so many of us in technology approach our jobs. We start building, find issues, and then fix them.

    However you cannot every eliminate the risk that something will fail. There are times we need to abandon the project or abandon the work done and rebuild the software from scratch. Those failures should be learning opportunities, and should allow developers to improve their work. From my perspective it seems that too many managers, however, view failures as events that have to be avoided. Perfection and success are the only possible outcomes that are acceptable. One slip up and you may get fired.

    It seems that’s what managers think about their career, so they continue to push down dead end roads, and throw more resources at a project to recover some small level of success.

    We will always make mistakes. The true failure should come from failing to learn from the mistakes and improving your future work. If management cannot tolerate these setbacks, this problems, and allow for them, then the work will not only continue to be substandard, but people will spend more time worrying about avoiding blame than actually looking to improve their skills.

    I can’t tell you when work should be abandoned, or a project is hopeless, but every project ought to be examined periodically for this situation, especially when it is apparent that it is in trouble. You can’t save all projects, but you can learn to let some of them go, or change the situation, before it becomes a bigger problem than it is.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Happy President’s Day 2012

    Happy President's Day

    It’s President’s Day in the US, and a holiday for me, so I’m having a Daddy Daughter day in Denver, away from work. Hopefully most of you in the US also have the day off and are enjoying yourselves away from a computer.

    For those of you in the US, I hope your code compiles the first time, queries return quickly, and you enjoy the blooper reel I’ve compiled from the last few months.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Programmers v Salespeople

    Are sales more important than development?

    Last year my wife moved from a sales engineering position to a sales rep job with her company. It has been a bit of a challenge, but she’s enjoyed it, and it’s been good for the family. On top of a small raise, she has a large potential upside to her income as a sales representative. I’m amazed how much money some of the people in her company make from selling software and services, and I sometimes wonder how it works out.

    Recently I sent her this link about salespeople and commissions. It talks about the problems with commissions and the potential misunderstandings of what commissions actually do for our company. I know that some companies think paying salespeople flat rates and no commission is heresy. I know others that have transitioned to flat rates, including many retail companies, and they have continued to achieve high sales.

    As we debated the benefits of paying commissions,  we argued a bit about the relative value of the positions. She asked me if everyone received a salary, who shoudl be paid more. I said that I thought it was easy to replace salespeople in a company, so developers. My wife countered with “it’s easy to replace programmers.” So for a Friday poll, I thought I’d ask the tech people out there.

    Should salespeople make more than programmers?

    You can assume a commission structure, or salaries for everyone, but when you look at the value each brings to a company, and the ways in which they can help grow business, which is more valuable? Which is easier to replace? Replacing a top performer in either place is probably hard, but what’s your opinion?

    I still stand by the idea that it’s easier to replace salespeople. While I think selling is a skill, I think it’s one more easily learned by a wider variety of the population. I think programming has a fundamental mindset that is hard to teach.

    Or maybe it’s a larger number of people would be more willing to spend their days trying to sell something than sitting in a cubicle writing code.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Use Your Tools

    I used this tool for the first time and found it very handy.

    Someone asked me recently if I’ve ever exported a table using SQL Packager, a tool from my employer, Red Gate Software. I hadn’t, and in fact, hadn’t ever even opened the tool. So I started it up and exported a table. I was surprised how easy it was, and I wrote up a short blog on it.

    That reminded me of a common issue that many of us have: we get into a rut. It’s easy to stick to doing things the “old way” we’ve learned, and not updating our skills to take advantage of newer features.  It’s also easy to get used to going through a process one way and never trying, or experimenting with different techniques or applications of the tools.

    I have been guilty of this, and am trying to rectify it, working with new features, and trying out new SQL Server 2008 R2 or SQL Server 2012 T-SQL changes where I can. I noticed Grant Fritchey recently talking about Extended Events and the advantages of using them with deadlocks, and also using them for performance tuning. Learning Extended Events is an area I need to spend some time with in the future, and I’d recommend most other SQL Server professionals do the same.

    However it’s not just the changes in SQL Server. There are changes in tools from vendors that can help us do our jobs better, or even tools we don’t know we have. I have spoken with lots of Red Gate customers that weren’t even aware of the capabilities of the tools on their machines. In some cases they weren’t even aware they had the tools because they were purchased in a bundle. Not every tool is useful, and not always appropriate, but it’s worth a little time investment to learn how to use the tools and gain some awareness of their capabilities.

    We publish some information on the Red Gate tools at SQLServerCentral, and I constantly find great blogs written by people that actually use the tools in their daily work. I suspect that’s the case for other tools as well. Take some time and read about the tools you own, and even the ones you don’t. You might find one that will actually save you time, make your job easier, and provide a nice ROI for your company.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.