This past week at gSchool, we had our first assessment. We were offered a problem, in this case, the building blocks of the Scrabble game, which included a short guide that informed us of some of the API decisions based on the expected input and output of the program, and we sat down with one of our three instructors for 40 minutes, while they watched and listened to us work through the problem.
As an exercise in Enumerators a few weeks ago, I took a similar look at the beginnings of the Scrabble exercise (counting word scores), so I did not spend too much time “preparing” for the assessment. I did not want to memorize how to solve the problem, because I wanted a raw feel to how my process works from my instructors’ perspective, so that I knew what I needed to work on improving.
Honestly, I was a little surprised by how it went. Although I got much further in solving the problem (with a little guidance in the right direction when I steered off course), my happiness with progress was not the purpose of the review. My reviewer pointed out that I had difficulties breaking down problems into their smaller pieces, and writing tests for these smaller pieces prior to attempting to solve the problem with code. I was using tests to verify my solutions as I busted through a problem, instead of using smaller tests along the way to drive the solutions.
I can memorize all the syntax out there, that has never been a problem for me. But can I use it efficiently and effectively? Not as well as I should. I was the student who shirked away from math courses, but loved science classes. I can tell you how many things work, recite hundreds of odd facts, but can I break down a logical pathway of WHY they work that way, and apply it to something else? Not always.
I thought I came to gSchool to learn Ruby best practices, learn agile and TDD, and make sure that I don’t get lost in the world of StackOverflow and Google when I get stuck. But really, what I’m starting to realize is that beyond those things, I came to gSchool to learn algorithmic thinking.
Learning to program is easy if you have a good foundation of algorithmic thinking, but this is something I never knew until this week. I had never heard the term until my assessment, and after the assessment, I wanted to do everything in my power to learn more about it, how to develop it, and find problems to practice.
My research on the matter leads me to conclude this:
- Repetition is how this skill is built
- Smaller exercises are easier to digest
- Math problems are actually great ways of building this skill
- If you were a math major or minor, you’ve probably mastered this already
I guess it’s finally time to face my fears of math so that I can become a better programmer.
As resources to help me practice building this skill, I’m going to use various websites to work through at least a problem a day. ProjectEuler actually fits all three of the criteria above for how to build the skill. The problems are small, the build on one another, and they are math-focused. I’ve found another, Rosalind, which is focused on BioInformatics, and seems promising for not quite as math-heavy solutions. Another interesting site is RubyQuiz, but this one might not be quite as helpful, as many of the quizzes seem to already contain a problem break-down spelled out for the user.
My goal is to look back at the assessment at the end of this course, and inherently know how to break down a problem into it’s smallest parts. I hope to marvel at how easily I can solve this problem, and many others — not through memorizing the solution, but by knowing how to work through the details.
I also found this resource, provided by Google, for any educators looking to teach kids math through the use of computational thinking. I may go through some of the exercises myself, even if they are for grades 6-12!
This free course from Udacity also explains algorithms through social networks. I’ve started working through it and it seems like it will be helpful.