The Qodana Story With Alex Gopachenko - Part I

So, okay, let's get into some serious stuff. This  is why we're here today is to talk a little bit   about your career at JetBrains, some of the  things that we're doing with Qodana at the   moment and the team. And I'd also really like  to get your perspective on kind of the industry   around us at the moment. Of course, there's  a lot of questions and I think you always   have very interesting perspectives and you're  very uh you make an effort to stay in the know,   which I appreciate. So, I guess the logical place  to start is talking about your career at JetBrains   a little bit. Obviously, it's impressive.  You've been here for a long time and I saw   that one of your first projects was actually with  PhpStorm which, in case anybody doesn't know, is a   um an IDE that was originally released in 2010  dedicated IDE for PHP and web technologies and   uh this is kind of where you started your  your JetBrains career. Can you elaborate   a little bit on that, and are you the father of  PhpStorm? Oh yes, yes I am. Uh but I you missed   one important part. It's not very visible but it  actually makes the story even more interesting.   So from the very first I uh become a JetBrains  employee in 2007 I think something like that.   From the very first day I started making Qodana.  Ah yes yes yes because my job was in TeamCity   uh and uh as the first ful-stack developer who is  familiar with front-end I was doing some dynamic  

interface stuff uh AJAX at that time uh and  the task which I was applying these skills to was   first of all exporting inspection results from  IntelliJ IDEA and importing them into TeamCity   and my database skills I was able to hone for  next week because I was designing the different   report on those runs because, for example, if you  run IDEA on IDEA it will give you 10,000 oh sorry   100,000 uh different warnings and so on and so  on and so on. So I was building a quality gate   for IntelliJ IDEA project itself checking itself  using city and the second thing I was what I was   doing as a red line uh through all my JetBrains  uh uh next and the current efforts uh uh what I   was doing on TeamCity the okay systems that you'll  be able to indicate the amount of stuff uh so you   have some graphs and charts so it will so double  like code coverage also now part of Qodana and   so and so on and so on. So it's all it's funny  but now it's retrospective. It's it's 20 years   of making Qodana. Yeah. Kind of a foreshadowing  for what Qodana is today. Also I mean I think   officially you were the Qodana project coordinator  in 2019. Is that correct? Yeah. Let's let's be  

sequential. Then uh I switched from the  uh taking in results of any inspections   uh and showing them and making them useful as  a quality gate and different different aspects   of quality make them useful for a project like  health. uh in TeamCity, I switched to to IDE teams   uh did work on on some of Java obscure nowadays  Java servers and then uh JetBrains was spawning   uh the whole family of IntelliJ-based IDEs  based ads the first was the ruby mine which   made intellj into a platform then was PyCharm then  the next stuff came and I was the father of both   PhpStorm and WebStorm this is why they have  the same name actually name family. Yeah. And   uh it was funny we took some existing code which  was contributed to project and the whole vision   was I was so fascinated with IntelliJ IDEA. Uh  uh then I first uh was started working in Java.   It was few years before JetBrains it was barely  version 1.0 actually only applets at that time.   I tried all the stuff from all the companies who  did Java, IBM stuff, uh, Borland stuff, all all   the IDEs and then I touched into the idea. It  just clicked immediately, and I think many of our  

uh like customers know the feeling then sometimes  it just works and it's like a "Shut up and take my   money". Uh, so uh I was uh, and PHP at that was  time was was already a little bit stagnating.   It was as a language a little bit um like a  language for people who do low-quality work,   something like that. It was a bad bad idea but  it was that before first of all they didn't have   any tools didn't have good debugging they didn't  have any any good tools they do do have now and   we JetBrains and PhpStorm played a big uh part  in that actually but uh yeah um the story   was different with WebStorm and I was fortunate  that it was taken from me because it was   exploding and I wouldn't be able to take a good  care of PHP if I was also thinking about   JavaScript it's I think an even harder story. PHP  was an easier target market for me. Um but basically   what I made the same awesome experience. I  exported the experience to the different language   and during that doing that I had to first of  all design a complex algorithms uh uh from   type inference to make the nice completion and  different different stuff like that and actually   change the PHP community themselves to switch  for example from working over FTP repository live  

on live server to, for example, source control uh  work, test-driven work and so on so and so on and   even more features for type inference we have  developed PHP dynamically typed language loosely   typed at that time uh we had to kind of we helped  the next generation of tools uh by uh making a set   of conventions and those conventions boiled down  into actually even future languages. For example,   in PHP uh we have introduced this variable can  be this type or that type, or that type with a   vertical pipe. Super easy internal syntax. It was  just how it was in memory. It was just a print out   and then you put it into PHP doc for developer  or or to take use or to pull like a PHP store to   make use of it to for either type inference  for completion or inspection. So you're using this   variable, which is not initialized, stuff we take  for granted now in Java. Uh we put it into we made   it for PHP and those commands and type definitions  started to shape in the language. Then the next   thing was that we um seeing the um what's happened  with Ruby basically language was dying. It's still   uh is little bit alive and RubyMine is still  selling and they're doing some interesting stuff in  

there but on overall is it's not even interesting  to to work with and PHP struggled uh at some point   nobody was wanted to maintain it and so on. Uh  so we hired an external person who was working   PHP itself Nikita Popov he's amazing actually  engineer. Hi Nikita if you will be watching this   in future - and for three years we were working on PHP  uh he would work on PHP but within our meetings   working on PHP in his all which language features  and conventions and APIs make it tool friendly and   having a good tool makes better software. So for  for making a high-quality program uh you need you   need to be able to do these type checks quality  checks to do generate tests to do code coverage   and so on and so on. So he was working on the PHP  engine and language features few years actually a   few proposals and we actually the PHP community was  very helpful. Derek from XDBug helped us a lot on   internals. Many other people many people who were  actually first PHP customers were moving us to   conferences. We were talking about this language  revolution and actually helped us to secure the PHP   system to make the next version of PHP and to make it  uh uh both secure and performant and uh actually   tool-friendly. So you have nice experience  developing it. So it doesn't it even dying   now we have a little bit less of new projects but  it's a majority system and at that point actually  

uh was a thing in my career which switch me back  to analytics and how to make stuff useful because   before that all for all of that I told you I was  a good proxy of what will be ideal flow for a PHP   uh developer using a JetBrains IDE like a Java-like  experience and so on and so on so on but at   some at some point those uh easy projections uh  ended uh and uh it was smaller smaller smaller   smaller features and for those smaller features  you need much tighter progress you need to measure   uh user interaction you need to measure the  quality you need basically what what what   again what is now now everybody takes for granted  and it didn't we didn't measure everything we had   input from YouTrack uh community uh in Twitter  support and so on and so on from internal tests   of our performance team. Um yeah, and actually  we developed a per whole performance suit   during during that using TeamCity indicators and  PhpStorm inspections to be able to do continuous   performance improvement. This is also like a  whole idea of what Qodana should be doing. Yeah,   your work has touched every facet of this business  almost every product that is in JetBrains over   the last years. Yes. At that point I switched  to the internal analytics platform which now   touches every product which is now basically  like a basic if you introduce new product if   introduce a feature in your product you do uh um  analytics uh instrumentation there. So you will   able to see that your customers have touched uh  and how many customers touch how many continued  

usages how many churned and so on and so on. So  yeah, before that we were developing our like   a super complex John Deere like a type combine  and dropping it into the wilderness but we designed   optimized our combine to for example you know, pick  up dig out potatoes and then uh people used this   some some combiners to cut bananas from and  it didn't work good but with this real-time   analytics and so on we are able to first of get  this information about new usages and uh maybe   even sometime adopt so we have can have adoptive  strategy within the products and optimization   strategy. Uh during that period we also introduced  like weekly APs and uh more more releases. Uh it   was also very helpful for streamlining that uh  uh data that we use now to design and shape our   own products. Obviously we still have a lot of  insight being like uh doing this for 20 years   15 years many many people in the company we are  very have very good understanding what are the   hard part parts of the software development  pipeline. It's not even usually creating the   code it's like keeping it maintaining and so on  and uh right now with with AI creating is even   more easier but keeping maintaining it gets harder  which brings us closer to Qodana and modern stuff