Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability? In the world of tech tools, there’s a lot of buzz. But it doesn’t always reflect the daily reality of programmers.
As the founder of a developer tools startup, I’ve talked with hundreds, if not thousands, of software developers over the last few years in the course of routine user research. The common theme in these conversations, even bigger than the need for the product we were building, was an overarching need that is currently underserved: building for real developers, or what I like to call the 99% Developers.
These are developers who are getting work done outside of the hip companies and frameworks, who often get neglected in conversations about “what developers want.” There’s a huge gap between what “developer-influencers” are talking about, and the daily reality of most developers. When you look at what gets covered by the tech media, or the speakers at top tech conferences, it’s often people from high-growth darlings like Airbnb or Stripe, or established, highly profitable companies like the FAANGs.
In fact, there’s a longstanding assumption that companies, outside of a small number of Silicon Valley unicorns, should aspire to have the processes of a “baby FAANG.” But this is increasingly not true. Our users would tell us, often sheepishly, that their practices look nothing like what they are “supposed to.” But for these “dark matter developers,” as Microsoft’s Scott Hanselman calls them, the practices of a Facebook or a Pinterest don’t make sense. Their user needs are different and their team needs are different.
It matters to talk about the 99% Developers because these are the developers building the software that powers our lives — insurance, health care, retail, and banking, just to name a few. It’s not only small companies that can’t easily adopt the processes of modern, tech-first companies; it’s most companies that were not built around technology and that have decades of legacy software practices firmly in place. Many of these companies move around quite a bit of money. Many of these companies handle quite a bit of our personal data. If technology innovations are not benefiting these software teams, we’re losing out on a lot of meaningful improvements to everyone’s quality of life.
In this piece, I’ll present some truths that both enterprise software buyers and builders can embrace to dispel harmful myths and improve developer experience for all.
“Trickle-down” tooling is aspirational
The myth
Because a disproportionate amount of writing and tooling comes from companies like Facebook, Netflix, LinkedIn, Google, and Amazon, many people assume there’s a trickle-down effect: Great engineers at companies with money to burn come up with good solutions to problems everyone else will have someday. It’s simply a matter of time until your typical small-to-medium business or Fortune 500 company experiences the same issues as Amazon or Facebook.
The reality
A FAANG-like company is different from an SMB or your typical Fortune 500 company along many dimensions, including scale needs, stance on building vs. buying, and makeup of the engineering team. A small number of large, well-capitalized companies have entire teams with world experts dedicated to observability, testing, developer productivity, and more. On top of this, it’s worth noting that FAANGs are optimizing around a small set of products that are digital from the start, something that’s not true of most software shops out there.
Many non-FAANG teams have a small non-expert team, or even a fraction of a non-expert engineer, to do things that FAANG-like companies have multiple teams of experts to do. These organizations rely primarily on external tools and services that they have little bandwidth for customizing.
What to do about it
First, the tech industry needs to acknowledge that organizations operating at different scales and with different engineering budgets are going to have different needs. A company that serves in the low millions of user requests per day doesn’t need to optimize its systems to the degree of a Netflix or a Google. Most companies do not have the latency, data storage, and other concerns that would lead them to write their own bespoke infrastructure components and tools like, for example, Facebook did with its Tao data store and Hive data warehousing tool — and they likely don’t have concerns that would warrant them even using such tools.
Acknowledging different demands will make space to talk about diverse needs across a wide range of organizations. For instance, companies with legacy systems that can’t afford to migrate to the newest architectures need to adopt new tools differently than newer companies, or companies that can dedicate a team to a large migration.
Recognizing that there isn’t a single aspirational company profile can help builders reach outside of the usual suspects when understanding users. This is crucial for bridging the gap between software needs and software tools in an achievable way.
Spot on by @jeanqasaur. Eg big tech invests big time in internal platform teams that are rarely present elsewhere.
Example: at Uber the mobile platform team identified slow-running tests *that my team wrote/owned* & pinged us on how we should fix it.
Let that reality sink in… https://t.co/gEZFVzvflW
— Gergely Orosz (@GergelyOrosz) November 3, 2021
There is no gold standard development environment
The myth
If you watch enough conference talks or read enough blog posts, it would appear there are many software teams out there with pristine coding sta
