OK I had this post in my mind for a while now — the only reason I’m publishing it so late is because it started initially with just small nags in my head about server side developers and I thought at the time one small nag from me hardly constitutes enough reason for a post. Since then though I guess you could say I’ve got a few more “nags” to add, hence finally this post 🙂
The reason behind it is the continuous specialization of developers in today’s world — mostly understandable, as the explosion of technology nowadays makes it very difficult for any developer to be a generalist. And as you know, we have nowadays (amongst many others) the 2 types of “breed” of developers: the front end and back end developers. And you probably know that in most cases the backend ones tend to think they are the better breed — as they do the “complicated” business logic stuff. However, what I hate about this “breed” of developers it the fact that even though they claim to be better than the front end developers they run shit-scared of simple things like JavaScript, CSS and HTML!
It even amuses me when they come up with comments like “JavaScript is so difficult!” or “CSS is too complicated for what it’s worth” and the likes. First of all, the syntax of JavaScript is right there with Java — we are talking the basic syntax! We’re not talking interfaces, inheritance, polymorphism and so on — because in most cases, as a server-side developer, you are unlikely to be asked to dive in the deep end of JavaScript client-side processing — more likely than not, you will be required to “deal” with some basic JS code in order to identify/fix a bug somewhere in the chain frontend – backend – database. As such, no one would expect server side “gurus” to know JQuery, or Scriptaculous etc — though from my point of view, if you truely are a really good backend developer, you surely figured by now that your backend cannot work alone and as such there’s always a frontend as well; and if you want to make yourself really useful and raise to a challenge then I’d say you should make yourself not familiar with these front-end libraries but even half-decent in using them. (Let’s face it, you will never be asked to write/debug JQuery plugins for instance, but instead you will be asked to deal with some code that maybe uses some of these plugins — and surely reading a page on the jquery website with the help information and being able to understand the calls that use that plugin is not too much!)
So bearing in mind that like I said a lot of the “fancy” stuff is taken out of the language and you’re stuck with Java-like syntax, what is difficult to understand? The DOM/DHTML processing bits? Let’s see…
document.getElementById("...") |
right? You mean you haven’t done any XML processing in the backend and never heard of the DOM and the W3C traversal functions? Because it’s exactly the same API!
And if you’ve done some Java for instance and touched onto Groovy then even some of the more obscure things in JavaScript should be easily readable (yep, JS does have closures too — just done via functions that’s all).
As for CSS — coming from a language like C# or Java where everything is OOP and inheritance you cannot understand it? The whole idea of “cascade” really means “inheritance” as for the CSS properties, you can get them listed on tons of websites nowadays so shouldn’t be a problem understanding that.
So all in all, I don’t get it: if you are a backend developer why can’t you work front end or at least assist with debugging some frontend code? Is it not the case that those who take this approach are not actually developing anymore and instead are so stuck in a routine where they just apply “patterns” (be it for Spring, Struts, or any other framework) that taking them outside that set of patterns (hardly called development!) makes them totally useless? And if that’s the case should you not be worried, if you do have such “developers” in your team, that in fact you might be spending money on something that’s not there really?
Don’t get me wrong, I totally understand that “context switching” in between applications does imply a hit on productivity — as the developer will have to take a bit of time to re-acquiant himself or herself with the product they just switched on to. If this switch happens only rarely, I expect it to be quite significant (ironically, if you get your developers to do this more often the context switching becomes much smoother and there’s less and less time spent on this!) — however, few hours max into it I expect a backend developer to be able to pick on the JavaScript (and if needed CSS, HTML etc) and be able from there on to run with it. If that’s not the case, like I said, time to look at competencies. Either you’ve hired the wrong people, or you hired the right people but you’ve burden them for too long with boring, repetetive “development” tasks that they’ve been brain-washed…in other words you ended up with the wrong people having hired the right ones. Either way, you’re paying too much for your backend development and you probably need a re-shuffle in that department!
And having just written the above, I’m curious to find out at some point in the future, how many companies are going to start asking their backend developers during the recruitment process about their JavaScript skills 🙂
