Beyang Liu

It's time to build developer tools · 2020.12.29

We are living through a golden age in developer tools.

Software is eating the world.

Every company is now a software company.

Every software company needs developers—and developer tools.

The ecosystem of companies building tools for developers is booming. If you are a developer who loves the art and craft of programming, if you like working on technical problems beyond scaling CRUD, or if you love the idea of accelerating technological progress by building tools for people like yourself, you should think about working on dev tools!

Historic forces, immense opportunity

Every company that now writes code has discovered (or is discovering) that software development is really tricky. The world needs more software, but it’s not as simple as hiring more developers. Building software doesn’t scale or parallelize easily. Serial dependencies coupled with unforeseen complexity lead to gross underestimates of timeline and budget, which in turn lead to bad business outcomes and even existential crises.

To address the challenges of developing software quickly and efficiently at scale, more and more companies are building and buying developer tools. It’s no longer just the Googles, Facebooks, Microsofts, and Amazons of the world spending serious money doing so.

To satisfy this increasingly apparent need, a rapidly growing new industry of developer tool companies has arisen in recent years. Individual names like GitHub, GitLab, and HashiCorp are now well known and the emergence of the field has not gone unnoticed.

It’s difficult to overstate how quickly the market for developer tools has grown in the past decade. When Quinn and I started Sourcegraph back in 2013, we quickly discovered that “dev tool” was a dirty word among investors. Developer tools, it was thought, were super valuable, but most of them were single player tools that didn’t make enough money (e.g., JetBrains, Sublime Text), internal tools built for the specific needs of a particular big tech company (e.g., Google Code Search), or open-source projects that no one paid for and which you could only make money from by selling services and support. Investors told us there was just one billion-dollar company that sold to developers—Red Hat—and it was the exception that proved the rule.

Developers were building lots of valuable software that was sold to other folks—salespeople, marketers, designers, etc.—but when it came to their own work, the common refrain was, “the cobbler’s children have no shoes”. An article in TechCrunch lamented, “Will Developer Tools Startups Ever Find Investors?"

But then, somewhere along the line of the past seven years, something changed. Evidence of this shift is in the valuations: GitHub acquired by Microsoft for $7.5 billion, GitLab valued at $6 billion, HashiCorp at $5 billion, JetBrains estimated at $7 billion, the list goes on.

But though the big numbers with lots of zeroes raise eyebrows and make the headlines, they are just the byproduct of the underlying factors driving big changes in where and how software is built. To list a few of these:

There are many other trends at play here, but one thing is certain: almost every valuable or growing company is now building software and most have realized they need great developer tools to compete.

This is fantastic news. “Tech” has traditionally been a distinct sector of the economy, and the ability to build software effectively at scale was confined to a handful of big technology companies. Now, companies in every sector understand that code has to become a core part of their DNA. And this means the impact of code and software is amplified. No longer does the value proposition of software have to flow through some product or service offered by a “tech company”—companies across every sector of the economy are now learning how to build great software themselves.

As the broader economy learns to build software, progress will accelerate. All the promises that the future holds—cures for cancer, life-saving medicine, mass individualized transportation, rocketships, and more—will arrive sooner in large part thanks to code. Software has long been recognized as a technological accelerant. But developer tools are now a second-order accelerant on technological progress. This is an immense opportunity.

How best to pursue it?

Large companies, open source, and startups

There are three places where you can work on developer tools. (There may be more, but for brevity’s sake, we’ll focus on these.)

The first is inside a large non-developer-tool company. Many large companies that build software are investing heavily in internal tools. There have been a lot of great dev tools created inside large companies, and many such tools have inspired the creation of similar tools outside the company. Blaze, the build system of Google, inspired other build systems like Pants and Facebook’s Buck and was later itself open-sourced as Bazel. Large companies also offer the benefit of a large, stable salary. The downside is that the direct impact of your work will likely be limited to a single organization. It’s possible that your work will be open-sourced down the road, but there is no guarantee, and it can often take years to get the necessary legal and bureaucratic approvals to do so. And, of course, you don’t have a direct piece of the financial upside if the tool becomes super widely used.

The second place you can build dev tools is on an open-source project. Working in the open guarantees you will receive recognition for your work, and you also have the benefit of not having any pesky pricing considerations standing in between your users and your product. If mass adoption is your primary goal, then open source holds great appeal. Many of the most widely used developer tools—Git, Linux, Emacs, Vim, etc.—are open source projects. The downside, of course, is lack of revenue. Most open-source authors and maintainers have an alternate source of income (often working at a large tech company). Patreon and GitHub Sponsors are great, but it’s likely that only a small fraction of open-source creators will ever earn enough to make a comfortable living through sponsorship alone. The number of hours you can devote to working on open source will be constrained by where you can find sources of income.

