My #SQLSaturday presentation on networking is viewable online #SQLSatAlbany #SQLSat961

I recorded my SQL Saturday session from this past weekend. If anyone is interested in checking out my presentation titled: “Networking 101: Building Professional Relationships,” it is now viewable online!

If you have an hour to kill, click here to see my presentation!

Impressions of a virtual #SQLSaturday — the debrief #SQLSat961 #SQLSatAlbany

Yesterday, we (our local user group) hosted SQL Saturday for the seventh time. As many of you know, I love SQL Saturday. It’s one of my favorite events to attend, and I credit SQL Saturday for boosting my career in a number of ways. I’ve also made many friends through my involvement with SQL Saturday. I apply to speak at any SQL Saturday event that I am able to attend. My hometown event, hosted by a user group of which I’m a member, is all the more special to me. While I look forward to attending any SQL Saturday, I especially look forward to the ones we host here in Albany, and I very much look forward to next year’s event.

That said, the COVID-19 pandemic forced us to hold it virtually this year. While I’ve participated in a number of virtual events (including speaking for a virtual user group a few times), this was my first time speaking at a virtual SQL Saturday. I enjoyed the experience, but it also had a number of pros and cons.

Let’s start with the pros. There’s something to be said about attending a full day of presentations for an online conference from the comfort of your own home office (or your living room, or a bar, or even a beach with a good WiFi connection). Although it was a full day of presentations, I wasn’t necessarily chained to my office chair for the duration; I was free to get up and walk around as I pleased. We set up four different GoToMeeting channel URLs, each one representing a different “room.” Each speaker occupied his or her meeting room at their scheduled times and did their presentations, just as we would for a regular SQL Saturday. As an attendee, I could switch rooms at any time; mostly, it involved leaving a meeting I was in and switching to a different room URL. Like a regular SQL Saturday, there were many good presentations. I would have liked to have attended a lot more, but I promised that I would moderate at least one room, so I largely stuck around a couple of rooms in which I was an organizer or presenter.

Speaking of moderating rooms: I volunteered to moderate the lightning talks. If you’ve never attended a lightning talk, think of it as a “micro-presentation,” only ten minutes long. We had five speakers doing lightning talks for our session. I was assigned as meeting organizer, and I assigned each speaker as presenter when it was his turn to speak. The GoToMeeting controls took a little getting used to — there is a little bit of a learning curve — but once I got the hang of it, I felt comfortable moderating the room channel.

My own presentation also went very well! I’ll admit that I felt a little trepidation going into it. Those of you who attend my presentations know that I like to do interactive presentations. I try to get my audience involved as much as possible. It keeps them engaged, and I like to think that it makes for an interesting presentation. I wasn’t sure how that would work in an online setting, although GoToMeeting does include tools for people to ask questions in a virtual chat function. One aspect of my networking presentation is a part where I allow ten minutes for my audience to do some in-room networking. This is easy to do in a in-person presentation where we’re all physically occupying the same room, but more challenging in an online forum. I ended up asking for a couple of volunteers, unmuting them (allowing them to actually speak in the meeting room), and encouraged them to engage in a networking session while the rest of us listened in. It ended up working remarkably well! If I ever do this session again virtually, I’ll have to keep that in mind!

I also found it interesting that the virtual format meant physical geography was a non-issue. It’s not unusual for people to travel to SQL Saturday (the farthest in-person SQL Saturday events I’ve attended were Pittsburgh and Virginia Beach), but holding this event virtually meant that people could attend and present from almost anywhere. One of the volunteers for my presentation demo was from (I think it was) North Carolina. I’d be curious to know what the geographic attendance was for yesterday’s event.

I also have another thought that has nothing to do with virtual SQL Saturday. One of the presenters was Sarah Patrick, who is currently a college student (her father, David Patrick, is also himself a SQL Saturday presenter). Her presentation was a narrative about setting up a database to perform a specific task. This was the second time I’d seen her presentation; I saw her give the same presentation down in Virginia Beach last year. What I found interesting was Sarah herself — that such a young and bright person was involved in doing presentations for SQL Saturday. I would love to see more young people getting involved. Greg Moore had his entire family involved as volunteers for yesterday’s event. His oldest son is currently a college student majoring in computer science. He helped moderate one of the sessions, and I found myself wondering if he would be interested in being a SQL Saturday speaker. (Greg, if you’re reading this, hint, hint!)

