On Programming Alone

Often we developers find ourselves working on projects as the only programmers. It may be a personal project or a company with enough work for only one. Such work often present challenges in way of responsibility and advantages like control and intimate knowledge of the system. In response to the challenges of programming alone, I have come up with the 5 rules that keep me and my work sane:

1. Care for the project

You are the only programmer, you must care for the code for, if you don’t, no one else will.

2. Offload onto others

Since you’re the only programmer, you should focus on the programming. All non-programming tasks should be passed onto other people:

• Writing: have the editorial team, the client or a freelance writer take care of the copy
• Graphics: this one always takes up my time. Ultimately, it is much easier to approach a designer and have them take care of the graphics than to try and do it yourself
• Testing: in testing, find people with vested interest in the project to do the testing. You can also hire work on Craigslist or, if you’re lucky to have a fan base, release a private beta.

3. Use tools you find enjoyable

If you cannot enjoy yourself, you may do poorly. This is especially true when coding alone when there is no person, who would understand your cryptic ranting, to share your angst with.

What gives me joy is working with modern frameworks (CakePHP, Django, MooTools) or by building interactive JavaScript widget.

4. Write good comments

If your project becomes successful, your code will be worked on by others. To help any future coder decipher your work, write good comments to describe it. Be concise. There may no be time to write unit tests when you’re alone, but good comments take little effort and go a long way in determining whether a function or a block of code works as intended. Here is an example of a comment:

/**
 * Function returns the latest articles.
 *
 * The returned articles are ordered by their published
 * date in descending order. If $public is true, only
 * articles accessible to the public are returned.
 *
 * The number of articles returned is determined by the
 * ARTICLES_LATEST_COUNT constant.
 *
 * @access public
 * @param boolean $public Flag to return only public articles
 * @return array Latest articles.
 */
function latest_articles($public = true) {
    $articles = array();
    // retrieves the request's language
    // TODO: replace this with a function call (e.g. userlang())
    $language = LANG;
    ...
    return $articles;
}

The above example uses the standard PHPDoc commenting style. Note how it also has a TODO item that is picked up by the Eclipse editor and informs future readers of unfinished work.

5. Refactor your code

This last point is one I follow religiously. Refactoring is your best friend. As you expand the completed featureset, you may end up with code that duplicates in functionality. There may also come a time when you will need to alter this duplicated functionality (say, add an extra condition to all queries searching for a type of article). Altering, in this case, is time-consuming and prone to errors. My least favorite type of duplication is HTML that is copy-pasted from template to template. At some point, the design changes and every template must be updated.

If you group all common functionality into a single place, the amount of work and the volatility of your work will be minimized.

I cannot stress enough the value of well refactored code. It’s also easy to do: when writing a function that uses part of another or when rewriting the same html/sql sequence, take that logic, markup or statement and wrap it in a function. A good example is the common a() function that ends up in many of my projects:

/**
 * Returns an anchor for a given URL.
 *
 * The inner content is $content and additional
 * attributes are specified in $attr.
 *
 * @param string $url The path
 * @param string $content The inner content
 * @param array $attr Anchor attributes
 * @return string Anchor HTML
 */
function a($url, $content, $attr = array()) {
   // ...
   return $html;
}
 
echo a('/blog', 'Blog', array('class' => 'menu-item'));

As the project evolves, this a() function will see additional rules that will cascade down to every anchor on the site. Then, as other HTML-generating functions are added (e.g. select($name, $options, $selected, $attr)), they will share the $attr parameter. At this point, I will add a function called attrtostr($attr) and used in every HTML- and XML-generating code.

Working solo

These 5 points helped me get through several projects where there were no other programmers on the team.

Have you worked as the only programmer on a team? What was it like?