Always be Learning

I found this article about being a better web professional - Five Easy Ways to Be a Better Web Professional. I realized that I have several sites that I bookmarked on this topic. Most of these are specific to PHP but c'est la vie. Always remember The Taxonomy of Terrible Programmers.


The Case for Slow Programming. The Challenging Period - Web Design Weekly.

language agnostic - Why Use !boolean_variable Over boolean_variable == false

10 golden rules for becoming a better programmer

7 Good Developer Habits I Wish I'd Adopted Sooner

The software engineer's career path

50 Lies Programmers Believe

Code by Heart

Signs that you're a good programmer and Am I really a developer or a good googler?

How to write a great error message

Why availability matters

I'm a Good Designer Checklist

CS for All

The 7 Habits of Highly Dysfunctional Developers

Learnable Programming

There is a great article entitled 'Why I'm The Best Programmer In The World' on Coding Horror.

7 Habits of Highly Successful Site Reliability Engineers

Taking the time to figure out how you provide value to a situation is a worth pursuit. Once you understand that, and come to grips with exactly why you are valuable, the rest is easy.

Testing, more specifically PHP Testing

Simplest debugging is make a note before the function is called. 'Hey we are going to do X'.

Here are some other ideas on testing:

SimpleTest for PHP

PHP Master | Preventing Code Rot 101: Unit Testing

PHP Master | Error Condition Testing with PHPUnit

Art of Debugging

Why you should always test.

Here is a great list of tools assembled by Scott Hanselman.

Writing Good Code

Always write your own code.

Quality software is correct (provides functionaltiy to satisfy requirements), exhibits robustness (can it handle unusual and unexpected demands?), and is accurate (describes how error-free the sofware is).

  • Use white space to give code a chance to breath.
  • Give each command its own line - clarity and readability.
  • Always use the shortest name possible which maintaining the meaning of what the varaible holds.
  • One method to fill your code with comments to prepare the page first with English (avoiding all syntax). Then copy that text in as comments adding the code underneath.
  • Unit test - test the code itself. Test with a variety of data, including data outside the range of expected values.
  • Check for misspellings and invalid names.

Here are 8 ways to become a better coder.

JS Hint - write clean javascript.

The Importance of Writing Code That Humans Can Read

Watch Others Program Live

Ways We Work: a digital publication focused on telling stories and getting first-hand accounts of how people do the work they love

Software Architecture cheat sheet

How to Write Better Code: The 3 Levels of Code Consistency

Writing clearer error messages - a great article explaining why and how.

Don't forget your commit messages. Here are some tips on writing good commit message.

Jakob Nielsen's Ten Usability Heuristics

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Match between system and the real world
The system should speak the users' language, with words, phrases, and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
User control and freedom
Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
Error prevention
Even better than good error messages is a careful design that prevents a problem from occurring in the first place.
Recognition rather than recall
Make objects, actions, and options visible. The user should not have to remember information from one part of the dialog to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Flexibility and efficiency of use
Accelerators—unseen by the novice user—may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
Aesthetic and minimalist design
Dialogs should not contain information that is irrelevant or rarely needed. Every extra unit of information in a dialog competes with the relevant units of information and diminishes their relative visibility.
Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focus on the user's task, list concrete steps to be carried out, and not be too large.

Qualities of Creative Leaders

  1. High standards of personal ethics.
  2. Big people, without pettiness.
  3. Guts under pressure, resilience in defeat.
  4. Brilliant brains – not safe plodders.
  5. A capacity for hard work and midnight oil.
  6. Charisma – charm and persuasiveness.
  7. A streak of unorthodoxy – creative innovators.
  8. The courage to make tough decisions.
  9. Inspiring enthusiasts – with trust and gusto.
  10. A sense of humor.
--from the unpublished David Ogilvy

5 essential skills every Web Developer should have

