Posts tagged with "coding"

A Day of Dev Bootcamp

I was supposed to spend yesterday in an airplane, hurtling from San Francisco back to Boston. Instead, I ended up in a fifteenth-floor conference room in Chicago with 30 aspiring web developers, getting them excited about coding.

What? How? Rewind:

It’s April 2011, and Jesse Farmer and I meet for breakfast at Stacks in San Francisco. We’ve reached a critical mass of friends in common, and so we decide to connect two more dots. Our conversation ranges from Chicago to Tumblr to fashion, but the part that sticks with me is the moment when Jesse asks: “but how do we get more women into coding?”

May 2012, and an email from Dave Hoover shows up in my inbox. We have a lot in common, not least our shared interest in mentoring and apprenticeship. It takes a while for us to hop on Skype, but once we do, it’s evident that our wavelengths are even closer than we thought. We resolve to stay in touch.

January 2013 finds me sending out my latest letter about what I’ve learned lately. In the letter, I write:

I’ve heard from a handful of people that my posts about programming have inspired them to give it a shot, or to get back in the saddle. And yes yes yes, that’s half the reason I’m doing this at all! I want more people to know what it feels like to make it to the edge. But the writing has gone about as far as it’s going to go on its own. If this work is to travel further and mean more, I need help. Will you tell people it exists?

The letter lands in Dave’s inbox; he’s been reading along. I receive a note from him in return: 

If you ever find yourself in Chicago, I hope you’ll come spend some time with us at Dev Bootcamp. We push people to the edge every day and try to instill in them the ability to remain comfortable with confusion.

"Dev Bootcamp" rings a bell, and loudly: Jesse is one of its founders! Dev Bootcamp is a 9-week intensive intro to web development, and Dave is starting up the Chicago campus. Two more dots, connected in a surprising way.

Two weeks after Dave’s note about the letter, another note shows up. He’s wondering, too: how do we get more women into coding? Not just in, but intoWe set up a Skype call for the afternoon of Wednesday, February 13.

On the call, I learn that Dave’s made significant progress: he and Elliott Garms and Jen Meyers have organized a day-long introduction to the Dev Bootcamp way. Through careful planning and the efforts of a supportive developer community, over 50% of those who’ve signed up for the workshop are women. But there’s still the question of how to make the most of the momentum, and how to keep it going.

This is something I think about all the time, so we dig into brainstorming. I float the idea of bringing in speakers who will tell their stories. “If I were to give a talk, it would be about how it took forever for coding to click for me…but once it did, I was hooked for good.”

"Wait. Do you want to give a talk?"

"Wait. Yes!"

"Are you free this Monday?" Monday is the day of the event.

We both laugh. The absurdity of the proposition is self-evident. It’s too soon! Unless…

"Actually, maybe. I’m supposed to be in an airplane all day. But if you can get me from San Francisco to Chicago on Sunday and from Chicago to Boston on Monday…I’m there.”

It’s getting real. We start looking up flights. “Could you stay and mentor the students all day?” I’d love nothing more. Okay! Lunch talk plus mentoring. “I have to run to a meeting,” I say, “but let me know what you think. I want to make this happen.”

By 9pm, the flights are booked. This is really happening.

Yesterday, it happened.







This one’s for you, Marie:


How do we get more women into coding? This is the answer that took me to Chicago yesterday: by telling our stories, and by seizing every opportunity to share what we’ve learned. 

Thank you, Dev Bootcamp. And thank you to Dave, Jesse, Jen, and Elliott for building the momentum that made yesterday possible.

Building SoundScout

Between November and December 2012, I built SoundScout as a way to discover up-and-coming musicians on SoundCloud. What started as a simple command-line script rapidly evolved into a Ruby app running on Sinatra, powered by two gems, deployed to Heroku, fueled by Sidekiq workers managed by a Redis instance. Building SoundScout was one of the most challenging projects I’ve ever undertaken, and one of the most satisfying by far.


It all started when I realized I wanted to find more people to follow on SoundCloud. My first impulse was to scroll through artists in my Rdio collection and then search for each name on SoundCloud in turn, but after a few minutes of rapid tapping, a realization kicked inA computer could do this! 

