Tag: Are Right A Lot

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.

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!

A Plethora Of Potpourri

A Plethora Of Potpourri

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.

Perdido En La Traducción

Perdido En La Traducción

Today my kids had to choose between virtual and socially-distanced on-campus learning for this fall semester (thanks COVID-19). The selection process involved picking their high school from a drop-down on the district website. Oddly we couldn’t initially find their school (Del Norte) in the list.

Why not? Well, it turns out that Google Chrome’s auto-translate feature was attempting to be helpful, and transformed it into “From North”. Which made me realize three things:

  • I’m really thankful to be techie and able to debug such issues, because I imagine this will cause confusion for those less clued-in to potential browser oddities.
  • It’s really hard for computers to do be “smartly” helpful in a transparent way; if an algorithm isn’t darn near perfect it’s likely to do more harm than good.
  • The implementor should have added translate=no to their <html> tag to avoid this problem altogether.
A Tale As Old As 2001

A Tale As Old As 2001

For the next week or two I’m going to go back through my old drafts and finish them up. That means the stories are at least a year or two old. For this one, I’m curious if Edge finally changed the behavior. Anyone want to try it out?

When you’re debugging a pernicious issue, there’s no greater feeling than Google search auto-completing your first couple search terms and matching a page that describes your problem to a T. The challenge of course is figuring out those magic couple of words.

The team was recently trying to figure out an IE11-only problem (ugh) where our authentication mechanism was failing, but only for a subset of customers, with no obvious commonality. The server would return a Set-Cookie header, but the browser completely ignored it. WTF, Microsoft!

We’d spent an entire day trying to come up with a solution, until finally stumbling into the root cause: underscores in the subdomain. Chrome and Firefox are cool with them, but IE silently refuses to store cookies when they’re present. The details are a fascinating combination of unexpected side effects from a bug fix, misinterpreted web standards, and lingering backwards compatibility. This post captures the story nicely.

My product manager had never been thrilled with the way we’d been handling domain names. While I couldn’t have anticipated our design would lead to this misadventure (and a simple s/_/-/ solved the problem), I probably should have given his critique a closer listen.

It’s Been Awhile

It’s Been Awhile

Howdy friend. It’s been quiet here for some time now, but as is typical around a new year, I’m renewing my efforts to stay active on this blog (especially since I’ve mostly stopped using social media). This is in no small part to me now working for AWS Professional Services as a Senior Consultant in the public sector, a role for which improving my writing will be particularly valuable.

My silence should not be interpreted as inactivity, because a heck of a lot has gone down since I last posted:

  • Got promoted to the Director of Engineering for a 20+ person team (this actually happened in late 2017 but I’ve never mentioned it here)
  • Led that team through a painful acquisition process that required reducing the team by about a third
  • Experienced the joy of having a paycheck delayed by two full weeks during the holiday spending season
  • I celebrated my 40th birthday with a trip to Germany and Ireland
  • Was laid off when my employer ran out of money, without warning and with no final paycheck (about this much more could be said, but going to keep it short for now)
  • Dipped my toes into independent consulting for a few months while searching for a new job
  • Was hired by Amazon as a Senior SDE to work on their Last Mile team (the folks that get packages from delivery stations to your doorstep)
  • Transferred to AWS as I mentioned above

Pretty bonkers 18 months, but things are starting to settle down, and I’m eagerly anticipating the new normal of 2020. More to come!

Truth And Consequences

Truth And Consequences

Yesterday I was in an all day meeting preparing for a large customer demonstration. Ran into a bug that turned out to be a misunderstanding of how JavaScript handles truthiness. Consider the following code:

if (person.address) {
  console.log('Address is ' + person.address);
}
else {
  console.log('No address.');
}

Seems clean enough right? Not so fast. If person.address is null, no problem. However, if person.address is an empty object, that evaluates to true, and the code fails to do the right thing. To me at least, this is non-intuitive behavior.

I started this blog with a discussion of why I love Python, and once again it behaves more intuitively. Empty dictionary, empty list, None, and empty string all evaluate to False. So the code works in a broader-variety of cases:

if person['address']:
    logging.info('Address is ' + person['address'])
else:
    logging.info('No address.')

Isn’t that nice and clean?

As an aside, most developers have become so accustomed to bracketing punctuation (e.g. braces, semicolons) that they assume there’s no other way. Personally I’ve come to love the lack of noise in Python syntax, and I think you will too.