Interface and User Experience
  • At a minimum test against a recent Gecko engine (Firefox), a WebKit engine (Safari and some mobile browsers), Chrome, your supported IE browsers (take advantage of the Application Compatibility VPC Images), and Opera. Also consider how browsers render your site in different operating systems.
  • Consider how people might use the site other than from the major browsers: cell phones, screen readers and search engines, for example. — Some accessibility info: WAI and Section508, Mobile development: MobiForge.
  • Staging: How to deploy updates without affecting your users. Have one or more test or staging environments available to implement changes to architecture, code or sweeping content and ensure that they can be deployed in a controlled way without breaking anything. Have an automated way of then deploying approved changes to the live site. This is most effectively implemented in conjunction with the use of a version control system (CVS, Subversion, etc.) and an automated build mechanism (Ant, NAnt, etc.).
  • Don't display unfriendly errors directly to the user.
  • Don't put users' email addresses in plain text as they will get spammed to death.
  • Add the attribute rel="nofollow" to user-generated links to avoid spam.
  • Build well-considered limits into your site - This also belongs under Security.
  • Learn how to do progressive enhancement.
  • Redirect after a POST if that POST was successful, to prevent a refresh from submitting again.
  • Don't forget to take accessibility into account. It's always a good idea and in certain circumstances it's alegal requirement. WAI-ARIA and WCAG 2 are good resources in this area.
  • Don't make me think
  • Implement caching if necessary, understand and use HTTP caching properly as well as HTML5 Manifest.
  • Optimize images - don't use a 20 KB image for a repeating background.
  • Learn how to gzip/deflate content (deflate is better).
  • Combine/concatenate multiple stylesheets or multiple script files to reduce number of browser connections and improve gzip ability to compress duplications between files.
  • Take a look at the Yahoo Exceptional Performance site, lots of great guidelines, including improving front-end performance and their YSlow tool (requires Firefox, Safari, Chrome or Opera). Also, Google page speed (use with browser extension) is another tool for performance profiling, and it optimizes your images too.
  • Use CSS Image Sprites for small related images like toolbars (see the "minimize HTTP requests" point)
  • Busy web sites should consider splitting components across domains. Specifically...
  • Static content (i.e. images, CSS, JavaScript, and generally content that doesn't need access to cookies) should go in a separate domain that does not use cookies, because all cookies for a domain and its subdomains are sent with every request to the domain and its subdomains. One good option here is to use a Content Delivery Network (CDN).
  • Minimize the total number of HTTP requests required for a browser to render the page.
  • Utilize Google Closure Compiler for JavaScript and other minification tools.
  • Make sure there’s a favicon.ico file in the root of the site, i.e. /favicon.ico. Browsers will automatically request it, even if the icon isn’t mentioned in the HTML at all. If you don’t have a/favicon.ico, this will result in a lot of 404s, draining your server’s bandwidth.
SEO (Search Engine Optimization)
  • Use "search engine friendly" URLs, i.e. use Page on instead Page on
  • When using # for dynamic content change the # to #! and then on the server$_REQUEST["_escaped_fragment_"] is what googlebot uses instead of #!. In other words,./#!page=1 becomes ./?_escaped_fragments_=page=1. Also, for users that may be using FF.b4 or Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1"); Is a great command. So even though the address bar has changed the page does not reload. This allows you to use ? instead of #! to keep dynamic content and also tell the server when you email the link that we are after this page, and the AJAX does not need to make another extra request.
  • Don't use links that say "click here". You're wasting an SEO opportunity and it makes things harder for people with screen readers.
  • Have an XML sitemap, preferably in the default location /sitemap.xml.
  • Use when you have multiple URLs that point to the same content, this issue can also be addressed from Google Webmaster Tools.
  • Use Google Webmaster Tools and Bing Webmaster Tools.
  • Install Google Analytics right at the start (or an open source analysis tool like Piwik).
  • Know how robots.txt and search engine spiders work.
  • Redirect requests (using 301 Moved Permanently) asking for www.Example Domain to Example Domain(or the other way round) to prevent splitting the google ranking between both sites.
  • Know that there can be badly-behaved spiders out there.
  • If you have non-text content look into Google's sitemap extensions for video etc. There is some good information about this in Tim Farley's answer.
  • Understand HTTP and things like GET, POST, sessions, cookies, and what it means to be "stateless".
  • Write your XHTML/HTML and CSS according to the W3C specifications and make sure they validate. The goal here is to avoid browser quirks modes and as a bonus make it much easier to work with non-standard browsers like screen readers and mobile devices.
  • Understand how JavaScript is processed in the browser.
  • Understand how JavaScript, style sheets, and other resources used by your page are loaded and consider their impact on perceived performance. It is now widely regarded as appropriate to move scripts to the bottom of your pages with exceptions typically being things like analytics apps or HTML5 shims.
  • Understand how the JavaScript sandbox works, especially if you intend to use iframes.
  • Be aware that JavaScript can and will be disabled, and that AJAX is therefore an extension, not a baseline. Even if most normal users leave it on now, remember that NoScript is becoming more popular, mobile devices may not work as expected, and Google won't run most of your JavaScript when indexing the site.
  • Learn the difference between 301 and 302 redirects (this is also an SEO issue).
  • Learn as much as you possibly can about your deployment platform.
  • Consider using a Reset Style Sheet or normalize.css.
  • Consider JavaScript frameworks (such as jQuery, MooTools, Prototype, Dojo or YUI 3), which will hide a lot of the browser differences when using JavaScript for DOM manipulation.
  • Taking perceived performance and JS frameworks together, consider using a service such as theGoogle Libraries API to load frameworks so that a browser can use a copy of the framework it has already cached rather than downloading a duplicate copy from your site.
  • Don't reinvent the wheel. Before doing ANYTHING search for a component or example on how to do it. There is a 99% chance that someone has done it and released an OSS version of the code.
  • On the flipside of that, don't start with 20 libraries before you've even decided what your needs are. Particularly on the client-side web where it's almost always ultimately more important to keep things lightweight, fast, and flexible.
Bug fixing
  • Understand you'll spend 20% of your time coding and 80% of it maintaining, so code accordingly.
  • Set up a good error reporting solution.
  • Have a system for people to contact you with suggestions and criticisms.
  • Document how the application works for future support staff and people performing maintenance.
  • Make frequent backups! (And make sure those backups are functional) Ed Lucas's answer has some advice. Have a restore strategy, not just a backup strategy.
  • Use a version control system to store your files, such as Subversion, Mercurial or Git.
  • Don't forget to do your Acceptance Testing. Frameworks like Selenium can help.
  • Make sure you have sufficient logging in place using frameworks such as log4j, log4net or log4r. If something goes wrong on your live site, you'll need a way of finding out what.
  • When logging make sure you capture both handled exceptions, and unhandled exceptions. Report/analyse the log output, as it'll show you where the key issues are in your site.

Thoughts on being a programmer

  • Don't be an asshole.
  • Simple code is hard to write.
  • Exquisitely simple code is exquisitely hard to write.
  • Just because it's easy to understand doesn't mean it was easy to write.
  • In fact, the easier it is to understand, the harder it probably was to write.
  • There are many ways to do something.
  • The first way you think of is highly unlikely to be the best way.
  • Anyway, there probably is no best way - just lots of ways that are differently good.
  • There's always plenty of room for improvement - in your code, in your abilities, in you.
  • If you think you're as good as you're ever going to be - you're probably right.
  • "One-line changes" aren't.
  • Learn to desire success more than you fear failure.
  • You're only old when you can no longer learn new tricks.
  • Always back up before tidying up.
  • RTFM.
  • Err vicariously.
  • Sometimes
    it's OK to be a bit of an asshole. But don't make a habit of it.

This page contains information I gathered and thought were very useful. See more notes on development.

Just to let you know, this page was last updated Friday, Sep 18 20