The Difference between Quitting and Giving Up

[Image omitted: liam-macleod-1357579-unsplash]

Photo by Liam Macleod on Unsplash

I’m usually really bad at quitting things. Once I’ve gotten into something deep, it’s hard to stop it; even if I really don’t like it or it otherwise isn’t giving me value. I just hate the idea of giving up on something.

Part of this probably has to do with the fact that, when I was younger, I had the exact opposite problem. I was giving up on things left and right. I would think of a new great idea for a website, or a project, or a book, get really excited, work on it for about 2 weeks, and then hit a wall. And then never came back from that wall. Repeat ad nauseum.

For veteran readers of the blog, this might sound familiar. It’s something I brought up in my final post on the #100DaysofCode challenge. In the post, I make a promise to myself to continue climbing even when I’ve hit that wall. And while I’ve done pretty good at continuing to hit on things now, I’m starting to wonder; is there anything that you should give up on? And if so, how do you figure out what it is?

About two months ago I read Seth Godin’s The Dip, which I would say touches on this subject better than anything I’ve previously read (it’s also only around 80 pages). Godin essentially fully describes this sort of wall idea that I mentioned in the 100DaysofCode, and gives some outlines on how to tell the difference between quitting for a good reason and quitting for a bad reason. I’ve decided to take a bit of a spin on these ideas and write out what I think are the key principles to think about:

Does this project give me joy?

As a good rule of thumb, Marie-Kondoing your project list will work pretty well. Now, there are a few exceptions to this rule (we’ll discuss them in the next point) but overall if over the full scope of the project you can’t think of a single redeeming feature about it that gives you confidence or excitement, then its pretty easy to see that its probably not worth it. This is the heuristic I probably use most often, although it does need to be used with restraint; just because something does not give you immediate satisfaction does not mean it is worthless in the long term.

What am I currently getting out of this project? What will I get when this project is completed?

Opportunity cost is also a pretty good heuristic for deciding whether something is worth it or not. To gauge opportunity cost, you’d have to look at both short term prospects and long term prospects to decide whether something is good. If something has only a few short-term rewards but many long-term rewards, then it’s a good investment. If there’s no short-term rewards and only a few long-term rewards, then you may want to at least consider other options. This is where the exception from earlier comes into play; something might not necessarily bring joy, but still give you better prospects if you complete it. Sometimes, if the rewards are high enough, I can understand slumping through a project at least temporarily to get into a better position later.

Will this project help me achieve my long-term goals?

Always focus with the end in mind. Not every single one of your current projects will involve one of your long-term goals (at least not obviously) but you should always make sure that the path you’re going down currently will at least lead you into hitting those markers. Don’t have long-term goals? Then make some, and follow them. Long-term goals have been the de-facto best way I have made sure to stay consistently on track, and I’ll probably continue to consistently refine it into the future.

[Image omitted]