Coding Horror

For many programmers, our introduction to programming was our dad forcing us to write our own games. Instead of the shiny new Atari 2600 game console I wanted, I got a Texas Instruments TI-99/4a computer instead. That's not exactly what I had in mind at the time, of course, but that fateful decision launched a career that spans thirty years.

Evidently, I'm not alone. Mike Lee had a similar experience:

I was born in 1976, the same year as Apple, so my dad was just the right age to get into the early results of the home-brew movement. One of my few memories of early childhood is of him coming home with a Sinclair 2000 and a book of games. He sat there for hours typing in the code for Space Invaders, and we played it maybe 30 minutes before turning the machine off and undoing all his work.

As did Shawn Oster:

I've been developing software for 25 years, since I was 8, starting with a book called "Your First BASIC Program" that my dad bought me because we had a PC while all my friends were playing StarBlazers on their Apple IIs. He said if I wanted to play games then I could write one myself. At the time I was a bit disappointed (OK, crushed) but now... well, Dad, thank you.

That's why it's so fascinating to retrace the earliest computer games. The personal computer industry grew up with us. We learned how to program by typing in those simple games from magazines and books. Look closely, and you'll find that those old game programs are the primitive origins of most programmers, the reptile brain stem we all collectively carry around in our heads.

Even a humble, simple little pack-in game like Minesweeper has deep roots going back to the days of punch cards:

Minesweeper has its origins in the earliest mainframe games of the '60s and '70s. Wikipedia cites the earliest ancestor of Minesweeper as David Ahl's Cube. But although Cube features "landmines," it's hard to consider this a predecessor of Minesweeper. In Cube, the mines are placed randomly and the only way to discover where they ends the game. You walk over a landmine and you die; you can't avoid the landmines or know where they are before you take a chance.

However, there are a number of very early "hide and seek" games about locating hidden spots on a grid. For example, in Bob Albrecht's Hurkle, you have to find a creature hiding on a ten-by-ten grid. After each guess, you're told in what general direction the Hurkle lies. Dana Noftle's Depth Charge is the same, but in three dimensions. Bud Valenti's Mugwump has multiple hidden targets, and after each guess, you get the approximate distance to each of them. Unlike Cube, these games match the general pattern of Minesweeper more closely: make a random guess to start, then start using the information provided by that first guess to uncover the hidden items. Of course, unlike Minesweeper (or Cube), the was no danger of "explosion," the only constraint was finding the secret locations in a limited number of guesses.

The closest ancestor to Minesweeper is probably Gregory Yob's Hunt the Wumpus.

Although it used an unorthodox grid (the original game used the vertices of a dodecahedron, and a later version used Mbius strips and other unlikely patterns), the Wumpus evolved from its predecessors in many other ways.

I was intrigued by the newfound connection between Minesweeper and Hunt the Wumpus, since the Wumpus is my power animal.

Most of the early games weren't even that much fun. Analyzing the game's program was almost as enjoyable as playing it; the very act of typing it in and understanding the program was "game" enough for many of us. But some of these early games evolved and survived until today, as Minesweeper did-- and it has become so ingrained into the public consciousness that it's now the subject of hilarious parody videos. Despite Minesweeper's simplicity (and popularity), it is also a surprisingly deep game of logic, as documented in the Wikipedia entry:

• Analysis: single square, double square, shared mine
• NP-Completeness
• Mine probabilities
• Measuring Board Difficulty

Minesweeper is still popular with programmers today; Automine, for example, is a Java program that automatically plays Minesweeper by reading the screen and manipulating the mouse.

The Minesweeper article is a part of the amazing Beyond Tetris series on GameSetWatch, in which many classic puzzle games are examined from the vantage point of a game designer and game programmer. I recommend it highly. Fair warning, though: don't click through unless you have plenty of time on your hands. For a programmer, analyzing games is almost as fun as playing them.

I've become a big fan of Twitter. My philosophy is, when in doubt, make it public, and Twitter is essentially public instant messaging. This suits me fine. Well, when Twitter is actually up and running, at least. Its bouts of frequent downtime are legendary, even today.

