Gitar: From the Team Behind Uber's Developer Platform

But what is it? An IDE?

Congrats on founding a company here!

The easy answer when bringing up something like IntelliJ is that we very much intend to go beyond the IDE (local edit-build-debug loop) and beyond an specific programming language (or set of related languages in the case of IntelliJ). But it is generally true that we aren't the first or only company to think about multiple parts of the development workflow. You could point to, say, Jetbrains Space as a better example of something from them in the same space (pun not intended).

We want to build an integrated development platform that goes from locally writing code, to code review, to continuous monitoring of code quality, to enabling automated dependency upgrades and migrations, to compiler optimizations guided by usage data and constraints. That doesn't mean that every tool in the platform will be something we build from scratch, though, we are looking to integrate with existing developer tools along a number of supported "golden paths", besides making our tooling available a la carte for others.

For linting, specifically. It's easy to add linting frameworks and checks, for most languages, but there are a few things we need to be considered when a diagnostic is surfaced locally: - Is it a suggestion or an actual error? - Is there an automated fix available? - Is the right set of checks turned on for the right subset of the code?

Then there is also the aspect of visibility and observability. Here is an example of an issue for which a lint was readily available, but ignored: https://imgur.com/a/wWqa0Wg. We believe that's common and not a matter of human error, but a direct consequence of the tooling not surfacing the issue in the right ways or providing an easy path to fix it once the code is already in the codebase.

Or, consider code refactoring. Many IDEs support code refactoring with full AST information, but for large codebases it can hit limits fairly easily: for a large monorepo, it might not scale in the sense of being able to keep all code indexed in memory within the same session; for a set of microrepos, it can struggle to perform refactorings across repo boundaries. One approach here is to build a powerful refactoring engine and expose it via integrations to the IDE (including IntelliJ!), code review system, and some sort of global management UI.

For each of the questions above you can find potential solutions, both from companies and in open-source, and yet, companies that can afford it benefit from having a "dev platform" team integrating, customizing, and maintaining various such tools benefit from that investment. I'd argue there isn't currently a clear go to answer for "Developer Platform as a service", particularly one that doesn't care to tie you to a particular language or stack.

Huh. Do you have a few examples?

I thought jaeger was pretty popular for tracing.

A cliche, perhaps, but build times and land times have always been a top priority of developers, particularly as tooling, specially code analysis, grows more complex. Developer tooling should be as blazingly fast as we can make it! (And obviously we aren't the only ones aiming for that, but it's good to have it as an explicit top priority!)