Author: Jud

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

Getting Warmer

By | | Comments 1 comment

This past summer my family and I took on a little project: we bought a house in Lake Arrowhead and listed it on Airbnb. Because it’s useful to both see and remotely control the temperature there, we had a dual-zone WiFi-enabled Honeywell thermostat installed. And because I’m a nerd, I wanted to track its settings, and the corresponding outdoor temperature, over time.

Behold the Temperature Collector. It runs in AWS Lambda and polls both the thermostats and a public weather API every 5 minutes, writing the results to CloudWatch metrics, where I can then graph them on a dashboard. Pretty nifty!

While I was at it, I added support for a Nest thermostat, which I have here in San Diego. And because I love writing automation, I have terraform code to deploy it all. If you need a simple example of how to create a Lambda that runs periodically, you’re welcome to steal it. That’s the beauty of learning in public.

Whatcha Been Up To?

Whatcha Been Up To?

By | | Comments 0 Comment

I’m naming this truism in honor of the co-inventor of the spreadsheet:

Bricklin’s Law

The probability of a project’s success is inversely proportional to the number of status tracking tools used by its team members.

Also, I think this is the first time I’ve used “pull quote” formatting on this blog. Neat!

Not Just Lip Service

Not Just Lip Service

By | | Comments 0 Comment

If you’ve been by the site recently, you might have noticed a new word cloud in the sidebar. On a whim, I read back though the entirety of my blog and tagged each post with a handful of relevant Amazon Leadership Principles. It was an enjoyable way to spend a couple hours, and who knows, it might be a useful resource. We take them pretty seriously at AWS, not the least of which during interviews. For mine, I had stories written out ahead of time that illustrated how I practiced each of these principles. This preparation proved invaluable to my success.

Sweat The Small Stuff

Sweat The Small Stuff

By | | Comments 0 Comment

Details matter.

I’ve been enamored recently with building little Python packages that provide useful capabilities for my colleagues. Things like a client for our internal ticketing system, a convenience wrapper to interact with our LDAP servers, etc. And I talk about them non-stop with anyone who will listen, because I truly believe they are helpful for automating mundane tasks across the organization.

But a pesky thing happens when actual people try to use your code. Bugs pop up. Installation errors occur. Weird behaviors manifest. Whatever can go wrong, will go wrong, and if you’re lucky, you’re going to hear about it from your users. If you’re unlucky, no one will bother to contact you or use your code again.

The gap between a toy script you write for yourself and a full-fledged tool usable by others is vast. Numerous compatibility and usability considerations must be considered: differing hardware, operating systems, language versions, user familiarity, probably even more things I’m not thinking of.

Case in point. A few weeks ago I added @functools.cache to a couple packages in key places where expensive API calls were being made. It’s a rad little annotation, but was new to Python 3.9. Didn’t take long before someone hit an error message that was anything but clear to them. Quickly I patched the code up by replacing with @functools.lru_cache which does basically the same thing and has been around for a while longer. But did I bother to test on the older version? No I did not (and shame on me, because tox and pyenv make doing so easy). Once again my user was thwarted, because while Python 3.8 allowed the use of this annotation without a parameter, Python 3.6 and 3.7 do not (and he was running 3.6.9). Once again, I had to quickly patch, but this time I made sure my tox setup tested across versions.

The worst part of the above is that I could have better guarded against an esoteric error message by specifying precise compatibility in setup.py (in this case with a python_requires='>=3.6' instead of python_requires='>=3'). If I’d have done that, my user would have still gotten an error, but it would have happened at install time, and been much clearer as to the cause. Two extra characters in an install script, but hugely improved customer experience.

Like I said, details matter.

Right On The Nose

Right On The Nose

By | | Comments 0 Comment

I’ve been working on a little project here at this blog, one that’s required me to go back and re-read all my old posts. Truth be told tonight I was using it as a distraction from what I really should be doing (backlog grooming ahead of tomorrow’s new sprint).

Let’s just say this post hit a little close to home. I suppose I better press pause for now (but you’ll hear more soon, I promise, and if you’re observant, you might be able to guess what I’m doing).

A Plethora Of Potpourri

A Plethora Of Potpourri

By | | Comments 0 Comment

