Tuesday, April 08, 2008
Old habits die hard, but occasionally it is good to look at them and see if they still make sense... When I started writing code, many moons ago, it was ingrained into my work habit to create or update a comment block at the top of the code file. This may be a foreign concept to some of you, so let me describe it. Typically this would include information about who was the original author, date it was created, a description of the purpose of the code, and a change log. The Change Log part of the comment block is where developers would enter their name or initials, the date of the change, and a description of what the change was that they were making. Sometimes it would have a reference number to cross reference their changes to a bug-tracking system. This comment block would appear at the top of any type of code file, whether a SQL Script, a web page, or source components that were eventually compiled into DLLs and the like.
Fast-Forward to today where much has changed. All the world seems to want to be faster and more Agile. We have tools that tell us more about our source code than ever before. For example, in our office, we use SourceGear Fortress as a big part of our ALM process. With Fortress, I of course have my source code history and can easily run a Diff to see what changes were made between two versions, and by whom, based on who did the check-in. Also, we require linking all code check-ins to an item in the item tracking side of Fortress, so I can easily look up the details of the bug or enhancement that led to the change. Conveniently, I can also see a list of all the source code files that were changed for that item.
So, the question arises, with all that the Fortress tool is doing for us, is the comment header block, or at least the Change Log portion of it, of any value anymore? I could see where you might still want the description for the file, but when it comes to your .NET code, maybe just the comments in front of each routine are sufficient (although some argue that you should do away with those, too).
Maybe I'm just slow to the party to rethink this one, but I'm curious what others think about it, especially those of you who have, or at one time had, this habit too.
Thursday, January 31, 2008
Now that I have had the "pleasure" of filtering through numerous resumes looking to hire someone, my thoughts on certifications has evolved a little... Or it's probably more accurate to say that they have been solidified.
Acrimony
Anyone who is active in the community is well aware that the topic of whether to pursue your MCDBA or other certification is hotly debated. Are things a little too quiet in the office or on the discussion boards? Just throw out the "innocent" question of whether it is worth pursuing certification and things are certain to get lively for a while. It ranks right up there with abortion, evolution, and Sean Connery vs. Roger Moore as topics guaranteed to get the sparks flying.
As for the MCDBA, the argument often breaks down into the following points:
- "I know plenty of people who have their certification but I wouldn't trust them to organize my pencil collection."
- "I know plenty of people who do not have certifications but are sheer geniuses in SQL Server."
- "All the MCDBA proves is that you know how to give the official Microsoft-approved answer."
My tendency in the past has been to come down on the side of "certification doesn't guarantee you know squat about databases in real life, but it probably doesn't hurt to have it on your resume when you're looking for a job." And guess what? I was right.
Hiring in the Real World
Here's how the screening process goes at my company. I tell the HR person (recruiter) that I am looking to hire someone and I send her the advertisement that I wrote which contains all the acronyms and buzzwords we are looking for. (Note that MCDBA is never on this list.) The recruiter then makes sure I didn't break any laws, puts our corporate intro or conclusion on it and gets the word out. This may mean working with a Staff Augmentation firm or posting it wherever her experience indicates we tend to get the best responses. She collects the responses and filters out candidates based on non-technical issues. For example, if we get a resume from someone who is international and we are not planning on sponsoring, then she weeds those out. Or when we get resumes from people that do not include any of the acronyms I specified, out they go too. There are a handful of reasons that a candidate is immediately eliminated, and she does a great job of that. She also does a good job of running interference with the StaffAug companies that want to send us every person they have riding the bench, and asks me for clarification of requirements when necessary.
But what our corporate recruiter absolutely does NOT do is make judgments as to someone's technical acumen. That is left to me. And here is where we get back to the point of this post. I know plenty of people who have their certification but I wouldn't trust them to organize my pencil collection. And I know plenty of people who do not have certifications but are sheer geniuses in SQL Server. BUT, when I do not personally know the person whose resume I am reading, and I am narrowing my list down for the first round of calls, and I have two candidates who appear to be similarly qualified on paper, if one of them has the MCDBA and the other doesn't, then the certificate gets called before the non-cert.
Why?
But Mark! You just said that certifications don't guarantee that the person knows anything! Yes, I did say that, and I meant it. But once I have sifted out the unqualified and am down to the situation where, I am looking at resumes for similarly qualified people, I do give one bonus point to the person with the certificate. Now hear me, I did not say that I would call every person who has their MCDBA, regardless of their experience. I'm talking about candidates that are nearly equal in experience. The certificate earns a bonus point because I know this much... you are serious enough to spend the time and money to go through the testing process, and you not only persevered, but you prevailed. (How's that for a little alliteration?) And for all that hard work, your reward is that you get called before someone else who otherwise would be tied.
So, should you pursue the MCDBA or not? Well, that's up to you to decide but here are a few key considerations:
- If you are job-hunting, it may help you get the interview, but probably won't get you the job (except for #2 or #4 below).
- Some companies are required to have a certain number of certified people on staff, and this could help you.
- Some companies pay more to people with certifications (we don't, but some do).
- While studying for the exams, you just might learn something new that lets you solve somebody's problem.
Those who really know me can tell you that it is the last one that would be the biggest consideration for me. Anything you do to learn more will help you grow and meet the needs of your current or a future employer. And that's what it's really all about, isn't it? Whether you can meet the need.
UPDATE: I stumbled across my own posting from four years ago on this topic. HA! I forgot I even wrote about it back then. But back then, I was an independent consultant. Now I'm a manager.
Monday, January 28, 2008
I knew in my heart that this was true. I had heard it several times, but darned if all of my personal tests just seemed to support the idea that the result set was always returned in order by the Clustered Index fields. But now, I have the proof I have been seeking!
In a comment to my How to Return Record #n post, Hugo Kornelis posted a link to his own post with the evidence (and later an explanation). I thought this was such a big deal that it deserved to be highlighted in a primary posting for the benefit of all those who missed his original post, only read the RSS feed and never follow the comments.
Thanks, Hugo!
Thursday, January 24, 2008
I got this question in email a while ago, and it seems to come up quite a bit, which frankly surprises me. I guess it's because I almost never* write an application where I need to retrieve the 10th (or whatever number) record. I am always trying to retrieve the record for Joe Smith, or Order Number 1256487, or the last record entered on 12/31/2007, or... well, you get the point. I am frequently searching for records based on a data value. But I rarely, if ever, have had to go looking for the nth record.
I see this question often enough that it makes me wonder if it isn't a school assignment somewhere. It sounds like the type of question you would get in school (or maybe in an interview)... "Write a SQL statement that will return the 17th record in the table." Or maybe it comes from people using Access where they had the FIRST() statement...UGH!
Of course the problem with this is that there is no such thing as the first, or 17th or nth record by itself. There is no guarantee in a SQL Server database (nor probably any relational database) that records will be retrieved in a particular order without the use of an ORDER BY clause**. And if you cannot guarantee the order that records will be retrieved, then the ordinal position of a record is completely useless.
Now, after all of that, if you still think that you have a need to get the nth record, here is my suggestion. First add your ORDER BY clause. And second, read Graz's article entitled What's After TOP?
* The one exception is where I want the SQL Server to handle paging for me instead of my front-end system. If you are in that position, then I suggest you do a search on the term paging on the SQLTeam web site. There are numerous articles about how to accomplish this.
** OK, someone is likely going to point out that if you put a Clustered Index on the field that you want it to sort by, that it will retrieve the data in that order. For a single table retrieval, you may be right, but I wouldn't bet my career on that always working out, especially when joining other tables with clustered indexes. Also, you will end up in a world of hurt if you rely on that mechanism and down the road your Production DBA decides to redefine the clustered index onto different columns for overall system performance.
UPDATE: Removed bad link and added some commentary.
OK, Damian, I get it now.
For those of you who weren't in the conversation, Damian (a.k.a. Merkin) was giving me a bad time about being a laggard in regard to Windows Live Writer. Well, I finally stumbled across more info I probably should have seen before, and now I get it.
Oh well, it just goes to show you that there is still nothing nearly as effective as a live personal referral to get someone's attention.
Tuesday, January 22, 2008
I know, we're already a few weeks into the new year, but I have been so busy with work and life stuff that I haven't been out here in a while, and it sounded like a good start.
I had dinner with Graz last night, and he off-handedly mentioned that I got passed by Mladen in blog post count, as if I might not already be aware of it. ;-) (Congrats Mladen! You are doing a great job and a great service to the community!) OK, seriously, Bill did encourage me to write some more, and suggested that I check out Windows Live Writer. I'm using it now to write this post, and I have to admit that I'm liking it quite a bit in just the little time I have used it. It is a good, simple WYSIWYG editor with options to write your post in either "Normal" text editor look or "Web Layout" which makes it look like you are writing directly in the way it will display on your blog, but without the top and side bars. There is also Web Preview so you can see exactly what it will look like when posted on your blog. And perhaps my favorite feature is to Save Local Draft so I can work on it, craft my words, save it, and come back to it later and edit one more time before actually posting it to the site. And, related to that, I can save drafts of multiple posts, so I can start topics that have been on my mind, and then come back to finish and post them later when I am ready. In fact I just did that to prove it works. I started a second post that I have been meaning to write for several months, and now I have the opening paragraph done. So, if you were like me, and just used the built-in post editor on your blog, go check out Live Writer for yourself. I think you'll like it!
And while I'm here, one more thing. If you are in a position where you communicate to non-technical management regularly, you should go read this article on the concept of Technical Debt. Apparently this phrase has been around for a while, but I just stumbled upon it today and I think it is going to be a very handy analogy to use.
So here's to the start of a great new year! I look forward to more writing this year than last (and hopefully you look forward to reading it).
Cheers!
Wednesday, September 19, 2007
A few months ago I was conducting interviews for a Production DBA position that we were creating, and an interesting thing happened...I ran into a candidate who was much like me a few years earlier. Unfortunately neither of us qualified. Here are some lessons from that experience...
Perhaps I should provide a little background for new readers. I have been a database application developer since about 1988 ranging from Info on minicomputers to Advanced Revelation and on to Oracle. I started using SQL Server in 1999 on version 7.0. I have a lot of experience in both the UI and database areas of development. I can hold my own when it comes to the responsibilities of being a Development DBA. A few years ago when I was doing a lot of contract work, I started looking for jobs with the title DBA in them. One of my great frustrations was running into interviewers who, I thought at the time, were inflexible and unwilling to give me a chance to prove myself. At the time, I figured that I was a fast learner and had done a lot of different things with SQL Server, so there shouldn't be much I couldn't handle or figure out (and hey, I always had my friends at SQLTeam to back me up, right?)
So as I was saying, a few months ago while I was conducting interviews, I ran into a guy who was just like I had been. He had good credentials for database development, was a great guy to talk to, and I had no doubt that he could learn things quickly. He was looking for someone to give him a chance. And right then I realized that I was thankful for the past interviewers who would not give me a shot.
Sound crazy? Well, if you have been reading carefully and you understand the terms, you know the problem. This guy (as I had been) was a good candidate for a Development DBA position, but I was seeking a candidate for a Production DBA position. While both are called DBA they have very different responsibilities. Basically the Development DBA supports the application development lifecycle and is generally focused on things such as normalization, naming conventions, constraints and keys, stored procedures and effectiveness overall. A Production DBA on the other hand supports the application after it has been deployed into the live (or production) systems. He or she is often focused on performance, efficiency, and reliability; including backups, replication strategies, serialization, locking and blocking. A Development DBA deals with the pressures of development deadlines, while a Production DBA deals with the pressures of C-Level executives screaming that every second it takes to fix a problem is costing the company umpteen millions of dollars.
So sometimes when you are out there interviewing, as frustrating as it can be at times, you need remember that the interviewer just might really know what he's looking for and you may not be the right fit. In our case, we needed an experienced Production DBA and were not willing to let a guy learn how to do his job on our time. We had an occasionally recurring nightmare that completely locked-up one of our mission critical databases causing about 50% of the company to come to a grinding halt. We already had two highly skilled, but development-focused SQL guys on the team who could read Books Online. We needed something different.
The good news for that candidate was that I recognized this while we were conducting the phone interview and I was able to help him see that I wasn't just being a jerk, but rather that I needed specific skills he did not have. So take a look at what your skills are, and either search for the jobs that fit you, or if you don't have the skills for the job that you want, go learn them as best you can. Maybe somebody is looking for a junior DBA that can join their team and grow into the position they want.
Tuesday, February 20, 2007
I'm sure I've written this before, but while I'm on the topic of interviewing, it bears repeating...
Do NOT confuse 1 year of experience repeated 5 times with 5 years of experience.
In the one, you have just been doing the same thing over and over, hopefully getting better at it, but not really growing. In the other, you are learning new things and growing, hopefully refining what you knew before based on what you are learning now, but at the very least, expanding the total area of what you know.
When a job ad says something like "5+ years experience" it is the latter, not the former, that they are seeking.
In my previous post about interview flubs, Jon dinged me in the comments for posting something that is too obvious. As he put it, "who DOESN'T know these?". Well, Jon, apparently a lot of people don't. I have been amazed at the things I have seen in my short stint as the lead interviewer for developers. (I alluded to this earlier, and last month it was finally made official that I am now the Software Engineering Manager.) One of the things that I have seen which I find really shocking is how much people misrepresent their skills. Oh sure, not everyone is intentionally lying. Maybe the problem is that they do a poor job of self-assessment. But if you're going to go apply for a job, you better get a grip on where you stand in your area of expertise.
Specifically, what I'm talking about here is the fact that in my phone screening I would ask people to rate themselves on a scale of 1-10 in several areas. When somebody rates himself a 7 or 8 in SQL Server, then I expect them to be able to fly through the specific technical questions we ask with no difficulty. We are not Microsoft, we are not conducting marathon interviews asking you to design on-the-fly solutions to real-life core business challenges, these are not difficult questions...certainly not if you rate yourself a 7 or 8 on a scale of 10. Yet time and again, I find people cannot explain to me what, if any, benefits they see to using Stored Procedures over in-line code. They struggle to explain the priciples of 3rd Normal Form, and we are not asking for the textbook definition, just give me the impression that you have a basic understanding of the concepts. We give them a basic problem with a subquery and ask them to rewrite it without the subquery. This is the classic example of using a JOIN and they miss it. We describe another classic example of when you would use a CASE statement, hoping that they can come up with that, yet they don't. I ask them their general impression of cursors and they have never heard of them! And they have the gall to tell me they are a 7 or 8?! Come on, get real! I'm not asking for you to explain the inner workings of transactional replication or to setup a Read80 Trace.
On the bright side, our simple questions are doing the job they were designed to do, which is to weed out the posers. I'm just astonished at how many of them there are. So here's my tip...Be honest with yourself and with the interviewer. I had a guy who was very honest with me that his SQL skills were not very strong but he was strong in .NET which was an additional skill set we were seeking. I really appreciated his honesty. I tailored the questions I asked based on that information and we had a great interview. I knew what to expect from him and he was right on. We were about to offer him a position because we knew what he could do and he had been completely honest with us, but unfortunately somebody beat us to it. But I'll tell you this, if I ever see his name come up again, I would not hesitate to give him another shot. That is quite unlike many of the others I have interviewed, who have no chance of working for us. And anyone else I know who is doing interviews, I would recommend they be sure to ask the detailed questions of those candidates so they know what they are getting.
For those of you who are already independent contractors, or thinking about taking the plunge and being your own boss, some good ideas and good humor awaits you at the
Escape From Cubicle Nation blog.