I am one month into my internship, and I’ve realized that I’m enjoying it.

Alright, I’ve known all along that I’m enjoying this. But it feels like a qualified decision now. This isn’t the awe of new things like, “wow I enjoy working”, or “ooh pretty city”, it’s a genuine appreciation of having a good thing going on.

I work on Webkit. That’s pretty cool. If you already know all about how webkit works, you can go find out what stuff I’ve patched by looking around in the bugzilla. If you don’t know how that stuff works, then I don’t expect you to care – it’s not very important anyway. I’ve only done test conversions so far, and a few other small things. I’m taking some bigger steps now, as I try to make a few actual code changes in the editing section – a cool 33 thousand lines of code among 60 files. Ramping up to speed on that is what this post is about.

My approach to this is holistic, which might be stupid of me. My fundamental assumption is that the better a programmer understands the system they are working within, the better a job they are able to do. I suppose that for an ideally modular system in a perfect world that might not hold, but I think it does here. I invite debate on the topic, but ask that you bring a) evidence which suggests I am wrong or b) viable alternatives to what I’ve said. If we simply disagree, we won’t be productive 😛

So, the “holistic approach”. I’ll define that as something akin to top-down, or biggest items first. Within the editing code, there’s a class ‘Editor’. It’s a pretty sizeable class – between its headers and implementation, it’s 3-4 thousand lines long. There’s a lot of other smaller classes, too. What my approach means is that I’ll read Editor’s high level definitions, then all of its methods, and as I find things which I don’t understand, branch into them and do similar. This search is a sort of optimised depth-first — only when something seems vital, common, and confusing will I break my task and go investigate it.

In this way, you can get a large chunk of understanding in a go. I spent 10 hours or so at the end of last week reading Editor.h/Editor.cpp and branching into some other important seeming code like Page, Frame, Node, EditorClient, and others. It seems to have gone pretty well. What seemed at first like a very confusing and scary bunch of code is now beginning to fit to a mental model: the Editor has a Page and a Frame and manipulates Nodes, and has all of the “policy information” about editing actions. The editing itself is done by the EditorClient, which is implemented separately by each of the different platforms that have ported Webkit. This large-scale picture makes the task feel much less daunting. I’ll draw an analogy.

Imagine you have a large puzzle with small pieces. The biggest clue for solving it is lookng at the picture on the box. With that frame of reference, you can identify the large objects you have to work with. That’s the first step in the recursion: you broke 1 big problem down into a group of smaller problems. Now the work is to treat each of these smaller problems in the same way: find a key feature or element, and identify subelements in relation to one another. Eventually, you’ll be working at the granularity of single puzzle pieces. Stepping back to code — you’ll eventually reach the granularity of single lines.

I’d like to hear people’s strategies for understanding large, complex, and at times roughly defined systems. I’m very interested in education, and at a certain level of abstraction, I think that all attempts to learn things are attempts to construct mental models which help us navigate complex systems. So I implore you – share your insights 🙂