Voice of the DBA

Category: Editorial

  • Why Can’t We Code?

    Today’s editorial was originally published on June 8, 2011. It is being re-run because Steve is on vacation.

    I think that most of the developers or data professionals out there have been through a variety of types of interviews in their careers. You might have had technical interviews that asked you to write code, or maybe you’ve been quizzed on SQL Server trivia or asked to explain methods and properties. Maybe you’ve had interviews with managers that had you define a few database terms. Perhaps you’ve just had someone ask you the ten common interview questions without requiring you to demonstrate any technical knowledge.

    No matter what you’ve experienced, I think that many people would agree that the hiring process needs work. It does a poor job of actually predicting if the new employee can produce quality code or manage servers. Why is that?

    Many companies have really tried to solve this. From the famous “How would you move Mt. Fuji?” questions at Microsoft to the common CS type questions at Google. Joel Spolsky has his own guerilla guide, which I assume has worked well for him, though on a much smaller scale. I think, however, that for the most part no one has come up with a good way to solve this issue.

    A friend sent me this piece recently: Why the New Guy Can’t Code. It’s a little heavy handed, but there was one quote in there that I thought made sense: “don’t interview anyone who hasn’t accomplished anything. Ever.” It’s so easy to set up your own website, design a database on your personal machine, even put an app out for sale, that there’s no excuse not to make some effort to accomplish something. Craig Farrall talked about building something in Looking for Work in SQL Server, as did Brandie Tarvin in Changing Career Gears. It’s also one of the things I talk about at the Modern Resume: show people what you’ve done.

    I don’t know that we’ll ever find a fool proof way to hire great employees, but hiring people that have proven themselves in the past, and can point to something they’ve done, is good start.

    Steve Jones

  • I Feel Like a Magician

    I ran across this comparison of SQL Server to PostgreSQL. It’s written from the point of view of a PostgreSQL developer, who certainly doesn’t like the Microsoft product much, with no shortage of complaints. Whether you agree or not, I do think there are a few valid points.

    However one of the quotes that really caught my attention was in the section on converting dates. The author says that “MSDN provides a table of these magic numbers.”, referring to the arcane and completely unintuitive format codes that we use with CONVERT(). Fortunately FORMAT() was introduced in 2012, and simplifies things, but still has issues and limitations.

    Certainly all systems and languages will have some codes and parameters that don’t make sense, left over from earlier times for backwards compatibility. However the more I look at T-SQL and SQL Server, the more I do find it silly that many of the small conveniences haven’t evolved across the versions. The bcp utility is outdated, functions haven’t been updated to work with more than 8,000 characters, SSIS has issues with CSV files, and more.

    It does seem at times that when I’m answering questions on the Internet that the answers I give, while logical and familiar to me, seem magic to others. This might be especially true when talking about transaction logs, which still seem far to difficult for many people to grasp.

    I enjoy working with SQL Server and look forward to a long career in the future developing software on the platform, however I do worry about some of the long term health of the platform for new users. It seems that the usability advantages of SQL Server have dramatically narrowed in recent years, and in some ways the other platforms have implemented features that SQL Server is sorely lacking.

    Hopefully Microsoft will focus on reducing the friction of manipulating data in SQL Server. Not that SQL Server will go away, but I can see companies migrating to other platforms if it becomes substantially easier and cheaper to manipulate data.

    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. feed

  • Half a Year

    Today is a holiday for much of the US workforce. Tomorrow is Independence Day, though we have another year until the sequel of the movie by that name. This is the day the US started down the road of becoming a country, and if you’re a US citizen, i’d urge you to take a few minutes and look back at our declaration.

    Half a year is gone in 2015. It’s amazing to think that this year is already halfway gone. At the beginning of 2015, we had little information on the next version of SQL Server, though we had a preview of some features, like Row-Level Security (RLS), in January. Now we have CTP 2.1 and a lot of features that are being added. We’ve added some jumpstart links for Learning SQL Server 2016, so if today is quiet, check out an area and learn a bit about what’s coming.

    We continue to see data loss incidents on a regular basis. It’s almost becoming a piece of news that we are desensitized to hearing. I’m not sure if it’s good or bad, but I don’t think the financial penalties are high enough to get companies taking it more seriously, or certainly not serious enough to ensure developers change their ways they build applications. If you doubt the issues here, read Troy Hunt’s blog. He regularly finds companies not implementing security well.

    All in all it’s been a good year for technology and it’s exciting to see many products changing, technologies maturing, and more options than ever for building software.  I hope you have a great holiday weekend in the US, and a pleasant one elsewhere.

    Steve Jones

  • SSMS Maturity

    I’ve used a lot of tools with SQL Server over the years. We had a variety of individual tools from Microsoft for SQL Server 4.2, including the isqlw query editor that I used for years. I wrestled with the Enterprise Manager MMC plugin and eventually moved away to use the Embarcadero suite to work with SQL Server before coming back to Microsoft’s SSMS in SQL Server 2005. I’ve had a love/hate relationship with that tool ever since, though the Redgate suite of extentions has certainly made life easier.

    However Management Studio (SSMS) hasn’t really evolved in quite a few years. It seems that the enhancements and additions that have been made with each version have been minimal, sometimes barely working and rarely improved across versions. It’s been disappointing that relatively few resources have been expended on SSMS, despite the regular evolution of SQL Server every 2-3 years. And despite the fact that one of the big reasons SQL Server was touted over Oracle and other RDBMSs is that the tooling was better. 

    I suspect some of the problems were the pressure to release the core parts of SQL Server first, and link SSMS to the server product, despite the fact that it really needs to support multiple versions and previous tooling should have been improved.

    That’s changing a bit. As Tim Ford noted, SSMS now has it’s own release and upgrade path. The tool should not have it’s own, separate download and lightweight installer along with a separate release cadence from SQL Server. I suspect this will evolve more rapidly, probably closer to an Azure like schedule, with more regular patches and enhancements. At least that’s what I hope.

    I was glad to see SSMS being made available for 2012 and 2014 versions as a separate download, and the change to a completely separate product that will likely become de-linked from SQL Server versions. I expect we’ll just have SSMS in the future, with some version that’s more like what we see in Chrome and Firefox. 

    For now SSMS is still based on the 2010 Visual Studio shell, but the comments in this announcement seem to indicate it will move to the 2015 shell soon. Let’s hope that happens and the performance improves along with the maturity of the tool in the future.

    Steve Jones

    The Voice of the DBA Podcast

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