Is your computer a tool, or an appliance? Appliances are good, but tools can be better. You can watch video on an appliance; you can make a video with a tool. You can read a book on an appliance, you can write a book with a tool. You can use software--access a website, use a database, manipulate data--on an appliance, you can create your own software on a tool.
At the moment, the computer-using world is divided into two groups. There are those who are happy enough to use their computers with whatever software is made available to them, and there are those who are able to make their own software.
In other words, the software literate and everyone else.
The software literacy divide is comparable to the old-fashioned literacy divide. In populations where literacy is not widespread, a professional class of scribes can develop. If you want to read or write a letter, a note, a book, anything, you go to the scribe. You hope the scribe is good enough to express your ideas accurately and to be able to explain all the words you want read to you.
If you aren't software literate and you want a piece of software to solve a particular problem, you go to a software scribe. You hope the software scribe is capable of writing a program that solves your problem correctly, accurately, reliably and maintainably.
Illiteracy is generally considered bad. In a free democratic society, it's best if you have a citizenry that can read and write, and think critically and for themselves about what they read and write. So we have comprehensive public education and a literate population.
What makes software so different? There are many reasons software literacy would be advantageous, beginning with improved efficiency at work. It shouldn't be hard, either: computers are everywhere, in our pockets, schools, homes, workplaces. High quality professional software, published under open source licenses, is widely available for free download.
So, what's the problem?
Do you remember learning to read and write? Chances are, you learned over a period of years, starting from the first time you ever saw a written word: maybe on television or maybe on a traffic sign or maybe in a magazine or maybe even in a book.
What you didn't do was sit down with a copy of Warriner's English Grammar and Composition and the MLA Handbook for Writers of Research Papers and start reading from Chapter 1 about why you might like to learn how to read and write. You certainly didn't do that before you'd ever held a book in your hands, or knew what a book actually is.
Yet that is almost exactly how most people have been trying to learn to program.
We buy 1200 page books that describe in excruciating detail every command and function of a programming language, every quirk of the language's control structures and data typing, every keystroke and mouse click to install and configure the software--yet these same books skimp on or skip entirely providing any context for what those functions do and how you might use them.
We try to follow tutorials that involve fairly complex processes, without understanding what they are, or in some cases without even being aware that they exist.
Imagine being a child who has never seen a book or learned the alphabet. Now, imagine being given Moby Dick and being told to read it and write a book report on it. Because that's more or less what it's like to try to learn to program. It's possible, but you'll have to put in a lot of time to try to teach yourself all the supporting technologies: the alphabet, how to open and close a book, how to turn a page, how to interpret the words on the page and navigate through chapters and all the rest that we take for granted as adults who have been reading for as long as we can remember.
Learn Python the Hard Way, by Zed Shaw
The beauty of Shaw's book is that it's the programming equivalent of Fox in Socks or Go Dog, Go. Each chapter is a simple snippet of code that you copy, one character at a time, into your own files and run on your own computer. Each chapter includes some "extra credit" problems that build on what you've already learned, and the focus of the book is on showing the reader how to move on, not telling the reader everything there is to know about a programming language.
So, here's my contribution to the literature of learning to program. I'm still very much learning to program myself, but I'm getting a lot of help, not just from the Internet, but also from great people in the Boston PHP and Boston Python meetup groups. So far, I'm making progress, but the only way to get better at writing anything, software or stories, is to do it, A LOT.
Use this site as a resource, but not the only resource. Some other suggestions:
I'll try to incorporate additional exercises or questions or topics of further research on each page; try to at least read and think about them before moving on to the next page.
I'll include this section on every page, going forward, to list the new words included on the page that you should really have some idea what they mean before going on. If you already know these words, great! If not, do your own research to get definitions that work for you: