Networking: it isn’t just for breakfast anymore

At last weekend’s SQL Saturday, I sat in on my friend’s (Paresh Motiwala) presentation about job hunting and interviewing.  (This is yet another presentation that I highly recommend!)  Since I was also doing a presentation related to career and job search, I figured that I should sit in (even though this was the second time that I’ve been to this presentation).

As in most career-oriented presentations these days, the subject of networking came up.  Paresh asked the question: “what is networking?”  One lady answered (I don’t remember the exact wording, so I’m paraphrasing), “it’s where you get together with people that have the same interests.”

That’s where I interjected.  I told her that what she said was a myth.  I said the myth were the words “…that have the same interests.”

When I did my own presentation later that afternoon, I made it a point to bring that up.  “Networking,” I explained, “is any situation where you get together and develop some kind of relationship with people.”  Notice that I did not say anything about people who have “the same interests.”  At a SQL Saturday, most people who attend are data professionals.  Of course, that’s a networking event of data professionals.  However, I also mentioned my extracurricular activities (such as, for me, the large symphonic concert band with which I’m involved).  That’s also a networking event.  I asked, how many of you are parents who bring your kids to Little League, soccer matches, and so on?  I explained, that’s also a networking opportunity.

Now, some of you will likely argue, “well, we wouldn’t have met these people at these places if it wasn’t for some common interest,” and you would be right, so let me qualify this a little.  Obviously, people expect to meet data professionals when they attend SQL Saturday.  But if you want to meet data professionals, and you only go to events like SQL Saturday, you’re missing out.  I play with music groups on the side.  I do CrossFit.  I attend user groups.  I am very active with my college and fraternity alumni events.  Some of you are likely involved with other activities.  All of these are networking opportunities.  Data professionals (or any kind of professional) are people, too.  They have lives outside of their profession.  While you are more likely to meet data professionals at events such as SQL Saturday, a local SQL user group, or any similar event, there is nothing that says you can’t meet one of these people at a music rehearsal, a church group, a kids’ soccer practice, a CrossFit class, a book club, or an online gaming convention.  I’ve actually connected with peers outside of technical events (in fact, I obtained my current job through a Facebook contact).  So you never know whom you will meet.

We connect with people through countless different channels.  Attending events that match your interests is a great way to meet people and to network.  Bear in mind, however, that networking opportunities exist everywhere, not just at an event geared toward your interests.  Your next employee, your next job, or an answer to your question might just be a connection away — and you might not even know it.

Advertisement

The bane of unsolicited recruiters

If you are a technology professional, chances are you’ve received the emails.  They usually look something like this:

To: Ray_Kim@MyEmail.com*
From: SomeRecruiterIveNeverHeardOf@somecompany.com
Subject: [Some job that doesn’t interest me] located in [some place where I’m not willing to relocate]

Dear job seeker:

I trust you are having a pleasant day!

I came across your profile, and I believe you are a perfect fit for our exciting job opportunity!  We have a position for [some position about which I couldn’t care less] located in [some place where I’m not willing to move].

If you think you are an ideal candidate for this exciting position, please call me immediately at (800) 555-1212!

(* My actual email address is suppressed for reasons I think are obvious.)

To me, these emails are no different from the email spam I receive that says I need to respond to claim $1,000,000 from a bank in Nigeria.  I’ll make this clear: spam is a major pet peeve of mine, and is something I hate passionately.

I came across this link that perfectly sums up why I hate these recruitment tactics.  I recently performed a Google search on “recruiting spam” — and the number of links I saw was overwhelming.

Among other things, I found a link by my friend, James Serra, who wrote this article about low-rate recruiters.  I also recently saw one of his SQL Saturday presentations where he talks about enhancing your career.  (It is an excellent presentation; I recommend it highly.)

In his presentation, James talks about taking risks, and he told stories about how he pulled up stakes to seek lucrative opportunities elsewhere.  Personally, I am not willing to pull up my roots and relocate (having said that, you are not me), but I do understand what he means by taking risks, especially calculated ones.  You need to take risks to get ahead, and you need to step out of your comfort zone.  (This is outside the scope of this article, and is another topic for another time.)

However, it’s one thing for opportunity (where you’d take a risk) to present itself.  It is quite another when a “get rich scheme” crosses your inbox.

I once had a bad experience with a spam recruiter.  He set me up on an interview.  When I asked the company with which I was interviewing, he would only say it was “an insurance company.”  He did not reveal much in the way of information.  I only found out where I was interviewing only hours before I was supposed to interview.  It ended up being for a company where I was not interested in working.  After that experience, I told myself that not only was I never going to work with that recruiter again, I also would never again accept any unsolicited recruiter requests.

