Andrew Powell has weighed in his thoughts on developers and how well they do (or do not) know SQL in You Think You Know SQL, Don’t You? While I work on one project with a dedicated DBA, for most projects I am in charge of designing the database and writing the queries myself. On a general scale I would consider my database skills to be quite good – but there are definitely situations where I will seek out the help of those with more specialised skills.

The points Andrew raises are interesting because in my mind, you could quite easily substitute “HTML” for “SQL”, “front end coder” for “DBA” and “CSS” for “queries” – and his post would reflect my thoughts on that matter entirely.

A lot of developers get forced into writing SQL HTML as part of their jobs. Should they be doing it? I don’t think so. It’s not necessarily the best of ideas, and in MOST cases should probably be avoided at all costs. Besides, developers cannot be experts in every language or technology right? Something has got to give somewhere. It’s usually their SQL HTML skills that suffer.

Developers are, sometimes, forced into situations where they have no choice but to write their own SQL HTML. There is either no DBA front end coder, a DBA front end coder who isn’t interested in helping developers with their queries CSS, or a DBA front end coder who isn’t even in the development loop (never a good sign). In these cases, developers may have to write their own SQL HTML. Sometimes developers have to know their limitations when it comes to writing queries CSS, especially complex queries CSS. I don’t think a lot of developers do truly know their skill limitations. Yet, these intrepid souls will trudge on thinking they can write SQL HTML just fine. When, in reality, they really and truly do not know the little tricks and tweaks that can make the SQL HTML perform better.

Heh, it does work, doesn’t it? Like SQL, I think HTML/CSS suffers from being considered less important than the application code itself. Also like SQL, optimised HTML/CSS can make a huge difference to not only how well the web application or site works (think cross-browser issues, loading speed, etc), but how easy it is to maintain going forward.

Andrew rounds out his post with some tips for developers to improve their SQL skills, and once again with just a few word substitutions we can borrow his ideas to apply to front end code.

First, he suggests using an ORM (Object-Relational Mapping) framework like Transfer. For HTML and CSS, I would suggest looking at a CSS framework. Blueprint received a lot of coverage when it was launched late last year. More recently, the 960 grid system has been released, which is interesting in that it provides a “kit” of supporting materials including templates for Fireworks, Omnigraffle, Photoshop and Visio. There are others out there – Smashing Magazine has a handy round up of some of the more popular CSS frameworks and also quickly covers the advantages and disadvantages of CSS frameworks.

Next, Andrew suggests using a good DBA. This most definitely applied to HTML and CSS – use a good front end developer, graphic designer and interface designer. In some cases you’ll get all of those wrapped up in one individual, but sometimes that’s not the case. Typically the amount of front end coder time needed will be tiny compared to the amount of application programmer time needed, and an investment in just a few hours can make all the difference.

Finally, when other options are not viable, Andrew suggests engaging an outside consultancy. The same most definitely applies to front end coders – and luckily, good designers and front end people are are far easier to find than database experts!

So what do you think – is having a good, solid presentation layer just as important as having a good, solid database layer? Do you think that writing good HTML and CSS is an art form, like good SQL? Are application developers forced to write HTML and CSS when they shouldn’t be? Leave your thoughts in the comments.