The checklist manifesto

Some time ago, I came up with a new presentation idea that I tentatively titled “The magic of checklists.”  The idea is to demonstrate how checklists can improve tasks in any organization.  I have a number of ideas regarding this presentation, and I’ll expand upon them in a future ‘blog article.

As preparation for this idea, I assigned myself some homework.  My friend, Greg Moore, recommended a book to read: The Checklist Manifesto by Atul Gawande.  I borrowed a copy from the local library and started reading.

The book (which I’m still reading) is turning out to be an excellent read: so much so that I’m considering purchasing my own copy, instead of just relying on the one I borrowed from the library.  (This way, I can use a highlighter and scribble my own notes in the book.). Yes, it reinforces my ideas about using a checklist to improve upon workplace tasks.  But I’m also discovering that there is so much more.  Reading this book has enlightened me on numerous ideas that had never occurred to me.

The book hits upon numerous concepts, each of which is worth an entire presentation in their own right.  Among them: the importance of communication, organizational structure, teamwork, crew/team resource management, keeping an open mind, empowering a team, following instructions, making adjustments, and doing the right thing.  (Since I’m not yet finished with the book, there are likely a number of other concepts I haven’t mentioned that I haven’t yet come across.). When I first picked up the book, my initial thought was, “how much can there be about a simple checklist?”  I’ve since learned that a checklist — any checklist, no matter how small — is not simple.  And while a checklist is an important tool, it is also a big part of an even bigger process.  All the ideas I listed several sentences ago are all part of that process.

I’d like to relay a story I came upon in the book.  David Lee Roth of Van Halen was famously known for canceling concerts if his instructions for leaving a bowl of M&Ms with the brown ones removed in the dressing room were not followed.  Many people — myself included — decried him for these seemingly cockamamie instructions.  However, there was a method to his madness.  It turned out that this was a test.  If that instruction hadn’t been followed, then it was possible that another critical instruction — like, say, installing bracing to ensure the stage didn’t collapse — had not been followed.  (And before you think instructions like these can’t be missed, they can, and they have — sometimes, with disastrous consequences.) It goes to show that there is always more to the story.

Once I finish reading this book and can organize my thoughts, I’ll put out another article and another presentation (hopefully, coming soon to a SQL Saturday near you).  In the meantime, I highly recommend this book.  Maybe it’ll change your perspective the way it has changed mine.

Advertisements

“I lost my job. Now what?!?”

Before any of my friends panic, no, I didn’t actually lose my job (at least not at the time of this article); this is just what I’m using for the title.

Having said that, here’s a little background for what prompted me to write this. A few weeks ago, I saw a Facebook post from a friend of mine. She was (understandably) flustered because her husband had lost his job.  I wanted to help them (and others) out, so I began jotting down my thoughts for this article.  Ironically, I had a Facebook “on this day” memory come up on the very same day that I started jotting down my notes for this article; it turned out that on that day four years ago, I was laid off from a job as well.

Losing your job is always a scary proposition. Very few people (that I know of) wants to be unemployed.  There’s a great deal of uncertainty.  Questions enter your mind; among others: “how long will I be out of work?”  “How will I pay the bills?”  “How will I get by?”

