Robert Standefer

Recently a friend of mine issued a plea on Facebook:

“Calling all techies! [My wife] lost her contacts on iPhone during her latest sync. I’m restoring from a two-year-old backup, her second-most-recent backup, but wanted to restore from her contacts in her mail system. Unfortunately, she has a Mac but uses Outlook. This isn’t even an option in the iTunes/Info tab. Thoughts?”

Challenge…..ACCEPTED.

First, open up Outlook for Mac and click the Contacts tab. Then click File->Export…. Click the “Contacts to a list” option, then click the right arrow.

You’ll be prompted with a window to save the file. Name it something and put it somewhere by clicking Save. Click the Done button in Outlook and you’re finished exporting.

Now open up Address Book. Click File->Import… and find the file you exported from Outlook. Click the Open button and then you get this:

See that option that says “Ignore first card”? Make sure that’s checked. Now click the right arrow. You’ll be presented with the first contact in the list.

On this screen, for each contact, you can confirm that the fields are correctly mapped. You’ll have to do this for every contact. Or you can trust the import implicitly and just hit OK.

Once you have finished, clicking OK will import the contacts into Address Book and you’re good to go!

Recently I was in the market for a new job, and after nearly twenty years’ experience, I found myself looking at several different possible positions, including enterprise architect, software architect, solutions architect, CTO, VP Engineering, VP Product Management, director of IT, and so on. These different positions don’t work with the “one size fits all” resume. Regardless of the amount of experience you have, whether it’s one year or one decade, you have to target your resume for the position you’re going after.

That’s just common sense.

Sometimes, and this is especially true when you work for the same place for a long time or you are a consultant, your job crosses several domains. This was certainly the case for me at Future Health, where I was the CTO but also a software architect, developer, and project manager. Ditto for HP, where my job title was generic and I spent nearly 10 years doing dozens of different things. For certain jobs and employers, I want to put the focus on my development skills, and for others, the focus is on my management skills, plus everything in between.

So when I started my job search, I had several different versions of my resume. Each copy had the “Standefer_Resume_” prefix, and then the job appended, e.g., “Standefer_Resume_CTO” and “Standefer_Resume_Architect.” This got unwieldy after a while, especially as I had to cut-and-paste significant portions of my resume across different versions.

Then it hit me: this is a problem that version control solves. I already have git and Mercurial installed on the machine on which I write my resume(s), so I decided to use Mercurial. I chose Mercurial (also known as hg) after flipping a coin. I’ll write a version of this using Git if you really want me to.

If you don’t have Mercurial installed, download it from the above link. The whole process is super easy.

The first thing I did was create a directory to store my resumes. Then I initialized a new Mercurial repository in that directory. I like to use the command-line, but TortoiseHg makes this process really easy too.

For this example, I’m going to create a simplified version of my resume and then use Mercurial to control the different versions of it. The base version of my resume contains my job titles and high level functions for those titles.

As you can see, it’s a fairly generic resume. I’ve listed three job titles, CTO, Enterprise Architect, and Enterprise Architect. This resume very succinctly captures a high level of what I’ve been doing for the past 10 years or so.

I saved this as Standefer_Resume.docx in the C:\Resumes folder. You can use anything you want to create your resume, but I highly recommend using a file format that is text instead of binary. This will make merging the different versions of your resume much, much simpler.

So, looking at my resume, you can see it doesn’t really have a focus. If I apply for an enterprise architect position, the hiring manager may be put off by the loose summary and the prevalence of my CTO position. So, I need to create a resume that focuses more on my enterprise architecture experience and highlights the EA stuff I did as a CTO. For this goal, I’m going to change from my de facto title of CTO to a functional title of Chief Software Architect.

First things first. I need to commit the base version of my resume to Mercurial:

What I’ve done here is added the file to the repository using hg add, then committed it using hg commit. The last line, hg branch, shows that we’re on the default branch, which is built into Mercurial, and for our purposes represents the default version of the resume.

Now I want to apply for that enterprise architect job. First thing I’m going to do is create a branch for it, like so:

As you can see here, I created a branch with a name (EnterpriseArchitect), committed it, and now I’m good to go. Let me just confirm that I’m in the right branch and my file is there:

Ok, now I can open the resume and edit it. I’ll just change a few things to make it more EA focused:

There, that’s a bit better. (Remember, this is just an example, so don’t nitpick on the details here.) Now it’s time to commit this to the EA branch.

