« swipe left for tags/categories
swipe right to go back »
Six weeks ago I saw a tweet about a new thing from Codecademy called Code Year. It promised to teach you how to code in 2012. I signed up right away and am now one of 396,103 people who have signed up as of this moment.
Like a good MIT graduate, I’ve procrastinated. When I was an undergrad, I liked to say things like “I want to give all of my fellow students a four to six week handicap.” Yeah – I was the dude that blew off too many classes at the beginning of the semester. I did read everything so I eventually caught up pretty quickly, but fortunately MIT drop date was late in the semester so I had plenty of option value on bailing if I’d left things too long.
Week 1 was trivial. I liked the Code Year lessons and the Codecademy UI is very good. I’ve scored 350 points, have completed 42 (simple) exercises, and have four badges, I only did the lessons for week 1; I’ve left the problems for another time to see if the syntax actually sinks in.
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.
- 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
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.