As much as I enjoyed yesterday’s event, it had its cons as well. One of the things I love about SQL Saturday is seeing all the people whom I don’t see on a regular basis. #SQLFamily is a real thing. I missed being able to wander around the event and being able to randomly talk to a John Miner, a Deborah Melkin, or whomever I happen to come across. I dearly love my #SQLFamily friends, and not being able to randomly interact with them was no small thing.

Of course, I’ll also admit that I enjoy good food and drink. For the last few years, our post-event celebration has been held at a local bar. There’s something to be said about enjoying libations along with the camaraderie of your #SQLFamily friends. My wife and I settled for ordering out for Chinese food last night. And, of course, during the course of the event, I had to settle for getting or making my own coffee, snacks, and food.

Overall, I had fun yesterday, I learned a few things, and I would definitely attend another virtual SQL Saturday. That said, it is not the same as attending a SQL Saturday in-person; I vastly prefer physically attending an event. Virtual SQL Saturday was definitely a good experience, but it’s not the same as attending in-person. When the COVID-19 pandemic has passed, I very much look forward to attending SQL Saturday in-person again.

But for the time being, virtual SQL Saturday will have to do.

#SQLSaturday #961 Albany — TOMORROW! July 25 #SQLSat961 #SQLSatAlbany

IMPORTANT!  If you are attending SQL Saturday, you MUST register on the SQL Saturday website (NOT Meetup or Facebook) at https://www.sqlsaturday.com/961!

This is a reminder that tomorrow, July 25, CASSUG will host Albany SQL Saturday for the seventh time!  And for the first time, Albany SQL Saturday is going virtual!

We will have a full day of great presentations that cover a variety of topics that include, but aren’t limited to, business intelligence, data science, database development, data architecture, and professional development!

We will also have our usual wrap-up and raffles at the end of the day!

To register, go to https://www.sqlsaturday.com/961.  It is important that you register at this site; RSVPs to Meetup or Facebook do not register you for SQL Saturday!!!

SQL Saturday is always a good time!  We hope to see you (virtually) on Saturday, July 25!

Don’t overlook your references #JobHunt

This morning, I had a conversation with a friend — a former coworker from a previous job — whom I listed as one of my references. He told me that he had a good conversation with a gentleman with whom I recently interviewed (whether or not I get the job remains to be seen). This friend has been invaluable throughout my job search, and I told him that I would get him a bottle of Scotch to say thank you once I landed.

It got me thinking: when it comes to advice about the job hunt, one topic that is almost never discussed are your references. Nearly every prospective employer asks for them, yet they are almost never mentioned when talking about the job hunt. I’ve read plenty of books and articles, and attended a number of SQL Saturday presentations, that talk about resumes, interview questions, how to dress, and so on. But it occurred to me that not one of them — including my own presentation (and I might need to rectify that) — talks about your references.

So, what should you consider when asking for people to serve as references? Here are my thoughts.

  • Make sure people are willing to serve as references. You want to make sure that you find people who are willing to speak on your behalf. Don’t list people as your references unless they give you their permission to do so. People don’t want to be surprised when one of your potential employers contact them. It’s unprofessional, and it’s just plain impolite.

    Speaking of which, the people I asked to serve as my references did request that I let them know any time that I dropped their names as references. So far, I have honored that request; every time a prospective employer asked me for references, I let my references know so that they wouldn’t be surprised when or if a phone call or email from my prospective employer came.
  • Get your references’ contact information. This might seem obvious, but it isn’t as straightforward as you might think. People might not want to be contacted at their work email, home phone number, and so on. When asking for references, make sure you also ask for an email and phone number where they don’t mind being contacted by a prospective employer.
  • Make sure your references know you well, both personally and professionally. You don’t necessarily have to ask your best friend to serve as a reference, but these people do need to be able to talk about your personality and your work. They need to be answer questions about you when prospective employers contact them. They are an extension of your interview; they need to be able to answer questions on your behalf.
  • Co-workers probably are the best references. There is nothing wrong with asking friends to serve as references, but keep in mind that prospective employers are likely to ask about your work, so they need to know you professionally as well.

    For me, I had a good rapport with my former co-workers, so I had no problem with asking them for references after I was let go from my job. However, if you’re actively working and are looking to move on, you might need to be more discreet. Make sure the people you ask are ones you can trust.

    Speaking of people you can trust…
  • Your references need to be able to provide an honest assessment of you. Your references are like your resume. They give a prospective employer a perspective of your skills and capabilities. It’s often said that you should never lie on your resume. The same holds true of your references.

    My friend asked me to discuss possible answers so that we were “on the same page.” I politely refused his request. I told him that I trusted him, and that I shouldn’t influence what he might say to a potential employer. I wanted him to provide an honest and fair assessment in his own words. If I didn’t trust him to do that, then he probably wasn’t my best pick for a reference.

