Great programmers and great chefs

A great chef can take the most basic ingredients and turn them into a lovely dish. A bad chef can take lobsters, mix them with nectarines and produce a horrorful dish. You have also chefs that make too complex food (e.g. using too many ingredients) or chefs that are dirty and don't create presentable food, but are really good at mixing flavours together.

Some of the properties of great chefs:

  • their food tastes really good
  • they can cope with deadlines and stress
  • their food is presentable
  • they keep it simple

While watching Ramsey's Kitchen Nightmares I have found out that the chef analogy can be applied to programmers as well. Programmers take some ingredients (languages, tools, libraries) and produce a dish (a product). Some examples:

  • The dish tastes really good, but the presentation is horroful => The product functions properly, but the implementation is horroful
  • The ingredients used for the dish are bad => The language/libraries used for a software product are crappy
  • The chef has used 20 ingredients in a dish that could have been made with 4 => The programmer has re-implemented a part where he could have used a library
  • The chef spends too much on presentation and too little time on cooking => The programmer spends too much time on making code look good, and little time on functionality

This analogy can be seen in some popular software projects:

  • Facebook: They have taken the most basic ingredients (PHP+MySQL) and have scaled that to millions of users. They are great chefs, but their ingredients suck
  • Universal feed parser: Created by Mark Pilgrim (Google employee) this dish is a hack-fest (one file with 3000 lines of code). The functionality is pretty good. This is an example of a talented chef with bad habits and messy presentation
  • Django: Lovely code, documentation and presentation
  • etc. etc.

I have looked at a lot of code in different languages and I know good code when I see it. When I look at my own code I see great functionality and simplification, but it's missing the last presentation touch and sometimes I am keen on doing it hacky style.

To become better I have looked at what other great programmers are doing and here is what I have concluded:

  • they implement things as simple as possible, but not simpler
  • they use idioms of a language (i.e. in Python you code like a Python programmer and not like a Java programmer)
  • they are consistent throughout their code (i.e. they use one naming convention etc.)
  • their code structure is really good (not everything is placed in one file :))
  • they add comments where comments are necessary
  • they finish their work on time and implement the products they start
  • they produce software with very high cohesion and low coupling

The good code

I really like how Django is coded (I don't personally use Django). Looking through their code you'll notice cleanness, structure, comments and really good code smell.

The bad code

Wick is auto completion for JavaScript. The functionality is good, but their code and code smell is something taken from a programming horror movie.

One of the functions look like this:

function smartInputMatch(cleanValue, value) {
	this.cleanValue = cleanValue;
	this.value = value;
	this.isSelected = false;
}//smartInputMatch

Another function looks like this:

function registerSmartInputListeners() {
inputs = document.getElementsByTagName("input");
texts = document.getElementsByTagName("textarea");
allinputs = new Array();
z = 0;
y = 0;
while(inputs[z]) {
allinputs[z] = inputs[z];
z++;
}//
while(texts[y]) {
allinputs[z] = texts[y];
z++;
y++;
}//

Global scope is totally polluted and only global variables are used.

Here is a clean rewrite (like in design, white space can do wonders to the code):

function registerSmartInputListeners() {
    var inputs = document.getElementsByTagName("input");
    var texts = document.getElementsByTagName("textarea");
    allinputs = [];
    var z = 0, y = 0;

    while(inputs[z]) {
        allinputs[z] = inputs[z];
        z++;
    }

    while(texts[y]) {
        allinputs[z] = texts[y];
        z++;
        y++;
    }
}

This can be done even better by using proper ingredients:

function registerSmartInputListeners() {
    allinputs = flattenList(
        $bytc('input', 'wickEnabled'),
        $bytc('textarea', 'wickEnabled')
    );
}

flattenList, $bytc (by tag and class) are from AJS.

Final words

I have looked through my code and I can clearly see what I need to improve to become a better chef - and who knows, maybe a great chef one day :)

Code · Tips 13. Jul 2008
3 comments so far

Great Tips Amix:)
Yep. Prorammers and Cheves are the same in many areas. However, in spite of cheves, programmes can complete and conclude thier works ....

Thanks, Amir. Just this weekend I uploaded a (partial) port of the unofficial Plurk API to Python. It was a late-night project, and it shows.

A reminder like this gives strong incentive to refactor the code and to correctly comment it.

@David:
Nice to hear :)

I would say that re-factoring code is pretty important and one can learn so many things by doing this. But it's tiresome and bug prone, especially if you refactor large chunks of code.

I would not recommend re-factoring big projects, I have tried this a couple of times with Skeletonz and it's just really tiring.

Post a comment
Commenting on this post has expired.
© 2000-2009 amix. Powered by Skeletonz.