Tag: Programming
Teaching kids to program is not an easy task – their attention span is short and what they are able to accomplish in a brief period of time is often uninspiring which results in them losing attention quickly.
Robots help a lot with this!
The Orbotix team has turned their Sphero into a fantastic programming aid to introduce coding to kids as young as 4th grade. In about an hour kids will be commanding their robot to drive geometric patterns while also learning a bit about angles, degrees, time and distance calculations, loops and conditional branching. If your my age, you might remember Logo and turtle graphics. It turns out to be really cool to toss a robot into the mix, instead of just a computer screen.
Coding is done via a simple app on either Android or iOS devices and sent to the Sphero via Bluetooth. The younger kids learn to program using a simple scripting language developed by Orbotix called MacroLab – the older kids learn BASIC which Sphero can interpret to do some complex tasks.
Orbotix is hosting a “Sphero Rangers” event at the Google offices here in Boulder this Saturday from 11am to 2pm. Robots and programming devices will be provided – but bring your smartphone if you want to use your own. Attendees will also be able to get a Sphero at a discounted price. If interested sign up here: https://www.meetup.com/
Why Don’t We Make Learning A Computer Language A Requirement In High School?
I spent this weekend at LindzonPalooza. Once a year Howard Lindzon gets together a bunch of his friends at the intersection of financing, tech, media, and entrepreneurship, we descend on The Del in Coronada, and have an awesome 48 hours together. Many interesting and stimulating things were said, but one I remember was from Peter Pham over dinner. It was a simple line, “why do we teach languages in junior high and high school but not a computer language?” that had profound meaning to me.
When I was in high school, I had to take two years of a foreign language. I had three choices – French, Spanish, or German. I didn’t really want to learn any of them so I opted for French. I hated it – rote memorization and endless tedious classes where I didn’t really understand anything. Fortunately I liked my teacher for the first two years and I did fine academically (I got an A) and ended up taking a third year of French.
Year three was a total disaster. I hated the teacher and apparently she hated me. We watched these stupid reel-to-reel movies of french cartoons aimed at English speakers trying to learn French. Beyond being boring, they were incomprehensible, at least to me. Somehow I ended up in the front row and it was my job to change the movie when it finished. One day, when I was sure the teacher was out of the room and I was changing the reel, I muttered ” tu es une chienne” (one of the few French phrases I still remember, along with “va te faire foutre.”) I was wrong – she was in the room and, after a trip to the principal’s office (the principal liked me and let me off easy) I dropped the class and took a study hall instead.
Now, before I use the old line of “I have a hard time learning languages”, I’ll call bullshit on myself since during that time I learned BASIC, Pascal, and 6502 Assembler. I was good at learning languages – I was just way more interested in computer languages than romantic european languages.
We didn’t have AP Computer Science at my school so I taught all of this to myself. But today, schools have computer science courses. And, based on what I’ve learned from my work at NCWIT, looking at course curriculums, and talking to a lot of students, most high school computer science courses suck. Part of the problem is the word “science” – they teach computer science theory, how to program in Java, math, logical, and a bunch of other things. But they don’t teach you software development, which is much more useful, and a lot more fun.
When I compare it to French 3, I wanted to learn conversation French. I probably would have enjoyed that. But the teacher, who was French, insisted on grinding us through endless grammar exercises. The movies were sort of conversational, but they obsessed over the different tenses, and we were tested endlessly on when to use tu and when to use vous, even in French 3.
I’m not a language instructor, nor do I have any interest in figuring out the best way to teach a language – computer or otherwise – but it seems to me that we are shifting into a different period where learning how to write software is just as important – and probably more so – to a high school student as learning to speak French, at least at a two year of course level where all you remember are a few swear words.
Am I wrong? If so why. BTW – Google translate quickly tells me that is “Ai-je tort? Si oui, pourquoi.” My bable fish is on order.
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.
Every week for the past six weeks I’ve been diligently getting an email from Code Year saying my next lesson was ready. Tonight, after dinner, I decided to tackle week 1 and see if this was an effective way to learn JavaScript. While I’m able to program in PHP and Python, I’ve never learned JavaScript. I’m not really proficient in either language (PHP or Python) since I don’t write any production code anymore, but I’m comfortable with the syntax and have done my share of simple little things. JavaScript – not so much. And that seems silly to me since so many people that I hang out with eat JavaScript for breakfast.
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.
I been spending some time with friends in Boulder talking about different approaches to teaching people how to program. One of the initiatives, which is starting to pick up speed, is called the Boulder Software School. Within the group we’ve been pointing at things like Code Year, but I don’t know if any of us have actually given it a shot. So – in the spirit of experimenting, I’m on it. It’ll be interesting to see if any real proficiency with JavaScript emerges, or if I just learn the syntax for another programming language that puts angle brackets in funny places to delimit conditional statements.
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.
As a user, how often have you thought “I wish this web service was faster.” As a CEO, how often have you said “just make it faster.” Or, more simply, “why is this damn thing so slow?”
This is a not a new question. I’ve been thinking about this since I first started writing code (APL) when I was 12 (ahem – 33 years ago) on a computer in the basement of a Frito-Lay data center in Dallas.
This morning, as part of my daily information routine, I came across a brilliant article by Carlos Bueno, an engineer at Facebook, titled “The Full Stack, Part 1.” In it, he starts by defining a “full-stack programmer”:
“A “full-stack programmer” is a generalist, someone who can create a non-trivial application by themselves. People who develop broad skills also tend to develop a good mental model of how different layers of a system behave. This turns out to be especially valuable for performance & optimization work.”
He then dissects a simple SQL query (DELETE FROM some_table WHERE id = 1234;) and gives several quick reasons why performance could vary widely when this query is executed.
It reminded me of a client situation from my first company, Feld Technologies. We were working on a logistics project with a management consulting firm for one of the largest retail companies in the world. The folks from the management consulting firm did all the design and analysis; we wrote the code to work with the massive databases that supported this. This was in the early 1990’s and we were working with Oracle on the PC (not a pretty thing, but required by this project for some reason.) The database was coming from a mainframe and by PC-standards was enormous (although it would probably be considered tiny today.)
At this point Feld Technologies was about ten people and, while I still wrote some code, I wasn’t doing anything on this particular project other than helping at the management consulting level (e.g. I’d dress up in a suit and go with the management consultants to the client and participate in meetings.) One of our software engineers wrote all the code. He did a nice job of synthesizing the requirements, wrestling Oracle for the PC to the ground (on a Novell network), and getting all the PL/SQL stuff working.
We had one big problem. It took 24 hours to run a single analysis. Now, there was no real time requirement for this project – we might have gotten away with it if it took eight hours as we could just run them over night. But it didn’t work for the management consultants or the client to hear “ok – we just pressed go – call us at this time tomorrow and we’ll tell you what happened.” This was especially painful once we gave the system to the end client whose internal analyst would run the system, wait 24 hours, tell us the analysis didn’t look right, and bitch loudly to his boss who was a senior VP at the retailer and paid our bills.
I recall having a very stressful month. After a week of this (where we probably got two analyses done because of the time it took to iterate on the changes requested by the client for the app) I decided to spend some time with our engineer who was working on it. I didn’t know anything about Oracle as I’d never done anything with it as a developer, but I understood relational databases extremely well from my previous work with Btrieve and Dataflex. And, looking back, I met the definition of a full-stack programmer all the way down to the hardware level (at the time I was the guy in our company that fixed the file servers when they crashed with our friendly neighborhood parity error or Netware device driver fail to load errors.)
Over the course of a few days, we managed to cut the run time down to under ten minutes. My partner Dave Jilk, also a full-stack programmer (and a much better one than me), helped immensely as he completely grokked relational database theory. When all was said and done, a faster hard drive, more memory, a few indexes that were missing, restructuring of several of the SELECT statements buried deep in the application, and a minor restructure of the database was all that was required to boost the performance by 100x.
When I reflect on all of this, I realize how important it is to have a few full-stack programmers on the team. Sometimes it’s the CTO, sometimes it the VP of Engineering, sometimes it’s just someone in the guts of the engineering organization. When I think of the companies I’ve worked with recently that are dealing with massive scale and have to be obsessed with performance, such as Zynga, Gist, Cloud Engines, and SendGrid I can identify the person early in the life of the company that played the key role. And, when I think of companies that did magic stuff like Postini and FeedBurner at massive scale, I know exactly who that full system programmer was.
If you are a CEO of a startup, do you know who the full-stack programmer on your team is?
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.