keegancsmith's comments

Sourcegraph engineer here. I'd be interested to know what you were searching for and what your expectation for top result was. We already do things like boost class name matches higher than functions (GitHub's new search does the same) amongst other possible signals.

There is also plz.review which more closely mirrors gerrit (ui flow, keyboard driven, etc). Plus I found the cli more pleasing to use than graphites. But glad there are finally options in this space!

- Mark Brooker :: https://brooker.co.za/blog long time lead engineer @ AWS blogging technical info on distributed systems - Chris Wellons :: https://nullprogram.com/ lots of interesting explorations in code

Also surprised by all these articles. But your point made me realise that most people didn't do accounting in high school like I did (also a South African). I wonder what some other uncommon high school curriculums from other parts of the world are.

In retrospect I wish what we learnt in High School was more focussed on personal finance than essentially constantly doing double entry data capture.

This is tricky but when you reframe it it's clear the heuristic you mention is the correct one. The value of a test is giving signal to a developer that the code they wrote is correct. If a test is flaky due to the test or the code, the signal the test provides has now become negative. The parent mentions filing it on the team that owns the test. This sounds correct and the onus is then on that team. At larger companies this process is automated. You may enjoy the flake detection section in this blog post https://dropbox.tech/infrastructure/athena-our-automated-bui...

Capturing is very simple since it is just plain text. For example here is a guide which uses siri on iOS to capture voice notes to your org-mode inbox: https://orgmode-exocortex.com/2020/04/30/voice-capture-org-m...

There is also a guide for android https://orgmode-exocortex.com/2020/04/28/voice-capture-org-m...

FB is company D or E. FB you could have a linux laptop though, and could install linux on the mac. Not officially supported, but lots of people installed linux.

I was an h1b holder working in Silicon Valley. My wife not being able to work was the main reason why we left after 2 years. Kind of silly to go through that whole song and dance of getting a skilled person to move across the world only to treat the spouse as if the only purpose they have is home keeping.

We (I work at Sourcegraph) actually started off with a similar model to kythe: https://srclib.org/ This project existed before kythe was published, but was based on the ideas talked about pre-dating kythe. If I remember correctly Steve Yegge had some blogpost about solving the MxN problem, which turned into him doing grok at Google.

We ended up switching away from that model for a few reasons:

- At the time it was very costly to essentially index the whole OSS world, when most commit indexes would never be read.

- It was slow to index a codebase for a commit, and most of the work was wasted since a developer would often only look at a handful of files.

- Getting incremental indexing working usually required pretty deep integration into the build tool, so was a lot of work per language which didn't scale.

- A lot of tools using an "indexed" model end up only indexing the master/trunk branch, and you don't get your code intelligence features for PRs/etc.

At some point LSP came onto the scene. We were early adopters making a bet that this would take off. It has, and the list of community created LSP servers is large: https://langserver.org/ It also allowed us to switch from an upfront indexing model, to a model which just encodes user intent. So the underlying LSP server can be as lazy as it wants to be with respect to how it responds to the user == increased perf and reduced resources.

Things like cross-repo references doesn't come with LSP. Many LSP servers assume the user sets the build up correctly. There are also quite a few more assumptions LSP authors make which don't easily translate into an automated server environment. So we have done quite a bit of work to smooth that over / contributed some LSP servers for popular languages.

Seems like you are digging in so you might have more questions. I'll try keep track of this thread, but also feel free to email me keegan at sourcegraph.com or file issues/questions on our repo.

I can understand the "daily standup" being very useful to you as the manager. I'm interested if the engineers find it useful though. Personally, in both remote and local contexts I haven't found much value in them.

10K+ concurrent requests to a single server sounds like a server that is mostly shuffling bits around. I assume the 150 concurrent is more realistic for a frontend server which actually does something.

Also note the speaker is a CTO of a CDN (fast.ly), I am guessing he has experience with large concurrent requests as well :)

An improvement I'd make to this is not sending the current directory to docker, but rather a directory containing just the binary. That way you don't send a massive context to docker which you just throw away. (Especially in go projects which vendor in a lot of dependencies)