Dev Experience team

Sourcegraph dev experience temporary team logo

The Dev Experience team, or DevX for short, is a team focused on improving the developer experience of Sourcegraph.

Need DevX help or support? Jump to the Contact section.

Members

Strategy

Find out more about the Dev Experience team’s mission, vision, and strategic plans in our Strategy page.

Responsibilities

Also see org-wide areas of ownership and our team processes.

Contact

For questions and discussions about anything related to developer experience, post a message in the #dev-experience channel.

For urgent requests or if you’re blocked on something important, add the @dev-experience-support tag in your message.

  • The @dev-experience-support tag will ping an on-call member of the DevX team.
  • Requests tagged with @dev-experience-support will get priority support.
  • Please use the @dev-experience-support tag only for issues that require immediate attention.

You can also interact with us on GitHub:

Principles

We inherit Sourcegraph’s engineering principles and practices. In addition, the following principles guide the work we do in dev experience. Sometimes adhering to one causes us to compromise another, but they guide our decisions on what matters.

  • We don’t own the developer experience at Sourcegraph – we simply focus on it. Sourcegraph engineers own the developer experience as a collective.
  • We ship open products. Our products are open to contributions to anyone in the company, documented, and provide migration paths if necessary. Our decisions are clearly and publicly communicated for everyone to understand our reasoning. We want to make it simple for everyone to benefit from and work on Sourcegraph’s developer experience.
  • We bandage first, then plan for surgery. Fix local problems first, then generalize if and only if it makes sense.
    • What we cannot take upon right now, we make its status clear and provide stewardship.
      • We should never refuse to fix a “now” problem in favour of a long-term solution, only to cancel the fix because the priorities changed in between. More than not addressing the issue at hand, it prevents our users from fixing the problem for themselves in the meantime.
    • We deliver small and iterative experiments and collect feedback. We communicate regularly on their status to enable others to provide inputs. We should reap the benefits of what we work on as we go, not at the end.
  • We listen and observe. Our users often know best what’s immediately good for them because they are the ones experiencing it every day. We are not a dependency. We actively seek to avoid blocking product teams. We focus on improving and expediting progress, not being critical to it.

Processes

Read more about how this team works.

Useful resources

Sourcegraph instances operated by us

We also maintain various instances of Sourcegraph which include:

Tech stack

  • We primarily build tools and libraries in Go, with a dash of bash scripting in between.
  • We also operate CI infrastructure with Kubernetes and Terraform.