Voice of the DBA

Category: Editorial

  • When Work Gets in the Way of Work

    It seems I find myself in this situation more and more. I’ve got work to do at SQLServerCentral. There’s a constant stream of articles to edit, content to review and schedule, questions to build, and of course, writing these pieces on data related topics. That goes on 220+ days a year, as we keep the site going and send a newsletter every weekday of the year.

    However the last few years I find myself crunched to get work done in my work week with the addition of other tasks to my routine. I’ve moved from 2-3 events and 5-6 presentations to 20+ events and closer to 40 talks a year that I deliver. Not only is there a high frequency of events, but there’s also a number of new presentations to build. It seems I have 3-4 (at least) new talks to assemble, which can be quite time consuming. That’s in addition to keeping SQLServerCentral moving.

    This isn’t different than many of the jobs I’ve had in the past. Often I’ve had a set of tasks that I need to work through regularly. Whether these were admin tasks, or development projects, I usually have found that I can develop a routine throughout most weeks. However things crop up. Bug fixes are reported, or hardware fails, or some other project takes some priority, but I need to somehow fit this into my week, along with everything I normally do.

    It’s tough, and I think far too many people with salaried jobs try to just work harder and longer to complete their work. That makes some sense for a short period of time (2-4 weeks), but after that it’s a mistake. Productivity declines and people burn out. They become cranky, and more importantly, they lose a substantial portion of their life over time.

    I’ve learned to push back when things become too busy, and while I’ve had managers that weren’t thrilled, even angry, almost all of them understood the problem and worked with me and others to change things.These days that means I cancel or skip events. More often I decline to accept engagements in the future to bring balance into life. 

    This month is tough, with a lot of commitments made months ago, and flying to the UK this week doesn’t help. However I’ve learned a few things about scheduling my time this year and hopefully I’ll do a better job next year.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Why Would You Move?

    I was reading a thread on Quora about why SQL Server is chosen by companies, and another on StackOverflow about why Oracle is a good choice. As much as I sometimes joke about the Oracle RDBMS, I think it’s a solid platform, and certainly wouldn’t resist working with Oracle databases if the opportunity presented itself. I like working with technology and enjoy learning about how different platforms work. However I also know that if I started working with Oracle, I’d be much less efficient, and certainly quite slower, in producing work than with SQL Server.

    I’d also probably make a lot of relatively poor decisions about how to run the database instance.

    I’m sure I’d get better writing PL/SQL, but that would take time. And in any setting, that also means that I’d be costing my company money while I learned the tricks, best practices, and skills needed to produce a well tuned, efficient Oracle-based application. It’s really no different than the way I have seen many highly skilled Oracle developers and DBAs come to work with SQL Server and try to treat SQL Server as if it ran the same way as Oracle (<shudder>cursors</shudder>).

    That’s why when I hear about companies making a quick switch to a new platform or language, I question the move. Certainly there are domains of problems that Oracle might solve better than SQL Server. There are situations where MongoDB is better than an RDBMS or Java makes more sense than C++, but there should be strong, solid technical reason why it’s worth trying something new. Not because a manager wants to save some licensing fees or a developer wants to try something new.

    By all means, experiment, but do so in small ways. Try new technologies with limited investments, and if they work, increase the investment. However for large projects, stick to what your staff knows best. Their skills are often the limiting factor in producing well written software, and in almost every situation, their salaries will far outweigh any cost of software that you license.

    Steve Jones

     

    The Voice of the DBA Podcast

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

  • It’s about Perception

    This editorial was originally published on Dec 9, 2009. It is being re-run as Steve is on vacation.

    It’s not just the code. Sure the code’s important, but it’s not necessarily the most important thing. It’s more than just the way something works, even if the code is written correctly and performs all the right calculations. That matters, to various degrees in different applications, but it isn’t the most important thing. The important thing is the way the application gets used, and the way the users feel about it. In other words, the perception of the application.

    The perception of all of our systems and the services we deliver is what really counts. I heard someone recently paraphrase a well known saying. I don’t remember it exactly, but it was something like “People never remember the quality code we deliver, but they never forget the lack of quality in our code.”

    That’s true, no matter what we deliver. Our users don’t remember the 500 days our database server ran without an issue; they remember the day it was down. They remember when our application rollout broke something or made them work more. And they definitely remember when the application is slow or doesn’t help them in their jobs.

    As an IT group, even as technologists in general, we have to  take this into consideration when we design and build solutions. Building great software doesn’t just mean meeting the specifications we were given to  the letter, or duplicating the functionality that we think is being performed or we think is needed.

    We need to make sure that our systems work with the user, that help the user and make their jobs easier. It has to provide some tangible benefits to the end user or they just don’t perceive it as being useful to them.

    I’ve rolled out applications before that had cool, new features that hadn’t existed before, or we had incorporated new functionality they had requested. But for some reason it didn’t work well, or smoothly, or the user didn’t understand how to use the system. The perception was that the application was a failure.

    None of us wants to be in that situation. We don’t want our work to go unappreciated. To do that we need to take the users’ perception into account when we’re designing and building software. We need lots of feedback as we go along and make sure we’re building the application the users actually want.

    Steve Jones

     

  • Mercenary

    I was listening to a few people talk at an event about the software they were working on. For some of them, there was a true passion in solving the problems they faced. However these weren’t applications that eased poverty with cleaner water, or more efficient transportation. These weren’t applications that dealt with medical issues impacting human health. In many cases these were simple, consumer applications that entertained people, but these developers were quite proud of the applications they worked on.

    However the challenge of practicing their craft well elicited quite a bit of passion from these developers. They not only took a lot of pride in building an efficient set of methods in Java or C# quickly, they really enjoyed the process of taking a development task, writing code and tests, and delivering software that worked. They would even find pleasure in receiving a bug report, finding the issue, and delivering a corrected version of code. Most of all, however, they believed their software was making the world better in some way.

    There were also plenty of developers that didn’t really care what they worked on. They didn’t find anything special about software development, and were happy to get assigned a task, write some code, and deliver it. They weren’t looking to produce shoddy applications quickly, and many of them were talented developers. They just didn’t much care where they worked or what the function the software performed.

    Is this you? Are you willing to work on whatever application comes your way? Or do you have a passion to build something in particular, to work on projects that have some meaning to you? I think I’ve usually been one of the former, willing to work on any application. I’ve always been more concerned about the coworkers I have than the project we work on, but there are times I’ve felt our applications were a little special, and made a difference in some way.

    Without a doubt I think most of us would prefer to work in an area that means something to us, an area that elicits some passion. I just wonder how many of us actively seek out such positions or projects.

    Steve Jones

    The Voice of the DBA Podcast

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