24 tips for web developers

I’ve neglected the development folks lately. Which is ironic, since I’ve spent the last six weeks buried in reverse proxies via nginx, Nutch and writing web spiders in Python.
To make up for it, here’s a list of random learnings I’ve had when I put on my development hat:

1. Learn the business case. Make sure you understand the purpose of the application you’re writing. It’ll help you make informed decisions on features and such.
2. Fight for simplicity. Once you know the business case, you can work with your client to keep the application simple. So do it.
3. A stupid specification doesn’t justify a stupid application. If you know the spec makes no sense, then work with folks to fix it. Don’t write crappy code based on the crappy spec and expect sympathy later on.
4. You’re an architect, not a hammer. In the same vein as #3.
5. Plan twice, write once. Oh. My. God. Before you write a loop within a loop within a loop, think! There’s probably a better way. Small changes in architecture can make life a hell of a lot easier.
6. Plan for scalability. When your client says “Oh, this will never need to handle more than 1000 records” they are lying. Always plan for ginormous scaling. Write your code so that it can someday run on a platform like Amazon EC2, at least.
7. Like it or not, you’re writing for human beings. Turning a simple feature into a game of keyboard Twister may seem logical at the time, but remember: You’re a mutant. You can do things with computers that make a normal person sweat through their shirt. Think carefully about who’ll be using your code, and code for them, not you.
8. Make your users leave you alone. Expose as many features as possible. Don’t force your client to come back to you, for example, just because they now want the spider you wrote to just grab image links, instead of both image and text links. 3 lines of code and you can get another week of peace.
9. Learn at least two languages. Doesn’t matter which two. The mental exercise will make you a far, far better coder.
10. Don’t use frameworks like Django or Ruby on Rails until you know the underlying language really well. Otherwise, the level of abstraction those languages create will turn you into a drag-and-drop programmer, and you’ll write godawful code.
11. Learn SQL!!!!! Every day, I see sites that could run three or four times faster if the developers could have the database server do more of the work, and the web server do less. At the very least, learn how to use JOIN, stored procedures (if your platform has ‘em), indexes and the slow query log (every database platform has one).
12. Don’t use compiled if scripting will do. I know some folks think JAVA is the risen savior. It’s a great platform. But sometimes, a language like Python or PHP can get you a better result with a lot less effort. Be ready to switch when necessary.
13. Learn HTML. And CSS. Too bad. Do it anyway.
14. Learn how web servers work. It will help you make smart decisions about everything from use of secure certificates to caching.
15. Which, by the way, is also important: Learn to use whatever caching modules/commands/features included in your platform of choice. I’ve recently seen three sites that regenerate every line of every page for every visitor. Seriously? You’re updating your site’s Terms and Conditions more than once a day?…
16. Do your own QA. Test your code before you fling it over the wall to the production team or the QA team. There are voodoo dolls especially created for developers who break this rule.
17. Include error trapping. Don’t show nasty 501 error pages to the whole world. As much as possible, have your application gracefully recover from errors.
18. Practice defensive design. Build smart validation into your applications. Anticipate the mistakes a hassled, rushed person might make while using the tools you build for them.
19. Turn on the logging. Your software will break. Make sure you have a clear diagnostic trail when it does: Turn on the logging tools built into your web server and your programming language.
20. Think about security. Trap for injection attacks. Use good passwords. And for the love of everything, don’t use the root user for database access in production, OK?
21. Oh, and ‘password’ is never a suitable password. Ever.
22. Google is your friend. I’ve rarely seen a totally unique development challenge. Chances are, someone else has solved it. Look around.
23. Google is your enemy. Just because someone else solved a problem doesn’t mean they solved it right. Check their assumptions, and yours, before you cut-and-paste.
24. Leave your computer. Stand up. Turn around. Walk out of your office and talk to other people on the team, face to face. Once they recover from the shock, they will be a lot easier to work with.

Other stuff

• An SEO workflow that works
• 19 ways to be a good marketing copywriter
• Dork detection: 10 questions for ‘professional’ developers
• 10 ways to think for yourself