(I was going to put a screenshot of one of my favorite Twitter messages here, but as I write this Twitter is down. Again. No, I'm not kidding. OK, it's back up.)

One of the design constraints of Twitter is that every message is limited to 140 characters. You quickly learn to embrace and live within those constraints, but if you like to post URLs in your Twitter messages like I do, those 140 characters become very dear. That's probably why Twitter automatically converts any URLs over about 30 characters to short URLs using the TinyUrl service.

For instance, let's say I wanted to make a shortened URL version of Steve McConnell's blog.

http://forums.construx.com/blogs/stevemcc/default.aspx

It's not a particularly long URL, but every character matters when it comes to Twitter. I found a list of common URL shortening services, so let's see how they compare:

• http://qurl.net/1YU
• http://rurl.org/808
• http://jtty.com/cuy
• http://elfurl.com/li4na
• http://shurl.org/pHbnD
• http://shrinkster.com/s9y
• http://tinyurl.com/yvvtag
• http://clipurl.com/?PAP269
• http://shorl.com/dihyfradiduba

Looks like the best we can do is 3 characters to represent the URL, along with a mandatory 16 characters for the protocol, domain name (everyone drops the leading "www"), and slashes. That's a total of 19 characters, a nice improvement over the 54 characters that make up the original URL. But using an URL shortening and redirection service isn't without pitfalls of its own.

1. What if the URL redirection service goes belly up, as the once-popular url123.com did? All your previous hyperlinks are instantly and forever broken. What if the redirection service is only sporadically available? That's arguably even worse.
2. The URL no longer contains any hints whatsoever as to the content of the URL. It's completely opaque. The only way to find out what's behind that hyperlink is to actually click on it. This is not a great user experience for the person doing the clicking.
3. URL redirection services are often used by questionable people for nefarious reasons. Another service, lnk.to, was shut down because of all the spammers abusing their service.

Despite all the potential problems, URL shortening services are still useful in the right circumstances. For example, sending out very long hyperlinks in email is always risky; you never know when the email clients will insert line breaks in the links and render them unclickable. Not to mention mobile devices, where space is always at a premium.

I often wonder why Google doesn't offer an URL redirection service, as they already keep an index of every URL in the world. The idea of Google disappearing tomorrow, or having availability problems, is far less likely than the seemingly random people and companies who operate these URL redirection services-- often for no visible income.

But what really struck me about these services is how they're a perfect embodiment of a classical computer science concept-- the hash table:

In computer science, a hash table, or a hash map, is a data structure that associates keys with values. The primary operation it supports efficiently is a lookup: given a key (e.g. a person's name), find the corresponding value (e.g. that person's telephone number). It works by transforming the key using a hash function into a hash, a number that is used to index into an array to locate the desired location ("bucket") where the values should be.

It doesn't get more fundamental than the keys and values of our beloved hash tables. But some of the services use an absurdly small number of characters as keys-- 1YU, 808, cuy -- to represent the entire Steve McConnell blog URL. Thinking about how they did that leads you to some interesting solutions. For instance, let's compare the result of applying traditional hash functions to Steve's blog URL:

Even the shortest hash function, the 32-bit CRC, is a bit too long for this usage. That's 4 bytes which will be at least five ASCII characters. To get a shorter URL, you'd have to switch to a 16-bit CRC. If you're clever about how you turn those 16 bits into printable characters, you just might be able to fit those 2 bytes into three ASCII characters.

But is a 16 bit hash enough to represent every URL in the universe? Rich Skrenta helps us out with a little hash math:

Suppose you're using something like MD5 (the GOD of HASH). MD5 takes any length string of input bytes and outputs 128 bits. The bits are consistently random, based on the input string. If you send the same string in twice, you'll get the exact same random 16 bytes coming out. But if you make even a tiny change to the input string -- even a single bit change -- you'll get a completely different output hash.