Having been there and done that, I empathize with people who find themselves jobless.  For those of you who find themselves in such a situation, here are some tidbits that helped me through these tough times.

  • Above everything else, control your emotions.  When you lose your job, your emotions run wild.  Most likely, you (understandably) get scared, depressed, angry, frustrated, and so on.  The worst thing you can do is lose control of yourself.  If you need to do so, find a safe way to blow off steam and keep your feelings in check.  It isn’t healthy to keep those emotions bottled up, but at the same time, it is absolutely critical that you keep your head on your shoulders.  Find a healthy way to get those feelings out of your system, but don’t let those feelings control you.
  • Keep a positive attitude.  It is very easy to get down on yourself when you lose a job.  Strangely, the last time I lost my job, I actually felt invigorated.  I looked at it as an opportunity.  It wasn’t so much that I’d lost my employment as much as I was being offered a chance to try something new.  I wrote a while back that a positive attitude can be a powerful thing.  Rather than dwelling in what was, focus on what might be.
  • Take advantage of your free time.  A friend of mine who’d lost his job at one point told me that he took advantage of his suddenly-acquired free time to spend time with his family, play golf, and do things he didn’t have time to do because he was at work.  While he did focus efforts on his job hunt, he also made it a point to balance his time between searching for a job and having fun — which brings me to another thought…
  • Looking for a job is a full-time job.  Back in the good-old “answering help wanted newspaper ad” days, quantity was quality (there might be some recruiters who disagree with me on this, but I digress).  I am, admittedly, old school, so a part of me still subscribes to this mindset.  There were job hunts where I averaged about ten applications a day.  There’s also doing your homework — researching companies and potential employers, sizing them (and yourself — again, more on that in a minute) up, getting addresses, making phone calls, polishing your resume and your cover letters, and so on.  That makes for a lot of time and effort, and it will tire you out.  Make the time for your job hunt endeavors — but don’t forget to balance your life as well.
  • Find something to hold you over.  No, flipping burgers isn’t sexy, but it’s a source of income.  Even minimum wage is better than, say, zero (and it might also be better than unemployment benefits, which, in my experience, usually pays squat).  There is no shame in taking a temp job to hold you over until you land on your feet again.
  • Get involved, and keep yourself busy.  Number one, it’ll get your mind off your situation.  Number two, it’s a chance for you to network (again, I’ll expand on that in a bit).  Number three, you might learn something new that would make you marketable.  For more thoughts on getting involved, check out my article on getting involved with user groups, as well as an article I wrote about using your skill set for speaking at conferences.
  • Be honest with yourself.  When I started getting down on myself about my job situation, I asked myself a few questions, including: “where do my strengths lie,” “what am I capable of doing,” and “what do I really want to do?”  I identified my own skill sets and my interests; this, in turn, helped me identify positions for which I was qualified, as well as developing my own professional persona that helped me with interview skills.
  • Be creative.  As part of my job search, as well as a tool for networking, I created business cards for myself.  However, these were no ordinary business cards.  I remembered a scene in Mr. Baseball where Tom Selleck’s character learned that Japanese businessmen networked by exchanging business cards.  He gave them his baseball card.  That got me thinking: “Business card…  baseball card…” and I put the two together.  The result is what you see in the picture below.
    raysbizcardpic
    My networking business card

    The picture is a souvenir photo I got on a trip to Cooperstown (they dressed you up in the uniform of your choice and took your picture with a stadium backdrop).  I took that photo and made it into the business card you see above.  The back side has my contact information, and inside (it’s a folded card) contains a mini-resume with my career information.  I always get great reactions from people when I hand these out; someone even once said to me, “if I was in a position to hire, I’d hire you right now just because of this card!”  People will remember you, and it makes a great conversation piece.

    You don’t have to come up with a baseball-business card (hey, my idea, darn it!), but by all means, tap into your creativity to get yourself noticed!

  • Network, network, network!  Did I mention that you should network?  These days, networking is probably the best way to find a job.  Someone who knows of a job opening can probably tell you about it long before the open position becomes public knowledge.  That extra time could very well be your foot in the door.
  • Take advantage of available resources.  In this day and age of communication, you have no excuse not to make use of social media.  LinkedIn is specifically designed for professionals, and many online resources (including and especially job-hunt and networking resources) ask if you have a LinkedIn account.  If you’re looking, you can’t afford not to have an account.  While Facebook isn’t specifically geared toward professional networking, it is still another resource you can tap.
  • Don’t limit yourself.  Would you consider moving or taking a job outside your geographic area?  Would you consider working from home?  What about a different line of work?  Would you work part-time, odd hours, or a contract position?  If you’re in a jobless situation, you may very well need to keep your options open.

These are just some of my thoughts regarding surviving a jobless situation.  Did I miss anything, or do you disagree with any of my thoughts?  Feel free to comment below.

On memorization

About a week ago, I got a text from a friend saying that she was taking up the accordion again.  (If said friend is reading this, I didn’t know you played the accordion!)  Knowing that I have a background as a classical pianist, she asked me my advice on how to memorize music.  I told her I was going to respond in an email with my thoughts, but thinking that those thoughts would also be helpful to others, it became fodder for yet another ‘blog article.

