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!

Advertisements

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

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.

SQL Saturday #797, Boston, Sept. 22

I received word this week that I’ve been selected to speak at SQL Saturday #797, Boston, MA (more accurately, Burlington, MA) on September 22!  This is the third time I’ve applied to speak at Boston, and the first time I’ve been selected.  I suppose the third time’s a charm!

I will be doing a brand-new presentation (that made its debut in Albany last weekend): “Networking 101: Building professional relationships” (formerly named “Networking: it isn’t just for breakfast anymore”).  This is an interactive session in which we will discuss networking — what it is, and why it’s important.  You’ll even have a chance to practice networking within the confines of our room!

Mark your calendars, and I hope to see you in Burlington, MA on September 22!

#BI101: Some SQL Saturday speakers to check out

This is part of a series of articles in which I’m trying to teach myself about BI.  Any related articles I write are preceded with “#BI101” in the title.

As a speaker on the SQL Saturday circuit, I’ve had the honor and privilege of having met, connected with, and even befriended a number of experts in SQL, data, and BI.  If you can get to get to a SQL Saturday, you can also have that opportunity.

In a couple of weeks (July 28), we will be hosting SQL Saturday here in Albany, NY.  I was going through the schedule, and noticed a number of speakers on the docket who will be talking about various BI topics.  I’ve attended a lot of their sessions, and I recommend these speakers highly!

(Note: for purposes of this article, I am limiting this list to BI topics, although these speakers may be giving other presentations as well.)

SQL Saturday is a great free learning resource, a great opportunity to network, and is always a good time!  If you’re looking to learn about BI or other data-related or professional topics, go check out a SQL Saturday event near you!

Humble beginnings

Once again, the Facebook “On This Day” memory feature shows it can be a curious thing.  And again, this is one I wanted to share.

The picture you see above showed up on my Facebook memories feed this morning.  Three years ago today, I gave a presentation at my local SQL Server user group meeting.  I had come up with a presentation idea that I thought would be of interest to my user group, as well as other technical professionals.  I jotted down some notes, put it into a presentation, and presented it at my local user group.

About a month later, I gave this very same presentation at our local SQL Saturday.  It was my first SQL Saturday presentation!

I was curious as to how other events would take to my presentation.  Later that year, I submitted it to, and was accepted at, another SQL Saturday.  It was my second time speaking at SQL Saturday, my first time speaking at an event in “foreign territory,” and my first SQL Saturday — speaking or attending — outside of New York State.

Since that humble beginning, I’ve spoken at 13 (soon to be 14) SQL Saturdays at seven different cities around the northeastern United States.  Thanks to this endeavor, I’ve traveled around the region, met a lot of great people, expanded my professional profile, started a ‘blog (that you’re reading right now!), enhanced my career, gained more confidence, improved my presentation skills, and become a better person.  This all came about because of these conferences and from this simple start three years ago.

I hope I’ll be doing many more!  Happy three year anniversary to me!

Ten Years at Redgate

Congratulations to my friend, Steve Jones, for ten years at Redgate!

Voice of the DBA

This year was my 10th anniversary of working for Redgate. The actual date was a bit ago, but they held off my celebration until I came over. These are nice at Redgate, better than at some companies where I’ve seen someone in management just give a mention during a company meeting and a token gift. At Redgate we get a really nice gift, which was a Garmin Forerunner 645 for me.

IMG_20180517_125604

At Redgate, the CEO comes around and does a 5-10 minute speech on the person, with some of his thoughts and memories, and also shares some stories that others in the company have sent in. There is usually a few embarrassing notes, and in my case, I got this picture, which is likely one that everyone thought would generate the most red from me. It didn’t, though I don’t think there are any really embarrassing pictures or video for…

View original post 725 more words