So when do you need to worry about collisions? The working rule-of-thumb here comes from the birthday paradox. Basically you can expect to see the first collision after hashing 2^n/2 items, or 2^64 for MD5.

2^64 is a big number. If there are 100 billion urls on the web, and we MD5'd them all, would we see a collision? Well no, since 100,000,000,000 is way less than 2^64:

264	18,446,744,073,709,551,616
237	100,000,000,000

For a 16-bit hash, our 2^n/2 is a whopping 256; for a 32-bit hash it'd be 65,536. It's pretty clear that URL shortening services can't rely on traditional hashing techniques, at least not if they want to produce competitively small URLs.

My guess is the aggressive URL shortening services are doing a simple iteration across every permutation of the available characters they have as the URLs come in. Each new URL gets a unique three character combination until no more are left. How many URLs would that take? Let's say each character is simple alphanumeric, case sensitive A-Z, a-z, 0-9. You can do somewhat better because more ASCII characters than that are valid in URLs, but let's stick with this for the sake of argument. That's 26 + 26 + 10 or 62 possibilities per character. So with a three character URL, we can represent...

62 * 62 * 62 = 238,328

... about 250,000 unique three-character short URLs. Beyond that, they'd be forced to move to four character representations. Assuming, of course, that the old URLs never expire.

I arrived at work today to find this package.

It's from one "C. Petzold", whoever the heck that is.

Inside was a copy of the book 3D Programming for Windows: Three-Dimensional Graphics Programming for the Windows Presentation Foundation.

It's even inscribed:

This is, of course, a reference to my post How Not To Write a Technical Book, in which I rather harshly called Petzold's previous book "a greyscale sea of endless text and interminable code", and compared it very unfavorably with Adam Nathan's book on the same topic.

I can't speak for the quality of the book, as I haven't had time to read it yet. But if nothing else, it tells us that Charles Petzold has a good sense of humor. (And, indirectly, it demonstrates the value of an "about me" page on your blog with your contact information.)

Thanks, Mr. Petzold.

It takes discipline for development teams to benefit from modern software engineering conventions. If your team doesn't have the right kind of engineering discipline, the tools and processes you use are almost irrelevant. I advocated as much in Discipline Makes Strong Developers.

But some commenters were understandably apprehensive about the idea of having a Senior Drill Instructor Gunnery Sergeant Hartman on their team, enforcing engineering discipline.

You little scumbag! I've got your name! I've got your ass! You will not laugh. You will not cry. You will learn by the numbers. I will teach you.

Cajoling and berating your coworkers into compliance isn't an effective motivational technique for software developers, at least not in my experience. If you want to pull your team up to a higher level of engineering, you need a leader, not an enforcer. The goal isn't to brainwash everyone you work with, but to negotiate commonly acceptable standards with your peers.

I thought Dennis Forbes did an outstanding job of summarizing effective leadership strategies in his post effectively integrating into software development teams. He opens with a hypothetical (and if I know Dennis, probably autobiographical) email that describes the pitfalls of being perceived as an enforcer:

I was recently brought in to help a software team get a product out the door, with a mandate of helping with some web app code. I've been trying my best to integrate with the team, trying to earn some credibility and respect by making myself useful.

I've been forwarding various Joel On Software essays to all, recommending that the office stock up on Code Complete, Peopleware, and The Mythical Man Month, and I make an effort to point out everything I believe could be done better. I regularly browse through the source repository to find ways that other members could be working better.

When other developers ask for my help, I try to maximize my input by broadening my assistance to cover the way they're developing, how they could improve their typing form, what naming standard they use, to advocate a better code editing tool, and to give my educated final word regarding the whole stored procedure/dynamic SQL debate.

Despite all of this, I keep facing resistance, and I don't think the team likes me very much. Many of my suggestions aren't adopted, and several people have replied with what I suspect is thinly veiled sarcasm.

What's going wrong?

I'm sure we've all worked with someone like this. Maybe we were even that person ourselves. Even with the best of intentions, and armed with the top books on the reading list, you'll end up like Gunnery Sergeant Hartman ultimately did: gunned down by your own team.

