I’m in the process of changing jobs at the moment, and have been struck by the difficulties inherent in trying to quantify experience and skill in people moving between companies in the web development sector.
I currently carry the job title of “Senior Web Developer”, but my skills are on a par with - and in many cases inferior to - many of the folks I work with. And I’m the only one with “Senior Web Developer” in my email signature. It’s right above the liability disclaimer and the bit about please god think of the trees. But in the company I’m moving to, I’m going to be “Developer”, or maybe “Front-End Developer” - we haven’t decided yet. So where did the “Senior” bit go?
In some companies, the use of “senior” or “junior” is used to connote experience, and in some it’s designed to indicate management structure. In the former, you can expect a Senior Whatever to be wiser than a Junior Whatever (or just a Whatever) in their chosen field; in the latter, Senior might tell Junior what to do, but in the knowledge that Junior can probably do it better than him. That’s essentially where my particular “Senior” comes from in this case.
So you’d be right to imagine that this lowers the value of “senior” when attempting to compare roles in different companies, as each company has a different idea of what “seniority” constitutes. The company that I’m moving to (all will be revealed once I’ve put signature to paper) took quite a while in deciding whether or not to hire me, partly because the experience I have (varied, but centring around PHP) doesn’t neatly dovetail with their choice of technologies (centring around Python). In making their decision they had to compare my skills with the skills of other candidates, many of whom were Pythonistas already, and figure out who would be the best fit. By some stroke of good fortune, they picked me.
My father has been a chartered surveyor for something like thirty years, and it was during a conversation with him on the progress of my job hunt that I realised just how esoteric and impregnable the world of IT and IT skills must seem to those in other professions. A surveying company like the one my dad works for can interview a graduate of Building Surveying or Civil Engineering or whatever and be sure to within some degree of precision what that person may or may not know about their field. After a given number of years working as a surveyor, you can reasonably expect to be earning a certain amount, and this amount progresses with fairly apparent constancy.
As a surveyor moving between companies, your years on the job will be assessed and used as a benchmark for what you should, and probably do know. I don’t know much about surveying, but I’m under the impression that most of your work as a surveyor takes the form of practices and procedures that have been honed over hundreds, possibly thousands of years, and that (and I’m intentionally generalising here) there are generally very few accepted ways to crack a nut while on the job. As it were.
And you can add to that the fact that (and this applies to general programming/software engineering as well) you could be self-taught or a graduate; could have spent those three years in a big company or a small company; could have spent them jockeying with cutting-edge stuff or puttering along with legacy tech and making good money either way, and “three years experience” is even less readily translatable to actual skill.
All this got me thinking about certifications, something that other industries lean on quite heavily. To re-use my earlier example, surveyors can become members of their industry’s professional body, RICS, and being a Fellow of RICS (FRICS) means something. Likewise having a degree in Building Surveying means you’re pretty much guaranteed to know the right things about Building Surveying. For my part, I have a degree that’s half Comp Sci, half Business, but rarely does it come up in interviews and I don’t think I’ve ever got a job because of it.
I’ve worked with extremely skilled people with a large variety of degrees, many of them unrelated to IT and many of them certainly unrelated to web development, and plenty of folks with no degree at all. My point being, unless you’re the hardest of hard-core software engineers, your degree doesn’t have much bearing on what you can do. So the degree, as a certification, doesn’t carry much weight when it comes to web development.
So what do we have? If you specialise in Microsoft technologies (e.g. ASP.NET) you can get an MSCE, or an MVP; if you do a lot of work with Cisco networking tech you might find yourself taking a course to gain a CCNA (I’m told this is a much bigger deal than the MS certs I just mentioned). But these are sort of specific and, not least, of limited relevance to web dev. So is there much else out there for web developers? Well, it seems, not really. A quick search reveals a few ideas, and a few half-assed attempts by jokers like W3Schools, but mostly people asking the same question, and not much of any substance.
What if there was? What would these certifications look like? How about an OWASP cert ((A bit of research reveals that this was on the drawing board for a while, but doesn’t seem to have seen the light of day.)) to signify your knowledge of web app security? How about a Web Standards Professional cert, that shows your commitment and adherence to web standards? How about being certified an Accessible Web Contributor, showing your ongoing desire to create accessible products? Responsive Designer? High Performance Scaling Engineer? That one sounds like action.
You’ll note that these examples don’t refer to specific technologies, and while that was sort of by accident, it represents a valid point. Too many qualifications today mean next to nothing a short while down the line. So if we were to invent the above, we’d have to take pains to keep them tool-agnostic. Web development is one of the fastest moving sectors around, with dozens of new technologies being released every year, so any certification would need to be designed with that in mind - certifying principles rather than packages. Principles change too, but at a far lower rate than operational tech.
Companies seem to deal with the “comparability gap” by putting their hires through technical tests, but it seems that only “in the field” does a person’s ability become apparent. Many companies now seem to take on new hires as contractors on one- or three-month contracts, offering them a permanent role if their trial run works out. This seems like a sensible strategy, but I can’t help but think certification would be a useful arrow in the quiver at selection time.
Who would administrate these certs? How much would they cost to acquire, if anything? These are questions on which the whole thing would live or die, and I don’t really know, but interested to hear ideas. What do you think - would this be something worth having for our industry? Answers on a postcard.