Code And Cocktails

Learning When to Give Up

| Comments

“When you find yourself in a hole, quit digging” – Will Rogers

Sometimes I wonder what the important skills for a developer are. I now believe that one of the important ones (perhaps most important) is knowing how/when to give up and start again. This contradicts another important skill/trait for a developer to have: tenacity. But I think they are balancing forces with giving up being slightly more important. Let me explain.

Often when working on a problem, it takes longer; is more complicated and difficult than expected. At this point there are many files modified and it looks like there are many more to modify; plenty of broken tests, maybe an unknown quantity. There are two options: keep going, or give up.

This is the point I like to remind myself (and my coworkers) of Will Rogers quote. Another thing I do is ask “Are we digging a tunnel, or a hole?” If we think we are digging a tunnel then we can give ourself a time limit for further digging; if it pays off – great! otherwise we need to climb out of the hole.

I used to believe, quite strongly, that tenacity was more important. To persevere through the mountain of outstanding changes and get it done was admirable. I now believe that giving up is the better option. What changed my mind? I now see more benefit in taking the knowledge acquired from the work done and reapply it to the problem from a fresh start. Powering through the situation is deciding at the current way is the only way; starting again is deciding that there is a different way, with the knowledge that the current way has giving you (which is at least that the current way isn’t working out).

As a footnote I want to add that I also thinking giving up in another way is important. When working on something collaboratively (such as when pairing) one can find oneself at odds with another developer about how to proceed. I believe that unless the idea is very obviously bad that to stop arguing/discussing and do something is better that spending time discussing. Especially when there is source code involved - any code is better than no code. Any code, can then be changed into better code.