Nick Lewis: The Blog

Everyday, I attempt to read 20 or 30 web development articles, usually via dzone, del.icio.us, and the drupal planet. Its a perverse and masochistic ritual. The articles I scan leave me with a dreadful sense of emptiness -- and a longing for a different career. On the otherhand, it tends to make my development work seem exciting by contrast.

I've identified 7 types of development articles that set kittens on fire. (Disclaimer: I acknowledge my own perverted abuse of blog entries that sets kittens on fire.)

1. The Ultimate List of 83 Untested Plugins, Techniques, or Tools

If I want a huge list of plugins that may or may not work, I can always go to the jquery plugin, or drupal module page and try them myself. Those pages are more useful to me since I can at least see when the last update to them was made. If you inflict such lists on the world, realize we are unimpressed that you can copy and paste interesting sounding plugins, and rewrite a description or two.

If you'd rather offer something useful to your readers, only list plugins you've actually worked with. Simply making sure they "work" isn't really helpful. Copying and pasting them and telling the world to use them is just evil.

NOTE: Smashing Magazine actually reviews the stuff they list, so don't think I'm talking about them.

2. Agile Methodology That Works

Whatever, chief. Unless you're article is titled: "how developers can get clients, senior management, and all powers greater than themselves to accommodate agile development " , I don't care.

Believe it or not, the majority of people reading development articles do not have the power to adjust an entire organizations process and schedule. So what use is advice that assumes they can call every shot at every level?!

Here's my company's *agile* methodology:

1. We are informed we need to build something by a certain date.
2. We throw bugs under a rug so that we can get something live enough to allow other stakeholders to say, "Wait -- this is totally not what we wanted." prior to deadline.
3. We adjust to feedback, and confront the darkness we hid under the rug.
4. Test, test, test.
5. Release and hold breath.

Perhaps, I should start touring the tech conference circuit ( by segway, of course ). I've always wanted an opportunity to bore audiences with seminars on how projects should be managed in imaginationville....

3. New Features That I Think Are Great

If a new project you are involved in makes a new release, don't bore everyone with a bullet list of improvements. If you want people to be interested (and bear in mind, that's a challenge) show them specifics.

If its an api improvement, show them how the api will improve their coding compared to previous versions. If you are trying to make converts -- compare your pure way to the ways of the infidel. *Show* them (remember freshman rhetoric?) exactly why your way will help them be lazy, rich programmers. Anything else is just a press release. And only the perverted, and untrustworthy read those.

The bottom line: an in depth look into one feature is better than a bullet list of 20 features.

4. PHP is Stoopid

I love PHP -- no one is perfect, right? If you are going to criticize PHP spare me from the criticism you've regurgitated from other bloggers. Nearly every anti-php post I read just repeats the same 10 points -- none of which really bug me as a web developer. If you'd like to be schooled on how to properly slap PHP, read this comment left by Steven Wittens. Who, I'll add is drupal.org user id number 2 -- he actually knows his way around PHP.

5. What do you -- the readers at home -- think?

Only 0.2 percent of blogs can actually directly ask their audience questions. And its a classic move: when an a-list blogger feels lazy, he'll often bring up a controversial topic, and ask his readers for their take. After the alist blogger hits the publish button, he retires to his study, and resumes reading his leather-bound volumes by fireplace. Meanwhile, his millions of visitors go at in the comment thread, each believing a lot of people will read their brilliant opinion. This deception more or less is what makes a fair majority of high traffic logs maintain communities.

If you are not an alist blogger, asking your audience a question will always have the reverse effect. In fact, there is no surer way to an empty comment thread than directly asking a question to the readers. So just stop. I promise it doesn't work, and it doesn't make readers think that you care about their opinions. If anything, it just makes you look lazy.

6. 10 Attributes of the Perfect Programmer

I see this article over and over again. Some old fart has a bad experience with a programmer who doesn't have a family, or doesn't sport a buzz cut, or keeps a messy desktop. So he decides to blog about it, and declare all sorts of nonsense like the best programmers have good hygiene, a rich family life, and regularly volunteer at the soup kitchen.

Here's an attribute I'd like to add on the list of things that makes a good programmer:

1. They write concise, extensible code that is as clear as window pane.

7. $_GLOBALS is bad

These articles are not just about globals. They could be about singletons, css hacks, echo vs print... but they always share a common thread. The author seems to be attempting to sound serious, and expert like. All the while, they inevitably leave out the fact that lots of "bad practices" are the ideal approach for real programmers with real deadlines. The value gained, for example, for having pure css corners is less than the time and effort it takes vs. just using javascript to do them quick, dirty, and working on every browser. Shut up with generalizations, and give me an in depth look into the considerations I should make.

Final thoughts:

Leave theology to the vatican. Leave regurgitation of other peoples thoughts to post graduate studies. Save the vocabulary and theory for your CS final.

Your role -- if you can tolerate such an emphatic word -- is to show readers how and why something does or doesn't work. Show them how you saved time. Show them how you mucked up a huge project, and how you would have done it differently. Otherwise, I'll only read you when I need the contrast to make programming fun and interesting.