Movin’ on Up

The time is right to move on to a better blog.    I picked up a sweet domain name and have copied all my previous posts here over to it.   The format is a little bland at the moment, but over time I’ll work on it.   I just wanted somewhere free and simple to post my random thoughts.

The new URL is http://www.coffeeandpizza.net.   If you’re reading this page, I hope you’ll try out the new one.

Sharing with the Community vs. Keeping a Job

Microsoft has done a whole lot to open source their tools to the IT professional community and this is awesome.   Some of the stuff that I’m using pretty regularly includes DSC modules that are available on GitHub for basically nothing.   I can actually modify the code and put in pull requests to get my changes put into the actual main product.

As a Windows guy, this is totally new to me.   When I find something that I don’t like, I can now change it to the way I want it and, if I think others would use it, I can put in a pull request (PR) to get it merged into the real deal.   On the other hand, if I do something that’s just for my own use, I can do it without worrying about breaking the real stuff.   It’s pretty neat and very useful.  I’ve been able to take some things. like the Windows Firewall DSC module, and modify it to give me more power over the rules when I use it.   I’ve even made my own DSC module for configuring Windows Update.

The question really now is, what can I share with the community and what do I need to keep to myself?  Obviously, if there is secret stuff, like passwords or private info, in the scripts, I need to keep that to myself.  But what if absolutely nothing in the code is specific to my employer?

I work for Trek.   I don’t do this kind of work on my own time, and even if I did, I still feel like it’s for Trek.   Every part of improving myself technically or improving my status in the community affects my employment, at least at a high level.   If I was to become the biggest contributor to the DSC modules “on my own time”, would that not benefit Trek?   What if I did something “on my own” and then put it in place at Trek?   Would that suddenly make the work “Trek’s time”?   If I was to build an awesome personal Git repository full of my own work, and never put in the PRs to merge them into the main code, would that be mine?  What if I was to leave Trek?   Would I be able to take all that work with me, thereby benefiting my next employer?

These questions keep me from posting really anything into my own GitHub account or doing PRs for what I do.   I just don’t see where risking my employment or some IP infringement problems is worth it.   I know there are some employers out there who totally encourage giving to the community.   That makes perfect sense, particularly if you’re a technology company running open source stuff all the time or a consulting company making money in open source development and support.

But I work for a bike company.   We have some high-tech stuff, but we aren’t a technology company.   If I’m to ever leave Trek, and my next employer wants me to do similar work to what I’ve already done, then that employer needs to pay for the time it would take me to regenerate it.  If that company is open to having me put everything I work on out in GitHub, I’ll jump on it to do it.   From what I can tell now, though, I can bring my skills and network along with me, but not my old work.

Career Tip: Learn PowerShell

I don’t remember if I’ve posted on this before or not, but it’s worth repeating anyway.   If you are a systems administrator or engineer who works in the Windows environment, you need to learn PowerShell now.   Even if you are primarily a Linux guy, if you work in Windows AT ALL, you need to learn PowerShell.

PowerShell v5 is going to be released basically any day now.   v5 has all kinds of nice features in it, particularly in regards to Package Management.   Windows Server 2016 has a “Nano Server” installation option, which basically is a headless server that can only be managed remotely via PowerShell or other tools.  Windows Server Core, which has been an installation option since Windows 2008, has PowerShell built-in, so you can do anything you want to on those machines from within the shell.

Microsoft is NOT moving away from this direction any time soon.   Jeffrey Snover, the inventor of PowerShell, has recently been promoted to be Distinguished Engineer, architecting everything on the Windows Server and System Center products.   As such, you can expect that PowerShell will become even more ingrained into everything, and all of these products are going to be even more manageable with it.   There are PowerShell modules for Exchange, Active Directory, SQL Server, SCCM, you name it, so a little foundational learning will carry you a long way.

