Menu

Posts tagged “engineering”

Field Notes From Shipping Real Code With Claude

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.

Field Notes From Shipping Real Code With Claude

In Praise of “Normal” Engineers

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.

In Praise of “Normal” Engineers

You're missing your near misses

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.

Code shufflin’

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.

What does a date actually mean?

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.

Why GitHub Actually Won

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.

Introducing "Listen to More"

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.

Replacing my Right Hand with AI

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.

How we got here (it’s not a “root cause”, it’s the system)

Lorin Hochstein shares a characteristically solid systems-thinking take in CrowdStrike: how did we get here?:

Systems reach the current state that they’re in because, in the past, people within the system made rational decisions based on the information they had at the time, and the constraints that they were operating under. The only way to understand how incidents happen is to try and reconstruct the path that the system took to get here, and that means trying to as best as you can to recreate the context that people were operating under when they made those decisions.

The “no root cause” concept is something I’ve been thinking about a lot as I’m working on a particularly complex project at work. Somehow we constantly forget that things usually are the way they are not because of a single “mistake”, but because of a the culmination of a bunch of legitimate reasons.

Systems get the way they are because of decisions made in good faith based on the data available at the time. And the worst thing you can do as a new person coming in to improve things is to hunt for a single “root cause” to fix. That’s just not how software (or people!) work. So take the time to understand Chesterson’s fence. Go ahead and draw boxes and arrows until no one disagrees any more about how the system works. And then figure out which parts can be improved, and in which order.


PS. Also see How Complex Systems Fail:

Because overt failure requires multiple faults, there is no isolated ‘cause’ of an accident. There are multiple contributors to accidents. Each of these is necessarily insufficient in itself to create an accident. Only jointly are these causes sufficient to create an accident. Indeed, it is the linking of these causes together that creates the circumstances required for the accident. Thus, no isolation of the ‘root cause’ of an accident is possible. The evaluations based on such reasoning as ‘root cause’ do not reflect a technical understanding of the nature of failure but rather the social, cultural need to blame specific, localized forces or events for outcomes.

You are not your team’s umbrella

Two recent articles about engineering management stuck with me because they complement each other well to articulate a leadership philosophy I’ve held for a long time, but haven’t been able to put into words effectively.

First, in The Disappointment Frontier James Stanier expands on a controversial quote: “leadership is disappointing people at a rate they can absorb.” He talks about how keeping teams in a “bubble of protection” (where you act as the “umbrella” for bad news) never ends well. And even though managing disappointment is a core leadership skill, it is typically overlooked when training new managers. It’s worth reading the whole article, but here is a key point:

Managing a team of any size—from a handful of people to a whole company—is a continual balance between trying to empower people to achieve what they want (interesting projects, plentiful opportunities, a plethora of pay increases and promotions) whilst navigating a conflicting reality that doesn’t always want to give it to them. As such, there is a lot of truth to the quote at the beginning of the article. Leadership is about disappointing people at a rate they can absorb. In fact, I think that I’ve likely spent far more time on mitigation of disappointment or on managing expectations than I have on being motivational in my management career.

James goes on to give some really good advice on how to manage disappointment well. The second article is Will Larson’s Unexpected Anti-Patterns for Engineering Leaders, in which he also discusses the dangers of the “umbrella” approach:

The more senior the teams I’ve worked with, the more I’ve come to believe that protecting your team from reality just makes things worse for them in the long term. Larson now tries to throw his team into the gory details much more quickly. “In the past, I used to think I was energizing my team by sparing them the details. But now it feels like lying to them,” he says. On a tactical level, Larson adjusted this habit by buffering less information. “That means even if it’s disappointing for folks, I’d rather them process news bit by bit, rather than deal with a huge ocean of mess all in one moment.”

Obviously you are not going to tell your team every little thing that happens in your day and your meetings. But the idea that we should shield our teams from the realities of an organization is fundamentally flawed and ultimately does a huge disservice to people. If we hide the context of our decisions or guidance we lose the trust of our team—and once that happens, all is lost. This approach also stunts growth. If we don’t prepare people for how organizations work, their eventual exposure to reality will be a huge shock and we would’ve lost out on the opportunity to coach them slowly over time.

I once received some performance review feedback that I am “too transparent” with my teams, and I need to dial that down a bit. I respectfully declined. I don’t know of any other way to be—both as a human and as a manager. I also firmly believe I would be a worse people manager if I adopted that feedback.

That said, transparency is a skill. One I’ve cultivated for many years, and will likely never fully master. How and when you say things matter, and it takes time to learn those nuances. The above articles give some great advice on how to start that journey with your teams. So I encourage you to give transparency a try. I think you’ll find that you immediately become partners with your team members, as opposed to just their “boss.” And you will make magic together once that happens.