>I love this. I’m going to add your 'Shield & Deliver' path as an alternative (and perhaps superior) winning state. This is exactly the nuance I wanted to surface.
I would be wary of this being the superior winning state, but definitely an alternative. I've done exactly this in my career as a tech lead only for it to burn me, and probably 2/3rds of the time the best thing for everyone is to simply "Save the Sprint" and not become mired in discussions that often are for personal empire building that strategic leadership would hate.
Maybe people have different experiences than me on this, feel free to speak up!
This is exactly why management is hard to unit test!
You are absolutely right. If you 'Shield & Deliver' every time, you risk becoming the 'Yes Man' who absorbs infinite scope creep for someone's vanity project (Empire Building).
The 'Correct' answer actually depends entirely on the Nature of the Request:
Legitimate Business Crisis? -> Shield & Deliver
Noise/Politics? -> Save the Sprint
Distinguishing between the two before you act is the master skill.
I think keeping both paths as valid strategies with different 'Trade-off' warnings or having 2 different contexts is the right move to reflect that ambiguity
When the traffic was peak, I did use LLM to polish my responses.
Later, I started replying without an LLM.
No, AI agents at work. This is an individual at work!
>If the VP requires these numbers and went as far as back channeling you there is probably a quite good reason for that.
This is good intuition but generally people won't tell you whether they have a good or silly/self-serving reason in my experience, and you can only really get them to surface that by comparing it to the priority of other commitments and forcing them to depriotize something.
I think the ratings might be a bit borked. There's a dialogue path choice that results in the A+ where you end up asking directly whether the back-channel was worth another delay, and you. The VP says no. No junior gets interrupted.
Sometimes you don’t even need to surface it. You just force responsibility: “This will prevent us from being ready for Friday’s demo. If you’re cool with that I’ll run it by {project sponsor}.”
Now it’s between the VP and the project sponsor - as it rightfully should be.
Wow, this is really great. These vignettes could make a good, short book that doesn't get into weird diatribes and instead actual experiences with engineering orgs. This is basically what I want to show to senior/staff engineers about how to do this back and forth.
I wanted to pre-order, but the link doesn't let me.
Thank you! That specific use case—helping Senior/Staff engineers visualize the 'back and forth'—is exactly where I think the biggest gap is. It’s hard to learn negotiation from a static blog post.
On the Pre-order: I’m sorry about that! The payment gateway is currently stuck in 'Verification Pending' (bad timing with the HN hug).
>All with the goal of enabling users to build fast analytics from the Postgres layer itself but still using the power of ClickHouse!
That would be incredible! So many times I want to reach for ClickHouse but whatever company I'm at has so much inertia built into PG. Pleease add CTE support.
And yes I'm aware of PeerDB or whatever that project is called. This is still or even more helpful.
Totally! Making things way easier on the app and query side is very important, which is why we plan to invest heavily in this going forward.
With respect to data replication, it gets really hard and has its challenges as data sizes grow - reliably moving tens of terabytes at speed, handling intricate quirks around replication slots, enterprise-grade observability etc. PeerDB/ClickPipes is designed to solve these problems. I wrote a blog post covering this in more detail here: https://clickhouse.com/blog/postgres-cdc-year-in-review-2025
That said, point taken - we will ensure query and app migration is seamless as well and reduce friction in integrating Postgres and ClickHouse. pg_clickhouse is a step in that direction! :)
I shouldn't be so flippant on here, of course I'm talking to the guy who wakes up and hears this every day.
I really appreciate the work that he and y'all are doing on both sides of the equation, it's great for every org that wants to use ClickHouse but can't.
Combined with security concerns, this made us reconsider even our self-hosted GH Actions last month.
GH Packages is something we're extricating ourselves from after today too. One more outage in the next year and maybe we get the ammunition to move away from GH entirely.
It's still hard to believe that they couldn't even keep the lights on on this thing.
In the real world, I'd say the 90% of the C code written is somewhere between "worthwhile to spend extra effort to detect and avoid memory errors" and "worth formally verifying".
Sure, for prototype sized codebases it might be able to handle finding mistakes a fresh grad might easily make, or even that memory bugs aren't a big problem - but in my experience it happily adds memory bugs to large codebases and multithreaded code (that I think an experienced human could easily spot tbh).
I would be wary of this being the superior winning state, but definitely an alternative. I've done exactly this in my career as a tech lead only for it to burn me, and probably 2/3rds of the time the best thing for everyone is to simply "Save the Sprint" and not become mired in discussions that often are for personal empire building that strategic leadership would hate.
Maybe people have different experiences than me on this, feel free to speak up!
reply