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.
Exercise 12: Review
The first stage of my methodic madness is complete for me but not for you. We are now going to review the strategy of this part of the book so you can continue to use it yourself in the future. The strategy is this:
- You need to work on that initial start to every project.
- To isolate this issue you sit down with a set of little projects you can do in 45 minutes. This focuses on the problem area of starting a project and lets you repeat that part of your process.
- As you work on these projects you identify possible causes of your problem starting a project. This can take the form of your computer setup, work environment, mental thought processes, or physical health. There are more, but those are the big possible causes.
- Once you've identified possible causes you work on eliminating or changing them within the small confines of your 45 minute hacks.
- Finally, you record and graph metrics to see if these possible changes are helping but also to make sure they aren't hurting your performance.
This doesn't need to be formal scientific process to be useful. All you need is to treat this as a journal that helps you objectively view how you work. If you're doing it right you'll run into surprising things that you hadn't thought of before. The collection of data forces you to explore new possibilities and expand what you think might be the cause of something.
Please remember that this personal metrics journal should not be shared with others, especially anyone in management. It is innevitable that managers will attempt to impose these metrics on you, and if they do, then you should flat refuse. These are your personal private notes, and nobody has a right to read them--much like a diary or your private email.
Exercise Challenge
The final exercise is for you to pick your favorite tool and to spend a series of 45 minute sessions refining it over the course of a week or more. Using everything that you've learned about yourself, take this project and start over from scratch to create something more solid. Still limit yourself to 45 minutes at a time, but don't treat this final project as a hack. Instead, it is the next step after a hack that you are working on.
After I'm done hacking on something real quick to test an idea, I will either delete it or clean it. If the hack is so completely disgusting that it should never see the light of day, then I delete it and redo it from a clean beginning. You won't forget the things you did and having to resolve them, but a focus on quality will help you do it cleaner. If the hack isn't so bad, then what I'll do is clean it up before expanding it.
One effective technique for turning a hack into something solid is to extract the key elements of the hack into a library with an automated test suite. This forces you to think about the code as something that will be used in other code. What I'll do is this:
- Go through the file and convert my "stream of consciousness hacking" into a set of functions.
- I'll then DRY (Don't Repeat Yourself) up the code a bit, making sure to remove repetition but not too much. Code with zero repetition is basically encrypted randomness.
- Once it's cleaned up and running the same as before but with functions, I pull those functions out into a module and make sure the original code keeps working. Remember, don't change things while you're cleaning up, just reorganize and fix it.
- After the code is moved and working again I sit down to write test cases that make sure they keep working for the future when I do start changing things.
For this exercise you'll take your favorite of the projects, and do this "officializing" process to it. Keep your time to 45 minutes at a time, and go through the above process to clean it up. It's fine to work more than 45 minutes that day, just be sure to take 15-30 minute breaks between each session. It's the same time frame except you're not hacking, you're getting serious.
Study Drills
- Compare your hack code to your official code. Did you find bugs by cleaning it up? Were there other improvements?
- If the hack and the cleaned code are nearly the same in behavior, then do you really need to clean up the hack? Why would you need to clean up a hack even if it is working just fine and is possibly simpler?
- Try a new command from your list of commands you run frequently (see Exercise 11), and try this entire process on it. Do a quick hack, then clean it up and make it official.
Further Study
Here is a list of other commands you should attempt doing replicas of in 45 minutes:
- ls
- rm
- rmdir
- mkdir
- cal
- tail
- yes
- false
Try implementing some of those.