CS50: Introduction & Problem Set 1
I discovered CS50 which is a free, 11-week computer science course provided by Harvard. It gives you a video lecture for each week, problem sets and some tools you need in order to understand wtf is going on. It starts off going over bits, binary, some low-level coverage of assembly language, and some other important stuff that has left my brain buzzing from over-stimulation.
I want to document my experience as a way to track my progress but also to show other newbies that it’s okay to feel like an idiot with this stuff (as a compulsive perfectionist and competitive freak, I’m still trying to convince myself of the latter). The only way I’m going to get through this is with:
- gifs (saying that with a hard ‘g’)
- puppy snuggles from my dog
- and most importantly, help from my real-life programming friends (thank you for your patience)
So, let’s get started!
There are 5 individual exercises for the first problem set (this includes more advanced exercises for those who are more comfortable with programming and/or have something to prove to the rest of society). I’ll talk about the one that made me feel like, Maybe I can actually do this!
Greedy: “Implement a program that calculates the minimum number of coins required to give a user change.”
If we’re speaking in terms of Spore, I’m still in the cell phase of my programming knowledge. If there was a level before cell phase, I would actually probably be in that. I have no idea what’s going on, so the best I can do at this point is to think about the problem in its real-world application.
Someone, for some reason needs only coins for a given amount. “Hey, I need $2.34 in coins ONLY. And give me the least amount of coins possible.”
I think about the given amount and validate that they haven’t given me a 0 or negative value.
“So, you’re requesting $2.34. Cool, let me get that for you.”
First, in the U.S. we have 4 coin types:
- Quarters ($0.25)
- Dimes ($0.10)
- Nickels ($0.05)
- and for some reason we still have Pennies ($0.o1)
In order to give them the least amount of coins possible for $2.34, I need to figure out how many times these values can divide into $2.34. This means I need to divide the input with the first largest coin amount ($0.25), leaving me with a remainder. Then, I’ll take that remainder and divide it with the next largest coin value ($0.10)to get another remainder. This happens until you’re no longer left with a remaining value.
But dividing with decimals is a complete mess and I hate it. It’s much easier for my brain to think about whole numbers rather than with the hated decimal value. So, by taking the coin and input amounts, multiplying them by 1oo, I’m now working with whole numbers. $2.34 becomes 234, $0.25 becomes 25, and so on.
So, now that I have the exact amount of coins, I return the amount to the person obsessed with getting change.
I’ve got a feeling that this isn’t the most sophisticated solution available, but I can’t believe I found a solution at all without help.
- I started with what made sense to me (real-world application and solution)
- I tried not to concern myself with writing the most sophisticated program, I found out what worked and later trimmed fat
- When I finished, I looked at other people’s solutions to see what I could have done to make it better
This isn’t the most life-altering program ever written, or even the 2,000,000th most interesting. But it was still difficult enough for me to second-guess my ability to be a functioning member of the human race.
The only way I can describe my relationship with programming so far is trying to go from living in a 4-dimensional world to living in a 4D world and perceiving it from a 1-dimensional perspective. The most challenging obstacle for me in all this is just how long it takes to be an independent programmer. I haven’t quite wrapped my head around the fact that programming isn’t supposed to be something you can just pick up. The complete inability to quickly achieve perfection or see it on the horizon is really difficult for a perfectionist.
One major thing I’ve learned with this lecture and problem set is this: taking problems and translating them into stupid simple terms, without overcomplicating them, is one of the most important but difficult skills (maybe in life). Having the ability to break down a problem in its most basic form and thinking about it both strategically and tactically is incredibly valuable to me as a UX designer. Even if I don’t make a full go at programming, it’s teaching me how to be a better designer and problem solver.
I’m still scared when I approach new problem sets because I don’t know where to start, but at least I conquered this one.