As I embarked on my journey to learn python, I began by exploring a number of different approaches.  I finally settled on using “beginner’s mind” (shoshin to those of you out there that know anything about Zen Buddhism).

Rather than just dive in and build on my existing programming skills and experience, I decided to start completely from scratch. Fortunately, MIT’s Introductory Computer Science class (6.00 Introduction to Computer Science and Programming) is available in its entirety – including all 24 lectures – on MIT’s OpenCourseWare.

I fired up Lecture #1 (Goals of the course; what is computation; introduction to data types, operators, and variables) and spent an enjoyable hour remembering what it was like to be in 10-250.  If you want a taste, here’s the lecture.

The lectures are all up on iTunes so I’m going to watch #2 on my way from Keystone to Boulder this morning (Amy is driving). I’ve got plenty of reading to do and I look forward to diving into the problem sets.

While watching the lecture, Professor Eric Grimson reminded me that this was not a course about “learning Python”, rather it was a course aimed at providing students with an understanding of the role computation can play in solving problems. A side benefit is that I will learn Python and – in Eric’s words – “feel justifiably confident of [my] ability to write small programs that allow them to accomplish useful goals.”

Beginner’s Mind can be a powerful thing.

January’s Tech Theme of the Month is going to be Python.  I realize it’s still December; I decided to get a head start.

Last month’s tech theme was videoconferencing.  I learned a lot, including the unfortunate continued split between low end and high end and general lack of ability to have a single universal solution.  Oh – and bandwidth still matters a lot.  I expect by the end of January we’ll have much better videoconferencing infrastructure set up at Foundry Group with the single goal of eliminating some travel.

I’ve thought about learning Python for a while.  I don’t code much anymore and I regularly find myself wishing I could do something with a simple UI and heavy back-end processing – mostly to move data between web services that I use via the web services APIs.  I stopped programming around 1993 although I occasionally had to dive back in and support something that I had previously written until the late 1990′s, when I stopped for good because I simply had no time.  As a result, the languages I feel like I have mastery over are BASIC, Pascal, Scheme, and Dataflex and the corresponding environment that I’m comfortable developing in ends with MS-DOS and Novell Netware.  While I did stuff in plenty of other languages as a result of courses I took (IBM 370 assembler, SAS, Fortran) or projects  I had to figure out (PL/SQL + Oracle, Paradox, dBase), I don’t feel like I did enough with these to claim mastery.

Every couple of years, I fuck around with a new language and environment.  PHP is the one that has stuck the best and I can read it and hack around if necessary.  But I don’t really like PHP – it feels sloppy and I constantly am having to look up syntax because it’s not comfortable to me.  I went through a “ok – I’ll figure out Ruby on Rails” phase a few summers ago but stalled when I realized that Rails wasn’t a particularly practical environment for what I wanted to play around with.

Python may be a miss for me, but when I look at Python code I feel very comfortable with the syntax.  A few folks that I know that are like me (e.g. not developers anymore, but were once, and occasionally bust out an IDE to hack on something) swear by Python.  But the biggest motivation for me was that 6.01 is now taught using Python.

In 1984, I took 6.001: Structure and Interpretation of Computer Programs.  This is the first computer science class most MIT students take.  I had written a lot of software, including several commercially released products, almost entirely in BASIC (with a little Pascal and assembly.)  6.001′s programming language of choice was Scheme (a LISP dialect) and working with it was an epiphany for me.  I continued to write commercial apps in BASIC and started using a 4GL called Dataflex, but my coding approach was heavily influenced by what I learned in 6.001.  The abstractions you could build in BASIC, if you tried, were surprisingly good and Dataflex was a remarkably robust 4GL – very UI constrained, but very powerful (and fast compared to everything else at the time.)

So – if you look at my history, I’m comfortable with imperative languages.  I got a good dose of functional programming from MIT but never did anything with it commercially.  And I stopped developing software before object-oriented programming became popular.  Python feels like a mix of imperative and functional when I look at it and read about it so I’m optimistic that I can use my regular programming muscles without having to fight through the OOP stuff that I don’t really know and doesn’t feel natural to me.

MIT has an IAP course (the MIT January session) titled 6.189: A Gentle Introduction to Programming Using Python.  As with many MIT courses, it’s available on MIT OpenCourseWare so I’m going to take the course over the next month and see how it goes.

If you are a Python expert and have any suggestions for sites, tools, or blogs I should pay attention to, please leave them in the comments.

More from our friends Nate and Natty at Everlater – this time on debugging.

One of the most important techniques we used when learning how to code is debugging.  It allowed us to do two things: fix our own code when it was broken and parse through others’ code to better understand how they were doing things.

