Recently, someone said that I needed to put more of the things with which I’m experienced on my resumé. They’re right, but it’s not an easy task, for a few reasons.
The main reason is that it’s too long. If you can name a mainstream language, chances are I’ve done something meaningful with it. Perhaps it’s not been a major project, but I’ve probably kicked the tires of each language enough to understand what it’s about, the paradigm of the language and ecosystem.
It’s not just limited to mainstream languages, either. There’re some obscure languages that litter the landscape, like Louis II, and even some custom languages, including some to which I contributed.
More than languages, it’s libraries. Java is one language, but it has thousands upon thousands of libraries and utilities providing functionality for application developers. Those libraries range from frameworks like Java EE to Spring, all the way down to matrix and artificial intelligence libraries and over to tiny utilities that just make tasks easier.
The problem here is how to specify with what I have experience, in such a way that my experience stands out in useful fashion.
The other main problem is how and why I have that experience, and what that experience means.
When I was in my twenties, and I’d not used C++ for a few years, a friend of mine and I sat down for what would now be a pair programming session. It’d been a while for C++ and me; I remembered what do to, but when confronted with the actual blank screen, I spaced.
I don’t remember what we did next; we probably played guitar for a while.
That moment stuck with me, though. It hit me again when I was working on the Alcyone, my MIDI foot-pedal controller project, which is written with C++. When I sat down to write it, my first thought was vague panic: how well did I remember C++? Was I good enough to get it done well? (The answer was: well enough, and yes, thank you.)
I use that sensation all the time. It was the basis of my employment by TheServerSide as editor in chief, the guy who’s supposed to vet content for quality and accuracy, and the guy who’s supposed to provide an actual perspective.
And there we have another problem with my experience: depth.
A while back, someone lambasted the Miami Hurricanes’ fanbase, pointing out that it was a mile wide and an inch deep; all their fans are band-wagoners. (When the team does well, they’ve been fans forever; when the team struggles, well, the beach is over there, are the ‘Canes playing today? By comparison, we Florida State fans are actual fans.)
Well, that’s me and a lot of technology, honestly: because TheServerSide watched everything, generally from Java’s perspective but not limited to Java, I encountered it all. Every obscure library wanted to be promoted, so I’d get notices of everything.
I read hundreds of posts a day, trying to understand not just the posts themselves, but whether they were relevant for a wide enough audience that I needed to tell my readers.
Once I decided that a topic was relevant, I had to write it up in such a way that I was actually trying to explain it to my readers. That meant I couldn’t see some obscure fuzzy logic library and think “Oh, that sounds neat,” and then copy and paste some blurb from the project website.
I had to download the project, perhaps build it. I had to understand the problem domain the project was trying to address. I had to try to use it, to see if the project’s claims were accurate, and to see how I actually felt about how it was used.
Therefore, my experience wasn’t just a mile wide and an inch deep – I had to approach everything, and build my experience to the point where I could conceivably use the project to actually do something. I had to come at everything with my tiny grains of knowledge and build a fortress against the ignorance, so I could tell others something they needed to know, whether they knew they needed it or not.
It wasn’t an easy job.
However, that was perfect for me: it played into my skills as an architect, and as someone who integrated information quickly and well, and into my desire to connect people with information.
However, how do I use all of this? Well, as a architect and a consultant, I’m good at approaching problems cold, and seeing how possible architectures map to those problems; I am not limited to seeing things from Spring’s perspective, or Hibernate’s, or Mule’s, or Rails’. I’ve used them all, and I have a good idea about what I think works well, and why, and where they don’t work well.
And if I’m wrong? Well, I don’t let my ego carry me too far down a wrong path; I know I’m human, I know I rely strongly on my ability to integrate and learn. So what, if I recommend Spring for something at first, and find that something else would be better? I had to learn, and I do learn.
So the issue with my experience is two-fold: it covers too much to be useful, and the best aspect of it is the experience of using and learning, as opposed to raw mastery of a given limited set of technologies.
I’m not really sure how to leverage that in the cold light of a resumé.