A quick skim of Rdio’s API documentation confirmed my hope that I’d be able to get the info I needed through their API. Meanwhile, past experience with the SoundCloud API reassured me that it would be smooth sailing on that end. Before long, it occurred to me: this had the potential to be a great final project for CS50, Harvard’s introductory computer science course (and one of my favorite classes last semester). A conversation with Erik convinced me that I could actually go beyond finding the SoundCloud accounts of my favorite Rdio artists—that the higher good would be to identify new artists to check out based the revealed preferences embedded in my Rdio data. And so, it was decided. With that decision, the next month of my life was more or less spoken for.

This is the story of that month, what I learned along the way, and where I ended up.

Read More

Code Log 12.4.2012

Notes on what it’s like to write code.

I woke up this morning and pulled my open laptop onto the mountainous comforter piled over my knees. Eyes blinking against the sunlight, I squinted at the Terminal window on my screen. Before email, before Twitter, before breakfast, before anything: the most pressing, exciting thing in my world at 7-something this morning was the status of the script I’d set running overnight…

…Noooooooo. I’d forgotten to turn off Energy Saver. The script had stopped when the laptop went to sleep, which is to say, right about when I went to sleep, which is to say, it hadn’t run overnight at all.

The goal had been to grab a ton of data from SoundCloud using their API, so that I could fill my database with useful test data against which to tune my algorithm. I’ve been working nonstop on this app idea I laid out exactly one month ago. It’s nominally my final project for CS50—due this Sunday!—but it’s become much more than that, as I always hoped it would.

Over Thanksgiving, I spent late nights coding at my grandma’s house in Wyoming, precariously connected to the internet over tethered cellular data. I generated piles of CSVs as I experimented with different properties that might indicate promising SoundCloud musicians inspired by artists a user follows on Rdio. My working title for the project was “Riser.” Since all my early files remained in the RIser folder, you can see the accumulated detritus of experimentation:


(Terminal sporting Erik’s dotfiles. They’re indispensable!)

As you can see, the folder was a mess. I’m philosophically okay with messiness (especially in the beginning of any new project), but I’ll admit that I added a needless layer of messiness by not using version control from the beginning.

Conceptual discomfort with version control was not the problem. I love using Git and GitHubmy GitHub profile shows 18 public repos—mostly forks of other projects—and I have 5 private ones (mostly original material) besides. The two main sticking points were subtler:

  1. To work with the Rdio and SoundCloud APIs, I needed to hand off some personal information through my app. In the beginning, I was just storing that info willy-nilly through the code. I eventually moved it to a credentials file (credentials.yml), but still had a nagging worry; I didn’t want to risk uploading a credentials file to GitHub.
  2. especially didn’t want to “risk it” because I semi-remembered that I’d hit my limit of private repos on GitHub’s micro plan. (Free to students.)

In truth, I probably could have figured out what to do. My eventual solution was to delete one of my private repos (which was actually just an empty app, so it was good to get that cleaned up anyway) and to add credentials.yml to my gitignore file so that Git would, well, ignore it when deciding what to track and send to GitHub. A quick conversation with Erik was all it took to get me over the hump and into using version control (in a new folder bearing the project’s final, still-top-secret name) at last. But what’s funny is that I’d actually handled each of those situations once or twice before; they weren’t completely alien to me. Rather, the hurdles felt just unfamiliar enough that I held on to some resistance below the level of conscious awareness. Minute to minute, the sensation was: I just want to keep making my app better! But now I’m kind of disappointed not to have the full history of my progress preserved eternally on GitHub. 

Next time will be better.

And the script that went to sleep? Well, that had a happy ending. After turning off Energy Saver with a flourish of righteous indignation, I spent some more morning minutes squinting at my screen (eyes slowly opening), improving the script, messing with my database, until it seemed like it was in better working condition. I set it running and then stepped outside to go get oatmeal from the cafeteria.

It was my first trip outside in…oh, about 36 hours.

I’m hopelessly hooked.

Code Log 11.4.2012

Notes on what it’s like to write code.

Today, I raced back into Ruby’s arms.

It’s hard to believe, but the end of the semester is drawing near, and so CS50 (the intro to computer science course I’m taking at Harvard) is winding down, too. Well, “winding down” would probably be an overstatement; there’s a lot of work left to do! But lectures have finally broken free of the thicket of C, and this week’s problem set will be our last. After that, there’s just one more quiz and the final project.