I used to teach IT and mathematics classes part-time for a small business school in Albany.  For most of those classes, I made my exams open-book, open-note.  I cited a number of reasons for doing so — among them, I didn’t want them to suffer exam anxiety, and I wanted them to develop teamwork skills (I told them they were allowed to help each other figure out answers, but were not allowed to give or receive answers).

I also told them that I believed in the ability to research answers, and I didn’t believe in rote memorization.  For one thing, as I told my students, when you’re out in the real world, how many employers are going to tell you to “put all your notes away; you’re going to work on this project completely from memory”?  For another, I believe that rote memorization is ineffective.  I strongly believe it is a horrible way to learn material.  Memorizing facts and buzzwords isn’t the same as knowing how to use them, and it’s definitely not the same as learning the material.  You can memorize an entire dictionary, but unless you know how to put words together to develop sentences, thoughts, and ideas, it isn’t going to do you a lot of good.

Additionally, even if you do try to memorize something, it will never be perfect.  We are human, after all, and our capacity to remember is limited.  I’ve often thought about memories from years ago, thinking that I remember every detail, only to come across a picture of that memory, and realize that it wasn’t as accurate as I remembered.

“Okay,” you might be asking, “but you have music experience.  What about all those classical pieces you’re required to perform note for note?”

Ah, yes.  Let’s talk about that, shall we?

Let’s talk about memorizing music.  First, I am not Lang Lang, or Yo Yo Ma, or Yefim Bronfman.  Despite my significant music background, I am not a professional musician.  So I won’t pretend to know how professional classical concert musicians learn and memorize new pieces of music.  Instead, I’ll talk about how I approach it.

I play the piano in church on Sunday mornings.  There are a number of pieces that I’ve gotten to know so well that I don’t use sheet music for them.  I remember one parish member talking to me about how I would “memorize” those pieces.  However, “memorize” is not an accurate term.  A better way to put it is that I’ve gotten to know the pieces, and am able to use chord progressions and patterns that fit them — in a way, I can “color” them at will.

Let me put this another way.  Most of us know how the song “Happy Birthday” goes.  But did you memorize it?  Most likely, you didn’t.  You recognize it, you remember it, and you can sing it.  But you didn’t memorize it (at least not in the sense that most of us think).  Think about your favorite music artist, or your favorite songs.  You probably know all the words.  You can probably sing (or at least hum) every song down to the last note.  But would you say that you “memorized” them?  You might be able to say you did.  But I don’t think that is the right term here (to be honest, I don’t know what the right term is).  Them same holds true for when I’m playing music.  The difference is, when I’m playing the piano, my output is through my fingers, rather than my voice.

When I’m practicing a piece, I’ll usually learn it a few measures at a time.  I’ll continually practice those few measures until I get them right (or at least something close to it).  Once I have them down to a level to which I’m satisfied, I’ll move onto the next few measures.

When you practice an instrument, it isn’t so much thinking about memorizing music.  It’s more about muscle memory.  Practicing means developing your muscles so that they’re used to it, and you can do it again.

Ask yourself this: when you’re preparing music for performance, does it have to be exactly like the notes on a page?  Unless you’re performing a classical (or a similar type of) piece that requires a great deal of precision and technique, in many cases, the answer is, probably not.

A friend of mine once asked me to accompany a show for which she was the music director.  I wasn’t the first person she asked; she had another accompanist before me.  However, she had to fire him.  My predecessor absolutely insisted on playing every single note as precisely written, and it was slowing down the process of everyone else learning the show.  When she brought me on board, I made it a point to learn the music as best as I could, and ad lib everything, much as a jazz musician would follow a fake book (which, when I’m not learning a classical piece, is pretty much how I approach most music, anyway).  In my approach, I was able to provide a good accompaniment, I was able to help others with their music, and we pulled off a very successful show.

Personally, I find it a lot of fun trying to put my own spin on music.  I take it as a challenge trying to take a piece of music I like and making it sound as close to the original as I can.  It usually doesn’t, but that’s okay; I’m a big believer in not trying to make a piece of music sound exactly like the original.  I’ve often said that what people should really do is take a piece of music and make it theirs.  Every artist is different, and every artist will put their own spin on a piece of music.

