I decided to start the “My Programming Lessons” series with a lesson I don’t consider the most important but still important enough.
Learning when to quit programming is hard. You have a deadline, you’re stressed and things aren’t going well – maybe the compiler complains about something you don’t understand or maybe the program doesn’t print “hello” even though that’s the first line being executed (or so you believe). This is the exact time you should let everything go and simply head home to rest.
You should let go because when you’re in this state you’re probably more destructive than constructive. The next day, if you’re like me and you re-examine your code often, you’ll probably replace all the crappy code you wrote with smaller, better code that will work first time around. And that’s the good scenario. The bad scenario is that you’ll keep trying to rework that crappy code until it seems to work and this almost always means a bug is hiding in there somewhere.
It takes some insight to learn when the right time to quit is. For me, now that I have a few years of programming experience, I usually know when to quit before I’m destructive. If this time of the day arrived and I still feel like I have to work, I usually do other (not as critical) work like documentation.