The third place is at a developer tools company. Most such companies will be startups, because of the rapid growth in market size for dev tools over the past few years. Dev tools companies offer the benefit of aligned incentives: your users, your customers, and even your fellow engineering teammates are often the same people. If you build a great tool, then your users are happy, you get paid so you are also happy, and you and your teammates can also make use of the same tool, so that should make you doubly happy! Dev tool startups have the additional benefit of financial upside (assuming part of your compensation is an equity stake in the business). This upside could be substantial. Personally, I think we are in the early days of the developer tools market. I believe the impact of high-quality, broadly useful dev tools will someday far exceed the impact of ads-driven web search, PC operating systems, and social media. Which is to say, I think that the value of developer tool companies will someday exceed the combined value of the most valuable tech companies today.

Of course, startups also carry a downside risk. There is a high chance that the company will fail to meet its lofty goals, or may need to lay people off, or fail completely. There is no one-size-fits-all prescription for the best place to work. Personally, the principle I follow is, “Maximize expected utility subject to minimizing the risk of ruin,” where the definition of “utility” and “ruin” is up to you to define.

Regardless of whether you opt for large companies, open source, or dev tool startups, there is still the question of how to evaluate which specific opportunities and tools are worthy of your time. For that, you’ll need to rely on a combination of intuition and worldview, which we’ll discuss next.

Scratch your own itch, but understand the big picture

Jamie Zawinski once said, “The best motivator in the world is scratching your own itch.” He was talking about developer tools, and he was right. Most developer tools start with a programmer noticing they have a problem, imagining a way to fix the problem through software automation, and then writing the code that implements that automation. Building for yourself means you get to wear the hat of product manager, engineer, and customer simultaneously. This is a fantastic recipe for building something truly useful, not just for yourself, but for other people who feel the same pain. As you evaluate the landscape of enterprise developer tools, you should rely heavily on your own intuition for where pain points exist and which products offer effective solutions.

However, you’ll also want to combine your direct intuition with a broader view of how software development works—what is common across companies and sectors and what is different and specific to the segment of the market you are building for. It’s important to understand where your itch fits into the overall picture, how others experience that itch, and how their itch fits into their picture.

The way software is developed varies widely from organization to organization and even individual to individual, but there is a general “software development lifecycle” template that is fairly universal:

  1. Plan and describe what the software should do (e.g., implement a feature or fix a bug)
  2. Read and understand the code being modified
  3. Write, run, and debug the new code
  4. Test the code
  5. Review the code
  6. Deploy the code
  7. Monitor the code in production and react to incidents

There are many variations on this lifecycle:

This general process and its specific instantiation by your customers is important to understand. It’s also important to understand whose lifecycle you’re accelerating—is it the individual’s, the team’s, the organization’s, or maybe some combination of the above? There’s nothing inherently wrong with selling just to individual developers, but many of the most successful developer startups sell to teams and organizations. Selling to a team means making a case to the representative of the team’s interest—perhaps someone with the title of “engineering manager”, “director”, or “head of developer productivity”. This individual may not code day-to-day.

When evaluating which dev tools and dev tool companies are worthy of your time, you should ask whether they sell to teams or individual developers, how they articulate their value proposition to different customer stakeholders, and how the tool you will help build fits into the customer’s software development lifecycle.

A brief sampling of dev tools startups

Let’s apply the software development lifecycle framework to a few dev tool startups. The following are some companies that I’ve had the good fortune of getting to know over the years and which I’ve spoken to directly on The Sourcegraph Podcast. (Incidentally, these companies are also where I’d start my job search if I were looking to join a dev tools startup—I think all of them are doing fantastic work.)

A lot of buzzwords in software engineering can also be thought of in terms of what they mean for the software development lifecycle. Understanding them in this way helps me think past the hype and clarify what they actually mean:

I’ll caveat all of this by saying this analysis is my own point of view. The companies discussed above might have a different articulation of their value proposition and how they impact the software development lifecycle. So might you if you do the homework of learning more about them, trying out their products, and fitting them into your own developer worldview.

And who knows? Perhaps investigating enough such companies and reflecting on personal experience will reveal to you gaps and opportunities that a new tool or company could fill. You may conclude that your best course of action is not to join any existing dev tools startup, but to create your own—but that is a subject for another post.

Parting thoughts

The past few years have witnessed an inflection point in the market for developer tools. Software development now permeates every sector of the economy and even “non-tech” companies today employ millions of programmers working on ever larger codebases that depend on an ever growing open-source universe. The opportunities awaiting builders of dev tools are immense.

So, scratch that itch. Advance the state of our craft. Become a second-order accelerator of technological progress. The cadence and drumbeat of the global economy moving forward will be “developers, developers, developers”. For makers of developer tools, that means it’s time to build.

Get in touch

If you found this post interesting or thought-provoking and would like to chat, please shoot me an email or reach out on social media. I enjoy learning from and helping others, especially those who are working on or would like to work on great dev tools.