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.