A good ethical recruiter will take the time to get to know you, gauge your career interests, get an idea of where you want to go, and respect what you want to do.  A spam recruiter could not care less about any of this.  All they want to do is make a buck, and they are willing to exploit you to do it.

I recently responded to a recruiter in which I apologized for my harsh response.  Like so many unsolicited recruiting emails, he pitched a position outside my geographic interests that did not interest me.  After I responded, he wrote me back to apologize, and he was sincere in his response.  I had made numerous attempts to unsubscribe from his list, to no avail (a fact that I mentioned in my email to him).  He mentioned that he had looked into it, confirmed that there was an issue, and made efforts to correct it.  His efforts actually swayed me.  I wrote back to apologize and to say that I was willing to work with him.  (Legitimate recruiters, take note; efforts like this go a long way.)

(Disclosure: I am not, I repeat, not, actively seeking new employment; I’m happy in my current position.  However, I would also be remiss if I did not consider opportunities that could potentially represent a step up.  See my paragraph above about taking calculated risks.)

Swimming in the candidate pool can be an interesting, exciting, and even rewarding experience.  Just be aware that, within that pool, you might be swimming with sharks.

Who owns the email?

A while back, one of my work colleagues asked a very interesting question.

“When we send out an email, who owns the copyright?  Is it the owners of the data (i.e. individual clients), or is it the owners of the email (i.e. our employer)?”

He continued to lay out the scenario: “Send it to Client 1. Employee at Client 1 leaks the contents of the email; (our company) has to then cede coypright (sic) to the report so that they can distribute it internall?” (sic)

His final comment: “Imagine if (other companies) did that: ‘You wrote this with Office 365, Microsoft Owns (sic) the copyright'”

That’s a good question.  It’s one to which I don’t have an answer.  To be honest, I don’t have the knowledge or background to be able to answer it.  (Maybe someone who understands legal procedure or copyright law can answer it better than I can; if so, please feel free to comment.)  But I do think it’s an important one, nevertheless.

Email is probably one of the least secure forms of electronic communication.  It is often said that email should be treated like postcards, where anyone and everyone who touches it can read it.  It’s something I always keep in mind whenever I send email.  I refuse to send critical data (passwords, PHI, financial data, etc.) over email.  If I do have a need to send critical data, I’ll look for a way to do it securely, whether it’s data encryption, secure channels, direct messaging (which may not entirely be secure), or even face-to-face communication.  Data security is a big deal (too big to cover in just a single article), and each news item about data breaches becomes a bigger focus (as of this article, the Facebook data scandal is one of the biggest and most recent; sadly, I do not believe that this will be the biggest, nor the last, such breach).

If someone told me that I had to answer this question (and mind you, this is my opinion; do NOT quote me or state this as fact), the original author (or any data content copyright holder) owns any copyrights.  If I sent a song lyric over email, whomever it was that wrote the lyric would own that copyright, but I would own anything that I wrote (that is, something that came from my head — intellectual property — and not from someone else).  The purpose of a copyright, after all, is to protect intellectual property.  However, given email’s open and unsecure nature, original thoughts posted to an email should probably be considered to be public domain.  (That said, if an email sender cites some data source, has he or she committed a copyright violation?  I won’t take the time to discuss that now, but that might be another topic for another time.)

Despite email’s security concerns, it is still a useful tool, and is pretty much ubiquitous throughout our daily lives.  So long as we keep in mind that it isn’t secure, and we can keep our communication habits in context, it is a technology that will likely not disappear anytime soon.

My SQL Saturday schedule, 2018 (so far!)

Well, I can now call it official!  I am speaking in New York City on May 19!  So, my 2018 SQL Saturday schedule is starting to shape up.

As of right now, I am confirmed to be speaking at the following SQL Saturday events.

I submitted presentations to these events, but am not yet confirmed (and there’s no guarantee that I will be speaking at any of these).

Of course, this schedule is subject to change, depending on whether or not I’m picked to speak, and as more events are added to the schedule, so stay tuned.  I might be coming to a SQL Saturday near you.  If so, come out and say hi to me!

SQL Saturday #716, New York City

I’ll often go out to the SQL Saturday website to check the status of presentations I’ve submitted, check to see if my profile needs updating, and to see if any new conferences are on the docket (I generally apply to conferences within reasonable driving distance from my home in Troy, NY).

