Memories of Pan Am 103

(Photo source: Wikipedia)

There are moments in your life when you remember exactly what you were doing as though it happened yesterday, even if it happened many years ago.  I previously wrote about what I was doing on 9/11.  Likewise, I remember other events, such as the Challenger disaster (I was a freshman at Syracuse having lunch in my dorm dining hall).  In this article, I want to write about another such fateful day.

Yesterday, with only a day to go before Syracuse opens its football season at Western Michigan, I went poking around a couple of websites for more information about the upcoming game.  I went to the Daily Orange‘s website, and in doing so, I stumbled upon this article, which I was not expecting to see.  As soon as I saw it, memories from nearly thirty years ago suddenly came back to me.

On December 21, 1988, I was winding up the fall semester of my senior year at Syracuse University.  I was living in a house that I shared with six other guys only a block off-campus.  It was finals week.  That evening, I was in my room, studying for one of my final exams.  I decided to take a study break and went downstairs to the kitchen to get myself a snack.

As I made my way down the stairs, I saw my housemates in the living room, gathered around the TV.

“What’s going on?” I asked.

“A plane crashed, and there were Syracuse students aboard,” I was told.

I was in shock.  To be honest, I don’t think I got back to studying that night.  I took a seat in the living room with my housemates and was glued to the TV, watching the news for the rest of the night.

The phone started ringing.  A number of band alumni friends (all of us in the house were members of the marching band) had just heard the news, and were calling to ask if any band members were on board.  (Those of you who know about marching band culture understand that band members consider each other to be family.)  At that point, news was just trickling in, and we were not aware of who was on the plane.  I remember hearing that SU students were aboard, but there was no information as to how many of our classmates were affected.  We heard varying numbers: ten, fifteen, nineteen.

I went for a walk around campus the next day.  The campus was eerily deserted, except for a few news trucks parked around the campus to cover the breaking story.  For such a large campus like Syracuse, the entire place felt like a ghost town.  With the nearly empty campus, combined with the cold December air, it was probably the only time I ever felt unnerved walking around the campus.

It turned out that there were thirty-five Syracuse students on Pan Am 103.  Thirty-five of my classmates were gone.  Although I didn’t know any of them, I now feel as close to them as I do any of my friends from college.

Syracuse played a home basketball that night.  As a member of the pep band, I could’ve attended the game, but I opted not to go, since I still had final exams to study for.  I understand that SU got a lot of flak for not canceling the game in light of the tragedy.  They did observe a moment of silence at the beginning of the game.

The marching band did have an opportunity to recognize the tragedy a couple of weeks later.  The Orange football team had played its way to a 9-2 regular season, good enough for a berth in the Hall of Fame (now Outback) Bowl in Tampa, FL.  We wore black ribbons on our uniforms for the game, and observed a moment of silence on the field during our pre-game show.  After the game, I took some White-Out and wrote “PA103” on one half of the ribbon, and “12-21-88” on the other.  I still have that ribbon.

Syracuse University has since paid tribute to the disaster by building a memorial, setting up a scholarship fund, and setting aside a Remembrance Week commemoration each year.  Whenever I’m back on campus, I try to take a moment to spend some time at the memorial as I remember my thirty-five fallen classmates.

Part of my reason for writing this post is so I can go back to that article I found.  At some point, I want to travel to Scotland and take a trip to Lockerbie — a pilgrimage, if you will.  I feel a need to connect with my classmates at the place where they died nearly thirty years ago, as well as pay tribute to the small town that was affected by the tragedy.  The article helped me better understand the town of Lockerbie, which would enable me to better respect the people there who have since moved on from that fateful day.

Advertisement

Technical writer’s block

“What no wife of a writer can ever understand is that a writer is working when he’s staring out of the window.”
— Burton Rascoe

“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”

Those of you who write creatively — whether it’s a book, an article, music, etc. — have all experienced writer’s block.  Even if you don’t write, maybe you’ve experienced it in some form.  Maybe you were assigned a writing project in school.  Maybe you’re trying to come up with ideas for a party or how to celebrate a co-worker’s special occasion.  It even comes up when my wife and I discuss what to do about dinner (“What do you want?”  “I don’t know!  What do you want?”).  No matter what form it takes, the moment when your brain fails to come up with any ideas (sometimes called a “brain cramp”) happens to all of us at some time or another and more often than we’ll admit.  As much as I’d like to post a ‘blog article each day, there’s a reason why I don’t.  A lot of it is because I don’t necessarily write articles professionally and I don’t always have the time to do it, but an equal part of the reason is not being able to think of things to write about.

