profile
viewpoint
Nick Snyder nicksnyder @sourcegraph San Francisco, CA

linkedin/LayoutKit 3119

LayoutKit is a fast view layout library for iOS, macOS, and tvOS.

nicksnyder/go-i18n 1481

Translate your Go program into multiple languages.

nicksnyder/ios-cell-layout 12

How to use autolayout for dynamically sized UITableViewCells

nicksnyder/basen 8

A base62 and base58 encoding library for Go

nicksnyder/go-securetoken 7

The securetoken package implements web-safe secure tokens in Go.

nicksnyder/activity 1

Activity is a command line tool that summarizes a person's activity from various services.

nicksnyder/docs 1

My personal style guide

nicksnyder/IBDesignableExamples 1

Example usage of @IBDesignable and @IBInspectable

nicksnyder/AndroidNativeVsWebView 0

Compare performance of native rendering vs WebView rendering

pull request commentsourcegraph/about

blogpost: Introducing a new database for code intel

I still have some feedback and I think it would be most effective to chat live tomorrow.

efritz

comment created time in 10 hours

Pull request review commentsourcegraph/about

blogpost: Introducing a new database for code intel

+---+title: 'Introducing a new database for Code Intelligence'+author: 'Eric Fritz'+publishDate: 2020-10-18T00:00-07:00+tags: [+  "blog"+]+slug: introducing-a-new-code-intelligence-database+heroImage: https://image.flaticon.com/icons/png/512/51/51333.png+published: true+---++With the release of 3.21, Sourcegraph will ship with a _second_ Postgres database instance, named `codeintel-db`, which we use to store the data that powers [precise code intelligence](https://docs.sourcegraph.com/code_intelligence/explanations/precise_code_intelligence).++We've [written previously](https://about.sourcegraph.com/blog/evolution-of-the-precise-code-intel-backend/) about the architectural changes we have made to the code intelligence backend. This post is yet another submission in the archaeological trail of how the code intelligence team shapes Sourcegraph on a technical level. The post explains why we chose to swap out our persistence layer - a very non-trivial difference in our architecture.++**TL;DR 1**: If you are a customer currently using precise code intelligence, [skip to the notes below](#notes-for-site-admins) to see how this could affect your instance.++**TL;DR 2**: If you are here for a daily dose of schadenfreude, read about how [we mucked this migration on our production instance](https://eric-fritz.com/articles/migrating-to-postgres/) on Sourcegraph.com.++## The impetus for a second database++A bit over a year ago, the code intelligence backend started as a single node process with access only to its own persistent volume. We chose SQLite as our persistence mechanism for a handful of reasons:++- It was the faster implementation compared to other contending designs we tried.+- Our MVP did not have access to Postgres at the time, which was owned solely by another team. Only later did we get access to Postgres to store cross-repository metadata and work queue data.+- SQLite had some nice properties such as easy data warehousing opportunities (on which we have not capitalized) and bulk deletion of expired data was straightforward. All we had to do was delete the SQLite file.++Using SQLite for this data has become an operational and feature burden for the code intelligence team.++1. We need to maintain a periodic process to reconcile the data on disk with the metadata we store in Postgres.+2. We have good instructions and tips for backup and recovery of our Postgres data store, but have never officially recommended backing up other persistent volumes.+3. We locked ourselves into a node topology which is not easily scalable. We essentially have a singleton service over a persistent volume. In order to scale this service horizontally (which would become necessary once either the amount of data or the frequency of queries increased), we would need to shard the data across multiple volumes. This throws a lot of wrenches into our plans: we need to be able to automatically move data on increase or decrease of shard counts; we need to be able to route requests to the correct node with that data; we need to ensure that reconciliation between the data on disk and the metadata we store in Postgres is aware that there are multiple nodes where data _could_ reside.+4. There is no efficient way to implement certain data access patterns we may need in the future. For example, looking for data matching a certain identifier _name_ would require us to open every SQLite database on disk (and, no, _batching it_ is not a solution).++Instead of forging ahead and tackling the complexity we've made for ourselves, we decided to take a step back and re-evaluate whether or not our previous architecture choices were meeting our current needs. And it seems like they did not.++Moving this data into Postgres seems like an obvious choice that will (eventually) be able to reduce or completely remove all of the burdens listed above.++1. Reconciling pieces of data in the same datastore is trivial compared to reconciling pieces of data in two different datastores, especially if it should be done transactionally. Even though we're not in the same _physical_ database instance, having all of our data in _some_ Postgres-compatible store opens up the possibility of transactions spanning multiple physical Postgres instances via [postgres_fdw](https://www.postgresql.org/docs/12/postgres-fdw.html#id-1.11.7.42.12).+2. Moving data to an existing technology allows us to re-use the same advice and documentation for backup and disaster recovery strategies. Removing the number of knobs that must be turned by site-admins is always going to be a win across the board.+3. Moving from an embedded database to a server-client database removes the nasty singleton property on the service. Now that multiple servers can interact with the same data concurrently without risk of corruption, we can scale the services horizontally without requiring additional effort into implementing sticky sessions or complex request routing rules.+4. Moving data into a single relational store allows us to create additional indexed views into the data. We can now query over dimensions that were not possible before without opening tends of thousands of relatively small database files.++## Notes for site admins

So my question is, why not delete all the content and just keep the links? If there is any content that you hesitate to delete, ask yourself if it belongs somewhere else (e.g. inside one of those links).

efritz

comment created time in 10 hours

PullRequestReviewEvent

Pull request review commentsourcegraph/sourcegraph

codenotify: add self to various places

+**/* @LawnGnome

fine with me!

LawnGnome

comment created time in 11 hours

PullRequestReviewEvent

Pull request review commentsourcegraph/sourcegraph

codenotify: add self to various places

+**/* @LawnGnome

