2 ms·

I used to work for Google - voluntarily left earlier this year. I'm not sure how much I am allowed to disclose about internal tools and processes, so I'll refer

I used to work for Google - voluntarily left earlier this year. I'm not sure how much I am allowed to disclose about internal tools and processes, so I'll refer you to this article: https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor... and call out some parts that you might care about. The workstation is not connected to the codebase via SSH on a server, but rather the version control clients are remote and mapped into the local filesystem via FUSE. So the workstation is less of a dumb terminal; programs that access the code can run locally, even though the code itself is not stored locally. Therefore, version control clients can be accessed with various web-based tools as well. Not all developers used a workflow that includes Piper/CitC, but most do. From my limited view, the Piper/CitC workflows were the most painless. Debugging - I only ever used a debugger for Python, and in those cases the application I was running was local. Otherwise I never used a debugger but rather logging (printf debugging, essentially). I'm of the opinion that if you have to open a debugger to understand the code, you've already lost. Others might have better stories. Remote machine - as mentioned above, there is no remote machine. Things are done on your workstation. The build commmands can build things locally (slow) or farm them out to a cluster of build machines in datacenters (fast). See https://bazel.build/faq.html#does-bazel-require-a-build-cluster https://bazel.build/faq.html#does-bazel-require-a-build-clus...

ralmeida 9y ago
That's very interesting, thanks for your perspective. I was familiar with Piper (from having skimmed the very article you linked), but didn't go much in depth about how it impacts dev environment. Debugging, I tend to agree with you to some extent - I'm even 'on the record' with friends on saying that debugging should 'come from the mind' before mindlessly stepping through a debugger. Being able to do it, however, may be a valuable tool to help you 'refresh your mental model' of the code, or even to build the mental model in the first place when you are first learning a new system. Building (Bazel) - Nice! Typically, when doing development on a compiled system, would you retrieve the build back from Bazel/Blaze to 'play around' with it locally? Or is most development test-driven? If the former, how many builds did you do on a typical day? If you're able/willing to share, of course.

ralmeida 9y ago

That's very interesting, thanks for your perspective. I was familiar with Piper (from having skimmed the very article you linked), but didn't go much in depth about how it impacts dev environment. Debugging, I tend to agree with you to some extent - I'm even 'on the record' with friends on saying that debugging should 'come from the mind' before mindlessly stepping through a debugger. Being able to do it, however, may be a valuable tool to help you 'refresh your mental model' of the code, or even to build the mental model in the first place when you are first learning a new system. Building (Bazel) - Nice! Typically, when doing development on a compiled system, would you retrieve the build back from Bazel/Blaze to 'play around' with it locally? Or is most development test-driven? If the former, how many builds did you do on a typical day? If you're able/willing to share, of course.