• Outgrown the term DBA? Unfortunately, yes.

    I am from the time when there weren't any DBAs, nor any other specialists. There were application programmers and systems programmers. And oh yes, some "senior" apps guys became analysts of one flavor or another. That was the beginning of the downfall.

    Specialization is detrimental.

    I am of the last generation of generalists. That is, I actually understand what computers do, and how they do it. I've worked with the "young pups" that know one thing, and THINK they know it well.

    They don't. Most of the people in this industry now have no real understanding of computing, IT, or really, anything technical. It's simply too easy to get things done in an adequate fashion.

    Back "in the beginning" when databases were "invented" in the '70s, it fell to the systems programmers to make them run, and we did. It was just another part of the job along with the core OS, telecom, storage management, applications support, and everything else we did. Strangely enough, even though those systems were MUCH harder to configure and maintain, most of us could handle most of the work - regardless of what it was.

    For some reason, now that it's almost trivial to create a complex application in a matter of weeks instead of years, there is an attitude that a whole building full of specialists is necessary to git-r-done.

    If even a handful of these specialists actually knew the SYSTEM, a lot of money would be saved. Of course, a lot of specialists would find themselves out of work because they are not useful.

    I've worked alone, and I've worked as part of huge teams. I believe that overall productivity decreases as the team size increases.

    This is a concept that goes back at least as far as the "skunk works" of aviation that gave us such miracles as the SR-71.

    However, the smaller the team is, the more skills each individual must have. In other words, they actually have to have a couple of brain cells to rub together.

    To make an analogy, our industry has people that can work with oak trees but not pine trees, grasses but not shrubs, etc. To be blunt, they are lost in the forest because they can only see a few of the trees.

    Am I unique? Far from it. But for certain, there are damn few - WAY too few - of the younger generation (eg. under 40) that have the drive to git-r-done.

    Here's a personal example. I just finished a contract writing a process control system. Never even saw one before. Never heard of PLCs (Programmable Logic Controllers). Yet, in 6 months, working alone, we're shipping bulletproof control systems.

    Why? Because I understand computers.

    I had some trouble with the PLCs at first. The normal programming language is "relay ladder logic". Then I found the checkbox that showed me the generated assembler code and instantly understood what was going on - I was working with a stack-oriented accumulator microprocessor - no big deal.

    My first formal introduction to programming was to create algorithms. First example was how to change a tire. Believe it or not, that simple act emcompasses every basic function of computing. If you actually analyze the process, the lightbulbs might start coming on.

    Now, if I could just find more clients like the last one. That is, people that can look beyond the alphabet soup and see that someone like me is what they need to get the job done. 😎

    In closing, a bit of advice: Learn the basics and build from there.

    P.S. To all those youngsters that think that Intel invented virtual storage with the 80386, you're wrong. They were 20 years after the fact (IBM/Cambridge, 1967).

    And the mouse was invented years before that!