
The Breaking Change mailbag is starting to run low. Email podcast@searls.co and ask me literally anything and I will maybe possibly answer it in the next episode! 🤞
The Breaking Change mailbag is starting to run low. Email podcast@searls.co and ask me literally anything and I will maybe possibly answer it in the next episode! 🤞
In hindsight, when I was under a lot of pressure to drop CoffeeScript a decade
ago in favor of "modern" JavaScript (defined as using tools like babel and
webpack), I wish I'd held my ground.
Without a doubt I'd be better off today if I'd just gone straight from CoffeeScript to real ESM and import maps. Just spent three hours dealing with bitrot in a webpack config with no end in sight. The JavaScript Dream was always a house of cards.
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.
This isn't how I expected DHH would declare 2024 the year of Linux on the Desktop world.hey.com/dhh/vscode-wsl-makes-windows-awesome-for-web-development-9bc4d528
Spent all morning trying to figure out why every postcss plugin that has anything to do with color conversion can't handle CSS Colors 4 rgb() calls (even the two that claim to do exactly that).
Now I have my own custom postcss plugin named 'these-colors-dont-run' that I have to drag around until the end of time. Great gist.github.com/searls/d9ca494792736f94d765223c6ba98d33
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.
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.
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.
This month's Searls of Wisdom newsletter just went out — it's all about how to travel well in an era of high prices, poor service, and crowded destinations. Sign up now and you'll get it: justin.searls.co/newsletter/
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.
I started a new Rails app in January and I've now been hit by damn near decade-old bugs in 3 of Ruby's most popular gems. Who did I piss off? github.com/paper-trail-gem/paper_trail/issues/1464
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)
I just wrote this utility class for my Rails app to ensure my Rake tasks logged their output to my terminal without screwing up anything else.
Was this actually necessary? gist.github.com/searls/a2a642520b36594bb9002e2f75761eec
Breaking Change v6 includes a (rather spicy) PSA detailing how Stripe may be inadvertently giving your product away for free—oops! Probably my best episode yet. justin.searls.co/casts/breaking-change-v6-pausing-doesnt-pause/
[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: