Sergey Dmitriev and the cost of telling a computer what you mean

A programmer who does not like to program sounds like a questionable hire. Sergey Dmitriev used roughly that description of himself in an early public biography. The joke becomes more intelligible when you look at what he helped build. IntelliJ IDEA would do some of the work a programmer otherwise had to do by hand. The complaint had a product attached. ↗

Software has a peculiar way of making clever people perform clerical duties. An idea can be clear while its expression is laborious. Change a name, find the places that use it, make sure the change means what you think it means. A computer can execute a program with impressive obedience and still require an exhausting amount of instruction. Dmitriev’s career repeatedly returns to the effort hidden in that gap.

He co-founded JetBrains in Prague in 2000 with Eugene Belyaev and Valentin Kipyatkov. They had worked together at TogetherSoft and were dissatisfied with the development tools available to them. Their early products included Renamer, for simple Java refactoring, and CodeSearch, a JBuilder plugin for finding uses of a class or method. IntelliJ IDEA followed. These were specific answers to specific annoyances. ↗

A complaint with a business attached

Dmitriev had been building software before there was a JetBrains name to put on it. In 1993, he co-founded Horis Ltd., a geographic information systems company, serving as chief technology officer and project leader. His experience also included image-recognition algorithms for computer-aided design systems. At TogetherSoft he worked as a project manager and core developer. The founding of JetBrains brought an existing engineering career into a new company. ↗

That background matters because the early products were tools for colleagues in the same profession. A developer understands the difference between an editor that accepts text and an environment that helps make sense of code. The latter has to recognize relationships. A name may appear in several places, but those appearances do not necessarily refer to the same thing. Reliable assistance depends on understanding more than the spelling.

The modesty of Renamer’s job is part of the appeal of this origin. A company can begin with a problem small enough to describe without a presentation. Renaming code will never be an especially glamorous dinner-party subject. It becomes interesting when the alternative is spending an afternoon doing it cautiously. The founders were selling time back to people who had better things to do with it.

A photograph preserved on Dmitriev’s personal website puts him in the Prague office in March 2003. He sits in a chair, wearing glasses and a dark jacket. There is no stage, no launch backdrop, no ceremonial prop. The site gives the date and the camera model. It is a small piece of office history whose precision is rather more engaging than a corporate portrait’s solemn attempt at importance. ↗

The language was part of the problem

Making a better editor opened a larger question. What if a programmer’s difficulty came from the language in which the idea had to be expressed? Dmitriev explored that question in his 2004 essay, Language Oriented Programming: The Next Programming Paradigm. He described programming as a movement from a conceptual solution to an expression a general-purpose language could accommodate. The translation could become the bottleneck. ↗

His proposed approach let developers create, reuse and modify languages and their environments. The desired freedom had to be practical: building an entire compiler or editor from scratch was hardly a convenient answer for most programmers. A platform that made language development easier could make the choice available in ordinary work. MPS, the Meta Programming System, was his attempt to build such a platform. ↗

In the MPS approach, the approach includes building domain-specific languages or adding domain-specific concepts to existing ones. The supporting environment can provide completion, checking and navigation for those languages. A domain expert can work with terminology designed for the task. It is easy to appreciate the attraction: the words used to discuss a problem might survive the journey into the software that addresses it. ↗

There is a pleasing escalation here. First, remove the nuisance from working in Java. Then examine the assumption that the developer must always work inside a language chosen in advance. The second task is much less tidy. It asks the toolmaker to make tools for other toolmakers, who may have entirely different problems in mind. A useful editor is already difficult; a system for constructing editors invites additional complications.

An experiment earns its desk

MPS began as research in 2003. By November 2004, Martin Fowler and his colleague Matt Foemmel had spent time with Dmitriev and seen it. Fowler wrote about the encounter, placing MPS in a developing conversation about closely integrated domain-specific languages. He also pointed to other work in the area, including Intentional Programming. Dmitriev’s experiment had company, and people outside JetBrains were paying attention. ↗