If you wanted, you could do something like this at the root directory (instead of adding a CODENOTIFY file under each campaigns dir.

**/campaigns/**

Totally up to you though.

LawnGnome

comment created time in 11 hours

PullRequestReviewEvent
PullRequestReviewEvent

push eventsourcegraph/about

Nick Snyder

commit sha d32e8493497a06ca3faf2402a19c2502fcd48dce

Update handbook/engineering/onboarding/software-engineer-onboarding.md Co-authored-by: Chris Pine <chrispine@sourcegraph.com>

view details

push time in 12 hours

push eventsourcegraph/about

Nick Snyder

commit sha fe955bf8213a7afe6bc854e8e3070eedae4d97f6

Update handbook/engineering/onboarding/engineering-manager-onboarding.md Co-authored-by: Chris Pine <chrispine@sourcegraph.com>

view details

push time in 12 hours

Pull request review commentsourcegraph/about

blogpost: Introducing a new database for code intel

+---+title: 'Introducing a new database for Code Intelligence'+author: 'Eric Fritz'+publishDate: 2020-10-18T00:00-07:00+tags: [+  "blog"+]+slug: introducing-a-new-code-intelligence-database+heroImage: https://image.flaticon.com/icons/png/512/51/51333.png+published: true+---++With the release of 3.21, Sourcegraph will ship with a _second_ Postgres database instance, named `codeintel-db`, which we use to store the data that powers [precise code intelligence](https://docs.sourcegraph.com/code_intelligence/explanations/precise_code_intelligence).++We've [written previously](https://about.sourcegraph.com/blog/evolution-of-the-precise-code-intel-backend/) about the architectural changes we have made to the code intelligence backend. This post is yet another submission in the archaeological trail of how the code intelligence team shapes Sourcegraph on a technical level. The post explains why we chose to swap out our persistence layer - a very non-trivial difference in our architecture.++**TL;DR 1**: If you are a customer currently using precise code intelligence, [skip to the notes below](#notes-for-site-admins) to see how this could affect your instance.++**TL;DR 2**: If you are here for a daily dose of schadenfreude, read about how [we mucked this migration on our production instance](https://eric-fritz.com/articles/migrating-to-postgres/) on Sourcegraph.com.++## The impetus for a second database++A bit over a year ago, the code intelligence backend started as a single node process with access only to its own persistent volume. We chose SQLite as our persistence mechanism for a handful of reasons:++- It was the faster implementation compared to other contending designs we tried.+- Our MVP did not have access to Postgres at the time, which was owned solely by another team. Only later did we get access to Postgres to store cross-repository metadata and work queue data.+- SQLite had some nice properties such as easy data warehousing opportunities (on which we have not capitalized) and bulk deletion of expired data was straightforward. All we had to do was delete the SQLite file.++Using SQLite for this data has become an operational and feature burden for the code intelligence team.++1. We need to maintain a periodic process to reconcile the data on disk with the metadata we store in Postgres.+2. We have good instructions and tips for backup and recovery of our Postgres data store, but have never officially recommended backing up other persistent volumes.+3. We locked ourselves into a node topology which is not easily scalable. We essentially have a singleton service over a persistent volume. In order to scale this service horizontally (which would become necessary once either the amount of data or the frequency of queries increased), we would need to shard the data across multiple volumes. This throws a lot of wrenches into our plans: we need to be able to automatically move data on increase or decrease of shard counts; we need to be able to route requests to the correct node with that data; we need to ensure that reconciliation between the data on disk and the metadata we store in Postgres is aware that there are multiple nodes where data _could_ reside.+4. There is no efficient way to implement certain data access patterns we may need in the future. For example, looking for data matching a certain identifier _name_ would require us to open every SQLite database on disk (and, no, _batching it_ is not a solution).++Instead of forging ahead and tackling the complexity we've made for ourselves, we decided to take a step back and re-evaluate whether or not our previous architecture choices were meeting our current needs. And it seems like they did not.++Moving this data into Postgres seems like an obvious choice that will (eventually) be able to reduce or completely remove all of the burdens listed above.++1. Reconciling pieces of data in the same datastore is trivial compared to reconciling pieces of data in two different datastores, especially if it should be done transactionally. Even though we're not in the same _physical_ database instance, having all of our data in _some_ Postgres-compatible store opens up the possibility of transactions spanning multiple physical Postgres instances via [postgres_fdw](https://www.postgresql.org/docs/12/postgres-fdw.html#id-1.11.7.42.12).+2. Moving data to an existing technology allows us to re-use the same advice and documentation for backup and disaster recovery strategies. Removing the number of knobs that must be turned by site-admins is always going to be a win across the board.+3. Moving from an embedded database to a server-client database removes the nasty singleton property on the service. Now that multiple servers can interact with the same data concurrently without risk of corruption, we can scale the services horizontally without requiring additional effort into implementing sticky sessions or complex request routing rules.+4. Moving data into a single relational store allows us to create additional indexed views into the data. We can now query over dimensions that were not possible before without opening tends of thousands of relatively small database files.++## Notes for site admins

I think the right way to call it out is to link to a source of truth. If those documents don't have sufficient information (customers have asked questions) then I think we should add context to the source of truth, not add more information here in this blog post.

efritz

comment created time in 13 hours

PullRequestReviewEvent

Pull request review commentsourcegraph/about

blogpost: Introducing a new database for code intel

+---+title: 'Introducing a new database for Code Intelligence'+author: 'Eric Fritz'+publishDate: 2020-10-18T00:00-07:00+tags: [+  "blog"+]+slug: introducing-a-new-code-intelligence-database+heroImage: https://image.flaticon.com/icons/png/512/51/51333.png+published: true+---++With the release of 3.21, Sourcegraph will ship with a _second_ Postgres database instance, named `codeintel-db`, which we use to store the data that powers [precise code intelligence](https://docs.sourcegraph.com/code_intelligence/explanations/precise_code_intelligence).++We've [written previously](https://about.sourcegraph.com/blog/evolution-of-the-precise-code-intel-backend/) about the architectural changes we have made to the code intelligence backend. This post is yet another submission in the archaeological trail of how the code intelligence team shapes Sourcegraph on a technical level. The post explains why we chose to swap out our persistence layer - a very non-trivial difference in our architecture.++**TL;DR 1**: If you are a customer currently using precise code intelligence, [skip to the notes below](#notes-for-site-admins) to see how this could affect your instance.++**TL;DR 2**: If you are here for a daily dose of schadenfreude, read about how [we mucked this migration on our production instance](https://eric-fritz.com/articles/migrating-to-postgres/) on Sourcegraph.com.++## The impetus for a second database++A bit over a year ago, the code intelligence backend started as a single node process with access only to its own persistent volume. We chose SQLite as our persistence mechanism for a handful of reasons:++- It was the faster implementation compared to other contending designs we tried.+- Our MVP did not have access to Postgres at the time, which was owned solely by another team. Only later did we get access to Postgres to store cross-repository metadata and work queue data.+- SQLite had some nice properties such as easy data warehousing opportunities (on which we have not capitalized) and bulk deletion of expired data was straightforward. All we had to do was delete the SQLite file.++Using SQLite for this data has become an operational and feature burden for the code intelligence team.++1. We need to maintain a periodic process to reconcile the data on disk with the metadata we store in Postgres.+2. We have good instructions and tips for backup and recovery of our Postgres data store, but have never officially recommended backing up other persistent volumes.+3. We locked ourselves into a node topology which is not easily scalable. We essentially have a singleton service over a persistent volume. In order to scale this service horizontally (which would become necessary once either the amount of data or the frequency of queries increased), we would need to shard the data across multiple volumes. This throws a lot of wrenches into our plans: we need to be able to automatically move data on increase or decrease of shard counts; we need to be able to route requests to the correct node with that data; we need to ensure that reconciliation between the data on disk and the metadata we store in Postgres is aware that there are multiple nodes where data _could_ reside.+4. There is no efficient way to implement certain data access patterns we may need in the future. For example, looking for data matching a certain identifier _name_ would require us to open every SQLite database on disk (and, no, _batching it_ is not a solution).++Instead of forging ahead and tackling the complexity we've made for ourselves, we decided to take a step back and re-evaluate whether or not our previous architecture choices were meeting our current needs. And it seems like they did not.++Moving this data into Postgres seems like an obvious choice that will (eventually) be able to reduce or completely remove all of the burdens listed above.++1. Reconciling pieces of data in the same datastore is trivial compared to reconciling pieces of data in two different datastores, especially if it should be done transactionally. Even though we're not in the same _physical_ database instance, having all of our data in _some_ Postgres-compatible store opens up the possibility of transactions spanning multiple physical Postgres instances via [postgres_fdw](https://www.postgresql.org/docs/12/postgres-fdw.html#id-1.11.7.42.12).+2. Moving data to an existing technology allows us to re-use the same advice and documentation for backup and disaster recovery strategies. Removing the number of knobs that must be turned by site-admins is always going to be a win across the board.+3. Moving from an embedded database to a server-client database removes the nasty singleton property on the service. Now that multiple servers can interact with the same data concurrently without risk of corruption, we can scale the services horizontally without requiring additional effort into implementing sticky sessions or complex request routing rules.+4. Moving data into a single relational store allows us to create additional indexed views into the data. We can now query over dimensions that were not possible before without opening tends of thousands of relatively small database files.

I think it is ok to talk about hypothetical future benefits as perks, as long as that is separate from and after the reasons why we are doing it now.

efritz

comment created time in 13 hours

PullRequestReviewEvent

Pull request review commentsourcegraph/about

blogpost: Introducing a new database for code intel

+---+title: 'Introducing a new database for Code Intelligence'+author: 'Eric Fritz'+publishDate: 2020-10-18T00:00-07:00+tags: [+  "blog"+]+slug: introducing-a-new-code-intelligence-database+heroImage: https://image.flaticon.com/icons/png/512/51/51333.png+published: true+---++With the release of 3.21, Sourcegraph will ship with a _second_ Postgres database instance, named `codeintel-db`, which we use to store the data that powers [precise code intelligence](https://docs.sourcegraph.com/code_intelligence/explanations/precise_code_intelligence).++We've [written previously](https://about.sourcegraph.com/blog/evolution-of-the-precise-code-intel-backend/) about the architectural changes we have made to the code intelligence backend. This post is yet another submission in the archaeological trail of how the code intelligence team shapes Sourcegraph on a technical level. The post explains why we chose to swap out our persistence layer - a very non-trivial difference in our architecture.++**TL;DR 1**: If you are a customer currently using precise code intelligence, [skip to the notes below](#notes-for-site-admins) to see how this could affect your instance.++**TL;DR 2**: If you are here for a daily dose of schadenfreude, read about how [we mucked this migration on our production instance](https://eric-fritz.com/articles/migrating-to-postgres/) on Sourcegraph.com.++## The impetus for a second database++A bit over a year ago, the code intelligence backend started as a single node process with access only to its own persistent volume. We chose SQLite as our persistence mechanism for a handful of reasons:++- It was the faster implementation compared to other contending designs we tried.+- Our MVP did not have access to Postgres at the time, which was owned solely by another team. Only later did we get access to Postgres to store cross-repository metadata and work queue data.+- SQLite had some nice properties such as easy data warehousing opportunities (on which we have not capitalized) and bulk deletion of expired data was straightforward. All we had to do was delete the SQLite file.++Using SQLite for this data has become an operational and feature burden for the code intelligence team.++1. We need to maintain a periodic process to reconcile the data on disk with the metadata we store in Postgres.+2. We have good instructions and tips for backup and recovery of our Postgres data store, but have never officially recommended backing up other persistent volumes.+3. We locked ourselves into a node topology which is not easily scalable. We essentially have a singleton service over a persistent volume. In order to scale this service horizontally (which would become necessary once either the amount of data or the frequency of queries increased), we would need to shard the data across multiple volumes. This throws a lot of wrenches into our plans: we need to be able to automatically move data on increase or decrease of shard counts; we need to be able to route requests to the correct node with that data; we need to ensure that reconciliation between the data on disk and the metadata we store in Postgres is aware that there are multiple nodes where data _could_ reside.+4. There is no efficient way to implement certain data access patterns we may need in the future. For example, looking for data matching a certain identifier _name_ would require us to open every SQLite database on disk (and, no, _batching it_ is not a solution).++Instead of forging ahead and tackling the complexity we've made for ourselves, we decided to take a step back and re-evaluate whether or not our previous architecture choices were meeting our current needs. And it seems like they did not.++Moving this data into Postgres seems like an obvious choice that will (eventually) be able to reduce or completely remove all of the burdens listed above.

"Seems like an obvious choice" and "(eventually)" sound wishy-washy and aren't confidence inspiring statements. Are you not confident this was the right decision?

efritz

comment created time in 13 hours

Pull request review commentsourcegraph/about

blogpost: Introducing a new database for code intel

+---+title: 'Introducing a new database for Code Intelligence'+author: 'Eric Fritz'+publishDate: 2020-10-18T00:00-07:00+tags: [+  "blog"+]+slug: introducing-a-new-code-intelligence-database+heroImage: https://image.flaticon.com/icons/png/512/51/51333.png+published: true+---++With the release of 3.21, Sourcegraph will ship with a _second_ Postgres database instance, named `codeintel-db`, which we use to store the data that powers [precise code intelligence](https://docs.sourcegraph.com/code_intelligence/explanations/precise_code_intelligence).++We've [written previously](https://about.sourcegraph.com/blog/evolution-of-the-precise-code-intel-backend/) about the architectural changes we have made to the code intelligence backend. This post is yet another submission in the archaeological trail of how the code intelligence team shapes Sourcegraph on a technical level. The post explains why we chose to swap out our persistence layer - a very non-trivial difference in our architecture.++**TL;DR 1**: If you are a customer currently using precise code intelligence, [skip to the notes below](#notes-for-site-admins) to see how this could affect your instance.++**TL;DR 2**: If you are here for a daily dose of schadenfreude, read about how [we mucked this migration on our production instance](https://eric-fritz.com/articles/migrating-to-postgres/) on Sourcegraph.com.++## The impetus for a second database++A bit over a year ago, the code intelligence backend started as a single node process with access only to its own persistent volume. We chose SQLite as our persistence mechanism for a handful of reasons:++- It was the faster implementation compared to other contending designs we tried.+- Our MVP did not have access to Postgres at the time, which was owned solely by another team. Only later did we get access to Postgres to store cross-repository metadata and work queue data.+- SQLite had some nice properties such as easy data warehousing opportunities (on which we have not capitalized) and bulk deletion of expired data was straightforward. All we had to do was delete the SQLite file.++Using SQLite for this data has become an operational and feature burden for the code intelligence team.++1. We need to maintain a periodic process to reconcile the data on disk with the metadata we store in Postgres.+2. We have good instructions and tips for backup and recovery of our Postgres data store, but have never officially recommended backing up other persistent volumes.+3. We locked ourselves into a node topology which is not easily scalable. We essentially have a singleton service over a persistent volume. In order to scale this service horizontally (which would become necessary once either the amount of data or the frequency of queries increased), we would need to shard the data across multiple volumes. This throws a lot of wrenches into our plans: we need to be able to automatically move data on increase or decrease of shard counts; we need to be able to route requests to the correct node with that data; we need to ensure that reconciliation between the data on disk and the metadata we store in Postgres is aware that there are multiple nodes where data _could_ reside.+4. There is no efficient way to implement certain data access patterns we may need in the future. For example, looking for data matching a certain identifier _name_ would require us to open every SQLite database on disk (and, no, _batching it_ is not a solution).++Instead of forging ahead and tackling the complexity we've made for ourselves, we decided to take a step back and re-evaluate whether or not our previous architecture choices were meeting our current needs. And it seems like they did not.++Moving this data into Postgres seems like an obvious choice that will (eventually) be able to reduce or completely remove all of the burdens listed above.++1. Reconciling pieces of data in the same datastore is trivial compared to reconciling pieces of data in two different datastores, especially if it should be done transactionally. Even though we're not in the same _physical_ database instance, having all of our data in _some_ Postgres-compatible store opens up the possibility of transactions spanning multiple physical Postgres instances via [postgres_fdw](https://www.postgresql.org/docs/12/postgres-fdw.html#id-1.11.7.42.12).+2. Moving data to an existing technology allows us to re-use the same advice and documentation for backup and disaster recovery strategies. Removing the number of knobs that must be turned by site-admins is always going to be a win across the board.+3. Moving from an embedded database to a server-client database removes the nasty singleton property on the service. Now that multiple servers can interact with the same data concurrently without risk of corruption, we can scale the services horizontally without requiring additional effort into implementing sticky sessions or complex request routing rules.+4. Moving data into a single relational store allows us to create additional indexed views into the data. We can now query over dimensions that were not possible before without opening tends of thousands of relatively small database files.++## Notes for site admins

Do we want this blog post to be the source of truth for information like this?

cc @christinaforney

efritz

comment created time in 13 hours

Pull request review commentsourcegraph/about

blogpost: Introducing a new database for code intel

+---+title: 'Introducing a new database for Code Intelligence'+author: 'Eric Fritz'+publishDate: 2020-10-18T00:00-07:00+tags: [+  "blog"+]+slug: introducing-a-new-code-intelligence-database+heroImage: https://image.flaticon.com/icons/png/512/51/51333.png+published: true+---++With the release of 3.21, Sourcegraph will ship with a _second_ Postgres database instance, named `codeintel-db`, which we use to store the data that powers [precise code intelligence](https://docs.sourcegraph.com/code_intelligence/explanations/precise_code_intelligence).++We've [written previously](https://about.sourcegraph.com/blog/evolution-of-the-precise-code-intel-backend/) about the architectural changes we have made to the code intelligence backend. This post is yet another submission in the archaeological trail of how the code intelligence team shapes Sourcegraph on a technical level. The post explains why we chose to swap out our persistence layer - a very non-trivial difference in our architecture.++**TL;DR 1**: If you are a customer currently using precise code intelligence, [skip to the notes below](#notes-for-site-admins) to see how this could affect your instance.++**TL;DR 2**: If you are here for a daily dose of schadenfreude, read about how [we mucked this migration on our production instance](https://eric-fritz.com/articles/migrating-to-postgres/) on Sourcegraph.com.++## The impetus for a second database++A bit over a year ago, the code intelligence backend started as a single node process with access only to its own persistent volume. We chose SQLite as our persistence mechanism for a handful of reasons:++- It was the faster implementation compared to other contending designs we tried.+- Our MVP did not have access to Postgres at the time, which was owned solely by another team. Only later did we get access to Postgres to store cross-repository metadata and work queue data.+- SQLite had some nice properties such as easy data warehousing opportunities (on which we have not capitalized) and bulk deletion of expired data was straightforward. All we had to do was delete the SQLite file.++Using SQLite for this data has become an operational and feature burden for the code intelligence team.++1. We need to maintain a periodic process to reconcile the data on disk with the metadata we store in Postgres.+2. We have good instructions and tips for backup and recovery of our Postgres data store, but have never officially recommended backing up other persistent volumes.+3. We locked ourselves into a node topology which is not easily scalable. We essentially have a singleton service over a persistent volume. In order to scale this service horizontally (which would become necessary once either the amount of data or the frequency of queries increased), we would need to shard the data across multiple volumes. This throws a lot of wrenches into our plans: we need to be able to automatically move data on increase or decrease of shard counts; we need to be able to route requests to the correct node with that data; we need to ensure that reconciliation between the data on disk and the metadata we store in Postgres is aware that there are multiple nodes where data _could_ reside.+4. There is no efficient way to implement certain data access patterns we may need in the future. For example, looking for data matching a certain identifier _name_ would require us to open every SQLite database on disk (and, no, _batching it_ is not a solution).++Instead of forging ahead and tackling the complexity we've made for ourselves, we decided to take a step back and re-evaluate whether or not our previous architecture choices were meeting our current needs. And it seems like they did not.++Moving this data into Postgres seems like an obvious choice that will (eventually) be able to reduce or completely remove all of the burdens listed above.++1. Reconciling pieces of data in the same datastore is trivial compared to reconciling pieces of data in two different datastores, especially if it should be done transactionally. Even though we're not in the same _physical_ database instance, having all of our data in _some_ Postgres-compatible store opens up the possibility of transactions spanning multiple physical Postgres instances via [postgres_fdw](https://www.postgresql.org/docs/12/postgres-fdw.html#id-1.11.7.42.12).+2. Moving data to an existing technology allows us to re-use the same advice and documentation for backup and disaster recovery strategies. Removing the number of knobs that must be turned by site-admins is always going to be a win across the board.+3. Moving from an embedded database to a server-client database removes the nasty singleton property on the service. Now that multiple servers can interact with the same data concurrently without risk of corruption, we can scale the services horizontally without requiring additional effort into implementing sticky sessions or complex request routing rules.+4. Moving data into a single relational store allows us to create additional indexed views into the data. We can now query over dimensions that were not possible before without opening tends of thousands of relatively small database files.

I think this section conflates reasons why we are making this change now, and potential benefits we will experience in the future. I think it is important to keep these things separate.

The conditional future tense used throughout this passage gives it won't be until some future point that we actually benefit from this change. As I reader I am left wondering "why make this change now?".

efritz

comment created time in 13 hours

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentsourcegraph/about

Manager onboarding

+# Engineering onboarding++Welcome! We're excited to have you join the team. This document outlines the structure of your first few weeks at Sourcegraph.++## Getting set up++You'll have to get some basics set up in your first few days:++- Complete [general onboarding](../../people-ops/onboarding/index.md#general-onboarding-checklist)+- [Configure your GitHub notifications.](../github-notifications/index.md)+- Join #dev-announce, #dev-chat, and your team's channel on Slack, as well as any other channels you find interesting. [Team chat documentation](../../communication/team_chat.md#engineering)+- Set up your [local development environment](https://github.com/sourcegraph/sourcegraph/blob/main/doc/dev/getting-started/index.md). If you encounter any issues, ask for help in Slack and then update the documentation to reflect the resolution (so the next engineer that we hire doesn't run into the same problem).+- [Add Sourcegraph as a browser search engine](https://docs.sourcegraph.com/integration/browser_search_engine). Add another entry for our internal instance: `https://sourcegraph.sgdev.org/search?q=%s`. This also ensures you have access to our internal instance.+- Read through your team's handbook page, to learn about the team and its internal processes.+- Complete the onboarding for your role:+  - [Software engineer onboarding](software-engineer-onboarding.md)+  - [Engineering manager onboarding](engineering-manager-onboarding.md)++## Manager checklist++Your manager should complete the following steps when you join:++- Schedule a recurring [1-1](../../leadership/1-1.md).+- Grant access to necessary services.+  - [Sourcegraph organization on GitHub](https://github.com/orgs/sourcegraph/people)+    - Invite to relevant GitHub teams, including [@sourcegraph/everyone](https://github.com/orgs/sourcegraph/teams/everyone).+  - [Sourcegraph organization on Sourcegraph.com](https://sourcegraph.com/organizations/sourcegraph/members)+  - [LSIF organization on GitHub](https://github.com/orgs/lsif/people) (optional; recommended for Code Intelligence team members)+  - [Buildkite](https://buildkite.com/organizations/sourcegraph/users/new)+  - Add the user to the `gcp-engineering` [group](https://console.cloud.google.com/iam-admin/groups?orgonly=true&project=&folder=&organizationId=1006954638239&supportedpurview=organizationId) so they have access to our [Google Cloud Platform](../environments.md).+  - [Opsgenie](https://sourcegraph.app.opsgenie.com/settings/users/)+  - [Docker Hub](https://hub.docker.com/orgs/sourcegraph)+  - [Site24x7](https://www.site24x7.com) (optional; recommended for Distribution team members)+  - [HoneyComb.io](https://www.honeycomb.io/)+  - Ask Christina to send an invite to [Productboard](https://sourcegraph.productboard.com)+  - Ask a member of the Design team to invite as "Viewer" to [Figma](https://figma.com)+  - Ask on `dev-chat` for access to [Percy](https://percy.io/) which we use for visual testing.++## Give feedback on your onboarding++At the end of week 6 at Sourcegraph, your manager will send you a survey to learn more about what worked and what didn't during your onboarding. Take your time to answer this thoughtfully — your answers will be very important to make sure our onboarding process is even better for future hires!

Consider adding the questions here in the handbook, and then tell the new hire to schedule a separate calendar event for 6 weeks in the future (or add to 1-1 notes doc for 6 weeks in the future).

nicksnyder

comment created time in 17 hours

PullRequestReviewEvent

Pull request review commentsourcegraph/about

Manager onboarding

+# Engineering onboarding++Welcome! We're excited to have you join the team. This document outlines the structure of your first few weeks at Sourcegraph.++## Getting set up++You'll have to get some basics set up in your first few days:++- Complete [general onboarding](../../people-ops/onboarding/index.md#general-onboarding-checklist)+- [Configure your GitHub notifications.](../github-notifications/index.md)+- Join #dev-announce, #dev-chat, and your team's channel on Slack, as well as any other channels you find interesting. [Team chat documentation](../../communication/team_chat.md#engineering)+- Set up your [local development environment](https://github.com/sourcegraph/sourcegraph/blob/main/doc/dev/getting-started/index.md). If you encounter any issues, ask for help in Slack and then update the documentation to reflect the resolution (so the next engineer that we hire doesn't run into the same problem).+- [Add Sourcegraph as a browser search engine](https://docs.sourcegraph.com/integration/browser_search_engine). Add another entry for our internal instance: `https://sourcegraph.sgdev.org/search?q=%s`. This also ensures you have access to our internal instance.+- Read through your team's handbook page, to learn about the team and its internal processes.+- Complete the onboarding for your role:

Yeah, there is a loop here, but I think it is valuable to link back to more general onboarding as a first step in case someone lands on the leaf page.

nicksnyder

comment created time in 17 hours

PullRequestReviewEvent

Pull request review commentsourcegraph/about

Manager onboarding

+# Engineering onboarding++Welcome! We're excited to have you join the team. This document outlines the structure of your first few weeks at Sourcegraph.++## Getting set up++You'll have to get some basics set up in your first few days:++- Complete [general onboarding](../../people-ops/onboarding/index.md#general-onboarding-checklist)+- [Configure your GitHub notifications.](../github-notifications/index.md)+- Join #dev-announce, #dev-chat, and your team's channel on Slack, as well as any other channels you find interesting. [Team chat documentation](../../communication/team_chat.md#engineering)+- Set up your [local development environment](https://github.com/sourcegraph/sourcegraph/blob/main/doc/dev/getting-started/index.md). If you encounter any issues, ask for help in Slack and then update the documentation to reflect the resolution (so the next engineer that we hire doesn't run into the same problem).+- [Add Sourcegraph as a browser search engine](https://docs.sourcegraph.com/integration/browser_search_engine). Add another entry for our internal instance: `https://sourcegraph.sgdev.org/search?q=%s`. This also ensures you have access to our internal instance.+- Read through your team's handbook page, to learn about the team and its internal processes.

Yes, this should be in general onboarding for everyone so not going to include it here.

nicksnyder

comment created time in 17 hours

PullRequestReviewEvent

push eventsourcegraph/about

Nick Snyder

commit sha aa63f5471ec0b7d9f0c8ed13dc06618e4ac6e2a1

Update handbook/engineering/onboarding/engineering-manager-onboarding.md

view details

push time in 17 hours

Pull request review commentsourcegraph/about

Manager onboarding

+# Engineering manager onboarding++We expect our engineering managers to drive outcomes, so here are the outcomes we expect of you as you are onboarding at Sourcegraph. You have ownership and autonomy on how to achieve these outcomes. If you aren't confident that you are on the right path, just ask for help from your team and/or manager!++## Week 1++- You have completed the [engineering setup](index.md#getting-set-up).+- You have scheduled recurring 1-1s with your team and ensured that you are invited to (and made the calendar owner of) all of your team's recurring meetings.+- You have made 1 commit or PR to our codebase (for example: adding yourself to our handbook, onboarding or product docs improvement).++## Month 1++- You have confidence in the team's high level goals, and can explain them if they are challenged.+- You are able to describe the individual work that each person on your team is doing, answer questions about that work, and explain why that work is important for the team's stated goals.+- You are able to describe the career aspirations of each teammate, where they are struggling, and where they are thriving.+- Your manager, your peer managers, and your teammates report that they are happy and relieved to have you on the team because you have already had a positive impact.+- You understand who are your stakeholders and have meet with them to understand their priorities.++## Month 2++- You are the credible voice and point of contact for the team. You are directly responsible for the team's success.+- You have a written forecast (e.g., in the handbook) of the work the team is going to do over the next 3 months to make progress toward their goals.+- You are accountable for your teams hiring process.+  - You understand what the team's hiring needs are (for example: skills, values).+  - You have confidence that our hiring process is calibrated to measure what we are looking for in an efficient and unbiased way.
  - You have confidence that our hiring process is calibrated to measure what we are looking for in an efficient and unbiased way (if not, you have proposed improvements).
nicksnyder

comment created time in 17 hours

PullRequestReviewEvent

push eventsourcegraph/about

Nick Snyder

commit sha c24f4e7a1a3d6f01e414ca54fc7a21e5cc3ef015

Update handbook/engineering/onboarding/engineering-manager-onboarding.md

view details

push time in 17 hours

Pull request review commentsourcegraph/about

Manager onboarding

+# Engineering manager onboarding++We expect our engineering managers to drive outcomes, so here are the outcomes we expect of you as you are onboarding at Sourcegraph. You have ownership and autonomy on how to achieve these outcomes. If you aren't confident that you are on the right path, just ask for help from your team and/or manager!++## Week 1++- You have completed the [engineering setup](index.md#getting-set-up).+- You have scheduled recurring 1-1s with your team and ensured that you are invited to (and made the calendar owner of) all of your team's recurring meetings.+- You have made 1 commit or PR to our codebase (for example: adding yourself to our handbook, onboarding or product docs improvement).++## Month 1++- You have confidence in the team's high level goals, and can explain them if they are challenged.+- You are able to describe the individual work that each person on your team is doing, answer questions about that work, and explain why that work is important for the team's stated goals.+- You are able to describe the career aspirations of each teammate, where they are struggling, and where they are thriving.+- Your manager, your peer managers, and your teammates report that they are happy and relieved to have you on the team because you have already had a positive impact.+- You understand who are your stakeholders and have meet with them to understand their priorities.++## Month 2++- You are the credible voice and point of contact for the team. You are directly responsible for the team's success.+- You are able to describe the vision for the team that everyone is bought in to and the handbook communicates a forecast for what the team will accomplish in the next 3 months.
- You have a written forecast (e.g., in the handbook) of the work the team is going to do over the next 3 months to make progress toward their goals.
nicksnyder

comment created time in 17 hours

PullRequestReviewEvent

push eventsourcegraph/about

Nick Snyder

commit sha f904e831470b3d00d71c23e5c55df117c648c34c

Update handbook/engineering/onboarding/engineering-manager-onboarding.md

view details

push time in 17 hours

Pull request review commentsourcegraph/about

Manager onboarding

+# Engineering manager onboarding++We expect our engineering managers to drive outcomes, so here are the outcomes we expect of you as you are onboarding at Sourcegraph. You have ownership and autonomy on how to achieve these outcomes. If you aren't confident that you are on the right path, just ask for help from your team and/or manager!++## Week 1++- You have completed the [engineering setup](index.md#getting-set-up).+- You have scheduled recurring 1-1s with your team and ensured that you are invited to (and made the calendar owner of) all of your team's recurring meetings.+- You have made 1 commit or PR to our codebase (for example: adding yourself to our handbook, onboarding or product docs improvement).++## Month 1++- You are able to describe the team's high level goals, answer questions about them, and defend them if they are challenged.
- You have confidence in the team's high level goals, and can explain them if they are challenged.
nicksnyder

comment created time in 17 hours

PullRequestReviewEvent

push eventsourcegraph/about

Nick Snyder

commit sha 0be2bb8f004550277ab420fc88f39c256b836066

Update handbook/engineering/onboarding/engineering-manager-onboarding.md

view details

push time in 17 hours

Pull request review commentsourcegraph/about

Manager onboarding

+# Engineering manager onboarding++We expect our engineering managers to drive outcomes, so here are the outcomes we expect of you as you are onboarding at Sourcegraph. You have ownership and autonomy on how to achieve these outcomes. If you aren't confident that you are on the right path, just ask for help from your team and/or manager!++## Week 1++- You have completed the [engineering setup](index.md#getting-set-up).+- You have scheduled recurring 1-1s with your team and ensured that you are invited to (and made the calendar owner of) all of your team's recurring meetings.+- You have made 1 commit or PR to our codebase (for example: adding yourself to our handbook, onboarding or product docs improvement).++## Month 1++- You are able to describe the team's high level goals, answer questions about them, and defend them if they are challenged.+- You are able to describe the individual work that each person on your team is doing, answer questions about that work, and explain why that work is important for the team's stated goals.+- You are able to describe the career aspirations of each teammate, where they are struggling, and where they are thriving.+- Your manager, your peer managers, and your teammates report that they are happy and relieved to have you on the team because you have already had a positive impact.+- You understand who are your stakeholders and have meet with them to understand their priorities.++## Month 2++- You are the credible voice and point of contact for the team. You are directly responsible for the team's success.+- You are able to describe the vision for the team that everyone is bought in to and the handbook communicates a forecast for what the team will accomplish in the next 3 months.+- You conduct the hiring manager screen calls for candidates who would be joining your team.+  - You can pitch Sourcegraph as a whole, the part of product your team works on, and the team itself.+  - You understand what our hiring needs are for the team (what skills, values we are looking for).+  - You have confidence in and can defend our hiring process (if not, you have proposed changes to improve it).
- You are accountable for your teams hiring process.
  - You understand what the team's hiring needs are (for example: skills, values).
  - You have confidence that our hiring process is calibrated to measure what we are looking for in an efficient and unbiased way.
  - You conduct the hiring manager screen calls for candidates who would be joining your team.
    - You can pitch Sourcegraph as a whole, the part of product your team works on, and the team itself.
nicksnyder

comment created time in 17 hours

PullRequestReviewEvent

push eventsourcegraph/about

Nick Snyder

commit sha f537bce9415e5ad07183c42264087b15c1e2ac63

Update handbook/engineering/onboarding/engineering-manager-onboarding.md Co-authored-by: Gonzalo Peci <pecigonzalo@users.noreply.github.com>

view details

push time in 17 hours

Pull request review commentsourcegraph/about

Manager onboarding

+# Engineering manager onboarding++We expect our engineering managers to drive outcomes, so here are the outcomes we expect of you as you are onboarding at Sourcegraph. You have ownership and autonomy on how to achieve these outcomes. If you aren't confident that you are on the right path, just ask for help from your team and/or manager!++## Week 1++- You have completed the [engineering setup](index.md#getting-set-up).+- You have scheduled recurring 1-1s with your team and ensured that you are invited to (and made the calendar owner of) all of your team's recurring meetings.+- You have made 1 commit or PR to our codebase (for example: adding yourself to our handbook, onboarding or product docs improvement).++## Month 1++- You are able to describe the team's high level goals, answer questions about them, and defend them if they are challenged.
- You are able to describe the team's high level goals, answer questions about them, and explain them if they are challenged.
nicksnyder

comment created time in 17 hours

PullRequestReviewEvent

push eventsourcegraph/about

Nick Snyder

commit sha 1a5826f14266354f3861cba023d62e9f606c8c98

Update handbook/engineering/leadership/worklog.md

view details

push time in 17 hours

Pull request review commentsourcegraph/about

Manager onboarding

 This is a list of things we have done in reverse-chronological order grouped by  ## 2020-10 +### Engineering manager onboarding++- Problem: We recently hired and onboarded our first group of engineering managers and onboarded each of them in an ad hoc way. We will be hiring at least one more engineering manager in the near future (for the web team) and we want to document what we have learned so they have an even better onboarding experience.+- Owner: Nick+- Outcome: [Documented our onboarding process for managers](https://about.sourcegraph.com/handbook/engineering/onboarding/engineering-manager-onboarding).
- Outcome: Documented our onboarding process for managers
  - https://github.com/sourcegraph/about/pull/1782
  - https://about.sourcegraph.com/handbook/engineering/onboarding/engineering-manager-onboarding
nicksnyder

comment created time in 17 hours

PullRequestReviewEvent

push eventsourcegraph/about

Nick Snyder

commit sha 8ab95a6cf9846b7b6c85ec324d4d7d972962fb45

Update handbook/engineering/onboarding/engineering-manager-onboarding.md Co-authored-by: Gonzalo Peci <pecigonzalo@users.noreply.github.com>

view details

push time in 17 hours

push eventsourcegraph/about

Nick Snyder

commit sha a4328f08d8f27ba12418569967db5dfa3f8e2b04

Update handbook/engineering/onboarding/engineering-manager-onboarding.md Co-authored-by: Gonzalo Peci <pecigonzalo@users.noreply.github.com>

view details

push time in 17 hours

push eventsourcegraph/about

Nick Snyder

commit sha ca09d74e5f41a34e21f6d2094fe8cbbc8fac297c

Update handbook/engineering/onboarding/engineering-manager-onboarding.md Co-authored-by: Tomás Senart <tomas@sourcegraph.com>

view details

push time in 17 hours

Pull request review commentsourcegraph/about

Manager onboarding

+# Engineering onboarding++Welcome! We're excited to have you join the team. This document outlines the structure of your first few weeks at Sourcegraph.++## Getting set up++You'll have to get some basics set up in your first few days:++- Complete [general onboarding](../../people-ops/onboarding/index.md#general-onboarding-checklist)+- [Configure your GitHub notifications.](../github-notifications/index.md)+- Join #dev-announce, #dev-chat, and your team's channel on Slack, as well as any other channels you find interesting. [Team chat documentation](../../communication/team_chat.md#engineering)+- Set up your [local development environment](https://github.com/sourcegraph/sourcegraph/blob/main/doc/dev/getting-started/index.md). If you encounter any issues, ask for help in Slack and then update the documentation to reflect the resolution (so the next engineer that we hire doesn't run into the same problem).+- [Add Sourcegraph as a browser search engine](https://docs.sourcegraph.com/integration/browser_search_engine). Add another entry for our internal instance: `https://sourcegraph.sgdev.org/search?q=%s`. This also ensures you have access to our internal instance.+- Read through your team's handbook page, to learn about the team and its internal processes.+- Complete the onboarding for your role:+  - [Software engineer onboarding](software-engineer-onboarding.md)+  - [Engineering manager onboarding](engineering-manager-onboarding.md)++## Manager checklist++Your manager should complete the following steps when you join:++- Schedule a recurring [1-1](../../leadership/1-1.md).+- Grant access to necessary services.+  - [Sourcegraph organization on GitHub](https://github.com/orgs/sourcegraph/people)+    - Invite to relevant GitHub teams, including [@sourcegraph/everyone](https://github.com/orgs/sourcegraph/teams/everyone).+  - [Sourcegraph organization on Sourcegraph.com](https://sourcegraph.com/organizations/sourcegraph/members)+  - [LSIF organization on GitHub](https://github.com/orgs/lsif/people) (optional; recommended for Code Intelligence team members)+  - [Buildkite](https://buildkite.com/organizations/sourcegraph/users/new)+  - Add the user to the `gcp-engineering` [group](https://console.cloud.google.com/iam-admin/groups?orgonly=true&project=&folder=&organizationId=1006954638239&supportedpurview=organizationId) so they have access to our [Google Cloud Platform](../environments.md).+  - [Opsgenie](https://sourcegraph.app.opsgenie.com/settings/users/)+  - [Docker Hub](https://hub.docker.com/orgs/sourcegraph)+  - [Site24x7](https://www.site24x7.com) (optional; recommended for Distribution team members)+  - [HoneyComb.io](https://www.honeycomb.io/)+  - Ask Christina to send an invite to [Productboard](https://sourcegraph.productboard.com)+  - Ask a member of the Design team to invite as "Viewer" to [Figma](https://figma.com)+  - Ask on `dev-chat` for access to [Percy](https://percy.io/) which we use for visual testing.++## Give feedback on your onboarding++At the end of week 6 at Sourcegraph, your manager will send you a survey to learn more about what worked and what didn't during your onboarding. Take your time to answer this thoughtfully — your answers will be very important to make sure our onboarding process is even better for future hires!

@lguychard Have we gotten to this step for anyone yet?

nicksnyder

comment created time in a day

PullRequestReviewEvent

push eventsourcegraph/about

Nick Snyder

commit sha ffb3a8abf224690f4993c8de6abdcb9eaaf92648

update goal outcome

view details

push time in a day

push eventsourcegraph/about

Nick Snyder

commit sha 14821c1d5e7ab8ae536888ba44a55c1e544a5609

fix links

view details

push time in a day

push eventsourcegraph/about

Nick Snyder

commit sha 62812b8f1d5305a404d423d86eb482bf6c856391

fix links

view details

push time in a day

PR opened sourcegraph/about

Manager onboarding

This adds new general onboarding documentation for engineering managers. I took a slightly different approach and described outcomes. What do you think?

@lguychard does this align with how you have thought about "onboarding" to the search team?

@chrispine @pecigonzalo @chayim would this documentation have been clarifying helpful as part of your onboarding? Do you feel like it is representative of what actually happened?

+74 -45

0 comment

4 changed files

pr created time in a day

push eventsourcegraph/about

Nick Snyder

commit sha 53c40579b35c08db18ba7678d5575ba58e9aef25

possesive

view details

push time in a day

create barnchsourcegraph/about

branch : manageronboarding

created branch time in a day

PullRequestReviewEvent

pull request commentsourcegraph/about

make engineering page index clearer

Thank you for helping to improve this; I agree it is a mess :)

slimsag

comment created time in 5 days

issue commentnicksnyder/go-i18n

no plural rule registered for XX

Currently for a locale to work with go-i18n, it must either:

  • Be supported by both https://pkg.go.dev/golang.org/x/text and have a plural rule defined in CLDR OR
  • Be an artificial language (e.g. art-x- prefix) (in which case it would use default pluralization rules, which might not be what is desired).

The real solution to this problem for a given local is to submit an upstream change to add support for that new locale.

bep

comment created time in 6 days

issue closednicksnyder/go-i18n

Adding a "zero" plural form?

The One/Other feature is neat!

Yet, I often find myself limitated because I need a specific case for the zero value. Would it be relevant to integrate it as a feature in go-i18n? That would be much better than a separate if/else in code.

(Disclosure: I use go-i18n through Hugo's i18n feature.)

closed time in 6 days

cyChop

issue commentnicksnyder/go-i18n

Adding a "zero" plural form?

First, there is a zero category, but it probably isn't what you are looking for because the zero category doesn't necessarily mean the number 0 in all languages. Even in English, there is only One and Other (English treats 0 as "other" and does not have a special pluralization for it).

If you need specific behavior for the number 0, then you need to write application logic.

Here are previous discussions: https://github.com/gohugoio/hugo/issues/5164#issuecomment-418774513 https://github.com/nicksnyder/go-i18n/issues/112#issuecomment-399573558

cyChop

comment created time in 6 days

delete branch sourcegraph/about

delete branch : test

delete time in 6 days

PR closed sourcegraph/about

test pr, ignore
+1 -1

0 comment

1 changed file

nicksnyder

pr closed time in 6 days

Pull request review commentsourcegraph/about

Update frontend engineer job description

 # Software Engineer - Frontend -We are looking for frontend engineers who know how to build intuitive user experiences and APIs to make the power of [Universal Code Search](https://about.sourcegraph.com/product) accessible to everyone. You will have a lot of ownership to solve tough technical and UX problems in key areas of our web application and browser extensions (e.g. code search, code navigation, campaigns).+We are looking for frontend engineers who know how to build intuitive user experiences to make the power of [Universal Code Search](https://about.sourcegraph.com/product) accessible to everyone. You will have a lot of ownership to solve tough technical and UX problems in key areas of our web application and browser extensions (e.g. code search, code navigation, campaigns).++## What you will do++- Work closely with a dedicated designer and PM to implement high-quality UIs.+- Actively participate in the planning of the features we're going to build, e.g. by writing and reviewing RFCs.+- Build UIs you will love to use yourself as a developer.+- Ensure UI/UX consistency in our app.+- Identify potential for abstraction and build components that can be reused, even by other teams.+- Improve the code patterns in our frontend.+- Hold up accessibility standards.  ## Qualifications -- Excellent knowledge of TypeScript.-- Solid understanding of JavaScript's concurrency model and event loop.-- Skilled at building and testing (e.g., unit testing, automated end-to-end testing) React single page applications and HTTP APIs (GraphQL and Go preferred).+- Experience in writing [SPAs](https://en.wikipedia.org/wiki/Single-page_application) using React or similar component-based frontend frameworks.+- Familiarity with TypeScript or a different typed programming language.+- Knowledge of CSS.+- Knowledge of semantic HTML.+- Experience in using backend APIs from the frontend.+- Skilled at building and testing (e.g., unit testing, automated end-to-end testing) UIs. - Ability to communicate clearly and empathetically, especially in writing and documentation.-- Practiced at creating high quality software balanced with a pragmatic understanding of how to make appropriate tradeoffs (e.g. cut scope) to ship quickly and iterate when necessary.+- Practice at creating high quality software balanced with a pragmatic understanding of how to make appropriate tradeoffs (e.g. cut scope) to ship quickly and iterate when necessary.+- [High agency](../../../company/values.md#High_agency).

So "Qualifications" means more like "Qualifications to get an interview"? I interpreted it as "Qualifications to get the job", which may be where the confusion came from.

@withdavidli how do you think about this question?

Regardless of David's answer, I am happy to merge this as-is since we can update it later.

felixfbecker

comment created time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentsourcegraph/about

Update frontend engineer job description

 # Software Engineer - Frontend -We are looking for frontend engineers who know how to build intuitive user experiences and APIs to make the power of [Universal Code Search](https://about.sourcegraph.com/product) accessible to everyone. You will have a lot of ownership to solve tough technical and UX problems in key areas of our web application and browser extensions (e.g. code search, code navigation, campaigns).+We are looking for frontend engineers who know how to build intuitive user experiences to make the power of [Universal Code Search](https://about.sourcegraph.com/product) accessible to everyone. You will have a lot of ownership to solve tough technical and UX problems in key areas of our web application and browser extensions (e.g. code search, code navigation, campaigns).++## What you will do++- Work closely with a dedicated designer and PM to implement high-quality UIs.+- Actively participate in the planning of the features we're going to build, e.g. by writing and reviewing RFCs.+- Build UIs you will love to use yourself as a developer.+- Ensure UI/UX consistency in our app.+- Identify potential for abstraction and build components that can be reused, even by other teams.+- Improve the code patterns in our frontend.+- Hold up accessibility standards.  ## Qualifications -- Excellent knowledge of TypeScript.-- Solid understanding of JavaScript's concurrency model and event loop.-- Skilled at building and testing (e.g., unit testing, automated end-to-end testing) React single page applications and HTTP APIs (GraphQL and Go preferred).+- Experience in writing [SPAs](https://en.wikipedia.org/wiki/Single-page_application) using React or similar component-based frontend frameworks.+- Familiarity with TypeScript or a different typed programming language.+- Knowledge of CSS.+- Knowledge of semantic HTML.

knowledge to establish patterns and abstractions that can be followed/used by others

Say that then!

- Skilled at writing clean and reusable HTML and CSS to implement visual designs.
felixfbecker

comment created time in 6 days

push eventsourcegraph/about

Nick Snyder

commit sha 7e1c3680132b7b211bfea7fdfc751e8ed997b234

Update index.md

view details

push time in 7 days

pull request commentsourcegraph/about

Improvements to values

I also think if we can get the base branch merged, then each of these could be their own PR that we can merge without coupling unrelated suggestions.

christinaforney

comment created time in 7 days

pull request commentsourcegraph/about

Improvements to values

I think we should avoid coupling reordering values with changing them as it makes the diff harder to review.

I think either reordering should happen last, or silently do that as a direct commit to the main branch.

christinaforney

comment created time in 7 days

push eventsourcegraph/codenotify

Nick Snyder

commit sha eea46df0314b4a7d2f2c1c7e8251e4b9223c8bb9

Update README.md

view details

push time in 7 days

Pull request review commentsourcegraph/about

Clarifying vulnerability payment amounts and categories

 If you think that you have found a security or privacy vulnerability, please ema  ### Bounties -We provide monetary rewards, from \$50 to \$10,000 USD, for security vulnerability reports. The actual reward amount is determined based on the number of customers impacted, the difficulty of exploiting the vulnerability, and the severity of the consequences (e.g. service disruption, data leakage, reputational damage to Sourcegraph) of a successful exploit.+We provide monetary rewards, from $50 to $10,000 USD, for security vulnerability reports. The actual reward amount is determined based on the number of customers impacted, the difficulty of exploiting the vulnerability, the severity of the consequences (e.g. service disruption, data leakage, reputational damage to Sourcegraph) of a successful exploit, and the quality of the security report. -We will send payment to a valid PayPal account. We will ask you for the name and country associated with your PayPal account.+When a monetary bounty is presented, eligible reports will be based on the severity, as determined by [CVSS v3.1](https://www.first.org/cvss/calculator/3.1). We will send payment to a valid PayPal account. We will ask you for the name and country associated with your PayPal account.++**Categories**++|Attack Outcome| Maximum Payout|+|:------------- | :----------: |+| You read or write to another user's code | $10,000 |+| You take over another user's account  | $5000 |+| You gain access to the internal Sourcegraph cloud network | $2500 |+| You gain access to another user's configurations | $2000 |

Consistently use comma (or not)

| You take over another user's account  | $5,000 |
| You gain access to the internal Sourcegraph cloud network | $2,500 |
| You gain access to another user's configurations | $2,000 |
chayim

comment created time in 7 days

Pull request review commentsourcegraph/about

Clarifying vulnerability payment amounts and categories

 If you think that you have found a security or privacy vulnerability, please ema  ### Bounties -We provide monetary rewards, from \$50 to \$10,000 USD, for security vulnerability reports. The actual reward amount is determined based on the number of customers impacted, the difficulty of exploiting the vulnerability, and the severity of the consequences (e.g. service disruption, data leakage, reputational damage to Sourcegraph) of a successful exploit.+We provide monetary rewards, from $50 to $10,000 USD, for security vulnerability reports. The actual reward amount is determined based on the number of customers impacted, the difficulty of exploiting the vulnerability, the severity of the consequences (e.g. service disruption, data leakage, reputational damage to Sourcegraph) of a successful exploit, and the quality of the security report. -We will send payment to a valid PayPal account. We will ask you for the name and country associated with your PayPal account.+When a monetary bounty is presented, eligible reports will be based on the severity, as determined by [CVSS v3.1](https://www.first.org/cvss/calculator/3.1). We will send payment to a valid PayPal account. We will ask you for the name and country associated with your PayPal account.++**Categories**++|Attack Outcome| Maximum Payout|
| Attack Outcome | Maximum Payout |
chayim

comment created time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentsourcegraph/sourcegraph

Add label notifier workflow?

+name: "Notify users based on issue labels"++on:+  issues:+      types: [labeled]++jobs:+  notify:+    runs-on: ubuntu-latest+    steps:+        - uses: jenschelkopf/issue-label-notification-action@1.3

For third party actions I think we should pin the precise SHA since tags can be updated under us.

        - uses: jenschelkopf/issue-label-notification-action@f7d2363e5efa18b8aeea671ca8093e183ae8f218 # 1.3
Joelkw

comment created time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

pull request commentsourcegraph/about

Updating company values

I pushed some changes to address comments and reduce the size of the diff. I think this PR got a bit sidetracked on some values that aren't actually changing and I think we should focus the discussion here on the top level summary and additions.

@AlicjaSuska your suggestions are good, but they feel out of scope of this PR given those values already exist and aren't changing here. Can you open a separate PR with those suggestions?

@tsenart I agree the high quality description has room for improvement, but again I think that is best discussed in a separate PR.

@christinaforney You can own taking another pass at this and deciding if/when this is ready to merge.

christinaforney

comment created time in 7 days

push eventsourcegraph/about

Nick Snyder

commit sha 344b225b8f0545351381c996a5e1772f78bfda79

reorder to reduce diff

view details

push time in 7 days

Pull request review commentsourcegraph/about

Updating company values

 We prefer to [build teams, not workgroups](https://dzone.com/articles/workgroups  As a team's size and scope grows, it (unintentionally) tends to become a workgroup. Resist this by aggressively focusing, or by splitting it into smaller teams. -## Open and transparent+### High agency++Everyone at Sourcegraph has the power and the responsibility to improve Sourcegraph as a company and as a product.++> “Life can be much broader once you discover one simple fact: Everything around you that you call life was made up by people that were no smarter than you and you can change it, you can influence it, you can build your own things that other people can use. Once you learn that, you'll never be the same again.” - Steve Jobs++A few examples of how we encourage high agency are by being a [handbook-first](https://about.sourcegraph.com/handbook/usage#why-handbook-first) company, which allows anyone to change how the business operates, and by empowering engineers to spend time on projects they believe in through our policy of [innovation time](https://about.sourcegraph.com/handbook/engineering#innovation-time).++With agency comes responsibility; employees are expected to take initiative and engage in collaboration when exercising their agency.  If you feel that something is important, then advocate for it! If you feel like you're using the wrong tools for the job or doing the wrong thing, then you're responsible for quickly voicing that concern, and engaging with your teammates to find the solution that is the best for the team. This doesn't mean that you should make unilateral decisions. As an [open company](index.md#open-company), we value open discussion on important topics, and think that collaboration should be a large part of making things better. It is not a bad outcome if your proposal is not accepted or replaced with a better solution, because you took the initiative, started the conversation, and either reaffirmed that our current solution is good, or implemented an even better one!++### High quality++Every person on our team is individually responsible for knowing what high-quality work looks like and producing high-quality work. You divide large problems into small low-risk, tractable problems that can be solved iteratively.++- If you don’t know what high quality looks like, it's your responsibility to find out (for example, by asking teammates and stakeholders).

I agree that I think this value could be updated to be clearer, but for the purposes of this PR it hasn't actually changed (just moved), so I think we should defer editing this value to another PR.

christinaforney

comment created time in 7 days

PullRequestReviewEvent

push eventsourcegraph/about

Nick Snyder

commit sha bced71d65d8e769f91e9a30ca86426b06688d707

Consistent "you"

view details

push time in 7 days

push eventsourcegraph/about

Nick Snyder

commit sha ca22aedb105d97e89e4db6ed3dd3b7881465c947

Update company/values.md

view details

push time in 7 days

Pull request review commentsourcegraph/about

Updating company values

 We prefer to [build teams, not workgroups](https://dzone.com/articles/workgroups  As a team's size and scope grows, it (unintentionally) tends to become a workgroup. Resist this by aggressively focusing, or by splitting it into smaller teams. -## Open and transparent+### High agency++Everyone at Sourcegraph has the power and the responsibility to improve Sourcegraph as a company and as a product.++> “Life can be much broader once you discover one simple fact: Everything around you that you call life was made up by people that were no smarter than you and you can change it, you can influence it, you can build your own things that other people can use. Once you learn that, you'll never be the same again.” - Steve Jobs++A few examples of how we encourage high agency are by being a [handbook-first](https://about.sourcegraph.com/handbook/usage#why-handbook-first) company, which allows anyone to change how the business operates, and by empowering engineers to spend time on projects they believe in through our policy of [innovation time](https://about.sourcegraph.com/handbook/engineering#innovation-time).++With agency comes responsibility; teammates are expected to take initiative and engage in collaboration when exercising their agency.  If you feel that something is important, then advocate for it! If you feel like you're using the wrong tools for the job or doing the wrong thing, then you're responsible for quickly voicing that concern, and engaging with your teammates to find the solution that is the best for the team. This doesn't mean that you should make unilateral decisions. As an [open company](index.md#open-company), we value open discussion on important topics, and think that collaboration should be a large part of making things better. It is not a bad outcome if your proposal is not accepted or replaced with a better solution, because you took the initiative, started the conversation, and either reaffirmed that our current solution is good, or implemented an even better one!++### High quality++Every person on our team is individually responsible for finding out what high-quality work looks like and producing that high-quality work.
Every person on our team is individually responsible for finding out what high-quality work looks like and producing that high-quality work. We divide large problems into small low-risk, tractable problems that can be solved iteratively.

accidentally deleted the second sentence with the last update

christinaforney

comment created time in 7 days

PullRequestReviewEvent

push eventsourcegraph/about

Nick Snyder

commit sha dcf62076ef061634dec1e038d7fd5d390f4660e0

Update company/values.md

view details

push time in 7 days

Pull request review commentsourcegraph/about

Updating company values

 We prefer to [build teams, not workgroups](https://dzone.com/articles/workgroups  As a team's size and scope grows, it (unintentionally) tends to become a workgroup. Resist this by aggressively focusing, or by splitting it into smaller teams. -## Open and transparent+### High agency++Everyone at Sourcegraph has the power and the responsibility to improve Sourcegraph as a company and as a product.++> “Life can be much broader once you discover one simple fact: Everything around you that you call life was made up by people that were no smarter than you and you can change it, you can influence it, you can build your own things that other people can use. Once you learn that, you'll never be the same again.” - Steve Jobs++A few examples of how we encourage high agency are by being a [handbook-first](https://about.sourcegraph.com/handbook/usage#why-handbook-first) company, which allows anyone to change how the business operates, and by empowering engineers to spend time on projects they believe in through our policy of [innovation time](https://about.sourcegraph.com/handbook/engineering#innovation-time).++With agency comes responsibility; teammates are expected to take initiative and engage in collaboration when exercising their agency.  If you feel that something is important, then advocate for it! If you feel like you're using the wrong tools for the job or doing the wrong thing, then you're responsible for quickly voicing that concern, and engaging with your teammates to find the solution that is the best for the team. This doesn't mean that you should make unilateral decisions. As an [open company](index.md#open-company), we value open discussion on important topics, and think that collaboration should be a large part of making things better. It is not a bad outcome if your proposal is not accepted or replaced with a better solution, because you took the initiative, started the conversation, and either reaffirmed that our current solution is good, or implemented an even better one!++### High quality++Every person on our team is individually responsible for knowing what high-quality work looks like and producing high-quality work. We divide large problems into small low-risk, tractable problems that can be solved iteratively.

Applying Tomás's suggestion here too since the content is copied.

Every person on our team is individually responsible for finding out what high-quality work looks like and producing that high-quality work.
christinaforney

comment created time in 7 days

PullRequestReviewEvent

Pull request review commentsourcegraph/sourcegraph

codeintel: Rewrite janitor

  **/* @bobheadxi **/* @slimsag++frontend.go @efritz+precise_code_intel_* @efritz+precise_code_intel_* @sourcegraph/code-intelligence

(or rename the team to @sourcegraph/code-intelligence)

precise_code_intel_* @sourcegraph/code-intel
efritz

comment created time in 7 days

PullRequestReviewEvent

pull request commentsourcegraph/sourcegraph

codeintel: Rewrite janitor

@efritz The @sourcegraph/code-intelligence codenotify mention is not working because the team's name is @sourcegraph/code-intel. Can you update the necessary CODENOTIFY files with the correct team name?

Alternatively, you should maybe discuss with the team whether they do in fact want to be notified of every change (maybe they don't?).

efritz

comment created time in 7 days

push eventsourcegraph/about

Nick Snyder

commit sha 568fcbbe5089d3aba2d2dd7c0a3b42b6e94258a1

Update company/values.md Co-authored-by: Chris Pine <chrispine@sourcegraph.com>

view details

push time in 7 days

push eventsourcegraph/about

Nick Snyder

commit sha a0368b67da563d791c93209793eec0dfac9cd71f

Update company/values.md

view details

push time in 7 days

Pull request review commentsourcegraph/about

Updating company values

 We prefer to [build teams, not workgroups](https://dzone.com/articles/workgroups  As a team's size and scope grows, it (unintentionally) tends to become a workgroup. Resist this by aggressively focusing, or by splitting it into smaller teams. -## Open and transparent+### High agency++Everyone at Sourcegraph has the power and the responsibility to improve Sourcegraph as a company and as a product.++> “Life can be much broader once you discover one simple fact: Everything around you that you call life was made up by people that were no smarter than you and you can change it, you can influence it, you can build your own things that other people can use. Once you learn that, you'll never be the same again.” - Steve Jobs++A few examples of how we encourage high agency are by being a [handbook-first](https://about.sourcegraph.com/handbook/usage#why-handbook-first) company, which allows anyone to change how the business operates, and by empowering engineers to spend time on projects they believe in through our policy of [innovation time](https://about.sourcegraph.com/handbook/engineering#innovation-time).++With agency comes responsibility; employees are expected to take initiative and engage in collaboration when exercising their agency.  If you feel that something is important, then advocate for it! If you feel like you're using the wrong tools for the job or doing the wrong thing, then you're responsible for quickly voicing that concern, and engaging with your teammates to find the solution that is the best for the team. This doesn't mean that you should make unilateral decisions. As an [open company](index.md#open-company), we value open discussion on important topics, and think that collaboration should be a large part of making things better. It is not a bad outcome if your proposal is not accepted or replaced with a better solution, because you took the initiative, started the conversation, and either reaffirmed that our current solution is good, or implemented an even better one!
With agency comes responsibility; teammates are expected to take initiative and engage in collaboration when exercising their agency.  If you feel that something is important, then advocate for it! If you feel like you're using the wrong tools for the job or doing the wrong thing, then you're responsible for quickly voicing that concern, and engaging with your teammates to find the solution that is the best for the team. This doesn't mean that you should make unilateral decisions. As an [open company](index.md#open-company), we value open discussion on important topics, and think that collaboration should be a large part of making things better. It is not a bad outcome if your proposal is not accepted or replaced with a better solution, because you took the initiative, started the conversation, and either reaffirmed that our current solution is good, or implemented an even better one!
christinaforney

comment created time in 7 days

PullRequestReviewEvent

Pull request review commentsourcegraph/about

Updating company values

 # Sourcegraph values -These values are some of the beliefs and principles that help us achieve our [goals](goals/index.md) and [vision](strategy.md#vision).+These values are the beliefs and principles that help us achieve our [goals](goals/index.md) and [vision](strategy.md#vision). -This list isn't intended to cover everything we care about; instead, it lists the values that we frequently find useful and refer to. We'll keep this list up to date with the frequently used beliefs and principles (adding, editing, and removing entries as needed). Our hope is that this makes this list more accurate and useful than if it were a list of stale, vague, aspirational, or obvious values.+- [**Be customer driven**](#be-customer-driven): You proactively work on the right things by continuously orienting your goals around delivering value to your customer.+- [**Work as a team**](#work-as-a-team): You work collaboratively with your peers, cross-functional teammates, and leadership to create shared success, trust, and belonging.+- [**High agency**](#high-agency): You have the power and the responsibility to improve Sourcegraph as a company and as a product. You deliver regardless of the circumstances.

This is an attempt to summarize this tweet (in the context of the whole thread): https://twitter.com/shreyas/status/1276956838840295425

This could be easily misinterpreted as "leadership" expects you to deliver even if they don't ensure you have the right context, clear goals, a psychologically safe environment and processes that work for you and not against you, etc.

We are of course trying to provide the best environment for everyone to be successful (clear goals, right context, psychological safety, good processes, etc.). It is important to acknowledge that we will never be perfect, and in some cases we will fail. We expect every teammate, regardless of position, to be active agents in identifying/communicating when problems exist and collaborating to fix those problems (not idling standing by assuming someone else will fix a problem, or worse, pointing fingers).

I agree this sentence is less than ideal but don't currently have a good suggestion.

christinaforney

comment created time in 7 days

PullRequestReviewEvent

push eventsourcegraph/about

Nick Snyder

commit sha a552ee6716e086f1f7a9705c39ba24cb1e19ae2f

Update company/values.md Co-authored-by: Tomás Senart <tomas@sourcegraph.com>

view details

push time in 7 days

push eventsourcegraph/about

Nick Snyder

commit sha 0eed64c45b53a9fead5869febacf8faaf7582736

Apply suggestions from code review Co-authored-by: Tomás Senart <tomas@sourcegraph.com>

view details

push time in 7 days

more