IntelliJ IDEA: The Documentary | An origin story

CultRepo| 00:39:04|Mar 26, 2026
Chapters12
Founders discuss the motivation to build a lightweight, smart IDE and the early struggle with competing tools and the scale of the task.

IntelliJ IDEA's origin story is a relentless, user-driven battle to reinvent Java tooling, blending deep code understanding with a devotion to speed, openness, and community.

Summary

CultRepo’s documentary-style interview reveals how JetBrains built IntelliJ IDEA from the ground up, driven by a need to escape Java’s clunky tooling and create something lighter yet smarter. The team chased the first-mover advantage, with a philosophy of effortless, transparent workflows where the IDE anticipates a developer’s needs. The transition from internal experimentation to a commercial yet open approach—split into Community and Ultimate editions—played a pivotal role in fending off Eclipse and shaping modern IDE expectations. The narrative highlights dogfooding, open source strategy, and key product decisions like dark UI themes and early Android Studio collaboration, all under a banner of “develop with pleasure.” The speakers stress speed as the core value, continuous iteration, and the culture of empowerment at a relatively autonomous JetBrains. The origin story also touches on the emotional highs and existential risks of startup life, including licensing shifts, community trust, and the long arc of building a sustainable business around a developer tool. Finally, the dialogue pivots to AI’s future role in IDEs, underscoring the balance between human insight and automation while reaffirming a commitment to reliable, intuitive tooling for developers.

Key Takeaways

  • IntelliJ IDEA’s developers aimed to create an IDE that didn’t mention Java, focusing on language-agnostic ideas like code completion, refactorings, and formatting powered by code analysis.
  • Speed is the most important attribute for developer tools, backed by a brain-chemistry argument that faster feedback reinforces productive flow.
  • JetBrains leveraged dogfooding (developers using IntelliJ to build IntelliJ) to deeply empathize with users and rapidly iterate on features.
  • The open-source Community Edition lowered entry barriers, expanding the user base and enabling widespread experimentation without sacrificing a paid Ultimate edition revenue model.
  • Android Studio’s birth on top of the IntelliJ platform exemplified how open core, collaboration with Google, and feature-sharing can redefine a platform’s ecosystem.
  • Dark UI was a bold, early differentiator that helped attract users, with Konstantin Bulenkov playing a key role in its development.
  • The switch from perpetual to subscription licensing was handled transparently, guided by community feedback and rapid responses to concerns, which reinforced trust and loyalty.

Who Is This For?

Software developers, product managers, and tech entrepreneurs who want to understand how a developer-focused company built a lasting IDE ecosystem and navigated open source, licensing, and platform partnerships.

Notable Quotes

""hey, this is not the best way to do something.""
The IDE’s ability to guide developers before running code highlights IntelliJ’s proactive quality checks.
""Speed is the most important thing I value in developer tools.""
A core principle driving design decisions for performance and flow.
""Something that everyone takes for granted now, like the dark UI theme.""
Early UX differentiator that helped broaden adoption.
""Dogfooding... there's a lot of developers who are using IntelliJ IDEA to create IntelliJ IDEA.""
Emphasizes the culture of using the product to improve the product.
""The support and the community around the brand... should be built.""
Shows how JetBrains values community feedback and transparent response.

Questions This Video Answers

  • How did JetBrains use dogfooding to improve IntelliJ IDEA during its early days?
  • Why did IntelliJ IDEA choose a split between Community Edition and Ultimate Edition?
  • What role did Android Studio play in expanding the IntelliJ platform and its ecosystem?
  • How does Kotlin’s adoption relate to IntelliJ’s platform strategy?
  • What are the future AI considerations for IDEs like IntelliJ according to its creators?
