Since becoming a CTO, I’ve had a major uptick in spam, everything from thinly veiled LinkedIn connection requests to blatant direct emails. This one was particularly funny:
Oh Brian, you have a delightful sense of irony. Your products probably won’t solve my unwanted solicitation problem, but your marketing attempt did bring a smile to my face, and for that I thank you. Now go away.
Generally speaking, people want to know they’ve made a difference in the world that will outlast themselves. Few occupations have the intense immediacy of potentially giving one’s life for the future of human flourishing than that of the solider. It’s an admirable profession that is worthy of respect, especially for those for whom this potential became reality. However, not many are suited for such work, not to mention ideally the need for soldiers will shrink as societies mature.
Thankfully there are myriad other ways in which a person can approach a career with the future in mind. Last week I read through a number of articles from 80,000 hours, and I have the book of the same name queued up as well. The premise is that our jobs take up a considerable fraction of our lives, likely more than any other activity, and thus it behooves us to think deeply of how to spend that time. That’s hardly controversial, but applying logical principles and data-backed guidance to maximize the future impact can be (similar to discussions around Effective Altruism).
Personally, I find the arguments compelling. It’s why I’ll spend the rest of my time as a technologist dedicated to work in the public sector, and especially in the space of tech and politics. When it comes to maximizing human flourishing, good public policy is critical, and with a shrinking world, the risk of bad policy existential.
Many have died to give those who remain the chance to build this better world. Honored to be among the latter group; don’t intend to let it go to waste.
As of today I have a backlog of 49 draft posts going back to 2017. A good chunk of this backlog, especially recently, centers around themes of maintenance, longevity, sustainability, and generally making sure that work outlasts oneself in some form or another. It’s obviously something on my mind.
So when I sit down to write, why do I most often start with something new instead of picking up an old draft? I suspect it has to do with a fresh take being more motivating. For today, that motivation was my completion of the La Jolla Half Marathon. It’s a race I’ve run before, though it’s been six years.
What’s the relevance to the theme that I mentioned earlier? It’s not only that I am still able to run it despite being in my mid-40s, but that I beat my prior time by over 10 minutes (today’s result was 1:56:05). Which means my years of running has created the kind of habits that enable successful long runs with little to no additional preparation (I only signed up for this race three weeks ago, and thus didn’t have much margin to do a ramp-up beyond my normal weekly miles).
Similarly, while I don’t code every single day (nor should I, it’s not the focus of my current role), I aim to do enough programming regularly so that I’m ready to do more if a situation calls for it.
There’s probably also something to learn here about the long-term benefits of keeping systems running that are doing their jobs as designed and continue to provide value, versus continually looking to replatform and rebuild.
In short: maintenance matters.
Yesterday I closed the book on my job with Amazon Web Services. It was a truly great gig; I was able to help numerous public sector customers advance their missions, grow both my technical and business skills, and work with some great people. But on Monday I start a new adventure as the Chief Technology Officer of Research Improving People’s Lives.
Officially, “RIPL is a tech-for-social-impact nonprofit that works with governments to help them use data, science, and technology to improve policy and lives.” But if you want a better sense of what I’ll be up to, these two opinion pieces by my colleagues are a great place to start:
I’ll have a lot more to say in the coming days about what led me to a new role, the emotions involved in transitioning from a job you love, and how to end your time at a company well. But since the cat’s out of the bag given my updated LinkedIn page, I wanted to get an announcement made here also.
Several months ago I had a need to cache function results across multiple executions of an API client. A quick web search revealed several solutions, the best fit being cachier. However, it was still missing a few important features I needed, and thinking it was the quickest solution, I wrote up a wrapper to implement these features and published it on PyPI.
One of the features was particularly tricky to get working without modifying cachier itself. Though I did get it working, I regretted not instead simply seeing if I could build my needed capabilities into that library itself and avoiding the wrapper altogether.
Turns out I had some additional free time, and took a crack at an integrated implementation of three key features, and turns out the maintainer of cachier was grateful for the contributions. I was also able to make additional improvements, which benefit all of cachier’s users, not just the one user (i.e. me) of a wrapper which is unlikely to get popular.
This experience was a good reminder that open source software is not built by a mysterious group of “other people” but by ordinary folks who graciously offer their limited time for the public good. Considering how much I’ve benefited from such generosity throughout my career, I’ve been thinking about what responsibility I have to the broader community. I’m not the only one. Do I have a professional obligation, or even a moral one, to contribute? Quite possibly, but either way, it’s something I’m going to do as long as I’m able.
Klaus Teuber died this week. His career began in dental hygiene, but by its end he’d designed one of the world’s most influential board games, The Settlers of Catan. I learned it about 20 years ago from a college buddy, and right away fell in love with its balance of strategy and luck. Enough of the former to make it interesting, enough of the latter to appeal to a broad audience. It also requires deft handling of social dynamics through alliances, trades, and the occasional threat.
It’s hard to overstate the influence this game has had on my life. Quick games of Catan formed early bonds between myself and my wife during the stress of having young kids. When we moved to San Diego it was a vehicle to make new friends in an unfamiliar area. And it’s been a staple of family game night since my children were in middle school (I still remember exactly where we were when we taught them to play for the first time). The above photo is from a game played just last night (I’m green, and I won with 4 cities and longest road).
I once read that a typical person will have a direct influence on 10,000 others over the course of a lifetime. No idea if that’s true (or what “typical person” could even mean), but the point remains that whatever influence we each have, it’s likely larger than we think. Certainly Klaus Teuber had no idea that his game would affect me and my family so positively. But I’m thankful nonetheless.
When I die, it won’t really matter what systems or organizations I’ve built, but it will matter how those systems and organizations have influenced the people involved, and promoted human flourishing more broadly. My tools are technology, but they’re not the goal.
As I get older, the more I’ve reflected on ways I can give back to organizations and communities that have had a big influence in my life. It’s why I contribute to open source projects. It’s why I respond to Stack Overflow posts (or at least try to periodically). And it’s why I give to the Wikimedia Foundation.
Despite it’s quirks and occasional inaccuracies, Wikipedia is a modern miracle of information that has shaped countless lives in inestimable ways. I find their mission statement a beautiful ideal: “a world in which every single human being can freely share in the sum of all knowledge.” Knowledge isn’t everything, but it’s a significant something; a necessary ingredient to human flourishing. And I’m happy to do my part to increase its presence in the world.
Don Norman came to mind today, a not uncommon occurrance. I’ve mentioned him before, but not loudly enough. If you care at all about building great solutions, technical or otherwise, reading The Design of Everyday Things is a must. Here’s my favorite passage:
The idea that a person is at fault when something goes wrong is deeply entrenched in society. That’s why we blame others and even ourselves. Unfortunately, the idea that a person is at fault is imbedded in the legal system. When major accidents occur, official courts of inquiry are set up to assess the blame. More and more often the blame is attributed to “human error.” The person involved can be fined, punished, or fired. Maybe training procedures are revised. The law rests comfortably. But in my experience, human error usually is a result of poor design: it should be called system error. Humans err continually; it is an intrinsic part of our nature. System design should take this into account. Pinning the blame on the person may be a comfortable way to proceed, but why was the system ever designed so that a single act by a single person could cause calamity? Worse, blaming the person without fixing the root, underlying cause does not fix the problem: the same error is likely to be repeated by someone else.
The notion of system error is quite profound, applicable to technology, organizations, governments, even entire civilizations. Leaders of all stripes do well to consider its explanatory power.
Just discovered that Don has a new book coming next month: Design For a Better World. Pre-ordered!
Read these two articles yesterday. On the surface they’re about different topics, but there’s a common thread: both call out an aspect of technical work that is often ignored, especially by the less-experienced.
The first tale, Our Company Fired the Best Developer and Project Manager, reminds us that “Getting your tasks done is half of the job. The other half is how you do it.” I’d go even further and say getting your tasks done is only a quarter of your job. The rest is how you do them, when you do them by, and most importantly, ensuring you understand why those are your tasks in the first place, and if perhaps you should be doing other tasks instead. Don’t climb the ladder only to find you leaned it against the wrong wall.
Coding Won’t Exist In 5 Years is yet another ChatGPT article, whose crux is the following: “Programming is the process of solving problems using a computer. Writing code is just one aspect of this process. It’s a necessary part, but it’s not the whole picture.” Yes, learn to write code well, but be aware you’re more valuable as an editor than as a drafter, and that’s only going to get more true as AI gets better.
I agree with this article that there’s a special joy that comes from building something to suit your own needs. But that doesn’t mean you shouldn’t share the results. You’ve got to store your artifacts somewhere, so might as well stick them in a public spot like Github. Perhaps someone else will find your work interesting and useful, not the least of whom might be an interviewer who needs examples of your code to do a proper evaluation.
Here’s a rundown of projects for which I am either the primary author or significant contributor, grouped roughly by subject matter. I capture them here for the value of having such an index, but also because some of it I believe has value. If any of you find such value, would you let me know?
Buy Me A Coffee Webhook – I wrote about this project two weeks ago, it’s a CDK-deployed Lambda function with an HTTPS endpoint that can receive webhook notifications from Buy Me A Coffee.
Temperature Collector – Another Lambda function, but this one deployed using terraform. It gathers temperature data from heterogeneous sources and publishes it to CloudWatch. I’ve also written about this one before; if nothing else it’s a reference example for how to use terraform modules.
Selenium Lambda Layer – It’s tricky to get all the right bits in place to get a headless browser working with Selenium in Lambda. Given how browser tech evolves, I doubt this still works, and if I have to do it again, my first choice would be CloudWatch Synthetics Canaries instead.
Lambda Layer Builder – When packaging dependencies, I prefer keeping them in a layer vs including them in the Lambda deployment package itself. It keeps the deployable package small, and ensures I can edit code directly in the console when I need quick turnaround. This script makes it a one-liner to construct and upload a layer that contains a set of either Python or Node.js dependencies.
Managed Blockchain Document Ledger – As part of a customer workshop I built this fully-functional example of using Amazon Managed Blockchain to write and read documents to Hyperledger Fabric. It illustrates how to create the network, set up users, load chaincode, front with an API Gateway and Lambda function, and deploy Hyperledger Explorer for visualizing the contents of the blockchain. It’s all automated using CDK and bash scripts.
Hyperledger Fabric CDK Construct – As I was developing the above, I realized there could be value in porting the capabilities provided by the bash scripts into custom resources, and packaging it all up into an easily installable CDK construct. This was my first foray into publishing a construct, and I learned a ton about it, in particular how to use projen to deploy a full CI/CD pipeline and get support across all CDK-supported languages.
Ethereum CDK Construct – Essentially the same as the above, but for Ethereum-based blockchain networks. I can only take minor credit for this one; while I gave them the idea, most of the implementation was done by an early career cohort as a capstone project.
Lilypond Music Files – Analogous to LaTeX for academic whitepapers, Lilypond is a text-based markup language for engraving (i.e. typesetting) sheet music. I created this repository as a place to collect my own by-ear transcriptions of bass guitar lines. There’s not much in there; consider it an aspirational life goal to add more (what would be extra rad is if this could be automated via AI/ML, with a tool like melody.ml).
Mix Maestro – I’ve been mixing live audio for nearly 20 years, on both analog and digital consoles. Back in 2013 I was doing so on a Roland mixer that had an RS-232 interface for remote control, and I wanted a way for musicians to adjust their own levels without buying an entire Aviom setup. So I grabbed a Raspberry Pi and wrote an HTTP server that abstracted the details. This repository contains the server code; I also wrote a companion Android app.
Light Maestro – Similar to Mix Maestro, I needed a way to control stage lighting, but without any budget to buy a console that had an app. Not only was I able to get a DMX interface built on top of another Raspberry Pi, but I was able to synchronize scenes to ProPresenter via its ability to trigger audio file playback, which I detected using Linux atime changes. Kinda hacky, but it worked more reliably than the bargain basement light board and the inexperienced volunteers that ran it.
Project Euler Solutions – If you want a fun and nerdy way to practice coding, Project Euler is a great resource (and more fun than Leetcode in this mathematician’s opinion). This repository contains my solutions to all the problems I’ve solved to date.
Buildozer – I love Python a lot, and sometimes that means I want to use it for projects where it isn’t typically considered, such as cross-platform GUI app development. With Kivy, it turns out to be quite possible. Buildozer is a framework for building Kivy apps for Android and iOS. Getting its dependencies right is a pain, especially on MacOS, but Docker to the rescue!
LaTeX – Back in graduate school I earned money by typesetting academic papers for mathematicians (such as the esteemed George Andrews) using LaTeX, a typesetting system built by none other than Donald Knuth, one of the giants of computer science (if you haven’t read The Art of Computer Programming, you really should; those folks were geniuses in ways modern developers rarely appreciate). Anyhow, LaTeX is also one of those tools that’s tricky to get set up, so it’s a perfect fit for running in Docker.
AWS CLI Profile Credential Helpers – Early in my tenure with AWS, I was working with several customers simultaneously, each of which had its own single-sign on solution for their accounts (e.g. Azure SSO, Okta, Shibboleth). In order to abstract away the details of each provider’s mechanism for getting temporary credentials, I built this wrapper, along with a handful of other useful utilities. I’ve used them daily ever since.
Amazon CloudWatch Publisher – Another tool that came directly out of customer work, I needed a way to publish basic CloudWatch metrics (like CPU usage, disk space, network traffic) from Apple hardware, which would not (at the time) run the CloudWatch agent. I decided to build it in Python (natch), which has the added benefit of allowing it to run on other platforms such as the Raspberry Pi.
Kubernetes Tools – It took me a couple months of regular usage to get comfortable with kubectl. Once I could rattle off most commands from memory, I found myself doing similar things over and over. Hence these wrappers. I stuck them on Github for posterity, and am glad I did.
MacOS Dotfiles – Since I made the switch to MacOS (and its Linux-like terminal) in early 2014, I’ve had 4 employer owned and 2 personally owned Apple computing devices. Not changing that any time soon, and looking forward to a rumored 15″ Macbook Air, which I’ll probably buy for its portability (don’t really need the raw power of the Pro when I’ve got the cloud). When I do, I’ll use this set of scripts to automate its setup just how I like it.
Résumé Builder – An example of using LaTeX and my associated Docker image to build a PDF résumé via a continuous deployment pipeline implemented on Github and Travis CI. The résumé is the résumé, if you follow me?
Chrome Local Storage – Yet another project I’ve blogged about, this is a Python package for importing and exporting local storage from a Chrome browser. I built it to move Wordle stats from my laptop to my phone.
Output Scrubber – Writing sensitive information to application logs is generally a bad idea, but it’s easy to do so inadvertently. Include this package in your Node.js application, and it will insert itself into stdout and stderr and remove any pre-configured patterns it finds, such as social security numbers and email addresses. Of course if you’re logging in AWS, there’s some additional tools at your disposal.
Requestium – I’m not the original author of this package, but found its “best of both worlds” tremendously helpful when building some automation around an internal website, because it let me get logged in via Selenium and then switch over to the requests module to interact with APIs. When I needed a few new features, I offered to write the PRs, and discovered the creator was looking for a new owner for the project, and I decided to say yes, at least on a best effort basis. So far it hasn’t required more than a few hours a month at most.
Garage Envoy – This is another “build an HTTP API on top of a thing” project. I took a Raspberry Pi, added a relay that I wired into the opener, and some proximity sensors for detecting the position of the door, and voilà, I had an Internet controllable garage door. The most useful thing here was learning how to control the RPIO pins on the Pi to open/close switches and read sensor values.
Pinochle Scoresheet – In 2013 I went back to school to get a web development certificate from San Diego State. Part of that program was a class on Android app development, and this code was my capstone project. Pinochle is a card game that I’ve been playing since I was a kid, so it was fun to create an app I’d actually use. In retrospect, though, a native app is overkill and a simple mobile-friendly web app would be fine. Also, this app was Pinochle-specific, but I play quite a variety of games regularly, so a general-purpose tool would be nice to have…
Online Scoresheet (coming soon) – … thus this idea was born. Besides being an app I would use myself, I want to use this development to learn a few new things. First, I want to build it within a cloud-based integrated environment like Github Codespaces or Amazon CodeCatalyst. Second, I want to (finally) learn React.js beyond a hello world app. My domain name is bought (onlinescoresheet.net plus a few synonyms) and a sample app is spinning, all I need to do now is build it out.