We've talked about a "safe mode" where we initialize it similar to JJ - such that you can no longer directly run git commands without funneling them thru graphite, but which would make it bulletproof. Would that be interesting?
Certainly! A lot less proof reading and pair programming and a lot more architecture / "hey should we be going in this direction" / sharing tribal knowledge
I've felt like a broken record the past few weeks, but this.
Authoring has never been the bottle neck, the same way my typing speed has never been the bottle neck.
The bottle neck has been, and continues to be, code review. It was in our pitch deck 4 years ago; it's still there.
For most companies, by default, it's a process that's synchronously blocked on another human. We need to either make it async (stacking) or automate it (better, more intelligent CI), or--ideally---both.
The tools we have are outdated, and if you're a team with more than 50 eng you've already spun up a sub team (devx, dev velocity, or dev productivity) whose job is to address this. Despite that, industry wide, we've still done very little because it's a philosophically poorly understood part of the process (why do we do code review? Like seriously, in three bullet points what's the purpose - most developers realize they haven't thought that deeply here).
I remember when I was working on https://medium.com/@tomasreimers/compiling-tensorflow-for-th... I thanked my lucky stars that TF used Eigen and not one of the popular math libraries (BLAS, Lapack) written in fortran b/c that would have been A LOT more work...
Whenever I talk to a friend starting a startup, I literally tell them to read this book.
It's really just the basics of user research (for those of us who haven't been a part of UXR before) with a focus on determining whether a startup idea has legs.
At some point, we decided that proposed changes (patches) should live in source control before they were approved and brought into history. In my view, this is where the problem lives.
I don't care about having an immutable record of the history of patches the same way I don't care about having an immutable record of your keystrokes as you produced the change. That's an implementation detail.
However, once something is merged into trunk, I want to know what was merged, when it was merged, who merged it, and any people who approved it.