For this article, I’d like to talk about technical writer’s block — yes, there is such a thing, and it happens more often than you think.  (I don’t know if that’s a widespread term; for all I know, I might have just coined a new phrase.)  However, it differs from other forms of writer’s block in that a technical writer already has a subject about which he or she is writing.  In this case, it’s not a matter of what you’re writing about; it’s more a question of how to write about it.  I can’t tell you how many times I’ve stared at a computer screen for (at least) twenty minutes, only to realize that I spent those twenty minutes just blankly staring at the screen.

Those of you who are technical writers, let’s see a show of hands: how many of you have been given, say, a step-by-step instruction to write about, but have agonized about how to put it together?  Should you list them as numbered instructions?  Should you keep it to simple bullet points?  Is it better to put items into a table and write out definitions for the terms?  People who know nothing about technical writing don’t understand the struggle; they think it’s just a matter of throwing it together and making numbered points from them.  What they don’t realize is that it is not that simple.

For one thing, writing instructions isn’t that much different than writing code.  Both involve logic.  But let’s say you have an instruction to “push the red button” but only if you performed another step or are faced with a specific circumstance.  In structured programming, this would probably take the form of an IF-THEN or CASE statement.  But when you’re writing a document, situational instructions aren’t as clear cut.  There is no standardized method for writing an if-then statement in a step-by-step document.  I’ve seen this situation addressed in different ways; in one job where I was employed as a full-time technical writer, the group include a style with their template that included a small table for these situations: do this for one situation, do that for another.  I’ve seen others where a step is accompanied by a note: “this only applies to (whatever).”  Since there is no standard way to address this, it likely makes writing instructions more, not less, difficult than writing code.

Your audience likely plays a role.  I’ve espoused time and again that you need to know the audience for which you’re writing.  In my first successful technical writing project, I made sure that I put myself in the reader’s shoes, empathizing with the reader.  “How do I write this so I can see what I need to do?”  That strategy made things very clear, and I was able to write a good document.  Unfortunately, tech writers don’t always have this luxury; sometimes, either the type of audience is unclear, or the writer is writing for multiple audiences.  If you know your audience, it gives you an idea as to how to structure and write your document.

As I wrote earlier, design matters.  Of all my experiences with technical writer’s block, this is probably the one with which I struggle the most.  How should things be laid out that would most help the reader?  Where should things be placed so that they best direct an end user?  A document’s design often makes or breaks a successful document.

I just wrote about some of the issues I face.  How to resolve them is not as clear cut, and I don’t have as many answers as to how to address them (that might be worth its own article).  Here are a few ways that I’ve dealt with technical writer’s block.

• Ask questions.  Clarification helps answer some of the issues with which I have to deal.
• Get help.  Another set of eyes can sometimes break the impasse.
• Work on something else.  Working on another task can sometimes spur ideas.
• Walk away.  Sometimes, you just need to take a break.

I’m sure there are others ways as well that haven’t occurred to me.  How do you deal with technical writer’s block?  Feel free to respond in the comments.

Fun times in the office

Steve Jones’ post today about fun at work got me thinking about the fun times I’ve had in the office.  So I thought it’d be fun to write an article in which I shared a few photos of some fun times I’ve had in my workplace, past and present!  Enjoy!

Here’s a pic of me around the holidays.  As you can see, I just have to have something Syracuse-related at my desk.  I’m loyal to my alma mater; what can I tell you?

My office has a significantly large Indian population.  Last year, they had a Diwali celebration in the office, to which the entire office was invited!  This is a pic of the spread in the main conference room.  If you walked away hungry that day, it was your fault!

One day, we declared Hawaiian Shirt Day in the office!

This next pic is from a previous job, right after I was moved to a new desk.  My friends asked me if I had my stapler, so I took this pic.  Yes, it was a Swingline, but unfortunately, I didn’t have a red one!

Practical jokes abound!  One of my co-workers built this around another cube while the occupant was on vacation!

Of course, said co-worker got her revenge!

One day, one of my co-workers and I randomly showed up at work wearing these.  How often do you see two guys in the office randomly wearing hockey jerseys on the same day?

