Jamie Turner and the art of making work disappear

Long before he became a chief executive, Jamie Turner was an intern with a mouse habit. A senior engineer named Stan suggested two improvements: trade Perl for Python, and learn the vi text editor. Turner took the advice. Then he discovered how difficult it was to pass the second recommendation along.

Deleting a line in vi involves typing “dd”. To Turner, once he had learned the system, this was convenient. To a colleague encountering it for the first time, it looked like a clerical error. Their conversations about better tools kept running into the same obstacle: something could become useful with practice and still look thoroughly unreasonable on arrival.

That small disagreement has followed him into a much larger business. Turner is co-founder and CEO of Convex, which puts databases, server functions and live updates into a shared programming model. His career has taken him through Bump and Dropbox, but the recurring question remains disarmingly familiar. How do you persuade someone to cross the awkward distance between the tools they know and a different way of working?

The trouble with “dd”

Turner places the episode with Stan in the late 1990s, at the beginning of his software career. Years later, Rich Hickey’s 2011 talk, Simple Made Easy, helped him name the distinction he had been struggling to explain. Familiarity and simplicity were different properties. Something familiar could be complicated; something unfamiliar could have a small, coherent set of rules.

Vi supplied his example. Learn an operation and a movement, and the two could be combined. The initial commands looked peculiar, but the combinations gave the editor its usefulness. He became interested in tools whose pieces behaved predictably when put together, rather than tools that merely felt comfortable on the first afternoon.

His personal website gives the softer version of that interest: “Likes making computers easier and more fun for humans.” It also describes him as the lead bassist of a band the reader does not know. The combination is useful. There is a serious systems programmer here, alongside someone willing to puncture his own introduction before it becomes a conference biography.

Dropbox user number 864

Before Convex, Turner led engineering at Bump, the mobile application acquired by Google in 2013. That year he joined Dropbox. He had been an early customer, number 864 by his own account, and admired the way the product made moving files between computers feel effortless.

Inside the company, he worked on the machinery behind that feeling. His projects included Magic Pocket, Dropbox’s storage system, with work on a custom file system. Later, he and James Cowling worked on rewriting the sync engine. He moved between the remote place where bytes sat on disk and the software living on a person’s desktop.

Turner eventually became a principal engineer and then a senior engineering director, leading the Business Platform and Storage / Databases groups. Those titles describe growing responsibility. The movement through the stack explains something more specific about his interests: he wanted to understand how an apparently simple action survived all the complicated events underneath it.

A file appearing on another computer looks uneventful when it works. That is the achievement. The user should not have to consider every machine, interrupted connection or intermediate state. Dropbox gave Turner and his eventual co-founders, Cowling and Sujay Jayakar, years of practice keeping that sort of promise.

The experts open the cloud console

After leaving Dropbox, the founders wanted to prototype applications. They opened cloud management consoles and found queues, databases, network settings and permissions waiting for them. They understood this equipment perfectly well. They were frustrated by how much of it stood between an idea and a working product.

Turner’s November 2021 introduction to Convex described cloud providers as having exported the divisions of a large company. A storage department became a storage service; a networking department became another set of controls. Smaller teams inherited the job of making the pieces cooperate.

The founders stopped coding long enough to speak to other startups and heard similar complaints. Convex emerged from that investigation. Its opening promise was practical: let developers concentrate on the application, while the platform handled more of the work required to keep shared data dependable.

The convenience rests on choices that constrain the system. Query and mutation functions operate within transactions. Changes to data can trigger updated query results for connected applications. Code and types connect parts of the application that a developer might otherwise have to coordinate separately. Turner’s enthusiasm is for the accumulated work this removes.

A database engineer declines the bar chart

Turner writes about those choices with the impatience of someone who has sat through the argument before. In an essay rejecting competitive database benchmarks, he walks through the ways two impressive-looking numbers can measure different promises. Does a write reach durable storage? What happens after a machine fails? What consistency does the system preserve?

A bar can grow very tall when a benchmark quietly asks less of the software. Turner allows that competitors have capable engineers too. Differences deserve examination before anyone orders the victory stationery.