This morning, I looked at my own profile for SQL Saturday #716 in NYC.  Among other things, it lists my presentation submissions for that conference.  I saw that one of my presentations was listed under “Regular Session,” not “Submitted Regular Session” — which is a telltale indication that my presentation was selected!

SQL Saturday in New York City is an important one for me.  It was the first SQL Saturday I ever attended, back in 2010.  Until we hosted our own conference here in Albany, it was the only SQL Saturday I’d attended.  I’ve tried (unsuccessfully) to get selected for the NYC conference for a couple of years.  As one of the higher-profile SQL Saturday conferences, it’s one that I’ve wanted to get into for some time.  And although I haven’t yet gotten the official confirmation, it appears that I will speak there this year!

I suppose it’s another example of perseverance paying off!

I’ll post again once it becomes official, but as of now, it looks pretty good.  Stay tuned!

SQL Saturday #714, Philadelphia

Last week, I received word that I’ve been selected to speak at SQL Saturday #714, Philadelphia (the actual location is Blue Bell, PA, which is outside of Philadelphia) on April 21!

At this time, I don’t yet know what I will be presenting.  When I do, I’ll post them to another ‘blog article.

Hope to see you there!

Coming soon: SQL Saturday #723, Rochester, NY

This afternoon, I received the following email:

There are only a few days remaining before your presentation at SQLSaturday #723 on Saturday, March 24, 2018 and we want to make a last push to bring in new attendees and remind those that have already signed up. Just a quick blog post, update on LinkedIn, or a tweet on Twitter is all we need.

Okay.  I will oblige!

Come out and check out SQL Saturday #723 in Rochester, NY on March 24 (as I write this, it’s a week from this Saturday)!

I will be doing the following two presentations:

  • I lost my job! Now what?!? A survival guide for the unemployed 

    You’ve just been told by HR that you are no longer a part of their organization. You’ve been kicked to the curb. You are now living in the no-man’s land called unemployment.

    Unemployment is a scary situation. You’re dealing with emotions and uncertainty. You don’t know if you’ll be out of work for days, weeks, or months.

    Fortunately, unemployment is survivable. In this session, I’ll share my own experiences (and perhaps we’ll talk about some of yours) with unemployment, and how I managed to get through the tough times. We’ll discuss emotional impact, the job hunt, and things you can do to get yourself through this tough time. Hopefully, you’ll land on your feet once again before long!

  • Disaster Documents: The role of documentation in disaster recovery
    I was an employee of a company that had an office in the World Trade Center on Sept. 11, 2001. Prior to that infamous date, I had written several departmental documents that ended up being critical to our recovery. In this presentation, I provide a narrative of what happened in the weeks following 9/11, and how documentation played a role in getting the organization back on its feet.

    While other disaster recovery presentations talk about strategies, plans, and techniques, this presentation focuses on the documentation itself. We will discuss the documents we had and how they were used in our recovery. We will also discuss what documents we didn’t have, and how they could have made the process better.

SQL Saturday is always a good time!  Come out and check it out.  And if you come to my presentations, feel free to say hi!

The mystique of March Madness


(Photo source: sports.cbslocal.com)

It’s March, which means college sports junkies are in nirvana.  As I write this article, the first of the First Four games of the NCAA tournament are on the TV in front of me.

For the benefit of those of you who either live under a rock, know nothing about sports, or refer to all things sports generically as “sportsball,” a brief primer: “March Madness” (a.k.a. “the big dance”) is a reference to the NCAA men’s basketball tournament, where 68 schools compete for the national championship in a single-elimination tournament format.  It generates a great deal of excitement for students, alumni, and sports fans.  It creates a conversation topic as millions of people fill out tournament brackets, trying to predict (mostly, in vain) the outcome of all tournament matchups.  To put it mildly, March Madness is a huge deal.

I played in a pep band for a power conference NCAA Division 1 school, so my sports loyalty and school spirit are, to put it mildly, very strong.  (Side note: GO ORANGE!!!)  Those of you who know people associated with college pep bands realize that our school spirit tends to run deep (this might be another article for another time).  I’ve had friends and colleagues comment that they almost never see me without wearing an article of Syracuse gear.

However, I was spoiled at Syracuse.  We are a major conference school.  When I was a student at SU, we expected to make the NCAA tournament every year.  Anything less than a tournament bid was a disappointment; for us, NIT stood for “Not In the Tournament.”  Our ultimate goal was, and still is, to win the tournament, finally reaching the NCAA basketball summit in 2003.

