Computational Thinking and Solving Problems

In my last post I shared how I am taking a programming class. We're a couple weeks in now, and it's all going well enough. (So far, so good!) 

Yesterday I wrote a fun little program to help with planning a hot dog roast. (Why do hot dogs come in packages of 10, and buns in packages of 8???) It's not the most elegant code ever, I'm sure, but I tested it with a dozen or so inputs, and the math checks out. It's a functional program. I'm feeling proud of myself, even though it's a relatively small thing.

Here's the output for the program I wrote. Fun, right?

I'm learning the syntax of Python, the "grammar" of the language. And I'm learning strategies to build code that is readable by both the computer (obviously) but also humans who might need to understand the code as well. And I'm learning about software development environments, and just how many places Python is used today. (It's a lot--a really useful language!)

But as interesting as it is for me to think through what I'm learning...it's even more interesting to me to reflect on how I'm learning.

I've taken programming before, and I'm finding myself calling back to the last time I took a course that involved hacking code, over 25 years ago now. The language is obviously different. But I'm thinking about the habits of mind I'm re-encountering as I'm taking this course. There is quite a bit of discourse in STEM education today about teaching what is called "computational thinking." This is the idea that we can break down problems into "computable" steps--algorithms, heuristics, and patterns that can help us solve the problem. 

I'm finding that more than learning coding in a particular language, I'm (re)learning some computational thinking strategies by taking this course. 

We're at a point in the semester where we are learning techniques for branching and iteration--"if-else" statements, and "while" loops--and the logic of understanding how the computer will process our code. This has me thinking about how I break the problem down, and how I attack the specific aspects of the problem to find a workable result.

My professor is fantastic at helping us think through "pseudocode" in class, where we take a problem, and collectively analyze the steps we might need to take to solve the problem, and sort of code it out as a series of algorithms, without actually writing all of the code in Python. Then we can work through the specifics of turning that pseudocode into the actual grammar of the language. It's a really effective teaching technique! And then, the practice: we use an online platform to practice writing small snippets of code and get immediate feedback. Because I get immediate feedback on whether my code "worked" or not, I can either move on to another exercise, or rework it, or if I really get stuck, it even offers some hints to get me thinking in a different direction. It's a pretty smart approach. This is really helping me to sharpen up my skills at attacking smaller scale problems that I can then bring to bear on the bigger coding problems that we do, like the hot dog cookout program I shared above.

When it comes to the exercises for homework, it's amazing to me how often find this pseudocode approach working--and it's also amazing to me how frustrated I get when I don't slow down and think computationally. There have been a few times where I read the problem in our online coding platform, immediately make an intuitive leap to how I think the code should function, hack out a solution to the exercise, and hit submit. And sometimes this works great! But other times...well, let's just say I hit "submit" 23 times for one exercise the other night, tweaking the code just a bit each time before hitting the button again. Ooof. I was getting a little frustrated, but when I finally got the right answer, I laughed...because I realized that I had been banging my head against the wall because I had missed a step in the initial framing of the problem, and in my rush to start hacking code, I didn't slow down to think through the steps.

And that, to me, is the most important thing I'm learning: I am often quick to make snap judgments, and I think this course has already been opening my eyes to the importance of slowing down and understanding the real situation of the problem before I just barrel on to a solution.

It's a lesson that I am going to need to keep relearning, I think. 

But I'll celebrate the small steps that I'm taking in this (re)learning process. And if you are planning a hot dog roast, I have a piece of code that might help you in the planning process.