So in all honesty, I believe that memorization isn’t all that it’s cracked up to be.  Just work on it as best as you can, reproduce it as best as you can, and enjoy your own interpretation of it.  You might find that what you produce is much more rewarding.

Keeping up with the Jones (or Gates, or Zuckerbergs…)

In the fast-moving world of technology, it is increasingly important to keep up with technological trends.  What was state of the art a few years ago may already be obsolete now.

I’ve been working in technology since I graduated college many years ago.  I started my professional career as a lowly computer operator, overseeing Informix database backups and working with SCSI drives (that’s “small computer system interface” for those of you who are wondering; I’m not even sure that SCSI is used anymore).  Each of these drive devices was about the size of a desktop PC or even a server.  I don’t remember how much data capacity they held, but I do remember that we did not measure it in GB.

I remember at the time when we took delivery of a one-gigabyte (for emphasis, that’s 1 GB — as in 1024 MB) tape drive that we were going to use for data backups.  We used to take these tiny cassettes, hold them in our hand, and joke, “in my hand, I am holding the Library of Congress.”

My, how times have changed since then.

For me, personally, I’ve had a more difficult time with keeping up with current trends as I get older.  For example, this past year, I was made aware of a relatively new data language called R.  If you’re a data professional, it’s likely something that you’d want to learn (again, there’s that theme about keeping up with trends).  There is a large number of technologies that are getting better, and it is impossible to keep up with all of them.

So how does one keep up with the times?

Personally, I’ve always had a knack for adapting to my environment; it is what has allowed me to survive professionally for so long.  I had been working as a developer for a few years, but when I realized that I was having a difficult time keeping up, I accepted a transition to a different department and a different role last year.  (For those of you who are curious, my role is difficult to describe in three words or fewer; I’ve largely been telling people that my new role is as a “programmer/analyst.”)  Among other things, I had an honest conversation with myself, asking myself what I really wanted to do, what my strengths were, and what I was capable of doing.  My new role better leverages my strengths, and I’ve been busier (and more content) than I’d been in a while.

(It also helps that I consider myself a team player.  When I was offered this role, I was asked if I was okay with it.  My response: “I play for the team.  Whatever you guys need from me, I’ll do.”)

A while back, I wrote about how important it was to get involved with user groups.  I do think it’s important to get involved with things, especially as we get older.  It enables us to learn new things, it’s a great way to network, and it’s a lot of fun.

Change is inevitable.  We need to acknowledge that we are changing, and we need to acknowledge that the world around us is changing.  It is for that reason why we need to stay on top of advancements if we want to survive — both professionally, and personally.

So you’re probably asking, “why don’t you write?”

“Life is what happens to you while you’re busy making other plans…”
— John Lennon, “Beautiful Boy”

“Waiting for the break of day; searching for something to say; flashing lights against the sky; giving up, I close my eyes…”
— Chicago, “25 Or 6 To 4”

No, I haven’t dropped off the face of the earth.

I haven’t been as prolific with my ‘blog entries as I would like.  To be honest, life and various commitments got in the way — as it happens with most people.  And when I have had free time, writing has been the farthest thing from my mind.  Sometimes, things happen.

So stay tuned.  All things eventually settle down.  And when that happens, you’ll hear from me again!

On data types

Previously, I talked about something I saw in the code that built the tables in my baseball database.  I wrote last time about primary keys.  In this article, I want to talk about data types.

Let’s revisit the code that builds the Batting table again.

CREATE TABLE [dbo].[Batting](
	[playerID] [varchar](50) NULL,
	[yearID] [varchar](50) NULL,
	[stint] [varchar](50) NULL,
	[teamID] [varchar](50) NULL,
	[lgID] [varchar](50) NULL,
	[G] [varchar](50) NULL,
	[AB] [varchar](50) NULL,
	[R] [varchar](50) NULL,
	[H] [varchar](50) NULL,
	[2B] [varchar](50) NULL,
	[3B] [varchar](50) NULL,
	[HR] [varchar](50) NULL,
	[RBI] [varchar](50) NULL,
	[SB] [varchar](50) NULL,
	[CS] [varchar](50) NULL,
	[BB] [varchar](50) NULL,
	[SO] [varchar](50) NULL,
	[IBB] [varchar](50) NULL,
	[HBP] [varchar](50) NULL,
	[SH] [varchar](50) NULL,
	[SF] [varchar](50) NULL,
	[GIDP] [varchar](50) NULL
) ON [PRIMARY]

