Over the past few months, I've been thinking about ways to become a better software developer, specifically in terms of Firefox extension development. I'm listing the ways that I came up with here; most of it can be generalized to the development of any end-user facing program or application, but I wrote it with extension development in mind. (I initially was going to call it "How to be a better programmer", but as it turned out, the most important things I came up with had little or nothing to do with writing code.)

1. Keep your ear to the ground.

   Nothing is worse than finding out weeks (or months) after the fact that there's a bug in your software that you never knew about. Nobody e-mailed you about it, you never came across it, so what were you to do? If you had signed up for Google alerts on your name/your extension/your website's name, you might have heard about it from someone who blogged about it ("FeatureFox is terrible. It doesn't even detect my COBOL widgets."), but didn't know how to report it as a bug.

   Having Google e-mail you when your name or extension or website is mentioned in a blog post can be invaluable in getting feedback that you otherwise might not have read. (I also find it helpful to use TweetScan to sign up for an RSS feed of tweets that mention your extension. Twittering is the new blogging for many users, especially if it's just a quick gripe about a buggy extension.)

2. Give your users a place to talk to each other.

   If you have a popular extension, that can mean that 100,000 users or more have it installed - one person doing customer support for 100,000 users will get old fast. I've found that if the users have a place to talk to each other (a comment thread on the extension's home page, a support forum), oftentimes, the more savvy users will be able to take over a portion of this support duty by helping out a new user who may be in the dark about how to use a certain feature of your extension. Additionally, several users working together may be able to uncover the roots of a bug more easily than just you and a single user working on it. ("We're all running Linux on a Mac with both Firefox and Seamonkey installed and we're all using a non-standard profile directory? That's a weird coincidence...")

3. Start a public bug tracking system.

   If you're not using some kind of bug tracking system (and I don't include your e-mail inbox as a "system"), you're not really invested in the success of your extension. Although many extensions are quick one-offs to add a new feature to Firefox, keeping track of issues reported by users is key, as 99% of software grows larger than originally anticipated. A public tracking system adds accountability, it gives other users a chance to chime in on a bug that they've experienced but didn't actually report, and it frees up your inbox without casting valid bug reports by the wayside. (I recommend Google Code; it's easy to use, has a nice issue tracker, and the support so far has been great.)

4. Release early, release often

   The old saying "release early, release often" certainly applies here, but I'd like to warn against releasing too early. Uploading an extension to Mozilla Add-ons that only adds a non-functioning item to the Tools menu just to get it out there will do more harm than good, since users will intall it, see that it's worthless, and uninstall it. Not only will they uninstall it, but they'll be more hesitant to download it in the future.

   Make sure your first release is functional, even if its function is small. It's key to get users to download it, but it's just as key to get them to keep it installed. From that point on though, release as often as you can, since everybody loves a good upgrade.

5. Talk to your users

   Whether it's by blogging, Twittering, or creating a thread in a support forum, start a conversation with your users. To many Firefox users, software development is magic - the idea that a person can type up some computer code and make their browser do great new things is mysterious and wonderful, and being able to interact with that person allows them to participate in the magic. The most enthusiastic users (and sometimes the ones with the best ideas) are often those who would have no idea of how to actually write the software behind the features. (Perhaps the fact that they are unencumbered by the burden of implementation is the cause for their enthusiasm...)

6. Be responsive

   This fits in with the previous point, but it's more specific. Once a user has posited a question in a support forum or a blog comment, the clock starts ticking. If it takes you a week to respond about why X or Y doesn't work in your latest release, you can bet that by the time you do answer, that user (and a dozen others who wondered the same thing) have spent the 30 seconds it takes to uninstall your extension because you didn't take the 60 seconds to respond to them.

   On the other hand, timely responses give your users more faith in your commitment to the project. For example, check out this comment left on my blog after I quickly replied to a user about a problem with TubeStop.

7. Participate in the development community

   Mozilla has a great community of developers, and you're doing yourself a disservice if you're not participating. The Mozilla IRC channels and the mozdev.org mailing lists, for example, are both great resources for connecting with fellow developers to brainstorm over weird bugs or just talk about software-related topics. I like to keep this rule in mind: there's always someone out there who knows more than you about extension development, and more likely than not, they're on irc.mozilla.org.

What do you think? What would you add? Anything you disagree with? Reply in the comments, and I will, of course, respond.

Since I always use Firefox as a single window with many tabs (and have become quite adept at switching quickly between tabs, but not so fast at switching between windows), having the Error Console open in a separate window always slows me down. What I've done is created a bookmark on my toolbar (right-click, select "New Bookmark") that points to chrome://global/content/console.xul. This way, I can control where it opens.

