Author: Jud

Technologist interested in building both systems and organizations that are secure, scaleable, cost-effective, and most of all, good for humanity.
Personal Assistant

Personal Assistant

For some reason unbeknownst to me, health insurance in the United States is tied to employment. So one of the joys of starting a new job is being forced to reevaluate a bunch of plans, choose new options, and in some cases, find new doctors. As it turns out, my previous physician retired last year, so in any case I need to find a new one.

This afternoon I called my preferred medical network to ask about doctors accepting new patients, and the agent informed me that due to a shortage of folks, there pretty much isn’t anyone for the next couple of months. Lovely. I asked about waiting lists or notifications I could sign up for; naturally that doesn’t exist either. The best he could suggest was to check the physician search page every couple of days.

Well, I’m lazy, so I reverse engineered the search API behind the website, wrote a Lambda function to query it periodically, and set up an alarm to email me when the search results come back non-empty. Take that, manual process.

In Medias Res

In Medias Res

I appreciate people who open up about difficult emotions they’ve experienced in the past. But I appreciate even more people who are willing to discuss them as they are feeling them in the present.

In that spirit, I must confess that this week I’ve experienced considerable Imposter Syndrome. Starting a new job can be overwhelming; doing so when you’re expected to be in charge, even more so, as I’m learning (this is my first time in the latter situation). There’s so much new information to absorb, new people to meet, new customers to understand, and a new culture to internalize. Literally everyone else I talk to knows more than me, and while there’s certainly a grace period, at some point I’ll be expected to earn my salary and contribute, and it’s hard to see when that will be.

Let this serve as a reminder to us all that feelings of inadequacy are normal, especially at times of transition like a new job or getting laid off (which, if that’s you right now, I’m so sorry). I’m telling myself that I’ve been here before, and it’ll be okay. Though I’ll be happy when onboarding is behind me, for sure.

Pro-Social Behavior

Pro-Social Behavior

As someone who tries to maintain a consistent and up-to-date, if atypical, online presence, it’s no small effort to update profiles and such when taking a new job. Here’s the list of the sites I’ve edited recently (documented here as a reference for next time I need to make such changes, if nothing else):

Besides the basic information, over time I’ve crafted a professional profile statement that I use to describe myself. It comes in three flavors depending on length required:

Technologist building systems and organizations that promote human flourishing.

Technologist building both systems and organizations that are secure, scaleable, cost-effective, and most of all, promote human flourishing.

Technologist building both systems and organizations that are secure, scaleable, cost-effective, and most of all, promote human flourishing. Well-versed in programming languages, cloud technologies, and people management. Experienced with the entire engineering lifecycle, from ideation and requirements design to architecture and implementation to sales and support. Also an avid runner, amateur musician, and owner of every iteration of the Raspberry Pi.

When I need a brief personal description, I use this:

husband, father, son, brother, musician, runner, and maker of things

I’ve also used a number of headshots through the years, here’s a couple of my favorites, in reverse chronological order:

Can’t Fight This Feeling

Can’t Fight This Feeling

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.

Don’t Repeat Yourself

Don’t Repeat Yourself

Technologists are generally pretty bad at understanding their own history. Understandable, given how quickly the industry moves, but still regrettable.

If you’ve ever written a line of JavaScript or called an API that returned JSON (and who hasn’t, they’re about as ubiquitous as tech can get), you should get to know Douglas Crockford. This interview with him covers a wide range of topics, including how JSON came to be (spoiler: as the antidote to XML), his perspective on JavaScript as a whole (and how it changed from his first impression), what it was like to work through the dot com bubble, and much more.

I also suppose I should study my own history better, because I’ve written on the topic of studying history several times before. Though not all forms of repetition are bad, right? Right?

Get In The Arena

Get In The Arena

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.

Little Light Of Mine

Little Light Of Mine

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.

Spirit And Truth

Spirit And Truth

As I was reading Things they didn’t teach you about Software Engineering, I found myself frequently nodding along. There’s a fountain of wisdom here. Seriously, go read it, or at least go read the headers, which are helpfully summarized along the side of the page.

One worth a deeper dive is this: domain knowledge is more important than your coding skills. I cannot agree more. If you don’t know your customer, it’s unlikely anything you build will add value, no matter how perfectly it’s constructed. And given that the typical end-user is rarely going to be a developer themselves, this knowledge won’t come automatically. It needs to be pursued intentionally.

I’ll go even further, though: knowledge isn’t enough. When the going gets tough (and it will, because programming is hard), a team needs more than information about their customers to keep them moving forward. They need an emotion powerful enough to overcome diverse roadblocks. They need empathy.

The best engineers don’t just seek to know about the problems they’re solving. They internalize those problems, engaging their emotions alongside their intellect. When a customer has a challenge, they feel it in their bones (it’s not by accident that we use the metaphor of a “pain point” when describing problems). When a customer is angry at a missed deadline or poor quality outcome, they lean in, acknowledging failure. And when a customer is overjoyed at the success of a new product launch, they get to share in that happiness.

Empathy is the key that unlocks the willpower to achieve great things. Regardless of technical prowess, show me an empathetic developer, and I’ll show you a good one.

Security Sunday

Security Sunday

I’ve been a daily user of YubiKeys since 2018. These little devices pack a hefty security punch with a number of useful features, including universal second factor (U2F), time-based one-time passwords (TOTP), static passwords, and personal identity verification (PIV).

This article contains an excellent overview of all the functions and how to use them. If you’re at all interesting in beefing up your security posture, I can’t recommend it highly enough.

Craft And Commerce

Craft And Commerce

According to the behind the scenes documentaries, the designers working on The Lord of the Rings trilogy spent countless hours adding details to the various costumes, weapons, and other props used on the film, including details that were on the inside of garments or other places that would never be seen on the screen. They wanted these items to feel real to the actors, but I also imagine there was a simple love of craft that drove them to put their absolute best into their work.

This same attention to detail is applicable to software development. Rarely will an end user ever see the source code that runs her favorite app, but that doesn’t mean it’s not worth making just as beautiful as what ends up in the interface. Beauty inspires quality, and there’s some things worth doing well even if just for yourself.

Of course one must balance this against deadlines and the needs of the customer, but whenever possible, pay attention to the details.