From a backend perspective, debugging is essential.  When I first started writing code, I would write what I *thought* was the correct way to do it. Ninty-nine times out of a hundred I was wrong and the code would blow up with some ugly exception that I had no clue about.  Copying and pasting the exception into google got me decent mileage, but the real silver bullet I discovered was just start from the beginning of the method and step through it using the ruby debugger and figure out where I had gone wrong.  Almost always I had forgotten to assign some variable or I was calling a method that did something different than I thought.

The other huge thing that is related is that I read and still read copious amounts of open source code written by other people.  I’m better at understanding it now, but at the beginning I would take a debugger and walk through the code myself to try to figure out exactly how their code was working so I could make my own code better.

This is super important on the front end as well.  Using tools like firebug or web inspector to take apart existing sites and figure out how they’re doing something or making something beautiful is a great way to learn better techniques for front end development.  They’re also essential for figuring out how to fix a layout when it’s broken, or how to figure out why an ajax request didn’t respond the way you would expect.

This is a great, free resource to use when learning how to program and really helped us to bridge the gap from a basic programming book to what current philosophies on development were.  A huge hat tip goes out to Jeffrey Kalmikoff for posting a comment on a previous post in this series that made me remember how important this is.

Somewhat related are tools that help you keep your code/team in order.  By far the most important is a good version control system.  This is something that they don’t ever teach even in college classes, but it’s hugely critical to building a project in the real world.  We use git at Everlater and it’s been an amazing choice.  When coupled with GitHub, it makes working even in a team of two seamless even if you’re working on almost the same code.

Also important is some way of keeping track of the quality of your code as your project grows.  This includes a good issue tracker (we simply use the to-do list feature of the free version of Basecamp), and a good way to know when there’s something wrong in your application (Hoptoad is great for Rails devs.)

I know it’s been a few weeks since my last Nate and Natty / Everlater post on learning to program.  I’ve gotten a few notes asking for more – expect a couple of posts over the next few days.  In the mean time, here’s Nate’s view on how to divide tasks between partners – in this case him and Natty.

Having good systems in place around your coding is just as important as the coding itself.  Natty and I spent a huge chunk of our time figuring out a great workflow that would allow us to program more effectively, and we think it’s paid huge dividends over the lifespan of Everlater.

The first and most important decision we made was to work together and divide the tasks we had to learn in half.  I (Nate) took most of the backend server tasks — everything from SysAdmin stuff to Ruby/Rails and a good chunk of the javascript that interacted with the server too, and Natty took everything that appears to the user — everything from learning Photoshop/Illustrator to HTML/CSS and quite a bit of javascript as well.

Nothing too special about our division of labor, but it bears worth repeating that this worked well because we worked so closely together to make sure that the other person still had an idea about what was going on.  I needed to know the basic structures of the HTML Natty was creating so I could work on the javascript, and Natty needed to know a good deal of Ruby for creating and displaying the content coming out of the database.  We’ve worked on how we pass work back and forth, and while I believe it’s pretty personal, having some basic workflow where you have several stages of planning, we do something like this:

• Mock up the pages super roughly with pen and paper and figure out the different database models
• Do Photoshop mockups and build the routes and models
• Actually build the pages in HTML/CSS and build out the controller actions associated with each view
• Finishing touches (usually javascript), and testing

At each point in the process Natty and I would sit down and talk about how it was going, and implement our side of the task.  It bears repeating that this is also a highly personal part of learning how to program.  The following worked very well for Natty and I but other people might be better off pair programming the whole thing, work at completely different speeds, etc.  The most important thing is thinking about the workflow in general and making sure it’s a conscious decision rather than something that just happens.

As Fred Wilson likes to say, often the best content for blogs is in the comments.  In this case, it was in an email I got from Boaz Fletcher in response to my post Web Sites and Books for Novice Programmers.  Boaz made a very interesting observation:

“As for learning how to code, I think good storytellers make the best programmers. I used to freak prospective employees out by having them write a story for me instead of the “what’s wrong with this code?” tests. But it showed me who was able to think well, organized, creatively, and filled in the details.”

He also had an insightful comment about teaching kids to program.

“I had an exchange with someone in the industry about teaching kids how to program – or, more appropriately, how little there actually is to start kids off (think Alice or Scratch). Considering the ubiquity of computers in our lives, I think it’s untenable that most people are just passive users of the things. It should be mandatory to teach kids how to program. They don’t all need to become software engineers (never mind that I think most software engineers today, aren’t) but a basic understanding of how to build something simple and useful to them. Think about “shop” in junior high – hands-on manipulation of the physical world. So you may never need to lathe out a wooden bowl again, but at least you can hang a picture straight. Kids can browse the net, but don’t have a clue why their computer gets stuck when they’re trying to print a webpage.“