Your references are often an overlooked part of your job hunt. Make sure you choose them well. They might be the difference between whether or not you get the job.

#PASSSummit 2020 #SQLFamily

It’s that time of year, when aspiring PASS speakers find out whether or not they’re speaking at PASS Summit. I was fortunate to be selected to speak last year, and I had the time of my life! If you want to read more about it, check out my synopsis of it from last year!

I got the official email notification yesterday (and now that the list is up, I can say it publicly). Alas, I was not selected this year. Oh well. C’est la vie.

That said, I was (and still am) excited about being selected last year. To be selected to speak at PASS Summit just once is a great honor and a nice feather in my cap. To be selected again would be a bonus. And although I wasn’t selected this year, it won’t preclude me from applying again for next year… and the next… and the next.

Unfortunately, given my current employment — and subsequently, my financial — situation, it is highly unlikely that I will be able to attend this year’s Summit, even if COVID-19 has forced it to a virtual event. Although the fact that the event is virtual means prices are reduced, they are still too high for me to attend (unless, between now and then, I land a job and my new employer would be willing to pay my registration fee — note to any future employer who might be reading this: here is a letter that makes the case as to why it would be good to send me to PASS Summit! Note that this link downloads an MS Word document). “Virtual” does not mean “free;” there are a number of expenses that still need to be paid, even for an online event. My friend Monica Rathbun wrote a nice article about what it financially takes to put on a PASS Summit, even a virtual one.

I went through the speakers list, and I was happy to see that a number of my #SQLFamily friends were selected to speak! Congrats to all of you who were chosen!

And although I might not be able to attend this year, if you’re able to get to a PASS Summit, I highly suggest you do so! You’ll learn a lot, and it’s a great time!

Coming up July 25 (a week from Saturday): #SQLSaturday #961, Albany #SQLSatAlb #SQLSatAlbany #SQLSat961

On July 25, a week from Saturday, CASSUG will host SQL Saturday #961, Albany! This is a daylong conference covering a variety of data, technical, and professional topics! And this year, we are going virtual, so you don’t have to be in Albany to attend!

To register for the event, and for more information, go to our SQL Saturday website!

And oh yes, did I mention that I’m speaking? I will be doing my presentation on networking!

SQL Saturday is always a good time, and the Albany event, which is near and dear to my heart, is one of my favorite events of the year. I’ll see you, virtually, a week from Saturday!

#SQL101: Create tables from CSV flat files

With my previous article about getting into REST applications, I figured it would be a good idea for me to set up a data source so I could practice. Besides, I had reinstalled SQL Server 2019 on my machine, and I needed to import some data so that I could brush up on my SQL skills as well.

Being the baseball nut that I am, of course, I had to import baseball statistics, so I decided to reimport the most recent data from Sean Lahman’s baseball database. The last time I did this exercise, I downloaded a database format. I don’t remember what format I used (the links all say “Access” — which I don’t remember downloading), but the files I used had an .sql extension. This time, I used the comma-delimited version, which downloaded a zip file containing files with a .csv extension.

I wanted to import the files directly into my database and have them create the tables upon doing so, so I opened up my SSMS, created a new Baseball database, and looked into how to do this. After poking around a bit (and a little bit of Googling), I found that flat files could be imported by right-clicking the database of your choice (in the below example, “Baseball”), clicking Tasks, and selecting Import Flat File.

Selecting this opened an Import Flat File wizard. First, it prompted me to select the input file. (Note: if you are importing multiple files, as I did for this little exercise, the wizard is smart enough to remember your last folder when you click Browse.)

When it looks at the flat file, it gives you a preview of the data that you’re importing. Since, for this exercise, I’m importing comma-delimited flat files, it was able to put my data into nice, neat columns.

Clicking “Next” brought me to a screen where I could modify the columns. I like this option a lot, as it gives me an opportunity to set up my data schema the way I want. If you’re a SQL or database newbie, I strongly suggest that you learn about primary keys and data types and take the time to set them up at this point.

In this particular example, I set my yearID to char(4), stint to int (I will likely change this to tinyint), teamID to char(3), lgID to char(2), and pretty much everything after lgID to int. I also set my first five columns as a composite primary key and everything else to be nullable.

I must have set these columns up successfully, because when I ran it, it did so without complaining.