During interviews, a common question directed at me is what my day-to-day looks like. While it feels like a cop-out, the answer is that I do whatever my customers need me to do. Some days that might mean writing Python, Node.js, or Java. Other days it might mean terraform, CDK, or (ugh) CloudFormation. Still other days it might not mean code at all, but leading daily stand-ups, drawing architecture diagrams, writing documentation, giving training, or planning long-term goals. And that’s not to mention all my managerial tasks like 1-on-1s, goal setting, performance reviews, an mentoring, since I view my team as customers of a sort.

We talk at AWS of being comfortable with ambiguity. It’s a posture that doesn’t suit everyone, but pretty much any technical job of worthwhile complexity requires the ability to deal with unknowns. There are no hard and fast rules. No absolutes. System design, software development, team leadership, they are all just as much art as science, requiring both good intuitions and good data to get right.

Don’t believe me? Then consider how Stack Overflow tells it.

Isn’t It Ironic?

Isn’t It Ironic?

By | | Comments 1 comment

Today I saw the following commit message in a code repository:

fix typi

It wasn’t me this time, but I’ve been there. We should all strive for better. There are dozens of guides on how to write good commit messages. And if you mess one up, as long as you haven’t pushed, git commit --amend is your friend.

Other than learning to type faster and more accurately, there are few activities I know of that can rapidly level up a developer’s effectiveness than becoming fluent with git. And I don’t mean just the basics, but really digging into the details and practicing until it becomes second nature. Start by reading Pro Git, cover to cover. You won’t regret it.

Joined At The Hip

Joined At The Hip

By | | Comments 0 Comment

Anyone remember this commercial (and the lead-in to it)?

If the kid is me, the doll is Python. Anywhere I go, it goes too. If I have a problem to solve, it’s the tool I reach for nine times out of ten. We’re like peas in a pod, Python and me.

In all seriousness, though, the comparison is apt. I’m a generalist at heart, and I don’t know of a better general-purpose programming language than Guido van Rossem’s masterpiece. Only recently did I make this association, but it fits.

As a team leader, I aim to be adequate or better with any part of the tech stack, so I can plug myself in wherever I’m needed. But it’s unlikely I’m the best one on my team at any of the tech either (in fact, if I am, the team probably doesn’t have an ideal mix of talent). That’s an awful lot like Python, which is the second-best language at everything:

  • Need a quick one-off script? Bash is a bit faster to write, but Python is pretty easy also.
  • Building microservices? Sure, Go is the new hotness, especially if performance is king. But most of the time Python will do the job just fine.
  • Serverless? Oh yeah, Python is money, even if Node.js might be more popular.
  • Doing data science? The nerds use R, but Python’s a great choice too.
  • Putting together a giant enterprise application in all its OOP glory? Most would reach for Java, but object support in Python is great.
  • Functional programming purist? Haskell is your language. But if you want to dabble, Python will get it done, and provide you more flexibility if you need to violate the paradigm for expediency.

Besides us both being generalists, Python and I are both minimalists. It eschews superfluous bits like delimiters, and you needn’t bother declaring types if you’re in a hurry and the situation doesn’t demand it. I also don’t like clutter, e.g. consider my primary workspace:

I stand about 80% of the time, and the kneeling chair takes care of the rest.

Did I mention Python is really easy to learn? And the community is great? And it’s just plain fun? As far as I’m concerned, Python is the Holy Grail.

P.S. It also has a great name. And that’s not nothing.

It’s The Little Things

It’s The Little Things

By | | Comments 0 Comment

We talk all the time about customer obsession, it’s the first amongst equals of our Leadership Principles. The general idea is that you always imagine the customer is in the room with you when making decisions, and consider their preferences when implementing a feature.

As email got more prevalent (and with it, junk emails), one feature that came along in the spirit of customer obsession was one-click unsubscribe. Me being a person who strives for inbox zero, stopping email subscriptions easily was a welcomed capability. But who knew it could be done even better. Behold, zero-click unsubscribe:

How cool is that? Recognizing that I haven’t interacted with any of their emails or visited their site, they automatically unsubscribed me from their lists. That’s customer obsession in a nutshell.

The really surprising thing about this capability is that it’s surely dirt simple to implement. I bet I could pseudo-code it off the top of my head in one minute. Ready, go!

all_emails = database.get_mailing_list()
for email_address in all_emails:
last_contact = database.get_last_contact(email_address)
if datetime.today() - last_contact > ONE_YEAR:
database.remove(email_address)

See how easy that was? Any marketing email system worth its salt already knows when you click on a link in any of their mailings, so the data is there. Just takes a company thinking more about their customers than the size of their distro.