Switching Jobs — Damn The Torpedoes

Doug Turnbull — October 1, 2012 | 4 Comments | Filed in: solr

Hi! I’m Doug Turnbull, the new guy. I’m really excited to be joining Open Source Connections. I’ve been seeing first hand how capable my new colleagues are and am really excited by many of the things they’ve been cooking up.

Technologically, I’m going to be learning A LOT in the next several months. I have a ton to absorb on Solr, Lucene, Hadoop, Ruby, and Rails among other things. My goal is to share my thoughts while I come up to speed and absorb all wisdom of my colleagues. Share the mistakes and lessons I learn. Share the random thoughts and ideas that seem interesting.

Before I start that journey though, I thought I’d share something about my background and my decision to join OSC. I need to prove I bring my own geek cred to the table, right?

Well, since I was a kid, I’ve been mesmerized by computers. Back then it was all AppleBasic on my Apple IIe and later QBasic/TurboC/Turbo Pascal in DOS. Even when it was just console IO and using extended ASCII to make little dungeons to play in, I was enthralled by what I could do. I still like seeing that bit of text come out on the console, getting my little power thrill from the simple act of saying “Hello World”.

Professionally, I’ve had a variety of experiences. Most recently as a C++ and python dev doing network analysis for Digital Receiver Technology on their software-defined radio platform. That job had a lot of requirements for maximizing processing throughput. I spent a bunch of my time focussed on performance problems, writing a little tool call VisPerf to help me analyze and improve the performance of C++ applications. I learned a lot of what to do and what not to do to make C++ code fast. I fine tuned data-structures to make them more cache friendly. I sped up a lot of slow string formatting code. I reduced the number of times memory was allocated from the heap in the processing pipeline. Lots of deep knowledge in what is slow and what is fast in C++, specifically in code compiled by Microsoft Visual C++ 9.0 SP1.

At DRT I’ve also been a test-driven development evangelist. There’s something cool about untangling a giant mess of legacy code and taming a meaty part with a suite of tests. There’s also something cool about finding bugs, writing the test to recreate the bug, and proving you’ve fixed the bug — now and forever. The coolest part though is how TDD impacts the culture. Sitting, pair programming with my buddy, writing the test before touching production code and asking ourselves, well what *should* this do? Its a pretty radical change in perspective, and I love radical changes in perspective. Hopefully I can carry my TDD experience forward wherever appropriate.

More specific to Charlottesville, concurrently with my work at DRT, I’ve spent a lot of time as the primary web developer for Charlottesville’s Outdoor Adventure Social Club’s members-only web app. In that role I did my best to be a full-stack LAMP developer (Linux, Apache, MySql, and Php). I was also the main everything from sys-admin to javascript developer to designer of new features for about seven years. I worked on linking up the club’s SmugMug content with the club’s site, and allowing members to associate Facebook accounts with club accounts and lots of other neat features.

I chose to work for the club because I wanted something completely out of left field to work on. I love those kind of things. Painful at first, but in the end I’m better for it. I’ve found a more efficient way to do something, and for me faster ways to implement something cool is always a plus. The larger the library I can pull from the quicker I can go from idea to cool thing on a computer.

Which gets to why I’m starting up at OSC.

At DRT I’ve become a pretty big domain expert. See, for you youngins who might not realize this, a bad thing can happen if you consistently do a really good job at a project. You become the go-to guy/gal for that project. Emergency bug fixes, meetings, customer consultations, it feels natural for others to seek you out on your project. For a long time (months, years, decades even) this is professionally fulfilling. It feels good to keep learning about your project and all things related to it. The project becomes your baby. You get praise for your work on it. You get paid more cause your the “guy”/”gal” for that project.

Eventually though, after many fulfilling months/years/decades, you get to a point where the technological work around the project gets repetitive. You find yourself answering the same questions again and again despite your best efforts at education and cross-training. You solve very similar problems over and over. You have a few people who might know something, or that you’ve tried to bring up to speed, but invariably the company only trusts you to do the heavy lifting. You ask to try something different, but invariable you can’t shake your original project. Starting on your other project, you still get the same calls, go to the same meetings, and find yourself still preoccupied with things related to your original project.

