This is a really interesting overview and perspective by one of the co-founders of GitHub:
So, to sum up, we won because we started at the right time and we had taste. We were there when a new paradigm was being born and we approached the problem of helping people embrace that new paradigm with a developer experience centric approach that nobody else had the capacity for or interest in.
The whole post is worth reading for the history and all ways things just went right for GitHub.
This is excellent advice from Will Larson:
Many high-agency managers try to prevent executives from doing silly things, but it’s almost always more effective to translate their energy for a silly thing into energy for a useful thing. It also leaves the executive feeling supported by your work rather than viewing you as an obstacle to their progress.
He shares some practical examples in the post to illustrate the principle. Also relevant—Casey Winters’s story about executives sometimes wanting their rounded corners on images:
You are going to run into founders, CEOs, execs that want their “corners”, or seemingly irrational markets, product, features, etc. And it’s going to be your job to make those things happen. As a former product leader, I think every CEO or founder should be trusted when they ask for a corner. Now, if they’re doing it all the time, it might just be a bad leader, and you should get a new job. But I have learned to respect there is a thought process I can’t always see, an important reason they can’t always share with me that may make this the right call. So, now I just label certain ideas as corners in the strategy to teams. I can’t exactly lay out all the reasons this makes sense to do now or agree with the ones I’ve heard, but we’re going to do it anyway, and hope it’s the right thing.
I love this sentiment from Austin Kleon:
I am big on being a "curious elder”—and one way, I think, to expand the curious elder idea is to not just be curious about what young people are into, but to also share your curiosity about the world in a way that is generous but without expectation. To point out the things you think are good… just in case somebody, maybe even somebody younger, is looking for them.
I’ll go ahead and keep sharing the things I like, and I hope everyone else does too.
Things have been a bit quiet on the blog, and there are a couple of reasons for that. The first is that I’m still ramping up in my new role at Cloudflare, and like all new roles that takes a ton of energy and life force! It’s been really good though, and I am enjoying building out the Data product team.
But the second reason is that most of my non-work, tinkering time have gone not into writing, but into making a new music side project site, now called Listen To More. So I wanted to talk about it a little bit.
About 18 months ago I wrote about the first iteration of this idea in Building a music mini-site with data from Last.fm, Discogs, and YouTube. The site evolved quite a bit from that initial post, up to the point where it got quite bloated and slow. In addition to that, it was built on Netlify, and as a Cloudflare employee, that was obviously not cool… I wanted an excuse to play with Cloudflare products anyway, so I decided to rewrite the whole thing.
Initially I planned for it to be a simpler version of the original site, but it ended up being so much fun that it is now essentially an ever-expanding artist and album database. For a bit of the nerdy detail, it’s a Next.js site hosted on Cloudflare Pages. I use Workers to manage all the API calls efficiently, and Workers KV for fast and reliable caching. I say this not just because I work there: these products are incredible. One of the reasons I’ve spent so much time on the site is that it is so easy and fun to create with these products.
So now that the site is in a pretty good place (of course, as with all side projects, it will never be done), I thought I’d share it a bit more broadly. So, give Listen To More a spin! Click around, search for stuff, enjoy. And if you run into issues (I am sure there are many bugs), I’d be forever grateful if you’d submit an Issue on GitHub.
I like Erik’s thoughts about AI and coding in Replacing my Right Hand with AI:
I do think that AI will lower the bar for anyone to be able to create software, just like anyone can use Excel to do their own personal accounting. This is a good thing!
And:
Human engineers won’t go away. We’ll still be needed to drive high-level prioritization, understand the overall architecture and scope of the problem, and review the AI’s work, especially as systems get bigger. But we’ll spend much more of our time thinking about what to build, and much less on the repetitive “how” of building it.
On the Product side of this argument, there is Paweł Huryn’s Will We Lose Our Jobs to AI? Cutting Through the Hype. Short answer: no! But he makes some points about how we should adapt that I agree with, especially these two:
- Educate yourself in AI: You should understand concepts like fine-tuning and AI agents, but there’s no need to obsess over them. YouTube videos are perfectly fine unless you want to tie your career more closely to AI.
- Get interested in the business side of the product: How do your organization’s Sales, Success, and Support teams work? How exactly does your company make money? How do you acquire customers? What are the key acquisition, retention, and revenue metrics? How do these metrics differ depending on the customer segment? How have they changed over time? Who are your competitors? What’s unique about your strategy?
In short, use AI for the things that it is good at, and get better at the things that it’s not good at.
I recently finished the book Service Model by Adrian Tchaikovsky, and thoroughly enjoyed it. There’s a little bit of a lull around the 60%–80% mark, but overall it’s a solid 4.5 stars for me. Mostly because the main character is a robot who isn’t sure if he has become self-aware or just imagining things, and he certainly isn’t sure if he even wants that. It is a wonderful premise (albeit clearly inspired by the Murderbot series), and Uncharles is probably my favorite robot character in a novel in a long time. The dude is just incredibly relatable—here are some things he says or thinks in the book:
I wish to report an error in the way that everything works.
The world, as I have witnessed it, is a place lacking in efficiency, rationality, and cleanliness. I am driven to find a place in it nonetheless.
He sat down because, having decided that there was absolutely no reason to do anything ever again, he would cause less damage to himself and his surroundings when he eventually toppled over from a seated position, rather than from standing.
I do not feel I have greatly profited from seeing the world.
I suggest that ‘kind and ordered’ is a better goal. It is possible that the world was once both kind and ordered. It is possible that it may be so again. Perhaps you will make it so.
I, for one, would like to sign up for helping to make this a “kind and ordered” world.
Anyway, it’s a wonderfully funny and delightfully poignant sci-fi story that is about robots but actually really about humans. What’s not to like.
I loved the story of the honking Waymos when it came out, and I’m glad it got the classic “but what does it all mean!?” treatment from The Atlantic:
Watching the Waymos circle the lot under the cover of darkness—and occasionally getting stuck in an endless loop—scratches a childish itch, akin to the fantasy of watching one’s toys come alive at night. In one video, the cars, bathed in taillight red and trying to exit, give off an aggressive vibe. In others, they seem clumsy. What do robots do when we can’t see them? Tung’s webcam answers the question. The stream makes it easy to spin up fictionalized, anthropomorphized yarns about the cars, because it feels like we’ve caught them in a private moment.
This whole story reminds me of scene from I, Robot where Will Smith’s character discovers a bunch of decommissioned robots in a junkyard just… standing around doing nothing. Well, until they don’t… But no spoilers.
I am a big believer in “moving at the speed of trust” with teams. You cannot shortcut the work to build strong relationships—and I’m afraid there is no roadmap or deadline for that. Sometimes it’s easy, sometimes it takes longer. But don’t skip this work. Move at the speed of trust.
Ben Kuhn shares some good tips around this in Trust as a bottleneck to growing teams quickly. I particularly like these two:
- Overcommunicate status. This helps in two ways: first, it gives stakeholders more confidence that if something goes off the rails they’ll know quickly. And second, it gives them more data and helps them build a higher-fidelity model of how you operate.
- Proactively own up when something isn’t going well. Arguably a special case of overcommunicating, but one that’s especially important to get right: if you can be relied on to ask for help when you need it, it’s a lot less risky for people to “try you out” on stuff at the edge of what they trust you on.
And speaking of communication… Also see Arne Kittler’s Part 4: Clear Communication, part of a series on “Clarity for Product Managers”:
Lengthy texts dilute your message or even discourage your counterparts to deal with them in the first place. Focus on the main points you want to make and provide the context that’s necessary to understand them as quickly as possible. When asking for information or a decision, be clear about what’s unclear.