Early on in my career as a budding programmer, I would write pages and pages of code before ever trying it out (aka compiling or running).
This was totally wrong. I wish I could tell my younger self what I now know is the right way to approach any program.
Avi, our head instructor at Flatiron School, has repeated this mantra to us:
“Make it run, make it right, make it fast.”
Order of Events
First, you should make your program run. After that, you can refactor it using built-in, human-readable Ruby methods like
.reject. Then once all of that refactored code works, find ways to make it run faster.
Experts always tell us that the first thing you should do when approaching any complex task is to break it down into smaller, manageable pieces.
Avi would probably add this one piece of advice to that (forgive me for paraphrasing this, Avi):
What’s the simplest piece of code we can write? Let’s write that first. We need some immediate feedback from the computer.
Practice what we preach
On day 8, our class was presented with what seemed like an impossible challenge at the time:
- Parse the Reddit API
- Filter out only SFW (Suitable For Work) posts
- Output a new HTML page with the title, link, picture (if one is available), up votes, down votes
The Reddit API is monstrous piece of data. At this stage in our work, here’s what we should/shouldn’t be thinking:
Yes, Think This
- .json to hash
- print hash to stdout
- ask the hash questions like
No, Forget That
- ensuring we use the best possible hash converter
- optimizing for HTML5
- iterate through hash (save that for later!)
That last part “iterate through hash” is important. Why do we need to forget it (and save it for later)?
Answer: Did you see that API? We don’t even know what we’re going to iterate on yet! First, let’s figure out where our desired data lives. Our iteration will likely take place in that data’s parent (or maybe a little higher).
Our team’s result, while the work of Ruby amateurs, nonetheless runs and meets the requirements.