One big gotcha that folks need to appreciate is that you don't get the full power of bazel just by getting baseline bazel to work and build things. You need to

One big gotcha that folks need to appreciate is that you don't get the full power of bazel just by getting baseline bazel to work and build things. You need to really be sensitive to your physical dependencies and not lump similar code together just because they play a similar role and are convenient to place in the same file rather than having that same source sharded out to distinct files. You need to partition source into all its relevant pieces and lump no more functionality in that source than is needed by clients. Bazel encourages the most minute fine grained resolution of dependencies because if you do that and manage it right you unlock the power of the cache. Once you successfully partition all the bits of software to their segregated sections of the build graph DAG then you're positioned to really leverage the test result cache and can start bypassing huge expensive tests that are completely irrelevant to the body of code you're developing on. Bazel is not just a build toolchain it is a test toolchain as well. The problems it solves with tests with respect to running only relevant & applicable tests to the changes being pushed is what many people have dreamed about before or came up with some crude solution to approximate the dependencies. If my test did not print out `(cached)` I know something in the dependency graph was disturbed in some way that may be completely not obvious to me, especially in a gigantic repo. Bazel query is also worth mentioning to visualize dependencies with its xml output and which can also enforce architectural barriers asserting empty `somepath` queries between two targets that should not meet in the middle somewhere. It would be neat one day if bazel integrates in some semantic logical level of dependency checking beyond the physical but that may be too expensive of an operation.