Tag: Are Right A Lot

Never Forget

Never Forget

Technologists love to collect and share horror stories (see, for example, The Daily WTF). It’s one of the reasons this blog exists, as a brag document of a different sort.

No matter how stressful the situation may be, no matter how long the debugging session took, no matter how brain-melting the eventual solution was to implement, on those days when you experience a moment that you know will go into the annals of “how the heck did this happen” infamy, it brings a smile to your face.

For me, yesterday was one of those days.

It’s a little too early to tell the full story in a public place (the key stakeholders should get to hear it first), but I hope to eventually. It’s an all-time head-scratcher.

Like Riding A Bike

Like Riding A Bike

Yesterday I re-passed the AWS Certified Solutions Architect – Professional exam. It’s my third time taking it (2019, 2022, and now 2025). I went into it cold turkey, absolutely zero preparation, and while my score wasn’t as good as before, a pass is a pass.

I guess at this point, I’ve done enough work in AWS that the knowledge is pretty much permanently ingrained. It reminded me of this article on Buying Moves:

There’s an amazing quirk of the human body that makes fitness adaptations work a bit like powerups in a video game. You can spend some resource to add capabilities to your “character,” and if you do it right they’re always available to you (for the most part). I’m talking about muscle memory and our ability to “lock in” physical skills.

Perhaps there’s a mental version of the same phenomena?

Speaking of that link, being one myself, I’m a big fan of True Generalist. While it isn’t for everyone (and that’s okay), I can’t disagree with his take on competencies that every person should have, and further skills that generalists need to function effectively. Both worth a read if you’re this type of person.

Figuratively Speaking

Figuratively Speaking

Speaking effectively to non-technical people can be a challenge for technical folks, but it’s an essential task for all but the most mundane (read: least-effective) of roles. One mechanism that I’ve found helpful is the use of metaphor. I’m a huge fan of trying to describe complex topics by mapping them to more broadly understood concepts. Being able to come up with such mappings fluently is a powerful skill. There may be many ways to develop it, but I suspect one is cultivating a wide set of interests.

While I was writing Tuesday’s post, it occurred to me that today’s Generative AI tools are to software what today’s 3D printers are to physical objects. On one hand, it’s incredible to be able to provide a specification and have it manifested in near real-time. Printers can make a variety of solids: toys, some kinds of replacement parts, that sort of thing. GenAI can create chunks of useful code, quick user interfaces, and basic apps, like my Pinochle scoresheet. But there are limits. Can either of these tools produce high tolerance, precision parts / highly secure, performant code? Can they build complex solutions like electronics / web browsers?

A 3D printer creating a figurine

I could be wrong, but just like we’re a long ways from 3D printing an iPhone, we seem a ways away from vibe coding Microsoft Word or an entire government system of record.

Diamonds and Digital Files

Diamonds and Digital Files

I’m a fairly good archivist. Today I happened to be rooting around some old files from college, and found (amongst other things I’m not going to share here) a paper I wrote in 1999 about the leadership style of Thomas J. Watson of IBM. I concluded with this summary that perhaps is still relevant today?

  • One of the most effective ways for a leader to build a cohesive team is to create an organizational culture that binds the employees together.
  • Having a vision for an organization is important, but being able to motivate others to get behind the vision is even more important.
  • Kindness shown to followers goes a long way towards developing loyalty and trust.
  • An autocratic leadership style can be very effective if interpersonal relationships are not ignored.
  • A good leader must not fall into the trap of wanting recognition.

I can mostly still agree, though that bit about autocracy makes me wonder.

Quasi-related factoid: I remember this class well because I pulled an all-nighter right before the final, not to study, but to drive across the state to the Lennox Theater in Columbus to watch The Phantom Menace at midnight. Good times, but a poor choice in retrospect.

Going Small

Going Small

I’ve been an Android user since the original Motorola Droid was released back in 2009. However, last month I finally broke down and made the switch to iOS.

I didn’t buy new, though. Because I don’t like big phones, I found myself a refurbished iPhone 13 Mini. It’s perfect. Sure do wish Apple would acknowledge the ongoing market for small devices, but it seems they’re well and truly dead. Maybe I should get a second Mini as a backup, especially since I’m case-free?

TL;DR

TL;DR

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.

Lightning vs Lightning Bug

Lightning vs Lightning Bug

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:

  • What do you appreciate about them?
  • What advice would you give them?

Question phrasing matters. I’ll be giving these ones a spin this year, we’ll see how it goes!

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.

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.