I’ve been thinking and talking about this particular construct a lot lately, especially in the context of NCWIT.  A person younger than 15 years old has never experienced life without the existence of the web.  Their view of the world, especially 29 years from now when they’ll be as old as I am today, will be radically different because of how the computers and the web are integrated with their life.

I never took shop in high school.  I’m not mechanically inclined (or skilled) at all.  Not only can I not hang a picture straight, I’m not sure I know what to do with a power tool.  And forget changing the oil in my car.  When I reflect on things I wish I had done more as a kid, it’s tinker with mechanical things so I’d be more comfortable with them.  In contrast, I’m completely comfortable with anything that’s “not physical” – I like to say "I’m only interested in it if I can’t touch it.”

We are definitely living in a world where both are important, but the not-physical is becoming increasingly pervasive.  Making sure that young people are tuned into this seems critical.  When I think hard about this, there’s real insight in Boaz’s comment about the power of storytellers.

Thanks for all the feedback and comments on the Learning to Program series with Nate Abbott and Natty Zola from Everlater.  In the last post, titled Web Sites and Books for Novice Programmers, I foreshadowed some of the tools that Nate and Natty chose to build Everlater.  Now that you know how they got started, here’s what they ended up choosing.

Everlater is built on Ruby on Rails, postgreSQL and is hosted on Engine Yard using a passenger/nginx combination.  Nate and Natty use several standard Ruby/Rails packages (gems) to extend the base functionality of Rails.  On the front end, they use a combination of jQuery and Prototype for Javascript.

The technology stack that they’ve ended up with has evolved over time.  The very first decision – which web framework/backend language to use – was the toughest.  Once again, our friend Google appeared – this time for the phrase “web framework comparison.”  A few days later, the exploration shifted from simply finding and poking around in the various languages (most notably Ruby/Rails, PHP/CakePHP/CodeIgniter, Python/Django, ColdFusion, .net, and Java), to figuring out the salient points in the debate: speed, ease of use, active development of the platform, security, and cost. 

Over beers, Nate and Natty put on blindfolds and threw darts at a board.  After incorporating these results into their decision matrix, they chose Ruby/Rails mostly because they felt that it had an active community developing it and seemed to be the easiest to learn the quickest.  It took roughly a week to come do a decision, start to finish.

After choosing Ruby as the main language they would be working with, they immediately began searching out every possible Ruby coding Meetup. Through those meetings they became connected with Boulder’s Ruby community which is an amazing group of incredibly smart people.  They also found two great people, Charlie and Ryan who began working with Everlater for equity early on and helped make some of the key early decisions.

In the continuation of the Learning to Program series with Nate Abbott and Natty Zola from Everlater, I asked them a few questions about which web sites, books, and blogs they consumed at the beginning of their journey when they knew nothing about programming. 

It turns out that Nate and Natty spent most of their time simply searching for what they were looking for.  Whenever a specific topic came up, they’d use Google, be patient when reading through the search results and forums, refine their search, and keep trying.   They discovered that there are an amazing number of programmers who publish code on their personal blogs.  As they were trying to get basic stuff to work, they spent time searching for and then reading the full posts and comments. 

While they like sites like Stack Overflow and Github’s wiki pages on different open source projects, Nate and Natty never found a great site on the web that has comprehensive documentation on how to program.  Instead, they concentrated on being smarter than the problem, really thinking it through and isolating what they needed to learn, and then being patient in searching for and researching the answer. 

As Nate and Natty landed on a language and a set of frameworks to work with (more on that in another post) they spent a lot of time with the API documentation for languages and frameworks.  As dry as it might be, they waded through the Rails API, the jQuery API, and even the WC3 documentation.  But they often quickly ended up back at Google searching away.

It turns out that Nate and Natty have only bought three programming books in the history of Everlater and one was a forgettable SEO book that doesn’t even merit being mentioned.  The other two were HTML, XHTML, and CSS published by Visual Blueprint and RailsSpace by Michael Hartl and Aurelius Prochazka.  They felt the HTML/CSS book was so-so but it was enough to get them started. On the other hand, they thought RailsSpace was an incredible book that taught Ruby on Rails by walking through the steps to create a social network for Rails programmers.  While they felt this was a little corny, it also ended up being very effective.

