10 Common Mistakes Made by Novice Web Developers

Share this article

I was amazed at the response to my recent article, 10 Common Mistakes Made by Novice Web Designers. I anticipated an angry mob congregating outside SitePoint HQ with pitchforks and flaming torches. Well, I expected a few incendiary comments at least.

It’s time to redress the balance and give web developers some flak. Will they be as open-minded? Are they willing to accept a little criticism? Obviously, this article isn’t aimed at you … you’re a SitePoint reader who already uses best-practice techniques. It provides a list of typical mistakes made by new web developers — but we were all novices at one time. Some points may also apply to that antagonistic co-developer who refuses to accept any notion that their code isn’t perfect…

1. Ignoring web standards
Web standards were invented for a reason: they help you create device-independent web sites and applications. Few people want to learn them, not everyone likes them and most developers will disagree with some aspects — but ignore them at your peril!

A novice developer will make typical mistakes such as:

  • forgetting or using inappropriate DOCTYPEs. I still don’t understand why so many developers use a transitional DOCTYPE — do they really want to add font tags and background attributes?
  • using old-school HTML such as table layouts and center elements
  • not appreciating the subtleties of inline or block elements, e.g. putting h2 headings inside a span
  • not validating their code. Or worse, using a validator then ignoring the results and arguing that validators are inherently flawed.

2. Visualizing the visuals
Do you rely on WYSIWYG design software? Have you avoided learning HTML? Sorry — you’re not a web developer.

WYSIWYG software forces you to think visually — you’ll be focusing on how the page looks rather than the content structure. Use a text editor and consider the presentation layer at a later stage.

3. Semantics shemantics
Here’s how a newbie web developer will code a page’s main heading:


<h1>Main Heading</h1>

Unfortunately, many developers then go wild with their newly-discovered HTML powers and end up with this sort of monstrosity:


<div class="mainheading" style="color:black;"><strong>Main Heading</strong></div>

They were right at the start. HTML provides most of the content tags you require (especially if you’ve migrated to HTML5). Use them appropriately.

You should also watch out for divitis and classitis: the novice developer’s solution to browser problems. It’s time to stop and rethink your code when your HTML starts looking like this…


<div id="content">
	<div id="main-content" class="main">
		<div class="first-item">
			<div class="para1">
				<p id="top-para" class="para">Hello World!</p>
			</div>
		</div>
	</div>
</div>

4. Practicing presentational class names
Presentational class names are another cardinal sin, e.g.


<div id="blue-left-column-96px">...</div>

This initially seems logical — it’s self-documenting code. That’s great until your design changes and the block becomes a 150px right-aligned red column.

5. Lazy browser testing
I’m going to let you in on a little secret. You know how developers moan about IE6? Well, any web site or application can be made to work in Microsoft’s ancient browser. Sure, it takes extra time and the browser has bugs, but they’re all well-documented. It’s often easier to fix a site for IE6 than IE7.

However, leaving IE6 testing until the end of the project will cause no end of grief. Fixing browser issues is no fun and that’s what your developer is really complaining about.

It’s not just IE6, of course — all browsers have bugs, quirks and problems. If you test early and test often, most of the issues can be rectified during the development phase. Unfortunately, the lazy novice developer will:

  • test in one browser throughout the whole of the development process
  • spend more time persuading people that other browsers are rubbish rather than fixing their application
  • and, if they’re given no other choice, they’ll implement horrible quick fixes using browser-sniffing and hacks.

6. Paying no attention to portability
The novice developer will use fixed file paths, hard-coded database connection strings and make assumptions about the environment. Their application will fail dismally if it’s not placed in a folder named “MyApplication1” in the root of an IIS web server running PHP with register_globals enabled. Oh yes, and it connects to an Access database running on their PC.

The ideal web application should be maintenance-free:

  • it should run wherever the files are located
  • configuration parameters should be contained in a single easy-to-edit file
  • if appropriate, it should work on different OS and web server combinations.

As a side note, be careful with sessions. They can catch you out when your popular application moves to a multi-server hosting platform.

7. Brushing off bandwidth
The problem with testing on a local PC server is that bandwidth issues aren’t usually noticeable and your 4MB background image will appear in an instant. Including 27 different JavaScript libraries — on the off-chance you may need them — won’t cause any delays either.

The novice developer does not care about bandwidth. Actually, I’m slightly concerned that our recent SitePoint poll indicated that 23% of developers didn’t care about bandwidth. I’m sure they must have been intranet developers…

8. Awful accessibility
To the novice developer, accessibility == image alt attributes. It’s like assuming you can drive because you successfully tuned the car stereo.

Accessibility is about supporting multiple devices with differing technical capabilities, e.g. mobile phones, screen readers, browsers without JavaScript, missing Flash plugins, or systems without a mouse. It’s not always a high priority — no one will use an online video editor in a screen reader — but there are few excuses for content-based websites. For example, if your page widgets, forms, or links rely on JavaScript, you’re simply blocking a percentage of your audience.

9. Scorning SEO
I partly blame this on the search engine optimization industry. SEO is presented as a mixture of psychoanalysis, technical complexity, and mysterious black arts. Businesses pay extortionate amounts for SEO witchcraft — they have no idea what they’ve paid for, what’s been done, or have any guarantee of success.

Novice developers therefore assume SEO is a wishy-washy soft-skill best left to the marketing department after the website’s gone live. That’s too late — SEO should be planned from the start just like any other aspect of the project.

I’m now going to reveal another industry secret: most SEO techniques are bleeding obvious. (Was that the sound of a thousand SEO sales consultants keeling over?)

If you’re selling Green Dooberries, make sure you mention it — especially in titles and the URL. Adhere to standards, do a little keyword research, produce decent content, add a sitemap, submit the site to search engines, and you’re 90% done. Forget keyword stuffing and other tricks: they won’t work.

10. Useless upgrading
Why should websites and services disappear for several hours owing to “essential maintenance”? I can understand it when hardware fails or you fall victim to a denial of service attack, but normal maintenance tasks should never require more than a few minutes downtime. All files and data can be uploaded, tested, then switched over in an instant.

In addition, if you have the same content, your users should never see a 404 page. URLs may change but it’s easy to redirect old addresses to new locations.

11. Bonus blunders
Here’s a collection of rants which didn’t make my main list:

  • little appreciation of client-server methodologies. This is especially evident when desktop developers start coding for the web — I know one who wrote a component which could only be used by one website visitor at a time!
  • quoting statistics as justification for ignoring or not testing in some browsers
  • not using source control when it matters
  • continually rewriting and refactoring the same code
  • spending hours arguing why technology X is better than technology Y rather than getting on with the task
  • developers who continually fail to address the real problem so they can concentrate on frivolous issues which are more interesting
  • woefully under-estimating development time
  • using duplicate ID names on the same HTML page
  • using form reset buttons — when has anyone ever needed one?
  • relying on bloated libraries when a few lines of JavaScript would suffice
  • not validating user input or assuming client-side-only validation is adequate
  • using JavaScript to apply effects which would be better handled by CSS
  • not playing nicely with other JavaScript code
  • over-use or inappropriate use of Ajax
  • creating separate CSS files for every browser (not just IE6/7 conditional comments)
  • adding inline styles everywhere
  • inappropriate use of Flash
  • using images when HTML text and CSS effects could achieve the same thing
  • forgetting to add a background color for the body
  • using vague technical jargon to bamboozle clients and co-workers.

</end-of-rant>

Have I missed your most irritating novice web developer mistakes? Do you disagree with any points? Let the backlash begin!…

Craig BucklerCraig Buckler
View Author

Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.

developerdevelopmentmistakes
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week