I’ve been thinking about engineering estimates a lot and need to write about it. But for now, Adam Keys sums it up nicely:
Everyone knows surprises will happen. The estimate should help the team make better decisions when they do, not box them into promises they can’t keep. The best estimates I’ve given weren’t the most accurate—they were the ones that helped teams navigate uncertainty instead of pretending it away.
Great tip!
Convert GitHub repos to markdown with repo2txt, drag into Google AI Studio, and ask questions. Gemini’s massive context window makes it amazing for code comprehension.
The rest of the article goes into Peter’s AI coding workflow. I’ve mostly been using ChatGPT o3 for spec creation, but this is another compelling alternative.
I know we’re drowning in vibe coding stuff right now, but this extensive post about shipping code with Claude is a fantastic resource. Great prompt rules and tips, and also solid advice for what the humans are for…
Your role as a senior engineer has fundamentally shifted. You’re no longer just writing code—you’re curating knowledge, setting boundaries, and teaching both humans and AI systems how to work effectively.
Lean management and continuous delivery practices help improve software delivery performance, which in turn improves organizational performance—and this includes how you manage AI collaboration.
I love this take on the “10x engineer” phenomenon. Ubuntu (the African concept, not the operating system…) strikes again. “I am because you are.”
Individual engineers don’t own software; engineering teams own software. It doesn’t matter how fast an individual engineer can write software. What matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.
I like this idea from Lorin Hochstein about focusing more on the almost-incidents in our products:
Because most of our incidents are novel, and because near misses are a source of insight about novel future incidents, if we are serious about wanting to improve reliability, we should be treating our near misses as first-class entities, the way we do with incidents.
I imagine that a culture of “post near-incident reviews” could be really beneficial for the resiliency of our products—and our ability to predict and avoid some of the really catastrophic incidents.
In Code shufflin’ Robin Rendle writes about why he, as a designer, still messes around with coding projects. I think this is why I continue to obsess over my side project as well—and proactively reach out to indie devs who use the Cloudflare platform to see if I can help.
I’d forgotten what it feels like not to ask permission for changes and instead make pull requests and break things. There’s a momentum to this sort of work that I crave deep down in my bones because it doesn’t rely on meetings or six months of quarterly planning or going up the chain of command. And what I love most about shuffling code around is that every day there’s progress, every day there’s a tiny degree of success you can point to.
James Stanier has a good argument for why deadline-driven development is so… difficult:
Given that non-technical people don’t understand why software is hard, dates become the stick that they beat you with when you don’t deliver on time. Don’t ask me why, it’s just human behavior. I’m sure you’ve done it when roadworks have taken longer than were specified on the sign, or if a delivery of a package was late. Dates mean something to people, so handle them with care. In fact, perhaps we could do something entirely different instead.
What’s the “something different”?
So, instead, you should take a forecasting approach that follows the uncertainty curve that we outlined above. You start wide, and you taper in. At the beginning of a given project, you might even just have the year that you’re aiming to ship. Then, as you progress, you can start to narrow it down to a quarter, then a month, and finally a specific date.
This is why I will always advocate for time horizon roadmaps.
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.
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.