Learn it now.   If you don’t, in 5 years, you’re going to be playing catchup.  In 10 years, you may just be looking for another career.   The GUI on Windows Server is slowly dying, and I don’t think Snover will have it any other way.   When you’re finished learning PowerShell, don’t forget that PowerShell Desired State Configuration (DSC) is available and right around the corner, too, and you’re going to have to skill up on it.   The days of doing server management via RDP or console sessions are over.

Here’s a couple readings and videos to get you started.   These are a little older now, but the concepts still apply.

  • PowerShell v3 Jump Start Class – Taught by Snover himself.   It’s a great start down this path.  I don’t see one for v5, but I’m sure there will be one eventually.
  • The Monad Manifesto – Years ago, Snover published this as a guide to show the direction he thought things should go.   Over time, PowerShell has become what he was calling “Monad” initially.   A Must-Read.
  • The PowerShell Team Blog – Great resource on what’s coming down the pipeline.   If you’re staying on top of this, you’re staying on top of Windows Server, too.

 

The Problems with IT Support

It goes without question that the biggest headache most knowledge workers deal with is the IT department.   Getting basic stuff done, like setting permissions so you can access a file you need or getting your computer fixed, seem to take forever.   I’ve worked in both large and small environments, and in almost every case, working with the IT staff has been a pain in the butt.

Why is this?   It’s because it all starts at the help desk.

The only number most companies give for getting IT support is the help desk phone number, so everyone knows it.   The folks on the IT end of the phone are either entry-level IT pros, old timers who haven’t skilled themselves out of the department, or, worst case, a call center person reading a script to simply fill in a form with your issue.

In only the most common cases (password resets and “reboot your computer”) does the first-level support person fix the issue without further research.  That is, Googling while you are either waiting on the phone or waiting for a callback.   If it’s beyond that, you can bet that the ticket is moving up to an administrator or engineer for further examination.

In the ITIL model, which basically all service desk groups follow, the only person allowed to talk to the end user is the service desk person.    That means that the engineer who works on your ticket isn’t usually allowed to contact you back.   You have to wait for the engineer to get back to the service desk person, who then contacts you.   It’s a back and forth routine that is inefficient and doesn’t work for anyone, other than keeping the engineer from having to actually speak to the end user.  Heaven forbid!

If all of that isn’t enough, you get larger companies having a “service catalog” and a “support form”, which are actually different things.   If you call the help desk to do something like, “I need to borrow a projector,” you get yelled at for not using the service catalog.   In other words, the ITIL process itself makes it such that the end user has a prescribed “right” way to contact IT.

What’s the solution?   Have all the engineers, administrators, and everyone else rotate through help desk duty one week a month.   This puts higher-end knowledge right there and keeps from passing the tickets around, plus forces everyone to remember that the end users really are the important thing.  And when the engineers go back to their “regular” work, they know what the hell has been going on and can look for long-term solutions for the problems.   I can tell you that engineers and admins aren’t digging through support ticket reports to find stuff to work on, as they have enough to do already.  If it directly affects them, though, they’ll definitely try to fix it.

How about when end users call, instead of routing them to the “right” form, filling it out for them and getting it done?  It is not the responsibility of the end user community to contact you the way you want to be contacted.  If you get contacted, respond and do your job.   I understand that there are some forms of communication that work better than others (I don’t like outages to be posted on Yammer at 3am on a Sunday morning, either), and you cannot be responsible 24/7/365 for responding to everything, but the help desk number is already well-known.   Use it.

During business hours, how about having all IT folks available for support?   This doesn’t mean that they are all going to fix the problems, but a warm body answering the phone is definitely better than a scripted call center employee.   At least the IT folks would have a chance of knowing how to route things appropriately, too.

Finally, and this is just a pet peeve of mine, when the user asks for help and doesn’t provide you all the troubleshooting information you think you need to come up with an answer, contact them to get it.   Don’t send them an email with 75 things that they need to provide…you need to call them and walk them through it, or even connect remotely and get the information yourself.   If they knew how to obtain all the troubleshooting information, chances are good that they could read it themselves and fix their own problem.   It is our job to get the information and get things moving.

Just my 2 cents.   Or 3.   Or however much.

 

