Increasingly, as I pursue my creative endeavors, I run up against a wall that my younger self could have never foreseen, or would have have actively rejected the idea of. I realize that, to better express myself, I need technical skills. And I don’t mean technical drawing skills or technical writing skills. Those are very helpful, in their way, but I mean technical in the very modern, computer-centric sense.
I need to be able to make these dumb metal boxes do exactly what I want.
To that end, I registered for a 15-week intensive course called Anyone Can Learn to Code. While I certainly find the name to be encouraging, it was the firsthand testimony of a friend who had recently taken the course that convinced me to sign up. The course involves three weeks of pre-work and 12 weeks of intensive classroom time, learning and building. The goal is to design a capstone project, something to show employers. To a similar end, the instructor, Jay Wengrow, recommended blogging about one’s progress, making notes of all the things you learn on any given day.
What I Learned Today
Not knowing that it would be part of the pre-work eventually, I watched the first eight screencasts on Jay’s website and did the associated exercises back in February. Today, though, I decided to do it all again as a refresher. This was surprisingly frustrating.
- Introduction to and installation of Ruby, Rails, and associated languages on my PC
- Objects and Classes
The challenges: Interestingly, the two exercises which drove me bonkers were associated with screencast 3 (identifying the Class of certain things) and screencast 7 (creating a quiz using Conditionals). My frustration with screencast 3’s exercise was more one of taxonomy than execution. I must have second guesses whether “hello”.class was considered a String because it returned the answer String or a Method because it executes a Method like a dozen times. Eventually, I just decided to move on, since I couldn’t find any resource clearly, simply laying it out. Programmers should perhaps look to biologists when cataloging the various linguistic species in the wild world of coding.
Screencast 7 was a different story. When employing a conditional statement, the program kept spitting out an error that made absolutely no sense to me. If I interpreted it right, it wanted me to change every single one of my “elsif” keywords to an “end.” No matter how I cut, pasted, added or subracted ends, or swore, nothing worked. Eventually I decided to see if the issue had something to do with real estate (i.e., the code just didn’t like where I had put my Conditional.) I couched the whole thing inside a method, and then called method. That seemed to soothe the savage beast. Why did this go wrong? I have no idea. But at least I have a strategy for testing it now.
The successes: For each of the tiny programs I built today, I decided to do the hardest thing I could think of, while trying to keep the code as straightforward as possible and without deviating from the intent of the exercise. I made some stuff I was reasonably pleased with, and it felt like shaking my brain awake, in some regards.
When my seemingly simple Conditional would not work, I turned in desperation to my long-time work friend: the chat client. I tried to track down people who might be able to lend me a hand. Ultimately, I got in touch with my friend who graduated from ACLTC, but not until after the situation had resolved itself. He had a good laugh at my predicament, and then said, “I hope you like feeling that way.”
Learning to code is like one of those newfangled room escape games. You’re trapped in the dark, up against a clock, and the challenge is to find your way out. My lesson today is to embrace the frustration. Learn to see a puzzle for what it is: a puzzle. And puzzles are fun!