Delivering Nice and Neat Results
Dmitry Jemerov, Head of Product for the IntelliJ department, answered Roman Poborchiy’s questions about the most famous JetBrains product, the culture of exploring the IDE, his co-authored book about Kotlin, and working for Google.
Dmitry Jemerov, Head of Product for the IntelliJ department
Roman: Hi, Dmitry!
Dmitry: Hi, Roman!
Roman: Thank you for agreeing to do this. How would you describe your current role at JetBrains?
Dmitry: My current role is the Head of Product for the IntelliJ department. This means that technically I am responsible for defining the product strategy: what our big goals are, what major tasks we have for the year, and which features get into which release. In reality, I do a lot more than that. For example, I still write code and participate quite a lot in discussions of specific issues, not on the strategic level, but rather on the level of how to make sense of the buttons in a dialog and on which side of the screen something should be displayed. Whenever it is needed, I try to help and take part in decision-making.
Roman: Which parts of the product do you write code for?
Dmitry: The choice is quite random, actually. Sometimes, if a task entails a lot of small changes, it’s easier for me to make those changes myself rather than create two hundred issues for developers and track their implementation. Last year, I undertook some pretty big projects, but I am trying not to do that anymore because I always find myself short on time to carry them out consistently.
Roman: That’s pretty logical. As the scope of your responsibilities grows, it’s getting harder to take on large individual projects.
Dmitry: At the same time, if no one knows how to approach a project, then me getting involved at least gives the team an understanding of what needs to be done, what the subtasks are, and which approaches will work and which won’t. I can work out this understanding and let other people further support and develop it.
Roman: Let’s get back to strategy for a moment. Is it difficult to develop a unified strategy for projects as large as IntelliJ IDEA?
At JetBrains, people enjoy autonomy. It’s in our culture. A lot of teams, a lot of talented people, and a lot of ideas – how can they all be steered in the same direction?
Dmitry: The product-level strategy for the coming year does not require detailed coordination with all the subteams. These are our big goals, and we put a lot of effort into them, but there are local tasks that the team does anyway beyond these big goals.
If we’re talking about release roadmaps, putting them together means having numerous conversations with the teams involved where team leads or other people tell us what they’re planning to do. Sometimes I have my own thoughts about their plans, and sometimes I don’t. Sometimes I give feedback regarding what the team wants to do, or the priority of certain things. In such conversations, we make a release plan based on my suggestions and those of the team. Autonomy is a real thing at JetBrains, and we take it into account.
Another important thing: I don’t have the formal authority to set tasks or give instructions. If I want something to happen, I need to convince people that it’s a great idea and it needs to be done. They won’t do something just because I said so.
Roman: To be able to persuade people all the time, you need to understand what different teams are doing, and that’s a vast landscape. Does this come naturally, or do you have difficulties finding room for everything in your head?
Dmitry: First of all, it has always been relatively easy for me to process a lot of information. I read a lot of Slack channels, and I can look through the new issues filed in YouTrack and break everything down into understandable pieces of information – I’ve always been quite good at this.
Roam Research, which I recently started using, helps me not forget what I once learned. For me, it’s an invaluable tool for keeping work logs and remembering what I discussed with different people. That’s where I collect links to various Google docs that I come across, and it’s very helpful.
Roman: Let’s recommend it to our readers then!
Dmitry: Roam is not the only option. Many tools use the Zettelkasten methodology – Obsidian, for example. I know people who work with similar tools based on other methodologies, like Notion. But for me, Roam Research works best.
Roman: Do you get tired at work?
Dmitry: I am now quite careful about my work-life balance and try not to work more than 40 hours a week. I know I can work more, but it will backfire: I will come to work, stare at the screen, and fail to figure out what to do and which keys to press.
Covid obviously made it more difficult to stay in shape, even though my circumstances are simpler than other people’s. For example, I don’t have kids to take care of while working from home. Still, it was a significant psychological burden, which led me to take three months off in 2021, and I returned only in November. That really helped me recharge and declutter my mind.
Roman: What did you do to recover?
Dmitry: I had no particular plan and just did a little bit of everything: traveling, reading, cycling, walking.
Roman: We’re glad to have you back.
Returning to strategy – to IntelliJ IDEA and Kotlin. You’re doing product work. This means that, among other things, you consider what features we need and learn about users.
Our users are a lot like ourselves because they are also developers. Was there anything that surprised you about the way they work?
Dmitry: First of all, IntelliJ IDEA is unlike most projects in the industry. It’s a huge monolithic desktop application that doesn’t use any traditional frameworks like Spring. We don’t have a REST API or rich client.
Sometimes we fail to accurately assess how serious an issue is for the users because we do not experience it ourselves.
Our users may have difficulties working on real-life tasks because there’s something we didn’t provide for, were unaware of, or didn’t finish. The Windows Subsystem for Linux support that we have been working on for the past year is one such thing.
What struck me the most was that there is no simple default way to master an IDE. Many people don’t even recognize that it needs to be done.
If you want to learn a programming language, you’ve got textbooks, courses, workshops, and YouTube videos. Everyone understands that you must put a lot of effort into learning the language to start programming. In an IDE, you see a list of files on the left, an editor in the middle, and some stuff you haven’t figured out on the right, but you may simply choose not to look there. And you’re good to go: here’s your file, here’s your editor, you can start typing.
This happens because mastering the IDE is not always necessary for achieving a quality result. You can spend a week exploring your IDE, but the code you write won’t get any better. You’ll be able to write it faster and with less stress, but these things aren’t always convincing.
Proficiency with your IDE affects code quality only to a point. We have static analysis and refactoring tools that can help you improve code quality. In some cases, this will make the program work better. The IDE has a debugger, which helps you find issues faster and detect more bugs than by looking at the debug print. So it does give you something, but there’s no obvious and guaranteed connection.
Users aren’t in the habit of exploring their IDEs, and we often see people sharing with others that they have stumbled upon some useful button. We talked about this button in the documentation, on Twitter, and on YouTube, but they haven’t seen any of it. And then they find the button and rejoice because they had been missing it badly for five years, and now they’re telling everyone about it.
Roman: There are about 3,000 features in IntelliJ IDEA. An average user uses only about 40. However, everyone uses a different subset. It’s not that these 40 are helpful and the rest are just extra. They are all useful, but each one has its audience. Maybe our users would be happier if they learned how to make use of a hundred, or at least 50, features. Do we want to help them in any way?
Dmitry: We do. But you have to understand that all of these problems don’t arise out of laziness or lack of curiosity. Programming is, in fact, a very complex occupation, and when someone works on a task, they are focused on solving the task and don’t have many extra resources for learning.
That’s why we come up with different ways of telling our users about a feature. For example, we have a plugin that detects whether a user has done something in a non-optimal way. It shows a notification saying, “What you just did by pressing ten keys can be done by pressing this one key here.” But I’m not sure if this is a good solution because notifications can take you out of the flow and distract you from finishing the task.
We have no clear understanding of how to go about it, but we now have cognitive psychologists working for us. Together, we analyze what happens to a person’s attention span when working with the IDE and how we can interact with them. How can we hold off on showing information to a user until right when they’re ready to consume it? One of the most interesting questions in my current work is how to teach people or motivate people to learn, and many of the answers are unclear.
Roman: That’s good – not knowing the answers makes things interesting.
I wonder how important it is for you to get tasks finished. Sometimes, as soon as I’ve figured out how to solve a problem, a checkmark in my head says “done.” And then it turns out that I didn’t get it done because the solution was too evident to implement. Does that ever happen to you?
Dmitry: Not really. For me it’s all about having the results of my efforts in front of me, playing with them, and seeing how nice and neat they turned out to be. I’ve been reorganizing the list of notifications in our IDEs. When you open an older version, it is a total mess of names, identifiers, and letters – very confusing. But in the new version, when I’m done, it’s going to be nice and neat. Seeing everything shape up this way is a big part of my motivation.
Roman: Speaking of nice and neat, let’s talk about Kotlin.
Together with Svetlana Isakova, you wrote a book about Kotlin. We know from other sources that the two of you were already planning to write a book when a publisher came knocking, and a partnership was born.
But then there are contracts, obligations, requirements, and deadlines, and you can’t work on the book at your own pace. Was it difficult to finish the book?
Dmitry: Well, deadlines are deadlines, but everyone knows that no one ever meets them. We didn’t meet our deadlines either, and everyone was OK with that. What mattered was that we were progressing and that new chapters were coming out regularly.
Was it difficult to finish? Rather it was difficult to stop rewriting chapters. It always felt like we could do better: rewrite something here and there, add an example, or explain something differently. Svetlana wanted it to be perfect, but I persuaded her to be done with it, add a full stop, and send it to the publisher. Otherwise, we never would have finished. It wasn’t so hard for me to finish the book after all.
Roman: Did your idea of writing change as you worked? Do you have any advice for someone who wants to write a book?
Dmitry: We worked a lot on examples. It came as a surprise how hard it can be to come up with a good example and how important it is. Having completed the first half of the book, we received a lot of feedback saying that our examples were too isolated and that we needed to show something more tangible. So we ended up writing a whole JSON serialization library as a running example for one of the chapters.
You also need to be prepared to have the entire text rewritten three times and plan time for that.
When it comes to working with a co-author, I think that, had I written the book by myself, I would have done it twice as fast, but it would be only half as good. Having another person continuously reviewing the text and bringing in their ideas adds a lot to the quality of the final result – at least that was the case for us.
Roman: I think it worked out great!
Let’s talk a bit more about your background. You worked for Google for a while and then returned to JetBrains. What has changed in your perception of the industry and your understanding of the right way to work?
Dmitry: When I decided to work for Google, I wanted to learn the sorcery behind Gmail, Google Maps, and Google Search that makes these products so fast and reliable. I really admired them but had a feeling that if I ever were to create something similar, I wouldn’t even know where to begin or which skill set to apply.
I found some of the answers. For example, it makes a lot of sense to store data in RAM. If you do the math, the costs appear to be reasonable, and this allows you to get very different access times and the amount of data you can work with compared to more traditional architectures.
I also saw how awesome it is to have an SRE organization like Google. They invest a lot into it and get magical results in terms of how their services work.
At JetBrains, the SRE culture has recently evolved pretty well, too. It’s not my area of expertise, so I don’t know all the details, but we’ve adopted many of the Google practices that have become industry standards as well.
Roman: Do you keep an eye on the latest development and management practices? Are you planning to try anything new?
Dmitry: At a certain point in my life, I was a big fan of processes and methodologies.
My journey toward joining JetBrains started when I saw a book on extreme programming in a bookstore in Frankfurt. I was intrigued by the title, and that is how it all began.
Then I kind of lost interest in project management methodologies, and lately, I’ve been more enthusiastic about cognitive psychology.
Roman: Since you’re mentioning cognitive psychology again, tell us where else we can use it.
Dmitry: In a few areas, actually. Mastering the IDE is one that we’ve already discussed.
Other folks are working on creating user personas and personalization based on them.
I see a lot of potential in changing the way we interact with developer tools. Things have become too conventional, everything is set in stone. We’ve been coding the same way for 50 years. I think there’s plenty of room to do things differently.
Of course, people have tried alternatives. Unreal Engine Blueprints is also a way of writing code. It is used by a huge industry, but it actually comes down to dragging arrows between squares. I don’t think that’s what we’re looking for.
By analyzing what is going on inside a developer’s head when they write code, we can find ways to reorganize the process and revamp their experience. But these are mere aspirations – I don’t have many tangible ideas in mind. Maybe nothing will ever grow out of this, but I think there’s a lot of potential for changing the rules of the game.
Roman: Well hey, we’re allowed to dream, aren’t we? And maybe something new will come out of it in the end. And we’ll continue to help our users develop with pleasure.
Thank you! This has been insightful.
Dmitry: Thank you!
Roman Poborchiy
