Warning
This book is new. If you'd like to go through it, then join the Learn Code Forum to get help while you attempt it. I'm also looking for feedback on the difficulty of the projects. If you don't like public forums, then email help@learncodethehardway.org to talk privately.
Part II: Quick Hacks
You've got the best idea ever. You're going to impress the world! You'll be a billionaire! Your brain is enflamed with the concept and you see it in your dreams haunting you like a Yurei. The next step is to make it real, to implement it and bring it out of your brain and into the computer. You have to kill the ghost, bring the Yurei back from the spirit world and bind it to a totem of Python and sticks that you throw into the sea of the internet.
Creative enough for you?
The enemy of creativity is the start. How can you realize your dreams if there's an obstacle course of setup procedures and dead yaks in the way? What if your idea is so intense and so big that you begin to worry? Will you be good enough? Will you be smart enough? Will that famous programmer who always yells at you to write your tests first be angry that you don't know how to do it? Getting started is universally one of the most difficult things in creativity, and this part of the book is designed to get you past that.
I am a painter, a musician, a writer, and a programmer so I know a thing or two about creativity. I know even more about getting started and about process. Process is what drags me through the muddy slog of a project when I'm just not interested in working on it anymore. But, I can't get to that slog without first getting started.
The start requires courage and a bit of not caring what anyone thinks. In painting, when I can't get started I just grab any random paint and smack it on the canvas in about the right spot. A whole lot of very accomplished painters work that way. Other painters get through the start by doing research--studying, testing, sketching and then finally pulling it all together to begin. As a writer, the first thing I do is walk around my apartment frantically talking to myself imagining I'm talking to someone, and then when I've said enough talking I sit down and write. I just write down the first things that come to mind.
I don't sit down to write and worry about grammar. I don't ask, "Do I sound smart?" I just write how I speak and flow it into the keyboard, and then when I'm done cranking out a few paragraphs I take a look. Does it make sense? Do I need to clean up? It works and this gets me flowing and going. Maybe what I write is total garbage. But, I started and that's what's important then. After this I rely on my process to turn the starting point into a fully baked word.
How do you learn your creative start? You, my friend, need to figure that out, and this book will help. First we need to bust your fear of the start. Maybe it's not even fear. Maybe you just have a metric ton of totally useless tasks you need to do before you begin coding and you've got to get the friction out of your way.
As I said in Part I, you can't be creative if every time you go to make a thing you have to clean up for an hour and fix a bunch of tools.
How To Practice Creativity
In this part of the book you will practice creativity by making yourself start right away and quickly. I'll give you simple little projects that are super boring. I mean, the cat command from Unix just spews out a file. That's honestly like two lines of Python as the simplest case. It's the start of these projects that matter, and you're going to be ruthless about getting going. You're going to sit down at your computer and jump off a cliff and make things happen. Now. Not after 30 minutes.
How do you do this? You need a checklist, and you need automation. The checklist is all the things you have to do to get ready to go. Turn on your computer, turn off social media, fire up your editor, touch your lucky rubber ducky, say a prayer to a deity, meditate for 10 minutes, and then copy your project skeleton over and go. That's an example, but you'll need a check list, and the shorter that checklist the bettter.
But you don't know what this checklist is yet. Maybe you have an idea, but do you really know all the things you do before you start working? That's what you'll focus on with each of these projects. In the first project, you'll sit down to attempt it, but you'll write down all the things you did. Can't manage what you can't measure, and this is your first step into measuring yourself to see how you do something. If you have screen recording software that would be even better. Turn that on and record yourself crank out a terrible piece of software, then watch the video. Write down what you did.
To make sure you don't slave away at the project rather than practice the start you're also going to set a strict timer on each project. You have to crank out the best piece of junk you can in 45 minutes. No more, no less. Set a 45 minute timer when you start, have your pad and pencil ready, and go. When the timer goes off you're done. Take a look at what you did, and then comes the good part.
After each project take your list and figure out what you can do to eliminate the friction. Do you sit there and make many little files that you have to look up on the internet? Make a project skeleton. Do you seem to have a problem typing commands at your text editor? Spend the time to learn to use it better, or learn to touch type. Do you flap around, not knowing basic commands and APIs? Get some books and study my friend.
Then erase your code and start over. Fresh. New pad of paper and begin to write. Or start recording. Whatever you have to do to track what you do. Did you get farther this time? Was there less friction? Your goal is to reduce the time between idea and implementation until the start is just a thing you do. Like eating and breathing. Eventually the start will feel natural and you can move on to the next project.
Remember that you are to sit down and code right away. Just go. If an internal voice tells you that you're doing it wrong, tell that stupid voice to shut its pedantic mouth. This is hacking. Keep it loose and pump it out like you're just blabbing the code out to a friend who knows you're kind of nuts but still fun. Pedantic things like testing and quality can come later in the book, but for now, just code. Make a mess and hack. It's fun. Getting the idea out is more important than winning an imaginary quality contest.
And after each sloppy 45 minute hack, you sit down and review how you did. This process of "create then critique" is what's going to help you improve in the future.
A Process For Early Coders
If you are just starting out and still completely lost when it comes to starting a project then I'm going to give you an abbreviated process to use to get you started. The exercise in this part is to hack for 45 minutes, but as an early programmer you may need a little more time or you may not know where to start. In this case, feel free to take 60 minutes or to use two 45 minute sessions to do each exercise.
For a process, an early programmer should do the following before every session (before you start the timer):
- Get your computer ready and make sure you are ready to go.
- Read the description of the task and write down notes. This is your research phase and you need to gather as much information as you can in written form.
- Take your research and turn it into a TODO list of what you need to do to implement the hack. Write down everything you can think of for the task. What files will you need to make? What directories? What features? What libraries will you use?
Once you have the TODO list you are ready to start the timer. During your hacking session you will then do this:
- Pick the first simplest task on your TODO and do it. Do you need a file? Make it! Do you need a directory? Make it!
- Check that what you just did works.
- Cross that task off and do the next one.
I am serious about this process. It's a smaller version of the one I use and it works. Nearly every process is simply "make a list, do it, check it." If it works for me it will work for you, so you should use it if you have no idea what to do.
An Early Coder's Coding Process
This process will also work for the code you write. I covered this in my first book Learn Python The Hard Way. When you are unsure how to write a piece of code follow this process:
- Write in plain English what your code should do. If you need to write it as a paragraph, then do it. If you can write it as a list of tasks, that's better. If you write a paragraph you'll then convert that to a list of things the code must do.
- Turn this list into comments by putting # in front of each line.
- Start at the top, and under each comment, write the Python code that makes it work. If the comment is too abstract then break it up into smaller comments and repeat this step.
- Run the code to make sure what you just wrote doesn't have syntax errors and will mostly work.
That's all you need to do. If you can say what you want the code to do in English (or any human language) then you'll be able to implement it easily and don't have to think in code. Eventually you won't need to write comments first and fill in the code, but when I'm stuck I do still this.