I wish I could say that I imported all of my flat files without a hitch, but I did run into a few that didn’t run successfully the first time. Here are some of the issues that I came across.

  • I had opened a file in Excel to check data types, forgotten to close it, and the import complained that it couldn’t work because the file was still open.
  • I miscalculated a few field sizes, and came across messages saying that my column sizes were too short (for example, setting nvarchar(10) for a column that included data with 15 characters).
  • There were a few cases where I simply had the wrong data type.
  • My Pitching table included a column for ERA, which I was surprised to see. Reason: ERA (Earned Run Average, for those of you who are baseball-challenged) is a calculated statistic, like batting average. However, batting average was not included in the Batting table. So, I set the column data type to float. However, when I tried to import it, it failed. When I looked at the data, I found entries under ERA that said “inf” (for “infinity”)*. In this case, I did some data cleansing. I got rid of these entries and saved the flat file. It then imported with no problem

(*Some of you might be wondering, how do you get an ERA of infinity? Answer: you give up runs without getting anyone out! Mathematically, you would get a divide-by-zero error for calculating ERA, but in baseball parlance, it means you give up runs and can’t get anyone out!)

So hopefully at this point, you now have an idea as to how to import flat files into a SQL Server database (and maybe even got a small taste of data types and primary keys). And hopefully, this little utility saves you a lot of grief when trying to import flat files.

#REST101: Pardon me, I’m RESTing

As my job hunt has progressed (or stalled, depending on what the case may be), I see a lot of programmer and developer jobs that look for REST API experience. While I do have object-oriented programming experience, a lot of it came about before REST became a widespread term. And since I’ve been out of the developer’s loop for a while, I figure that I should do more to get my hands dirty with REST APIs.

I was recently asked about a developer position in which I was asked about my REST API experience. The response I received (and I’m paraphrasing here) was something to the effect of, “your credentials are impressive, but I don’t see a lot of REST API experience.” Unfortunately for me, that was an accurate statement. The closest I came to a RESTful experience was a project in a previous job where I worked on a project with ASP.NET MVC, which, by its nature, was a RESTful technology, but otherwise, I don’t have a lot of experience with REST APIs.

So, consider this my first article in which I talk about REST APIs. These articles will be preceded by the #REST101 hashtag.

For this first article in this series, I’ll list a few REST tutorial links (that, admittedly, I’m posting for my own reference). I went out and did a Google search for REST API. Among other things, here are some interesting links that I found.

So if you’re a budding developer, and like me, you’re looking to learn more about REST APIs, come along with me. Let’s learn about this together.

Notes are not documentation

Since I speak frequently at SQL Saturday, much of my audience is usually made up of data professionals. So whenever I do my presentation about technical writing or talking to non-technical people, I always ask the following question: do you understand the difference between data and information?

For those of you who don’t understand what I’m saying, let me elaborate. The terms data and information are not, I repeat, not interchangeable. Data refers to the collection of statistics, facts, and figures that are gathered through observation, research, and log captures. Information, on the other hand, is an interpretation of that data. Its creation involves analyzing the data, interpreting it, drawing conclusions from it, and presenting it in a way that can be understood by others. To put it another way, data refers to the raw materials, while information is the “finished” product.

(We could also get into a discussion that talks about how bias is introduced when data is analyzed and interpreted by humans, all of whom have some measure of preconceived bias, no matter how small, about the data they’re researching, but it goes beyond the scope of this article, and I won’t get into that now. That is another topic for another day.)

Once I establish that distinction, that’s when I go into what I believe is an important point about written communication: there is a difference between notes and documentation.

I believe this distinction is critical, and is often overlooked by people trying to write documentation. (One of the biggest things that disparaged one of my previous employers was that they did not understand — or worse, did not care about — that difference.) How many times have you been frustrated whenever you’ve asked for documentation about something, and the person you asked pointed you to something like a loose collection of seemingly-meaningless and disorganized scribbled notes that are kept in a three-ring binder? (Okay, maybe they’re kept digitally these days, not in a binder, but humor me, here.)

Granted, notes are important. They are thoughts in someone’s head that are expressed in written form. They are often important concepts that are jotted down so they can be remembered later. Those notes can come in many forms. How many of the best ideas, for example, started out as notes scribbled on a cocktail napkin?

However, more often than not, notes are only meaningful to the person who wrote them. Notes are mnemonics. They are not conveying information to a wide audience. In all likelihood, most people who read notes will not understand what they mean. Only the person writing the notes (or, if they’re jotted down during a meeting, the people attending the meeting) will understand what the notes are.

Documentation, however, is an interpretation of those notes. Documentation is notes that are presented in a way so that they can be understood by a wider audience. This is what professional communicators, such as technical writers, do. They’re in the business of taking loose data, such as notes, and making it meaningful.