Is anyone interesting in helping alpha test and/or do some QA on a side project I'm working on? It's a fairly simple Web application that should be relevant to pretty much everyone, but it will obviously be more useful to some people than to others. (How's that for specifics?)

If you want to take a look and give some feedback, either leave a comment below or e-mail me at cfinke@gmail.com, and I'll send you the URL.

My wife just used the "Forgot my password" form on the MNCPA's website. The automated response was, how you say, not very helpful:

This is definitely a candidate for WorseThanFailure.

Want an easy way to generate a podcast or RSS feed? At Eliot's request, I wrote a PHP script that generates an RSS feed based on the contents of its parent directory, so whenever you add files to that directory (or its subdirectories), the feed is updated with links to those files. It also supports enclosures, so if you add an audio or video file to the directory, that file will be available to podcast clients. If you modify a file in the directory, the feed updates the link so that subscribers will see that it has changed. It's a no-fuss way to syndicate content without having to tie it into a CMS like Wordpress or TypePad.

Here's how to use it:

1. Save this file as EasyFeed.php (or dir.php or feed.php, it doesn't really matter).
2. Copy it to a directory on your webserver.
3. Subscribe to the feed with any RSS or podcasting client.

That's all there is to it. For example, here's the feed of all of the files I've ever uploaded for use in my blog. If you subscribe to that feed with iTunes, you'll see that I've uploaded two audio files: programming.mp3 and calacanis.mp3. iTunes will automatically download them, as well as any other audio/video files I upload. No fuss, no muss.

A few weeks ago, I started a little side project, and I decided to write it in Python with the Django framework based on all of the good things I've heard about it. I may never go back to PHP.

It's like this: imagine you've been driving the same 1987 Dodge Dynasty for the last 8 years. It gets you around, and you know exactly how to handle it. Most importantly, you've learned just what to do when it breaks down to get it going again. Then, one day, someone offers to trade you their brand-new Mustang for your Dynasty, straight-up. (They're a collector of late '80's sedans, you see.) You are unsure, since you'll have to learn how to handle this new car, but you accept, and your entire perspective on driving changes - the tired chore of going to the post office becomes your favorite pass-time; you've volunteering to take friends to the airport even when they have no flights to catch; and you can finally drive on the interstate since you know you won't break down.

This is what it's like to switch to Python after a lifetime of writing PHP. Programming is part problem-solving and part code-writing. With PHP, the fun of solving the problems overcomes the chore of writing the code; with Python, writing the code is enjoyable enough that I find myself wanting more problems to solve just so I can code the solutions. It's a great feeling.

Digg finally fixed the bug I reported and wrote about here 3 months ago. When you consider that my feed reader checks for new items every 15 minutes, 10 hours per day, I received an unreadable feed almost 4,000 times.

Something I've always been fascinated with is the way that certain words can define a time period. Over the last decade, for example, there were periods of weeks where you couldn't turn on the television without hearing "anthrax" or "lewinsky" or "taliban" or "tsunami."

I've been working on a little project to help visualize what these "hot topics" were for each month over the last seven years, and I'm calling it the History Cloud. What I've done is parsed the main pages of several major news sites going back to mid-2001 and extracted the words most commonly used in news articles during each month. I've arranged these words in a tag cloud to make it easy to see which terms dominated the news. Clicking on any of the terms in the cloud shows the stories from that month that made the term popular, courtesy of Google News.

My favorite feature of this history cloud is that when you hover over a term in the tag cloud, the other terms that are related to that term are highlighted as well. This makes it even easier to tell why a certain term was in the news. For example, if you hover over the "bush" tag in May of 2001, the highlighted related terms are "energy", "education", "tax", and "plan." Contrast that with the "bush" term in April of 2003, where the related tags are "UN", "Iraq", and "Iraqi." Oh to be back in the innocent days of early 2001...

If any of this sounds interesting to you, check it out. Feedback is always welcome. FYI: there are a few months with little or no data; clicking on these months just won't display any tags.

Digg finally implemented threaded comments yesterday, and the top story on Digg right now is a harsh criticism of the new system. The consensus appears to be that while the new system is a step forward in terms of technical functionality, it's two steps back for usability.

New features on a large community site will always draw complaints from a vocal minority, so Digg may just have to wait a few days for these users to get acclimated to the changes. My personal opinion is that it's definitely a good step to allow for true replies and threading, but the system seems over-engineered. Having to click to see any replies is a poor design choice, and with all the extra borders and headers, the page gets cluttered very quickly.

My unsolicited advice to Digg is to follow Netscape's or Reddit's lead and simplify what you've got. Drop the "click to view replies" links, keep the pagination ("Click to view the next 50 comments"), and get rid of about half of the extra borders and headers that have been added. Do this and you'll get one of your famous "We love Digg for listening to us" frontpage stories, and the deluge of feedback e-mail I'm sure you're getting will slow to a trickle.

If you had downloaded the Feed Statistics plugin for Wordpress and couldn't use it because of an error during activation, version 1.0.3 is for you. The "Plugin could not be activated because it triggered a fatal error" message was being caused by my usage of PHP's short open tags, which I should have known are not enabled everywhere. Thanks to Veg for the help that led to the fix.

Download the zip file of the newest version here, and overwrite feed-statistics.php in your blog's wp-content/plugins/ directory if you downloaded an earlier version. If you're downloading it for the first time, just copy it to that directory and activate it from the Plugin administration menu.