Karl Dubost’s recent post on the craft of HTML coincided with the launch of the first round of Web coding standards at work. Why did we need coding standards? Karl answers that for me in his first paragraph:
HTML is a practical art. In a professional context, it requires precise and extensive skills. As with many popular crafts, the vast majority of people do it on their own, but only a few do it for a living. The quality of products varies a lot.
When you have a team of developers working on a product, you need to set quality requirements… but to meet those requirements you also need to set the expectation that the developers will work in a consistent manner. Sometimes this can be achieved by having the team lead set the direction for the code by crafting templates and doing code reviews. But what happens as team members rotate on and off the project — how do you retain the knowledge about the coding direction without taking time to bring each person up to speed? What happens as your development team grows to 10, 40, 100 people? This stuff doesn’t scale without spelling out the rules and setting expectations… thus the need for coding standards.
But standards alone won’t create consistency, of course. When Karl says that “HTML is a craft”, he implies that there are techniques that one can only learn through study and practice. When practicing a craft, there are skill levels that reach into the realms of mastery that only few will ever meet. Out of that team of 10, 40, or 100 developers, how many will truly become those masters?
My experience over the past 8 years of working in industry has led me to find that only a few will ever commit themselves to the craft of Web development, and that worries me as a developer and as a manager. We all want job security, and dedicating oneself to excellence in a field implies we’re in that field for the long haul. But what career path can a Web developer expect to have today? What opportunities will be available 5 years from know? There are many unknowns and I think that this may be one big reason I don’t see more talented developers taking the plunge and committing themselves more fully to Web development as a craft and career.
Karl points to another problem: the “majority of people do it on their own, but only a few do it for a living”, which to me implies that most people think anyone can be a Web developer (how many times have you heard someone state that their kid could build a better site?) and therefore they don’t take the craft of Web development seriously. I’ve found that most Web developers who didn’t emerge from computer programming backgrounds have serious complexes over whether or not they’re “real” developers… and a lot of this is due to snarky computer programmers who put Web developers down because they make the same, stupid assumption that “anyone can do Web development”. How is that encouraging to anyone looking at committing themselves to this work as their career? (Nevermind how irrational it is for a computer programmer to dismiss part of their larger discipline.) How is that encouraging to anyone who has hopes of using Web development as a basis for a career that could include programming in other languages?
So what’s a developer to do? And what’s a manager to do? I’ll post my ideas at another time… right now, tell me yours.
4 comments
Eddie Welker stopped by on August 10, 2007 at 6:03 PM EST and had this to say:
In general, the number of websites being created is not going down… the number of households with computers isn’t either. It does not seem reasonable that the whole market is going to dry up anytime soon, nor do I see the number of developers entering this market going down. So I don’t see the need for web developers (and thus their managers) drying up in the next 10-ish years. That being said…
The manager should be trying to give the developers a gentle push in the direction of becoming a “master”. Once they are shown the proverbial “path” it is up to the developer to take it or reject it. More specifically, a combination of sharing knowledge with the developers and showing them how to solve problems and find answers will enable show them what they have to graduate from the ranks of amateur to professional. If that person does not take that path, it’s up to you to either use what they can do, or find someone else.
The developer, on the other hand, needs to have a certain proficiency in these areas to begin with, and has to have the desire to go from craft to career. I don’t believe that changing technology strikes fear into those looking for job security… if one is a responsible professional, he/she is always looking at new technologies that can be applied to what they are doing. It may seem like new technologies pop up out of no where, but they rarely spring up out of no-where overnight. Plus, they should look at the fact that most new technologies have foundations in earlier ones, so if they really focus on their profession, they should already be prepared for whatever the next big thing is.
As for people not taking the job seriously… a “potential” developer would not be potential if he/she didn’t take the job seriously. It would take 15 minutes looking at any job board/salary listing/job demand site to realize that the people who need these positions filled take it seriously enough. And while I don’t have an answer to changing people’s ideas about taking different programming disciplines seriously, both sides should remember that someone can really fantastic things in c, as someone else can write really fantastic things in javascript… but anyone can write crap code in any language.
steph stopped by on August 13, 2007 at 7:31 PM EST and had this to say:
Kimmie, this post is so good, it should be over at webstandards.org ;)
Personally, I brainwash my developers, mwahaha.
There’s much so say, but I’ll keep focus on one aspect in this comment.
In my team, it’s (almost) easy, I set a very high bar about who I hire. It’s as much about aptitude as it is about skill, but mostly aptitude for me could mean someone is willing to pick up the required skills. Quite a lot of educating has to do with psychological interactions, the ability to persuade and to coax. I tease my guys if I find any stray ’s, and I show them how they could refactor their code so that it becomes cleaner.
During interviews, I ask very pointed questions that tells me a developer’s skill and ability to think on their feet. If they get an answer wrong or less than satisfactory, quite often I use the chance in the interview to teach them what they should already know in order to have qualified for the job that they were seeking. In some twisted way, I prefer to do this so that more developers (than the ones I hire) realise that they are not up to par when they are not, but instead of dropping them a blind note of rejection, they take away some knowledge that would hopefully set them on the right path beyond my encounter with them.
steph stopped by on August 13, 2007 at 7:33 PM EST and had this to say:
That should’ve said “stray <br />’s” :) Your blog software ate my HTML!
Stéphane Deschamps stopped by on August 23, 2007 at 6:34 AM EST and had this to say:
Here’s food for thought, and a bit of metooism too: I’ve found in my eight years online as a professional that the client-side aspect of development has always been, and still is, considered an intern job.
The general wisdom seems to be this: You want to be a web professional? Do JSP, ASP.net or whatever that works server-side and generates HTML, because HTML is so easy that an intern can take care of it, and my server-side framework will generate most of it anyway.
Yeah, right.
One of my fondest memories is of a manager who told me “you’re lucky, here you’ll work with Java people and you’ll be able to learn a real job”.
Six years after she told me that, I’m still on the client side and feeling very comfy in my shoes, thank you. (but I’m in the lucky bunch who are taken seriously in what they are doing - I hear we’re a happy few)
This long rant to say that the craftsmanship required is all the more difficult to advocate for than most people still haven’t realized that state-of-the art HTML and CSS paired with unobtrusive JS together with accessibility in mind is indeed a real job.
We’ve still got a long way to go before it’s recognised as quality craftsmanship.
My way of changing mentalities in my company? Wait for whatever bug pops up (CSS, JS, whatever), and that happens sooner or later. Usually, it’s because of poor contractor material, or framework-generated stuff. Then people come to my office, and rather than giving them the solution I grab my white board and turn teacher, give them some historical facts (box model, anyone?), explain how this relates to that, and try to make them understand what’s wrong.
Then I help them fix the problem for real, all the while insisting heavily on the fact that yes, client-side is a real job. A few teams in my company are beginning to seriously consider having a full-time client-side specialist. (and I do consider this a small but significant victory).