Let me say it again for emphasis: notes are not documentation. To go back to my data and information analogy, data is to information what notes are to documentation. Notes are the raw material, but documentation is what makes the notes meaningful.

Ghostwriting — the art of writing for someone else

One of the new projects I’ve taken on is ghostwriting ‘blog articles for one of my clients. While I have plenty of technical writing experience — where I take a topic or application that isn’t mine and try to write about it — ghostwriting is an entirely new experience for me. Not only is it something new for me to tackle, I’m finding the experience to be interesting, and even fun!

My client maintains a ‘blog as part of his website, and by his own admission, isn’t a prolific writer — which is where I (along with one or two others) come in. I’ve only done a couple of articles for my client so far, but I’m learning a few things as I go along.

  • Keep in mind that it isn’t your article. One thing I need to remember is that even though I’m the one doing the writing, I’m not the one doing the “writing.” Essentially, I’m taking someone else’s thoughts and putting them into an article. (Sounds a lot like technical writing, no?) While I’m putting these thoughts and ideas into words, they are not my thoughts. The intellectual property belongs to my client, not me. As such, I consider the article as being my client’s property.

    I recognize that this can be a potentially slippery slope; by that same token, it could be argued that technical writing could belong to the subject matter expert (SME), not the person writing the documentation. I won’t talk about that here; first, this goes beyond my expertise (maybe someone who knows more about intellectual property law than I do can address this better than I can), and second, this discussion goes beyond the scope of this article.

    As far as I’m concerned, the client has the final say about the article. It’s possible that my client might give me credit for writing it, but that’s up to him. I’m just taking his thoughts and putting them into words.

    Speaking of writing someone else’s thoughts…
  • Writing what someone else is thinking is hard to do! Most people understand how difficult it is to understand another person’s thoughts; after all, that’s what communication is all about. I’m sure most communication professionals are familiar with the Shannon-Weaver communication model. For the benefit of those who aren’t, here’s a quick synopsis: a sender sends a message to a receiver. However, noise breaks down the transmission (note: the noise may not be literally “noise”), so when the receiver receives the message, it is never 100% accurate (and it never will be; the noise is always there. It’s like a mathematical graph; the line approaches, but will never reach, 100%). The receiver sends feedback to the sender (during feedback, the sender and receiver roles are reversed — the feedback becomes the new message), who uses it to adjust the message, and the cycle begins again.

    That communication model becomes magnified when ghostwriting an article because what the receiver — in this case, the ghostwriter — is feeding back to the sender is much, much more precise. A ghostwriter is trying to write on behalf of the client, and the client wants to make sure that what is being written is (1) accurate, and (2) maintains a voice that the client likes. In all likelihood, the client and the ghostwriter will go through several iterations of edits and adjustments.

    This reminds me of another thought…
  • I fully expect that what I write will be changed. Never get too attached to anything that you’re ghostwriting. Any time that I ghostwrite a work, I fully expect it to be different by the time my client and I are finished with it. As adjustments are made between me and my client, what we end up producing may look completely different from what I originally wrote.
  • You’re writing for someone else — but still be yourself. Even though I’m writing someone else’s thoughts, I never think about whether or not my writing “sounds” like the person for whom I’m writing. Thinking about writing in another person’s voice stifles my work and is a huge distraction that destroys my productivity. I write whatever comes naturally to me, and only through the editing process do I start worrying about the article’s voice, when the client starts adjusting the article to his or her liking.

    This thought brings to mind a quote from one of my favorite movies.

“No thinking – that comes later. You must write your first draft with your heart. You rewrite with your head. The first key to writing is… to write, not to think!”

William Forrester (played by Sean Connery), Finding Forrester
  • I’m learning new things! I’ve written before that one of the best ways to learn something is to write about it. Any time that you write about a topic, you end up learning about that topic — sometimes to the point of becoming an SME! Ghostwriting is no different. As I’m writing for my client, I’m learning new things and gaining new perspectives that hadn’t previously occurred to me.
  • I’m gaining new writing experience. I think this might be one of the biggest benefits of ghostwriting. Not only am I gaining additional writing experience, I’m also learning how to do so from another person’s viewpoint. As I mention above, I’m learning new things. I’m also learning how to be a better communicator, as it sharpens my communication skills as I continually feed back with my client. And it also teaches me how to look at things from a different point of view, which is what ghostwriting forces me to do.

I’m discovering that ghostwriting is a rewarding experience. It’s a great way to gain writing experience, and it ultimately makes me a better writer, a better worker, and a better person.