At the end of his post, Dennis provides a thoughtful summary of how to avoid being shot by your own team:

Be humble. Always first presume that you're wrong. While developers do make mistakes, and as a new hire you should certainly assist others in catching and correcting mistakes, you should try to ensure that you're certain of your observation before proudly declaring your find. It is enormously damaging to your credibility when you cry wolf.

Be discreet with constructive criticism. A developer is much more likely to be accept casual suggestions and quiet leading questions than they are if the same is emailed to the entire group. Widening the audience is more likely to yield defensiveness and retribution. The team is always considering what your motives are, and you will be called on it and exiled if you degrade the work of others for self-promotion.

The best way to earn credibility and respect is through hard work and real results. Cheap, superficial substitutes -- like best practice emails sent to all, or passing comments about how great it would be to implement some silver bullet -- won't yield the same effect, and are more easily neutralized.

Actions speak louder than words. Simply talking about implementing a team blog, or a wiki, or a new source control mechanism, or a new technology, is cheap. Everyone knows that you're just trying to claim ownership of the idea when someone eventually actually does the hard work of doing it, and they'll detest you for it. If you want to propose something, put some elbow grease behind it. For instance, demonstrate the foundations of a team blog, including preliminary usage guidelines, and a demonstration of all of the supporting technologies. This doesn't guarantee that the initiative will fly, and the effort might be for naught, but the team will identify that it's actual motiviation and effort behind it, rather than an attempt at some easy points.

There is no one-size-fits-all advice. Not every application is a high-volume e-commerce site. Just because that's the most common best-practices subject doesn't mean that it's even remotely the best design philosophies for the group you're joining.

What I like about Dennis' advice is that it focuses squarely on action and results. It correlates very highly with what I've personally observed to work: the most effective kind of technical leadership is leading by example. All too often there are no development leads with the time and authority to enforce, even if they wanted to, so actions become the only currency.

But actions alone may not be enough. You can spend a lifetime learning how to lead and still not get it right. Gerald Weinberg's book Becoming a Technical Leader: an Organic Problem-Solving Approach provides a much deeper analysis of leadership that's specific to the profession of software engineering.

Within the first few chapters, Weinberg cuts to the very heart of the problem with both Gunnery Sergeant Hartman's and Dennis Forbes' hypothetical motivational techniques:

How do we want to be helped? I don't want to be helped out of pity. I don't want to be helped out of selfishness. These are situations in which the helper really cares nothing about me as a human being. What I would have others do unto me is to love me-- not romantic love, of course, but true human caring.

So, if you want to motivate people, either directly or by creating a helping environment, you must first convince them that you care about them, and the only sure way to convince them is by actually caring. People may be fooled about caring, but not for long. That's why the second version of the Golden Rule says, "Love thy neighbor", not "Pretend you love thy neighbor." Don't fool yourself. If you don't really care about the people whom you lead, you'll never succeed as their leader.

Weinberg's Becoming a Technical Leader is truly a classic. It is, quite simply, the thinking geek's How to Win Friends and Influence People. So much of leadership is learning to give a damn about other people, something that us programmers are notoriously bad at. We may love our machines and our code, but our teammates prove much more complicated.

I started out in early 2004 as a blog skeptic. But over the last four years, I've become a born-again believer. In that time, I've written almost a thousand blog entries, and I've read thousands upon thousands of blog entries. As a result, I've developed some rather strong opinions about what makes blogs work so well, and what makes blogs sometimes not work so well.

I'd like to share some of the latter with you today, in a piece I call Thirteen Blog Cliches.

Before I start, realize that these are my opinions. That should be a redundant statement on any blog, much less my own, but I'm putting the disclaimer out there anyway. Just because I run my blog a certain way doesn't make it the right way – or even a very good way. These are preferences, not beliefs. Please don't be offended if your blog, or a blog you enjoy, violates one of my so-called cliches. I'm not trying to single any one person or blog out here. It's your blog, and you don't have to answer to me. I'm just some guy on the internet. Run your blog as you see fit. These are nothing more than broad observations formed over a period of four years where I've been deeply immersed in blog culture.

