This is my latest code review project. The coding program I am going through, Epicodus, is modeled after a software development company rather than a school. That means that instead of lectures and classes and homework, the emphasis is heavily on time with hands on the keyboard. Each day we pair up with a different peer and “pair code”—work through a coding exercise together, switching off typing code and proofreading for errors. Every Friday, we work alone on a project from 8am to 5pm, and we are not given the prompt ahead of time.
This prompt was called Mr. Roboger’s Neighborhood. The challenge was to take a number from user input, and return to that user all the numbers from 0 to the user input number, with some numbers substituted with words based on the presence of certain digits in the numbers.
This code review project came after a week of learning about creating arrays in JavaScript, manipulating those arrays, and creating looped functions through arrays. The curriculum always includes skills that are relevant to working in the software industry but are a little outside of core coding skills. This week that involved writing plain-English tests for each step of our code writing process in order to prepare us for adding automated code testing to our projects in a few weeks. I found it really frustrating to stick to that focused, incremental way of working. If I have to code a, b, and c, I generally code most of a before going on to b, writing a very specific part of c, then coming back to finish a, which broke b, etc. I can feel that once I get used to the mental discipline of working in test-driven steps, I will start making rapid progress and spending less time tracking down spelling and syntax errors in my code.
Completing the actual project went really smoothly for me. On Friday morning, I read over the specs for the project, then walked over to the kitchen to make a French press. While I was staring at the water, waiting for it to boil, the basic path toward completing the project just bubbled up from my subconscious. When it came time to actually write it, it turned out to take way more individual steps to manipulate the input than I first anticipated. I also really struggled to keep my work adhering to the test-driven development principles. I made a lot of progress in the morning, and just before lunch I realized I hadn’t documented any tests and had to try and fill in testing for code I already wrote.
I had the most fun stying the page in the afternoon, after I got the functionality of the project working. I knew right away that I wanted to evoke an old-school monochrome green monitor. I first tried to align the page the way I wanted using the Bootstrap framework that we use as a starting place for most of our projects, but that wasn’t working for me and I ended up styling the whole page in custom CSS. I wanted to transform a picture of Mr. Rogers into green monochrome, but that ended up being a little beyond my skill. I was playing around with the image in GIMP and more or less stumbled across the color distorting effect that made it to the final project. It reminded me of both old school computers and was also a little psychedelic, so I couldn’t resist including it. I also had a lot of fun using the voice reader feature built into most modern browsers. That took the last hour and a half of the day. It wasn’t necessary and using that API was way outside my grasp, but the emotional payoff when it started speaking was the high point of the day.
I’m excited for what’s coming next time. This week we learned how to create our own JavaScript object constructors and prototypes, and if I had learned that technique my code for this project could have been much smaller. I also can’t wait to get skilled enough to understand how, exactly, to manipulate the screen reader to use different voices, pitches, and reading speeds.
If you’d like to view the code for this project, it lives in this Github repository.