I’m surprised that that I like coding on flights. It’s surprising because airplanes are generally hostile environments for most things, but I’ve found it a good place to code.
The obvious reason is the lack of interruptions and distractions. Usualy there is no wifi, or it is too spotty to count on. So no email or IRC or web. While I know that distractions kill flow, I never seem give myself license to unplug in normal life. I’m a manager, and being a manager means being interruptible.
But there’s another reason. When I code unplugged, I code differently. I have to be self-sufficient. Instead of just looking things up on StackOverflow, I take 20% more time to figure it out myself. That’s much more satisfying! It’s just not that hard to rummage through the Django code or try things out in iPython.
Also it just sounds cool to say you coded something up on the flight.
But thre real question is should simulate “airplane mode” when grounded. Hmm.
I am of two minds about Peter Reinhardt post today calling out online education’s poor retention rates.
I agree that retention rates are low. At Stanford we we just completed the Winter run of Jennifer Widom’s Database Class, here are the course stats:
- Registered: 64,127
- Turned in some work: 20,836
- Took the final exam: 4,771
- Received a Statement of Accomplishment: 4,854 (1,927 with distinction)
How do I feel that 23% of students who started the class finished? Or that only 7.6% who enrolled finished? Mostly I’m fine with that. I think there’s a lot of value in someone kicking the tires. Some were experimenting with on-line education, some didn’t know before hand if the class would be right for them. I share Curt Bonk‘s view that this shouldn’t be seen as a black mark but as another form of outreach.
I consider this over forty thousand people who got some exposure to the topic, the platform, and what this MOOC thing is all about.
But I totally agree that increasing retention is a worthwhile goal and a valuable metric. Online education platforms (mine included) should do what we can to keep students engaged. This article has many good suggestions. And there’s a lot of room for experimentation.
(disclaimer: I’m the engineering manager on Class2Go, the open-source MOOC platform we’ve built at Stanford)
I’ve observed a recurring source of tension: building things fast vs. do it the right way. Usually you’re not lucky enough that you can do both. This post explains a bit why we (engineers) care so much about building things right. Even when things are overdue and our stakeholders (end-users, biz folks, product management) are pushing to just get it done.
You can describe the two poles here in pejorative terms. Fast is slapdash, quick and dirty, bad software. The right way is really just ivory-tower over-engineered turd polishing. Is that fix really so important that we shouldn’t ship it? Do you really need to refactor that now?
I see three things driving engineers to build it right.
- Wrong is insidious. A story: early on in Class2Go every page began with a fetch of some basic page data. If there was an error on lookup we would throw a 404. Not only is “not found” the wrong message, but it also isn’t helpful. It covers up all kinds of other problems, in a way that is really difficult to debug.But for an engineer, these programming messes are broken windows. Not only do they cheapen the project, they encourage others to take bad shortcuts. Heck, if they can’t be bothered to handle exceptions correctly, then why should I?
- Wrong is the express train to support hell. Unless you leave the company or project, you’ll be called upon to support your own crappy code. That is certain. And there is almost nothing worse than being dragged back to debug some old code that you never meant to become production, and is now breaking the world.
- Wrong hurts your reputation as an engineer. People see you taking shortcuts and infer that you are a sloppy programmer. And really they aren’t wrong to do so. One habit of really good engineers is they don’t leave a wake of messes behind them. They are able to do things (mostly) right even when they are moving fast.
This last point is really the key one. Amongst engineers your reputation is your hard currency. It affects what projects you’re invited to work on and what companies you’ll be asked to join. Most importantly, good engineers only want to work with other good engineers, and they won’t seek out someone sloppy. So I assume that any code I write will be looked at by a potential colleague or employer. This is especially true when working on an open-source project.
This doesn’t mean you have to go slow — indeed, on my current project, Class2Go, we get a lot done every week. What it does mean is that sometimes I’d rather not do something than do something I know will come out poorly.
So, product manager waiting on a feature. What to do if you’re waiting on an engineer and you think it’s taking too damn long? The tactic **not** to use: tell them this won’t matter and to just ship it. That will just piss him off. Better: get your senior engineer to convince the junior one why it’s good enough to ship and reason about what really needs to get done. Exception: if the engineer you’re waiting on is your senior engineer, then trust her judgment and wait.
And finally, to you product managers and biz folks who push. You are right do do so. That’s all that matters to the customers, all matters at the end of the day. Keep it up.
Update with actuals from Halloween 2012: It was a banner year.
You may be giving out candy later today. What can you expect? Let’s look at some data. This post summarizes the past three Halloweens.
As you can see we live in a pretty popular neighborhood. Each year has its own story.
- 2009 – our first year in our new neighborhood. We had no idea that this was such a popular trick-or-treating spot. I ran out of candy at 8:00, turned out the lights, and hid in the back of the house. Shameful.
- 2010 – a fine year. No complaints.
- 2011 – we moved to a new house just around the corner. I figured the quieter street would mean fewer kids — not so! What I didn’t appreciate was the attractive power of my next door neighbor’s insane decorations. Luckily my wife came back with emergency supplies just in time.
And how busy do things get? Darn busy.
During the busiest 15 minute period last year I was serving a kid every twenty seconds or so. When bursting this is close to my max current candy-dispensing throughput.
If you come by my house this year you’ll see me again, handing out candy with one hand and scribbling hash marks with the other. I’ll update the data in my public spreadsheet.