Microsoft: a great place to work

“That is nice work if you can get it, and you can get it, if you try…”

— George and Ira Gershwin

This is the last (for now, unless I come up with anything else — which is entirely possible) article that came out of my experience last weekend with SQL Saturday #814.

After last Saturday’s conference, George Walters and a few of his Microsoft coworkers held a session on what was billed as “Diversity, Inclusion and Careers at Microsoft” (or something to that effect).  Unfortunately, I missed about the first half of the session (I had to run up to the speaker’s room to get my stuff out of there before they locked it up), so I’m unable to comment on the “diversity and inclusion” part.  Speaking as an Asian-American, that’s unfortunate, since it sounded like something that could potentially appeal to me.

I want to emphasize again that I am not actively seeking new employment.  However, I’ll also admit that I do look passively.  If something drops in my lap, or if I come across something that looks interesting, I’d be remiss if I didn’t at least look into it.  Besides, George is a friend, and I wanted to at least see what it was about (not to mention make the rounds with my friends before I left the conference).  (And on top of that, they had free pizza!)

From my perspective, it seemed like a Microsoft recruitment pitch (and I say that in a good way).  They discussed opportunities at Microsoft, what was needed to apply, what they looked for, what the work environment was like, and so on.  There were good questions and good discussion among the crowd in attendance, and I even contributed some suggestions of my own.

For me, one of the big takeaways was the description of the work culture.  If you decide you’re not happy with your career direction at Microsoft, they’ll work with you to figure out a path that works for you.  It seems like there’s something for everyone there.  Since I’m at an age where I’m probably closer to retirement than from my college graduation, the idea of finding a good fit appeals to me.  (On the other hand, that thought would probably also appeal to a recent grad as well.)  And I’ll also say that a lot of what the Microsoft reps said didn’t sound too bad, either.

While I’m happy in my current position, it won’t last forever (and besides, things can happen suddenly and unexpectedly — I’ve had that happen before).  So it doesn’t hurt to keep your eyes and ears open.  And when it comes to potential employers, you can probably do worse than Microsoft.

Advertisements

“So what, exactly, are you doing in IT?”

“Aside from mediocre marks in his freshman literature courses — even MIT wanted people to be literate, but evidently Peter Zimmer didn’t care for poetry — the kid was straight A.” (bold type added for emphasis)

— Excerpt from The Sum of All Fears by Tom Clancy

As I mentioned before, a lot of things came out of SQL Saturday #814 — enough that I have enough ‘blog article material for at least a few days.  This is the first of those articles.

At the Friday night speaker’s dinner, Eugene Meidinger asked me what I thought was a very good and valid question.  I’m paraphrasing what he said, but he asked me something like this.

“I’ve been reading some of your ‘blog articles.”  (Ed. note: hey, someone reads my ‘blog!)  “Most of your articles don’t have anything to do with SQL.  Do you ever write anything about SQL?  How did you get involved with SQL Saturday?  Are you one of those people who just happened to latch on to SQL or hang out with SQL people?”

The answer is not simple.  This article is my attempt to answer his questions.

To answer his first question, yes, I have written about SQL, but it’s been a while.  For his (or anyone else’s) reference, here are some of the SQL articles that I wrote.

Yes, I do have experience in SQL Server.  However, I am not a SQL MVP, nor do I consider myself a SQL expert.  As I describe myself, “I fall under the category of knowing enough SQL to be dangerous.”  (Or, as I like to think of it, I know enough SQL to be able to do the job.)  Although I don’t know enough to be able to talk about advanced SQL techniques, I can discuss beginner-level SQL topics that can help people just getting started in SQL.  I’ve been meaning to write and present more beginner SQL-related topics, but (primarily) lack of time has kept me from getting them done.

(I’m also at a bit of a disadvantage because I currently work in an Oracle, not a SQL Server, environment.)

I won’t rehash how I got involved with SQL Saturday (I’ve already done that; I’ll leave it to you to check the link and read it for yourself).  I’ll just simply say that, although I don’t talk extensively about SQL topics, I’ve learned that there is still a place for me within an endeavor such as SQL Saturday.

When I first started my ‘blog, I intended for it to supplement my SQL Saturday presentations.  Since then, however, it seems to have taken on a life of its own.  It’s become a forum for me to express my thoughts in a way that they’d be helpful for both myself and for other people, especially anyone pursuing professional careers.

