A tech writer learning to code
Starting with Ruby…
I finally did it: I took the plunge into the world of software development and engineering.
I started my tech writing career 6 years ago documenting software user interfaces and creating video tutorials (and still do… yes that is my voice!), and slowly moved into documenting APIs and code. But with the latter I became more of a “transcriber” for software engineers than an actual creator of content; and in many cases, more of a burden to developers when we needed documentation, than a service to them to save time.
For a tech writer, learning programming languages opens up an entire new world of possibilities and career paths.
I tried a few free online courses for JavaScript, but never had the determination or perseverance to push myself through the curriculums when they became more abstract. As a former teacher (I taught Middle School English for 4 years on the Lower East Side of Manhattan), I realized I needed a more structured and supported education if I were to ever make software development a reality.
So I applied to Flatiron School when I saw it listed on the Linkedin profile of a phenomenal Product Manager I met. It’s part time online classes, and online educational coaching and teaching have been exactly what I needed. The first 2 months we’ve learned Ruby, and this blog post is about my first Ruby project: a command line interface (CLI) application that makes API calls and gives the user multiple options to input and receive information.
My project
You can find my project here: https://github.com/scottjordanswimming/watch-your-favorite-games-cli-gem — This app:
- Lets a user see a list of the 25 most popular games being played right now
- Let’s them choose one of the 25 games to watch live on their computer, and automatically opens a live version of that game in their browser, from www.twitch.com
- And if they like the person who’s streaming the game, they can choose to get a list of that streamer’s 5 most popular videos they’ve made .
My journey building it
I’ve found it difficult to balance learning Ruby with maintaining good performance with my full time job. In fact, as I write this blog post on the final day of the project, there are still 6 labs in the Ruby curriculum that I haven’t completed! And that’s why I felt fortunate to have worked with APIs as a tech writer, so the concept of an API and REST were something I didn’t have to spend much time understanding or practicing.
My first step was to search for a Ruby Gem that built a skeleton of a CLI app for me, which I found quickly: this gem called ZERP.
My next major step was to get my application working. I determined my app would need to make 3 separate API calls to the Twitch API, so I started there. I used Postman to test my API cURL commands, and tweaked them until I was receiving the data I needed. Then I found an online cURL to Ruby converter, which turned my API calls into Ruby code (a hack, I know, but I did learn how the code worked later on).

Next I parsed the API responses using the array and hash manipulation skills I learned in the Flatiron courses, and stored the information in global variables (a global array, which I knew was generally bad practice, but I just wanted to get it working!).
Next I had to figure out how to get user input from the command line, so I referred back to a tic tac toe lab in the Flatiron curriculum I completed a few weeks ago, so I could remember the specific line of code that prompts and gets user input, “gets.chomp”.
I was surprised how quickly I actually got my program to work: it was one incredibly unorganized file that was almost impossible to follow! On top of that, instead of coming up with good variable names I just went down the alphabet, and named my variables starting with a, b, c, d…
After meeting with my cohort lead (what Flatiron calls our main teacher), it became clear to me that I would need to refactor my code to follow more object oriented principles. The concept seemed simple to me, but I knew I was going to struggle a bit with communicating and passing information between Ruby Classes and files (not coincidentally the concepts I found most difficult during the coursework).
Learning from a pro
I‘m fortunate to have a very talented friend who recently build his own Chrome Extension called Full Page Screen Capture, with almost 40,000 downloads at the time of this publication. He was just releasing his premium version of the extension, and needed a video tutorial to advertise and educate the new features he built. In return for creating the video tutorial for him, my friend promised me “a coding lesson” in return.
Knowing that I needed to refactor my code into appropriate classes and objects, I thought now was a perfect time to show him my application and learn from a master.
His lesson wasn’t what I thought it was going to be, and was in fact far more valuable than I could have imagined. As my friend worked with me through my code, we largely spent our time on figuring out how to test the code at specific lines interactively using IRB. This was surprising to me.
While I had learned how to use “pry”, “REPL”, and “IRB” (and use it often I did), it was enlightening for me to see a veteran software engineer using it at almost every turn. I guess I thought that testing every line of my code initially would be too time consuming and redundant. And so I was too often trying to guess at code, hope it would work, run the program, and debug later.
Learning the value of efficiently and frequently testing code allowed me to finish up the project very efficiently.
Finishing the project
I successfully refactored my code into several objects, and stored information in their appropriate classes. I was happy to finally understand how classes communicate with each other, a concept I was struggling with during the curriculum, perhaps because I wasn’t applying it to a real world application, which this project allowed me to do.