The final project. The specification explains: “All that we ask is that you build something of interest to you, that you solve an actual problem, that you impact campus, or that you change the world. Strive to create something that outlives this course.” I’ve built apps before, but something feels different about the prospect of this one. It might be my great love for the course; it might be the element of communal experience; it might be that CS50 itself feels like a rite of passage. It might be that in the past, apps I’ve built have always felt hacked together—hanging by a thread. This one might, too, but I’ll understand the threads so much better. I’ll see how they come together.

For a long time, I’ve imagined that I’d build my final project for iOS. The promise of being able to experience something I built on my phone just seemed impossibly cool. But after spending some time with Apple’s iOS documentation this weekend, my heart fell. In spite of my newfound (relative) comfort with C—a close relative of Objective-C, the language iOS apps are written in—the tutorials still felt insurmountable. This could be for a lot of reasons, but I have a feeling that Xcode's cryptic interface contributed mightily.

So I backed up. I remembered RubyMotion, a “toolchain” that lets you write iOS apps in Ruby that then compile to Objective-C. Also, if the screenshots are to be believed, it lets you circumvent Xcode. Hallelujah! Seems great. The only problem is that it costs money. I visited their website for the dozenth time, and this time noticed that they were willing to discuss student discounts for those who wrote in. I wrote in. I still hope to hear back; I’d love to try it out. But in the meantime, my mind started spinning on alternatives.

The idea for the alternative I’m running with arrived unbidden, as most good ideas do. This is how it came about:

This coming Thursday, I’m traveling to Berlin—for the first time!—to visit friends at SoundCloud. I’m so, so excited for this trip. One reason: I’ve been recording daily, private audio messages to Erik using SoundCloud’s iPhone app for the past year (now up to 321 tracks totaling over 75 hours), so SoundCloud means a lot to me; this will be like a pilgrimage to the mothership. Another reason: I’ve never been to Germany, and haven’t been to Europe at all in almost eight years. Also: I’ll get to hang out with David!

So over the weekend, looking forward to the trip, I decided it was high time to follow more people on SoundCloud. My primary one-to-one use case means that I haven’t played around with many of the site’s social features, and I wanted to take those for a whirl by filling out my network a bit. The only question: how?

I was running errands while mulling this over, so I pulled up the SoundCloud app on my phone and decided to just start searching for the names of bands and musicians I like. But—well—that didn’t seem very thorough. So I opened up Rdio (my primary music app) and started scrolling through the artists in my “collection”—a list of albums stored in my account, originally built off of my iTunes library (which is itself now in deep storage on an external hard drive…Rdio and sites like HypeMachine and SoundCloud serve all of my day-to-day music needs, and SSD storage space is precious). It’s a long list; my iTunes library was huge, holding almost a decade’s worth of accumulated tracks. When I saw an artist that rang a bell as a solid favorite, I’d toggle over to the SoundCloud app on my phone and search for that artist’s name. But the hit rate was disappointingly low, and I soon grew frustrated with the workflow. This seemed like the kind of repetitive work a computer could be doing…

A computer could do this!

And that means I could make a computer do it.

The idea started to shudder to life in my mind. What if…matching?…Rdio…SoundCloud…APIs?…this must already already exist?…shouldn’t it be built in to SoundCloud?…but…well…it sounds fun.

My mind careened onto other topics, then veered back, then kept careening. Later that evening, back in front of my computer, I decided to give iOS development one more shot. I got stuck on some Xcode setting and felt totally defeated. Eventually, I went to sleep.

Today, Erik and I got to talk in real-time for the first time in a while; he was at RubyConf in Colorado for the second half of the week, and we typically rely on time-shifted methods (like my SoundCloud audio messages) during the workweek anyway. We talked about all kinds of things (including the lightning talk he gave on the T gem, his open-source command-line power tool for Twitter), but eventually ended up at the question of my final project. 

I presented the options. Option 1: I attempt an iOS app, but I somehow have to figure out all of iOS development in two weekends, since I’ll be traveling for most of the rest of November and the CS50 fair (where we exhibit our apps) is on December 10. Or, Option 2: I explore this Rdio/SoundCloud idea in Ruby (a familiar language) and focus on making the interface cool. But…that didn’t feel like quite enough. I’ve mashed APIs together before; for a project last spring, I at one point had Stripe, Twilio, and MailChimp all hooked up at once. So where was the challenge befitting a semester of hardcore computer science?

Erik’s suggestion: focus on the algorithm. What if instead of straight matching—”you listen to this artist on Rdio, here’s that same artist on SoundCloud”—the app used Rdio artists-in-collection as revealed preference inputs to a suggestion algorithm for new, up-and-coming artists to follow on SoundCloud?

