Critical Thought

We’ll get to that in a minute.

Welcome to the blog! If you’re here, and you need an explanation, you’re probably lost. However, because I’m a good sport, you’ve reached the life and times blog of John Napier, a 20-some-odd year old variety-of-things guy. If you know the difference between NP-Hard and NP-Complete, or you feel slightly offended that I’d even ask, you belong here. If you think it’s possible I insulted your mother at some point in that last 60 or so words, you might find your time better spent perusing around some other, less-technical articles – in which case, you’re currently out of luck, as this is my first post. Let’s be on with it then.

It seems to me that in 2009, the concept of what was once considered to be an experienced software engineer has all but vanished. What used to be “experienced” is now considered “masterful”, and the sub-levels below have been graduated up at least one degree, in some cases, more. I’m shocked to meet what is now considered to be a “Junior level engineer” – a 23 year old fresh-out-of-computer-science bachelor’s degree holding script-kiddie. I met this person a few days ago at what became the most awkward interview of my life – stay tuned for more information on this in later posts – and it got me thinking.

To start out, the very first thing you can do completely wrong – something that when done will absolutely solidify any suspicion of question about your competence (whew!) –  is refer to a framework as a language. For instance, confusing JQuery with JavaScript, Cake with PHP, Rails with Ruby, etc. At first thought, it may seem like a subtle, perhaps even non-important difference, until you sit that particular developer down in front of Prototype for JS, CodeIgniter for PHP, or God-forbid, the core Ruby language. You’ll find them typing things that their code-assisting IDE complains about within the first couple of lines of code. These developers have become dependent on their frameworks.

Now, for all of you who are so frustrated at the notion that I’m against frameworks in general you’re about to cry, hold your tears! Sam Stephenson did nothing wrong in creating Prototype. In truth, of the many JS libraries I’ve used, Prototype is one of my favorites. I’m not speaking against the use of a framework for it’s application organization faculties, helpers, or rapid code-development properties – provided the parties using the framework could perform the same tasks without it.

Some languages attract library-only development more than others – JavaScript is one of these languages. One of the most clear-cut signs of framework dependency I’ve seen to date was in a phone interview I was conducting about 6 months back. At the JavaScript section, I asked if the developer would know how to crawl the DOM and return an array – or browser-specific iterable object, if necessary – of all DOM elements with a class containing “my-div”. The initial response was “…sure…document-dot-get-elements-by-class-name.” As if to say “Duh, why am I not conducting you’re interview.” 

At this point, I figured there were a few possibilities. He could have taken the initiative to familiarize himself with our code base, and noticed we were using Prototype. He then augmented his natural, instinctively intelligent response to reveal his initiative and ability to step into a Prototype framework and hit the ground running. This was the first, and truthfully, the only acceptable possibility . The others I could think of involved his having worked so long in a Prototype environment, he simply had a brain glitch, or that he was, frankly, incapable of writing actual JavaScript, etc.

Whatever the reason, he was more than slightly surprised and annoyed at my response: “OK, very good. Now without the assistance of Prototype, or any framework for that matter. Also, make it work in both Firefox and Internet Explorer…6″. He had pissed me off.

Suffice it to say that in the painful 5 minutes that followed, he was unable to even begin to approach how one could perform this incredible engineering feat. I wouldn’t be surprised if he called HR on me and complained that his interview process was both cruel and unusual – he wasn’t a rocket scientist, after all.

That was more of an extreme case of one’s dependency on a framework to do his work for him. The point I’m trying to make is this: there are key, fundamental elements of programming and engineering. Some of these involve performance testing, cross-interface compatibility, unit testing, and a variety of other things.

While I’m all for alleviating a developer’s job of ensuring the functions and methods he’s using are highly performant, he has to understand the actual idiosyncrasies and peccadillos of a language to be able to identify why looping with a $$() in Prototype will bring the user’s browser to it’s knees.

While I like the fact that CodeIgniter provides me with an out-of-the-box MVC-with-a-front-controller implementation, I have to understand core OOP principles to realize that its object- instantiation-as-a- Singleton behavior is less than satisfactory on an application-wide scale.

While I think it’s great that Rails simply doesn’t believe in what they refer to as wasting a developer’s time (which I completely agree with) - providing things like scaffolding, Rake, and the Active Record pattern – if you ever, ever want to work at a non-Rails company, you’d better know how to write developmental-only database-insertion code and use a little language you may have heard of called SQL.

Ultimately, it’s about the developer at this point. In 2009, you truthfully can acquire, and retain, a job simply by coding in frameworks, lacking knowledge and understanding about the core language you’re coding in – I’ve seen, and worked, with that particular developer, and his name is I-make-and-will-always-make-70k-a-year; there are many of him, and he’s really only useful for software grunt-work, also referred to as bitch work, because that’s what he is.

…Okay so that was maybe a little harsh, but seriously, if you want to ensure you’re hiring people with the potential to actually become solid software engineers by traditional standards – the ones who can handle learning a language prior to learning any frameworks or libraries built on it – make sure they can do everything you’re company does without the frameworks and libraries that your company uses.

You’ll also find that if you ever migrate to another framework, a task that would simply cause your library-dependent engineers’ heads to explode, the one person you hire who actually knows the language itself will be left – well, with a head.