When we look at the repository in TortoiseHg, we see the details of what we’ve done so far.

You can see that we have two different branches, default and EnterpriseArchitect, with the commit messages. Now let’s do something kind of cool. Let’s say I want a version of my enterprise architect resume for a specific employer, so I need to add in my C# knowledge. Easy enough, I can just create an EnterpriseArchitectMS branch. Ok, done.

But what I’ve realized is that I really need this in both of my resumes because I really want to highlight my development skills.

What I’ll do is make the change in my default version and merge it back into the enterprise architect version. First, update to the default branch using hg update -C default and then edit the resume accordingly.

Now my C# stuff is in there. Commit it, then update to the EnterpriseArchitect branch. Now we’re going to merge the default version into the Enterprise Architect version. I used the command hg merge default and Word popped my resume open with the changes tracked.

Now what I need to do is accept the changes I want and reject the ones I don’t. If you look closely, you can see the additions we made to the EA resume, as well as the “Wrote code in C#” change we made to default. This file is a merge of the two versions. I’m going to accept the changes and save the document.

Now my EA resume has the “Wrote code in C#” part, as does my default resume. Save the combined result and commit the changes.

Let’s take a look at the repository in TortoiseHg now.

You can see that we added C# skills to the default branch and merged it back into EnterpriseArchitect. The other branch we created, EnterpriseArchitectMS, isn’t going to be used after all, so we’ll close it with hg commit –close-branch.

After a while, you might have several different versions of your resume all stored in their own branches. A quick look at hg branches shows mine:

That’s pretty much it! I simplified things quite a bit but the concepts are pretty clear. Feel free to email me corrections, suggestions, or questions at rob@standefer.com or comment here.

As of this past Monday, I’m no longer Chief Technology Officer at Future Health. That means I am now able to write freely about projects I’m working on, opinions I have about technology and the market, and more. It also means I get to work on new things with more hands-on development, more customer interaction, and less stress.

I’m taking a week or so off before I start a new position, and I’m using the downtime to explore Ruby on Rails a lot more (and relax, of course). Last night I went to the Iowa Ruby Brigade meeting downtown and watched a very good presentation on getting started with Ruby on Rails, presented by my friend Levi Rosol (founder of ScoreYard and Craft.ly). Levi’s work is inspiring because he comes from a .NET development background and learned Rails on his own, and made not one, but two different applications that are startups in their own right.

I’ve had a project bouncing around in my brain for a couple of years, and I never really got it off the ground. That’s not all bad; the time I’ve spent waffling on building my idea has resulted in a simplified design and feature set, which means less development time and a simpler elevator speech. Yesterday I went over the idea with Zoe and she helped me identify a couple of areas that I will focus on in the next several days.

Today I will get a Heroku account set up, sign up for a new GitHub account, get the development environment configured, and build version 1.0 of the landing page. Then I need to start thinking about a name.

That may be the hardest part of the whole thing.

Last week I launched http://summerofrob.com. I agonized over the decision of which technology stack to use. At first, I started working on a Ruby on Rails app for the site. Then I thought I should use ASP.NET MVC because it’s what we use at work. Finally, I decided to just freaking ship it, so I settled on my favorite blog engine, WordPress.

When people ask me for advice on how to enter the software development biz, I always tell them, "Find a project and build it, preferably something you’re passionate about." One of the new people on my team has never had a programming job before, but he built a complete application on his own time that is pertinent to his interests. In doing so, he learned how to be a developer. Now that he’s on my team, we’re able to coach him and grow his skills.

I don’t always take my own advice, but I also don’t feel passionate about building something like summerofrob.com. That’s a site that serves a purpose, and while it would have been great to become a better Rails developer by building that site with it, it would put the project itself at risk. After all, what matters most to me is having the site available when Summer of Rob starts.

Most of what I learned when I started my career were from doing my own thing. In fact, my first professional development job came about from writing a bunch of Excel macros for a really complex spreadsheet (auspicious, I know). I just kept learning and learning because I really wanted to be a software developer, and nothing was going to stop me. My macrolust even cost me a job once. I had added BEEP statements to a Lotus 1-2-3 spreadsheet macro and my coworkers thought I was playing a game, so they reported me, and I was fired. In the grand scheme of things, that worked out just fine.

I still feel that spark of passion, but it’s often tempered by what needs to be done. Case in point, summerofrob.com. Yet, I find opportunities to create new things and learn new things, and they’re not always related to software development. Now I look at myself and say, "What’s next?"