Last time, I mentioned that every single column allowed NULL values (and I’d like to expand on that in a future article).  Today, I’d like to talk about the fact that every single column is defined as varchar(50).

For those of you who are getting your feet wet with SQL Server (or don’t know what I’m talking about), let’s take a moment to discuss…

What are data types, and why are they important?

Imagine that you’re presented with a math problem (don’t worry; we’ll keep it simple).  However, when you’re presented with the problem, it looks like this:

XII + IX

Want to give it a shot?  The truth is, there’s a reason why we don’t normally use Roman numerals in our society.  Unlike the Arabic numeral system that we use in everyday life, the Roman numeral system is inefficient and not very intuitive at a glance.  For us to use Roman numerals, we’d first need to convert them into a format that we can easily understand.

So, knowing that XII = 12 and IX = 9, our new math problem is 12 + 9.  We now know our answer is 21.  (And if we want to convert back to Roman, it’d be XXI.)

Data types operate along the same principle.  A number that’s stored as a data type of, let’s say, varchar(50) (for those of you who don’t yet know T-SQL, that’s “variable character of up to 50 characters”) needs to be converted to a numeric type of (for example) int (for “integer”) before it can be processed.

“Okay,” you might ask, “why is that such a big deal?  Just let the system do the conversion and let it do the work.”

Let’s go back to that Roman numeral example for a moment.  In order for you to understand what the Roman numerals were, your brain had to do some work to perform the conversion.  Imagine that you had to process dozens, even hundreds, of those problems.  That’s a lot of Roman numerals that you have to process.  That makes for a lot of work.

Likewise, imagine that a computer system has to convert millions of data types.  That’s a lot of extra work that your computer has to do.  That can make for a very inefficient system.  One of the big issues that a DBA or a developer often has to deal with is a slow system.  Using proper data types can often help with trying to fix a slow system.

What kinds of data types are there?

In a word, many.  A number of web sites list data types for various systems, including MSDN and W3Schools.  Since I’m writing primarily about SQL Server, I’ll focus on SQL Server data types.  I won’t talk about all SQL Server data types (I’ll leave you to look at the links for that); rather, I’ll just discuss a few that are relevant to our conversation.

Let’s start first with the varchar data type, since that’s what’s defined in our tables.  Varchar is for variable character.  What that means is the data type accepts character strings up to a length that you specify.  A data type of varchar(50) means that the field accepts strings up to 50 characters.

There is also a char data type.  Like the varchar type, you specify the number of characters allowed by the data column.  Unlike the varchar type, however, it is a fixed length string.  A column of type char(50) means that the data will always have 50 characters.  If data that is fewer than 50 characters is stored, it pads the rest with spaces.  This is important to consider, because those characters (even the space characters) take up space.  If you’re storing millions of rows of data, and you’re using char data types for data that takes up fewer than the number of characters you specify, that’s a lot of wasted space.

So, let’s revisit our Batting table.

BaseballBatting

When we built our primary key, we created a composite primary key from the playerID, yearID, and stint columns.  Can we improve upon these columns?

Let’s look at playerID.  Do we need to reserve fifty characters for this column?  To find out, I ran the following query.

select distinct playerID, len(playerID) from batting
order by len(playerID) desc

To translate this query into English*, this means “give me each distinct playerID, along with the length of the playerID, from the batting table, and give me the results in descending order of length.”

(*For those of you who don’t speak T-SQL, yes, I do intend to write an article about it.)

The results looked like this:

PlayerIDLength

So what does this mean?  It means the longest playerID is nine characters.  Could it be longer than nine?  Possibly.  Will it ever get up to fifty?  Unlikely.  So while the varchar(50) will definitely accommodate this, my thinking is that it’s overkill.  I’m going to shorten the column.  I’m going to cut it down to 25 from 50.