He also makes a revealing admission about Convex’s early public version: he estimates that it handled only tens of requests per second, and says the team did not measure because the immediate question was whether anyone found it useful. Scaling would follow actual customers and their workloads.

“Do we keep our promises as they grow?”

Jamie Turner, on measuring Convex’s success

That is a demanding standard for a company selling infrastructure. A developer can enjoy a demonstration and still worry about cost, reliability and tomorrow’s traffic. Turner argues for explaining those obligations through recognizable applications and their operating costs. His writing keeps pulling the conversation back from a contest between vendors to the person deciding where to put an application.

The CEO who still builds his own blog

Turner’s GitHub account contains a compact catalogue of his interests: an embedded key-value storage engine, a Haskell server library, enhancements to Russ Cox’s libtask, and a file-management component for Convex. The subjects remain close to storage, networking and the mechanics of programs working together.

He also knows that an explanation benefits from a little theatre. To demonstrate Convex’s Rust client, he recreated the Santa Claus concurrency problem, drawing on Simon Peyton-Jones’s Haskell example. Nine reindeer, ten elves and Santa need to coordinate work and holidays. A distributed systems lesson acquires a sleigh.

At the end of 2024, he documented building his personal blog with Convex, TanStack tools and AI assistance. He began with the interface in v0, then used Cursor to help connect it to database records and an editing workflow. The account includes prompts, schema changes and the decisions he made along the way.

It is a useful view of a founder using the product outside a polished demonstration. He wants a preview that looks right, reusable components, private drafts and an editor that shows the final rendering. The chief executive still has ordinary software requirements. He also recognizes the ancient hazard of building a blog engine: eventually one is expected to write another post.

Giving people room, giving software rules

Turner’s approach to management leaves room for other people’s judgment. He credits Dropbox leader Akhil Gupta with helping shape his thinking about agency. His preferred role is to work alongside people, hear their ideas and let them own decisions. That approach puts considerable weight on choosing colleagues who can operate independently.

On camera, he and Cowling are prepared to make the product itself the uncomfortable subject. Their Databased series includes Why Convex Sucks - For Now. In March 2026, they returned with Convex Still Sucks, a discussion of remaining gaps, improvements and plans. The titles leave very little room for the usual ceremonial applause.

The personal warmth and the technical restrictions can coexist. A colleague needs scope to exercise judgment. A database needs dependable rules about what happens when two people change information at once. Across both, Turner seems interested in making the agreement clear enough that everyone can proceed with confidence.

Then the programmer acquired an agent

AI brought the unfamiliar-tool problem back in a different form. In his personal essay about simplicity, Turner observes that human developers reasonably weigh the time required to learn something new. A coding agent has no corresponding attachment to a familiar editor, database or professional identity.

His technical explanation of Convex’s appeal to agents focuses on feedback and boundaries. Typed code can expose mistakes. Reactive queries reduce the state changes a programmer must coordinate by hand. Fewer separate systems leave fewer assumptions to keep consistent. These are his design arguments, rather than a guarantee that generated applications are correct.

The business has grown around that proposition. In April 2026, Turner announced enterprise plans and said nearly 10,000 teams were paying for Convex. On August 4, he announced a $57 million Series B led by Insight Partners, alongside existing and other investors. The money arrived with a renewed concern about the reliability of software that people increasingly delegate to agents.

His interest extends beyond the database. In May, he announced Abstract, a conference about principled design, scheduled for September 2 at San Francisco’s SFJAZZ Center. The invitation welcomed people making physical products, games and educational experiences as well as software. He said the event would take no paid sponsorships.

The common interest is the reasoning behind a design: which responsibilities belong together, which boundaries should hold, and what a person should be able to take for granted. It is the old vi conversation with a much larger cast.

Stan’s advice asked a young programmer to tolerate a little strangeness in exchange for a tool he could use fluently. Turner now asks developers to consider a different arrangement of the backend, and asks what changes when an agent does much of the learning. The ambition remains recognizably human. Get the machinery working well enough that someone can get on with the thing they wanted to make.