Another pic from another previous job.  I looked out the window, and saw this guy sitting on the street light!

And finally…  I occasionally need to work from home.  Here’s one of me where I’m working out of my living room…  along with my co-worker for that day!

Agnostic document references

Many of you who are technical writers — or data professionals — understand how important it is to not expose real data.  There is a huge emphasis on data security, as there should be.  But a lot of people never think about smaller pieces of data within a document — something as simple as, say, an email address.  In a lot of documentation I write, I make it a point to make much of it as anonymous and agnostic as possible.  There are a number of reasons for this, as I outline below.

I’ll start with a point of emphasis that I make in documentation time and again: know your audience.  Earlier this year, I was responsible for writing a user guide for an application that was to be used by multiple clients.  When I first started working on the document, the application was only being used by one client.  The application — and the document — contained many references to that one client.  In order to update the application to serve multiple clients, all references to the one client had to be removed, not just in the application itself but also in the documentation.  If a document is to be used by multiple audiences, specific client references should be made generic.

Likewise, I’ve accessed applications that display my name on the screen: “Welcome, Ray Kim,” for example.  If I screen-capture that image, I often alter the image so that my name is removed.  I don’t know about you, but I wouldn’t want to be contacted incessantly about an application that I probably know little about.

Another reason is data security, which becomes a larger issue by the day.  Sensitive corporate data risks being exposed within documentation.  For example, for my screen captures and illustrations, I request a “dummy” account that displays “bogus” corporate data for document illustration purposes.  I’ve gotten into the habit where I request this for every document I write.  Corporate data is sensitive; indeed, there is an increasing awareness of keeping such data private (the European Union’s GDPR and laws such as HIPAA and various other data protection laws come to mind).  Live data should never be used in documentation (unless authorized by the client in question); you can never tell what can be revealed in that data.

Here’s another reason I have for keeping documentation generic.  Let’s say, for example, an instruction for additional help directs you to “contact john.smith@yourcompany.com” in your document.  However, there’s one problem: John Smith no longer works for the company.  The correct contact is john.public@yourcompany.com.  But nobody made you aware of this change, nor is anyone aware that this contact is in the documentation.  And who is to say that John Public won’t leave the company or change roles in the next couple of weeks?  Additionally, listing a specific person runs the risk of that person getting spammed by peope who decide to use the contact for reasons other than the one listed in the document.  These risks come up any time a document references a specific person.  A better approach is to reference something more generic — say, a generic mailbox (e.g. HelpDesk@yourcompany.com) or a departmental site.

Here’s another argument for using generic references: how often does the document need to be updated?  Let’s say, for example, you write a document that references “Acme Corporation.”  Over the course of time, “Acme Corporation” changes — perhaps the company is bought or merged, the name changes, and so on.  How often do you need to go through your document looking for “Acme Corporation” and all its variations (shortened to “Acme,” abbreviated as “AC,” misspellings, etc.)?  And suppose your document is hundreds of pages long, with company references interspersed all throughout the document?  Making those edits does not make for a good working day.

Documentation runs the risk of exposing large amounts of data.  For data security, privacy, or even simple editing reasons (and maybe a bunch of others that I haven’t thought about yet), unless there’s a specific reason for not doing so, illustrations, examples, and references should often be made generic.  It’s a simple but critical step that can make your job better as a technical writer, and save your organization from a number of headaches — possibly ranging from complaints from audience members to a lawsuit.

Every once in a while, say “what the heck”

“Sometimes, you gotta say ‘what the f@%k!'”
— Miles Dalby, Risky Business

“All we are is dust in the wind…”
— Kansas

“While you see a chance, take it…”
— Steve Winwood

Last night, I checked an item off my bucket list.  I met and got my picture taken with my favorite band!  The pic is above.  That’s me in the middle, along with the guys from Kansas: from left to right, Phil Ehart, David Ragsdale, Richard Williams, yours truly, Ronnie Platt, David Manion, Zak Rizvi, and Billy Greer.

