Another gist for your holiday season: this one makes it easy to run a specific terraform version in Docker. Why might you want to do that? Well, for one, if you need a specific version (though tfenv can get that job done too).
My reason, though, was that I needed a version so old that a handful of plugins aren’t supported on Apple silicon. Docker with Rosetta to the rescue.
Happy holidays y’all!
I like Github gists. They’re perfect for long-term publishing of any code snippet you might want to refer to later, without the overhead of a formal repository. I’ve used them as backing storage for a number of blog posts as well, and will do so again today:
Need to bulk update the contact information across a set of domain names you own in Route 53? I got you. Need to do it across a whole slew of AWS accounts (or anything across a number of accounts)? No problem.
Happy scripting!
I’m sitting on a flight somewhere over the middle of the country on my way home after spending the Thanksgiving holiday with family in Ohio. Naturally it’s a time to be thinking about being thankful, both personally and professionally, a topic I’ve written about before.
That advice (say it often, say it aloud) is still true, but it’s incomplete. While expressing thanks to co-workers is necessary to being a good leader, it isn’t sufficient. Thankfulness must be shown through giving of time, empowerment, listening, and taking action when needed. Oh yeah, and through compensation too, if it’s within your power to influence. The expression “give thanks” is apropos: being thankful costs something.
When not backed by action, spoken words are empty at best, and counterproductive at worst. Might be better to say nothing if you’re not truly grateful.
Show and tell isn’t just for kindergarten and job interviews.
I’ve discovered a couple highly practical uses for GenAI this week relative to performance reviews.
In one case, I collected various stakeholder feedback for an individual on my team (using these questions from the other day) and used AI to extract common themes (both strengths and growth areas) that I could share without revealing who wrote what (which I’d promised in the hopes of getting more honest responses). It was also useful for me as a manager to see what emerged so we could review together.
In another, I took all the self-evaluations across a team and asked AI to identify and then summarize specific portions that would be relevant to pass along to the broader leadership group (e.g. feedback they had about the organization, common challenges that might be indicators of systemic problems). It’s a lot to ask of an executive to read these docs in their entirety, but there’s valuable insights to be gleaned. Building this summary was the best of both worlds.
Something my years at Amazon taught me is the usefulness of discussing performance in light of shared values. Our evaluation forms this year broke down questions along those lines (at my suggestion), but I’m now seeing it may be a bit too structured and artificially constraining. So next year I might see if we can keep the reflection questions a bit more open-ended, and then use AI tooling to align people’s responses to our specific guiding principles. Will that be effective? Not sure! But worth a try.
Just finished Marianna Bellotti’s excellent Kill It with Fire (thanks Kate for the recommendation!) If you do any work with legacy systems, give it a read post haste. You’ll be equal parts informed and inspired.
This quote jumped out at me in particular:
Feedback loops are most effective when the operator feels the impact, rather than just hearing about it.
Amen and amen. Intellect is great, and willpower is helpful, but what fuels anything truly worth doing is emotion. It’s not an accident that a particular emotion tops my company’s list of guiding principles.
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…