Now, let’s look at the yearID column.  I ran the same query as earlier, but this time, I replaced playerID with yearID.  Every column was four characters long.

SQL Server provides us with a number of date and time data types.  My first thought was to use one of these data types, but at that point, I stopped to think.  What, exactly, is the purpose of the yearID column?  It identifies a season.  That’s it.  Will I perform any calculations with it?  It’s possible, but unlikely.  Will it ever change from four characters/digits?  No.  I’m going to make this a fixed four-character field.  For that, we’ll use char(4).

Now, let’s look at stint.  What is this column?  It keeps track of a player’s stint with a team in a season.  So, let’s see how this works.

I went into the database and looked to see what stint values were in the Batting table.  There were five.  I looked up the player who had five stints, and found a man named Frank Huelsman, who played in the early 1900s.  I ran a query that gave me this.

FrankHuelsmanStint

In 1904, he had five stints with four different teams, having played for the White Sox (twice), Tigers, Browns, and Senators.

So, what data type should we use for stint?  Let’s think about this.  We could use a char(1), but I don’t think we should.  Is it possible that a player could have ten or more stints in a year?  Unlikely, but yes.  So we’d need at least two characters.  Let’s try char(2) — or should we?

I say no.  I say that we should use a tinyint data type for stint.  Why?

I say it for a couple of reasons.  First, there the matter of ordering.  Let’s order the numerals 1-10.  How would you expect them to be ordered if they were stored as characters?  If you say 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, you’d be wrong.  If it was defined as a character data type, the order would look like this: 1, 10, 2, 3, 4, 5, 6, 7, 8, 9.  When we’re talking about characters, 10 comes after 1.

Second, there’s a matter of memory.  tinyint uses only 1 byte, as opposed to 4 bytes for int. The memory used by char and varchar data types are dependent on their sizes (i.e. how much is allocated).  Also, tinyint accommodates values from 0 to 255, which is plenty for our purposes.

So, let’s start by redefining the data types for our composite primary key.  Because T-SQL in SQL Server won’t let us alter multiple columns at once, we need to run them as separate queries.  I wrote three statements like this:

alter table Batting
alter column playerID varchar(25)

alter table Batting
alter column yearID char(4)

alter table Batting
alter column stint tinyint

This should do the trick — or so I thought.  When I ran the queries, SSMS gave me error messages that looked like this:

Msg 5074, Level 16, State 1, Line 1
The object 'PK_playerID_yearID_stint' is dependent on column 'playerID'.
Msg 4922, Level 16, State 9, Line 1
ALTER TABLE ALTER COLUMN playerID failed because one or more objects 
access this column.

What’s going on here?  Keep in mind what we’re trying to change: three columns that are part of a primary key.  So before we can alter these columns, let’s drop our primary key.

alter table Batting
drop constraint PK_playerID_yearID_stint

Now when we run our alter table statements, we should be set.

Or are we?  I tried to recreate the primary key (I decided to rename the primary key, while I was at it).

alter table Batting
add constraint PK_Batting primary key (playerID, yearID, stint)

Instead, it gave me the following error:

Msg 8111, Level 16, State 1, Line 1
Cannot define PRIMARY KEY constraint on nullable column in table 'Batting'.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint or index. See previous errors.

Now what’s going on?  Apparently, I’d forgotten to include the NOT NULL statement when I altered the columns.  So this time, I’ll rewrite the statements like this and rerun them.

alter table Batting
alter column playerID varchar(25) not null

alter table Batting
alter column yearID char(4) not null

alter table Batting
alter column stint tinyint not null

After running these statements (which ran successfully), I retried my statement that added the primary key.  This time, it worked.

So, our primary key columns are now altered.  Let’s look at the rest of our table.

Our first two columns are teamID (for “team ID”) and lgID (for “league ID”).  I checked the data in these two columns (I’ll save you the trouble of looking at the T-SQL I used).  I found that they are never null, and they are always 3 characters and 2 characters, respectively.  They are also not unique.  For our table, I’ll redefine them as char(3) and char(2).

Now let’s look at the rest of the table.  For the benefit of anyone who doesn’t understand baseball, let’s write out what these columns are.

