The Structure and Interpretation of Computer Programs (SICP) is a classic computer science text written by Gerald Jay Sussman and Hal Abelson. It is widely known in the computer science community as the “wizard book”. It intends to teach the foundations of computer programming from “first principles”, illustrating programming language design using Scheme, a dialect of the Lisp language.
In this context, from Aug 26 – 31 2018, I am taking a “think week” to reflect on my relationship to computer programming.
I am spending this week in Chicago with David Beazley (@dabeaz), where we will be spelunking through the land of this famed SICP textbook via Racket, a modern functional programming environment one can use to program in — and even extend — Scheme and many other languages.
The course will also (of course) involve some Python. This will be a fun follow-up to an earlier course I took with Beazley in 2011, “Write a Compiler (in Python)”. I can’t believe I wrote the code for that course over 7 years ago.
Back in 2011, I took “Write a Compiler (in Python)” with David Beazley. A handful of long-time professional programmers and Pythonistas, locked in a room together for 5 days, hacking away on a Python compiler for a Go-like language. It was so much fun. It proved to me that I loved programming! I’m the one whose head is exploding on the left.
How I’m thinking about this course
I have long identified primarily as a computer programmer. I studied Computer Science at NYU, and I currently read about programming languages, paradigms, and design patterns all the time. I have read way more technical programming books than any other category or genre of book.
But, I’m also someone who is interested in the business of software, and leadership of software teams, in a sort of secondary way to my love of software itself. Business books — and particularly books about high-growth startups and their teams — make up my other big obsession. But, in the last several months, I’ve seen my relationship with software change in a number of ways.
First, as of April 2017, I have not written any “production” code for Parse.ly systems. Last year, I wrote some code for an important production system (in C, no less!) right before starting the process for Parse.ly’s Series B financing round. That round closed in August-September 2017. Once that was done, I spent the next several months running a hiring process for Parse.ly’s team, as well as kicking off several projects to extend our core products and to launch a brand new one.
All of these product initiatives had their major code and engineering contributions by the amazing Parse.ly product team, but I pulled myself completely out of all coding projects to focus exclusively on recruiting/hiring, mentorship, and product management.
This was the right move from the standpoint of Andy Grove’s concept of High Output Management, that is, I was applying the concept of “managerial leverage”. With a team of 12 backend engineers, 5 frontend engineers, 5 support engineers, and several designers, I could do much more as a “force multiplier”, and even as a “project clarifier”, than I could do writing any single line of code.
But this transition was a struggle for me, personally. After all: it was the first time in ~15 years where my work no longer included directly writing and shipping code that makes products work. In other words, I was no longer in the practice of programming. And, to reference Paul Graham, I had shifted from a maker’s schedule to a manager’s one.
So, how does this all relate to functional programming, SICP, and my “think week”?
Making coding a hobby again
Well, I’m going to spend next week figuring out whether coding should continue to be my hobby.
It started as my hobby, and became my profession, and it’s now the technology lifeblood oozing through the company on which I spend my mental energy every day. But that company needs me much more as a technical leader and manager than it does need me as a coder.
I suspect coding should remain my hobby. And that I should write more (in English, and in code).
I suspect, similar to my explorations with Clojure a few years ago, by looking at different ways of programming, it can help refresh my brain, but also help me re-establish my “hobbyist” relationship with programmer tasks.
It may not (ever again!) be wise for me to insert myself into complex and time-sensitive production coding projects at Parse.ly, but it may still make total sense for me to treat coding as one of my important “satisfying thought-work” activities, alongside writing and reading, which are the other two big ones for me.
If coding remains my hobby, I can establish a healthy relationship with it as a hobby. And that would be good for me and my own identity. Then I can shift my mind toward applying my coder brain toward challenges that truly change the way I think about automation and problems. Perhaps it can also change how I think about design of systems and of code.
Programming should be fun. It was when I started, and I still miss it. I’m hoping Beazley’s course is a little kick in the butt that I can make time for it as a hobby, once more.
This year, I began my professional transition to, “I am primarily a recruiter and leader of technical teams that operate on the fully distributed model and that ship high-growth products with a huge business or societal impact.” But I still want to be extremely close to code — now, and for the rest of my life. I can focus on technical leadership at Parse.ly with little guilt — to know I have not thrown out my passion, and the thing that gives me my edge.
About 15 years ago, the open source community introduced me to Python, and it changed my life as a programmer forever. But, about 10 years ago, a sage programmer I deeply respected handed me the book “The Anatomy of Lisp”, and said that if I could read and understand that book, then I will have truly combined my computer science education with my practical programming experience, and be forever bettered for it. I tried to crack that book open over the years, but I never had the functional programming fundamentals to make it very far. Here’s to hoping that a guided path from Python to Racket to Scheme to SICP gets me one step closer to enlightenment.