IntelliJ IDEAJetBrainsAndroid StudioAndroid developmentEclipse competitionOpen source strategyCommunity EditionDark UI themeUI/UX in IDEsCode editing and refactoring tooling
Full Transcript
So actually in this regard I can be very honest. It's hard to speak about emotions.  Yeah. Especially for engineers.   For the first time I met a smart tool and the  scary part about that is sometimes intelliJ IDEA  was much smarter than me. Basically the main  challenge was the size of the task. I guess   I can start from the beginning. If you don't  mind. Yeah. Yeah. Yeah. Let's go. Let's go.   Let's go. So in the very beginning we just looked  at, okay, we look at the competitors we look at all   these IDEs and we see, okay, what is, like, how much is in general, like... if we were to   rebuild something like this, how  much stuff would have to be there? And as soon   as you become the number one there's always  someone who is trying to chase you and and   your job is much harder than theirs because they  just -- they learn from what you're doing and   they just imitate you. You have to be the first  one; you have to experiment; you have to invent. I would say that IntelliJ, in some sense,  rescued the Java language from itself.   That the experience of programming in Java  without an IDE is kind of a mess. Unfortunately,   Java didn't include an IDE when  it first released and IntelliJ came along   and, you know, provided what was missing. My main  challenge was basically to create an IDE that   did not have any mention of Java in it whatsoever.  A lot of people started to use Rails specifically   because they wanted to escape from the world  of Java because they hated what the Java enterprise   stood for at that time. Java has evolved a  lot in the intermediate times but back then   it was seen as something very heavyweight; very  bloated. We needed to separate a lot of concept   to split interfaces and implementations because  implementations were so much Java dependent   that they didn't suit any other  language. When I first started programming Java,   I didn't use an IDE. They taught us how to do it  in a text editor. You write the code, you compile   the code, the code doesn't work, and then you  have to keep going through these iterations of   'what did I do wrong? What do I need to change?' Later on when IDEs were introduced to Java,   particularly when I started using IntelliJ  IDEA, I could see that IntelliJ IDEA, that   the editor itself tells you before you've even  compiled it, before you've run anything: "hey,   this is not the best way to do something." So you  know instantly that there are better ways to write   the code or that you've made a mistake. I was  very used to these very slow, clunky alternatives,   things like J Developer and JBuilder and whatever.  And I was looking for something more lightweight   but sophisticated. You can easily relate from  when you get angry if you're using some software.   Like I often say I hate developers. I hate them  because they produce the crappy software and I'm -- I feel maybe responsible for being one of  them. I feel the responsibility for all   the crappy software in the world, right? A good  IDE, you know, automates away a lot of the tedious   aspects of programming in whatever language you're  programming in and IntelliJ does that for sure.   And you know, a great IDE anticipates your needs.  When you really start transforming programs,   you realize how much manual activities you have  to do because you have to change here and here and   here and here and then make sure that you haven't  forgotten anything. So there's like lots of   changes and the the larger the system is the more  changes. A lot of that work can be done automated.   This is very easy. So all we did is just  automate all the tedious, very hard work which was clear that it was taking a lot of  our time. It's, like, maybe breathing -- like you   enlarge a number of things and then you're trying  to push them down and consolidate. Actually, IntelliJ was not the first product that we made  because we started a bit earlier. We have   started releasing kind of precursors to IntelliJ.  We used to -- me and my partners -- we used to work for   a company, for a different company before. Yeah.  And that was what we've been making there.   It was a software company. We were building tools,  actually. But then eventually what we realized   is that we started turning that product into an  IDE. Yeah. So then we decided okay we'll just not   do it that way. We will just  start fresh -- absolutely fresh. What these   guys – Jetbrains – did, they tried to use the front end of the compiler, so the analyzing part, and instead   of generating the code, they used the knowledge of  the code to support the programmer to do   code completion, to do refactorings, to do some  code transformations and even code formatting. It   was a really interesting idea for me; I wasn't  sure that this will pay off in terms of the   financials or security or career or something  that wasn't on a scale at all, but then only   pure joy of doing something useful. I would say we  were in a team uh where everybody wanted to – not to   show off but to to really change something. We  spent a lot of time in the office. We came   mostly each weekend, on Saturday or on Sunday  and you would always meet somebody else who is   also trying to do something, and the most  easiest way to learn was to read code which was   written from your colleagues and they wrote  good code. So I tried to make my code more or less   indistinguishable from what they wrote. One  of the reasons why IntelliJ IDEA is so effective   as a tool is because of the dog fooding; is because  there's a lot of developers who are using IntelliJ   IDEAto create IntelliJ IDEA. For many people this  has helped a lot because it makes it   very easy to to empathize with the user. Well, if  you don't use your product, how can be honest with   your users in a blog post on Twitter that your  product is the best? The IntelliJ developers are   never satisfied. Nothing's ever, ever enough.  People usually hate IntelliJ for its indexing   because you have to – when you open the project –  you have to wait for a little bit before it's   completely ready. And we know that this has  been a big pain point for users. So we have been   making it possible to use more and more product  features while indexing is still running. So it's   not just a time where you just have to sit  and wait. You can already start working on   the project. They were always asking how  can we make the experience better? Okay,   we can't make it perfect. Can we make it 98%,  can we make it 99%. There are a number of   times when I remember feeling like how the heck  did it figure out that that's what I wanted it   to do? When we were developing IntelliJ IDEA,  we always keep in mind the principle of flow and   it's a principle when, well, actually  it's a condition when you feel the most happy,   you're focused, nothing interrupts you and you are dedicated to one specific task. Speed is   the most important thing I value in developer  tools. There's actually a chemical process   in the brain that comes by making changes quickly  and seeing that validate quickly. Right? If you,   if you disrupt that, it can be very frustrating.  Right? People don't like doing that. There's    some people who think about that old, those old  days and think that software is no fun. It's a   lot of fun if you're moving. You know, you want  to focus on your goals – on your path. So similar   is here. You don't think about the tool itself.  You do your job and your experience    becomes kind of seamless and transparent. We kind  of forgot what the abbreviation PSI stands for. So   I think it's either program structure interface  or program source interface. And I think no one   can tell for certain what which of those two it is  anymore. But this is the core abstraction that is   basically how IntelliJ represents the source  code, the different syntactic elements and   the connections between them. Those things have  been there from the very beginning and they are   still there in 2025. Of course, with software  like this, which is being developed for 25 years,   it is hard to to keep up, right? But it is  also inspiring that you find the way. In   order to to get somewhere, you have to –  it takes time. Takes time, a lot of effort.   When you create the product you love, there  will become times when it will be really hard. In the early days, IntelliJ was a minority  player. It was pretty much – from the very, very   beginning when we started – experiencing  different pressure coming from people.   Our old employer at some point tried to get  us back. They threatened with lawyers. They kind   of tried to negotiate. They suggested different  collaboration scenarios. They wanted to pay money.   They wanted to do some contracts with them. So  like all sorts of things. Microsoft tried it. They   were very persistent. They were sending very, very  skillful scouts. We had lots of meetings.   They took us to some restaurants and then they invited us to Redmond to the headquarters.   So first of all we started before Eclipse and  then we managed to build some of the user base.   Obviously, also, we were paid and Eclipse  was sponsored by large companies like IBM and   later on the whole bunch of companies also from  a commercial perspective, this competition should   have been lost. Competing against a free product  that's very high quality and moving very quickly   is really going to be tough. Then, as we observed  what they were doing in the next few months,   we realized that they are very, very quickly adding  things to their product that we are doing.   We implement a new feature, we discuss it in  the community, we implement a new feature,   two weeks later they are publishing  something like this. We implement something   else and they again. So it became clear  that they are just chasing us. Yeah. The pressure   was more from inside that we wanted to make our idea  faster, that it would include more features which   would help people, then it would help us to make  new features for for our users. You have to   apply consistent force for a long period of  time, right? That solves most of the issues – growth issues. Eclipse was number one  because it was free and mediocre. Uh, IntelliJ  was a commercial tool and it cost money  and a lot of developers didn't want to pay money   for development tools but the good ones did and  they were able to build a business on it that they   were able to slowly grow. So we decided that it makes sense to keep trying to compete   because we saw the support from existing users and  they were kind of a driving force for us to   identify our core values for ourselves and  then maybe we just were not professional enough   in business to understand that this game  is about to be lost. So we just didn't see this   coming, and then it turns out that yeah, it wasn't  lost. For me, it was clear that usability and the   ease of use and then the feelings that  people kind of get when they use   products that's essential to a good business.  The IntelliJ IDEA is really customizable. So,   um, you know, you have the opportunity to turn  up or turn down almost any of the suggestions,   warnings, you know, and things  that it offers you. Something that   everyone takes for granted now, like the dark UI  theme. I think this was, this alone has brought   a lot of users to us because we were the first  IDE to release a good-quality dark UI theme. Uh,   this was Konstantin Bulenkov's effort.  Oh, dark was a very bold move. Back into 2011,   there was not a many dark desktop applications.  The only one I remember was a Photoshop. But what   if we move that experience to code editors,  IDEs? I had such an idea and let's try it. it   It wasn't a mainstream but I started doing  something, so I took some days on my vacation   made a prototype and it was a very  interesting. So I like the experience and   I had a huge support from the community, from  people who said "okay, that's nice, even if I thought   that was far from the production ready, it  was a great moment because I feel the support   and why not? What surprised me of a company of  that size is the amount of autonomy a lot of   developers had as well. The ability to pick which features they're going to work on, the ability   to propose features which are going to make things  easier for people. And that's one of the reasons   why you end up getting some interesting features  because if you have a product owner saying this   is what we're going to work on, you don't always  catch some of these little features which could   just make developers lives a lot easier. Having  these opportunities is why I stay for so long   because I can always – I never get bored. I always  have something new that I can try. From the very   beginning of this, we wanted to build a company. We  wanted to build a business. It was not only about   the product itself. It was the full business around it. We sell a thin box, basically,   no books, nothing, just like, a help file and plus  a nice product. We just have to find the price.   To the price was, we always thought that  it cannot be more than $500. We read it   somewhere that this is a consumer ceiling  of a consumer product. No one will buy it out   of their own pocket even if it's the best tool  out there if it costs more than 500. Back then   for many people we decided, 'okay, so we don't  have budget for software development tools.'   So we need to switch from paid software to open  source software. And then the decision was   made to to make IntelliJ open source. Unlike  Eclipse or some other open source software,   we don't have any external funding. We didn't see  a need for external capital. If you just can stay   lean and grow organically and your business grows  together with your company's growth, that's the   best choice. So we still had to keep the  good revenue stream to make sure that we can   develop new versions and feed all of the people  in the company. Right? So the decision was made   to split community edition which is open source  and ultimate edition. I think that this community   edition actually helped us a lot to deal with this tough competition with Eclipse. If we would   wait more, we probably would lose this battle completely. Probably it would be better   if we would start earlier, but in most cases  it would be better if you start earlier. Yeah,   you know, everybody I knew was using the paid  version, but the open source meant that new   people could look at it and try it out and  they just fell in love with it as well. Thanks to having a version like IntelliJ IDEA  Community Edition available free of charge to   everybody to students alike as seniors, it really  decreases the barrier of entry for everyone.   You can just download it, check it out. And I  believe, especially for newcomers to Java, to the   JVM, but also to programming in general, it's a  super easy getting started experience. I think the   fact that IntelliJ community edition is  open source is very much a symbolic thing as well,  showcasing how Jet Brains invests into the  community, into the software development ecosystem.   So developers notice these things, they value  those things and in the end they are still open   to paying to software, to paying for enterprise  features, paid features, even if a core is open   source. So I don't really think that putting  something out on an open source license takes away   from your business case. It actually expands your  business case. I work on an open source project   called Quarkus which is a framework comparable  to Spring Boot. I'm a senior principal software   engineer and I work daily on Quarkus with IntelliJ  IDEA and nothing else. Like you said, Red Hat and   IBM have a very strong open source culture. That  means that when we identify a gap – for example   for Quarkus – on the community edition of IntelliJ,  we will likely like create an open-source   plugin for IntelliJ to help and we have  done that right, so regular IntelliJ community   edition doesn't come with any Quarkus specific  support out of the box but we now have our own   plugins that you can, that the users of  the community edition can install and get   Quarkus-specific support without having  to like go the ultimate route which obviously   is the is the best solution because the the  support is more comprehensive and also open   sourcing IntelliJ core allowed for later on  to collaborate with Google on Android   Studio which made our initial platform even  more popular. One of the most important moment   in the history for Jet Brains and especially  IntelliJ platform was the moment when Google   decided to move its Android development  to IntelliJ platform and base Android Studio   on top of IntelliJ platform. Yeah. So at the  time we were basically building all the Android   support for Eclipse. Eclipse was the dominant  IDE for Java development. But inside of Google,   a lot of the developers working on the Android  operating system, they were using IntelliJ because   IntelliJ was clearly a better IDE. It just, you  know, wasn't as widely known, uh, because it was   pretty recently open sourced. And so, it was this  expensive IDE that prodevelopers would choose,   but the masses were not. So, we asked ourselves,  if this is what engineers inside of   Google prefer to use, why are we forcing our  users to use Eclipse? Now clearly there were   some people who liked Eclipse but you know, we  knew that IntelliJ was better and so we thought,   'okay, what would it take for us to basically pivot  and build our Android developer tooling on top of   IntelliJ?' When I found out that there might be  a chance for the Android development to move   over to our platform, I was very, of course, I was  very keen to help make this happen. At one point   I just basically went to Mountain View for like a  week or a week and a half to basically help them   get started. So, we got the team together. We  started this collaboration in in secret and we called it Project Diamond. And so, that's  a little bit of an inside joke that, you know.   Basically there's something called the diamond ring  effect related to eclipses. So, you know,   when the Eclipse is over, you have the diamond  ring effects; little pearls as the, you know,   the moon shifts away from the sun. So, Project  Diamond is what comes after eclipse. Haha.    So that was Project Diamond. So there was like  four of them in the room with me and I was just   trying to walk them through the initial process  of: this is how you build a dedicated IDE on top of   IntelliJ. How you set up the build scripts,  how you set up the product information, the splash   screen, stuff like that. It was kind of like  Christmas, you know. One one thing I remember   was they had this feature for code folding. So in  Java, the way you write inner classes is pretty   verbose. You know, you have to 'new' the object  and overwrite it. And Intellij had this   nice feature where they would fold that whole, you  know, syntax together into a single lambda-like   thing. This is code folding for Java. And we  realized this is perfect for Android resources.   We can basically inline the default strings and  show them verbatim in the source file. And that   was one of the features we highlighted when we  unveiled Android Studio at I/O 6 months later.   Seeing the applause when they announced that this  was one of the highlights of my career, one of   the happiest moments. I think right before the  announcement, I was able to ask them   to make a last minute change so that they would  feature the name of the text powered by IntelliJ platform. I think it  was there because I asked for it to be and this   happened like really, two days before  the release and they agreed to do that and it   was there in the initial release and I think it's  still there and I think this is a very important, it's a very important contribution that it's  not just them who did it but it's also something   that, it's also something that we did together.  Feature-wise, what we really gained was just an   incredibly powerful IDE and that's what we wanted.  I still remember, you know, just the change in editor feature set, right? Like the  really nice inspections and intention actions. My   favorite feature they've come up with is this  debugger enhancement where while you're debugging,   they create these fake comments in your source  file that are showing the current value. So when   you're looking at your source, you don't have to  guess, well, I wonder what that variable is now   because IntelliJ helpfully puts a little  comment there saying what the value is. Just   brilliant there. They have just tons  and tons of features like this. It's just a gold mine of of hidden and visible features.  We saw it as a great opportunity for us to   have some marketing support or Google supports  you then it's a totally different play and   that was the beginning of very fruitful years  long collaboration with Google Android   team which later on lead to Kotlin being  adopted by Android and many other things. Mirror was founded around 2011. I wasn't there  but I had a discussion with engineers who still   work at mirror. They confirmed that IntelliJ IDEA was here from day one. Our primary stack is   Java and Kotlin for back-end development and  absolutely most of our engineers are using   IntelliJ products. I think one of the most  meaningful integrations and plugins that we   use are Spring-related because almost all of  our services are based on Spring boot. Also,   we use a lot of refactoring and static analysis  tool from IntelliJ IDEA is something that   we use quite a lot. It's kind of when you get  to the office, you don't think about Wi-Fi,   right? You just open it and it kind of works.  Same here. So it you rely on such infrastructure   tooling a lot but you don't want to focus on it.  Instead you have your problems to solve and   I think IntelliJ IDEA was evolving great.  I've had the privilege of working with the   IntelliJ team and so have other people on  the Spring team. We've had a good collaboration,   an ongoing collaboration for years now. So I  know that the team is very eager to make this   the best experience for Spring developers.  And so they're always adding new things that   support new projects, new frameworks, new ways  of working with Spring as we add them. And so   there's already new things being developed. And  I just feel like that relationship has led to   a place where we are now where everything that  we want people to be able to work with, they can   pretty quickly. And so I hope that continues.  You know, I see no reason to think it won't. If there were moments in particular where you  thought, I don't know how we're going to make   it through this. Mhm. How do we overcome this?  How do we push? Mhm. Yeah. There were multiple points like this when we decided to  switch from perpetual license to subscription   license. It was deep in the night. I was testing some clicks or reading through the forum   and understanding that, 'God, maybe I have  killed this company.' 'And that was specifically  because of...?' That was because of a broken promise of being a good guys. Most of the   companies do one of the two things. So they  roll everything back as it was before or they   ignore what they've been  told and hoping that it will pass and then   everything is going to be fine. We'll just  wait it out. So we decided to do differently.   So we analyzed the actual patterns when people  aren't happy with our offering because   we honestly thought that it was beneficial for  everyone. It just turns out that not everyone was   properly covered and in the three days we've released an updated offering which for   many people looked like, you know, 'oh that you've planned from the very beginning', but if you freeze that then   will be [ __ ] storm but now it feels like a step  back so it is getting accepted, right. So people   thought that it was some kind of orchestrated plan  from the very beginning but it wasn't. So it was an honest attempt to to mitigate the damage that we  as a company made, the community and many people   saw it like this and appreciated the behavior  and even more it was appreciated inside   the company. They saw that the company listens and  that was like, you know, an ultimate bond– maybe I   would say for everyone. The community feedback is  crucial for us. Most of the time it's harsh and   honest and this is what we like. We we use  it to actually understand where our   bets were wrong or right and how users feel  about our changes. We have created this online   community of people who were coming and living  through the evolution of this product together.   So people knew that when they reach us  they reach developers, they don't reach support   engineers, level one, level two or something. So  they knew that it's like a direct line   to the people who would make change. What I  really appreciate is how seriously Jet Brains has   taken this and within usually one day you  got a very reasonable response. People tried   to help you while nobody is asking, "which kind of  license you have, subscription, whatever" and   for me it was always a referential example of how  the support and the community around the brand   or product should be built. Yeah. So it's very  important for me to help as many people as I can.   So, and I found out that if I help software  developers, I also help people – other   people. And it's not nice to be in the in  this chain of helping other people. "I'm sure we're going to go into AI, but what do  you think the future of programming is from an   advocate's perspective?" So, I have I have opinions  on the future of programming. Yeah. So, my   personal take on AI is that – I'm an AI skeptic.  So, I enjoy doing myself a lot of the things that   people uh use AI for. I only can speculate on the  future but I still believe that we are dopamine   addicted species and I don't see a future of  software development where we don't have humans   in the loop. I don't think the fundamentals  change. We still need tooling to be able to   understand our code, to navigate our code, to do –  I do think one of the things – a specific feature   I think is going to be so important is good diff  tooling because if an AI writes the code, we want   to understand what happened? When did it happen?  What's the difference between what it wrote, what   I understood before?... These are the kinds of tools  which I think an IDE could focus a little bit more   on and make it easier for us to work. This is the  unique position because Jet Brains is right in the   middle of the most disrupted profession in the  world. Yes, it's like super scary and dangerous,   but you are in the very middle of the tornado.  You have to be close but at a distance. It's like,   okay, it's so important for it to be fluid and   intuitive and powerful, right? And so that's   what I appreciate so much about IntellJ..  It has this mantra of 'develop with pleasure.' I   think that's the tagline. And you feel it,  right? That it's just it's really a natural flow   and it doesn't get in your way. And I think  that's maybe the essence of of IntelliJ and,   you know, as we pivot towards AI features – that's the challenge, right? Is to make sure that   it retains that there is a great opportunity for  IntelliJ to lead this but if you incorporate the   new technology, new tools in a framing that's already familiar to people in   a place where they are solving their task  and problems, then that's the way to go to   continue providing a set of tools that is relevant  for how people work. So I don't think that our   future necessarily relies on like, you know, big,  shiny new features or like, big discoveries that,   big inventions that we would make. I think  a lot of this is just about being reliable,   being performant, being easy to use.   But I think with AI we are going to have another   approach to this and I have good hopes  that it will be successful in the end.   But if you try to generate the whole application,  then you probably have no idea what is written   inside. And at this point, IntelliJ could really  help you to find the common mistakes because   our inspections are really trained to find  mistakes. I think that Jet Brains and IBM   will be able to work together in the AI space by  bringing IBM specific models to the Jet Brains   IDEs and having them working just like they  do with Cloud or Open AI or anything else.   And again we come back to our values and  say like if Jet Brains understands   their users. If Jet Brains can design a great  experience of using that, they can listen to   what people need. So I see the future  of Jet Brains and the future of IntelliJ is   not about necessarily adding features to our  existing products but transforming into a new   reality where the work is done differently. AI was  always, always there like IntelliJ – the intelligence   part of IntelliJ is intelligence and then  and it was, it was not a human intelligence   there because it was encoded in the tool so  it wasn't artificial intelligence there always. There is a good synergy between between  Java's development and the development of a   of a tool like IntelliJ. We get good feedback, you know, from them about the language, about   what's working, what's not working, and you  know, the existence of the, you know, of   a good IDE informs the choices  that we make when we're evolving the language.   You know, I think of many of the engineers  and IntelliJ friends, we have regular meetings   and we also share quite a bit  of our internal road maps and so on. So   we we have a lot of trust and I think we we  all realized that this has been, you know,   a mutually beneficial collaboration,  one that I hope will last many,   many more years. So I'm a big fan of  IntelliJ. I can confidently say as,   a representative of my team that we love IntelliJ  and we hope that the team at Jet Brains will   continue to do amazing work for a very long time.  "I mean, is there anything that maybe has come to   mind in the last days or so or during the  interview that you maybe wanted to mention?" Jet Brains, maybe you have such highlights. I  don't know. If I could just say one last thing,   I want to say thank you very much to the Jet Brains team for for just being a great   partner in this process, right? It's just,  it's really important that when you think about   the developer experience, you think about  the framework and we try and do that.   And then also the developer tooling has to  be topnotch and they do a great job there.   We were kind of a group of friends  where everybody helps everybody.   Yeah, it was really nice feeling that  you always really always have support from   your colleagues because they are not only your  colleagues but they are your friends and I   think having remote developer advocates who come  from different countries and come from different   cultures also helps kind of spread the message in  a way which is more understandable by a broader   range of of developers. I've met many  great people while doing this both inside company,   outside of the company and I think that I've  seen a lot of great examples of how people think.   So I've seen great examples of empathy and great  examples of creativity and this is hard to over   stress how much I enjoyed this time. So for me  and for many people who work in this, this is the   ultimate testimony of doing something useful in  this life. That sounds posh right? But it is   true. We were also young and lucky and basically  the learning was not always the   right one. Yeah. We've seen many, many times since then how hard it is to create successful   companies. And we had this illusion back then  because it kind of happened very quickly. We   were so successful. We had this illusion that  actually building great products   and building great companies is an easy thing.  You can keep repeating it and actually this was   this was a false learning. Yeah. And because we  like, in the last 25 years we've seen it, it's it's   not the case. Creating companies is extremely  hard. Creating good products is extremely   hard. Creating good products and good companies at  the same time is enormously hard. Yeah. And then   That's the thought I wanted to put  in. It didn't answer your question.

Get daily recaps from
CultRepo

AI-powered summaries delivered to your inbox. Save hours every week while staying fully informed.