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.
Continue reading Expanding my mind, once more, with functional programming
From Good Business, by Mihaly Csikszentmihalyi, the author of Flow.
Another condition that makes work more flowlike is the opportunity to concentrate. In many jobs, constant interruptions build up to a state of chronic emergency and distraction.
He goes on:
Stress is not so much the product of hard work, as it is of having to switch attention to from one task to the other without having any control over the process.
Continue reading Flow and concentration
Engineers hate estimating things.
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.
Continue reading Software planning for skeptics
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.”
Continue reading In support of net neutrality
In September 2013, my startup, Parse.ly, had just raised Series A capital, and had just begun growing its team rapidly, from a small group of fewer than 10 to over 40 employees now. In the past several years, I have run Parse.ly’s fully remote engineering, product & design team.
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:
Origin of this talk
- Parse.ly turned 4 years old in May 2013
- I reflected after our Series A round
- I read a book about ethics/identity, Reasons & Persons
- Realized some interesting concepts apply to firms, too
Parse.ly, different takes
- “An analytics platform for large media companies?”
- “A startup founded originally in 2009 at Dreamit Ventures?”
- “A team of employees?”
- “A specific configuration of tech and code?”
What is Parse.ly, really?
- our history?
- our appearance to customers / press?
- our employees (or founders)?
- our technology / product?
- our shareholders? (huh?)
Ship of Theseus
What is the Ship of Theseus?
- They took away the old planks as they decayed
- … putting in new and stronger timber in their place
- One side held that the ship remained the same,
- … and the other contended that it was not the same.
Continue reading Parse.ly Culture: Ethics & Identity
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?
Continue reading The value of money in a technology career
Can pair programming be done in a way that is compatible with async communication?
Pair programming is described by the original c2 wiki as a process in which “two engineers participate in one development effort at one workstation”. It would seem the process is inherently synchronous, at least as originally described and practiced.
I experimented with pair programming at my first industrial programming job at Morgan Stanley. It was 2006-2008 and two fads were happening in parallel: “agile” software management techniques and “extreme programming”, with a particular emphasis on test-driven development with Java.
I occasionally found pair programming to be effective, but noticed my results varied wildly depending on the engineer I paired with and the problem we worked on. Some people really enjoyed the “brain swarming” of having two heads attack a problem. Other people found it cumbersome and interruptive. Some problems seemed so indivisible that it always ended up that one person drove, and the other person merely watched. In the end, I couldn’t really say whether I benefited from it, despite many hours of experimentation.
Continue reading An async kind of pair programming
I realize now that one of the hardest parts of running a successful startup is “betting” on tech stacks that, 3 years out, will have a groundswell of community support around them.
It’s still shocking to me that when I chose each of the following technologies as a central part of Parse.ly, they were so new/immature as to not even show up on a Google search trends box, but are now very popular technologies.
Continue reading Picking tech stacks
In 2009, Jack & Russ hacked on an early prototype of SeatGeek for the Dreamit Ventures summer class in Philadelphia. The initial prototype came together in the last two weeks before demo day. I remember that Russ hadn’t shaved in weeks because they were spending every night hacking.
You see, before that, the founding pair knew they wanted to start a company, but they weren’t sure about the idea. They had brainstormed ideas ranging from “WebMD for pets” to “amateur art marketplaces”, finally landing at “Yelp for Bloggers”, an idea they called Scribnia. This got them into Dreamit Ventures.
Continue reading What entrepreneurship really looks like
From a poster at Hacker News commenting on The New Yorker article, Inside the Collapse of The New Republic:
I think I’m exactly the audience that TNR wants. I’m well-educated, make a good living, largely agree with them politically, enjoy long-form journalism, and am familiar with the brand and its history.
Yet I don’t think I would ever subscribe to TNR. I just see a magazine as something that’s going to pile up in my house. I can read more than enough great content online for free. If I was going to subscribe to a magazine, I think that The New Yorker is a lot more interesting than The New Republic.
Take note, journalistas. This is how your readers view your stuff — not as a “public trust”, “a voice”, or “a cause”, as TNR was described by the exiting editors in their resignation letter.
For better or worse, readers view your stuff as a product. And a product, to be bought, let alone used, needs to be useful.
Continue reading The New Republic as a product