Now that was interesting. I could feel myself getting more excited. I’ve never tried to write a real algorithm, though I’ve gotten close in my work with databases. When I interface directly with databases, it’s usually about pulling all the fields I think might be useful, exporting to a spreadsheet, then messing around in Excel til the data starts to make sense. The prospect of writing an algorithm tugged at those same detective instincts, but went beyond. Rather than figuring out how to make sense of the data in one particular configuration, I’d be trying to figure out how to make sense of the data across all users and all cases, and to present the results of that sense-making in a usable form. When I mess with data in Excel, I’m the intended audience; by putting data through an algorithm, it expands the possible audience to—well, anyone.

So, that’s the going idea. That’s what I’ll be working toward. But this is one of my favorite things about coding: glimpsing the end goal let me see all the hurdles standing in the way—stretching out to the horizon—and gave me the energy to start jumping them, one by one.

Obstacle #1: I wasn’t actually sure what Rdio’s API looked like. I’ve used SoundCloud’s API for projects in the past (here’s one example), so I felt pretty confident that I’d be able to get what I needed from that side. But Rdio’s API was a total mystery. And, weirdly, I haven’t seen many people tap it for projects. That could just be a sample error (I only follow so many people on Twitter, so I only hear about so many hackathon projects), or it could be that Rdio just doesn’t have a big presence at hackathons, or it could be a lot of other things. But that relative void made me wary, so I decided to investigate Rdio’s API first, to make sure it had what I needed.

I found Rdio’s developer page just by searching for “rdio api,” and quickly realized that I would need to apply for an API key. I was a bit worried that a human would need to review my application, so I resigned myself to a couple-day wait. But fortunately, the process was automated; my application was approved instantly. I browsed the documentation just enough to reassure myself that the API was, indeed, quite extensive. And then it was time to rush off to lunch.

When I came back from lunch, I hit obstacle #2: finding the right Ruby gem.

The hazard—and joy—of programming in the GitHub era is that for any given API, there might be lots of ways to access it in your language of choice. Companies will often release an official “wrapper” for their API that makes it nicer to interact with their data through Python, or Java, or—my favorite—Ruby. But that wrapper (called a “gem” in the context of Ruby) may or may not be the nicest one: some kind soul out there in the world might have taken it upon themselves to make an even better one. There’s really no way to know until you start looking. And, unfortunately, the company’s documentation will not always give you the answer you seek.

In the case of Rdio’s API, I started out on the straight and narrow. Well, I thought it was the straight and narrow. I typed `gem install rdio` at the command line, kind of expecting that to be the canonical one. Simplest name, most canonical; makes sense. Sadly, as I soon discovered, the gem hadn’t been updated in a while…and didn’t behave exactly as I expected. It might actually be fine, but I veered away before answering that definitively, because a closer look at Rdio’s documentation told me that what I really wanted was Rdio-Simple, a family of wrappers developed by Rdio itself and hosted on GitHub.

Except…did I really want it? The syntax seemed kind of horrible—not Ruby-like at all—and I was having trouble getting it to do what I wanted. Again: maybe it’s fine. I didn’t push it far enough to know for sure. What I do know is that I got frustrated and went on a last-ditch quest to find something better. To do that, I went straight to the source: GitHub.

GitHub explains itself as a place for “social coding,” and it meets that definition, certainly. But it can also act like magical toolbox: every time you go there, the available tools have gotten better and shinier in your sleep. I say “act like” because in reality, it’s not magic at all: it’s a result of the efforts of hundreds of software developers, working out in the open, giving their creations back to the community. What makes GitHub so great is that those creations are made instantly usable and instantly discoverable—so instantly that as soon as you find the tool that does what you need, you can’t imagine how you ever lived without it.

So, I went to GitHub and typed into the search box: “rdio”. Rdio’s official rdio-simple repository did show up first. But a few lines down, something caught my eye: a different gem by AnilV, titled “rdio_api”. I went to the gem’s page, skimmed the README, and noted that its author cited the Twitter gem as inspiration. Erik’s one of the Twitter gem’s primary maintainers, and so I’ve seen first-hand all of the care that’s gone in to designing it well. This seemed like a good sign. I installed the gem and revised the few shreds of code I’d written up to that point, trying to use the gem the way I thought it should work. I ran the program and…it didn’t break! The gem worked the way I wanted it to! I didn’t have to bend to its will, or bend it to mine; it already fit my will like a glove. 

That’s one of the nice things about open-source: sometimes it’s not about what version is better or worse, but about which one matches your built intuition. The rdio_api gem matched mine, and so I ran with it.

I figured out how to get artist names from Rdio; then figured out how to input those names as search terms to SoundCloud; then figured out that if I ranked the results from SoundCloud by number of followers, I got a reasonable approximation of the “most legit” account matching any given artist’s name. I started printing those results to the command line, but then realized that scrolling up and down through Terminal would be a pain; printing the results to a CSV (which I could then open in Excel) would be way more usable. So I got that working, and then watched with glee as my spreadsheet filled up with permalinks to artists’ pages. I hit a few snags—I periodically got 503 error codes from SoundCloud, and discovered that SoundCloud couldn’t seem to handle colons as search input. (My iTunes library was voluminous enough that it included a couple of artists with this issue, including the mysteriously-named P:ano.) But overall: it worked. It worked! The basic idea worked.

With the data in a handful of spreadsheets, I started exploring—clicking permalinks that seemed promising and, on a meta level, trying to develop some intuition for what datapoints I was privileging when deeming permalinks as “promising,” so that I could build that into a future algorithm. I ended up following about 45 new accounts (you can see all of them here), very few of which I would discovered without this exercise. A few highlights:

  • Olafur Arnalds makes serene, dreamlike music. At least one of the tracks appears to be a true improvisation—not just a polished, finished track. I always like it better when artists show their work.
  • The way I was sorting showed me that Vagrant Records is actually home to several artists I love, including Edward Sharpe and The Magnetic Zeros and School of Seven Bells. Since Vagrant lists those artists in its profile, SoundCloud search picked up on the connection and returned Vagrant’s account as a result. And now I’m following them, which means I’ll get to trust their taste further.
  • It seems improbable that this Owen Pallet account is legit, but I loved hearing the demo version of “Tryst with Mephistopheles”—a song I listened to every morning, for a span of months, when I lived in San Francisco.
  • Lykke Li!

Now that I’ve cleared many of the hurdles, I can’t wait to start building out the app itself—tweaking the algorithm, generalizing the code to work for more users than just me (probably by enabling authentication), figuring out how to present it all. But underneath that anticipation, there’s also ecstatic satisfaction. There’s nothing quite like bringing an idea to life in an afternoon, and I never get that feeling more reliably and more acutely than when I’m working with code.

And I’d say that the prediction/wish I made last week is holding truer than I imagined: “I don’t think I knew how good I had it with Ruby…but I also never knew what it was capable of (or what I was capable of). So that’s the bet I’m making: two months of alternately infuriating and satisfying hand-to-hand combat with C followed by a lifetime of harmonious cooperation with Ruby and whatever comes next.” Ruby is awesome. It’s so good to have it back. I’ll never take it for granted again.

What else? So many things!

While debugging with Erik today, we took a detour into talking about SOLID principles of object-oriented design—specifically, the Liskov Substitution Principle, which states that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” I actually had a bug that related to that principle, so it proved a good learning moment. In the process, I learned about Barbara Liskov—a computer science pioneer, now at MIT. New goal: meet Barbara Liskov before I leave Boston/Cambridge!

Exploring SoundCloud, I ran across this Four Tet remix of Ultraísta’s “Smalltalk,” (warning: it’s great), which reminded me of this Twitter exchange with Patrick and Buzz, wherein Buzz noted that “Objective-C actually shares one of the same ancestor[s] as Ruby (Smalltalk),” and Patrick recommended Squeak as a way to play with Smalltalk today. Still need to dig in to all the links they suggested, but that thread is one of the many that feels more woven into my life lately.

I’m still making progress through Seymour Papert’s Mindstorms, which I picked up from the library after taking heed of Bret Victor's strong recommendation in his post on “Learnable Programming.” The book is sort of about LOGO (the programming language with the turtle), but mostly about learning. A few passages I’ve loved recently:

Of all ideas I have introduced to children, recursion stands out as the one idea that is particularly able to evoke an excited response. I think this is partly because the idea of going on forever touches on every child’s fantasies…
…what is important when we give children a theorem to use is not that they should memorize it. What matters most is that by growing up with a few very powerful theorems one comes to appreciate how certain ideas can be used as tools to think with over a lifetime. One learns to enjoy and to respect the power of powerful ideas. One learns that the most powerful idea of all is the idea of powerful ideas.

