Author: Jud

Technologist interested in building both systems and organizations that are secure, scaleable, cost-effective, and most of all, good for humanity.
Be Kind, Not Right

Be Kind, Not Right

Several months back I read The Phoenix Project, a tale about how one company changed its IT culture to great success. I found the advice mostly good, and the idea of dishing it out in narrative form kept things interesting, though I’d hardly call it a page-turner.

However, one aspect really bugged me about it: the “guru” character Erik is a real piece of work. Talking down to his colleagues. Deliberately getting names wrong. Assuming his own body odor smells of perfume, as the Amazon leadership principle warns against. In the actual world, without kindness, it doesn’t matter if you’re right all the time, no one will listen to you. This is just as true in the realm of technology work: ever been told to RTFM and felt like an idiot? You’re not alone. I have to fight being that kind of jerk, but it’s a fight worth having.

And of course it really shouldn’t be that hard of a fight. Just do the little things: be on time, be responsive, be quick to listen and slow to criticize. Be patient. Treat others as they wish to be treated.

Oh, and learn your colleagues names, both spelling and pronunciation. It’s a basic gesture of respect that goes a long way.

I Appreciate You

I Appreciate You

Technology-related work, like all work, is primarily a social endeavor. It’s surprising that so little effort goes into preparing aspiring technologists about this side of the business, especially given our propensity to be singularly bad at it. Hence this article.

Along related lines, I found the suggestions in What Makes a Great IT Consultant completely applicable to a broader set of technology roles, and would highly recommend it.

I’ve also finally started digging into The Architecture of Open Source Applications; it’s been hit and miss, but more of the former, so definitely worth the time investment. A statement that jumped out at me today (from the chapter on Eclipse) was that an API is a social contract just as much as it is a technical one. I like that way of looking at it; seems a natural corollary of Conway’s Law.

In tangentially-related news, season 2 of Ted Lasso comes out today. You should watch it.


Slip Of The Finger

Slip Of The Finger

Don’t run your tests with production data. Just don’t. Otherwise, your customers will end up with delightful emails like this:

In jobs past I was pretty cavalier with production data. I was never part of a major incident, but that was more due to luck than strong security controls and separation of concerns. Really thankful that my current employer takes this stuff as seriously as it deserves.

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.