I’m a technical person. I teach technical Microsoft SQL Server classes and present technical seminars and answer technical questions on help forums. I write technical books and articles. So when someone from a technical magazine wants to interview me, during a break in one of my recent seminars, I am happy to oblige. Interview questions should be no problem, right? Not this time.
Although all my work is very technical, these interview questions were not. I was asked to compare feature sets of SQL Server and several of the competing database systems on the market, both more expensive products and free products. I was asked to guess how various proposed new features (some of which were in areas of the product that I never work with, such as CLR or Analysis Services) would be received in the marketplace and to predict future trends in the database industry in general (not SQL Server-specific trends). It was the hardest interview I ever sat through. I do not know much about any other database systems besides SQL Server. I do not try to “sell” SQL Server by convincing anyone that SQL Server is superior to its competition. I just try to explain how SQL Server works at a very deep level and let people make their own purchasing decisions. I don’t know everything about every single aspect of the SQL Server product line and can’t begin to comment on nonexistent features in technology areas that I don’t use. I don’t have a crystal ball, and I don’t know what going to happen tomorrow, much less several years from now.
I am well aware of the fact that there are non-technical people who try to talk about technical products. Sometimes the things they write can even be useful, especially when they’re describing the benefits and usefulness of new features with the intention of convincing (non-technical) management folks that they need to upgrade to a new version. But often, for technical readers, trying to read something written by non-technical marketing people is downright painful, and frequently it’s a waste of time. And sometimes it can be detrimental.
One of the oldest and most persistent examples I know of potentially dangerous marketing information originated way back when I was working for Sybase. One of the main messages that the marketing people had concerning Sybase’s stored procedure functionality (stored procedures were relatively new in the database world at that time) was that stored procedures are precompiled, and not having to expend resources on recompilation every time a procedure was run was a very good thing! I certainly could never argue that it wasn’t a good thing to conserve resources. However, there are many other reasons why stored procedures are a wonderful feature, besides saving on compilation resources. But more importantly (and more technically) there are times when the reuse of a precompiled procedure plan is NOT a good thing at all. This is as true today in Microsoft SQL Server as it was 22 years ago in Sybase SQL Server. And trying to explain to a nontechnical marketing person why using precompiled plans is not always the best thing to do is as frustrating today as it was then. (Hint: Have you heard of “parameter sniffing”?) I often have very technical students in class who have taken this marketing message to heart, and find it difficult to “unlearn” this idea and accept that sometimes reusing an existing plan is not good.
I understand not everyone can be, or wants to be, technical. And the world and workplace needs people who have skills that are not technical. And people who work in one technical area often depend on people with technical expertise in other areas. For example, when tuning a database system, I depend on the people with the operating system and physical hardware expertise and on the people with the application development skills. When writing a book, I depend on the graphics experts who can take my pencil and paper drawings and create beautiful diagrams and on the publishing staff who can turn my simple documents into a printed book. We need people with administrative skills and managerial skills. (But we could have another discussion about whether a manager of technical folks should have some technical skills in the same area as those people being managed.) So I don’t expect that everyone I work with needs to be a SQL Server expert or even needs to understand what a database is.
But it would be nice if someone interviewing me for a technical magazine, while I am in town giving an extremely technical seminar, would ask for something more than my predictions for future versions of SQL Server. I’m too busy (and having too much fun) working with the present version.
