My Twitter account had been peacefully lying dormant since November 18th, 2022, but so many people are still using X that I finally caved a few weeks ago and spent 45 minutes wiring up a syndication strategy, effectively adding it to this site's POSSE.

If you want to do this, here's what you'll need:

• The azu/rss-to-twitter GitHub Action and a modest amount of a free account's budget
• A Twitter developer account and app
• An Atom feed to read from (here's mine, specially crafted to cram the full content of each tweet in the <title> of each <entry>)
• The handle you're posting as must be marked as an automated account and registered as managed by some other account

Once you have all that, you can define a YAML file defining the action in your GitHub repo like the one for this site:

# .github/workflows/rss_to_twitter.yml
name: rss-to-twitter
on:
  schedule:
    - cron: "*/30 * * * *"
  workflow_dispatch:
jobs:
  twitter:
    runs-on: ubuntu-latest
    steps:
      - uses: azu/rss-to-twitter@v1
        with:
          RSS_URL: "https://justin.searls.co/shorter-form.xml"
          TWEET_TEMPLATE: '%title%'
          TWITTER_APIKEY: ${{ secrets.TWITTER_APIKEY }}
          TWITTER_APIKEY_SECRET: ${{ secrets.TWITTER_APIKEY_SECRET }}
          TWITTER_ACCESS_TOKEN: ${{ secrets.TWITTER_ACCESS_TOKEN }}
          TWITTER_ACCESS_TOKEN_SECRET: ${{ secrets.TWITTER_ACCESS_TOKEN_SECRET }}

The above cron schedule translates to checking the Atom feed "every 30 minutes", which is more frequent than it needs to be in my case. And as for all those ${{ secrets… }} directives, here's how to configure your repository's GitHub Action secrets.

And that's it. Easy!

Enter your iPhone passcode to set up your Mac

visionOS Algorithm Failure Detected

Apart from being one of my favorite people—and someone whose wisdom had a big impact on my own professional development—Joel Helbing shares a bit about his experience giving himself just enough of a crash-course on whatever skill a new job needs to be able to show up to work on Monday:

Then I ended the call, got in my car, and drove an hour to the nearest Borders bookstore. I purchased two promising books on Microsoft SQL Server, went to the bookstore’s in-house Starbucks, purchased a venti iced coffee, sat down with those two books and a legal pad, and mapped out my weekend in fine detail. It came down to 15 minutes for this chapter, 10 for that chapter, skip this other chapter, etc. Then I drove home and followed my script meticulously for the whole weekend. This was not easy for me; I’m a curiosity-driven learner who loves to follow a thread and go deeper. Not this weekend, though. I stuck to the plan, and on Sunday night I got back in my car and started the long drive to my new gig.

(Imagine I spent the thirty seconds to insert a "this is the way" GIF here.)

But seriously, Joel's not kidding. He's indeed one of the most deliberate, curious people I've ever met, and I bet rushing through a bunch of content in order to get his arms around a topic was acutely painful for him. But when you're a consultant, your clients need you to be conversant in whatever they're focused on, and frequently that means brushing up on topics and technologies your previous ten clients weren't focused on.

Doing this was always painful for me, too. In part, because I'm a perfectionist who really struggles to move onto chapter two until I've absorbed, critiqued, and improved on everything the author posited in chapter one. For me, the act of learning is an exhausting war of attrition. But when my job depended on me showing up knowing something, I had no choice but to swallow my pride and immerse myself in a topic uncritically in order to learn enough to be dangerous.

This is an intensely uncomfortable activity. That immersion feels like drowning at first. I'm even feeling it this morning, as I'm upgrading a database I haven't touched in 3 years and which I presently can't remember how to back up—my gut is churning in worry as a result. As a consultant, though, I always understood that the stakes were always higher for my client than for me, and every ounce of discomfort I shouldered almost always translated to an ounce of burden I could remove from their plate. Sometimes that meant using their preferred technology over mine. Or assigning myself to their legacy systems so their full-timers could be the ones to break ground on the next green-field app. Or, and this was always the hardest for me, relenting and using their janky issue trackers and time-keeping systems.

Some consultancies blunt this reality by deploying large teams where there are levels of indirection between clients and practitioners—placing an engagement manager in front of the client who can run interference while the team of consultants behind him ramp up at a more leisurely and comfortable pace (as they bill every hour at a full rate). Other consultancies prioritize their convenience over their clients' needs by narrowing their services and prescribing a single monolithic "Way" to work with them—often requiring clients to build systems in the agency's favorite tech stack—firmly ensconcing each consultant in a cocoon of comfort. But at Test Double, it never occurred to do anything other than lean in and rise to the challenge of actually meeting our clients where they are. We spent years demonstrating to our clients that no matter how arcane their technology or byzantine their org chart, our people will get up to speed so fast it'll make their heads spin. You get good at what you do, and if the thing you do is stomach discomfort as you learn hard things in service of others, then there's almost no limit to what you can accomplish.

One last note: showing up to a client following a weekend-long crash course in a particular technology doesn't make you a fraud. Nearly twenty years in consulting has taught me that the people most worried about misrepresenting themselves and their abilities are the people who have the least reason to worry. The fact they care so much almost always means they'll put in the work when they need to. The real frauds, meanwhile, don't worry at all. And while Joel was holed up in a Starbucks for 72 hours, I'm sure they were having a delightful and relaxing weekend. And Joel's much richer for it, as he's gotten four careers' worth of experience by repeatedly diving into new industries, organizations, and technologies, whereas the real imposters only learned how to talk a good game as they skated through life without ever stretching themselves.

So, I built this little bit of UI today as part of an email-based authentication flow for Becky's new app:

(I haven't shipped this yet and I'm too lazy to record a screencast, so just imagine that this field behaves perfectly, please and thank you.)

If you, like me, have ever found yourself in the thrall of a beautiful-looking 6-digit form when logging into some site, whether when filling a TOTP from your authenticator app or copy-pasting a code that's been texted or e-mailed to you, you've probably wondered "how'd they make that field look nice like that?"

Well, today I actually started digging into it, and I didn't like what I found. At all.

Let's dive in and find out…

Epic Inbox Zero