Skip to content

Instantly share code, notes, and snippets.

@ashishraste
Created October 12, 2016 10:12
Show Gist options
  • Select an option

  • Save ashishraste/24c2ee3c12f00b886afa92a465e3aff4 to your computer and use it in GitHub Desktop.

Select an option

Save ashishraste/24c2ee3c12f00b886afa92a465e3aff4 to your computer and use it in GitHub Desktop.
Design methodologies and tips to become a better programmer

The Joel Test


Listing out the points suiting to a single programmer.

  • Do you use source control?

    • There's a single script you can run that does a full checkout from scratch, rebuilds every line of code, makes the executables, in all their various versions, languages, creates the installation package, and creates the final media.
  • Can you make a build in one step?

  • Do you make daily builds?

    • On large teams, one good way to insure that breakages are fixed right away is to do the daily build every afternoon at, say, lunchtime. Everyone does as many checkins as possible before lunch. When they come back, the build is done. If it worked, great! Everybody checks out the latest version of the source and goes on working. If the build failed, you fix it, but everybody can keep on working with the pre-build, unbroken version of the source.
  • Do you have a bug database?

    • complete steps to reproduce the bug
    • expected behavior
    • observed (buggy) behavior
    • who it's assigned to
    • whether it has been fixed or not
  • Do you fix bugs before writing new code?

  • Do you have an up-to-date schedule?

    • The crucial thing about having a schedule is that it forces you to decide what features you are going to do, and then it forces you to pick the least important features and cut them rather than slipping into featuritis (a.k.a. scope creep).
  • Do you have a spec?

  • Do you use the best tools money can buy?


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment