Be A Lumberjack

Be A Lumberjack

Spent my morning debugging a data extraction pipeline that’s been failing to properly update a dashboard, despite it completing without error (lovely). Digging through the output of the pipeline software got me thinking about logging. There’s a real art to getting it right: too much is impossible to parse (and potentially leaks sensitive information), but too little is useless. Sometimes the difference between finding the source of the problem and not is having logs in a Goldilocks Zone.

In today’s case, the log looked something like this:

- Calling the API
- The API call succeeded

Better than nothing, at least it would have let me know if the API call was failing altogether. But this would have been so much more helpful:

- Calling the API with parameters X=a and Y=b
- The API call succeeded and returned N items

I updated the data pipeline to provide the above output, and will see how it runs tonight.

Details matter, y’all! I wish I knew a way to teach the above to software engineers, but I fear there’s no real way to learn except through the experience of having to do this sort of debugging. It’s not fun work, but it’s oh so valuable.

That’s Good Advice

That’s Good Advice

Part of the CTO job is being conversant in a broad set of technical domains. I’ve never been a data engineer, but a current project has need, and thus I’ve been getting up to speed.

Spent some time on a flight this morning reading Amazon Redshift documentation, and found this beauty:

How helpful, Amazon: a best practice for loading data is to first learn how to load said data? Wouldn’t have guessed that. I wonder what other wonders of wisdom await me…

Tunneling Through

Tunneling Through

From time-to-time I have need to connect to VPNs, usually when doing work directly for one of my government partners. For a reason that utterly escapes me, Cisco hides its AnyConnect client behind a login that requires a license. And it’s a heavyweight install to boot. Ugh. I’d rather use a CLI; enter openconnect.

It can be a bit tricky to get the parameters right, so I put together a little helper script that abstracts some details, not the least of which is storing the VPN password in the local keyring for quick retrieval.

Posting it here for posterity. Enjoy!

That Kind Of Day

That Kind Of Day

You know when you’re trying to clean up a bunch of old AWS accounts but there’s no way to bulk close them so you have to click them one at a time and then click close and then copy and paste the account number to confirm and then there’s also a rate limit so you have to wait a minute between closures and then you hit a “10 account closures per 30 days” limit and no you can’t increase the quota says the documentation but you talk to support anyways and then they try to increase the quota but they can’t either so they suggest you log into each of them as root one at a time to close and you say “fine” but then the root email passwords are missing in your repository of credentials so you try to go through the forgot password flow but the root email address has two plus signs in it and no Exchange configuration you can think of to try seems to be able to accept such an email address and so you’re just outta luck…

ARGH!!!!!!!!!!!

UPDATE: So you finally get a shared mailbox set up with a carefully crafted alias that will receive email from the offending email address at least from your personal gmail account so in theory its working but then you retry the forgot password flow on the AWS login page and there’s a CAPTCHA and the first 4 times you try to solve it you get it wrong and then finally you get it right and the page claims it’s sent you password reset instructions to via email but you’ve waited 15 minutes and nothing has come through and yes you’ve checked the junk folder and what the hell am I doing with my life this is not what I dreamed a career in technology was going to be like and why can’t it involve more of the Property Brothers??

Life Imitating Art

Life Imitating Art

While it’s not all been fun and games, my career has still given me a number of cool opportunities: spending a summer flying around in the back of a C-130, cobbling together election equipment from off-the-shelf printers and scanners, and traveling over most of the US and a handful of other countries (Australia and Mexico).

But one of the most unique experiences was getting to twice attend the Emmys, first in 2015 and again in 2018 (roughly around this time of year, as my phone has recently reminded me). It was at the latter event that I was able to capture a particularly funny moment.

Just a month before, I’d been shopping for new furniture and, in a moment of levity, snapped a photo of myself between cardboard cutouts of the Property Brothers:

Now, I’m not really a fan of the Property Brothers (or HGTV type shows in general); I couldn’t tell you their names even now. But when they were hanging out just a few tables down at the 2018 after-party, I couldn’t resist asking them to help me recreate the above IRL:

Not exactly the kind of thing you tell a budding computer scientist to expect from their career, but fun nonetheless. I wonder what craziness the future has in store…

Made Along The Way

Made Along The Way

For reasons not worth getting into here, I’ve been waxing nostalgic (a phenomenon to which I’m apparently rather vulnerable; I mean, seriously). In particular, I took a brief mental stroll down memory lane to think of key leaders who influenced my career trajectory in a positive way. People who took a chance on giving me more responsibility than I’d had previously.

This is far from an exhaustive list, but thank you to the following folks:

  • Greg, who hired me to my first full-time coding gig despite me not even having yet graduated from my undergraduate computer science program.
  • Rick, who got me internal funding to implement an idea I had, giving me my first taste of leading a project completely my own.
  • Cathy, who brought me to San Diego without having seen me in action, only my reputation with a particular set of skills, which her project desperately needed.
  • Lori, who first promoted me to a management position when my prior boss left the company, and trusted me to scale an engineering organization to meet the company’s big goals.
  • James, who gave me my first singleton leadership position, and helped me think beyond my team and begin operating at a broad organizational level.
  • Taj, who twice helped me step up into broader responsibilities, and who first challenged me to consider business implications of technical decisions.
  • Abby, who recruited me into my current role, and has taught me much about how to be a true partner at the executive level.

In all these cases, the individuals didn’t just give me advice. They made opportunities happen and put me in places that caused growth. That’s what makes a mentor a mentor.

If you’re on the other side of a mentoring relationship now, don’t just pontificate. Open doors. Delegate. Trust. Support. Praise. Endeavor to be on someone else’s list.

Future Reference

Future Reference

Sometimes certain bits of writing resonate in such fundamental ways that you come back to them time and time again. I have a couple of those in my personal brag document, for example. And these two articles, which I share regularly when describing my profession:

Programming Sucks

So You Want To Reform Democracy

I bet I read both of these at least 4 times a year. They do not get old.

Speaking of re-reading, it’s a pretty rare thing for me (for reasons). Off the top of my head, the only books I know for certain I’ve read more than once (and in all cases still only twice) are The Lord of the Rings trilogy, The Hobbit, The Chronicles of Narnia, the Foundation Trilogy, and (somewhat randomly) Thinking in the Future Tense.

Tautology

Tautology

Had to fill out an online form yesterday to register for the chance to upgrade my season tickets to the San Diego Wave. The first draft of this form had some issues…

Misunderstanding of checkboxes and radio buttons is a classic, but inadvertently applying phone number validation to what is definitely not a phone number field is a new one.

Testing is a thing, my friends! Do it.

Ticking Away The Moments

Ticking Away The Moments

Nine years ago today I started this blog with a post that laid out my intentions in creating it. It’s cliché, but true, that a lot has changed in the intervening (near) decade, but for the most part, I think I’ve hewn pretty closely to the original idea, even if my underlying motivations have shifted.

Like many things worth doing, it took some time to find a good rhythm. After two initial posts I went almost 2 years without writing anything. Had a great streak going in 2017, but sputtered out in 2018 and didn’t get going again until early 2020. Since then, though, I’ve been on a roll. Maybe it was turning 40? Maybe it was COVID? Can’t say for sure, but I’ve been happy with my consistency since then (and a growing readership is nice too).

In other wistful, “how time flies!” type subject matter, my youngest kid left for college this past weekend and my oldest starts her junior year with a new location and major. They’re both gonna crush it, I have no doubt.

Go With It

Go With It

Last week I finished The Principles of Product Development Flow, based on a recommendation from the article I wrote about in Fightin’ Words. To say it was relevant to my current line of work is an understatement; I immediately mailed a copy to our de facto development process person.

Luckily for us all, though, there’s an official TL;DR version online. It’s a plethora of pithy principles packed onto one page. Go check it out!