Here’s a job description I got in my inbox today.

LUCILE PACKARD OF STANFORD MEDICAL CENTER
Sr. UI/Front end Deveoper
Perm, Up to 115K
Top of the Line Benefits

Our client, Lucile Packard Foundation is looking for a permanent UI Developer to join their team immediately on a full-time basis. Please find the responsibilities below and let me know if you might have interest.

Skillset & Requirements:
•7+ years experience developing complex dynamic web applications
•Development and Collaboration w/ both small and large development teams
•Expert knowledge of HTML/XHTML
•Ability to write code without WYSIWYG editor
•Advanced Object Oriented JavaScript
•Experience with JavaScript libraries such as jQuery and DWR
•Practical knowledge of AJAX using JSON
•Proficient in the implementation of Cascading Style Sheets
•Skilled in the use of CSS Selectors
•Competent in Web Design and graphic creation
•Experience w/ WebSphere or WebLogic is a plus

Notice I bolded the “Advanced Object Oriented JavaScript” line. This is the problem that I have with this job requirements list: The very next line mentions jQuery. Every time I see requirements lists like this it almost invariably means that they’re really not doing OOP JavaScript. Oh, they use objects and such, but their actual implementation of OOP tends to be fairly limited. Another problem related to that line is that there is not associated line that requires object oriented analysis and design. Essentially, that shop is doing DOM-level stuff. The effects are cool, but I can tell that the position is pure coding, very little engineering.

Having gone through many interviews in the latter half of last year, when I’ve interviewed with companies who have these kinds of descriptions, invariably, when they post requirements like this, they’re only paying lip-service to actual object-oriented programming. And if they do indeed do OOP, they design by code, which raises a HUGE red flag for me. Only a couple of companies that I interviewed with (one of which I joined) did some level of design, or at least wanted to begin a process that included design. Now by design, I don’t mean visual design, but engineering design, which includes UML diagrams (or industry-standard diagramming), and technical design documents. The best company that I interviewed with up in San Francisco actually spent the better part of the interview grilling me on an object diagram they had me create based upon a set of animals within a fictitious animal kingdom. I had to create the object hierarchy, and also draw out simple sequence diagrams to illustrate the interactions between the animals and their “world.” Very cool stuff, and just about the best interview I had ever gone through.

Unfortunately, a lot of companies just don’t take the time to do real engineering design. Most internet-based companies engage in “agile” development. Gawd I hate that term, mainly because practicing it has been so bastardized. What many organizations just don’t realize is that Agile development requires so much more developer discipline than most engineers are willing to commit. This is exacerbated by pressure from sales and product management to constantly deliver features and the time allotted for delivery just doesn’t allow for taking the time to do design.

As for the last line in the previous paragraph, that’s actually horseshit. In my experience, with good developer discipline, you can actually deliver more in the same amount of time because you don’t waste time flailing around with code. If you discipline yourself to design what you’re going to build, then coding is simply connecting the dots. It may seem counter-intuitive, but I will posit that if you’re not spending at least 60-75% of your development time designing, you’re really not being very productive. Food for thought.