An important component in the history of knowledge is the development of techniques that increase the potency of “words and diagrams.” What is true historically is also true for the individual: An important part of becoming a good learner is learning how to push out the frontier of what we can express with words.

And, finally, there was this: an artifact of today’s remote pair programming date with Erik, the moment where I excavated all the way to the bottom of an object’s ancestry.


The process of debugging is a normal part of the process of understanding a program. The programmer is encouraged to study the bug rather than forget the error.

Seymour Papert, Mindstorms

Code Log 10.25.2012

Notes on what it’s like to write code.

The past month has been a quick, rocky plummet further into C. With every problem set, I feel like I’m hanging on for dear life. My eyes go wide as I read the specification; a few hours later, I’ll have solved one small part of it (conceptually/syntactically) and hope returns. Then I’ll try to compile the program, and hope will go out the window for another twenty minutes. In all but one case, I’ve eventually figured it out…usually at four in the morning or something. At this point, I will usually clap quietly to myself and go to sleep or go shower, depending on how close it is to morning.

This sounds terrible, but there’s something great about it. The process requires such insane focus, such maddening brow-furrowing, but the wins are within reach…if you’re willing to reach for ten or fifteen hours. This is especially so since CS50, the intro to computer science course I’m taking, only poses problems that are in fact solvable. If we were at the edge of human knowledge, things might be different—I might be walking around for days, months, years wondering whether I’d ever reach the point where I could clap my hands together and go shower! But I’d still wager that my experience is a reasonable microcosm. I can see how people get hooked…I might be getting hooked, too.

I’ve been so absorbed in C that I’ve barely touched web development in over a month. A couple times a week, I’ll slip into a reverie about how lovely Ruby once was and how good it will be to return to it. I don’t think I knew how good I had it with Ruby…but I also never knew what it was capable of (or what I was capable of). So that’s the bet I’m making: two months of alternately infuriating and satisfying hand-to-hand combat with C followed by a lifetime of harmonious cooperation with Ruby and whatever comes next. At least that’s what I’m imagining will happen.

This week’s problem set is, I think, the last of the semester that’s fully in C. CS50 doesn’t actually cover Ruby, but everything we’re about to learn besides PHP will be something I’ve worked with before. HTML, CSS, Javascript and SQL aren’t exactly old hat, and it will be exciting to learn some of the theory behind them; I’ve only ever really used them as point solutions to more pressing problems. But still, they feel like places I’ve visited before—I’ll recognize the terrain. This represents both a relief (aha! a place of comfort!) and a challenge: it’s closing in on time to take everything I’ve learned andget back to making things I can share with the world.

Last time I mentioned reading (and loving) Bret Victor’s latest essay on learnable programming. Soon after, I went to Lamont Library to borrow a copy of Mindstorms, the book Bret cites as an inspiration for many of his lines of thinking. I’m energized by pretty much all of Bret’s lines of thinking, so picking up the book was a no-brainer…and I’m really enjoying it so far, frayed red binding and all. On Erik's recommendation, I also went back and read an October 2011 post by Bret titled “Up and Down the Ladder of Abstraction.” The post is great not only because of the care put into making it readable—all the examples are interactive in a way that makes the words make more sense, not less—but also because you can see the through line to his most recent post, and imagine that same through line stretching and bending into the future. After reading it, I told Erik that I found the emphasis on built intuition heartening. “We learn a lot by studying and playing with these representations, even if we can’t put our insights into words,” Bret writes. “What we are doing here is feeding the pattern-recognizer in our brains, and building up an intuition for how the system behaves.” And this was possibly my favorite moment in the piece: ”To understand a system, we must explore it.” Within Bret’s acknowledgment that many existing systems seem willfully obtuse, there’s this kernel of something I’ve felt in forests and text editors alike: intense, open, eager awareness. That’s what I’m after.

On another thread: Alex Payne recently posted a picture of this whiteboard from Hacker School, and it rings wildly true to me—