You may not agree that these are cliches. You might even feel very strongly that I'm wrong about all of this. That's what comments and trackbacks are for. Use them.

1. The Useless Calendar Widget

   This list isn't in any particular order, with one exception. There is nothing I dislike more than the redundant blog calendar widget. It's like a recurring canker sore we can't quite seem to rid ourselves of.

   

   I can't think of a single time I have ever found the blog calendar widget helpful. My computer already has a calendar function, so it's not like I need another calendar displayed in my web browser. Every post carries an obvious datestamp, so I can easily discern when it was published. But knowing whether someone posted an entry on the third tuesday of the month? Utterly useless.

   The calendar widget is the vestigial tail of blog engines, evidence of our primordial ancestors. But we've evolved; it's time to lose the tail. Surely there's something more useful we could put in that space.

2. Random Images Arbitrarily Inserted In Text

   One of the cardinal rules of web writing is to avoid large blocks of text. There are plenty of excellent web writing guides that exhort you to break up your text, using bullets, numbered lists, quotes, paragraph breaks, images – anything, anything to avoid creating an intimidating wall of dense, impenetrable text.

   And they're right. That's what you should do. I do it all the time. I'm doing it right now.

   But like all good advice, it can be taken too far. For example, when you find yourself inserting random pictures into your writing for the sole purpose of breaking up the text.

   

   In the above snippet, what does that image have to do with the text? As far as I can tell, absolutely nothing at all. I see this on a disturbing number of blogs and feeds that I regularly read. It's probably due to the influence of Philip Greenspun and his seminal book, Philip and Alex's Guide to Web Publishing, where the text is juxtaposed with random photographs that Philip has taken. It's one of the earliest and best references on web development, and the fact that it's still relevant today despite its age speaks volumes about the quality of Mr. Greenspun's writing. But it's the writing that makes the book a classic, not the amateur photography sprinkled throughout its pages.

   As the old adage goes, a picture is worth a thousand words. But you should no more insert a random image into your writing than you would insert a thousand random words into your writing. I don't care how beautiful your photographs are, it's a terrible, irresponsible practice that distracts and harms readability.

   And those of you sitting there smugly, with your stock photo library and your peripherally, tangentially, almost-but-not-quite related images that you use to break up your text, don't think I'm not talking about you, either. Because I am. Think about that the next time you read an article about a "web 2.0 bubble" accompanied by – you guessed it – a stock photo of a child blowing a bubble.

   Images are not glorified paragraph breaks. Images should contribute to the content and meaning of the article in a substantive way. And if they don't, they should be cut. Mercilessly.

3. No Information on the Author

   When I find well-written articles on blogs that I want to cite, I take great pains to get the author's name right in my citation. If you've written something worth reading on the internet, you've joined a rare club indeed, and you deserve proper attribution. It's the least I can do.

   That's assuming I can find your name.

   To be fair, this doesn't happen often. But it shouldn't ever happen. The lack of an "About Me" page – or a simple name to attach to the author's writing – is unforgivable. But it's still a problem today. Every time a reader encounters a blog with no name in the byline, no background on the author, and no simple way to click through to find out anything about the author, it strains credulity to the breaking point. It devalues not only the author's writing, but the credibility of blogging in general.

   Maintaining a blog of any kind takes quite a bit of effort. It's irrational to expend that kind of effort without putting your name on it so you can benefit from it. And so we can too. It's a win-win scenario for you, Mr. Anonymous.