That context keeps the story in proportion. Dmitriev did not invent the desire for a language suited to a particular job. His contribution was a concrete proposal and a system intended to make it usable. The value of an engineering idea often lies in the machinery around it: editors, constraints, generators and the decisions that allow another person to get something done.

When the beta arrived in December 2008, Dmitriev remembered an early research project with limited capabilities that was “a lot of fun to play with.” The phrase is a welcome change of scale. Five years of development can look inevitable in retrospect. At the beginning, there was something small enough to play with, and enough curiosity to keep working on it. ↗

“a lot of fun to play with”

Sergey Dmitriev on early MPS, 2008

The beta announcement also described JetBrains using MPS to develop new products. That gave the experiment a demanding audience inside the company. Colleagues building real software need more than a persuasive demonstration. They need a system that allows tomorrow’s work to happen. Their questions are liable to be less polite than those asked at a conference, which can be a considerable service to a tool. ↗

MPS 1.0 shipped in July 2009. It supported language creation and extension, with specialized editors and code generation. Languages could be combined, making reuse part of the proposition. By October, JetBrains had released YouTrack 1.0, the first mature product developed using MPS. An argument about programming had helped produce a system for handling bugs and requests. ↗

YouTrack is a useful detail because issue tracking is stubbornly ordinary. Teams need to record a problem, find it again, and change its status without turning the process into a second occupation. The original release emphasized keyboard controls, search and commands. Dmitriev explained that existing tools had fallen short for JetBrains’ own work. The company’s dissatisfaction had found another outlet. ↗

The small chores add up

The same period includes a less celebrated thread: managing information. Dmitriev’s early biography lists Omea among the projects he started. Omea Pro 2.0, released in 2005, brought together different kinds of incoming information and desktop files. Its premise was that finding something once did not solve the continuing problem of organizing material around projects, research and contacts. The inbox had its own engineering problem. ↗

TeamCity addressed a different routine. In 2008, Dmitriev described the build system as a daily part of JetBrains’ own development process, used across its projects. Building and checking software happens repeatedly, and repetition is precisely where a small delay becomes expensive. These products put the company close to the unceremonious work between an idea and a release. ↗

The developer community also had room to alter the tools. JetBrains’ 2006 plugin contest drew more than sixty valid entries. Among its winners were a database helper, a language-injection tool and Key Promoter, which showed users how to perform actions from the keyboard. Even the prizes tell a story about the audience. A shortcut can be a sufficiently interesting invention to win money. ↗

In 2009, during Dmitriev’s CEO years, JetBrains introduced the free, open-source IntelliJ IDEA Community Edition and opened the IntelliJ Platform under Apache 2.0. His explanation connected the move to the company’s existing feedback practices and work with open-source projects. Developers could inspect and build on the platform as well as use the application. Another part of the toolmaking process had become accessible. ↗

Two chairs for one job

Dmitriev’s engineering influence also passed through people. Maxim Shafirov later recalled being asked by him to lead IntelliJ IDEA. The invitation surprised Shafirov, who had been working on the editor’s behavior and performance. He accepted after thinking it over. In the same interview, Shafirov described Dmitriev asking what the company could do beyond its familiar IDE and tooling work. Dmitry Jemerov proposed a programming language, an exchange that became part of Kotlin’s origin story. ↗

In 2012, Dmitriev handed the CEO role to Shafirov and Oleg Stepanov together. Shafirov later explained the practical arrangement: he was in St. Petersburg, while Stepanov was in Munich, two large development centers. Each location had someone who could make a decision. For a company built around developers’ working needs, the geography of leadership was another working need. ↗

JetBrains continued through later changes in leadership. Kirill Skrygan became CEO in February 2024 after leading the IntelliJ department. Dmitriev is publicly identified as the company’s president. His place in the story therefore spans an early hands-on engineering period, the CEO years and a company that continued under other leaders. The products did not require him to remain in the same chair. ↗

The thread connecting those years is a question about effort. How much of a programmer’s day belongs to the problem, and how much belongs to accommodating the computer? Dmitriev helped build a business around reducing the latter. Then he tried to give developers more say over the language of the conversation itself. The early joke about disliking programming begins to sound like a rather precise specification.