Not surprisingly, Nate and Natty read a lot of blogs.  They read typical tech news blogs like TechCrunch and VentureBeat, popular VC blogs like Fred Wilson’s and Dave McClure’s, and entrepreneur blogs like 37signals blog Signals vs Noise.  But when they went deep technically, they spent a lot of time with RailsCast, the Engine Yard blog, and Yehuda Katz’s blog.  For design, they went with SpeckyBoy and Smashing Magazine. And when they needed a break from development they read Tech Trader Daily which was a holdover from their old life as junior investment bankers.

As I reflected on this, I found it fascinating how little they relied on books.  True to form, they sat down in front of their computers and just got started.  All of the information was already out there – they just had to be disciplined about finding it, reading it, and learning it.

What have you read lately?

To start off the Learning to Program series with Nate Abbott and Natty Zola from Everlater, I asked them the simple question “What Was Day 1 Like?”  Nate responded first:

Day one was totally overwhelming.  Overwhelming because we didn’t know what we didn’t know.  It’s one thing when you don’t know how to do something (e.g., validate email addresses or change a button’s hover state).   But we didn’t know what we needed to learn, and that made it difficult to even start down a path.  The first week was spent just googling "web site design", "web site architecture" and "web server" to try to get a handle on all of the acronyms we were coming across (such as CSS, HTML PHP MYSQL, ROR, JS, AJAX).  Our goal was to piece together the list of skills that we were going to collectively learn in order to create a web service like Everlater.

Day one was also thrilling and exciting.  It’s the same feeling I get when I’m starting a long bike ride in the mountains, the same feeling I got when I first got to college, or when I got my first offer letter for ibanking in New York.  To me, there’s nothing more exciting than beginning a large task, and nothing I had done was quite like the task at hand.

Natty responded shortly there after with a few things to add:

We also researched sites we liked and benchmarked what they were doing/using to get a feel for what the popular/hot sites were using.  Most notably I remember looking at Facebook and seeing .php at the end of the url string.  This gave us ideas of where we should start our research.

I was excited like Nate, but also somewhat afraid.  We quickly realized we were going to be learning another language, but much harder than a foreign language because we couldn’t rely on familiarities like verbs, nouns, and sentence structure. Worse, we would have to learn the basics of speech in becoming functional at the command line, databases, and editing programs. 

The other interesting thing was that before we put any code down or started day 1 of our idea, we had spent a month brainstorming what we wanted to build.  While this was pre-day 1 it enabled us to focus on making code/tech decisions and learning the code rather than also having to think about what we were doing with it.  I think this sped our research because we had a framework within which to think about the decisions we were making.

Lastly, it really helped to research with Nate because we could bounce ideas around, problem solve, and challenge each other.  Plus, it made it significantly more fun knowing we were diving into the unknown together.

To summarize.  They were simultaneously overwhelmed and excited.  But fearless – they just jumped into the swimming pool off of the high dive and hoped there was water in the pool.

I had lunch today with Nate Abbott and Natty Zola, the co-founders of Everlater, a TechStars 2009 company.  Nate and Natty are two of my favorites – not only because they regularly kick my partner Seth Levine’s ass on bike rides but also because they starred in last year’s TechStars The Founders video series.

Today, while enjoying a veggie burger at Mustard’s Last Stand, we talked about how Nate and Natty learned to program.  When they came up with the idea for Everlater, they were both young finance geeks on wall street.  Nate was a math major; Natty was a econ major, but neither had a clue how to build a web app.  They decided that rather than find a “developer” to team up with, they would learn how to program.

I regularly get asked questions (via email, face to face, and this blog) by non-technical entrepreneurs how they should get started if they don’t have a technical co-founder.  There are a variety of answers – one is “learn to program.”  In Nate and Natty’s case it’s worked out great and their story is an instructive one.  So we’ve decided to work on a series of blog posts together about their story of how they learned to program, the resources they used, decisions they made, struggles they had, and beer they drank (well – maybe not the beer). 

Now, both Nate and Natty are smart, which is obviously a pre-requisite.  But neither were computer science majors, nor were they “hackers” (although apparently Nate is pretty good at a wide range of video games.) 

Look for some posts over the next few weeks on this topic.  Of course, like any of the series I’ve written, your feedback matters a lot to how much I keep it going.  If you decide that the story is great and/or helpful, tell us and we’ll keep it going.  If not, we won’t. 

Boulder AWS Anonymous held its first meeting last week, and there were eleven attendees despite the fact that the meeting had been inadvertently scheduled at the same time as Obama’s inauguration. Attendees represented a wide variety of uses and potential uses of Amazon Web Services, ranging from hosting popular websites and application development to load balancing, autoscaling, and internet telephony. The group is encouraging anyone in the area interested in getting updates to join their Google Group and/or to attend the next meeting at The Cup, 1521 Pearl St, at 10:00 am on Wednesday February 18.