There are 351 schools (as of this article) that play NCAA Division 1 men’s basketball.  68 of them make the NCAA tournament.  That’s 19% of NCAA membership.  Of those 351 schools, there are 42 schools that have never played in the NCAA tournament.  (That number had dropped by one from 43, after Lipscomb won their conference tournament this year to make it for the first time.)

I currently live in a metropolitan area that hosts two Division 1 basketball schools (Siena and UAlbany), both mid-major conference schools.  Unlike the power conferences, the mid-majors usually don’t harbor realistic expectations of winning the national championship.  For them, just making the tournament is a big deal, never mind actually winning it all.

This is a frequent conversation topic with my friend, Jim, who is an alumnus of the University of Maine (and one of the 42 schools that, as of 2018, has never made the tournament).  He has told me that he dreams of watching the selection show and seeing Maine appear in the bracket.  I understand his sentiment; for him, it is a source of school spirit and regional pride.  Seeing your school’s name come up for a major sporting event in front of a national audience is a source of pride and excitement.

Only one school will win the national championship; the other 350 will be left saying “wait ’til next year.”  For the vast majority of those schools, the possibility of winning the championship is far-fetched.  But for the 68 schools that make the tournament, it’s the idea that you have the opportunity to play for a championship, regardless of your team’s odds of winning it.  It’s like playing the lottery; as long as you get a ticket, there’s a possibility, no matter how small, that you could win it.  This is the mystique of March Madness; the majority of schools in the tournament likely will not win it, but they at least have the opportunity to compete for the big prize.

The CrossFit family

The other day, a thought popped into my head for no reason (that happens occasionally — doesn’t it happen to you?): “I feel like hanging out with my CrossFit family.”  I don’t know why I started thinking about it, but I was thinking about the great times I’ve had hanging out with my CrossFit friends outside of the gym — bowling night, playing poker to raise money for charity, going out to dinner, and so on.  I’ve been a member of my CrossFit gym for over three years (and counting) now, and I’ve made a lot of great friends in the process.  Who would’ve thought that I, a longtime self-admitted couch potato, would happily be spending his free time hanging with a bunch of athletes at a gym?

Ever since I started doing CrossFit, I’ve heard a lot of people refer to “their CrossFit family.”  This term, much less, concept, is nothing new.  Among all my activities, I’ve heard references to “my music family,” “band family,” “SQL family,” and so on.  As it’s been often said, “family” is more than flesh and blood; it’s about people to whom you’ve gotten close and learned to trust.  We as social animals thrive on these relationships.

The fact that I’ve managed to stick to a fitness program for more than three years is a huge deal, and I believe that the support system — all these friends I’ve made — is a big part of that.  A support system of friends can make almost anything pleasurable.  I’ve met a lot of great people in CrossFit, and one of the big things is that these people make me want to go to the gym.  When you have great friends and a solid support system around you, anything is possible.

Technical writing: the Rodney Dangerfield of tech professions

“It exists!” he cried.

“No,” said O’Brien.

He stepped across the room. There was a memory hole in the opposite wall. O’Brien lifted the grating. Unseen, the frail slip of paper was whirling away on the current of warm air; it was vanishing in a flash of flame. O’Brien turned away from the wall.

“Ashes,” he said. “Not even identifiable ashes. Dust. It does not exist. It never existed.”

“But it did exist! It does exist! It exists in memory. I remember it. You remember it.”

“I do not remember it,” said O’Brien.

— Excerpt from 1984 by George Orwell

 

“If it isn’t documented, it didn’t happen.”  — Sohail Sangi

Chores.  Taking out the trash.  Doing the dishes.  Cleaning up the room.  You don’t like doing them.  Neither do I.  Yes, I’ll admit it: I’ll do just about anything to avoid doing them.

Chores exist in the workplace, too (filling out your timesheet, checking your email, and so on).

However, documentation is not a chore.  Why do I say it isn’t?

Because chores at least get done.

A show of hands: how many of you work in a place where everything is well-documented?  Obviously, I can’t see everyone’s hands, but I’d be willing to bet that not a lot of them go up.

I have seen way too many cases where documentation is ignored — often blatantly so.  In my tech writing presentation abstract, I go as far to say that “documentation is one of the most critical, yet most blatantly ignored and disrespected tasks when it comes to technology.”  I go as far as to compare documentation and technical writing as being the “Rodney Dangerfield of technology tasks.”  It gets absolutely no respect at all.

I once told someone that I had technical writing experience.  His response?  “I’m sorry.”

As someone who harps on documentation and communication, this baffles me.  It absolutely bothers me when important things are NOT documented.

Folks, I get it.  I understand that people don’t like to document.  It’s not a sexy task.  Some people believe that watching grass grow and paint dry is more exciting than writing documentation.  People don’t like doing it.

But the fact is, it’s important!!!  Here is a sampling of links I found that describe why documentation is critical.

Occasionally, when I have an idea for a new presentation topic, I’ll post it to the forums on SQLServerCentral for feedback.  When I posted my idea for my tech writing presentation, one of the most profound responses I received was from Jeff Moden, who wrote this response.

So why are documentation and technical writing tasks so universally hated and disrespected?  I don’t have any evidence or data to answer this question (maybe if I decide to pursue a Ph.D, I might focus on this as a point of research), but I can speculate on some possible reasons.

  • “It’s boring.  I just don’t want to do it.”  To my knowledge, nobody has ever said that documentation was fun (well, there might be a few people out there, but I digress).  But there are some ways to make it more fun (more on that below).
  • “I can just remember everything in my head.”  This probably qualifies as being one of the biggest lies of all time.  Can you tell me exactly (and I really mean exactly) what you had for breakfast yesterday, or the day before (or this morning, for that matter)?  Yeah, I didn’t think so.
  • “Nobody documents anymore.  It’s not a big deal.”  See my comment above.  This is another huge lie.  Especially in this day and age where misinformation spreads like wildfire, documentation is critically relevant.
  • “It’s not a priority.”  It absolutely must be a priority.  Documentation needs to be included in project planning.  Make sure that time is budgeted for documentation.  It is that important, people!
  • “I just don’t have the time.”  See my bullet point above.  Make the time, damn it!!!
  • “I’m not a very good writer.”  Not everybody is.  Keep reading for my thoughts on this.

So what are some possible solutions to these issues?  Again, I am speculating on a lot of this, but here are a few things that seem to have worked.

  • Always follow the KISS principle.  Keep it simple, stupid!  This may be one of the oldest rules in the book.  Nobody wants to write a lot of detail, and nobody wants to read it, either.  Sometimes, the less you write, the better.
  • Find a way to make tools easily accessible.  Some of my past jobs included keeping a “scratch notes notebook” (in pre-online days) or incorporating a departmental intranet, Wiki, or team collaboration product (such as Confluence, GitHub, or SharePoint).  Having the tools readily available makes it more likely that they will be used.
  • Establish guidelines.  It seems like people are more likely to document when rules are laid out for them.  It can be something as simple as creating a template for people.  I’ve noticed that when documentation guidelines are established — developing a template or a form for people to use, asking people to write comments when coding, and so on — people tend to stick to them.
  • Document your code.  I had professors in college who used to dock points from my project grades if they weren’t documented or commented, regardless of how good my code was.  If you’re a developer or a programmer, code comments are probably the easiest and most effective ways to document.  Code comments can explain, in just a few lines, what some pieces of code are doing and why some variables are being used.  This allows for easier code updates, troubleshooting, and debugging.
  • Don’t worry about grammar.  As a self-admitted grammar snob, this statement is probably anathema to people like me.  However, writing ability could be a potential roadblock to documentation.  Human beings tend to be self-aware about their mistakes, which prevents them from doing their best, and documentation is no exception.  If you are self-aware about how you write, go ahead and write without grammatical restrictions.  So long as ideas are conveyed and understood, it should not be a roadblock.  If your document needs to go to customers, have an editor (or someone who knows what they’re doing) review it and make it look pretty later.
  • Find a way to make it fun.  Even my own attention span is reduced and my eyes glaze over after spending a couple of hours working on documentation, especially text.  However, I’ve noticed that working on some types of documentation — especially anything that involves illustrations, visualization, and UX/UI — tends to keep my attention much more than writing instructions or text.  Humans are visual animals, and we are more receptive to visual cues.  Creating (and consuming) illustrations tends to be easier (and more fun) that consuming text
  • Be a subject matter expert (SME).  Maybe the answer is that you don’t have to write at all.  If you really don’t like to write, then make yourself available to someone who does, and let that person worry about the documentation heavy lifting.  Sharing your expertise contributes to documentation.

This is by no means a comprehensive list (as I stated earlier, I’m speculating on a lot of this).  If you have anything more to add, by all means, please do so in the comments.  Your ideas might just make their way into a future presentation or ‘blog article.

I absolutely believe that ignoring documentation is a recipe for disaster — maybe not immediately, but it will happen somewhere down the line.  These issues (and maybe some others I haven’t thought about) must be addressed.  Documentation can pull your butt out of the fire and save it.  The lack of it can guarantee that you go down in flames.