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.

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.

Over the years, I’ve put together a few public technical talks where the slides are accessible on this site. These are only really nice to view on desktop, and require the use of arrow keys to move around. Long-form notes are also available — generated by a sweet Sphinx and reStructuredText plugin. I figured I’d link to them all here so I don’t lose track:

One of the most-often quoted lines about estimation is “Hofstadter’s Law”, which goes:

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

If you want to deliver inaccurate information to your team on a regular basis, give them a 3-month-out product development timeline every week. This is a truism at every company at which I have worked over a varied career in software.

So, estimation is inaccurate. Now what?

Why do we need a product delivery schedule if it’s always wrong?

There is an answer to this question, too:

Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. [Good schedules] make your product better, delight your customers, and — best of all — let you go home at five o’clock every day.

This quote comes from Joel Spolsky.

So, planning and estimation isn’t so much about accuracy, it’s about constraints.

I am a longtime Thinkpad and Lenovo user as my preferred laptop for Linux computing and programming.

The Lenovo X1C 2016 4th Generation Model is my latest Linux laptop

For some context, I’ve been running Linux on my desktop and laptop machines since ~2001, and started using Thinkpads in this role starting with the famous Thinkpad T40 (2003), one of the first laptops that provided good Linux support, a rugged design, portability, power, and an excellent keyboard.

I then moved through a few different Lenovo models: the T400 (2008), the T420s (2011), and the X220 (2011).

I spent a couple of short stints in-between — which I always regretted — on other PC laptop models, including HP and Asus. I upgraded from the T420s to the X220 after coming to the realization that portability and power consumption mattered more to me than the 14″ form factor, and that I could easily expand the X220’s limited hard drive with a 512 GiB SSD.

Since 2013 or so, the X220 has been my main programming/Linux machine. The X220 was my favorite Thinkpad model of all time, despite some flaws. I’ll discuss my Linux desktop experience with the X220 briefly, and then go on to my experience with my current model, the Lenovo X1 Carbon 2016 model (4th Generation).

So, doctors are to blame for setting the prices for reimbursement by private health insurance companies? And they are also to blame for pursuing extra years of low-pay resident/fellowship training so that they can do advanced procedures and be paid decently for their work? And, they are also to blame for “defending their turf” within a specialty — that is, for specializing at all?

And, this article is even written by a doctor?! Why, yes, of course, it is!

I think medicine may be the world’s most self-hating profession. Trapped inside a system that takes advantage of their altruism, ridiculous work ethic, and decades of training, they can’t help but blame themselves even as the capitalists around them exploit them.

I wrote a letter in support of net neutrality and Title II classification of Internet Service Providers to the FCC. For background on this FCC vote, you can read this Arstechnica explainer.

You can add your own comment in support of net neutrality to the FCC at the URL gofccyourself.org. To clarify some terms:

“net neutrality” is a term coined by Tim Wu (author of “The Master Switch” and “The Attention Merchants”) which describes a legal principle that “Internet service providers and governments regulating the Internet should treat all data on the Internet the same, not discriminating or charging differentially by user, content, website, platform, application, type of attached equipment, or mode of communication.”

“title II” is a part of the Communications Act of 1934 that establishes that certain forms of communication infrastructure are “common carriers”, which means that in delivering Internet service, the ISPs “cannot discriminate [content/services], that is refuse the service unless there is some compelling reason.”

Back in 2013, we had achieved initial product/market fit, initial revenue, and had already established a kernel of a product and engineering culture. I knew the company would change, but I wasn’t sure exactly how. Meanwhile, I had just recently read “Reasons & Persons”, a book on ethics and identity by the philosopher Derek Parfit. Though his ideas focused primarily on individuals, they influenced the way I thought about my business, my team, and its evolution over time.

What follows are my speaker notes from a talk I gave to my team to discuss the issues of Ethics and Identity central to Parse.ly’s culture:

Michael O. Church wrote an essay awhile back called “Why programmers can’t make any money.” The post is no longer on his website — for some strange reason — but you can have a look at the archived version here.

If you don’t wish to read his post, this quote will give you the summary.

When the market favors it, junior engineers can be well-paid. But the artificial scarcities of closed allocation and employer hypocrisy force us into unreasonable specialization and division, making it difficult for senior engineers to advance. Engineers who add 10 times as much business value as their juniors are lucky to earn 25 percent more; they, as The Business argues, should consider themselves fortunate…!

I empathize with his thoughts, but I have struggled — for years, now — to understand the author’s conclusion.

If we want to fix this, we need to step up and manage our own affairs. We need to call “bullshit” on the hypocrisy of The Business, which demands specialization in hiring but refuses to respect it internally. We need to inflict […] artificial scarcity.

I decided to (finally) publish this response today because I have seen artificial scarcity play out in another industry; my wife is a medical doctor in the US. Are we to believe that programmers should establish artificial scarcity in the same way that doctors have — with political organizations like the American Medical Association and credentialing via something equivalent to medical school and board certification?

Apple just announced that the headphone jack is going the way of the dodo, but as programmers, we know better. The headphone jack is our reprieve from cantankerous office banter, our salvation from your office mate’s obsession with cat videos, and our gateway to productive coding flow.

For those of us who still believe in the simplicity and beauty of the good old auxilliary audio input, here are three headphone options that I’ve field tested extensively and can vouch for quality and convenience.