justin․searls․co

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.

A weird consequence of Japan spanning a single time zone is that lots of apps stop working outside business hours for "maintenance".

I lost an hour today freaking out over error messages that my account was locked right around 11pm JST because (I now realize) their servers were only partially shut down.

Feels weird knowing—100%, not a doubt in my mind, knowing—that humanity will have cured cancer before it creates a system that can autonomously maintain an accurate inventory of the food available in one's kitchen.

Making a nice 2FA / OTP / SMS field with Tailwind & Stimulus

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.

But wait, there's more…

Epic Inbox Zero

I am generally extremely on top of my inbox, but I don't know if I can get through 18 quintillion e-mails by end-of-day.

Just realized it's much more acceptable to say I'm too busy writing to have time for reading than it is to admit I'm too busy talking to have time for listening.

Nice set of reminders on how to validate e-mail addresses in Rails models and was glad to find his second example to be almost identical to what I found in my newest app:

class User < ApplicationRecord
  validates :email,
    format: { with: URI::MailTo::EMAIL_REGEXP },
    presence: true,
    uniqueness: { case_insensitive: true }
end

One thing I'd be sure to add, though, is the new normalizes class method to ensure all email addresses saved by your app are easily compared by stripping whitespace and lower-casing them. From my User class:

normalizes :email, with: ->(email) { email.strip.downcase }

Never hurts to revisit the stuff you wrote on the first day of an app's life.

"It is currently estimated that new models with significant changes to the Vision Pro specification may not be in mass production until 2027," Kuo said today.

This makes me glad I bought at launch as opposed to waiting, and even more glad I opted for monthly AppleCare payments as opposed to buying the fixed two-year contract.

Until yesterday, I had never heard anyone but me in the Ruby community express confusion over the fact that Rails produced both paper_trail the audit log gem and Papertrail the logging SaaS.

But seriously, how the hell did everyone else keep these straight in conversation? (My bet is that they didn't, actually)

Breaking Change artwork

v6 - Pausing doesn't pause

Breaking Change

[UPDATE: In this episode, I referenced Stripe having an IPO in the past tense. I was mistaken, they are not (yet) publicly traded. We regret the error.]

The audio is better this week! I'm learning.

Also, I finally had something to talk about that has nothing to do with Apple! The target of the ion cannon that is my mouth this time? drumroll… it's Stripe! Sorry, Stripe. If you like rants about software quality and the systemic reasons everything is terrible, hoo boy! This one brings the heat. 🔥🔥🔥

We're starting to work down our mailbag backlog, so help me freshen it up by e-mailing the show at podcast@searls.co and our dedicated staff (me) will read it and—potentially, maybe—respond on the air!

And now, some URLs:

Show those show notes…

One of the most valuable things about writing automated tests is that they force you to run your code very many times in very many ways.

It's important to understand this is not a value of testing per se, though, and that there are other valid ways to achieve the same goal.

Captchas have really gotten away from us

Thanks to recent advancements in AI, the only way to pass this captcha and prove you're a human is to mutter, "what the fuck are we even doing here anymore," into your device's microphone.

Two decades as a programmer hasn't made me any better at estimating how long it'll take me to write software, but it's made me MUCH better at estimating how long other things will take. I'm a master at intuitively timing multiple dishes to finish simultaneously, for example.