4. Excess Flair

   I'd like to talk to you about your flair.

   Blogs work because they're simple. When we clutter up our blogs with a zillion widgets, features, and add-ons, we're destroying an essential part of what makes blogs worthwhile.

   

   I've lost track of all the times I've clicked on an image in a blog and been hijacked by some crazy JavaScript image loading technique, when a simple link to the image would have sufficed – and probably would have been faster and more convenient. Or when I've moused over an unassuming hyperlink and had an annoying, superfluous image preview of the link pop up when I didn't want it to. And do your readers really want to see pictures of the last 10 visitors to your blog?

   Before you add a new "feature" to your blog, consider whether this feature will be useful enough to your readers to overcome the additional complexity it adds to the page. Hint: almost none of them are.

5. The Giant Blogroll

   I'm all for linking generously to outside content. We all stand on the shoulders of giants, after all. Although if you look down in today's world, you might find that you're standing on lots and lots of midgets. Large or small, we owe them a debt of gratitude.

   Citing your references and influences is a great and necessary thing, but obsessively listing every single blog you read – the so-called "blogroll" – is just noise.

   

   If you're really reading this many blogs, you should be linking to them organically in your blog posts, in a sort of natural quid pro quo. Wearing a giant blogroll on your sleeve is an empty gesture. I'm reminded of the distasteful way that blogs in giant ad networks (such as Weblogs, Inc) spam every page with a huge list of internal links to their other blogs. It feels artificial and insincere.

   Publish your OPML if you think organic links in your writing aren't telling the whole story, but avoid cluttering up your page with a huge, spammy blogroll.

6. The Nebulous Tag Cloud

   I'm a big fan of tagging. It's far superior to the old method of placing everything in hierarchical folders. Tag categories on blogs are moderately useful, particularly for bloggers who tend to bounce around among many different topics. What I've never found useful, however, is the stereotypical tag cloud visualization, where the size of the tag word varies with its frequency. 

   

   The perception is that tag cloud visualizations are cool, like badges of honor for the tagging club. The reality is that tag cloud visualizations are chaotic, noisy, and unusable. Keep the tagging, lose the cloud. A simple sorted list of tags, along with the number of posts associated with each tag, is much more effective.

7. Excessive Advertisements

   Advertising is a fact of life. People need to feed their starving children. I get it. I've even reluctantly entered the field myself. But is it really necessary to make your blog look like Times Square? Does every square inch of whitespace have to be filled with paid links, Google AdSense, and ad banners?

   

   In the process of researching this article, I found a related article on blog usability that's a perfect – even ironic – example of how you can hurt your usability with excessive, obnoxious advertising. It's everywhere.

   It is almost never in the reader's interest to see advertisements, so my advice is to tread very lightly, and be respectful of your audience. Bad advertising is so prevalent that if you take the time to advertise responsibly, you may find that readers appreciate you for it.

   Well, probably not, but it can't hurt to try.

8. This Ain't Your Diary

   I don't begrudge anyone their right to post whatever it is they think they need to post on their blog. But let's be perfectly clear: your readers aren't coming to your blog to read about you. They're coming to your blog to find out what it can do for them. If you find your blog turning into a diary of your daily activities, you'll have a very limited audience unless you happen to be a real world celebrity. Even my wife isn't particularly interested in the minutiae of what I do every day. Why would I expect my readers to be?

   

   That said, blogs are a place for writers to find an interested audience, and a place for readers to find a helpful peer and a unique voice. It's OK to be yourself; at some level, it is a cult of personality: people are reading not only because your content is useful to them, but because they like you. It's normal to inject a regular dose of yourself into the conversation.

   But like Tabasco sauce and other powerful seasonings, a little YOU goes a long way. A really long way. Write accordingly.

9. Sorry I Haven't Written in a While

   If you haven't posted anything new to your blog in a while, don't waste our time with apologies. Just write! The best apology is new and improved content. Maybe with a wee bit more consistency this time, though.

   The most important piece of advice I give anyone who asks me about blogging is this: pick a schedule you can live with, and stick to it. That doesn't mean you should post substandard crap, of course, but I find that talent is far less important than enthusiasm. And the best way to demonstrate your enthusiasm – and to improve – is to get out there and write. Regularly.

   And if you can't muster the enthusiasm for writing regularly, move on. But don't stop creating.

