One thing at a time. Finishing one thing before moving on to the next is more efficient because
- you avoid task switching overhead costs
- you can allow your brain to forget things not relevant to the problem at hand
- you make time to build a focused mental context to work in
- you produce higher quality work
Take breaks but don’t multitask. Read my article on multitasking for more background and some practical tips on how to manage your projects and day to day tasks.
Don’t repeat yourself. Known as DRY, this idea came to prominence in the late nineties as part of the Agile Software movement.
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
This can be applied to denormalised databases just as well as duplicate address books. Even such everyday things as having only one place for your car keys or having everything on one central to-do list.
- Record everything but ensure minimal maintenance.
- Look for components and extract them for reuse in other contexts.
- Recognise the overhead involved in DRY; sometimes copy and paste is OK.
- Always fix a guilty, unjustified, rush copy-paste later.
- Things which need to remain in sync won’t; especially if you have to sync manually.
- The opposite of DRY is WET - “We Enjoy Typing”.
‘Miscellaneous’ is an Old English word meaning “I can’t be bothered to think about this.” Miscellaneous can be a good thing, an inbox is a good example, but usually it’s just a dumping ground for unfinished ideas or lazy categorisation. You must have misc but keep it as empty as possible.
Prefer deletion over organisation. There’s a tension between this and not repeating yourself. Recognise when a thing will have future value but don’t hoard for the sake of it. Keep things simple by deleting anything that has no value or whose value is exceeded by the cost of keeping it. In essence, this is an exhortation to fight against the second law of thermodynamics: “There is a tendency to move from order to disorder as time passes.”
My brain is a processor not a memory. Write it down boy! Store notes external to your head. Recognise the ease of looking things up. Have a written to do list. Keep your head clear for thinking rather than remembering.
Support ‘undo’ in everything. Ctrl-Z is your friend. Use a version control system, Git, SVN, whatever. Undoing things is made substantially easier by doing one thing at a time because it creates a linear progression without any interleaved actions.
I’m sorry this letter is so long. I didn’t have time to make it shorter. It takes a great deal of effort to strip things down to their bare essentials. Always be looking for things that can be removed. Usually the complexity of a thing remains constant but our naive, initially rapidly increasing, understanding leads us to generate more data about it. Only once the majority of the data has been collected can we begin to form a fuller understanding and this allows us to remove much of the data we generated on the way.
A web site has four audiences; the user, the client, the tool set and the maintainer. The first two are obvious, though the distinction between them is often not. The tool set has a completely different set of requirements. For example, should a WordPress post title be an
<h1> tag or an
<h2>? The tool set will only accept one or the other but from a user perspective, a categories page should probably be showing a different heading level than a single post page. The maintainer, of course, wants to know why you picked
<h1> rather than
The client isn’t always right. But sometimes you need to let him be wrong. You’ll often disagree with your client over matters of style. Sometimes you need to let the client’s views win out. Sometimes they’ll have business insight which overrides aesthetic concerns. Sometimes it’ll be a subjective call with no ‘right’ answer. Sometimes you’ll be right but the fight isn’t worth the damage to your relationship or reputation. Sometimes you’ll just be plain wrong. Yes, even you Mr Ego.
There are fewer psychopaths in the world than you think. There’s usually a perfectly reasonable explanation behind weird behaviour. Fear and miscommunication are the top contenders. Always take a step back. But never forget that there are some psychopaths in the world.
Rock, paper, scissors, business. Business wins. Always. A business need satisfied beats design shininess every time. The purpose of a shiny design is to satisfy the business need.
Hired for design, fired for process. Projects are almost always awarded based on a pretty portfolio and almost never on a pert PERT chart. Both are important but the usual emphasis is way, WAAAAY out of wack. The fact of the matter is that bad projects almost always go bad because of poor project management and hardly ever because of creative ineptitude.
Real trust is earned trust. If you, as a complete stranger, expect me to trust you wildly, you’re gonna have a bad time. I’ll be doing some work up front, for free, on spec. It’s part of the pre-sale process. That’s my trust investment. Your half of the bargain is that you pay me up-front for the design and development work.
Don’t gild the lily. A drop shadow should not be noticed. Engagement with a design works mainly at a subconscious level. It’s really the things not seen which the brain uses to build its map of what it thinks of your work. Good design should not distract.
Not everybody’s screen is as big as yours. With the rise and rise of mobile tech, this is becoming more and more obvious and barely needs thinking about any more. It is still tempting to stick with a nice big screen for too long during a project though. Go diddy early and make sure you look good on the small screen.
Content is under-rated. Designers have an attraction to the shiny whether it’s the latest and greatest user interface tricks or a gorgeous pixel perfect layout. But it’s information that really counts and that means content and content means words. For the most part at least.
Typography is under-rated. If content is king then he needs some finery. Typography is hard. Really, really, hard. But if you’re after showcasing your content then it has to be done well.
Right, cheap, fast: pick one. Seriously. A well honed process will allow you to choose one whilst also maximising the other two. But make no mistake, you cannot dial more than one of them up to ten. Unless you have flexible resource levels (i.e. you have a team who can be pulled off other work or you can call on outside help). In that case you can potentially pick ‘fast’ and one other. But nowhere near as often as you’d think. More people means more overhead and can really put the brakes on a project until they get up to speed.
Performance should only be optimised in response to measured metrics. A dev who knows what performance bottlenecks his code will encounter is a rare thing indeed. The vast majority of those who do, are simply making lucky guesses. The fact is, there are so many contextual variables that it’s nigh on impossible to do any kind of performance tweaking without actually running the numbers.
You can never test enough. There will always be some funky freaky corner case that you’ve missed. The more you test, the more you eliminate, but don’t ever kid yourself you’ve whacked all the moles. Try to design for resilience under failure though.
Design security in from the start. Security isn’t something you can layer on top of an existing project. It has to be baked into the heart of the thing. Plan what you need early and never lose sight of it. Even after you’ve shipped.
Code for today rather than a dreamed of tomorrow. Otherwise known as YAGNI (you ain’t gonna need it). Many, many, absolutely essential features turn out to be less essential than you first thought. Build a strong, flexible foundation and drop the features on top as and when they are required.
Comments are evil. The voice of your code must be clear and precise. I don’t get it. Never have. Why do so many experienced coders use so many comments? It’s not DRY. Every time you repeat yourself those repetitions will go out of sync. Comments on all your
</div> tags to tie them to their opening tag? You’ve probably got div-itis. Simplify the markup or replace some with HTML5 semantic markup.
A backup plan without tested recovery is just a guess. There are so many things that can go wrong with a backup plan. Simply setting up an automated backup to run once a week is just not good enough. Does it actually run? How do you know if it has run? Has it generated the data (because running is no guarantee that it’s done anything)? Can you get access to the data under all circumstances (hint - no you can’t)? Can you restore from the data? How do you know the restore you just did worked?
A tidy file structure is a cognitive burden beaten into submission. There really should be a place for everything and everything should be in its place. Lots of other principles come into play here. Make sure you only keep one copy of a file. Make sure your files are named sensibly (image.png is not a good name for a file). Make sure your folder structure works for you rather than against you.
Never add a version number or name to a file. Version control is there for a reason. There’s really no excuse for not using a version control system. It’s a bit of a steep learning curve but it’s so pleasing to be confident that you can rewind history in a simple and consistent manner.