Search the Blog
Bio


Thanks for visiting the blog. Here you will find random musings about user experience design, business, productivity, project development, a few 2x2 grids drafted late at night, and some pop-culture references to things like the Karate Kid and American Idol (which is to stay I often watch bad TV and occasionally read an interesting book).

Liza

BLOG ARCHIVE
« Writing Into Your Arc | Main | Painting a House, The Karate Kid and Running a Business »
Thursday
Sep252008

A LIBERAL ARTS GRAD LEARNS HOW TO PROGRAM.

 

This Week's Lesson: It's not about code

 

liberalartslearnsprogramming.jpg

This is an installment of A Liberal Arts Grad Learns How to Program, a series of ultra-beginner thoughts and lessons on computer programming and the Ruby language more specifically. This is not for people who know programming, or who studied computer science in school. As the title implies - this is for non-programmers who think they'd like to get into programming. For the record, I studied Modern and Contemporary European Philosophy in College and started programming almost a year ago. Because of this, take everything I write, especially the code, with a large grain of salt

One of the problems I first encountered when starting to program was the panic attack a computer screen full of code induced. This made it very difficult to get anything done, as you can imagine. There is, of course, a reason they call them programming languages; and trying to read (much less write) a screen of Ruby, or Pearl, or C, or even HTML if you don't understand the language is like listening to the radio in a language you don't speak - you know there's meaning to what you're hearing, but that meaning is not for you.

And so, what's your way in? Assuming you are a skill-less liberal arts grad like me, how do you start programming; how do you learn a language?

 

I suggest this: forget about the code, at least initially. Don't worry about writing code, that skill comes later. Instead, remember that programming is problem solving; before code comes the problem, and while code is eventually how you will get the computer to solve your problem, train your brain to first understand the problem in English (or whatever your primary language is). The code you will eventually write is simply the instructions you give to the computer that allow it to solve your problems. But, if you haven't solved them as a human first, good luck getting the computer to do it.

A SIMPLE, BUT INSTRUCTIVE EXAMPLE: Let's say you want to write a program that allows a user to enter their age into a form on the computer and have the computer tell them whether or not they are old enough to vote. Forgetting for a moment how to write the form, the basic program would look like this:

 


age = params[:age]

 

if age >= 18
puts "You are #{age}, and old enough to vote."
elsif age < 18
puts "You are #{age}, and not old enough to vote."
end

 

OK, maybe that makes sense to you, maybe you are starting to get dizzy; but either way: forget about the code. Let's first understand the problems we want our program to solve.

First, we want people to be able to enter their age into the computer.

Second, we need to somehow have the computer remember or capture that age.

Third, we need to take the captured age and compare it to the legal voting age - 18. If it's less than 18, then we want the computer to do one thing (Tell them they are too young to vote); if it's 18 or greater, we want the computer to do something else (Tell them they are old enough to vote and that they should vote for Obama).

Each of these could then be further broken down as needed. (i.e. for people to be able to enter their age into the computer, we need to display a box for them to enter their text, and a button that will submit that information, etc.)

Once we understand, in English, the components of what we are trying to do, we can use those pieces to help us find/write the appropriate code which the computer will understand. Put another way, it's much easier to figure out how to say "I would like more wine" in French if you first understand how and why you would say it in English. The same with programming; it's much easier to write code if you first try and understand the problem you are trying to solve in your primary language.

PrintView Printer Friendly Version

Reader Comments (2)

One thing I always find helpful is to get out your legal pad and pen, and start sketching out the problem. Boxes, lines, arrows, and text served me well. Re: the language itself, we're still in the extreme dawn of how to create complex artifacts. Nature solves this problem by growing things via evolution over many, many millennia. Just look at the junk in DNA to see the failures and "bugs" in that process. Sadly, for programming the high-level tools are still a ways off.

Good luck!
September 28, 2008 | Unregistered CommenterMatthew Cornell
Yes - the drawing arrows on paper thing is something I need to do more of. In the Rails book I am reading - Agile Web Development with Rails - the first step in their tutorial application is actually sketching out a basic page flow - totally helpful.

Thanks Matt!
September 29, 2008 | Unregistered CommenterMatthew Latkiewicz
Member Account Required
You must have a member account on this website in order to post comments. Log in to your account to enable posting.