19 Jul 2020
Another good reason to begin documenting your Theory of The Program: it’s a way to combat the death of the author. If you have explicitly written down the intentions of some software, and what it assumed, then others cannot add assumptions onto you in the future. You are also forced into honesty about what you initially considered and how you perceived the world. (From reading ferd.ca’s thoughts on language and inclusiveness)
Recently, I was reading Marc Booker’s post about the need for documentation outside of the codebase.
A thoughtful comment on the post led me to Peter Naur’s paper on Programming as Theory Building, which I recommend reading.
In it, Naur argues that the act of programming is not a practice of writing code but the work of creating a theory of the problem at hand and a theory of the system to address it.
As a team exercise, we practiced documenting our theories of the OfficeLuv system and found it very rewarding.
14 Jun 2020
It is not enough to simply architect a system or solution. You must create a story, a path through it, from your current state to multiple end states. If you simply present a picture of end state, members do not know what to do to contribute. The path and the narrative is the actual useful solution. Architecture or solution alone is an empty vessel.
31 May 2020
Listening to win vs. listening to fix vs. listening to learn. The default position for engineers and executives is listening to fix. You’re employed to move things forward and solve problems. Sales’ default position is listening to win - to convert the sale, listening to sell. But good product work requires listening to learn. You can fix it later, iteratively, but first you need to soak it in with no idea on how to fix it. (While listening to Jennifer Garvey Berger.)
31 May 2020
Code performance, reliability, security, cleanliness. These things are not achieved through big sweeps and special efforts. They are only really possible by baking the practices into every day and each decision. You can’t focus on fixing them for a week. You need to invest in them slowly, constantly, over the life of the project. (Thoughts after reading about why NetNewsWire is fast, listening to a code audit webinar, and thinking about how we’ve done so much with 2 engineers at OfficeLuv.)
Reading The Making of Prince of Persia journals, by Jordan Mechner, is energizing and stressful. They are the journals of a 20-something year old developer and writer. Every interaction is dramatic or consequential or fraught. Every downbeat or still moment is an existential crisis. I couldn’t read it before bed because it would keep me up at night. I finished reading it this afternoon and I was pacing back and forth during the last hundred pages.
I finished So Many Books (Gabriel Zaid) a couple months ago but the main points have been rattling around my head since then. The book reads like a series of essays, focusing on (in relative order) the habits of book collecting, habits of reading and comprehension, growth of publishing, and the economics of publishing. It’s a short book, makes a dry topic very interesting, and makes arguments relevant in today’s world of self-publishing, blogging, vlogging, and all else.
I was generously gifted Lab Girl by Hope Jahren through Jane Kim in her last week at OfficeLuv. I finished it today, after about a month.
After reading her excerpts from the last few months, I picked up Ellen Ullman’s Life in Code. I finished the collection of essays yesterday.
My brother’s gift to me this Christmas was The Undoing Project, a novel by Michael Lewis on the work done by researchers Daniel Kahneman and Amos Tversky. I read it from December 27 through January 1.
I’ve sent these thoughts & instructions to friends more than once, so I should probably write them down.