Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It seems plausible that programming while tired doesn't do a whole lot of damage in itself (more than the usual amount of bugs), provided that you also write unit tests and do code review. This could include self-review: that is, don't check in while tired, and read it over the next morning.

On the other hand, the shortcuts people take while under deadline pressure seem more damaging, and people are more likely to work longer hours when under time pressure. And the cumulative effects of working while tired might result in worse results the next day, even if a single day doesn't do it.

But I'm just speculating. It would be interesting to see a study that tries to distinguish between these different effects.



> provided that you also write unit tests and do code review

Not necessarily. Imagine submitting a patch on 8 PM, when everyone has already been in the office for 10 hours. It has a glaring bug in a particular branch that's not covered by the unit tests in a way that coverage testing doesn't show, yet everyone is too tired to see that bug. Thus the patch gets greenlit and applied to production. Just as everyone is heading home to fall into bed, pagers start ringing because prod is on fire.


> It seems plausible that programming while tired doesn't do a whole lot of damage in itself (more than the usual amount of bugs)

I can tell you in embedded devices that simply isn't true.

In a lot of embedded programming, you can cause real damage--short out boards, crash equipment, etc.

If I have been at something for too many hours, I may simply stop. I will certainly stop if I recognize that I just did something really boneheaded and simple. That means that I'm likely to continue doing boneheaded things and cause real damage.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: