Thinking away from the computer

Over the past week I started to work on the implementation of the programming language for my honor thesis. On Monday I created a fresh Git repository and started writing some code. Though I sat in front of a machine for close to three hours, my total contribution amounted to about 50 lines of C, almost all of which was just struct definitions. I did solve some problems but there were a lot more implementations questions that I left answered (including most of the important ones). Suffice it to say that at the end of Monday night I felt like I really hadn’t accomplished that much.

I suppose that one problem could have been the annoying sophomores sitting at the other end of the lab complaining about their CS102 homework and checking Facebook and setting their party schedules instead of actually doing any work. However, the more important reason is probably that I sat down with the expectation of just being able to write code and do my thinking on the fly. That’s worked in the past, but thinking back on it, that only strategy only really works when I have a solid problem description and a good idea of what it is I’m trying to build. When I’m working on my thesis though, the question is a lot more vague and I have a much less definite idea of what I’m trying to build. Sure, I know the features I want my language to have, but it’s a different question entirely of how I’m getting there.

Yesterday I took a different route. At around 8pm I found myself in the odd position of having a half-hour until I met a friend to talk about homework. Now I generally consider half an hour to be too short a time to do anything really productive (unless it’s something simple like looking up papers or websites). But for some reason I decided to sit down in and think about some of the problems that had stumped me the night before. I found a nice comfy couch in the library and pulled out a simple lab notebook that I carry around with me all the time. I spent about 5 minutes just rehashing what I’d already written out in C code and making some changes. But in the 15 minutes after that I came up with (what I consider) a rather decent solution to one of the more important problems that had stumped me the night before.

I was really surprised that I could do in 15 minutes what had taken up more than 3 hours the night before. I’m aware of a lot of evidence that suggests that the best ideas come after your brain has been soaked in relevant information and thought patterns for a while. In that light, it’s perhaps not surprising that I had a eureka moment after a night of concentrated thought. However, I think that a significant part of the problem is being able to step away from the computer. Despite the fact that I love writing (both code and text) as a form of “thinking out loud” and that I don’t usually go into rapid task-switching when I’m “in the zone” on something, I think that sometimes just the very act of staring a screenful of code can make you blind to solutions.

The blank text editor buffer is a scary place. You’re sitting there trying to write the awesome piece of software that’s going to change the world and make you a billionaire in the process, and you have absolutely no idea how to start. While I’m all for starting out small, building a prototype and taking it from there, sometimes even getting started can be a pain. The second problem is the very nature of programming itself: it’s all about rules and structures. You’re writing in a language with syntactic and semantic constraints, you’re building a system of complex rules and systems and it can be very easy to get bogged down in it or get overwhelmed by inertia and keeping going down a wrong path (without even realizing that it’s the wrong path). While having rules and constraints can and do make a design better and leaner, at some points you need to relax the rules so that you can get a higher level view of things. After that you can come back down to earth and start making things fit the rules of the system.

For me my problem was that I was trying to write functional code while all the design ideas I had were very high level. I needed to establish some sort of middle ground so that I could make low-level design decisions without having to fit it into syntactically correct code at the same time. Unfortunately, while I was sitting in front of my machine with my Emacs buffer open, all I could think about was C structs and functions. Being able to sit down with a pencil and paper and no computer in sight allowed me to take a step up and do design work without being tempted to produce correct C code. At the end of my 15-minute eureka session last night, I had about 10 lines of pseudo-code and 3 diagrams that specifying a concrete implementation of what I needed to build. Since it’s not actual C code, it’s going to need some work to get implemented, but it’s a great start.

Right now I have about 6 hours a week (two 3-hour blocks) that I plan on devoting to implementation work. I’m going to be setting aside another hour or two in the week to do computer-less work. I’m a great believer in creating your own luck so I’m interested in seeing just how lucky I can get.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s