16 ms·
An ex-Googler’s guide to dev tools
- logicslave 6y agoHonest opinion on FAANG tools is that the big ones are now antiquated and slowing these big tech companies down. Eventually they will need to rip out all these tools that once gave them an edge and replace them, but they cant bc of how much depends on them, and whala, you have a large failing slow company
- ponker 6y agoIs “whala” an adaptation from the French “voilá” or of a different origin?
- logicslave 6y agoIts me not caring about the spelling haha...
- jayd16 6y agoIts a boneappletea-ism.
- deleted 6y ago[deleted]
- beagle3 6y agoNot clear. Look at https://en.wiktionary.org/wiki/wallah#Etymology_2 https://en.wiktionary.org/wiki/wallah#Etymology_2 wallah is arabic slang for "by god" voila is french for "look there", meaning "just look at that" They are totally different semantically interjections originally, yet one fits almost everywhere the other does, and if Wiktionary is to be believed, in Danish one is a spelling for the other.
- tpetry 6y agoDeclaring a FAANG company failing because it‘s toolset is antiquated is the rare hn elitist opinion you see here more and more. Are startup people in the valley more and more becoming blind to the real world?
- logicslave 6y agoI'd say once you take a peak behind the curtain at some of these FAANGS you see that their once greatest assets are becoming liabilities. The magic of "FAANG" goes away. The innovative systems they all built in 2007-2012 period are now aging.
- herodoturtle 6y agoAn analogy, if I may share: On the one hand I agree with you, in that these liabilities you describe are much like the legacy systems I see in our local banking sector. On the other hand, these legacy systems just work. And adopting newer / more modern systems might definitely have advantages, but doing so creates a bunch of other liabilities - as I've seen take place in our new startup banks. Stuck between a rock and a hard place. Of course that's just in banking. I most certainly don't have the experience to comment on whether the same liability tradeoff would happen at FAANGs.
- crisper78 6y agoFAANG's often don't have paying customers, banks do. Its not being stuck between a rock and a hard place, you just need strong management that understands that changing whole systems is never a good idea without clear benefit, other than "technical debt" which is such a bad term for reliable software. Software doesn't age, im not sure how software engineers don't understand this, or maybe they do and want to write more s/w.
- oblio 6y agoSoftware does age. Security ages, network protocols age, human related configs age (timezones, for example). And that's besides tribal knowledge that goes away as people leave or retire.
- discordance 6y agoUnless I’m missing your point, I disagree. Many Microsoft teams I’ve worked with use Azure Dev Ops or Github + whatever OSS tooling they need. They have all done solid testing, infra as code and CI/CD etc. The tooling is not at all antiquated. It’s actually been pretty refreshing to be around.
- mlazos 6y agoNew orgs are forming at big companies all the time. In my time at Microsoft, I’ve seen the tooling go from horrible monorepos with perforce to really nice git repos in azure devops. I also don’t think “failing” is the right term for these megacorps. Slow maybe, but even that varies per team.
- alisonkisk 6y agoWhat does it mean to have plural monorepos?
- bregma 6y agoWouldn't the central planning committee include a great leap forward in the next five year plan? This is capitalism, after all, and it's far superior to the socialism of open source software where it's survival of the fittest in a dog-eat-dog world.
- dilyevsky 6y agoRight if only they could get on such cutting edge tech as npm, cmake or just gnu make with a pile of bash like most oss projects out there
- idank 6y agoNice, but tools are only one thing to miss about development at Google (or any other of the FAANGs). I found the more meaningful thing is the ecosystem of smart engineers, and the ability to find others who face similar problems, exchange ideas and solutions. It's a skill of its own to find these people and learn their "language", but once you do, it's a huge multiplier that is hard to find elsewhere.
- deleted 6y ago[deleted]
- dannyw 6y agoI would say there are lots of smart engineers at non-FAANG companies too; especially engineering-first orgs.
- summerlight 6y agoI think what the OP intends is its size and diversity of the talent pool. Obviously, there are so many smart engineers outside FAANG, but it's also true that having world-class experts on cryptography, networking, distributed system, web technologies, machine learning, microprocessor, compiler etc etc... in a single company is something very rare.
- zrail 6y agoI work at a FAAG-adjacent and the single most valuable thing for me personally is being able to hang out in the Slack channel where all the old timers idle. If I need context on something and nobody on my team knows, 9 times out of 10 I can ask there and someone will at least point me in the right direction.
- ind3mp0tent 6y agoRefreshing article! For people with less time check out https://github.com/jhuangtw/xg2xg https://github.com/jhuangtw/xg2xg which tracks open source implementations of Google internal tools (also linked in the article) Also I have been looking to move away from Makefiles and bash scripts and Bazel does come up more often. What are your experiences working it and how does it compare to Blaze?
- rockwotj 6y agoI'm a big fan of bazel. It's very similar to blaze, which outside of Google is a good and bad thing. The good is that I find BUILD files easier to read/reason about than Makefiles and it also is multilingual. The bad is external dependency is hard, especially if you want to take advantage of all of bazel's features like hermetic builds. Most larger C and C++ don't use bazel to build and don't have BUILD files, so you end up maintaining your own build system for that project OR use something like [this][1]. 1: https://github.com/bazelbuild/rules_foreign_cc https://github.com/bazelbuild/rules_foreign_cc
- tannhaeuser 6y agoCan't say much about Bazel. I understand it's used at Google for their increasingly polyglot builds. I just needed to isolate the incantations to get j2cl + closure-compiler (= their migration target for gwt apps) running together in a somewhat quality-assured way such that I don't run into problems related to non-aligned versions since closure-compiler, while very powerful, has always been something of a bitch to setup and run. Ended up analyzing Bazel logs to get at the needed command-line parameters, configs, etc. Would have preferred a doc about running j2cl/c-c outside Bazel rather than bundling it, since both of these programs are still just Java command-line apps. As I understood more of Bazel, I didn't find it half bad. That says a lot since my tolerance for over-reaching build tools is near zero - a couple months ago I even did the opposite of what you're suggesting and migrated my old Java builds from maven (and ant) to straight Makefiles, for a significant win in clearness, robustness, performance, scriptability, and network traffic.
- pcj-github 6y agoI'm a big fan. In order to accomplish its core mission of making build & test so much faster, it has to have near complete knowledge of your build graph (the source files and precisely how they depend upon one another). This means that to get the main benefit, you need to go all-in. Plug: for those interested in codesearch within bazel repositories, my vscode plugin for bazel has a special feature for this: https://stackb.github.io/bazel-stack-vscode/searching https://stackb.github.io/bazel-stack-vscode/searching
- galkk 6y agoI also think that one of the parts of the success is that insane amount of system configs and other data are also source controlled or provide other means textual access for search (bigquery, etc). This makes code search a super power. (googler)
- akhilcacharya 6y agoIsn't *this...common? IaaS is good practice these days. I work at an eCommerce co and we do this as well.
- tdeck 6y agoPerhaps, but what's notable about Google is the extent to which everything is a text config file, and the fact that everything is in a monorepo. As an example that surprised me, even our oncall rotations are kept in a text file along with a list of upcoming assignments. The rotation tool checks out that file and appends the next few names in the list to the end of that file to prepare the "calendar" for the coming weeks.
- ra7 6y agoUnsurprisingly, this reminds me of upstream Kubernetes where code reviewers/approvers and project maintainers are all just text files named OWNERS, and the tools just read the files to enforce the rules. Very simple and elegant!
- 6y ago
- Sevii 6y agoIsn't code search more table stakes nowadays? Both github and gitlab have it. There isn't anything said about end to end, integration or functional testing here. I'm in a world where everyone hacks their own system together onto the same runtime, leading to some wonky outcomes and lots of operational support. Would be interesting if there was a 'google' way to do it.
- greggman3 6y agoI don't know what Google's internal code search is like but if you want to see Chromium's code search it's here https://cs.chromium.org https://cs.chromium.org also android's https://cs.android.com/ https://cs.android.com/ So you can compare
- galkk 6y agoNice. It looks like a subset of internal tool. Even my favorite shortcut is working (l r - reference to current line in current commit) https://source.chromium.org/chromium/chromium/src/+/master:ios/web/find_in_page/find_in_page_request.h;l=21;drc=663a3aca17c5d94220544893e4ad436bbcde7f2a https://source.chromium.org/chromium/chromium/src/+/master:i...
- deleted 6y ago[deleted]
- skrebbel 6y agoLast I checked, GitHub's code search was so bad that it's useless. There's definitely a use for good code search.
- rockwotj 6y agoSearch on GitHub is very bad IMO. The recent semantic references stuff they've added is helping, but that only seems to be available in certain language/setups and doesn't work cross repo. Google's xref system allowed you to browse essentially the whole Google codebase - it was amazing. Third party code was indexes too, I remember my team used code search to track down a bug in NGINX once. Githubs normal search feature is bad. I can't even quote stuff for exact matches. I usually end up using bigquery for GitHub wide searches [1] or just pull down the repo and grep locally. [1]: https://www.google.com/amp/s/cloudblog.withgoogle.com/products/gcp/github-on-bigquery-analyze-all-the-open-source-code/amp/ https://www.google.com/amp/s/cloudblog.withgoogle.com/produc...
- person_of_color 6y agoArticle author interned there for "less than a year" -- LinkedIn.
- lima 6y agoPlenty of time to get an idea of the engineering workflow.
- dbnoch 6y agoYeah I agree, however its still worth pointing out. OP has been working for their own startup for 7 years and interned at google almost 10 years ago. It's basically using "ex-googler" for clicks.
- exdsq 6y agoReally? Maybe to know of it, but to know the ins and outs? As an intern? Probably not. Also it's years out of date. Practically just clickbait.
- tdeck 6y ago> Many years ago, I did a brief stint at Google. A lot has changed since then, but even that brief exposure to Google's internal developer tools left a lasting impression on me. Perhaps the operative phrase being "Many years ago". I currently work at Google, previously I worked at Square. Of the two, I generally prefer the OSS and off-the-shelf tooling at Square. Some things really are better at Google (code search and Blaze are definitely a big improvement over what we had), but many of our monitoring and CI tools feel antiquated and cluttered with inscrutable debris. Or take Gerrit, where each change has 3 different IDs and the developers decided that every workflow status should be expressed as an integer in the range [-2, 2] for some reason [1]. They were probably amazing (and much simpler) tools back in the day, but the world has moved and we're somewhat constrained by what's familiar. [1]: https://gerrit-review.googlesource.com/Documentation/images/user-review-ui-change-complex-reply-dialogue.png https://gerrit-review.googlesource.com/Documentation/images/...
- ma2rten 6y agoNote that Critique (Google's main code review UI) doesn't have the same issues that Gerrit apparently has.
- corentin88 6y agoCritique seems a well-guarded secret inside Google. Can't find more information on it. No images. Interesting
- Sesse__ 6y agoIt's a reimplementation of an earlier system called Mondrian, which you can find some information on.
- cmrdporcupine 6y agoI used Mondrian for the last couple months it existed, and I recall critique being fairly different. I think they kept the same keystrokes, though. That is one nice thing about Critique is although it's a webapp you can drive it pretty much entirely by keyboard. It has the feel of an old usenet newsreader like nn, in a way.
- burakemir 6y ago(Googler here) The article is a good description of the tools, and I was not aware of the blaze clones plz and pants. One thing that is maybe not obvious: For an API author, code search in combination with a monorepo and the somewhat hermetic universe which is Google's code base provides immediate access to all uses of a library. You can see what worked well and what didn't, and it enables effective refactorings. That also means when writing a client, you can quickly figure out from other client code how stuff is supposed to be used. All this makes code search such an effective tool in Google's development environment (in the broader sense). If anything like this were possible for open source (indexing code that depends on a library/API, across subrepos in any version control system, in a way that gets near complete coverage), it would enable similar possibilities of systematic improvement. Alas, it does not seem realistic except in a few niches where the number of clients is bounded and code owners are willing and able to follow a protocol (approve changes to their code that unblock such global improvements.)
- dannyw 6y agoCan I ask a monorepo question: what do you when you’re trying to upgrade dependency XYZ, and a moderate or large refactor is required in another team’s code?
- marcyb5st 6y agoAnother Googler here. We usually have a 3 steps process. 1st new API interface/service using the new dependency is added and runs in parallel with the existing one, 2nd we blast email to users of old one to migrate to the new one, 3rd when usage of the old one hits 0 it is removed. When a team slacks off in migrating (usually we have months between receiving the first notification and service shutdown) things escalate and a director might get involved. Anyway, this means that migrating to the new interface is clients' responsibility. However there's an exception: if the changes are trivial (like changing the the name of one of the API endpoints), we have an automated tool that basically performs this change across the whole codebase. These kinds of changes still need to be approved by the codebase owners and shouldn't break any test, so they must be really trivial. In this case is usually the team owning the API/Service that performs that.
- nt2h9uh238h 6y ago1. Why does Google develop their own tools? 2. Why doesn't Google open source them?
- redis_mlc 6y ago> 1. Why does Google develop their own tools? Often there's no OSS version yet. Usually they have better performance. They want cluster and multi-cluster services. > 2. Why doesn't Google open source them? Mainly dependencies. But they release academic papers that OSS implements.
- anoncake 6y ago> 1. Why does Google develop their own tools? Because it benefits Google. > 2. Why doesn't Google open source them? Because that would benefit the competition.
- marcyb5st 6y agoDisclaimer, I work for Google, but what follows is my personal opinion. Google open-sources a lot: Tensorflow, K8S, Apache Beam, ... . And even if it doesn't end up as fully open sourced project, Google still releases white-papers on the subject that allows startups to create something similar (Cockroach-DB for instance). However, while I admit that some decisions might be made to avoid benefitting competition (I think, that kind of stuff is way above my pay-grade), some things cannot be open-sourced for purely technical reasons (without a complete rewrite, that is). For instance, within Google everything is a protobuffer, and tools rely on that assumption heavily to work. Outside Google people don't use protobuffers nearly as much and the usage of those tools would be very low. Other tools are tied to Google having many datacenters and multiple fibers between each of them for redundancy. Like Spanner, which also requires atomic clocks to work properly.
- ikiris 6y agoSame reason stuff gets deprecated. Just maintaining the code against the dependency tree is work. Trying to make it functional in the real world that doesn't have the 50 billion libraries it relied on that are also internal only (or entire systems) is work ^ work. Unless its low level infrastructure or based on a research paper, its not an easy task.
- prepend 6y agoSourcegraph seems interesting but the pricing seems off for me. The “Teams” plan costs $150/month for 25 people and that works out to $6/user/month. Using GitHub it’s between $4-21/user/month. So this means that insight from my source costs sometimes more than actually managing my source. I’ve never worked at Google but it seems like one benefit is that they’ve figured out how to scale the costs of this kind of functionality so you don’t have to run into conundrums like this.
- dannyw 6y agoIt only needs to save your developers a few minutes of time on average to be worth it.
- prepend 6y agoI get that, and understand value-based pricing. But when it starts being relative value that it’s hard to line up. Let’s say sourcegraph saves a few minutes and it worth it. GitHub saves way more time so it’s relative value is much higher. I think this is a problem with many SaaS products in that it’s more “efficient” to just be software. It also seems like the per user costs are relatively low and the effort is in the code base indexing and whatnot. I think it’s a good idea and think it’s great if users are happy. But I’d rather have an OSS product that I could install as part of the tons of other stuff I use than be on the hook for a monthly charge for every user. I expect that they’ll be bought by GitHub or GitLab and rolled in at some point and will make more sense to me value wise when it’s like $.17 or something of an overall source management cost.
- throwaway4good 6y agoIt also needs to compensate the users for the time spent setting it up, learning it, playing with it until it actually solves a valued added use case. We developers often overestimate the value vs. cost of the tools we use ... many tools have a negative value vs. cost eventhough they are free.
- randomsearch 6y agoThere must be a name for this psychology: “Product A is great value and product B is more expensive than (or same as) product A therefore product b is bad value and I won’t buy it.” The ROI or otherwise of a product is not related to the first one. Unless your budget is so limited it’s either-or, why is this fallacy so prevalent?
- throwaway4good 6y agoThe article is based on the assumption that what developers absolutely need are the overengineered and bureaucratic tools of a big monopoly company wealthy enough to hire the absolutely best for even the most menial task.
- throwaway4good 6y agoWhat are the tools used in the most cash-strapped companies facing fierce competition yet prevailing?
- tsjq 6y agoVim, gcc, notepad++, python, mspaint, libre office, gimp,
- cowsandmilk 6y agoFor some of the things mentioned, got pull. If I want to jump around to see how a function is defined or used, I don’t need to be able to click in the web interface like you can in Critique. Pulling the code locally and using the open source tools I’m already used to works even better.
- Quarrelsome 6y agoyou're assuming the egg is after the chicken. There's a lot to argue for in stating that orgs should create tools to increase the volition of their devs.
- andrewem 6y agoI agree with what I think is your argument that “bureaucratic” tools used at a company with many thousands of engineers aren’t necessarily appropriate for a much smaller company. For example, the system of ownership by directory in a monorepo alluded to in other comments is unnecessary if you have a handful of engineers or a few dozen. Or the system like their “readability” reviews that you can read about elsewhere online (eg https://www.pullrequest.com/blog/google-code-review-readability-certification/ https://www.pullrequest.com/blog/google-code-review-readabil...) It’s when you get to a bigger size that you (probably) need to worry these cases.
- varispeed 6y agoWhile it is always interesting to read what successful company is up to, I have always been wondering what is the motivation behind ex employees writing memoirs about what was going on in the bedroom. For one, the possibility of such thing happening in the future keeps companies in check, so the company must ensure they don't do evil but also that reveals any weak points to the competition. Google is of course one of those companies that are too big to fail, but what such article would mean for a small company operating in a dog eat dog environment?
- izacus 6y agoI think it's just useful as an idea what others are doing and why. Bigger companies had more time to work on their processes and approaches. They usually also have an interest in increasing their developer productivity. It's more to see the lay of the land than anything else - might be something very cool for you to pick up. Most of it will be an overkill for smaller teams.
- cromwellian 6y agoI think what's missing from the tools discussion is the infrastructure that the tools sit on top of: 1) CitC (Client in the Cloud). Mounts your development environment on FUSE filesystems that exist in the cloud. The entire monorepo is mapped into your CitC directory. You can access it from your desktop shell, your home laptop, or a Web Browser based IDE. Any edits you make are overlaid onto the (readonly) source repository, looking seemless and creating reviewable changelists on the fly. Effortless sharing of editing between multiple machines. ObjFS, which also sits in your client, allows blaze(bazel) build artifacts to be shared as well, between clients, even between users. In other words, if I work on 3 machines, I don't need to "check out" my work 3 times. In fact, I almost never "check out" anything at all. I work in a single monorepo with Mercurial, edit files, which produce reviewable changelists against the main repo. I don't need to decide what files to check out or track, nor decide which machine I will work on, and I often switch between IntelliJ locally, IntelliJ via Chrome Remote Desktop on my office computer, and a VS-Code like Web IDE. 2) Skyframe (https://bazel.build/designs/skyframe.html https://bazel.build/designs/skyframe.html). Imagine parsing the entire monorepo and every single BUILD file into a massive pre-processed graph that knows every possible build target and its dependencies. This allows ultra-efficient determination of "what do I need to rebuild? what tests need to be re-run" across all of Google. I guess the closest thing to this is MvnRepository.net or BinTray, but Skyframe doesn't just parse the stuff and give you a search box, it informs CI tools. 3) Citc/Critique extensions to Mercurial -- take a chain of commits and make them a single code review, or take a a chain of commits and make them into a stacked chain of code reviews. 4) Critique presubmit tools (e.g. errorprone, tricorder, etc). Google has a huge number of analysis tools can run on every review update, for bugs, security problems, privacy problems, optimizations, data-races, etc. Yes, these are usually available outside, but it's just so easy to enable them internally compared to doing it on GitHub. Lots of other codehealth tools, for automatically applying fixes, removing unused code, auto-updating build files with correct dependencies. 5) Forge -- basically Blaze's remote build execution (what Bazel calls RBEs). Almost every build at Google is extremely parallelized, and if you need to run flake tests, running a suite of tests 10,000 times is almost as fast as running it once. 6) Monitoring's been mentioned, but monitoring combined with CodeSearch hasn't been touched on. Depending on configuration, you can often see from Critique or CodeSearch what release or running server code ended up in and what happened to it (did it cause bugs?). CodeSearch has an insane number of overlays, it can even overlay Google's Sentry-like exception logger being able to tell you about how many times some line of code produced a crash. A lot of Googlers use maybe 25% of all of the features in CodeSearch and Critique. Here's a in-depth article from Mike Bland https://mike-bland.com/2012/10/01/tools.html https://mike-bland.com/2012/10/01/tools.html
- gandutraveler 6y agoI boomeranged google after working at few other large techs. Google tooling was miles better 5 years back. Now the OSS tools have caught up. They are much more stable, have better UX and are transferable skill.
- summerlight 6y agoFor me, logs processing system and Dremel were probably the most marvelous tools that I've ever seen in my SWE career. Millions of machines are producing trillions of logs records everyday. Then Dremel runs some arbitrary query over those records in an order of minutes (seconds for simple queries), without indexing.
- dilyevsky 6y agoThere are a few oss dremel alternatives with Clickhouse being my favorite To me their absolute best technology edge is still their storage system (colossus)
- exclipy 6y agoIn the table for "Write Code" / "Inside Google", I think you mean Cider, not Critique.
- zcw100 6y agoThe one tool everyone missed was marketing with being able to call yourself an ex-googler being the biggest tool in the toolbox. Let me share the other side of the diaspora (I dislike this term). Tons of former X, pick your popular Silicon Valley company, employees with little else to sell other than that they worked foe x company. The vain CEO hires them hoping that they’ll sprinkle some magic fairy dust on their dysfunctional company. Never mind that the reason it’s disfunction is because the CEO hired his buddy from high school with a degree in poly sci to run things and is having an affair with the head of hr. Our intrepid developer constantly mumbles “we’ll at x we used to do whatever.” Afraid that the CEO will realize that the fairy dust is just a combination of cool aid and glitter starts throwing people under the bus and the knives come out.
- nvarsj 6y agoYes... It's a huge pet peeve of mine when recruiters, companies, tools, say something like "written by ex-googlers", "work with ex-googlers", etc. Like it means anything at all that you have an engineer from a company w/ 100k employees. It's absolutely meaningless. And you see it all the time, especially in link-bait Hacker News headlines.
- mav3rick 6y agoDid you even read the article ? It's incredibly well written with pros and cons of each tool. I know you have a hatchet to bury against Google but why don't you read the article first.
- Cthulhu_ 6y ago
- pontus 6y agoI found this super useful. It has a bit more suggestions than the article. https://github.com/jhuangtw/xg2xg https://github.com/jhuangtw/xg2xg
- arthurjj 6y agoThanks this is the table I was hoping the article would have
- rahimnathwani 6y agoIt's linked in the article, and the next sentence explains the motivation for not just starting with that list: "This list is comprehensive, but a bit overwhelming. So where do you start?"
- diveanon 6y agoGoogle's internal tooling, and by extension the developers who blog incessantly about it after doing a brief stint there are highly overrated.
- utopcell 6y agoI suspect the author meant to mention "cider", not critique, for writing code.
- deleted 6y ago[deleted]
- dontreact 6y agoEx Googler here I really liked this article. It makes great points about the order in which to try to improve things. I feel seen about trying to push a build system before having built social capital. Great to learn about other build systems. I am still having trouble explaining "what's wrong with just using Makefiles"... working on it.
- junon 6y agoWe need to stop treating "ex-Googler" or "Googler" as some form of elite credential. It's not, and Google is hardly any authority on good software.
- tellis72 6y agoDid you even read the article? The guy never claimed some elite stance. Google is well-known for its internal tools. It would help to educate yourself a bit.
- kudokatz 6y agoIf you read between the lines, the article sounds a lot like "I know better", implicitly "because I worked at Google" (as per the "ex-Googler" qualifier in the title). Consider this: > Introducing code search and monitoring doesn't require asking anyone on the team to change existing workflows. Changing the code review tool, however, does. It basically sounds like the author wants to take over and tell everyone how to do things. After time at Google, comparing them to other organizations all the way from 8-person start-ups to other FAANG+Microsoft, there are a LOT of downsides to their tools and their isolated ecosystem. A lot of things are more difficult and take longer to just get done than elsewhere at the same quality. > Google is well-known for its internal tools. It would help to educate yourself a bit. This may also be exactly the attitude OP was talking about.
- mraza007 6y agovery interesting article. how do people stay updated with latest tools outside of google's ecosystem and do they feel like they are missing out. lastly I am just curious to know why don't companies adopt opensource tools that are being used everywhere so skills can be transferable easily
- ramon 6y agoDid Google copy Google in the first place? You can use it as your study case but think about making it better, put your progress in the table, innovate.
- goatinaboat 6y agoHow many ex-Googlers are there in the world now? There must be a few hundred thousand.
- mark_l_watson 6y agoI used Docker to install sourcegraph yesterday on my MacBook. It took a while to locally cache about 2 GB of data from my 130 GitHub repos. I think this is a game changer, but I need a few weeks with it to make sure that the ceremony is worth the effort. I should probably be running it in a VPS rather than my laptop. I worked as a contractor at Google in 2013 and I do miss their internal dev environment.