I somewhat agree with you, and think you're right at least part of the time. The main disagreements I have are (a) dogfooding is not a panacea; it can result in products that are built for the user who pays the least rather than for the wider market, and (b) too often, Product is simply not hired from the market. Product rarely works when the person coming into the role was a software engineer who got an MBA, unless the product is also used by software engineers. I can't imagine trying to lead Product for, say, Excel, without a background as an accountant or banker, who lived with the problem day-in-day-out and has strong opinions about what the solution looks like.

> The product changes are primarily additive... I think the reasons for this is that it's lot easier to add new capabilities, than rethink existing capabilities.

This is perhaps the biggest difficulty in Product, and the core of the Innovator's Dilemma. Changes or removals, fundamentally, fuck with how somebody uses your product. It is very, very rare to ship a feature - something that inspired somebody in Product, got all the internal stakeholders to sign off, including getting leadership to fund it - and have nobody use it, so that it isn't controversial to remove it; even then, removing it competes with resources for adding something else, so it's still controversial to remove it. When somebody uses something that you fucked with, you risk them churning, that simple.

Coming up with good features to add is not hard. Everybody and their grandma has ideas. A simple spreadsheet can count which ones are most popular and are proposed most often. This should not, in and of itself, dictate what you build next, and bad Product leadership looks like following mass diktat.

Good Product leadership is not afraid of the consequences of fucking with the user. Good Product leadership has both the courage to reformulate the offering and gets the reformation right, because they intuitively understand the user, the domain, and where they sit in it, better than anyone else. They ship stuff that fucks with you because they understand the difference between the bad kind of being fucked with, and the good kind. And if you churn, then you churn. So be it. You can't actually make everyone happy all the time, so focus on making happy the people who get it, and accept losing the rest. That's also easier to say when you have $100k in ARR with $1k ACV, compared to $5m in ARR with $2.5m ACV.

Good Product leadership is rare because good leadership is rare. AI has nothing to do with it.

Yeah, sure, I'll file that away with the NPM "tens of thousands of tiny dependencies is OK" thinking. Constant dependency upgrades is a nightmare. There's a reason why shell + Helm is popular - they're stable.

Yes, but it might throw errors because the client library you're using is too old and attempts to define fields that no longer exist in your newer infrastructure API. You do not find these errors at compile-time, but rather at runtime, and only after both serialization and API request execution finish and you get an error from the API, in the best case, or a silent failure misconfiguring your infrastructure, at worst.

The only time an infra engineer would trust the types is if the vendor themself supplied them, or there's a mainstream community effort to keep them up to date, or they're maintained in-house with procedures to try to keep them up-to-date with new releases. At the end of the day, the API takes a string, not some protobuf or CORBA or God knows what binary serialized monster dujour...

The whole problem on the infrastructure side is that the APIs are slow and you don't have exclusive access. Building the CRUD app would be a million times harder if SQL calls took 100x longer to execute and other people could randomly reach into the database and change the schema and data at will - can your basic CRUD app gracefully handle somebody shoving newlines at the end of usernames? Odds are that the first time, no, not until you put a trim() call. And then you cry in pain at needing to put trim() calls everywhere. And then you gnash your teeth at people reporting performance problems because of all the defensive checks you put in because all trust has been thrown out. And then you find out that trim() was deprecated and will now be replaced by strim() that handles Unicode a little differently, and you need to port your code before End of Life to stay compliant.

A basic CRUD application with a basic SQL database doesn't solve the problem, because you don't seem to appreciate that there already is a database - however your vendor stores configuration - and it's your job to deal with it. Adding another database on top of it would make the problem worse.

As much as I agree with this, I don't think that the whole rest of the post (about how best to examine LLM usage in an interview loop) coheres with this.

You cannot conclusively test for common decency in either interviews or recommendations. People are on their best behavior in interviews, and it's rare for someone to pass along a recommendation that will criticize them (or their behavior). Length of tenure at prior organizations is not proof, since too many will tolerate poor behavior. Accept that this is a risk involved with any hire, have clear, written business conduct policy, and be willing to show the door to people who cannot control their behavior after written warnings.

Asking how people approach problems with LLMs need not be more than a conversation. Architectural interviews need little more than a whiteboard. If you wouldn't hover over the shoulder of an employee while they work, why do you feel the need to do so in an interview?

