Interview with Sergey Coox, the .NET Department Lead at JetBrains
Anastasia Kazakova, our Product Marketing Manager for C++ tools, talks with Sergey Coox about controlled chaos, internal competition, and keeping 90 colleagues happy at work.
Q: Hi Sergey! You lead the .NET Department at JetBrains. How big is your department and what products does it work on?
According to the latest ‘census,’ we’re 90-strong. We work on ReSharper – our Visual Studio extension for .NET, the second oldest JetBrains tool after IntelliJ IDEA; Rider – an up-and-coming cross-platform .NET IDE; a family of profilers including dotTrace and dotMemory; dotCover for analyzing code coverage; dotPeek – a decompiler for .NET apps; and finally, ReSharper C++ – a Visual Studio extension for coding in C++. That’s about it.
Q: Sounds like a lot! As the Department Lead, what does your job entail?
Making sure that everything works! There are many different people who need to talk with each other and reach a common understanding. That’s what I help them do. Of course, the ideal situation is when the whole system manages itself.
Q: Any success with that?
To a degree, yes.
Q: Recently you joined the JetBrains Open Day in Moscow with a talk entitled “A Minimum of Processes is a Process, Too.” Is this approach unique to JetBrains or our .NET Department?
That is a very specific management style which I like and which suits me the most. Talking about JetBrains as a whole, there are lots of different management styles at work, some teams adopt agile techniques and play them by the book, others prefer more of a total control style, or there is the kind of controlled chaos that we have in .NET.
Q: If I’m catching your drift, your idea of an ideal process is one that fits all the team members best, isn’t it?
Yes, with one important correction: one that fits the team AND delivers good results. If the team is happy but takes years to roll out a major product release, that’s no good.
Q: You mentioned “controlled chaos.” How does one control chaos anyway?
You need to create an environment where people are genuinely interested and invested in what they do. If that’s in place, if people enjoy their work, then as a manager you simply steer them in the right direction. Of course, we need a competent QA team too, to keep ourselves honest. Plus you need some technical solutions like our merge bot that acts as a last line of defense. (It prevents direct commits to the master; we code only in branches, while the bot uses our CI server to merge the master into each developer’s branch, runs tests, and only if everything checks out does it upload the developer’s changes back to the master.)
Q: Do you use special hiring strategies, to manage a team that way?
Yep. Not everyone can fit in a team like that.
Q: Being the department lead, do you keep a close check on recruiting and hiring?
I’ve been involved in making hiring decisions for ReSharper for years. The ReSharper C++ team is more independent in that regard. The Rider team grew out of ReSharper, so in a way they have it easy when it comes to hiring. As for our profiler teams, they aren’t growing much except that we may be looking for one or two people to help with dotCover and the profiler core.
Q: Do you believe being a competent and well-regarded developer is enough to become a department lead at JetBrains? Or does it take more skills and qualities than that?
You need to talk with people, understand who is doing what and the attitudes which are prevalent in the teams. I spend a lot of time talking with my teammates in the office, just to keep abreast of things. I don’t get to communicate with my remote colleagues quite as much, but I’m working on it because I don’t want them to feel left out.
Q: As a manager, do you ever get to code anymore?
I do, I just committed two branches to the master this weekend. But of course I don’t get to code as much as I used to. There’s so much going on lately that I’m not as keen about coding anymore.
Recently I’ve been focusing on making sure I don’t have many release-critical tasks assigned to me in our issue tracker – if only because I can’t guarantee I can devote enough time to resolving them. That’s why I usually try to code at the beginning of our release cycle, if ever. For example, I’ve just refactored a good chunk of our code to prepare for ReSharper out-of-process (extracting ReSharper functionality into a separate process from the 32-bit Visual Studio process in order to boost the extension’s performance).
Q: Let’s go back a little. What did you do before JetBrains?
I graduated from the Mathematics and Mechanics Faculty of the St. Petersburg State University, like many other JetBrainers have. As was customary, I started out at Lanit-Tercom (a company closely affiliated with the university department that accepts many of its students as interns), working on a cross-translator from COBOL and PL/I to C++, Java and Visual Basic.
Q: How did you end up in .NET?
After Lanit-Tercom, I went to work for Memory Corporation, where some of my coworkers left for JetBrains and invited me along. When I got there, they said “We’re going to be using C#.” I had never coded in C# prior to JetBrains. So I joined JetBrains for the interesting challenges they had to offer; the choice of language was secondary.
Q: When was that?
I joined the ReSharper team in 2004, almost 14 years ago. Back then I think we were working on ReSharper 1.5 or maybe 1.65. The product has certainly undergone a lot of changes since then.
Q: Wow, that’s a long history! Do you think you’ve implemented most of the functionality you could by now? Or maybe there are things you’d still like to add to ReSharper?
The biggest thing we’re looking forward to adding is ReSharper out-of-process, which should make it perform faster. As far as unique features, I think we’ve already covered most of those. Our most recent triumph was bringing debugging inside the editor, but even that probably wasn’t game-changing.
Q: How does ReSharper get new features anyway? Do you look at what Visual Studio is doing, other extensions for VS, or just come up with your own ideas?
Most of the time, new features arise from our own need, since we use ReSharper to develop ReSharper. What I love the most is when someone comes to our stand-up meeting on Monday and says, “I got this great idea over the weekend and coded it, check it out!”, and then it just comes through. Then, of course, there are situations when someone starts out with a hack which is then gradually polished into a real gem.
Q: Do these kinds of enhancements account for a large percentage of all the features your teams create? I mean if we compare this to the capabilities that our users can enjoy in Visual Studio but would appreciate an improvement in Rider or ReSharper.
We don’t imitate Visual Studio; we look at how they do things and we endeavor to do it better. Well, in the case of Rider we do still implement features that developers have become used to having in other tools, e.g. Visual Studio. If someone’s using Visual Studio with ReSharper, they can still revert to VS’ native features, but if they switch to Rider, a standalone product, they can’t, so we try to accommodate those users.
Here’s an example. There’s a tool called CodeLens that shows you how many times each method is used in your project. I don’t get why this is so essential, but our users have been asking for this feature for a while. I suppose it’s not the precise numbers that people are interested in, but rather knowing if it’s “none”, “a few” or “a lot.”. We’re working on making this available in Rider.
Q: Talking about Rider, how are you doing with implementing Visual Studio features? In a lot of ways you’re a direct competitor, so there must be a lot of people asking you to add the same features.
We do look at how things are done in Visual Studio, but we do not try to copy its capabilities. We try to take it into account and, well, do better.
Q: OK, then let me ask you a tough question. How much of Rider’s functionality is your take on Visual Studio features, and how much is your team’s unique vision for the product?
That’s a good question. Rider is still young. Most of its functionality is inherited from ReSharper, and this process is ongoing. Even now, Rider is still getting some of the refactorings from ReSharper (rewriting those for the cross-platform engine was quite a challenge, let me tell you). And then there are things we’re doing that people ask for, like CodeLens, supporting Roslyn analyzers and so on.
Q: It looks like the Rider team has their work cut out for them! You need to both add new features and implement the things that people are used to from Visual Studio, whereas in ReSharper (a VS extension), you only had to worry about the former.
True enough, and the team are stoked about it! Things are pretty straightforward. First we cover the basic functionality, for example, the debugger. An IDE without a debugger is useless, so we need to have one. Then, we start adding bells and whistles on top of that. For example, Visual Studio has the Exceptions Dialog Box, which is very useful but not too user-friendly. In Rider, we’ve created a similar feature but made it way more intuitive.
Q: How did you come up with the idea of Rider, that is, launching a standalone .NET IDE? After developing an extension to Visual Studio for years?
Believe it or not, when I joined JetBrains back in 2004, it was to develop a standalone C# IDE. But I’ll be honest; I did not put much trust in the project back then.
Q: What has changed?
The technology landscape. Plus, there’s actually a market for this kind of product now. Before, it made little sense to create a C# IDE that would only run on Windows and compete directly with Visual Studio, without matching it feature for feature. We also had little in the way of UI expertise back in 2004. All in all, we stood no chance. But by 2014 or 2015 it was a different story.
Q: What made you believe in this product idea?
Things just started coming together. I saw a tool shaping up that was usable and even cool from a developer’s standpoint.
Q: When you say there’s now a market, are you talking about cross-platform .NET development?
Exactly. It simply didn’t exist until Microsoft started developing its cross-platform .NET Core. C# developers who liked their Macs and had to use Parallels or BootCamp were finally spared the hassle.
Q: So, considering that Rider only came about because its future competitor had spawned a new market, how’s the product doing?
It’s even more ironic than that. Rider is to some extent competing with its own parent, ReSharper. Competing against Microsoft is an exciting challenge. They are clearly dominating the market right now, but we have the chance to do some things better and to innovate, with a vibrant and rapidly developing product like ours.
Q: Internal competition sounds entertaining enough. As you manage the .NET department, which includes both Rider and ReSharper, how do you balance the efforts and ensure both products keep evolving?
It was really tough at the beginning, with a lot of competition for shared people. Folks would get absorbed in the brand new toys and say, “Hey, I’ve got a gazillion things to do for Rider, I haven’t got time to work on releasing ReSharper.” We had a lot of debates over this. Eventually we squared everything away and came up with a people-sharing arrangement that works for everyone. There is no competition to speak of anymore, and we’re all in the same boat. I don’t mind either way which product a customer buys, as long as they buy something. Of course if they buy Rider + ReSharper Ultimate, that’s the cherry on the cake :)
Q: Your teams do share some codebases, don’t they?
Yes, we share a lot of code. We’ve also synced the release cycles of both products. We roll out new versions of Rider and ReSharper from the same codebase so our users get the same features and enhancements. So you could say we’re not several teams, but actually one big team that works on multiple products at the same time.
Q: Do you get involved in anything else at JetBrains, in addition to the .NET tools?
Not right now. I contributed to redesigning our CRM solution in 2014. I was getting a little bored around that time. Max (Maxim Shafirov, JetBrains CEO) came to me and said “Let’s code this in Kotlin!”. If it were Java, I would have turned his offer down, but Kotlin was brand new and very exciting. New task, new language, new paradigm. I had never coded for the web before. It was a worthwhile experience. Front-end development isn’t my thing, but coding the back-end was really cool.
Q: If you’re eager to respond to new challenges and ideas, have you thought of maybe leaving this management gig behind and starting up your own new and innovative project within JetBrains?
Well, I can hardly invent something new, I’m more about making it happen once invented :) Running a big department like this is new and challenging enough for me, for now. I think it’s been working out pretty well, but let’s see how it all pans out.
Good luck with that, Sergey! It was great talking with you!