10. Blogging About Blogging

    I find meta-blogging – blogging about blogging – incredibly boring. I said as much in a recent interview on a site that's all about blogging (hence the title, Daily Blog Tips). I wasn't trying to offend or shock; I was just being honest. Sites that contain nothing but tips on how to blog more effectively bore me to tears.

    If you accept the premise that most of your readers are not bloggers, then it's highly likely they won't be amused, entertained, or informed by a continual stream of blog entries on the art of blogging. Even if they're filled with extra bloggy goodness.

    Meta-blogging is like masturbating. Everyone does it, and there's nothing wrong with it. But writers who regularly get out a little to explore other topics will be healthier, happier, and ultimately more interesting to be around – regardless of audience.

11. Mindless Link Propagation

    One of the most pernicious problems in blogging is the echo chamber effect. Most blog entries merely regurgitate what other people have said or add vapid commentary on top of news articles and press releases. Only the tiniest fraction of blog entries are original content, and only a tiny fraction of that fraction is worth your time. One of my very favorite articles is Chris Pirillo's piece on 10 Ways to Eliminate the Echo Chamber. Chris has been blogging for a very, very long time and he has the battle scars to prove it. This call to action should be required reading for every blogger. With pop quizzes.

    It's always been deeply disappointing to me that we have the whole of human history to talk about, and most people can't get past what happened today. If I wanted news, I'd visit one of the hundreds of news sites that do nothing but news every day. Putting yourself in the news business is a thankless, unending grind. Don't do it.

    

    If everyone knows about it, what value does that information have? Three years from now, will anyone care that Apple released a new iPod on that particular day? My advice here is almost contrarian: if everyone else is talking about it, that means you should avoid talking about it. Switch things up. Seek out uncommon sites with unique information. Dig down to original sources and read the material everyone is commenting (comments on top of comments on top of comments) endlessly on.

    If all you can find to talk about is what's already popular, you're not trying hard enough. Form your own opinion. Do your own research. Go out of your way to blaze a new trail and create something we haven't already seen hundreds of times before.

12. Top (n) Lists

    Yes, exactly like this one.

    The problem with Top (n) Lists is that they become a substitute for critical thinking, the classic, laziest possible use of Cliff's Notes that every college professor and high school teacher fears. You're supposed to read the book, then read the Cliff's Notes as a companion to the book – not use the Cliff's notes as a substitute for reading the book.

     

    Lists are a great convention. They make sense, people understand them, and they're a logical way to structure your writing. But don't let lists become a crutch. I'm always taken aback when I see the "most popular" posts on a blog dominated by Top (n) Lists. Shortcuts are only meaningful if you know what it is, exactly, you're cutting. If all you read is whatever Top (n) Lists have managed to float to the top of today's Reddit or Digg homepage, then you've cheated yourself out of the deeper experience of reading a complete book.

    If you find that the Top (n) List convention is a go-to tool in your writing toolkit, consider rebalancing your writing portfolio with longer, more in-depth pieces as well. Not everything should be a sprint; throw a few small marathons in there somewhere to complement your short distance skills.

13. No Comments Allowed

    A blog without comments is not a blog. Yes, there are exceptions for massively popular blogs where comments clearly don't scale. But until that applies, the value of the two-way conversation far outweighs any minor inconvenience on your part. Writing is inconvenient. Get used to it, and get over yourself. The sum total of community contributions is far more useful than any one thing you'll ever write.

    Besides, It's an open secret in the blogging community that the comments are often better than the original blog entry itself. Would you browse Amazon without the user reviews? No? Then why would you willingly choose to run your blog that way?

    Don't be afraid of comments. Embrace them. Moderate them. The community will respect you for it, and your blog will be better for it as well.

This piece ended up being much longer than I originally intended. But I've had a lot of this stuff on my chest for years, and I wanted to do it justice. I also needed to explain myself in a constructive way so I don't end up offending too many people.

I've already broken at least two of my own rules with this very post. How cliche.

Discuss.