|
|
-
Posted Thursday, May 10, 2012 10:36 PM |
"Imagination…One little spark, of inspiration… is at the heart, of all creation."
– From the song "One Little Spark", by the Sherman Brothers
I have a confession to make. Despite my great enthusiasm for databases and programming, it occurs to me that every database system I've ever worked on has been, in terms of its inputs and outputs, downright dull. Most have been glorified e-spreadsheets, many replacing manual systems built on actual spreadsheets. I've created a lot of database-driven software whose main job was to "count stuff"; phone calls, web visitors, payments, donations, pieces of equipment and so on. Sometimes, instead of counting stuff, the database recorded values from other stuff, such as data from sensors or networking devices. Yee hah!
So how do we, as DBAs, maintain high standards and high spirits when we realize that so much of our work would fail to raise the pulse of even the most easily excitable soul? The answer lies in our imagination.
To understand what I mean by this, consider a role that, in terms of its output, offers an extreme counterpoint to that of the DBA: the Disney Imagineer. Their job is to design Disney's Theme Parks, of which I'm a huge fan. To me this has always seemed like a fascinating and exciting job. What must an Imagineer do, every day, to inspire the feats of creativity that are so clearly evident in those spectacular rides and shows? Here, if ever there was one, is a role where "dull moments" must be rare indeed, surely?
I wanted to find out, and so parted with a considerable sum of money for my wife and I to have lunch with one; I reasoned that if I found one small way to apply their secrets to my own career, it would be money well spent. Early in the conversation with our Imagineer (Cindy Cote), the job did indeed sound magical. However, as talk turned to management meetings, budget-wrangling and insane deadlines, I came to the strange realization that, in fact, her job was a lot more like mine than I would ever have guessed.
Much like databases, all those spectacular Disney rides bring with them a vast array of complex plumbing, lighting, safety features, and all manner of other "boring bits", kept well out of sight of the end user, but vital for creating the desired experience; and, of course, it is these "boring bits" that take up much of the Imagineer's time.
Naturally, there is still a vital part of their job that is spent testing out new ideas, putting themselves in the place of a park visitor, from a 9-year-old boy to a 90-year-old grandmother, and trying to imagine what experiences they'd like to have. It is these small, but vital, sparks of imagination and creativity that have the biggest impact. The real feat of a successful Imagineer is clearly to never to lose sight of this fact, in among all the rote tasks.
It is the same for a DBA. Not matter how seemingly dull is the task at hand, try to put yourself in the shoes of the end user, and imagine how your input will affect the experience he or she will have with the database you're building, and how that may affect the world beyond the bits stored in your database. Then, despite the inevitable rush to be "done", find time to go the extra mile and hone the design so that it delivers something as close to that imagined experience as you can get.
OK, our output still can't and won't reach the same spectacular heights as the "Journey into The Imagination" ride at EPCOT Theme Park in Orlando, where I first heard "One Little Spark". However, our imaginative sparks and efforts can, and will, make a difference to the user who now feels slightly more at home with a database application, or to the manager holding a report presented with enough clarity to drive an interesting decision or two.
They are small victories, but worth having, and appreciated, or at least that's how I imagine it.
|
-
Posted Wednesday, April 25, 2012 10:40 PM |
Of all the valuable attributes of a DBA covered so far in this series, ranging from passion to humility to practicality, perhaps one of the most important attributes may turn out to be the most seemingly-nebulous: foresight. According to Free Dictionary foresight is the "perception of the significance and nature of events before they have occurred". Foresight does not come naturally to most people, as the parent of any teenager will attest. No matter how clearly you see their problems coming they won't listen, and have to fail before eventually (hopefully) learning for themselves.
Having graduated from the school of hard knocks, the DBA, the naive teenager no longer, acquires the ability to foretell how events will unfold in response to certain actions or attitudes with the unerring accuracy of a doom-laden prophet. Like Simba in the Lion King, after a few blows to the head, we foretell that a sore head that will be the inevitable consequence of a swing of Rafiki's stick, and we take evasive action. However, foresight is about more than simply learning when to duck. It's about taking the time to understand and prevent the habits that caused the stick to swing in the first place. And based on this definition, I often think there is a lot less foresight on display in my industry than there ought to be.
Most DBAs reading this blog will spot a line such as the following in a piece of "working" code, understand immediately why it is less than optimimum, and take evasive action.
…WHERE CAST (columnName as int) = 1
However, the programmers who regularly write this sort of code clearly lack that foresight, and this and numerous other examples of similarly-malodorous code prevail throughout our industry (and provide premium-grade fertilizer for the healthy growth of many a consultant's bank account).
Sometimes, perhaps harried by impatient managers and painfully tight deadlines, everyone makes mistakes. Yes, I too occasionally write code that "works", but basically stinks. When the problems manifest, it is sometimes accompanied by a sense of grim recognition that somewhere in me existed the foresight to know that that approach would lead to this problem. However, in the headlong rush, warning signs got overlooked, lessons learned previously, which could supply the foresight to the current project, were lost and not applied.
Of course, the problem often is a simple lack of skills, training and knowledge in the relevant technology and/or business space; programmers and DBAs forced to do their best in the face of inadequate training, or to apply their skills in areas where they lack experience. However, often the problem goes deeper than this; I detect in some DBAs and programmers a certain laziness of attitude.
They veer from one project to the next, going with "whatever works", unwilling or unable to take the time to understand where their actions are leading them. Of course, the whole "Agile" mindset is often interpreted to favor flexibility and rapid production over aiming to get things right the first time. The faster you try to travel in the dark, frequently changing direction, the more important it is to have someone who has the foresight to know at least roughly where you are heading. This is doubly true for the data tier which, no matter how you try to deny it, simply cannot be "redone" every month as you learn aspects of the world you are trying to model that, with a little bit of foresight, you would have seen coming.
Sometimes, when as a DBA you can glance briefly at 200 lines of working SQL code and know instinctively why it will cause problems, foresight can feel like magic, but it isn't; it's more like muscle memory. It is acquired as the consequence of good experience, useful communication with those around you, and a willingness to learn continually, through continued education as well as from failure. Foresight can be deployed only by finding time to understand how the lessons learned from other DBAs, and other projects, can help steer the current project in the right direction.
C.S. Lewis once said "The future is something which everyone reaches at the rate of sixty minutes an hour, whatever he does, whoever he is." It cannot be avoided; the quality of what you build now is going to affect you, and others, at some point in the future. Take the time to acquire foresight; it is a love letter to your future self, to say you cared.
|
-
Posted Tuesday, December 20, 2011 12:00 AM |
If you have seen the movie ‘The Christmas Carol’, you will remember that the evil bank owner Ebenezer Scrooge is not a proponent of the holiday season, claiming Christmas to be "a poor excuse for picking a man's pocket every twenty-fifth of December" and doesn't even want his employee Bob Cratchet to miss work on Christmas Day; work that involves foreclosing on his customers who no doubt spent their money on the holiday merriment instead of the mortgage. If you are unfamiliar with the story, I won't spoil how it happens, but in the end, not surprisingly, his heart softens to the ordeal, gives Bob the day off and a big raise. However, even Scrooge 2.0's head would have exploded at how much time his employee would be spending on the festivities nowadays.
During the holiday season (more or less all of December and a bit of the surrounding months), the productivity of the average worker falls off to dangerously anemic levels. Preparations for parties, travel, shopping, office decorating, gift exchanging, vacations, team volunteering outings for Toys for Tots/Rescue Mission etc. and other seasonal activities encroach heavily upon the employee's attention. Most companies are complicit with this, organizing several holiday parties (team, department, division, company, SQL User Group), and in some companies this means that employees come back to work the next day a bit tired, or worst case, don't come to work the next due to what is claimed to be a mysterious fruitcake related illness (we know the truth though). With productivity so low, many employees save up their vacation and take most of the month of December off in order to escape the frustration of getting work done in December, thereby multiplying the effect.
However, all of these lazy employees, like me, for instance, are not my focus today. Rather, I wish to send a love letter of sorts to the excellent DBAs and consultants who tirelessly support the work that developers like myself have created and forced them to support, regardless of whether Charlie Brown is on TV or not. Many production DBAs will have to work the holidays, or for the case of the observant DBA, carry around electronic leashes to be available in case their monitoring software determines there is cause for concern (day or night.) For many there will be issues. As each year passes, we get more and more electronic devices being used around the word that require the Internet to operate twenty four hours a day, since Christmas Day in one part of the word is Christmas Eve in another, and just another work day for still more parts of the world.
So during this holiday season, when you are leaned back in your favorite sitting place with your bowl of gingerbread cookies and a glass of eggnog (more nog than egg, naturally), with your new Internet connected phone, tablet, MP3 player, laptop computer, DVR, Internet radio, WiFi Router, TV Remote Control, TV, and Toaster humming along simultaneously, remember to take a few minutes to think about the production support staff, (especially our beloved DBAs!) and what they go through when they are the only person available to solve a problem for tens of thousands of customers that will either be the next repeat customer, or the next negative reviewers, all based on just how well they handle the issues that we developers left them. So whether or not the DBA likes it, on Christmas morning they may have to say "humbug!" to the figgy pudding (whatever the heck that is) or perhaps their child's first holiday to diagnose an issue that may have just needed an index that should have been caught in development or testing (by me, no doubt).
Happy Holidays to all, and to all a good database design!
As an added bonus, enjoy the following festive picture by Andrea Benedtti (anbenedetti on twitter), a SQL Server MVP from Italy by running the following SQL Server 2008+ code...
Christmas Tree Drawn Using SQL Server Spatial Types
/*
********************
Happy SQL Christmas!
********************
Andrea Benedetti, SQL Server MVP
Twitter: @anbenedetti
*/
SET NOCOUNT ON;
/* please choose the level of the tree... :-) */
DECLARE @level smallint = 10;
DECLARE @i tinyint = 1;
DECLARE @Offset smallint = 10;
DECLARE @x1 smallint = 100;
DECLARE @y1 smallint = 100;
DECLARE @x2 smallint = 150;
DECLARE @y2 smallint = 100;
DECLARE @x3 smallint = 125;
DECLARE @y3 smallint = 115;
DECLARE @x4 smallint = 100;
DECLARE @y4 smallint = 100;
DECLARE @Tree TABLE( Id tinyint IDENTITY(1 , 1) ,
Triangle geometry );
DECLARE @Palline TABLE( Id tinyint IDENTITY(1 , 1) ,
Ball geometry );
WHILE @i <= @level
BEGIN
INSERT INTO @Tree( Triangle )
VALUES( geometry::STGeomFromText( 'POLYGON ((' + CAST(@x1 AS varchar( 5 )) + ' ' + CAST(@y1 AS varchar( 5 )) + ',' + CAST(@x2 AS varchar( 5 )) + ' ' + CAST(@y2 AS varchar( 5 )) + ',' + CAST(@x3 AS varchar( 5 )) + ' ' + CAST(@y3 AS varchar( 5 )) + ',' + CAST(@x4 AS varchar( 5 )) + ' ' + CAST(@y4 AS varchar( 5 )) + '))' , 0 ));
INSERT INTO @Palline( Ball )
VALUES( geometry::STGeomFromText( 'POINT(' + CAST(@x1 AS varchar( 5 )) + ' ' + CAST(@y1 AS varchar( 5 )) + ')' , 0 ));
INSERT INTO @Palline( Ball )
VALUES( geometry::STGeomFromText( 'POINT(' + CAST(@x2 AS varchar( 5 )) + ' ' + CAST(@y2 AS varchar( 5 )) + ')' , 0 ));
INSERT INTO @Palline( Ball )
VALUES( geometry::STGeomFromText( 'POINT(' + CAST(@x3 AS varchar( 5 )) + ' ' + CAST(@y3 AS varchar( 5 )) + ')' , 0 ));
SET @x1-=@Offset;
SET @x2+=@Offset;
SET @x4-=@Offset;
SET @y1-=@Offset;
SET @y2-=@Offset;
SET @y3-=@Offset;
SET @y4-=@Offset;
SET @i+=1;
END;
SET @x1 = @x3 - @Offset;
SET @x2 = @x3 + @Offset;
SET @x3 = @x3 + @Offset;
SET @x4 = @x2;
INSERT INTO @Tree( Triangle )
VALUES( geometry::STGeomFromText( 'POLYGON ((' + CAST(@x1 AS varchar( 5 )) + ' ' + CAST(@y1 AS varchar( 5 )) + ',' + CAST(@x2 AS varchar( 5 )) + ' ' + CAST(@y2 AS varchar( 5 )) + ',' + CAST(@x2 AS varchar( 5 )) + ' ' + CAST(@y3 AS varchar( 5 )) + ',' + CAST(@x1 AS varchar( 5 )) + ' ' + CAST(@y3 AS varchar( 5 )) + ',' + CAST(@x1 AS varchar( 5 )) + ' ' + CAST(@y1 AS varchar( 5 )) + '))' , 0 ));
SELECT Triangle
FROM @Tree
UNION ALL
SELECT Ball.STBuffer( 3 )
FROM @Palline;
|
-
Posted Thursday, December 15, 2011 9:56 AM |
As a data architect, and writer on the same subject, I am completely entrenched in learning and applying the discipline of normalization. When I set my course down the road of great database design, my motto is "Fifth Normal Form or bust", even if it takes months to finish the design for just a few tables (and, of course, to make sure every table and column is meticulously named). Not much gives me greater pleasure than the beauty of a database that has been honed to a high degree of normalized perfection and that, to the amazement of the many detractors and doubters, also performs magnificently.
If this sounds like one of Lewis Carroll's stories, there is good reason for it. The reality is that I don't live in Wonderland, and rarely get time to design anything, much less everything, in meticulous detail. My average project tends to fall into one of two categories
-
The Surprise Project – about 30 seconds after you fall asleep for the night, a mobile device starts dancing to that catchy ringtone that was annoying 10 years ago. Something has failed and it is time to fix it. As long as the problem wasn't caused by you, this can be the most rewarding times of your career, as you put on your Superman Underoos and save the day.
-
The Incredibly Urgent Project – after months of furtive meetings between various marketing and project managers, over the need for some innovative new campaign, advertising scheme, or product line, a decision has finally been made to go ahead. And they need the project to start…immediately! And the delivery date is…as soon as possible!
My normal workday, as a result, most closely resembles a typical episode of the TV show, Junkyard Wars…"Contestants, you have just 10 hours to build a fully-working dragster from the contents of this junkyard." My favorite team welded together an old motorcycle and a rusty golf cart and went flying down the track. Their solution would never work long enough to survive the complete drag racing season, but it survived 2 trips down the eighth mile. They knew for how long their solution would be used, but most software built like this, with a planned expiration date, usually last years longer than expected.
Many project are like this; get it done quick. The best theoretical solutions need not be posited; your deep and hard-won knowledge of advanced "internals" is of little good to you here. Practical is what is required. When a manager says "as soon as possible", they don't mean "as soon as you can reasonably arrive at the optimum database design and then build a proper solution with stringent application of sound programming principles". They mean "why haven't you got something to show me, already?"
The oft-heard battle cry from management is that "Better is the enemy of good enough"; true, but in the wrong hands, very dangerous. Too often, the definition of "good enough" is taken to mean something works to the point that the manager can check a box, no matter the implications to the future user or maintenance workers.
Does this mean that all of your training, all of your dedication to doing your job the right way, is useless? Not at all; in fact, it is going to be more necessary than ever. Just because your solutions need to be devised with practicality and timeliness as a priority, it doesn't mean that you can actually do things poorly or technical debt will pile up like dirty clothes in a dorm room. It does mean, however, that you need to stop aiming for perfection and start shooting for "good enough", but where good enough implies a practical solution that adopts at least the basic software engineering principles, and a solution that you are comfortable releasing to the users, even in the knowledge that an even better solution was just out of reach.
Almost every solution that is created according to a definition of practical that means "delivered tomorrow" is doomed to be a lesson for the next project; when practical means "as good as practically possible", everything will usually be alright.
|
-
Posted Sunday, November 13, 2011 9:35 PM |
When walking up to the building where I work, I can see CCTV cameras placed here and there for monitoring access to the building. We are required to wear authorization badges which could be checked at any time. Do we have enemies? Of course! No one is 100% safe; even if your life is a fairy tale, there is always a witch with an apple waiting to snack you into a thousand years of slumber (or at least so I recollect from elementary school.) Even Little Bo Peep had to keep a wary lookout.
We nerdy types (or maybe it was just me?) generally learned on the school playground to keep an eye open for unprovoked attack from simpler, but more muscular souls, and take steps to avoid messy confrontations well in advance. After we’d apprehensively negotiated adulthood with varying degrees of success, these skills of watching for danger, and avoiding it, translated quite well to the technical careers so many of us were destined for. And nowhere else is this talent for watching out for irrational malevolence so appropriate as in a career as a production DBA.
It isn’t always active malevolence that the DBA needs to watch out for, but the even scarier quirks of common humanity. A large number of the issues that occur in the enterprise happen just randomly or even just one time ever in a spurious manner, like in the case where a person decided to download the entire MSDN library of software, cross join every non-indexed billion row table together, and simultaneously stream the HD feed of 5 different sporting events, making the network access slow while the corporate online sales just started. The decent DBA team, like the going, gets tough under such circumstances. They spring into action, checking all of the sources of active information, observes the issue is no longer happening now, figures that either it wasn’t the database’s fault and that the reboot of the whatever device on the network fixed the problem. This sort of reactive support is good, and will be the initial reaction of even excellent DBAs, but it is not the end of the story if you really want to know what happened and avoid getting called again when it isn’t even your fault.
When fires start raging within the corporate software forest, the DBA’s instinct is to actively find a way to douse the flames and get back to having no one in the company have any idea who they are. Even better for them is to find a way of killing a potential problem while the fires are small, long before they can be classified as raging. The observant DBA will have already been monitoring the server environment for months in advance. Most troubles, such as disk space and security intrusions, can be predicted and dealt with by alerting systems, whereas other trouble can come out of the blue and requires a skill of observing ongoing conditions and noticing inexplicable changes that could signal an emerging problem. You can’t automate the DBA, because the bankable skill of a DBA is in detecting the early signs of unexpected problems, and working out how to deal with them before anyone else notices them.
To achieve this, the DBA will check the situation as it is currently happening, and in many cases is likely to have been the person who submitted the problem to the level 1 support person in the first place, just to let the support team know of impending issues (always well received, I tell you what!). Database and host computer settings, configurations, and even critical data might be profiled and captured for later comparisons. He’ll use Monitoring tools, built-in, commercial (Not to be too crassly commercial or anything, but there is one such tool is SQL Monitor) and lots of homebrew monitoring tools to monitor for problems and changes in the server environment.
You will know that you have it right when a support call comes in and you can look at your monitoring tools and quickly respond that “response time is well within the normal range, the query that supports the failing interface works perfectly and has actually only been called 67% as often as normal, so I am more than willing to help diagnose the problem, but it isn’t the database server’s fault and is probably a client or networking slowdown causing the interface to be used less frequently than normal.” And that is the best thing for any DBA to observe…
|
-
Posted Friday, August 12, 2011 9:17 AM |
Anyone who remembers the rock opera Tommy might have guessed that this blog will describe my forthcoming rock opera about a coder with hysterical blindness who becomes a Relational Wizard. Watching him, I jealously start singing…
“Ever since I was a newbie
I wrote code like a storm
My databases rendered
In the fifth normal form
But I ain’t seen anything like him
On any IT team
That deft DBA can
Code T-SQL up a storm.”
That guess would be wrong. Rather this blog is going to be about avoiding the urge to judge a book by its cover, by being ‘blind’ to all but what is important. It started back at SQL Saturday #50 in East Iowa. They had a ‘Women in Technology’ panel in the main lunch room, and some of what I heard sort of bothered me. I heard it again at SQL Saturday #45 in Louisville, and finally, sitting at a table with Erin Stellato and Jes Borland in Columbus, the topic of women in technology was discussed rather vigorously, and I promised to write about it (I really have to learn when to shut up.)
Now, if you are particularly sensitive, you probably heard that women in technology bother me. Well, they do, but no more than men in technology. In fact I am annoyed by all sexes equally. The point of this blog is that I don't like irrelevant labels placed on any groups of people. If we were blind to all irrelevant factors when dealing with other technology people, life would be much simpler. In my mind, attaching a label to a group (like "Women in Technology") can unintentionally marginalize all members of that group. Do they really belong in a group that requires special pleading or positive discrimination? Are Kim T, Kalen D, and Jessica M (to name just a few!) top in the field for any reason other than skill and hard work? Of course not. They are smarter and certainly work way harder than me (and most of you who are reading this blog.)
Throughout history, attempts to compensate for prejudice have resulted in a perception of forced equality, leading to jealousy, distrust and worse yet, quotas, meaning good people are left out and less qualified people aren't. This then reinforces stereotypes making matters worse. The fact is that I just want to have code that works and deal with less stupid questions than I would get from someone who is less talented than the right person for the job.
The second, not exactly politically-correct, term I have bandied about is "judgmental". Is it okay to be judgmental? Of course. As a DBA/programmer we ought to do a lot of code reviews. Judging the work of others is necessary. The problems happen if one allows one’s judgment of a person’s professional competence to be skewed by the shape or color of their body. You don't judge a book by its cover but by the quality of the words (or pictures!) inside. In my perfect blog world, people choose employees based on the following two criteria:
1. Does this person have the skills and experience needed?
2. Will this person reasonably support the purpose of the organization?
The first one is obvious. If you need a programmer, and the person can't work a calculator, much less comprehend the concept of binary numbers, the fit is clearly going to be bad. The second is a lot more complex and controversial. I work for a non-profit organization, and we certainly can discriminate based on the bedrock beliefs of the organization. But should Pepsi hire you if you are an avid Coke drinker that owns the website www.PepsiTastesAwful.com (not a real website) which professes that Pepsi is made from rusty sewer pipe drippings? (To be fair, I like them both, but one had to be the patsy). Of course not. However, most times I have seen the concept of the "wrong fit for the job applied,” it has just been that the person seemed like they were "different," which has usually seemed like they were quirky (and aren't the best programmers a bit quirky, at least?) The obvious problem is that it is just far too easy to mask sexism, racism, or really any sort of -ism with the concept of fit.
I perhaps have veered a bit off of the topic of Women In Technology groups, so let's steer back there. I don't want to make it seem as if I thought for a moment that ‘Women in Technology’ groups are evil and bent on world domination. The times I have attended their luncheons, the focus was on how we make it more socially acceptable to get younger girls into more technology oriented career paths. Excellent. But Don't forget about the young boys. Technology has long been considered as unacceptable by the cool cliques, and while that is changing slowly, it isn't changing fast enough. We continue to have a dearth of qualified people out there writing code and designing databases.
My solution would be to elevate technology in the classroom to one of the fundamentals, to the level of reading, writing, and arithmetic. It might not be popular with many students, but fundamental education is not designed to be popular, it is there to give you foundational knowledge to build upon. The most helpful class I took in high school was one my father forced me to take but turned out to be one of the most influential in my future; typing. Twenty years ago, typing was not a common class that boys took (nor twenty-six years ago when I actually took it!); but my father, who was a mechanic at the time, wanted to prepare me for the future that he saw coming. All day at work, and even as I sit here typing this blog, I use my typing skills. That kind of parental "encouragement" to build fundamental skills for the future is probably the most necessary step, and one that cannot be legislated but can start with you and your child/niece/nephew/neighbor. It is still a problem in this day and age that parents ingrain their children with an attitude that technology work is for people who can't do "real" work. Showing them how great your job is and being an encourager will certainly help. In the end, a person’s career choice should be the intersection of what they have the skills to do and what they like to do.
The goal should be that we work to get every young person of all types involved with technology early, and not just for playing Angry Birds and texting random body parts to their classmates. Then we won't just be helping women into technology, but men too. Let’s face it, if you are a highly qualified technologist, you should be excited about the concept of getting more qualified people in technology regardless of who they are. Of course, if you are not qualified, well...I can see how you might be opposed.
|
-
Posted Tuesday, July 12, 2011 12:00 PM |
There comes a point in many people's lives where they stop adding new knowledge and become stuck at a point in time. My father-in-law worked with technology for many years with a telecommunications company until he retired. He was an "early adopter" and a proud owner of one of the first satellite dishes, a big screen TV (27 inch!), and a VCR that took at least two people to move. His remote control had as many buttons as the dash of a Boeing 757 and yet he was able to 'land any aircraft' with speed and assurance. As technology moved on, he upgraded too, but the newer, arguably more user-friendly remote, was never quite his bailiwick. He tended to shun new features, sticking as closely as possible to what was familiar, and even then often complaining bitterly about "why they had to change things". His memory was stuck in the past, no longer having the capability to acquire new information, even if it was similar to what he had known previously.
Likewise, there often comes a point in many a DBA's career where it feels like enough information has been acquired to do all the tasks a job requires, without having to find room in the brain for any more new technologies. Their company is slow to move on from older versions of SQL Server, and that suits them fine. Even when upgrades do happen, it turns out that most of what they need to so in SLQ Server 2008 can be done with their old SQL Server 2000 code base! In other words, the DBA starts to "coast". Now, if you happen to be approaching 65 and already own your vacation home on the Riviera, well then good for you. If you are still 30 years from retirement age, coasting to a finish is probably not optimal.
When your backward-looking company fails you, you'll find that many other companies don't feel the same way about new technology. No matter how well you might interview, and answer general questions, don't expect a senior-level position if you are stuck with knowledge from the previous millennium. All DBAs needs to keep themselves educated and ahead of the curve, within their field of expertise. Luckily, the educational opportunities in our field are really quite amazing. The following list, loosely assembled in the order of desirability, describes where you might get, and keep getting, education:
-
College Degree – consider getting one. You will have a little fun and feel simultaneously older and younger while working on it.
-
Individual Study – books are an essential resource for personal study, though don't rely on a single source (even if it's a book I wrote ;)). When designing our first data warehouse, we relied on Kimball Group's books, with only partial success. After later attending a class and getting some mentoring from an amazing expert, it became obvious what we had done wrong.
-
Blogs – highly unstructured but useful for filling gaps in your knowledge, and learning from other's experiences
-
Conferences – 2010 and 2011 have seen an explosion in the number and variety of events available, from free single-day training ( e.g. SQL Saturday) to bigger, paid events (SQL Rally, SQL Teach, SQL PASS, Tech Ed, SQL Bits, SQL Solstice) to monthly user group meetings. There will doubtless be an event you can drive to easily, and probably attend for free.
-
Training Classes – Week-long, in-depth training in a specific skill or technology. Often expensive, and obviously the quality of the teacher is important, but these are invaluable in helping improve your working practices. For example, I recently had training from a great SSIS teacher.
-
Direct Mentoring – either working daily with an experienced co-worker or hiring an expert to help your company with a system. Either way, this is the absolute best type of learning; a good mentor can make a huge difference, especially to a fledgling DBA.
-
Teach, Speak, Write, Answer Forum Questions – all of these will more or less force you to read and research to make sure you get it right, because if you don't your audience will let you know! Also, the presentations, articles, blogs, forum posts and tweets that you produce can be a wonderful advert to prospective employers
With all of these possibilities, many of which are free, there is no excuse to stop learning. The minute you do, you start to fall behind. Then, when the company you'd "settled in to" fails, you'll be left staring at a "new remote control", wondering why things had to change. It's only a short step from there to standing on the side of the street holding a sign that says "Will DBA for Food (SQL Server 2000 Only)".
Conversely, a manageable amount of time spent on the above activities will keep you up-to-date, make you attractive to prospective employers and, as an added bonus, may well re-enliven your enthusiasm; turning the your job from a day-to-day grind into something more like a hobby you just spend 50 hours a week on (40 for the man, 10 for yourself!)
|
-
Posted Thursday, June 09, 2011 5:22 PM |
"There are 10 kinds of people in the world. Those who will always wonder why there are only two items in my list and those who will figured it out the first time they saw this very old joke."
Those readers who will give up immediately and get frustrated with me for not explaining it to them are not likely going to be great technical professionals of any sort, much less a programmer or administrator who will be constantly dealing with the common failures that make up a DBA's day. Many of these people will stare at this like a dog staring at a traffic signal and still have no more idea of how to decipher the riddle. Without explanation they will give up, call the joke "stupid" and, feeling quite superior, walk away indignantly to their job likely flipping patties of meat-by-product.
As a data professional or any programmer who has strayed to this very data-oriented blog, you would, if you are worth your weight in air, either have recognized immediately what was going on, or felt a bit ignorant. Your friends are chuckling over the joke, but why is it funny? Unfortunately you left your smartphone at home on the dresser because you were up late last night programming and were running late to work (again), so you will either have to fake a laugh or figure it out. Digging through the joke, you figure out that the word "two" is the most important part, since initially the joke mentioned 10. Hmm, why did they spell out two, but not ten? Maybe 10 could be interpreted a different way?
As a DBA, this sort of logic comes into play every day, and sometimes it doesn't involve nerdy riddles or Star Wars folklore. When you turn on your computer and get the dreaded blue screen of death, you don't immediately cry to the help desk and sit on your thumbs and whine about not being able to work. Do that and your co-workers will question your nerd-hood; I know I certainly would. You figure out the problem, and when you have it narrowed down, you call the help desk and tell them what the problem is, usually having to explain that yes, you did in fact try to reboot before calling. Of course, sometimes humility does come in to play when you reach the end of your abilities, but the ‘end of abilities’ is not something any of us recognize readily.
It is handy to have the ability to use logic to solve uncommon problems: It becomes especially useful when you are trying to solve a data-related problem such as a query performance issue, and the way that you approach things will tell your coworkers a great deal about your abilities. The novice is likely to immediately take the approach of trying to add more indexes or blaming the hardware. As you become more and more experienced, it becomes increasingly obvious that performance issues are a very complex topic. A query may be slow for a myriad of reasons, from concurrency issues, a poor query plan because of a parameter value (like parameter sniffing,) poor coding standards, or just because it is a complex query that is going to be slow sometimes. Some queries that you will deal with may have twenty joins and hundreds of search criteria, and it can take a lot of thought to determine what is going on. You can usually figure out the problem to almost any query by using basic knowledge of how joins and queries work, together with the help of such things as the query plan, profiler or monitoring tools. It is not unlikely that it can take a full day’s work to understand some queries, breaking them down into smaller queries to find a very tiny problem.
Not every time will you actually find the problem, and it is part of the process to occasionally admit that the problem is random, and everything works fine now. Sometimes, it is necessary to realize that a problem is outside of your current knowledge, and admit temporary defeat: You can, at least, narrow down the source of the problem by looking logically at all of the possible solutions. By doing this, you can satisfy your curiosity and learn more about what the actual problem was. For example, in the joke, had you never been exposed to the concept of binary numbers, there is no way you could have known that binary - 10 = decimal - 2, but you could have logically come to the conclusion that 10 must not mean ten in the context of the joke, and at that point you are that much closer to getting the joke and at least won't feel so ignorant.
|
-
Posted Friday, May 06, 2011 5:00 PM |
It is a well-known saying that “curiosity killed the cat,” but is this really not as true as it might sound; right up to the end of our devoted cat’s long life, she constantly poked around into places we didn’t want her to, but always approached new things cautiously and generally knew when to run away to safety. For people, the saying is generally used to discourage the recipient’s desire to know more of something. For example, if you asked the tuxedo wearing driver of your vehicle “What would happen if I pressed this button?” as you sped down the highway, he probably wouldn’t tell you to push it to find out that it controls the ejector seat you are sitting in. Curiosity won’t kill you, but recklessly pushing that button most certainly would.
Any database professional needs curiosity. The world of SQL Server, for example, used to be a reasonably simple one, made up of “only” a relational engine. It wasn’t impossible to become an expert in the entire product, because the whole product was made up of parts that worked together very naturally. Today, SQL Server’s relational engine is just a tiny part of a galaxy of products that are packaged together, including Analysis Services, Reporting Services, and Integration Services, as well as complicated high-availability options such as mirroring and clustering. Even the relational engine comes bulging with non-relational sorts of features that are useful in their place; but for a relational focused programmer they feel out of place. For example, the XML and spatial (geometry and geography) data types are cool, but don’t work quite the same way as the basic relational tools.
Without curiosity, most people would simply avoid the features they don’t use, but if you are going to administer or code with a product it doesn’t hurt to learn more and more about the tools, because it isn’t always easy to predict when it will be helpful to be familiar with them. Curiosity helps you push the limits of your knowledge, but it has drawbacks, just as the cat chewing on a high voltage wire to see if it is filled with some form of edible creamy goodness will probably discover when she gets to the tangy copper flavored center. Clearly, curiosity must be leavened with reasoning and wisdom.
Let’s briefly look at the pros and cons of curiosity for the database professional:
-
Pro – Learning new techniques – Writing basic SQL is easy, in fact the language was envisioned as a tool for users of all levels, but as your skills advance, you can write in a single statement what might take ten thousand procedural lines of code, leaving the dirty details of implementation to the query optimizer and processor
-
Con – Overusing newly learned techniques – When you learn a new skill, you want to start using it, regardless of whether or not it is needed. For example, once you discover temp tables, derived tables and CTEs, you will see that they can help you produce amazing results, but overuse tends to produce less than desirable results. As an example, while you can delete data using a CTE based query, if you are not careful you can delete all of the data in the table when you didn’t expect to.
-
Pro – Discovering interesting data – Throughout your enterprise database, there is likely an amazing array of interesting data situations just waiting to be found. Better ways to serve customers, ways to save money, as well as ways to better relate and integrate data from multiple systems.
-
Con – Discovering interesting data – There are bells you cannot un-ring, and forgetting something you see that you shouldn’t is difficult. You might find something annoying, like the salary of the dunderhead employee whose job you are doing for him; or something more sinister that the owner of the company is doing that entices you to violate stock trading laws.
-
Pro – Proactively solving problems – As a database professional, you will find that while data should be your company’s most important asset, it is often treated as an afterthought. So your daily jobs to copy, backup, manage, and deal with data of all sorts will often fail. As you become skilled you will likely start to become addicted to looking for types of problems that might occur and make sure they never do.
-
Con – Loss of sleep/sanity when problems cannot be repeated – Try as you might, some errors are random. The SQL community can help out, but sometimes you will be the first person to encounter an error that eventually becomes very common (someone has to be the first to report the error on the Internet, after all.) It is easy to get wrapped up in your code and spend all of your waking hours tilting at SQL windmills.
You’re unlikely to become a complete expert on all of the parts in the SQL Server package, but a measure of curiosity will lead to sufficient understanding to know what parts to use when.
Did curiosity kill the cat? Not as a rule. After a long, rich, life spent in pursuit of intellectual stimulation through satisfying her inherent curiosity, our cat died of having enjoyed over twenty years of easy living. In professional programmers and DBA’s it is more likely that a lack of curiosity will kill your opportunities for advancement and intellectual growth, just don’t push the red button without knowing what it does, ok?
|
-
Posted Saturday, April 16, 2011 10:59 AM |
My family and I enjoy sitting down together to watch the TV show called "Wipeout". The contestants try to run wacky obstacle courses filled with various bizarre and fiendish obstacles in the fastest possible time. Failure is a guaranteed occurrence; contestants run into fake walls, get hit by "cartoon" hammers, and generally end up falling off a multi- story precarious perch unceremoniously into a pool of water or even more humorously, disgusting mud. They then pick themselves up, wipe untold amounts of gack and goo off their face, and go back for more of the same until they finally get to the end.
My family finds all of this hilarious, but I have to admit I sometimes wonder how stupid these people must be to keep going as they know they are going to fail over and over. Then of course, because everything I do inevitably gets me thinking of technology, it all reminds me of the daily process of the average production and development DBA. Then I understand why these people keep going. They become driven to finish in the belief that next time they can dodge the hammer and not get smashed… and the hope of a large sum of cash isn’t a bad motivator either.
DBAs are faced daily with failure in some way, shape or form. The first time we execute any non-trivial SQL query we almost inevitably get some error message like the dreaded “syntax error near…” message. Then we keep going, failing over and over until things work at least once. When everything seemingly works, we give our creations to users and barely a day, sometimes minutes, after our lovingly-crafted solutions get in their hands, users begin reporting various types of failures. The system is running "too slowly" or is failing to satisfy some mysterious "requirement" that you're fairly sure the user just made up on the spot just for their entertainment. And, of course, no matter what the true source of the problem, from slow reports to hardware failure to network glitches (and occasionally something SQL related), it’s always initially considered the database's, and the therefore the DBA's, fault.
Some of these "hammers to the head" failures hurt, but somehow giving up is never an option; DBAs keep going back for more. They keep going-and-going, fixing problem after problem until the torrent of 2AM alerts on their phone becomes only a trickle of concerns that can be put off to the morning. Then, at 8AM it is back to start the process again, eventually repeating until the next time an error occurs somewhere in the enterprise.
If the fate of the DBA has many parallels with that of the Wipeout contestant, there is one crucial difference: for a good DBA, acceptance of failure is not taken lightly and giving up is not possible. If a good DBA did the Wipeout course for the first time, the hammers to the head would connect just like for everyone else. The next time however, those hammers will have been disabled permanently, even if it meant a slower course time for them and all following contestants could finish in record time.
"Proactive monitoring" helps to head problems off at the pass. Code is fortified with layer-upon-layer of error handling. DBAs fight vigorously for the time, manpower and resources to do adequate testing, often in the face of cries of "insanity" that meet our requests, especially to spend money for a test server of the relatively same power and capabilities as the production server.
Failure, especially public failure, is something that by nature we shun. However, the try-fail-learn cycle is one that all good DBAs (and programmers) must accept and embrace without fear. Fail once, that’s life, fail again in the same way, and that isn't being a good DBA and a DBA that doesn’t learn from mistakes is probably in the wrong profession. And of course, we do like the promise of a nice cash prize every two weeks.
|
-
Posted Friday, April 01, 2011 12:00 AM |
This post (hopefully obviously) was my April Fool's day post. I assume that was quite obvious as everything in this post was opposite of the common reality (and really, is adventurousness even vaguely a word?)
The fact is though, while you can pretty much toss a boolean NOT() operator around the entire article and get much closer to reality, a sense of adventure and progressiveness would certainly be a great trait for a DBA. Keeping up with the latest versions of software is a great practice as more often than not, the vendor fixes problem as time progresses. Even if you want to follow the one service pack rule, it is still better than waiting until the day before Microsoft stops supporting the version you are on to start thinking about upgrading.
Finally, it can't hurt to at least understand the alternatives to the paradigm you are following. New languages, alternatives to relational databases, etc, usually all have merit for some applications. The best way to defend against technology misuse is to understand the proper use. Otherwise you just sound like a zealot when you protest a decision that is actually wrong, but Flashy Bob Manager read about it in a magazine (written by the vendor of the new product, natch') and you are going to use it.
The following is the original post:
The ever changing nature of the relational database system requires administrators who relish risk and adventure. From the moment that Edgar F Codd proposed his 12 rules that defined the relational database management system, the language COBOL and the VSAM databases that had been so popular vanished as database administrators rushed to adopt the new system, keen as always to adopt the latest technologies, using hardware that had less power than the current middle school math student’s calculator: the relational era was born.
DBAs are characteristically keen to upgrade to the latest technology. In a survey done in December 2005 of DBAs employed in Fortune 500 financial and health care corporations, over 80% of these organizations were already using the new SQL Server 2005 database technology, and 19% had already begun using a beta edition of SQL Server 2008. (1)
This rapid uptake of new RDBMS versions causes much difficulty for locating new DBA candidates, because most technology employers desire new hires to have years of practice with the tools they are being recruited to use. John Smith, a hiring manager for Natural Utility Tools commented, “For most technologies, we look for 3-5 years of experience in a technology before we will make use of it. Just now in 2011 we are getting people ready to make good use of C# and Visual Studio 2008. But DBAs rarely have any production experience in a SQL Server version before they have used it in production and are pushing to start working on the next beta or alpha edition. It really drives the other developers crazy”
To be a really great DBA requires not only an adventurous nature with database technologies, but technologies of all sorts. Whereas most people wait for months or years to adopt a Mobile Phone technology (2), and keep that technology until they are required to upgrade, DBAs regularly change phones at least yearly if not more frequently, making sure to have the most up to date electronic communication devices.
Most DBAs spend a lot of their time enthusiastically and uncritically learning all sorts of technologies such as LINQ and XML in order to understand the world of the developers they deal with regularly. Most DBAs understand networking, hardware, and learn at least one procedural/object oriented language (and many are fluent at several.)
Finally, one of the key ingredients in being a successful DBA is keeping up with trends in the business. As new database technologies come out, like Object Oriented-Relational, Entity-Attribute-Value and recently NoSQL, most DBAs find that it is important to learn everything they can about these in case they might be a suitable replacement for the relational model that has served them well for 25 years: DBAs are constantly on the cutting edge out there searching for the next best thing, and it could be 10 days from now, or 10 more years, but for the successful DBA, it is all part of the adventure.
1. Dewey, Cheatham, and Howe Technology Studies, 2005
2. Steve Bow and Frank Guss Statistics, 2008
A local PASS Chapter of DBAs excitedly contemplate the joys of the latest Multi-Processor Server
|
-
Posted Thursday, March 10, 2011 8:54 PM |
In football (the American sort, naturally,) there is a select group of players who really hope to never have their names called during the game. They are members of the offensive line, and their job is to protect other players so they can deliver the ball to the goal to score points. When you do hear their name called, it is usually because they made a mistake and the player that they were supposed to protect ended up flat on his back admiring the clouds in the sky instead of advancing towards the goal to scoring point. Even on the rare occasion their name is called for a good reason, it is usually because they were making up for a teammate who had made a mistake and they covered up for them.
The role of offensive lineman is a very good analogy for the role of the admin DBA. As a DBA, you are called on to be barely visible and rarely heard, protecting the company data assets tenaciously, even though the enemies to our craft surround us on all sides:.
- Developers: Cries of ‘foul!’ often ensue when the DBA says that they want data integrity to be stringently enforced and that documentation is needed so they can support systems, mostly because every error occurrence in the enterprise will be initially blamed on the database and fall to the DBA to troubleshoot. Insisting too loudly may bring those cries of ‘foul’ that somewhat remind you of when your 2 year old daughter didn't want to go to bed. The result of this petulance is that the next "enemy" gets involved.
- Managers: The concerns that motivate DBAs to argue will not excite the kind of manager who gets his technical knowledge from a glossy magazine filled with buzzwords, charts, and pretty pictures. However, the other programmers in the organization will tickle the buzzword void with a stream of new-sounding ideas and technologies constantly, along with warnings that if we did care about data integrity and document things, the budget would explode! In contrast, the arguments for integrity of data and supportability tend to be about as exciting as watching grass grow, and far too many manager types seem to prefer to smoke it than watch it.
- Packaged Applications: The DBA is rarely given a chance to review a new application that is being demonstrated for the enterprise, and rarer still is the DBA that gets a veto of an application because the database it uses has clearly been created by an architect that won't read a data modeling book because he is already married. More often than not this leads to hours of work for the DBA trying to performance-tune a database with a menagerie of rules that must be followed to stay within the application support agreement, such as no changing indexes on a third party schema even though there are 10 billion rows instead of the 10 thousand when the system was last optimized.
- Hardware Failures: Physical disks, networking devices, memory, and backup devices all come with a measure known as ‘mean time before failure’ and it is never listed in centuries or eons. More like years, and the term ‘mean’ indicates that half of the devices are expected to fail before that, which by my calendar means any hour of any day that it wants to fail it will.
But the DBA sucks it up and does the task at hand with a humility that makes them nearly invisible to all but the most observant person in the organization. The best DBAs I know are so proactive in their relentless pursuit of perfection that they detect many of the bugs (which they seldom caused) in the system well before they become a problem.
In the end the DBA gets noticed for one of same two reasons as the offensive lineman. You make a mistake, like dropping a critical production database that had never been backed up; or when a system crashes for any reason whatsoever and they are on the spot with troubleshooting and system restoration plans that have been well thought out, tested, and tested again. Not because there is any glory in it, but because it is what they do.
Note: The characteristics of the professions referred to in this blog are meant to be overstated stereotypes for humorous effect, and even some DBAs aren't quite this perfect. If you are reading this far and haven’t hand written a 10 page flaming comment about how you are a _______ and you aren’t like this, that is awesome. Not every situation applies to everyone, but if you have never worked with a bad packaged app, a magazine trained manager, programmers that aren’t team players, or hardware that occasionally failed, relax and go have a unicorn sandwich before you wake up.
|
-
Posted Tuesday, February 15, 2011 1:57 AM |
“Practice makes perfect:” right? Well, not exactly. The reality of it all is that this saying is an untrustworthy aphorism. I discovered this in my “younger” days when I was a passionate tennis player, practicing and playing 20+ hours a week. No matter what my passion level was, without some serious coaching (and perhaps a change in dietary habits), my skill level was never going to rise to a level where I could make any money at the sport that involved something other than selling tennis balls at a sporting goods store. My game may have improved with all that practice but I had too many bad practices to overcome. Practice by itself merely reinforces what we know and what we can figure out naturally. The truth is actually closer to the expression used by Vince Lombardi: “Perfect practice makes perfect.”
So how do you get to become skilled as a DBA if practice alone isn’t sufficient? Hit the Internet and start searching for SQL training and you can find 100 different sites. There are also hundreds of blogs, magazines, books, conferences both onsite and virtual. But then how do you know who is good? Unfortunately often the worst guide can be to find out the experience level of the writer. Some of the best DBAs are frighteningly young, and some got their start back when databases were stored on stacks of paper with little holes in it.
As a programmer, is it really so hard to understand normalization? Set based theory? Query optimization? Indexing and performance tuning? The biggest barrier often is previous knowledge, particularly programming skills cultivated before you get started with SQL. In the world of technology, it is pretty rare that a fresh programmer will gravitate to database programming. Database programming is very unsexy work, because without a UI all you have are a bunch of text strings that you could never impress anyone with. Newbies spend most of their time building UIs or apps with procedural code in C# or VB scoring obvious interesting wins. Making matters worse is that SQL programming requires mastery of a much different toolset than most any mainstream programming skill. Instead of controlling everything yourself, most of the really difficult work is done by the internals of the engine (written by other non-relational programmers…we just can’t get away from them.)
So is there a golden road to achieving a high skill level? Sadly, with tennis, I am pretty sure I’ll never discover it. However, with programming it seems to boil down to practice in applying the appropriate techniques for whatever type of programming you are doing. Can a C# programmer build a great database? As long as they don’t treat SQL like C#, absolutely. Same goes for a DBA writing C# code. None of this stuff is rocket science, as long as you learn to understand that different types of programming require different skill sets and you as a programmer must recognize the difference between one of the procedural languages and SQL and treat them differently. Skill comes from practicing doing things the right way and making “right” a habit.
|
-
Posted Thursday, January 20, 2011 5:58 PM |
One of my first questions, when interviewing for a DBA/Programmer position, is always: “Why do you want this job?” The answers I receive range from cheesy hyperbole (“I want to enhance your services with my vast knowledge”) to deadpan realism (“I have N kids who all have a hole in the front of their face where food goes"). Both answers are fine in their own way, at least displaying some self-confidence, humour and honesty, but once in a while, I'll hear the answer that is music to me ears...
“I LOVE DATABASES!”
Whenever I hear it, my nerves tingle in hopeful anticipation; have I found someone for whom working with database isn't just a job, but a passion? Inevitably, I'm often disappointed. What initially seemed like passion turns out to be rather shallow enthusiasm; the person is enthusiastic about working with databases in the same way he or she might be about eating a bag of Cajun spiced kettle chips; enjoyable, but not something to think about too deeply or take too seriously.
Enthusiasm comes, and enthusiasm goes. I've seen countless technical forum users burst onto the scene in a blaze of frantic question-answering, only to fade away within days, never to be heard from again. Passion, however, is more of a longstanding commitment. The biographies of the great technologists and authors of the recent past are full of the sort of passion and engrossment that lead a person to write a novel non-stop for a fortnight with no sleep and only dog food to eat (Philip K. Dick), or refuse to leave the works of the first tunnel under the Thames, even though it was flooded (Brunel).
In a similar (though more modest) way, my passion for working with databases has led me to acts that might cause someone for whom it was "just a job" to roll their eyes in disbelief. Most evenings you're more likely to find me reading a database book than watching TV. I've spent hundreds of hours of my spare time writing blogs and articles (some of which are only read by tens of people); I've spent hundreds of dollars travelling to conferences, paying my own flight and hotel expenses, so that I can share a little of what I know, and mix with some like-minded people. And I know I'm far from alone in this, in the SQL Server community.
Passion isn't everything, of course, and it isn't always accompanied by any great skill, but in almost every case, that skill can be cultivated over time. If you are doing what you are passionate about, work turns into more than just a way to feed your kids; it becomes your hobby, entertainment, and preoccupation. And it is this passion that gives a DBA the obsessive stubbornness, the refusal to be beaten by even the most difficult problem, which is often so crucial.
A final word of warning though: passion without limits can turn weird. Never let it get in the way of your wife, kids, bills, or personal hygiene.
|
|
|