Rapid skill acquisition: Tips to quickly adapt to new career opportunities

“We need some help with SQL Server work. Can you start Monday?”

It was Friday afternoon. I had taken a class in Microsoft SQL Server years before, on a version years out of date. I’d never really used it in any real projects. And this phone call came from five hours away, in another state.

But I was unemployed. So I said, “Sure thing. See you Monday morning!”

Then I ended the call, got in my car, and drove an hour to the nearest Borders bookstore. I purchased two promising books on Microsoft SQL Server, went to the bookstore’s in-house Starbucks, purchased a venti iced coffee, sat down with those two books and a legal pad, and mapped out my weekend in fine detail. It came down to 15 minutes for this chapter, 10 for that chapter, skip this other chapter, etc. Then I drove home and followed my script meticulously for the whole weekend. This was not easy for me; I’m a curiosity-driven learner who loves to follow a thread and go deeper. Not this weekend, though. I stuck to the plan, and on Sunday night I got back in my car and started the long drive to my new gig.

A similar thing happened when I started my career at Test Double. At that point I had been working with Java for years and hadn’t used Rails much at all during that time. In this instance, I was serendipitously a couple of weeks into a refresher with Rails. Nevertheless, on my first day, I found myself pair programming with Test Double’s co-founder and CEO, Todd Kaufman. No pressure!

So how did I get the chutzpah to jump into these significant career opportunities? Am I arrogant or sublimely self-confident? Well, I don’t think so. I don’t consider myself exceptionally intelligent; based on observation of my many illustrious peers, I’ve always felt that I’m having way too much fun with an average-intelligence brain. I do suffer from imposter syndrome. So how does one gin up the moxie to say, “See you on Monday?” Well, here are a few thoughts on how to do that.

Leverage your existing knowledge and experience

When I said yes to starting work as a SQL Server database administrator with only a weekend to prepare, it’s worth noting that I’d been working with databases for years at that point. I had a pretty good command of SQL, mostly the MySQL flavor. So I knew there would be commonalities. I also knew there would be differences and that I could use those deltas as a sort of knock-out pattern that could help me to mnemonify those distinctions.

In the Rails example, I’d done work with a prior version of Rails and had been leveraging that understanding in my work with Java. I compared my prior learnings of Rails to Java Struts as well as a couple of other Java web frameworks I worked with. When I came back to Rails, I brought all of that with me, giving my new observations of the then-current version of Rails a stronger contextual foundation.

In all these cases, I was able to use what I’d previously learned to develop instincts for the probable design decisions people had made when designing these unfamiliar tools. A crucial part of this is in getting an understanding of the problem which the designers were trying to solve. This can help in making better guesses about features which might exist, and even about what form they might take.

Focus on overview

In both examples I described above, my goal was to get a footing in unfamiliar territory quickly. This meant I had to deny my innate tendency to let curiosity drive, to follow every thread, and to dig deeply. Instead, I ruthlessly time-boxed my study in order to prioritize breadth over depth. This is important to note; depth is certainly valuable. But I knew I had a natural tendency to pursue depth, and I also knew that what I needed in these instances was higher level over-arching perspective.

When it came to prepping for Rails work, I focused on subsystems that I didn’t feel I understood well, approaching each of these in the same time-boxed way. I’d allocate a specific amount of time to study and learn routing, for instance, developing a good sense for the problem it’s meant to solve, and the design values used to create it. And when the time was up, I’d rip myself away and move on to the next thing.

You decide when you’re ready

Maybe it was the spectre of unpaid bills piling up. Unemployment does introduce a certain kind of boldness, after all. Whatever it was, somehow I recognized in these situations (and at other points in my career), that I didn’t have a sensei who would assign to me the perfect number of menial preparatory tasks and then eventually say, now you are ready.

It’s a little bit scary, I’m not gonna lie. The desperation of need does factor in, but it’s also important to think about your own personal standard for readiness. For me in these example cases, that involved getting a mile wide and an inch deep on the particulars and distinctions of SQL Server relative to my other database experience, or working through a set series of specific Rails subsystems. Advice on readiness abounds, but you’ll still always have to make the call yourself.

It’s also important to plan how you’ll represent and defend your readiness. Personally I knew I could not (and would not) outright lie about my level of experience. But I also knew that a certain amount of pre-gig preparation is normal, especially for someone shifting focus to a near-related kind of work. I also did what I could to understand my client’s needs and expectations, and to evaluate my own chances of success. Had they asked me to help with Oracle databases instead of Microsoft ones, for example, the conversation might have been shorter.

Remember that luck favors the prepared

On that fateful Monday, my first day on the job as a Microsoft SQL Server DBA, I happened to overhear a couple of colleagues discussing the difficulties they were having with getting a large quantity of data in a CSV file imported into the database they were working on. They were considering whether they needed to write a small program to do this task.

“Hey,” I piped up, “have you considered using bcp?”

“bcp?” they inquired.

I hadn’t spent much time on the chapter which talked about SQL Server’s “bulk copy program” command-line utility, and three or four days before that, I hadn’t even known it existed. And I’d only spent scant attention to that chapter. But it made sense that such a thing should exist, as moving bulk data into a database doesn’t seem like a weird or fringe use case. I reached over to the book shelf in my cubicle and grabbed one of the two brand new SQL Server books, and thumbed over to the chapter on bcp. And just like that, I was hilariously established as a SQL Server guru.

This kind of thing happens because in software work, nobody knows everything all the time. Someone brand new to the field may well have fresh access to bits of expertise which are disused or unknown to long-experienced experts. It is hilarious, and the only appropriate response to this hilarity is humility. If you’re one of these deeply experienced folks, expect the moment when someone new to the field hands you a key to the problem you’re pairing on. And if you’re new to a particular domain, take heart: Knowledge in the field of software development is not a narrow hierarchy, it’s a vast matrix. Gaining knowledge and expertise is not a matter of climbing a ladder, it’s more like spreading out over a mountainside, searching together for clues. None of us actually knows who will be the next to shout “Eureka!” Maybe that’s scary. Or maybe it’s just part of the fun.