In particular, I was interested and encouraged to see that the question “What scares us the most about programming?” elicited more than one answer to the effect of: “asking for help.” In my experience, it’s not so much that the act of asking is so scary, though there’s some of that. It’s more that figuring out how to give enough context that you’re not asking the recipient to be a mind reader but not so much that you’re asking them to do the work for you can be almost as hard as solving the problem in the first place. In fact, many times it leads to the solution without you ever having to go through with the asking, which is kind of cool but also demonstrates just how much brow-furrowing must go into the initial question. There’s also a related problem, called out on the whiteboard specifically: “balance between doing it yourself and asking for help.” I’ll never know how many breakthroughs I’ve short-circuited by asking for help too quickly, but I do know that it’s precisely the four-hour blocks of pure frustration that eventually (after much Googling, staring, and getting up to pace around) dissolve into epiphanies.

There will always be more links, but these are the things I’m thinking about right now.

Code Log 9.27.2012

Notes on what it’s like to write code.

It’s late (or early)—a bit past 2am on September 27, 2012. I just submitted my third CS50 problem set of the semester. It was titled “pset2,” (since, of course, the psets are zero-indexed), and marked two weeks of progress in C.

I feel like I’m finally getting the hang of C. It took some time; Ruby habits are hard to break. Ruby’s the programming language I’ve been using for the past few years, and although at a base level it’s actually written in C, it’s different in a number of ways. Ruby is elegant, forgiving, and unadorned; C is wordy, rigid, and laced with curly braces and semicolons.

I’ve been thinking about whether it’s better to start in Ruby and work backwards to C, or start with C and then move on to Ruby.

I sent Erik this text message right as I started working on the problem set on Sunday night:


Two hours later—just two hours!—I sent a followup:


My original prediction was right: I did feel amazing once I figured it out. And it didn’t even take lifetimes—just a couple of hours.

Looking at the timestamps now, I’m actually surprised that the turnaround was that quick. I remembered it being closer to 6 hours or something. I guess the overall coding session was about that long. But the core of it—the part where I went from despondence to triumph—happened in the slow blink of an eye. Something to remember for next time.

Yesterday, I posted some thoughts on CS50 and how we might start to usefully unbundle classroom experiences.

I read Bret Victor’s new post on Learnable Programming today (on Erik’s recommendation) and felt a surge of hope. Things don’t have to stay the way they are. At this point in my coding journey, I’ve learned to accept (and even appreciate) the sorcery of programming. But Bret’s post opened up my mind to remembering something I’d intentionally forgotten: how painful it is to do battle with a computer’s mental model at first, when it feels at its most unintelligible and unknowable. Bret has some solid ideas on how to change that process; they’re lovingly, persuasively illustrated in motion. Best of all, they’re embedded in a framework more timeless than the suggestions themselves.

In the post, Bret gives Seymour Papert’s Mindstorms: Children, Computers, and Powerful Ideas just about as strong a recommendation as is humanly possible. I figured out that Harvard carries a number of copies in its libraries, so I’ll be tracking one down. (The call number for one copy is sitting insistently in my inbox right now.) I think Erik’s going to read it, too.

Things don’t have to stay the way they are.

Unbundling the Classroom Experience

This year—my sixth on campus, and my last—I decided it was finally time to take CS50, Harvard’s introductory computer science course. CS50 lectures happen twice a week in Sanders Theatre, a ridiculously majestic setting. Yet for all intents and purposes (and completely by choice), I’m taking the course online. 

I’ve tried taking courses online before—I’ve even tried taking computer science courses specifically. But they’ve never quite worked for me. I’ve learned all kinds of things in my time by plundering Wikipedia and following links with abandon, but I’d all but given up on the traditional course format transposed online. CS50 is changing my mind. It’s extraordinary.

Read More

Code Log 9.10.2012

Notes on what it’s like to write code.

CS50 started last week. It’s the introductory computer science class I never took as an undergrad, so I’m beyond excited to be taking it now. We learned all about psuedocode and binary and ASCII and Scratch. I watched both lectures on video (one via simulcast at HBS, one the morning after on my iPad at the gym), which felt like a strange luxury. The problem set was to assemble a small app in Scratch. Looking around my dorm room for ideas, the mobile hanging from the ceiling lamp caught my eye. (Amazon tells me that it’s called “Expecting Fish,” but we always thought of our matching mobiles as whales.) I spent a lot of time tracing photographs of the mobile on my iPad in Adobe Ideas (quite a great app—it smooths out jagged, finger-painted lines) to create some hand-drawn sprites for the app I had in mind. It’s called Hungry Whales in Love. I might try to animate the sprites a bit more before the problem set is due, but I’m pleased by how possible it was to create something cool.


Read More

Load More