The Difference between Quitting and Giving Up

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.

Anyway, that’s all for this one. I do want to point out that we have a brand new newsletter! Following this will give you the low-down of all the new stuff I’m working on. Subscribe here!

Five Takeaways from #100DaysofCode


Photo by Luca Bravo on Unsplash. I don’t even use a Macbook. Also not sure if that code even does anything.

For the longest time, I’ve tried to code. From taking an AP Computer Science class in high school to trying to make a command line RPG in C++, I’ve always wanted to expand my knowledge of programming, understanding that it now plays a key role in our world. However, each time I’ve tried, I came out of the experience disappointed; continuing to see people discuss CS concepts that were far out of my league and witnessing people excel in the field ten times faster than I seemingly could have. So, when I found out about #100DaysofCode, I decided to take on the challenge with one simple objective: see what people are talking about, see what people find important today, and see what I want to know – then learn in that direction.

Today was my final day of the challenge. Overall, my experience was… mixed. However, I’ve found that I’ve learned a great amount – not just about coding, but also about learning principles and a few life principles as well. I’ve decided to use my last day of this challenge to write down five key takeaways I got from doing this challenge.

There’s a massive difference between learning to code and solving problems in code

This I think was my biggest mistake from earlier attempts, and I didn’t even realize it until halfway through the challenge. You can go through something like Codecademy or FreeCodeCamp tutorials, but all they really tell you is what you can do with a programming language. It teaches you semantics through a fairly trivial and easy set of problems – which definitely helps when you’re just trying to understand what you’re working with (and I think that’s the goal of these two sites), but they suck at teaching you how to code.

If you want to learn to code, you need to know how to use a programming language. HackerRank, LeetCode, and Project Euler are fantastic resources on this. If I could do it all again, I would say to spend the first one to two days learning about a language on Codecademy/FreeCodeCamp, and then spend the majority of the time practicing your knowledge through intuitive and challenging problems (and believe me, they are challenging).

Choose something and stick to it

I’m terrible at this. I really am. I’m currently reading six different books at once just because I get about 100 pages in to a book before I think “You know what? This book on AI is really fascinating, but tonight I’m feeling something more about design”. This escalates to a point where instead of reading 100 pages a day in one book, I’m reading like 10 pages from 10 different books and it totally stifles my progress.

A similar thing occurred while doing this challenge.

During my prepping for this challenge, I made an entire roadmap of different projects and courses I could do, when I’d start and end them, etc. I threw it out on the second day. From there, I went on to not finish things such as CS50, a Codecademy React course, FreeCodeCamp, and also Quantopian (to be fair, I plan on finishing that last one post-challenge). Now that I reflect on my completion of the challenge, I realize how much more I would have known by this point if I just stuck with my roadmap. My advice for the future: always use roadmaps. Design a path and stick to it. Don’t get distracted by the shiny things across the road; instead, if you must, save them for later.

An hour a day goes a long way

Not going to lie; I didn’t do the recommended one-hour session for #100DaysofCode every day. In fact, I did it very little. But the times that I took on the full hour, I realized just how powerful an hour of time is.

Optimally, you have about 16-17 hours in a day that you can fill up. One hour, in that respect, is a pretty small amount. However, one hour is also 60 minutes, or 3600 seconds; and that’s a surprisingly long amount of time. I try practicing piano for about an hour a day (well… tried). I played until my fingers got sore, and I got tired, so I got out the chair and checked the clock. Only 30 minutes had gone by. This happened a lot when I was doing the coding challenge as well – if you think you’ve “learned enough” within 30 minutes, that means that you’re learning 2x that much in an hour. Also think about how these hours increase over time – optimally, by the end of this challenge, you would have put in just north of 100 hours into coding. I have about 105 hours total in Guild Wars 2, and that’s felt like an eternity. Now imagine if I spent that time learning and practicing Python.

All coding languages can be very much the same (and very much different)

After doing this for 100 days, I feel certain of one thing: that all coding languages are pretty much the same thing. Just like real languages, they’re all an assortment of different ways of communicating the same thing.

However, just as Russian has almost 10x the amount of curse words as English, some languages have certain strengths for certain situations. You use SQL for databases. You use Assembly for low-level stuff. You use C# for software, and JS for web apps. However, the languages themselves typically stay the same; you can print, use for loops, make ints, etc etc. In this case, you only really need to learn one language; and then when you need to switch to another, you retain your knowledge and just uncover the small semantical differences (print vs printf, {} vs end, etc.).

Determination is one thing. Hard work is what counts.

And here I think is the probably my most important takeaway of the challenge – it’s that there’s a big difference between hard work and determination. To be completely honest with you, #100DaysofCode – for me at least – was less a challenge of coding and more a challenge of consistency. I don’t think I’ve ever done anything 100 days straight in my life. And even though I wouldn’t necessarily say I did the challenge for 100 days straight (there was a few hiccups here and there), I still completed the challenge, which is a big deal.

But as you can get from previous takeaways, there is still much to be desired.

Consistency is only half the battle.

I think I made good progress during this challenge, but let’s imagine the optimum path: if I had followed the roadmap, if I had done exact an hour a day, if I spent the majority of the time on solving problems, and if I had gone for 100 days straight rather than skipping a few here and there. I can imagine that, if this happened, my current knowledge of coding would be 10x what it is now.

Now, that’s not to say I think this challenge was a failure. At the end of the day, I’d say my coding experience with this challenge was much more positive than it has been in previous attempts. Focusing on my three views (what people talk about, what people find important, what I like) definitely helped me stay in the right direction. And now I know that I can apply these takeaways to future attempts at similar challenges, with which I know there are many coming… such as my next challenge, #30DayStartup, which I plan on beginning pretty soon (and also plan on documenting much more).

In the meantime, like share this post if you’ve found it relatable, or otherwise especially find it share-able. If you want to follow me on the next challenge, either follow this blog or my Twitter (@astukari) as I’ll be surely posting plenty of updates on both. ‘Til next time.