DB Indexes and the Card Catalog

To start, I’m going to say “indexes” instead of “indices”, even though that drives me crazy.    I’ve read “indexes” in too many books now and I guess it’s right.

I’ve struggled for a while to really grasp how database indexes really worked.   I’ve been searching for some guidance, and everything I find basically tells me to think about a phone book.   That never has seemed to help me, so I decided to think about it like a card catalog.   My intuition was right, at least according to the DBA I asked to confirm my thinking.   Here’s my explanation, for what it’s worth.

If you are old enough, you can remember the card catalog at the library.   It was a big box, or group of boxes, in the room that had a few index cards (nice name) for each book on the shelves.  You could find cards based upon author, title, or subject, so if you wanted a book by Stephen King, you could look under the Ks, find the cards going with that, and then go to the locations and find the books.    You could do the same with title or subject.   The subject one always seemed iffy to me, because I didn’t know if the librarians actually read every book they added and came up with subjects themselves, or if the publisher told them the subjects, or whatever.   It was still better than starting at the front of the library and looking through everything myself.

download

This is, essentially, how a database index works.   Imagine a shelf of 1000 books, each book the same size, built such that each shelf was exactly the right size for 250 books.   Also, suppose that the books are ordered alphabetically by title.   You would have 4 shelves, then, and maybe an empty one on the bottom to add books later.

In this case, if you were looking for a book that started with a G, you could scan through to the Gs and find your book.   Not too hard.   What if you bought a new book that began with an E?   To insert that into the right shelf, it would probably go on the top shelf, and you’d have to move every book to the right and below it, and you’d then have one book, probably beginning with Z, on the once-empty bottom shelf.   What if you get rid of a book beginning with R?    You could just pull it and leave a hole, but then, if you got a new book that didn’t begin with R, you’d have to keep that hole as you shift everything to make room for it.  What a pain.

To make it worse, what if you need to find a book by a specific author?   You would have to start at the top left, and go through the entire bookcase to find the books.   Then you’d have to find the one out of that set that you want to read.   Alternatively, if you only want exactly one item and you don’t care which one, you can just take the first one by that author, but you could feasibly end up scanning the whole bookcase anyway, if the one you want is at the bottom.

You may have a neatly-ordered bookcase, but adding and removing books has proven to be difficult, plus searching by any means other than by title is hard.  This is where an index can help.

First, you have to choose what to index on.   Since my example is a search by author, let’s just use that.   If you created an alphabetical list of authors in your bookshelf, you could then just tell it which row and location the books are in.   For instance, if you have one book by a guy named “James”, you would have an entry for “James” => “Shelf 3, Item 8”, or something like that.

If you got rid of that book by James, you could remove it from the shelf and then, either immediately or at a later time when you can, you would just delete the entry from your index list.   If you move the book to a new location for some reason, you can just update the index accordingly.  Easy-peasy.

A better way, though, to organize your books, would just be to assign them a number when you buy them.   Maybe you have books 1-1000 in no particular alphabetical order, sitting on the shelf in numerical order by this number.   If you want to add a new one, you can just put it on the bottom OR fill in a hole if one has been removed from circulation.   Then, you could have two indexes: one by title and one by author.   In each case, you’d just have a list and the location on the shelf.

This is the basic idea with databases and indexes.   Each table you create should have a primary key, which is really a “clustered index”, and that determines the order the records are stored.   In our example, that numbering 1-1000 is the primary key, and the shelf is ordered accordingly.

“Non-clustered Indexes” are basically just like our two catalogs.  They are sorted by some other column, like title or author, and have a pointer to tell the system where the exact record is stored.   When you add or delete a new record to the table, you simply put it in there wherever, and then immediately update the indexes to show the new entry’s location.   That’s it.    It’s basically instantaneous, so the index is always up-to-date.

Does this cause some issues?   Sure.  Updating stuff in the table means you have to update the indexes on the table, so it makes things a little slower.   Also, if you delete things from the table, you might leave holes in the indexes that need to be reorganized.   This is done normally by rebuilding the index during a maintenance window.

Now, I think it’s safe to say “I Get It”, at least at this high level.   Now maybe I can move on and not be so confused.

 

Jumping and Gifts

Here’s a video I’ve seen on Facebook a few times featuring Steve Harvey, talking about how you need to “jump” to make your life better.    This should be required viewing for everyone.   Ignore the religious parts of this if you want….that’s up to you and I don’t really know if it’s Biblical or not.   The core of this message is the most important message I can give my kids as they grow up.

Just to build on this, I hope to also impart the idea that when you find your gift, not only do you need to run with it, you need to nurture it.  There’s an awesome book called Now, Discover your Strengths, and a followup called Strengths Finder, that throw out a lot of the rules when it comes to personal development.

The main idea in these books is that it doesn’t make any sense for someone to take a listing of their weaknesses and work to make them better.   The better option is to consider your strengths and go out and nurture them.   This is the exact opposite of every corporate individual development plan thing I ever did, at least until I read and worked through these books.   Sure, there are things you have to do in your career that you suck at, and you have to become at least somewhat proficient in them, but, by and large, you should focus on what you’re good at.  Basically, most people like doing things they’re good at and hate doing things they aren’t, so not only could you make more money nurturing your gifts, but you’ll also be happier.

If you’re good logic and doing stuff like programming, you should make a career out of it and try to be the best programmer in the world.  If you enjoy working outdoors and building things, you should go become the best damn carpenter around.   If you enjoy meeting people and talking things up, you should probably be in sales.   If you’re a great public speaker, maybe teaching or the ministry is up your alley.

Too many technical people are put in a career path where they are expected to someday go into management.   Being in IT is pretty nice in that you can make a darn fine living either remaining technical or going into management, but there’s a fork in the road where you kinda need to decide.   I was always on the fence as to what to do, until I read these books.    Afterward, the Strengths Finder made clear to me that my place is as a technical resource.   I don’t like dealing with conflict, I don’t like holding people accountable for their work, and I don’t like being responsible for things that I cannot directly fix.  I DO like learning new things.   I DO enjoy solving problems.   IT is basically a perfect fit.

If I can get my kids to see that they need to jump at some point and that they need to nurture those gifts that they have, I think I’ll have done a pretty good job of parenting.   Even if they end up doing art and living in my basement….

 

Brain Changes

I’ve always heard that as you get older, you start to learn in different ways.   I know that when I was a kid, I could pretty much pick up a book or listen to a lecture and “get it.”   I didn’t need any hands-on kind of experience to learn how something worked.   They say that adults learn by doing, but that never applied.

Now, I don’t think that I need to “do” to learn, but I’ve found that it’s harder to grasp things from just reading some documentation.   For instance, nowadays, if someone gives me a high-level overview of what some software does, I can then take the documentation and be off to the races.   This is exactly what happened this week with Chef Provisioning Services.

I’d seen the software on Github for a while and had no idea what it did.   I could read the main readme file and all that, but I didn’t get it.   The examples of usage were there, but that didn’t make sense to me.  Then, in a call with Steve Murawski, he said, “Have you tried Chef Provisioning Services?   It’s like recipes for deploying VMs in Azure.”

That is all the man had to say.   I know what recipes do, as I’ve worked with Chef on them for over a year.   I know how to deploy VMs in a variety of ways in Azure, so that’s no issue.   Just hearing “it’s like recipes for deploying VMs in Azure” is all it took for me to get it.

I went out to Github immediately and looked at the example.   Well, d’uh…that makes perfect sense now!   I took the example and within an hour I had the example deployment working.   Since then, I’ve changed the template to use a custom image that I have in Azure already, and I’m a stone’s throw away from being able to spin up as many VMs as I want to from the MS gallery Windows 2012 R2 image.

Why didn’t I see this before?   Maybe there’s a section of your brain that makes the clicks when things click, and it eventually moves slower.   Hell, I don’t know.   I just hope it keeps clicking.  🙂