Course Report Podcast


While reseaching the numerous code schools in New York and deciding which ones I’d like to apply to, I have found Course Report articles and reviews very helpful. Yesterday, I discovered that they also launched a monthly podcast with updates about bootcamps, such as new schools opening and articles published about code school outcomes.

Podcasts are my favorite way to consume news (I listen to them while I make beaded jewelry for my Etsy shop,) so I’ve already blown through the May and June episodes, and plan to listen to the latest episode, July 2016, later today.

I like that the podcast gives a bird’s eye view of the ever-changing code bootcamp landscape. Before finding this podcast, I found it difficult to stay on top of bootcamp news while I focus in on my own learning and preparations. These brief (15-20 minute) episodes summarize relevant information effectively.

Beading and podcast-listening



My Strategies for Learning to Code

When I first started learning to code, I didn’t have much of a strategy. I floated between podcasts, Codecademy, and talking to my friends who worked in the industry. It wasn’t a bad approach, but after taking a few months to learn some basics and look into code bootcamps, I started developing a more organized strategy.

Often, I have felt adrift in my learning process–not sure of what is most important and what I might be missing completely. But lately, I’ve been getting glimpses of the big picture: what code bootcamp will be like, and more distantly, what working as a programmer will be like. That’s given me some confidence in my approach and helped me use my time more productively.

Here are the strategies for learning to code and preparing for bootcamp admissions that have worked best for me:

  • Using a variety of learning tools to find the ones that work best for me (and to switch between when I need a change in scenery.) I’ve used W3Schools, Codecademy, Udacity, Codewars, Coderbyte, Codefights, and Flatiron’s free lessons on, as well as podcasts, blogs, and Twitter.
  • Taking notes on anything that may be useful in the future. I created a .txt document so that I can easily add and search for bits of code. I also define terms, summarize concepts, and paste in websites that I may need to refer back to.
  • Being open to both long and short study sessions. Sometimes, I can get wrapped up in involving code challenges for a couple hours without noticing the time pass, but for tasks that I’m dreading, it’s tough to get motivated to push through them. I try to set aside 20-30 minutes to chip away at tricky or otherwise untempting tasks.
  • Identify recurring concepts and mastering them. Recently, I created a 24 problem “quiz” for myself that covered concepts, such as recursion, that I had encountered but not fully mastered. With help from Google, I solved (and then re-solved) the problems until the solutions came easily to me.
  • Trying to finish a study session on a high note; it’s a morale boost that makes it easier to get back to work later. (That said, if I get stuck on a problem that seems unsolvable, I take a break from it. More than once, I have returned to a coding challenge with fresh eyes and quickly noticed an easily fixable mistake.)

Using Terminal and GitHub

I’ve dipped a toe in the world of GitHub and Terminal over the past few weeks. I’m still getting a grasp of how to use them, but here are the basics I’ve figured out so far.

A computer terminal is used to enter data. The Terminal app on my Mac opens to a shell (on Mac known as Bash) where I can type command lines. According to this handy MacWorld article, “a command has three elements to it; the command itself, which calls a specific tool, an option which modifies the command’s output, and an argument, which calls the resource on which the command will operate.”

I can manipulate where the command is executed by changing or adding directories. (“cd /Users/rachel/homework” changes directory to this preexisting directory, for example. I can see which directory I’m in by entering “pwd.”)

Changes made in Terminal to a forked project from GitHub can be uploaded back into GitHub (after doing Git add and Git commit in terminal), and a pull request can be submitted. A pull request notifies others working on the project of my changes, so they can review and choose to add.