I became a fan of Kansas sometime around college.  I saw my first Kansas concert a couple of years after college, in Pittsfield, MA (unfortunately, by then, group stalwarts such as Kerry Livgren and Robby Steinhardt had already left the group).  Last night’s concert was in my hometown of Kingston, NY (well, my actual hometown is Woodstock — yes, that Woodstock, NY — but most of my hanging out when I was in high school was done in Kingston), so that made it an extra-special experience for me.  I don’t know how many Kansas concerts I’ve attended in-between, but some notable ones included Syracuse at the State Fair last year; the “Big E” (New England fair) in Springfield, MA; Pittsburgh, PA for the beginning of their Leftoverture 40th anniversary tour (and the night before I spoke at Pittsburgh SQL Saturday — which was why I was in Pittsburgh in the first place); an Alive At Five concert in downtown Albany; and Latham, NY at the now-defunct Starlight Theater.

That was a great experience, although if I really wanted to complete my experience, I would’ve liked, as a musician, to have played just one song with the band!  Alas, I realized that just wasn’t in the cards, if it ever happens (I’m not holding my breath).

I splurged and paid the money for the meet ‘n greet (or as we Kansas fans — a.k.a. “Wheatheads” — refer to them, “Wheat ‘n Greet“) event, along with a seat right in the front row.  So why pay a few hundred bucks (or whatever it was) for a twenty-minute meeting with a band and a front row concert seat?

Let me ask you a question.  How many times in your life have you ever said, “I wish I’d (fill in the blank)” and didn’t follow through?  How many times have you had the opportunity and the resources to fill in that blank, only to not follow through and let that opportunity (which might have been the only such opportunity in your lifetime) slip through your fingers?

In my life, I’ve had a number of significant experiences, more than a lot of people can say they’ve ever done.  As a musician, I’ve had a chance to perform in large events such as the Macy’s Thanksgiving Parade, a major college bowl game, an NCAA tournament, and major league baseball and football games.  I’ve met sport celebrities such as Reggie Jackson and Jim Boeheim.  I’m friends with some television and media personalities (granted, they’re not prominent big names, but still…).  I’ve taken trips that I never thought I’d take.  Through my involvement with SQL Saturday, I’ve had the opportunity to meet and make friends with some big names in the database industry, and I’ve become a fairly respected speaker myself.  Last night, I took advantage of an opportunity that came my way, and I took full advantage of it.  I have absolutely no regrets about spending those few hundred dollars.  As far as I’m concerned, that was money well spent.

A fulfilling life is about taking advantage of opportunities when they come your way.  Don’t be one of those people who doesn’t take a chance and end up regretting it later.  Grab the opportunity when it comes your way.  You’ll be smiling afterward — and you just might end up with a great story to tell.

It was the best of times, it was the worst of times

Steve Jones recently asked: what were your best days at work, and what was your worst?  He also issued a challenge to write about our typical days at work.  In terms of writing about a typical workday, I have the first of four (per Steve’s challenge instructions) draft articles warming up in the bullpen; hopefully, I’ll crank that one out sometime within the next week or so.  But in the meantime, for this article, I want to take a moment to address the best and worst days.

In terms of the worst day, I don’t think there is any contest.  I think it’s pretty safe to say that 9/11 was my worst day at work.  (For the benefit of those of you who don’t feel like clicking my article link, I worked for a company that had an office in the World Trade Center — when 9/11 happened.)

In terms of the best days, however, that requires a little more thought.  It’s not that I haven’t had any great days — that isn’t true — it’s just that there are a number of them, and having been a working professional for (cough! cough!!!) years, trying to pick out a few that stand out over the years is difficult for me to do.  So what I’ll do is pick out a few project victories that I’ve had over the course of my career.  Granted, I’m picking these from the top of my head, and there very well might be others that were more significant that I’m not remembering right now, but for purposes of this exercise, I’ll write about some projects with which I was involved and take a measure of pride.

I’ll start with a project related to the worst day that I mentioned above.  One of my tasks was to maintain an inventory of the servers in our data centers.  For a long time, this was a tediously manual task.  I went through our data centers with a clipboard, checking to see what servers were in each rack, noting any changes and adding new servers and racks that I found.  I drew a map of each room in Visio, even going as far as to count the floor tiles so that I could draw them to scale.  I populated the maps with boxes representing server racks and came up with a naming scheme directly tied into a row-and-column location scheme, making it possible to identify and label each rack so they’d be easy to find.  Included with the maps was a listing of servers within each rack.  I maintained the Visio file on my PC, making sure it was backed up to a departmental file server, and keeping hardcopies in each server room as a reference for various IT workers.