G Games
AB At Bats
R Runs (Scored)
H Hits
2B Doubles
3B Triples
HR Home Runs
RBI Runs Batted In
SB Stolen Bases
CS Caught Stealing
BB Base On Balls (Walks)
SO Strikeouts
IBB Intentional Base On Balls (Walks)
HBP Hit By Pitch
SH Sacrifice Hits
SF Sacrifice Flies
GIDP Grounded Into Double Play

They’re all statistics, and they’re all integer values.  For now, we’ll make them all integer values.  Do we make them NOT NULL?  Not necessarily.  Why?  Because for some records, certain statistics didn’t exist during their time, so they might not exist.  Some of these numbers may very well be NULL.  So we won’t add the NULL constraint.

Here’s what I wrote for my T-SQL:

alter table Batting alter column [teamID] char(3) not null
alter table Batting alter column [lgID] char(2) not null
alter table Batting alter column [G] int
alter table Batting alter column [AB] int
alter table Batting alter column [R] int
alter table Batting alter column [H] int
alter table Batting alter column [2B] int
alter table Batting alter column [3B] int
alter table Batting alter column [HR] int
alter table Batting alter column [RBI] int
alter table Batting alter column [SB] int
alter table Batting alter column [CS] int
alter table Batting alter column [BB] int
alter table Batting alter column [SO] int
alter table Batting alter column [IBB] int
alter table Batting alter column [HBP] int
alter table Batting alter column [SH] int
alter table Batting alter column [SF] int
alter table Batting alter column [GIDP] int

The query, which took 20 seconds to run, ran successfully.

Note that I only dealt with a few data types in this article.  I didn’t talk about decimal data types or computed values.  (What if, for example, we wanted to keep track of batting averages?)  I’ll cover those in a later article.  Hopefully, at this point, you’ll have a better idea of what data types are and what they can do.

The only person whom you can change

“Q: How many psychiatrists does it take to change a light bulb?”
“A: Only one, but it really has to want to change.”

“If you choose not to decide, you still have made a choice…”
— Rush, “Freewill”

“Minds are like parachutes.  They only work when they’re open.”
— Thomas Dewar

The other day, I was watching the Tour de France on the TV with a couple of friends, when another guy walked in.  He started going off, unprompted, about how “bicycling isn’t a real sport,” “I know because I worked with bicyclists,” and so on.  The way he was talking, it was blatantly obvious, even to me who doesn’t know as much about cycling (as a sport) as my friends did, that he had no idea what he was talking about.  This person was aggravating — to the point where one of my friends finally said to him, “I’m done talking to you.”

Someone once said that you can’t outtalk someone who knows what he’s talking about.  Unfortunately, you also can’t outtalk someone who has an opinion and is unwilling to change it.  It is for exactly this reason why I refuse to talk about politics with anyone.  No matter what facts you tell that person, you’ll never be able to change him or her.  Any attempt to do so only gets you frustrated and angry.

There is only one person over whom you have 100% control: you.

You have the power to influence change on others.  You can’t completely change them.  We all have our own thoughts and opinions that we express to others.  But as much as we’d like for people to see the world the way we see it, it’s ultimately up to them to make up their own minds and act upon their own thoughts.

I’m thinking about the movie Coming To America, where Eddie Murphy’s character is talking to his newly appointed bride-to-be.  “Jump on one leg.  Bark like a dog.”  And she does — without any question.  This scene brings up two thoughts.  First,  what he couldn’t do was convince her to be her own person.  He doesn’t have that power.  Nobody does, except for that person.  Second, would you really want a friend, spouse, or significant other who (as much as we like to joke about it) is completely obedient to every single word you way?  I sure don’t.  My wife is one of the most strong-willed individuals I know (note: individual is a key word).  And I wouldn’t want her any other way.  Sure, we fight on occasion; all spouses, couples, and even friends do.  There is no relationship that is 100% perfect.  There shouldn’t be.  Every person is their own individual.  It’s up to that person as to how to change.

I previously wrote about how change is inevitable.  It is up to us to determine how that change happens — and how we should handle it.  We can always try to influence change — and we should.  But influencing change is not the same as implementing change.  People will always try to influence you with their opinions.  What you do with those opinions is up to you.