At this years NDC Oslo conference I spoke about helping other engineers develop C++ effectively when you're at massive scale. This talk is about the tooling that goes into helping a single engineer evaluate the question "is my diff, my code change, safe?" even when the scope of that change is hundreds of thousands of files. I explain how you can tweak otherwise "ok" tooling to build trust so that it becomes great tooling. This talk is about what a few other engineers and I do at work.
The original abstract:
Enabling engineers to write correct C++ is hard. Period. Full stop. At Facebook we've put a lot of effort into letting our engineers focus on impact; everything else should "just work". This talk addresses the question "How do you prevent code from breaking?". We'll talk about the automatic tools behind knowing when and why code breaks; the answers to these questions inform more than just whether it's ok to ship code, but also how to triage existing bugs more effectively.
We'll also talk about the human issues behind making that information easily consumable; incorrect or flakey reporting of bugs is an obvious problem, but reporting real bugs in a noisy fashion is a dangerous problem in its own right. This talk is about all of the things that go into creating a scalable environment to develop correct C++.