Because this was a manual process, the maps were never completely accurate — I have no doubt that new servers were continually added in-between map updates — and it was a tedious process.  All the while, I kept thinking, “there has to be a better way to do this.”  Sure enough, I found one!

I discovered that all our servers included a product called Insight Manager.  Among other things, it included the ability to collect server BIOS information and store it in a format suitable for importing into a database such as SQL Server.  Using the Insight Manager data structure as a template, I set up a SQL Server database on one of our departmental servers and created a system that enabled it to import data from any server on demand through Insight Manager.  I now had a central database with server data that could be updated at any given time!

Of course, data isn’t information unless it can be interpreted and understood, so the next step was to create an interface for it.  I was responsible for maintaining a departmental intranet site; although it was an internal intranet, I treated it as though it was a full-blown web site.  I created a web site to display the server data stored in my back-end.  I took my Visio server room maps and created image files from them.  From the image files, I created image maps that enabled a user to click a server rack on the map, drilling down to a list of servers in that rack.  Clicking on a server displayed data for that server — serial numbers, IP addresses, applications, and so on.

My server inventory system, which I previously had to update manually, was now automated!

This project was a major milestone for my career.  It was my first significant foray into SQL Server.  (At that time, I hadn’t yet learned about data normalization; had I known about it, I could’ve made the back-end even better.)  It gave me some experience with image maps, HTML, and classic ASP (the technology used on that intranet server at that time).  Most of all, it was my first taste of what it was like to be a web applications developer.

Memories of this project also reminded me of another good day I had on the job.  One particular day, I traveled to remote offices in Yorktown Heights and Middletown to survey their data centers for the server inventory system that I just described.  I hopped into my truck (I owned a small Toyota pickup truck at the time) and drove to Yorktown.  It was a gorgeous picture-perfect day; the sun was out and it was comfortably warm with low humidity.  It was comfortable enough that I left the air conditioner turned off and drove the entire trip with my windows rolled all the way down.  It was the kind of day where I wished I owned a convertible!  My route between the Yorktown and Middletown offices took me through the Bear Mountain area, including traversing the Hudson River over the Bear Mountain Bridge.  If you’ve never driven through that area of New York State, it is an absolutely picturesque and beautiful drive.  The entire trip was so fun and relaxing that it did not feel like a business trip at all; I actually felt as though I was on a vacation!

Finally, I want to talk about one last project in which I had a hand.  In one of my first jobs out of college (my second job out of school, actually), I was responsible for supporting my company’s document imaging system at a client site (a client that eventually ended up hiring me directly).  One of the system’s components was a WORM optical platter jukebox that was in constant use and occasionally needed operations maintenance, which ranged from simple tasks such as inserting an optical platter to complex ones such as restarting it when it locked up.  The device had to be operational 24/7, even at hours when we were not in the office.

I was tasked with putting together a small set of instructions — nothing big, just a few pages — that explained how to perform these tasks, including the correct way to insert a platter, what to do when (unfortunately, not if) the machine stopped working, and so on.  It needed to be written in such a way that the night maintenance staff could maintain the device.  So I sat down in front of my PC with a blank MS Word file and said to myself, “if I was a member of the night staff, what would I want to read that would enable me to perform these tasks?”

I had intended for the document to be a simple three to four page quick reference.  As I wrote and came up with more ideas that would help the readers who would be using it (including the innovative — for me — use of illustrations), the document kept getting bigger and bigger.  I don’t remember how big it eventually became, but I think it was somewhere in the ballpark of thirty pages.  I had absolutely zero technical writing experience at the time; I wrote the document completely by instinct.  I didn’t really know what I was doing; I just did things (illustrations, headers, subject organizations, etc.) that made sense to me.

The final product was a huge success — so much so, in fact, that management developed a training program based around this document.

A couple of years later, I discovered that nearby Rensselaer Polytechnic Institute had a Masters degree program in technical communication (note: I am not entirely sure if the program still exists).  I had been interested in pursuing a graduate degree, and I thought the program sounded interesting, so I decided to apply.  During my application interview with the faculty, I brought along a copy of that operational jukebox document I’d written.  I explained that I’d written the document completely by instinct and with no knowledge or experience in technical writing whatsoever.  The faculty seemed to be impressed with my effort on that project.

