My Gmail account turned 20 years old today:
I’m fairly certain it’s the only technology, hardware or software, that I’ve used continuously over that time period. That’s an impressive accomplishment; tip of the hat to the Gmail team. May we all be so fortunate in our endeavors to build something that lasts.
For many organizations (mine included), November is performance review season. I know it’s not everyone’s cup of tea, but I quite enjoy both getting and giving of constructive feedback. So much so that apparently I like writing about how I like performance reviews every November as well.
Today’s post is about specific questions for collecting feedback from stakeholders about a person you’re reviewing. Giving such feedback is uncomfortable for many people; it can feel like tattling or speaking ill of someone behind their back. But as a manager, my perspective is inherently limited (and usually biased). I require input from those who are working with my team day-to-day in order to fairly evaluate them and give them the feedback they need (both growth opportunities and especially praise they may not otherwise hear).
I’ve used a variety of approaches in the past, with mixed success. But I recently formulated a pair of questions in conversation with a career coach that I think can coax out the desired information without making stakeholders have too icky a feeling about giving it. They’re delightfully simple, and can be answered quickly and discreetly via BCC-ed email or even DM:
Question phrasing matters. I’ll be giving these ones a spin this year, we’ll see how it goes!
I don’t know what’s scarier, that I saw this when trying to use airplane WiFi…
… or that I know the technologies to which it refers.
Honestly, sounds like how a D&D character might meet their untimely demise, does it not?
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 succeededBetter 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 itemsI 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.
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…
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!
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??
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…
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:
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.
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:
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.