I get it - bad hires are expensive in more ways than one. But screen-to-offer should not take longer than two weeks in small companies. Interviews help you derisk, but do not ever fool yourself into thinking that an interview process will ever reduce your hiring risk to zero. Getting a handful of dates before a shotgun wedding will always be risky. Accept it and learn to be more comfortable with risk.

> the energy you bring to a team matter

This is all the more true for hiring managers. Bad management will take strong, high-energy, high-ownership performers and handcuff them. Good management can, sometimes, take people with weaker skills, train them, set them up for success, and inspire them into becoming great performers. Someone who is interviewing, who might accept your job offer, is also taking a risk on whether you are the bad kind or the good kind of manager. The only difference is that job seekers often have more appetite for that risk than job offerers.

1. the pedestrian traffic light's hand and "wait, citizen" text are not inside the light itself

2. The armadillo's nose is outside of the astronaut helmet

Isn't that just proof that the pelican has been benchmaxxed?

In large companies (Fortune 1000 etc.), you don't have much of a choice, the culture was eroded long ago, and corporate governance by metrics is a lesser of evils. But thankfully, not all companies are there yet.

Enterprise browsers are not like MDM that take over the entire machine. A contractor on BYOD can install a consumer browser and an enterprise browser side-by-side on his machine, using the enterprise browser (with its controls) for the contracting project and the consumer browser (free and open) for personal ends.

Mozilla is also very, very far behind in this race. But the potential is real. Enterprises have both the budget and the motivation to care about DLP (including preventing employees from copy/pasting sensitive data into AI chat apps), VPN-less access to private intranet apps (including to contractors on BYOD), preventing access to sites that distract employees and have zero business value (pornography, gambling, etc.)...

If you care about an open web browser, you should care about it having a sustainable revenue model. Enterprise browsers are exactly that revenue model. The question is not whether this is a good idea; the question is whether Mozilla can catch up.

NodeJS-only feels very pre-AI. Let me tell my agent to write my web service in Rust/C++/C/Go/Zig, and ship a statically-linked single binary that fits within a maximum binary size ceiling. I'd get much better performance, and make much more of the premium CPU/RAM pricing that I'm being asked to pay in exchange for scale-to-zero and fast autoscaling.

The rest is amazing. First-class support as a CloudFront origin. Easy multi-region and gradual deployment. Clearly, finally, a great response to Cloudflare. Just.... so close, and yet, so far. No way am I going back to Node as a web backend for greenfield projects in 2026.

Stuff that was lacking from the first edition, that it doesn't seem like it will make it into the second edition:

Financial justification and cost optimization, in particular for observability: it's easy to extoll the virtues of collecting metrics, logs, traces, and profiles, but it gets very expensive, very quickly. Conversations about observability quickly throw out the baby with the bath water, rather than laying out clear best practice approaches on when, along the lifecycle of system maturity, additional return on investment can be proven. But FinOps perspectives in general are lacking as well.

Security-focused SRE: rolling out secrets management, permissions management, certificate management, firewall/network management, adapting SIEMs, whether or not traditional SOC work should be integrated with SRE roles and given the same "solve toil like a software engineer" treatment.

I don't know if I'm really suggesting that the book should be twice as long; perhaps there should be multiple volumes: uptime reliability engineering, financial reliability engineering, security reliability engineering, for lack of better phrasing off the top of my head.

GitHub Actions is only OK for relatively simple CI needs, or if your project is open-source and you enjoy having free CI. No major professional/enterprise CI need should depend on it.

Agents just won't build it out by default - you have to ask for it.

Looking forward to seeing some benchmarks!

For sure. Still much cheaper than vacuuming every day.

> getting stuck

I appreciate that this is a function of the specific environment and robot you buy, but as a personal anecdote, this doesn't happen to me in practice. There was a setup cost, but once that was done, it doesn't get stuck.

> Emptying the vacuum bag

Not that frequent at all, considering that daily vacuuming keeps things remarkably clean and thus little is added to the main bag in the docking station each day. This is also far less work and far more preferable than doing the vacuuming myself.

The analogy is like pointing out that you can have a robot vacuum clean your floors every day. Before the robot, you'd do it maybe once a week, just no time - "too expensive" to even think about doing it daily. The robot makes it happen all the time for a tiny, tiny fraction of the cost.