I was accepted into the program.  I now have an MS from RPI hanging on my home office wall and listed on my resume.

This article ended up being a lot longer than I expected.  Looking back on this exercise that Steve assigned, I suppose my good days at work were more significant than I thought.  These projects were major events that ended up shaping this professional career.  I suppose the moral of the story is not to underestimate job achievements.  You never know where they might lead!

Is Your DR Plan Complete?

Here’s another article reblog, this time from my friend, Andy Levy. Disaster recovery is a big deal, and you need to make sure that you’re prepared.

Don’t think a disaster can’t happen to you? Well, it happened to me.

The Rest is Just Code

Kevin Hill (b|t) posted a thought-provoking item on his last week about Disaster Recovery Plans. While I am in the 10% who perform DR tests for basic functionality on a regular basis, there’s a lot more to being prepared for disaster than just making sure you can get the databases back online.

You really need to have a full-company business continuity plan (BCP), which your DR plan is an integral portion of. Here come the Boy Scouts chanting “Be Prepared!”

When disaster strikes:

• How will you communicate it to your customers, including regular status updates?
• How will you communicate within the company?
• Do you have your systems prioritized so that you know what order things have to be brought online? Which systems can lag by a day or two while you get the most critical things online?
• Do you have contingency plans for all of…

View original post 543 more words

Maintain Your Trustworthiness

This is a reblog of an article written by my friend, Steve Jones. I would hope that this is something that goes without saying among data professionals like myself, but I think that it’s important enough that it’s worth repeating (and reblogging).

Voice of the DBA

Many of us that are DBAs and/or sysadmins find ourselves with privileged access to many systems. We can often read the data that’s stored in these systems, whether that’s a relational database, a NoSQL store, or even a mail system. As a result, it is incumbent upon us to be trustworthy and maintain confidentiality with privileged information.

Overall I think most of us do this, but there are always some rogue administrators out there, some of which might take malicious actions. There have been a few people that were arrested or sued for hacking into systems, trashing backups, or causing other issues. Often those are emotional outbursts that disrupt operations, and many people are aware there is an issue. However, what if people weren’t aware they were being hacked in some way?

I ran across this story about some “admin” software being sold on a hacker forum site, which was…

View original post 309 more words

Don’t fear the CrossFit

(Photo source: https://www.endlesscrossfit.com)

“I gotta run a little faster; I gotta reach for the sky; I gotta come a little closer; even if I lose, I gotta try…”
— Kansas, “Inside Of Me”

“Try not.  Do.  Or do not.  There is no try.”
— Yoda

Every Saturday, my CrossFit gym invites friends to join members for workouts (“Bring A Friend Day,” as it’s called).  It’s a little bit of a misnomer, as guests don’t necessarily have to be friends — as one coach likes to describe it, “bring your friends, neighbors, coworkers, colleagues, enemies, ‘frenemies,’ whomever.”  It doesn’t necessarily have to be by invitation; anyone interested in trying CrossFit can come to these classes — a type of “try before you buy” session, if you will.

I’ve tried to get friends to go to these sessions, with mixed success.  Those who do enjoy the sessions, but I have yet to have one friend (other than my wife) try it out and join the gym.  (Admittedly, there are fringe benefits for me to get someone to sign up — a month of free membership, for example.)

What’s interesting is those who don’t try it and outright refuse my offer to join me.  (As I tell people, joining me in these sessions pretty much guarantees that I will work out on Saturday!)  I tried to tell one friend that I thought CrossFit might benefit her.  Not only did she outright refuse to take me up on it, I got the impression that she was actually scared to try it.  She would not even keep an open mind about it; she just said, “I will NOT do it.  Don’t ever ask me about it again.”  End of conversation.

My question: why???

I would never twist anyone’s arm into trying it (well, okay, maybe friends with whom I know I can get away with it), but what I don’t completely understand is why people fear it.  I get why people won’t do things like go bungee-jumping (disclosure: I am deathly acrophobic), eating exotic foods (I’ll try almost anything, although I draw the line at anything that has more than four legs, shellfish excluded — Andrew Zimmern I’m not!), or do something on a dare.  But why are people afraid to try CrossFit?

I think part of it is that it’s human nature to fear what you don’t know.  People will see these images of CrossFit (I often post what I do on Facebook) and immediately get the impression that they’re expected to be able to lift large amounts of weights, be pushed to do double-unders, or be able to do pull-ups right off the bat.  The fear of “gymtimidation” comes into play.  People who fear it are likely afraid of being embarrassed or injured.

First, one of the selling points of CrossFit is that anyone can do it.  I’ve seen people as old as eighty (and even more!) in the gym.  I once saw a guy who had the use of only one arm in a workout (it was interesting watching him on a rower and an Assault bike).  I’ve seen newbies who struggle with weightlifting form.  Even I have my own struggles; I can’t (yet) do any moves that involve pulling myself up (pull-ups, muscle-ups, rope climbs, etc.), I have trouble with movements that involve squatting (I was diagnosed with osteoarthritis in my knees), and I’m not exactly the fastest runner (for me, there’s almost no difference between a jog, a sprint, or a fast walk).  Heck, even some warmups can sometime leave me out of breath.

However, one of CrossFit’s selling points is that it is scalable.  You are never asked to do anything you are not capable of doing.  If you have trouble with pull-ups (like I do), you can do barbell pull-ups or ring rows.  Unable to do a certain type of weightlifting movement?  Don’t worry about the weight; instead, use a lighter weight, an empty bar, or even a PVC pipe, and practice your technique.  Whatever movement gives you trouble, there is always a way to scale it that will allow you to perform it to your capabilities.

I’m sure the fear of being injured comes into play.  As I just said, you’ll never be pushed to do what you’re not capable of doing.  But one of the selling points for me is that CrossFit emphasizes technique.  If you are not sure about how to do a movement, coaches will teach you how.  If your form has issues, coaches will tweak it so it is better.  Technique is key to anything: the better your form, the less chance you’ll be injured.

I also think the intensity is a factor.  CrossFit can get very intense.  Admittedly, there isn’t a lot that’s enjoyable about working your tail off to the point where you’re gasping for breath and end up lying on the floor.  That’s something that can scare people off.  However, how hard you work out is up to you.  Intensity is what you make of it.  But why is it so intense?

I think it’s because the majority of people who take CrossFit seriously want to improve.  People push themselves because they want to get better at what they do.  Did a deadlift weight of 305 pounds?  Next time, I’m going to try 315.  Run 5,000 meters in under ten minutes?  Next time, shoot for nine.  CrossFit is about making yourself better.  While you are not asked to do anything you can’t do, you are asked to challenge yourself and push the limits of what you can do.  Even my own gym’s motto is “(Be)tter” (as in, “be better”).  I wrote before that you have to get uncomfortable in order to improve.  Making yourself better involves going out of your comfort zone.  How much discomfort — intensity — you decide to put into it is up to you.

Finally, there’s the phenomenon that Planet Fitness refers to as “gymtimidation.”  People are embarrassed by their lesser skill level and are often intimidated by performing in front of other people who are in much better shape.  This attitude does not exist in CrossFit.  Everyone — even the elite athletes — roots for everyone else to succeed.  I remember one time watching the CrossFit Games on TV and hearing the commentator say, “CrossFit is probably the only sport in which the person who comes in last gets the loudest cheers.”  Even in events where athletes are finished, they will often go back out into the field to cheer on and encourage those who are still working through the event.  Here’s a secret: everyone, at some point in their lives, was a beginner at something.  Someone once said that one of the worst phrases ever coined was “do it right the first time.”  It’s almost never done right the first time.  Fear of embarrassment should never be a factor in trying something new.

I wrote before that CrossFit is a supportive community.  I have made a large number of friends in CrossFit, and even though I look more like a couch potato than an elite athlete, I feel as comfortable with this group as I do as any group in which I’m involved.

Although people have their reasons why they don’t want to try CrossFit, fear should not be one of them.  CrossFit can be a fun and exciting way to keep fit.  Give it a try.  Who knows?  You might just get hooked — like I did!

And if any of my local friends are interested in hitting a Saturday “Bring A Friend” WOD, hit me up!

The importance of maintaining a LinkedIn account

My own presentation and a lightning talk by Paresh Motiwala from our SQL Saturday this past July got me thinking about my own LinkedIn account.  I’ve been going through the activities feed fairly regularly, making sure my ‘blog articles are posted, getting an idea of how many people see (much less, actually read) my articles, and to get occasional updates as to what my contacts are doing.  But it also occurred to me that it’s been a while since I did a full-fledged inventory of my own LinkedIn account.  I’ve written before about the importance of maintaining documentation, and my own LinkedIn profile is no exception.

Why inventory my LinkedIn account?  To answer this, I suppose I should explain why I have a LinkedIn account at all.

I’ll admit that I’m usually a lot more active on LinkedIn if I’m looking for a job.  I don’t know the statistics as to how people use LinkedIn, but it wouldn’t surprise me if job hunting is the number one reason.  Nevertheless, I try to check my LinkedIn fairly regularly, regardless of whether or not I’m looking for new employment.

I should note that, as of this article, I am not actively looking for employment.  That said, I still think it’s important to maintain my LinkedIn account.

Probably my biggest reason for maintaining a LinkedIn account is networking.  I’ve written before about the importance of networking in your professional lifetime.  I have an entire presentation about networking.  LinkedIn provides a tool for maintaining my networking contacts and staying in touch with them.  I’ve often said that one of my main reasons for maintaining my Facebook account is to keep in touch with family and friends, and to keep them up to date with whatever is happening in my life.  LinkedIn mostly serves the same purpose, with the primary difference being that the context is professional, not personal.

If you’re job hunting, a LinkedIn account is invaluable (I would even go as far as to say it’s necessary).  I came across an article (on LinkedIn, of course!) that stated about 85% of jobs were filled through networking.  I can personally attest to this; the person who hired me for my current job is connected to me through both Facebook and LinkedIn.

If you’re not convinced that LinkedIn is necessary for effective job hunting, imagine this scenario.  You’re a hiring manager who’s looking to fill one position, and is looking over two nearly identical resumes.  Both people are qualified for the position.  You decide that you want to know more about them.  You see that one has a LinkedIn profile.  The other does not.  Guess which one will have the advantage.

I’ve seen job applications that ask for your LinkedIn profile URL.  That tells me that employers take LinkedIn pretty seriously.

I said earlier that I am currently not actively seeking new employment.  However, I didn’t mention anything about passively looking.  Although I am content in my current position, I would be remiss if I didn’t keep my eyes and ears open for my next big thing, whether it’s a step up in my position or my salary.

I attended a SQL Saturday presentation by my friend, James Serra, about how to build your career.  One of the takeaways from his presentation was not to get comfortable if you want to get ahead — a point that prompted me to write about it in another ‘blog article.  Granted, I enjoy what I do, and I’m sure I could remain in my position for some time, but I’d be crazy to pass up an opportunity that represents a major step up and is right up my alley.

So, I started going through my own LinkedIn profile.  First, I went through my contacts to make sure it was up-to-date.  I started by going through the last SQL Saturday schedule, looking through the speaker profiles to see who else had LinkedIn accounts (those who have one are noted by a LinkedIn icon under their names), and checking to make sure I was connected to them.  I should note that I did not do this with all the speakers, but mainly the ones I know reasonably well and with whom I feel comfortable connecting.

Going through the “People you may know” feature, I was surprised to find a number of people whom I know but was not already connected on LinkedIn.  I sent them invitations to connect with me.  As of this article, about ten of them have accepted my invitation within the past week.  More will be coming, I’m sure.

I also looked at my own summary and realized that it’s not really a “summary” — that is, it should be a list of highlights and fairly easy to read.  I have some ideas in my head as to how to rewrite it; I have not yet done so as of this article.  Nevertheless, my personal professional summary will definitely get some tweaking sometime in the days ahead.

Whenever I assemble a new presentation, I make sure that it is listed under my Publications section.  It indicates that I am active with my presentations.  Demonstrating that you are doing something to enhance your background (in this case, staying active with my SQL Saturday presentations) is always a good thing.

I also solicit recommendations from people.  Maintaining recommendations on your LinkedIn enhances your profile.  And I make it a point to reciprocate when someone leaves me a recommendation.  This is a key point of networking; networking is a two-way street.  If someone does you a favor, make sure you do the same.

Maintaining LinkedIn is critical for your professional career.  I only talked about a few reasons for maintaining your account; there are many more that I didn’t mention.  (Out of curiosity, I Google-searched “reasons to maintain linkedin account” and a number of links showed up.)  In this day and age where maintaining an online presence is nearly expected, LinkedIn might make the difference in advancing your career.