Author: Jud

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

Mount Rushmore

I wish I had the time and talent to write like Joel Spolsky. He’s one of my favorite people in the public sphere of software engineering. Here’s a couple articles I read yesterday, they’re both oldies but goodies:

  • Making Wrong Code Look Wrong – I’ve never been of fan of the “data type prefix” in variable names, so I was biased going into this discussion. But I was pleasantly surprised to hear the actual history of Hungarian Notation and that misuse of it was based on a misunderstanding of “type” vs “kind”.
  • The Law of Leaky Abstractions – I’ve talked about abstractions before, they’re a central concept to the art of software development. Getting them right is hard; in fact, it might just be impossible.

You should check out Joel’s whole blog. It’s great.

On The Brink

On The Brink

I’m currently sitting at 998 reputation on Stack Overflow. Anyone willing to upvote some of my answers to push me over 1000?

Speaking of which, most software developers are rapid consumers of Stack Overflow, but how many give back by actually answering questions? About 8 years ago I started trying to spend a bit of time each week contributing, and while my consistency dropped off after a few months, it was a rewarding experience. It didn’t hurt that I was also trying to beef up my online presence during a season of job hunting.

My current workplace has an internal developer Q&A site which I’ve just recently started actively contributing to as well. For one, it’s good writing practice. And also because learning is best done in public.

Word Salad

Word Salad

Yesterday I was notified via email that some of my personal information had been compromised by the ParkMobile app. Besides the obvious question of why it took them two months to contact users proactively (vs a post on their website), I found this paragraph a blend of confusing and concerning:

Encrypted passwords were accessed, but not the encryption keys required to read them. We protect user passwords by encrypting them with advanced hashing and salting technologies.

So many things wrong with the above. First, passwords should not typically be encrypted, and certainly not in a way that would allow a company to read them. The better approach is to hash them, which ParkMobile mentions later, but encryption and hashing are not the same thing. It’s hard to trust an organization that doesn’t know the difference.

Additionally, the adjective “advanced” gives me pause. It’s not communicating anything of value. Why not instead tell me the exact algorithm used, such as bcrypt, Argon2, or PBKDF2? Most likely the person writing the response doesn’t really understand the technologies used to protect passwords. And claiming something is advanced when one has no ability to know if such a claim is true screams Dunning-Kruger effect.

Ironically in an attempt to express competence, ParkMobile has done the opposite.

Turduckens Everywhere

Turduckens Everywhere

Did you know you can implement a CPU in Minecraft or write arbitrary computer programs using Magic: the Gathering cards? Computing is powerfully weird, and hidden structures and capabilities can arise from all sorts of odd places.

I read a theory a while back that the Internet was, in some meaningful sense, intelligently conscious, though we may never be able to interact with such an intelligence. The analogy was to human consciousness arising from the cells of the brain in a way that no individual cell could ever comprehend it, but despite that it being no less real. The notion of Turing-complete computers being buried inside all manner of languages and tools has a similar vibe to it.

On The Shoulders Of Giants

On The Shoulders Of Giants

Apparently I really like the above phrase as a blog post title, because this marks the third time I’ve used it. I also once owned its equivalent domain name, where I hosted a blog where everything was themed around it. The blog itself I believe is still out on the Internet, but I’m not going to link to it; I’m not exactly embarrassed by it, but I am a very different person than I was 10 years ago when it was written.

The tagline on that blog was an interesting one: when experience is not retained, infancy is perpetual. That could certainly be said for experience in technical domains like software development, where there’s a bias towards the new, and few people spend time studying the history of the field. Which is why I couldn’t be more excited to have discovered The Architecture of Open Source Applications, a set of books that cover in detail a variety of programs that are used daily around the world.

I just need to finish The Expanse series first, only 2 books to go!

Can’t Unsee It

Can’t Unsee It

On the plus side, she writes her people-searching algorithms in Python. But c’mon Wonder Woman, you need to work on your variable naming!

I’m pretty sure this function could be further simplified with some basic mathematics; it’s far too long and complicated. Reminds me of the film I captured it from.

Mutually Assured Destruction

Mutually Assured Destruction

Automation is great and wonderful and everything, but it does provide ample opportunity to do damage quickly. Great power, great responsibility and all that.

Drink Coffee - Do Stupid Things Faster with More Energy
Automation is a lot like coffee

Over the weekend I was working on a Python library to interact with an internal ticketing system. I was adding the capability to generate a bunch of tickets at once, and wasn’t paying attention to the folder I was pointed at. Let’s just say I heard from multiple folks first thing Monday morning about the 50+ emails in their inboxes notifying them of new issues that needed their attention. Whoops!

Lesson learned: double-check your inputs when writing automation scripts. Also own up to your mistakes, better to apologize fast than lead with an excuse.

Getting Warmer

Getting Warmer

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?

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

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.