In this post I want to talk about having a working model in mind when you code. I’m mainly writing this for people like me, who think of themselves as research software engineers, and who come from a non-traditional background–i.e., you didn’t get an undergrad degree in computer science. Of course, even if that doesn’t describe you, you might want to read, if you’re at all interested in different strategies for writing code to solve research problems. If you are someone like me, who came to research software from experience working in a laboratory or a similar setting, you might feel like you have one strength because of your background, one strategy that helps you problems with your code: you are used to treating some system of interest as a black box, and you have built up a good intuition for how to design and run experiments to figure out what’s going on inside the box. In the lab, if you were studying a gene in bacteria, you might knock out that gene to test whether it plays a role in some physiological process. With computer code, you might comment out a block of code to figure out if it’s the source of a bug. The main point I want to make in this post is that you can take another lesson from science, to make yourself more effective: have a working model in mind when you code. As with that previous post on domain-driven design, I am not claiming that having a working model when you code is a revolutionary idea. I’m sure that for a lot of people it might sound like an obvious idea. But it’s one of those things that I keep re-learning the hard way. So think of this post as more like a nice little nugget that can give you an alternative approach, when you are trying to break down the big problem you’re solving with code into smaller problems that are easier to solve, like computer science textbooks tell us we’re supposed to do. This post is supposed to be like one of Brian Eno’s oblique strategies or a chapter in Writing Down the Bones.
Computer programmers have working models
In a previous post I wrote about domain-driven design, and at the end I said I had to admit that it is not a new idea, because I found it in Structure and Interpretation of Computer Programs (AKA SICP).
I ended up reading SICP because I have begun working my way through the reading list on teachyourselfcs.com. My reasons for working through that could be a blog post unto itself, but suffice to say it is a source of some shame that I ostensibly make my living by programming computers, but I only have the vaguest idea of how computers work, or how programming works, and so I have this need to fix that. Reading books like SICP has also made me realize that, of course, computer scientists think in terms of models of computers, –that is, their domain–and this is why it’s easier to learn about computers by learning about the models that computer scientists use. This is why it’s helpful to learn git by actually learning how git works as others have noted, Reading SICP gives you different mental models of how computer programs work.
A working model helps you avoid getting lost in the weeds
Again, maybe its old news to you, but I feel like I really need a reminder that we constantly build and then throw away scratch models of whatever we’re working on, be it computers or any other domain. One reason I think I need this reminder is that, by its very nature, programming requires us to hyperfixate on details. Building a mental model of what’s going on is one way to avoid getting lost in the weeds.
The other reason I think I need to be reminded to focus on my model of the domain is that I have somehow inherited this notion of a programmer as a modern conjurer; that I should sit before the blank screen emitting cryptic incancations until the program emerges fully formed. Like a cyberpunk Zeus with code children sprouting from my forehead. I am mixing Greek mythology and wizardy in my metaphors. Whatever, you get the point. Given that SICP has the nickname “The Wizard Book”, I can’t be the only one who falls into this way of thinking— that programming is modern sorcery. I still remember with some shame the time I went to a meetup, a Python Atlanta “jam session” that welcomes beginner programmers, and an older woman who was doing one of the “koan” exercises was writing notes on a legal pad while she worked. I asked if she was in fact taking notes, and she very kindly replied “yes, I always take notes when I work.” I was dumbfounded. “You can do that?” I thought to myself. I thought I had to hold all the pieces of the problem in my head at the same time. Reminding yourself that you need to have a working model of what you’re doing is another way to avoid this tendency as well.
In general, you should have a theory of your code, just like a cognitive scientist should have a more-or-less formalized theory of cognition they are trying to test.