Welcome to my PinkLetter. A short, weekly, technology-agnostic, and pink newsletter where we cultivate timeless skills about web development.
My Ramblings This Week
Ciao!
More than one year ago, I started working from home. I was in fear, and I’m still stressed to this day. But I was privileged to switch to remote work. And I thought it would be cool.
Except, I screwed it up.
Have you ever heard the fable of the boiling frog? They say if you put one in boiling water, it will jump away. But if you slowly bring the water to boiling, well, it doesn’t end up ok.
I hadn’t realized the importance of the chatter in the office, the small talks in the kitchen, and the presence of other human beings around me. But going from eight hours a day to zero eventually got to me.
I’ve since started reconnecting with people, and I’m looking forward to restoring the balance. But I wanted to let you know that, yeah, it can be shitty, and you are not alone.
As always, replies to this email get to my inbox. I’m always happy to hear from you, so drop me a line!
Elsewhere on the Web
HTTP is fundamental to modern development, from frontend to backend to mobile. But like any widespread mature standard, it’s got some funky skeletons in the closet.
Some of these skeletons are little-known but genuinely useful features, some of them are legacy oddities relied on by billions of connections daily, and some of them really shouldn’t exist at all. Let’s look behind the curtain:
(Riccardo: Let’s not forget HTTP 418!)
Strategies For Small, Focused Pull Requests by Steve Hicks
A common suggestion for improving pull requests (PRs) is to “make your PR small and focused”. I myself gave this suggestion in a recent article on this very blog about including context in PRs.
Like most internet advice, this can feel like the “draw the rest of the owl” meme. Even if we’re in agreement that I should make a PR smaller…how do I do it? How do I avoid a big PR when there’s a lot of cross-cutting changes to make? How do I create small, focused units of work when I’m building a large feature? How can I overcome my perfectionism and submit a PR that feels incomplete to me because the edges aren’t all polished?
(Riccardo: When you pull a ticket, give it a thought before you get deep into hacking the hell out of it.)
Speed is the killer feature by Brad Dickason
Speed is a killer feature. Speed is a differentiator.
Yet teams consistently overlook speed. Instead, they add more features (which ironically make things slower). Products bloat over time and performance goes downhill.
New features might help your users accomplish something extra in your product. Latency stops your users from doing the job they already hire your product for.
(Riccardo: Speaking of the Jesus phone, amen to this post.)