Thanks to everyone who came out to my session on Getting Started with MongoDB and .NET at the 2012 Carolina Code Camp.

I've uploaded the code to my GitHub repository, please feel free to download and use as you like.  Also, please find links to the references I mentioned in the talk below...

• MongoDB in Action by Kyle Banker
• MongoDB Basics for .NET by Example

If you have any questions whatsoever please don't hesitate to ping me on twitter at @jeremyjarrell!

Did you know that payroll is usually the biggest expenditure of any software company? If you do, then it should come as no surprise that many companies tout the line ‘people are our greatest asset’. However, it can be scary just how little thought those same companies put into hiring the right people for their teams. Here are some things that we've learned over the years which have helped us continue to build a great team.

A-B-R. Always Be Recruiting

With apologies to Glengarry Glen Ross, the number one rule of the game is Always Be Recruiting. Too many times a team will only think about who they would like for an opening just as that position is posted. This is the easiest way to guarantee that you’ll move faster than you meant to on a hiring decision and inevitably settle for a candidate. And, when you’re working on something as important as growing your team, settling is one thing you do not want to do.

So how do you prevent yourself from being forced to make a decision before you’re ready? By always having a pipeline of strong candidates available at any given time. We build this pipeline by constantly having a recruiting presence in our local market by getting involved in networking events, user groups, or by just encouraging our team members to get out and build their own relationships among friends. We’ll regularly troll user groups looking for people talking about the same types of ideas that we value as a team. Or, we’ll post our open positions to LinkedIn and Twitter which allows us to instantly reach out to former colleagues who may be in the market for a change. The goal is to constantly be building a pipeline of great candidates that is ready to draw on whenever a position opens up.

Know Your Gaps (And How to Fill Them)

At the beginning of each year, we make a list of the skills we have on our team and the skills we need...i.e., our ‘gaps’ for the more business savvy amongst us. The result is a list of skills that we know we need to get better at in the coming year, or that are missing entirely from our team. What’s interesting is that the vast majority of our gaps tend to be very niche skills rather than full-blown positions. For example, rather than 'DBA' we may list 'SQL Server performance tuning' as a gap. But unless we think our team of less than 6 can support a 'Senior SQL Server Performance Tuning Specialist' we're not likely to be hiring it as a full-time position anytime soon. That leaves us with three options:

1. Grow those skills in our existing team through training and education.
2. Temporarily bring those skills in from outside through a consulting engagement.
3. Find a candidate for an existing position who also happens to bring those skills to the table.

Finding a candidate who already has those skills can be a huge win, arguably even more so than growing them in-house since the incoming candidate presumably has real-world experience putting those skills to the test. But how do you find such a candidate? By looking at those who are already in your pipeline.

Imagine that you have an open Software Developer position. Now imagine that you have two equally skilled candidates applying for that same position. Both have several years of experience with the platform that you're currently using and both have logged enough hours in your domain to wield the arcane terminology of your industry like a second language. However, one candidate worked to improve the performance of a large SQL Server backed application at his last job by tracking down multiple bottlenecks between the application code and the database. Remembering our skillset gaps from above the choice becomes clear. By hiring a developer who already has those skills not only do we fill an open position, but we also fill one of our gaps with someone who can share her experience with the rest of the team.

Don’t Hire Yourself

Let me be abundantly clear, in a team-oriented field like software development fit trumps all. How someone's personality fits in with the dynamic of your team, regardless of how amazingly talented they may be, is the single biggest factor as to whether or not they'll be successful. However, just because you're hiring for someone that fits in well with your team, doesn’t mean that you want your very own Mini-Me.

One of the biggest results of the rapid evolution of our field is that there are now tons of moving parts to any software project and countless ways to handle each of them. Odds are that you’ve developed some pretty strong opinions about the best way to do each piece and, odds are, you'll gravitate towards others who share those same opinions. Because, if we’re really honest with ourselves, we tend to believe that our opinions are correct by the virtue of them being our opinions. Hiring someone who shares those opinions can have some great advantages as long as we remember this: those that share our same opinions about techniques and technologies will inevitably share our same blind spots. This is true whether those blind spots are confirmation biases about a given platform, ignorance of emerging alternatives, or just misunderstandings about how an alternative technology works. Don’t perpetuate those same blind spots by hiring them again.

Summary

In a knowledge worker industry there is no single greater advantage that you can give to your team than to infuse them with good people. Why not approach this task with the same rigorous thought and attention to detail that you expect each member of your team to bring to their own tasks?

When I was a kid, my big sister and I were addicted to a show called “Out of This World”.  The show revolved around a Evie, a young girl with an alien for an estranged father, who could freeze time simply by pressing her index fingers together.  I don’t have to tell you that this is the type of concept that takes hold in the mind of an 8 year old and never lets go.  I also don’t have to tell you that I spent countless hours in my room pressing my fingers together hoping that ‘maybe this time’ time would freeze for me.

As I’ve gotten older, obviously I’ve realized the fallacy of this idea.  The idea that a race of aliens (the Antareuns, I believe) who are capable of freezing time could ever develop interstellar travel is ludicrous.

You see, interstellar travel would be a huge technological achievement, even for the race of extra-terrestrial swingers that existed in the show.  An achievement so large, in fact, that it could have only been wrought by the constant pressure of deadlines.  The problem, however, is that deadlines and time pressure would be meaningless to a race that could freeze time on a whim.  Why march towards a ship date when you can just freeze time until it’s ready?  What forces the tradeoff between delivery and functionality when you can simply freeze time until all of the functionality is done?  You see, as technologically advanced as the Antareuns were they lacked one crucial piece of knowledge that we learned in software long ago:  if you don’t have a deadline, you’ll never ship.

Without the pressure of a hard deadline features will creep, schedules will slip and a released product yours will never be.  Part of the reasoning behind this comes back to an idea known as Parkinson’s Law.  Parkinson’s Law succinctly states: Work expands so as to fill the time available for its completion.  What this means in a nutshell is that regardless of the true time required for a task, however much time you schedule for the task is how long that task will take.  Do you have a 1 week feature on the schedule for 2 weeks?  Then that feature will take 2 weeks.  How about that 30 minute meeting scheduled for 1 hour?  Congratulations, you just bought yourself a 1 hour meeting.  Like water, any task will invariably expand to fill the time allotted for it.

So what happens when you have a task without a deadline?  Then that task has an infinite amount of time allotted for it, and thus, that task will never be completed.  If you want to ship your product then you have to set a deadline.  No, your product won’t be done at arrival of your deadline.  It won’t have all of the bells and whistles you so desperately believe that your customers need and it won’t have that last 0.999% of polish that it would be unthinkable to release without.  However, guess what: your competitor’s product won’t be done yet either but it’ll already be in the market.  And if their product is all your customers are going to see, then all of the polish in the world won’t save you.