Coding is a marathon of sprints

Coding is a marathon of sprints

Coding a new feature is like running a marathon by doing a lot of short sprints.

The mistake we as developers often make is trying to achieve too much in one go. We try to complete all the work in the spec in one go, i.e. we disappear into a dark hole and only resurface once we are done. There is several reasons why this is a bad idea.

  • Only revealing what you have worked on when it is done means you cannot incorporate any feedback into your work while you code, which in turn means you will be re-doing a lot of it.
  • The longer you wait to release code the higher the chance that something external has changed that will result in you having to change some of what you have done.
  • Working in isolation means no collaboration, which in turn reduces innovation.

The best way to go is to release lots of small incremental changes (the sprint) instead of going all the way (the marathon) before releasing the code. This way you get feedback quickly, and should you be going off track you can get on the right patch quickly.

Divide your task into small chunks, and do these one at a time. Not only will you be able to better measure progress, but you will be able to collaborate much better, and the instant feedback will result in a much better result. This approach will also make it much easier for the person having to review, merge and release your code into the bigger product set.

Leave a Reply