Bad Coders VS. Lazy Coders


4 Comments - LEAVE A COMMENT

What’s the difference you ask? A lazy coder MUST be a bad coder! If you’re lazy then you’re not coding to best practices therefore you MUST be a bad coder.

While the above in part is true, there is an integral difference between someone who is a flat out BAD coder and one who is just a bit on the lazy side. If you’re looking to hire a coder there is a few key ways to tell the difference.

How to spot a bad coder vs. lazy coder

  • Tables -Ok people, tables are the WORST possible way you can realize all the hard work someone has put into a design. Are they more often then not cross browser compatible at face value? Eh, yes. But a good coder worth the time and money can translate practically ANY design into a cross browser compatible tableless version of all that hard work.
    • Bad Coder: Will resort to tables immediately. “CSS? That’s for styling my table background and link hovers, right? Right?”
    • Lazy Coder: Will resort to using a small table to contain things such as business hours (that’s close enough to tabular data), or forms.
  • DIVS, DIVS, DIVS and more DIVs! – Take a look at your prospective coder’s HTML. What’s in there?
    • Bad Coder: Is everything <div class="logo">, <div class="paragraph">, <div class="menu1"> etc? Is EVERYTHING controlled by divs? This is bad, bad coding. If the coder knows what they are doing they will be able to control many elements on the page within the CSS by styling just the elements – like, heading tags, lists, paragraph tags, and any available HTML attribute.
    • Lazy Coder: Instead of using the paragraph tag the footer text is wrapped in and defining the styles on that element, a div is added surrounding it.

    Be careful not to judge to harshly as divs ARE a necessary part of coding any design, but if the ids, classes and styles mostly are related to divs, then chances are this particular coder isn’t quite up to par.

  • Unstructured CSS – Take a peek at a coder’s CSS, is it a mess?
    • Bad Coder – Does each section for the sidebar have the SAME look, but the coder has slapped a different class to each portion, and defined each separately in the CSS? Are CSS properties defined separately instead of combined for condensed shorthand? Are there many, many !important, declarations after elements? Chances are high then this coder isn’t a top notch CSS master.
    • Lazy Coder – Do they use a CSS reset method and not redefine more than half of the styles? Or do they use no reset at all? Are there a few too many !important declarations? Chances are this coder is taking the easy way out.
  • No alt="" attribute on img tags
    • Bad Coder – This really doesn’t need too much explaining. If you’re using XHTML images NEED an alt attribute to be defined for it to validate. Don’t care about standards compliancy? You should.
    • Lazy Coder – Generally will miss a few, but even lazy coders are pretty good about remembering a simple alt tag, even if it is just blank (alt="").
  • Images used in HTML where they could have been defined as background-images in the CSS
    • Bad and Lazy Coder – Example: A picture of flowers in a header. If that’s defined as an inline image in the HTML, it’s wrong. Example 2 – Perhaps there is a separator image between articles in your sidebar… this can and SHOULD be easily defined in the CSS as a background image.
  • INLINE STYLES!!!!! – Inline styles have their practical uses and are necessary at times.
    • Bad Coder – That said, if you are seeing repeated inline styles for simple things (like all h2‘s in your content area have an inline style of a padding-left:20px) this is bad coding. This easily can be defined in the CSS. The same can be said for embedded stylesheets. The whole point of CSS is to have all your stylistic elements contained in a separate file where you can edit it once and make GLOBAL changes to your website. This is lost if every page has embedded styles when they can be easily put in a CSS file and linked to.
    • Lazy Coder – The lazy coder will sparsely use inline styles. Perhaps on an img that needs to be floated right only a few pages, instead of having a predefined class for that purpose.

    Please be sure not to confuse IE conditional statements with embedded styles (but even these styles can easily be contained in a separate IE targeted stylesheet.

  • Using javascript to control image hover states instead of CSS and text – For something so simple as switching the background on text when hovered over, there is no reason to resort to javascript when CSS can be used alternatively.
    • Bad Coder – Will gratuitously use javascript on things like navigation roll overs, buttons and more, when a few simple lines in the CSS will easily control the same action.
    • Lazy Coder – Even a lazy coder won’t resort to this. They will use CSS to control this, although the lazy coder will be less likely to use the faster loading (also prevents the loading flash on hovers) CSS Sprite method (check out the CSS for the navigation on CSSgirl – an example of using CSS Sprites).

Why is it important to define the differences between these two types of coders? Well, the short of it is – a bad coder is a bad coder plain and simple. Only time and experience will hopefully enhance their abilities. A lazy coder on the other hand is a decent coder in disguise. A lazy coder can easily become a good coder if someone lights the appropriate fire under their behind.

Jump to Comments

4 Responses to Bad Coders VS. Lazy Coders

  1. flippy says:

    i’m a bad coder -=/

  2. Simon says:

    I cannot agree more about the tables (well really with all the points here, but especially tables)

  3. I’m a big fan of your blog and I read it regularly. Keep up the good work!

Leave a Reply

Your email address will not be published. Required fields are marked *