Wrapping up ThinkShout Cares
How a kooky idea turned into a fulfilling, team-building project.
09.28.2010 Culture, Community, and Business
(In response to http://growingventuresolutions.com/blog/state-drupal-certifications-2010)
The increased discussion of Drupal engineering certifications concerns me. I question the motivations behind this movement, the efficacy of such certification programs to precisely identify talent within our developer community, and its potentially skewing effects on vendor selection in the the Drupal service provider industry.
I am not a Drupal rockstar engineer. I’m a humble 4 on the Certified to Rock scale. I’ve asked way more questions on the forums than I’ve answered. But I’ve personally logged probably 3 to 3.5 thousand hours of paid Drupal development and I’ve project managed another 3 thousand hours of such work. I consider myself a pretty solid Drupal technologist who’s made 70-80 clients happy over the last 5 years.
What makes me a passable Drupal technologist doesn’t have much to do with code. It has to do with being an English major and being somewhat talented at communication. It has to do with having lived in the developing world and understanding what true crisis is (it is not a website launching a month late). It has to do with having spent a lot of years working in the vertical (in my case nonprofits) that I serve.
Now, my motivation in writing all this isn’t to self-aggrandize (though it may sound that way), or to feel sorry for myself that I’m only a “CTR 4”. There are way better developers, project managers and firms out there (which is awesome, because I learn from them). My point is that as seen with testing programs in U.S. public schools, a written test of an engineer’s expertise with Drupal provides very limited information when making a hiring decision - while simultaneously bringing with it the possibility of much misinformation and many negative implications for our community.
I think that the following points need to be considered:
The people driving this movement are good. They love the Drupal community. But they need to pay themselves. Managing the certification process has financial rewards. At this point in the process, you don’t have to have the best certification process, you have to be the first to gain traction in the market. Do we want the quality of our fellow Drupal developers to be determined by the marketing that backs such-and-such certification program? Do we want talented Drupal developers to spend time (and money) on certifications rather than contributing organically to our community?
Certified to Rock is a great response to this. It provides a fun, silly, low-key way for Drupal devs to bump chests at the bar after a day at a DrupalCon. There’s no financial reward (that I’m aware of) for those that manage the algorithm. Hopefully if it becomes too serious, it will go away - because it will stop being fun for us geeks.
Engineering certifications provide a single point of data in the hiring process. But that’s the one point that’s easiest to ascertain in the hiring process. With just two or three well-asked questions and 5 minutes of research on Google, I can get a good-enough sense of a Drupal developer to know whether or not I should interview her for a job. It’s the interview process that’s the art - and that process is affected by organizational culture and other factors that can’t be reduced to a written test.
We are largely a self-taught community. Part of why Drupal is so popular is that it’s an easy framework to pickup and learn without familiarity with other development tools. If we focus on hiring developers strictly based upon Drupal experience, rather than plain-old software engineering experience (or God help us, rather than with folks that have been working in Rails or other equally-to-more robust development frameworks), we will miss learning opportunities and we’ll become the stereotypical Royal Family - and a little too close to close to kissing cousins.
Case in point, when OpenSourcery (where I project managed for 2 years) hired Jonathan Hedstrom, he had next to no previous Drupal experience. He’d made relatively few upstream, public commits on any open source projects. But he’d been doing incredible engineering work for years on an application that was intended to be open sourced in the future. He knew source control inside and out, he knew his development tools, he knew test-driven development. He is brilliant, and he instantly became a Drupal star and our senior Drupal engineer. If we’d chosen another applicant with a higher Drupal “score”, the entire Drupal community would have missed out on his talent, let alone OpenSourcery.
Sorry for being crude, but as a vendor this is my primary concern - and not because I’d win or lose that match, but because our clients will suffer as a consequence. It’s already overwhelming for clients, particularly in the nonprofit space, to understand what makes a reliable, effective Drupal shop. It’s not about badges on a vendor’s website. It’s in large part about engineering talent. But it’s mostly about making clients happy. It’s about translating technology into tools. It’s about exceeding expectations. It’s about communicating clearly. It’s about integrity. It can’t be bought with certifications or badges - but it can be hidden in the strobe effect of such flashing marquees.
Even if such certifications are meant to be a single point of data, clients can miss that - particularly in an RFP process. If we want to do right by our clients we need more engagement with them to help them understand the subtleties of working with technology providers - not hand them our “scores”, saying “Good luck, you ought to pick me.”
. . . .
In conclusion, our Drupal community is unique because of its grassroots nature - and the personal interactions that we share as geeks, engineers, artists, activists, and so forth. As Drupal becomes a main-stream enterprise platform, that culture is poised to change. In some ways, it has to change. But we need to be conscious of the unintended effects of the “meta companies” and “certifications” and “service level agreements” (all potential Cathedrals) that are springing up. We need to honor our roots in the Bazaar.
Questions? Comments? We want to know! Drop us a line and let’s start talking.Learn More
How a kooky idea turned into a fulfilling, team-building project.
Back-end intern Myisha shares her experience from her internship here at ThinkShout and what inspired her to create her own website with a cause.