One of the most effective ways to keep programmers productive is to tell them to write reviews of their work. The idea behind the review is that programmer knows that he must write it and give it to his manager and there should be a list of tangible results. If he won’t write it it will be the same thing as if he wrote an empty review. When he just imagines how he comes to his manager and says “I’ve done nothing, sorry” heart begins to beat faster. And this means that he will strive to accomplish some noticable tasks thus making visible progress on the project.

The pitfall here is reviews frequency. Beweekly or monthly reviews are not quite effective because there is enough time to defer some tasks closer to the review date and there are weekends in between so it’s tempting to think of them as of extra work time. Daily reviews do more harm than good: the problem is that there is no time reserve so the programmer can manage self. There is a feeling of being instantly watched, there is fear that if you’ll encounter a bug and it will be tough and you won’t fix it within a day you’ll have to say that you did nothing. Daily reviews are very stressful and demotivating so you’d better off doing them.

The best time span for review is a week. There is enough time to achieve something more or less significant and recover from unforeseen obstacles. The best time to send review is a Friday – there is no weekend time that may be used for work.