Month: April 2023

In Medias Res

In Medias Res

By | | Comments 0 Comment

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

By | | Comments 0 Comment

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:

  • Headshot by Bethany Zabrosky (2022)
  • 40th birthday (2019)
  • Bass playing photo by Nikki Brill (2017)
  • Headshot by Cindy Kyle (2016)
  • All-time favorite selfie, I look like my grandfather (2014)
Can’t Fight This Feeling

Can’t Fight This Feeling

By | | Comments 3 comments

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

By | | Comments 0 Comment

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

By | | Comments 0 Comment

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

By | | Comments 1 comment

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

By | | Comments 0 Comment

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.