An interview with Kirk Haselden
Kirk Haselden is the development manager for the SQL Server Integration Services Team at Microsoft. Kirk is also the author of the recently-published book, Microsoft SQL Server 2005 Integration Services.
Kirk answered the following questions by e-mail.
Doug: The Microsoft hiring process is legendary. What was it like going through all of that?
Kirk: Sleepless nights, cold sweats, anguish and uncertainty…! No, it’s not that bad really. The anticipation is worse than the actual experience. My first interview loop was a bit rough though. I actually interviewed with two teams. I had to arrive around 8am, which meant that I woke up around 4am mountain time to fly in from Salt Lake City. I didn’t eat any breakfast, and then, because of some miscommunication, neither team did a lunch interview. My interviews started at 9am and didn’t finish until 3 or 4pm. So, I ended up eating nothing for 13 hours and having 6-7 one hour interviews during that time. The interviews fried my brain and by the time they were all over, I was exhausted. Fortunately, I received an offer before going home and this made it all worthwhile. That was unusual. We try to make interviews a more pleasant, less stressful process. Some people actually enjoy interviewing because they do it well. One thing that isn’t widely known is that the interviews continue even after you’re hired. If you want to move to another group inside Microsoft, you have to go through the same interview process. So, for those who don’t really like being interviewed, it’s a barrier to moving teams. I estimate that I’ve been through 15 interview loops since starting at Microsoft. Frankly, I still don’t like doing them.
Doug: You’re a development manager at Microsoft. How would you describe your role and how does it compare it to similar positions?
Kirk: Development managers are responsible for the code. They manage anywhere between 3-8 development leads and a total of between 15-45 developers. Our primary responsibility is to ensure that the code that goes into the source tree is of top quality. We do that by ensuring that significant and effective processes and practices are used throughout the team. Quality assurance starts with the development manager.
Development managers also deal with some of the more common managerial issues such as morale, team unity, and hiring. Finally, their input into much of the technical and architectural activity for the project is highly important. The development manager’s role is greatly dependent on the needs of the team and also on the development manager’s own strengths. This creates differing priorities and styles of management between development managers – one development manager’s job is not necessarily like another. As it turns out, there are only about 20 or 30 development managers at Microsoft.
Development leads have smaller teams and are usually much more focused on technical issues. As well as managing the team they typically contribute to its code output. I believe that being a dev lead is the hardest job at Microsoft.
In large groups like SQL Server, development managers sometimes report to a director of development who is much more focused on long-term, strategic and architectural goals. They’re typically very technical, but don’t get involved much in the code. Directors of development are even rarer than development managers. In fact, there are probably only 9-10 directors of development at Microsoft.
Doug: When you program in .NET, which is your favored .NET language?
Kirk: Gotta be COBOL.NET! Seriously though, C# is my favorite, simply because I have a C, C++ background and it was a natural transition.
Doug: Microsoft has been very active in encouraging its employees to take part in blogging. I can see from your weblog that you are also as enthusiastic. What have you found to be the best part of blogging? The worst?
Kirk: The best part… Hmmm. I guess the best part is when people say thanks. When folks send e-mail saying, “Thanks, that really helped me get over a conceptual hump.” Or “Man, keep it coming, your blog really made a difference.” That’s always encouraging. When I first started blogging, I wondered if anybody would even read it. It’s the audience and their interaction with the blog that make the time well-spent.
The worst part is the time it takes to do it. The other part is that I get a lot of questions from folks who seem to not have done any research on their own because the questions are already answered in the forums or in my own blog. People sometimes find it easier just to send me an e-mail, rather than to do a quick search on the forum on the blog. This is really frustrating. I usually end up doing a search for them and then responding with the search result. I want to help, but I don’t scale that well :-).
Doug: SQL Server Integration Services (SSIS) serves as the successor to DTS, which had existed in a number of prior versions. What do you feel that SSIS accomplishes that DTS did not? Is there anything that you feel should not have been left out?
Kirk: SSIS has achieved a lot: scale, performance for real world data loads, better stability, more powerful data manipulation, transformation and integration, and an architecture on which to build that is superior overall. There are always things left out, otherwise we would never ship. I have my personal list of things I’d like to see in the next version, but we’ll have to see which ones make it into the product.
Doug: The SSIS user interface is a bit different from the prior DTS user interfaces. Can you tell me what the new interface is designed to address?
Kirk: It’s mostly about making clear which parts of the package are data flow and which are control flow. DTS munged them all together and I always had trouble deciphering what was what. SSIS is also more complex than DTS, so we needed a rich interface to express and support that complexity.
Doug: You have recently finished writing a book. How did you enjoy becoming an author? Do you have plans to publish more?
Kirk: It’s hard. I think if I hadn’t been married, had kids or a full time job, it would have been much easier. The most difficult part is carving out time to sit and write for extended periods. Once I did that, I found that actually writing the book was quite enjoyable. I kept track of every hour I worked on the book, so that now it looks like I might just break even at minimum wage once the book has run its course!
It’s also a leap of faith. All that time spent on something, and you have no idea if it will even interest people. Luckily, the response has been very positive, so I’m very pleased. However, early in the process when you have to make a choice between spending time with friends or family and ensconcing yourself in a dark corner to write, it’s hard to believe that it’s worthwhile. I often found myself wondering: “What am I, crazy?! Why am I doing this?”
Now that I’ve been through the process I think I could do another book in half the time and with half the effort. I made a lot of mistakes early on. I depended far too much on people and processes that don’t deliver, and I stressed about too many things that don’t matter in the end. If I do another book, I’ll probably not make such expensive mistakes. I would like to write another book. I’ll probably do the second version of the SSIS book when it ships again. I doubt I’ll do another technical book from scratch. I’m working on a few ideas for some novels and exposés. Time will tell!
Doug: Can you recommend any database related or general software books which you have read recently?
Kirk: I just read Jill Dyché and Evan Levy’s book: “Customer Data Integration: Reaching a Single Version of the Truth”. Jill’s an incredible writer; I also read her CRM publication. Evan is very knowledgeable in the CDI/MDM space. This is all demonstrated in their book. I also recently read Jack E Olson’s book: “Data Quality: The Accuracy Dimension”. Its mastery lies in examining how data quality diminishes over time and through which processes.
I have to say, though, that one of my favorite software development books isn’t about software: “A Timeless way of Building” by Christopher Alexander. At first glance, it’s about architecture, but the concepts can be applied equally to software architecture. The book is a fun read, because it’s well-written and presents a lot of interesting information. But it also explores the notion of patterns, elegant design and flow. Something architects of any persuasion can use.
Doug: What do you think about using VB.NET or C# for stored procedures, user-defined functions and triggers? What sort of guidance can you give to people who are looking to properly leverage the ability to use procedural code in SQL Server 2005?
Kirk: I think people should use what they’re familiar and comfortable with. The CLR integration creates one more possibility. Folks should definitely use the CLR features instead of XPs.
Doug: Many years ago, long after HTML was created by Tim Berners-Lee, I independently “discovered” markup languages, and was very proud of myself until I came across the much cooler, more thought-out HTML. My markup language involved lots of @ signs and was not terribly device independent; I hard-coded a lot of things that should not have been. Have you ever “invented” anything, and then discovered, to your horror, art that was better prior to your inventions?
Kirk: <Head hanging low> Yeah, I have. I wrote a graphical display language similar to HTML myself. It was much more concise than HTML, but not nearly as flexible or device independent. I also wrote a light version of a network device discovery and enumeration API before a colleague introduced me to WMI. What can I say…
Doug: For folks moving from DTS in SQL Server 2000 to SSIS in SQL Server 2005, can you think of any particularly cool tip or trick they might miss?
Kirk: Sure – you can still create and edit DTS packages in the SSIS environment. I show you how in my book! 🙂