Many software engineers find themselves in this kind of conundrum. Some employers are helpful, but sadly, many are not. So what’s an engineer to do? Well you pretty much have three career options from this point.

The first option is you can become a highly paid expert (read consultant) on your project. As long as it’s a thing, you can rake in the dough from your current employer or whomever. Maybe its a little boring and repetitive. Maybe there’s not much else to learn, but it pays the bills and leaves your bank account in a pretty healthy state. That is as long as that project is a going concern, which can be a big gamble. It could become obsolete or unimportant by something else. You might end up regretting steering your career in a dead end. Or you might end up Daddy Warbucks laughing at us from on top of a giant mountain of consultant cash.

The second option is to pivot. Make a radical change to some part of your experience, but keep another part the same. For me, maybe that would be continuing with the same technology as my current project, but not in C++/Python. Or stick with C++/Python, but with a different problem domain. A rational, halfway solution, this method keeps you in a reasonable compensation situation, allowing you to emphasize one piece of your expertise while not emphasizing another. A good option, in a way hedging your bets. Sticking with one skillset you know and feel secure in while taking on another that may be a bit risky.

Then there’s the third option. The crazy (but fun) option. I call this option “Damn the torpedoes!” Try something radically different and don’t worry about the consequences. Something pretty much the opposite of everything you’ve done up to that point. In this scenario you’re gambling more on your intangibles than on whether any specific technology or skill is going to last into the future. You’re saying that you have the attitude and ability to transcend specific skills.

Selling an employer on the 3rd option after gaining some seniority isn’t easy. Its easy to measure specific pieces of knowledge. It’s harder to measure intangibles like attitude and ability to grow. You say I promise I enjoy learning and breaking out of my comfort zone — but how do you really know? I promise I’m not going to gravitate back to my comfort zone and open every can with a knife cause I can’t be bothered to learn about can-openers. Are you certain?

Well, I’ve pretty much made the decision to figure out a way DAMN THE TORPEDOS! If I can become the prime contributor at the Outdoor club starting from nothing and having enjoyed the experience, what’s stopping me! The time is ripe for change, for new ideas. For identifying and destroying my comfort zone. I want to find better, newer ways to do things. Radical ways to do things! I want to be evaluated on my intangibles, not whether my brain holds the specific facts of what a pointer is and what it means for it to be NULL and what it means for it to be dangling. The latter is trivia.

Lets do this! May the neural pathways built in by past experiences be torn down in a terrifying maelstrom so that they can be rebuilt in new but temporary glory!

Of course, as I said, the 3rd option is always easier said than done. Luckily I’ve found OSC which understands the kinds of intangibles that really counts.  I’m happy to be given the chance. Can I prove to them that I have them? Can I become a pro at this stuff? Can I then become good enough so that I can teach you through this blog?

Well as I write about things big and small, you (and they) can be the judge as to whether or not I’ve succeeded at any of that. Happy trails DRT, its been a good and very educational run, but now its time to damn the torpedoes, charge straight in, and see how much I can turn my mind inside out in the process!

Wish me luck!

4 comments on “Switching Jobs — Damn The Torpedoes

  1. Hi Doug,

    It’s good to hear that there are others out there that think like I do. I’ve recently gone through a terrible job which has given me a completely new perspective. It’s got me damning the torpedoes, shooting for the moon, and hoping for the stars. You aren’t the only one out there. I hope all goes well, and let us know how it goes.

    Good luck,
    Sean

  2. I’m thinking along the very same lines, jumping out of .NET altogether on my latest web app, to get closer to the bare metal. Damn the torpedos! More pony blood!

Comments are closed.

Developed in Charlottesville, VA | ©2013 – OpenSource Connections, LLC