The Dot Com Bust - Part 2

  • Comments posted to this topic are about the content posted at

  • I do laugh at the last thing about DBA's lasting longer. find where I work and a few other large corps around here that the job title DBA is a joke. Most "DBA"s around here do nothing more that handle access issues. They do not even troubleshoot issues nore do they setup maintainence. That is generally left to the developer and the NT sysadmin folks to handle. They don't even have a hand in setting up SQL. Oh well, if anyone starts loping in my area they generally start with the titled DBA group, we lost about 15 over the past year for cut backs. Fortunately it was done thru attrition instead of layoffs. Means you quite or move they just don't backfill the position. I would have to say DBAs may or may not be safe depending on what you actually do.

    "Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)

  • I think Steve makes a good point about spending your political capital wisely. Along with that make sure you're visible, not sequestered in a dark corner office somewhere! Perceived contributors will also generally last longer.


  • jon,

    Creepy!! I am looking atround th office right now to see if you are here & writing in cognito!!

    I've always thought that certain people ge t promoted out of the way, but never thought about who they may take on!! The other problem with the corporate way is that the demarcation of areas of responsibility are too rigid. Everyone wants to do things in a way which suits them without a thought for the bigger picture.

    Still, at least we get 25 days holiday a year! I hear that in America and Canada get a lowly 10 to 15 days!!

  • Excellent article Steve, we're seeing a way worse situation in Britain, especially in the development sector where there's 50% of programmers out of work.

    This is mainly as a result of our woefully out of touch government thinking there's a skills shortage, and opening the flood gates for anyone who's seen a PC to come into the country.

    Sadly, older, way more experienced, quality people are being ignored by recruiters here, because companies can get someone who isn't up to doing the job, cheaper. All good old fashioned false economy. But then idiots never learn, by definition. And they wonder why their projects fail.

    We're also seeing alot of Visual Basic developers who have maybe used Enterprise Manager a few times applying to be DBAs, in the hope that they can pull the wool over the interviewers eyes.

    I've interviewed two dozen people for three DBA positions in the last 18 months, and I've asked them some VERY simple questions first which every DBA should know in order to warm them up, and guess what? 8 out of 10 can't answer them. And that's after we've rejected the obviously hopeless CVs. We had one guy who was apparently an MCDBA, who didn't even know what the two types of indexes are that you can create on a table !! <And for those developers who are reading this and about to look it up for your next interview, that one's off my list now 🙂 >

    Now I know rates drop in a recession, but we're getting many unscrupulous, major IT recruitment agencies and companies advertising jobs at £10-£15/hr, where £35-£40/hr would be usual. Because they know that if they can't fill the position within a month, our immigration rules say we can then advertise it outside of the western european union area. And guess what? No one on home soil bites. They'd be better off working a check-out in the local supermarket. So we end up paying lots of social benefit to unemployed IT people, whilst the companies get someone "cheap", who in my experience of interviewing them, hasn't got the first clue. Really worrying situation, and going by what happened in the 1970's, many qualified, experienced IT people will leave Britain permanently in another brain drain and never come back - myself included.

    The other problem we have here is incredibly stupid management. Scott Adams would have material for life. In Britain, if good technical people want more pay, they have to move into management (d'oh), so the company looses their technical skills and invariably gains a not-too-hot manager. Or, if you can't stomach the politics, you move elsewhere and your company quite justifiably looses your company-specific knowledge and has the cost of finding someone else. We also have a corporate culture where we promote people based on how dangerous they are - ie : techies who are clueless or incompetent get moved swiftly into management, where they can't touch anything critical, and because their management are in turn too spineless to sack them. In their new role, they then become the incompetent who does the hiring and get the wool pulled over their eyes by even more incompetent "technical" people who can interview well and can talk the talk rather than do the job, exacerbating the problem even more. So we end up in a vicious downward spiral. Hope you guys in the US do it better, because this country's on a steep downward dive which we're not going to get out of. As a piece of advice, if you've got a brain, forget coming to Britain, you won't be appreciated or paid well. If you can get a job in IT that is.

    Jon Reade


  • I switched jobs in May 2000 from a good size stable company to a dot com called At the time people at my previous job were concerned that I'd soon be out of a job. As for me, I just saw the $13,000 more a year in salary and the extra challenge the job would give me and took the job.

    As life turns out, it was a good decision. I still work for as a SQL programmer and don't feel my job is in danger. The company has stopped hiring, except to replace people as they leave. A couple months ago, our other SQL programmer left. Our company took one of our VB programmers and designated him as a VB/SQL programmer. He now spends most of his time doing SQL stuff and on occasion works on VB. We then hired another person who is also designated a VB/SQL programmer. He hasn't worked on any VB stuff yet, since we have been very busy with new SQL developments.

    Robert Marda

    SQL Server will deliver its data any way you want it

    when you give your SQL Programmer enough developing time.

    Robert W. Marda
    Billing and OSS Specialist - SQL Programmer
    MCL Systems

  • My story, for what it's worth...

    Got laid off in March. Went on active duty with the Air National Guard 3 weeks later, so that took me out of the job search. Now, I'm two weeks from going home and I'm starting up my job search.

    I've sent out my resume, made a bunch of phone calls and I've found a few possiblilites. I live in the Minneapolis - St. Paul, MN area, which wasn't killed by the Dot-Com meltdown. So that is a good thing but I'm not getting my hopes up. I'm expecting to have to put in some serious work and time to get my next job.

    One thing I have noticed is how many SQL Server positions here in the Twin Cities want someone with OLAP experience and of course I don't have any (But I would love to learn!)

    One thing about getting laid off...companies do use it to clean house, but many times it may have nothing to do with you. Even if your boss really likes you, if he has less power than his peers, you could still be out the door.


  • This is a great article. Certain DBAs are reevaluating their skillsets as a result of the next release of SQLServer, Yukon. Yukon will be deeply integrated within the .NET Studio Development environment, and will be built around the CLR. For instance, it will be possible to write stored procedures using C#.

    Some DBAs could become obsolete quickly if they decide to ignore the software development implications of Yukon. Suddenly, developers that are simply playing with SQLServer 2000 today, could slowly become the best positioned DBAs of tomorrow.

    Now is the time to investigate on how to use .NET, how to develop basic applications in Visual Basic .NET for example, and get ready for the wave that Yukon is about to bring to the DBA community.

    Herve Roggero
    SQL Server Database Proxy/Firewall and Auditing

  • I totally agree with Herve Roggero comments above about .Net. I've picked up a Beginning VB .net book and have started to work with it. All SQL Server DBA's and developers need to learn about .net...or get left behind.


  • > All SQL Server DBA's and developers need to learn about .net...or get left behind.

    Okay, I'll bite. There are a couple of posts in this thread urging me and other DBAs to "be there or be square" with regard to .NET. Who knows, maybe this time the doomsayers are right. Unless I get on the bandwagon NOW!!!! and get with the program on .NET, I'll be selling apples on the street corner in three years, while some pimply teenager gets stuck maintaining my databases.

    But first, a word from reality...

    1. The principles of database design and SQL are not likely to change that much in the next twenty years. Incrementally, yes. In a revolutionary manner? No.

    2. Database is a big enough chunk for most people to bite off. Lord knows it keeps me busy. It's likely I'll learn a few things about .NET that a database guy needs to know, and leave becoming an expert in it to those with a need to know.

    3. Most programmers do not find database very interesting, and thus have mixed results when designing schemas. It isn't likely that .NET is going to make programmers love database more. Which is fine... more work for me.

    4. The rush to learn the latest technologies can keep one way busier than necessary. I've been in this business since 1984, and here, in capsule form, are some of the highlights...

    a. Learn DB2 or you'll be unemployed in two years.

    b. Learn Unix or you'll be unemployed in two years.

    c. Learn to program in C or you'll be unemployed in two years.

    d. Forget C, learn to program in C++ or you'll be unemployed in two years.

    e. The real wave of the future is top-down structured design. Pretty soon, we'll be forced to adopt it, and those who don't will become dinosaurs.

    f. Scratch that, all real programmers are learning Warnier-Orr diagramming. It's catching on -- EDS uses it -- and pretty soon all programmers will be forced to learn it.

    g. Object-Oriented Design will soon replace all procedurally-oriented code, and those programmers who can't learn the new paradigm will find themselves out of a job.

    h. Distributed client-server applications (i.e., "fat client") are the way things are going, and woe to the programmer who can't understand the concepts of networking.

    i. Client-server is an outmoded architecture, as the configuration costs are too high. Thin client is the latest thing....

    And ditto: Ada, Pascal, Java, Perl, object-oriented database, AI, code generators, OLAP, Power Builder, C#, etc., etc., and etc.

    Some may counter that I'm enshrining ignorance. Hardly. I just have a healthy enough respect for what I do that I know I must pick my battles.


  • Completely agree Lee - it's usually curtains for any project when a developer turns DBA and tries to design databases, let alone administer them. I'm working on a project where we've just inherited a big software development from a team where the DBA/Database designer was a developer, and it ain't pretty. As to using a procedural language to manipulate data that is best manipulated using set based operations, well.... sounds to me like developers being ignorant of how inefficient it is for a database engine to deal with data on a row-by-row basis (I'm not targetting this at you Herve, as I've heard this claim myself previously, but at the marketing behind Yukon). Why would anyone WANT to use a mutated C derivative to do what SQL has been doing really well for decades? Beats me. Just because you *can* do something doesn't mean it's a) efficient b) productive c) elegant or d) easy to understand or maintain. Small, simple but damned important points which the 'gee-whiz' brigade pay lip service to, and why so many projects fail.

    Gotta go - off to code a few web pages in assembler - it's SOOOO fast....see y'all in 2004.

    Jon Reade


  • I also agree with Lee and jonreade. T-SQL has a very simple syntax and few semantics (not sure if that's the right word) relative to VB's/C's... object models and programming interfaces.

    My point is this: If it were just a case of knocking together procedural code and having a "programmer" wanting to do this, then fine, write your SP in any language you want. T-SQL is simple to learn anyway so why wait for .NET?

    The thing that separates us DBA/SQL coders from "VB guys" is that we need an understanding of SQL's internals (index types, statistcs, locking, etc.). We'd need this understanding no matter what language we code in.

    In addition, I assume that because these .NET languages have to go through the CLR that they are "heavier" and therefore slower. I may be wrong though and this may only be a factor if things are done in a non-set, recursive fashion. But really, who would do things like this anyway?

    Happy coding (however you choose to do it),


  • Is TSQL "simple" to learn? From some perspectives, undoubtedly, but such a statement begs numerous other questions.

    All programming can be boiled down to three things: 1. What output do you wish to produce? 2. What inputs are available to you? 3. What tools are available to you for crafting your processes? This is true whether you are producing a 2,000 page report on insurance transactions using COBOL on a mainframe, or whether you want the pixels representing a monster's face to smash to a pulpy mess when a kid pushes the red button on his joystick.

    Anything that produces your desired output from the available input is a 'process', and the ease or difficulty of writing, reading, or maintaining the process is less reliant on the syntax, but rather directly dependent upon how well organized the coder's mind happened to be at the time it was written. I would rather debug well-written C++ than poorly-written SQL.

    It is easy to get a programmer new to TSQL up and running; it is harder to find programmers who are expert TSQL coders. It is so easy to use TSQL that programmers mostly stop well short of exploiting it to its fullest.

    I've seen, for example, FoxPro programmers use TSQL in a rudimentary query in order to get a stack of data into FoxPro, where they proceed to do stuff that could all have been done more easily inside of TSQL. I just rewrote such a program, a table-populating system, that used several small TSQL stored procedures, about a thousand lines of manipulation in FoxPro, and a DTS package to break up the results and load them into a SQL Server table. I did the whole thing in TSQL, in about 500 lines of code, and it runs in about a fourth of the time. This is not to poke fun at the FoxPro developers, for whom I have tremendous respect. It's like I said: They never felt the need to move beyond the rudiments. (And I fall into the same trap myself with VB and FoxPro: To the coder whose only tool is a hammer, every problem is a nail. :-))

    However, from what I've seen of VB, there's nothing at all hard about the syntax. What's hard about it is knowing how to use all those system 'methods' and 'collections'. It seems more important to recall that somewhere there's an object that already does what you need, than to write elegant logic. (If this is an unfair characterization of VB, go ahead and hit me, I can take it. :-))

    The venerable longtime oboist in the Chicago Symphony, Ray Still, once was asked how he felt having achieved one of the top posts for someone who plays as difficult an instrument as oboe. His response was to challenge the basis for the question. He said: "People say oboe is the hardest wind instrument, but though clarinet is supposed to be one of the easier instruments, there are fewer great clarinet players than oboe players. Doesn't that mean the clarinet is harder?"

  • quote:

    Is TSQL "simple" to learn? From some perspectives, undoubtedly, but such a statement begs numerous other questions.

    While I'm here I just thought I'd try to clarify what I meant (T-SQL is my first language, English second :-)...

    The syntax is easy to learn. Sure there are numerous options for each of the statements/constructs, but these are all clearly documented in BOL. As opposed to - as you point out and I agree - hidden in a vast number of component objects.

    So I guess the real point is that you need some way to manipulate "sets" of data more than you need a new procedural language. So when using C#, you'll probably (hopefully) end up doing set-based operations with in-line (T-) SQL.

    I do welcome any comments on this and all my posts, and at the very least thanks all because I have now decided to check this C# stuff out for myself.

    Anyone for SQL#?

  • 1) LOL SQL# (Shouldn't that be SQL#.Net++)

    2) Ask any DBA worth their salt and they'll tell you that programmers don't understand databases. In particular, they don't understand the set-based approach (vs procedural) needed to efficiently manipulate the data. Allowing the programmers to code the database is going to result in a great deal of cursors looping through a recordset.

    There are some extensions to T-SQL that the new languages should bring (Defining constants, include files, etc.). What I hope will come out of this is a good debugger.

    Steve Hendricks


    AFS Consulting Group

    (949) 588-9800 x15

    Steve Hendricks
    Data Matrix
    (949) 588-9800 x15

Viewing 15 posts - 1 through 15 (of 22 total)

You must be logged in to reply to this topic. Login to reply