Thinking Like a Programmer

3 min read

thinking like a programmer

I am reading, Thinking Like a Programmer by Anton Spraul and the first few sentences say:

Do you struggle to write programs, even though you think you understand programming languages? Are you able to read through a chapter in a programming book, nodding your head the whole way, but unable to apply what you’ve read to your own programs? Are you able to comprehend a program example you’ve read online, even to the point where you could explain to someone else what each line of the code is doing, yet you feel your brain seize up when faced with a programming task and a blank screen in your text editor?

You’re not alone. I have taught programming for over 15 years, and most of my students would have fit this description at some point in their instruction. We will call the missing skill problem solving, the ability to take a given problem description and write an original program to solve it.

This describes me a lot of the time, especially on the last Treehouse assignment.

I looked over some of the code today and realized while some of that stuff looked foreign to me after I downloaded the solution, taking my time and actually writing some pseudocode and breaking the problem down could have actually helped me figure it out.

Breaking Things Down Into Smaller, More Manageable Pieces

This has been drilled into my head by several experienced Code Newbie programmers in the Slack channel.

When I was at Pitt learning Java I often struggled understanding a large problem and actually looking at it as a whole. Karen Bigrigg, my Intro professor, actually taught us the Divide and Conquer method of programming which is basically an algorithm for breaking down a problem into smaller pieces and dealing with them that way. In this instance, it may or may not fit for what I am trying to do, but it essentially is the way programming works, in general.

I tend to get stuck looking at the whole problem. Perhaps writing pseudocode or looking at one feature at a time when building my contacts app, workflows, etc would make me less afraid of the code editor.

Sometimes, Though, I Actually Win

A lot of times when I am building something, I actually have an idea of where to go and how to implement what I am trying to do. If I don’t, I Google or go to Dash Docs 1 for a quick lookup of something I don’t understand.

For instance, Free Code Camp does a good job of preparing you for projects you are about to build, and the Research, Google, Ask methodology they implement is a pretty important skill for any developer, junior or otherwise.

I’ve gone into the CodePen challenges quite ready for them, even though they’ve been pretty simple so far, not really requiring any JavaScript at all 2. I know they’ll get more difficult but I feel like out of Treehouse and Free Code Camp, Free Code Camp prepares you much better. I use Treehouse to shore up some knowledge and Free Code Camp to become better.

My Plan

My plan is to remember what I’ve been taught. I look at a thing like my contacts app and get overwhelmed. This can be avoided by looking at a small bit of functionality, brainstorming it with a mind map, listing things to do in TaskPaper, and then writing pseudocode to flesh it out, followed by actually source code implementation.

  1. There’s for online documentation, much like Dash Docs that won’t nag you and isn’t just Mac only. Kapeli has a fork of Dash for Windows you can find on his website. ↩︎
  2. Though I did add jQuery to the tribute page just to look like I knew what I was doing. Ha. ↩︎