Does Anyone Know Perl
With the official folding of my company into a sister company and my transition to having a fancy sounding title and officially managing managers of developer teams (instead of unofficially overseeing them), I’ve found myself musing over the past. How did I get here? What successes and failures can I learn from? What can I teach others? What do I want to be doing in the future? These are hard questions and I don’t have a lot of answers. But having been a technology consultant for more than a decade now, I do at least have a few interesting stories.
Within the first few months of working at Ackmann & Dickenson, I found Mike Ackmann (co-owner, hence the name) wandering around the office looking for developers and asking “Does anyone know perl?”
At the time, I had recently been hired as Lead Mobile Developer and was working on a small iOS app. I did have some—very limited—amount of experience with perl in years past, and that happened to be more than anyone else he could find. So the next day I found myself on a phone call with a company out of LA being described a complicated problem for an even more complicated software stack that left me confused and intrigued. Red Hat 6. Private fork of Apache 2.2. Physical servers in 6 different data centers around the globe. No documentation. Extremely limited access to the original developer (who’s name happens to be on the patent for this particular doodad). And then a giant pile of disorganized perl scripts. The issue the client then described involved SSL breaking for a small subset of customers. I had so many questions; it was one of those issues that makes you sit at your desk afterword and study your notes thinking “this can’t be right.”
The problem might sound like a nightmare to some, but to me it was a rewarding and a fun challenge. Even though my programming expertise at the time was focussed on iOS and Android development, I was not working on a product at a product company, I was consulting at a technology services company. I was able to use the experience I did have with Linux server management and web development to uncover that the issue was actually different than what they had described and was related to the private fork of apache being out of date, not OpenSSL (though it was also out of date and a major security hazard). The pile of perl turned out to be a red herring and not related to the root customer issue at all, but it did complicate the build process and held up deploying the solution for a stupid amount of time.
The underlying skills as that are most important in this context are not which frameworks, languages, or tools I was most familiar with, but my ability to problem solve coupled with some understanding of how various concepts might be used in different situations. Now, what does it mean to be able to problem solve effectively? In this case it means I understood how to thoroughly investigate a problem, document my findings, understand how to research the problem and potential solutions effectively, and throughout the whole process, pay attention to detail.
Would a programmer with years of experience with C, Perl, Apache and Red Hat have solved that problem faster than I did? Of course, but in the time the client would have likely needed to find that person and negotiate a contract (which we already had in place from other work we were doing for them on a different product), I was already providing them with documentation of what I was finding and helping solve a greater business problem that was uncovered in my investigation, as well as working toward a solution on the original problem.
Successful software consulting companies recognize that the important skills in a developer—regardless of amount of experience that person may have—are curiosity, the ability to problem solve effectively, and being excellent at communicating. Years of experience in whatever the current fad technology is should always be a bonus.