The job of a front-end developer is a challenging one. Our job is not one of rules but of recommendations and best practices. With each project we try to improve our skills and hope to get better at what we do, but the path to success isn't always very clear. We can learn a lot from our past mistakes, but having a bit more grip on how to improve ourselves can be equally stimulating. This article will tell you where to start.
how to define quality
I'm not too interested in defining a grading scale, as that is quite impossible anyway. I think it's more important to define what areas and scopes there are to define the quality of front-end code. In my experience, there are four important levels that need to be taken into account. I'll start off with the easiest and smallest one, working my way up from there.
1. making a page
Apart from design issues, you also have to worry about writing valid code and you have to make sure that your page is accessible to people not using regular web browsers. For most people this will open doors to a whole new and unfamiliar world, but it's essential for the overall quality of your code.
Checking the quality of this first level is quite easy. Code validators, a quick glance across the source and quickly scanning the page with css turned off will tell you a whole lot. But of course, this is only the beginning.
2. making a page work cross-browser and cross-platform
Time to zoom out. Making one single page to work in your favored browser is one thing, making sure it works okay in a range of browsers and operating systems is a whole different challenge. First of all, it is important to note that it's not necessary to have the page show up exactly the same in all browsers. For older browsers it suffices to make it look and work okay, just without the fancy stuff. It is important though to make sure all the functionality is still there. Sacrificing essential functionality is simply not done.
Usually worrying about browser-compatibility is something that happens afterwards, but it's actually important to have it in mind when you start on a project. Some techniques work better than others, some techniques are easier to fix than others. Choosing the right ones from the beginning will make browser-testing and fixing so much easier for you. Knowing the ins and outs of browsers and slightly changing your code course to steer away from the biggest issues is a long and tiring process, but it helps to improve the quality of your code by a great deal.
Measuring the actual quality of this level is a tad harder, though the length of the browser-testing phase is a good indication of this. The better you get, the easier it becomes to tackle browser problems, and the faster you'll be at making sure all browser show a page in an acceptable way. But even then, some extremely obscure bug might keep you up all night.
3. making a site
This level is actually quite easy to check. Simply take a few pages from a site, single out a few components with clear design variants and check how they are constructed and styled. If there is no common base, this will surely affect the quality of your site in the long run.
4. stability and flexibility
The three levels above are all important, but even matching all three criteria the quality of your code can still be quite subpar. Your code will only truly shine when it proves itself to be stable and flexible. The problem is, you can only measure this when it is effectively too late. You can look for several indicators though.
The first one is when you've reached the point of "the 5 last bugs". These are either last minute changes or bugs with a slightly lower priority you postponed because they are quite hard to fix. You know you did a good job when you can quickly dispose of them. On the other hand, if fixing these bugs introduces new ones or requires reworks of complete sections, there is still plenty of room for improvement.
Another good indicator is "phase 2". How well prepared are you to incorporate functional and design changes without ruining half your site. Can you drop an existing component somewhere else without having to rework the whole css? Can you make your left column wider by only adapting a minimum of css values and without recutting any images? Can you create a design variant of a component without having to deliver new hmtl code? How easy is it to switch places for components? What if a breadcrumb spans two lines? All these elements are indicators of the stability and flexibility of your code.
If the quality level of scope 4 isn't met, it might cost you a lot of time, effort and money. Simple questions of your client will have to be answered by complicated technical answers your client doesn't really care about. It will lead to overtime, missed deadlines, stress and a decline in the relationship with your client.
It is a serious learning process though, as flexibility and stability are only attained by mastering the first 3 levels and evolve from there. If you want to improve your skills, take a look back at the project you just finished and grade yourself on these four categories. See where you've slipped and think of ways to make sure it won't happen again. If you do so with each project, the sky is the limit.