One thing that has come out of these efforts is that, professionally, I’m finding myself more and more.  I’ve had to come to terms with my own level of technological knowledge and expertise.  For years, I’ve been seeking positions in programming and application development.  But a funny thing happened along the way.  I discovered that while I do enjoy coding, I wasn’t passionate about it.  I wasn’t willing to spend late nights and downtime doing more with it or to immerse myself in it.  As soon as I came to that realization, that was when I realized that I should look into something else.

And as soon as I came to that realization, good things started happening for me.  I became happier and more confident in my career direction.  I started getting more and better opportunities.

It also made me realize that, despite all my jokes about being an odd man out because I was “not a SQL expert,” there is still a place for me in SQL Saturday.  No, I may not be presenting SQL or data topics, but I am still making important presentation contributions to the database and IT communities.

Back when I worked at Blue Cross in the late 90s and early 2000s, I fulfilled a role in which I supplied server staff with information they needed to do their jobs.  As I describe it, my job was to “support the support staff.”  It’s only within the last few years that I really appreciate just how important of a role that was.

Ironically, although Eugene asked me the original question, it was one of his own presentations that made me come to this realization.  The increasing difficulty of keeping pace with technological trends contributed to my waning passion about some technological topics.  I mentioned a while back in a podcast that I thought it was important to play to your strengths.  By focusing on something about which you’re really passionate — in my case, it’s technical communication — there’s no telling how far you can go.

So Eugene, if you happen to be reading this, hopefully this answers your questions and gives you a perspective of where I’m coming from.  (Good to see you this past weekend, by the way!)  And for anyone else reading this, hopefully this will inspire you to reflect upon your own interests and skill sets, and provide you with a sense of guidance as you pursue your career interests.

The SQL Yearbook

Earlier this year, Jen McCown announced that she was embarking on a project that she called “the SQL Yearbook.”  I decided, what the heck, and told her I’d take part.

A little while ago, I got an email from her saying that the project is finished!  (Per her instructions, I also want to make sure I attribute it properly, so here it is: “SQL Yearbook 2018” by Jennifer McCown of MinionWare is licensed under CC BY-NC-ND 4.0.)

If you click either PDF link, my profile shows up on page 19.  (Really, it’s the same one I use for my SQL Saturday speaker’s profile.)

I have a number of friends and associates who are featured throughout this yearbook, primarily through my association with my local SQL user group, my dealings with SSC, and my experiences with SQL Saturday.

Hope you enjoy it!

Comment your damn code!!!

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
— Martin Fowler

When I was a computer science major in college, I had professors who used to dock points if my code wasn’t documented.  It didn’t matter how well-written my code was, and it didn’t matter how well my code worked.  If I didn’t include comments to describe my code, what my variables were, why I used certain functions and coding techniques, a project that could’ve gotten an A grade instead got a B.

That memory came back to me this evening at our SQL user group meeting this evening.  Our guest speaker was Jen McCown, who gave a presentation called “T-SQL’s Hidden Support Feature.”  (A description of her sessions can be found here, and I found a SQL Saturday link to it here.)  Her presentation talked about a feature included with T-SQL (and just about every language imaginable).  It is guaranteed to improve how people handle, develop, and maintain code, and it costs nearly nothing to implement.

What is this miracle feature, you ask?

Code comments.

Simply commenting code can save developers lots of headaches and development time.  It can provide an explanation of how and why code snippets were used.  It can describe variables, what they’re for, and how they’re utilized.  It can describe program structures that help in debugging and maintenance.  I even remember a comment to a SSC forum post by Jeff Moden who mentioned the return on investment of commenting code.  It also reminded me of Steve Jones’ article about how important it is to comment code.  I believe Jen’s presentation should be required for anyone who writes code.  The benefits for commenting code are endless.

Commenting code is probably one of the simplest and most useful, yet most underutilized, methods of documentation.  I’ve mentioned time and again about how documentation gets no respect in technology, and yet too many developers still refuse to do it.  Jen’s presentation was a reminder of how important it is to document code; in fact, she also mentioned some points that didn’t occur to me.  For example, documents such as Word, Wikis, or Confluence can get lost, misplaced, or buried.  Code comments, however, stay with the code; it cannot get lost or separated from the code.  (There were several other points she mentioned as well, but it’s her presentation, not mine, so I don’t want to take away from it.)

When I was in school, I was docked points when I didn’t comment my code.  Sometimes, I think developers should be docked pay if they don’t do so.  Commenting code is the simplest, yet most effective tools around.  So you want to be a better developer?  Then comment your damn code!

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!

SQL Saturday #741 Albany — the debrief

Once again, we had another great SQL Saturday here in Albany this past weekend!  I don’t know how many people attended, but by my estimate, we had well over two-hundred people.  I had a great time (as usual), and it serves to remind me why this is one of my favorite events.

My own presentation went very well!  I had nine people attend my session.  Two people (not including myself) were in the room when I started, but more people started filing in after I began my presentation.  Everyone I spoke with told me it was a great presentation, and I got nothing but positive feedback!

I did, however, get one piece of feedback that I did not expect.  I spoke with a number of people who did not attend my presentation, and one who almost skipped it (but ended up coming, anyway).  They all told me the same thing: they read my presentation title and automatically assumed that my talk was about computer networking, not business networking.  Had they known that, they all told me, they would have been there.  So I missed out on a potentially larger audience, simply because of my presentation title.

My initial reaction was frustration.  Mt first thought was, “read the presentation abstract, people!”  I didn’t want to change it; I liked the title and thought it was clever (I’d taken it from one of my ‘blog articles with the same name).  At the same time, I also couldn’t ignore the feedback; it’s human nature to judge a book by its cover (or, in the case, the title), and first impressions are important.  So, reluctantly, I renamed my presentation.  At the same time, I also made a slight tweak to my presentation slides; I removed one slide that did not serve much purpose during my presentation.

I’d be remiss if I didn’t mention a great event without talking about other great presentations.  I attended James Serra‘s session on presenting.  I’m always looking to improve upon my own presentation skills, and I got a lot out of James’ presentation (as always).  Not only did I pick up a few new tips, he also reinforced some points that I use in my own presentations.  This is always good to hear; it legitimizes things that I discuss.  I also sat in on a less serious presentation by Thomas Grohser.  At the end of the day, a little humor is a good thing.  James and Thomas are both excellent speakers, and I always recommend them.  I’d also heard great things about a session I’d missed presented by my friend, Deborah Melkin, another wonderful speaker that I highly recommend.

Unfortunately, part of the reason why I missed Deborah’s session (and others) was an issue that needed my attention.  When I arrived at the event site that morning, one of my tires went flat.  I didn’t have the time to address it, and I didn’t feel much like dealing with it, especially on a warm and humid day.  Fortunately, I have a AAA membership.  Let me tell you about how handy that became that afternoon.

Of course, there were also the events around SQL Saturday.  Friday night was the speaker’s dinner.  It was held at a Mediterranean restaurant about ten minutes away from my office.  I’ve driven past this place many times, and had no idea that it was there.  It was a good place, and I’m going to keep it in mind!  The closing and accompanying raffles are always fun.  My wife’s name was actually drawn for a prize!  Unfortunately, she couldn’t claim it, simply because she was not there, and the rules stipulate that you need to be present to win!  (Some people said that I should claim it by proxy, but at the same time, rules are rules!)  The post-event party was held at a place across the street, a great opportunity to mix and mingle with fellow speakers and event volunteers in a loose and casual atmosphere!

All in all, it was a great event!  This is one of my favorite events, and I look forward to doing this again next year!

SQL Saturday #741, Albany, NY — Come to upstate New York!

On Saturday, July 28 (a week from tomorrow as I write this), our local Albany-area SQL user group will host our fifth SQL Saturday!  I have participated in all five; I worked as a volunteer at the first one, and I presented at the other four (including next Saturday).  This is one of my favorite events, and I look forward to it every single year!

This year, I am debuting a brand-new presentation: “Networking: it isn’t just for breakfast anymore,” based upon my ‘blog article of the same name.  (An alternate name for it could be “Networking 101: networking for beginners.”)  This presentation is primarily for people who want to get better at networking but don’t know how to do it, although seasoned veterans might be able to get something out of it as well.  It’s one of the first sessions of the day (8:30 am!), so come early!

As much as I promote my own presentations, mine is not the only one on the docket.  There are many wonderful speakers and presentations being given at this event, and I encourage you to come out and check out as many as you can that interest you!

SQL Saturday is always a great time, a great opportunity for free learning, and a great opportunity to network with data professionals.  The Capital District region here in upstate New York has been my home for many years.  I hope to see you here in my home turf!