Should Tech Support Engineers Code?
Here’s what Serge Baranov, JetBrains’ legendary tech support engineer, had to say to on the matter.
Hi Serge! Have you heard of Jony Ive, Apple’s chief design officer a.k.a “the man from the white room”? Every Apple press conference (WWDC) has a video with him, showing an empty all-white room. Some say Jony Ive is not a human but only an app. There’s a similar myth about you at JetBrains: people believe you’re not a real person but some advanced futuristic AI! I guess it’s because you work from home, invisible to your colleagues, and you respond to user requests almost 24/7, at lightning-fast speed. What’s your secret? How do you manage it?
Sorry to dispel that myth, but there’s no real secret. It’s true that I telecommute and rarely visit the office, so many of our colleagues have never met me in person. I do go to our company get-togethers though. A handful of our most seasoned colleagues saw me work in the office, but that was a long time ago, back in the early 2000s.
As for responding quickly, I do everything in my power to minimize the response times. I’m on weird working schedule: I put in a few hours in the morning, a few in the afternoon and some at night. That way I stretch my online availability and cover as many time zones as possible. I’m moderately active on weekends and holidays too. Usually I don’t go to sleep until all the requests are closed.
One member of Hacker News ventured a guess that they keep me locked up in a room somewhere. This idea caught on with the hashtag #keepsergecaptive.
Why have you worked from home for the last 12 years?
Our company’s offices have always been kind of far away – a one-hour commute each way or more. When I just started out, I would share rides with Sergey Zhukov (JetBrains IT Director) who lived nearby. He would pick me up and we’d ride to the office together, discussing work issues on the way. That was fun. But then the company started releasing more products, my workload increased, and the commutes began to overstrain my schedule. I began to work from home more. At first it was one day a week, then two, then three. Eventually I stopped coming to the office at all.
Don’t get me wrong though – the office is great. JetBrains has always offered lots of perks for its people – the atmosphere, the workplace and the food are awesome. I had a lot of fun hanging out with colleagues on tea breaks. But I still hated wasting time on the commutes. Plus, I naturally prefer working alone.
Tech support at JetBrains used to be set up in a way that I personally covered all of our IntelliJ-based products. I didn’t really need to be in touch with other support engineers. I would sometimes talk to developers, but not too often. I made sure to use email to avoid distracting them from work. In our first office, when there were only about 10 of us, we all sat in one big room and it was easy to come up to someone and ask them questions. But it still didn’t feel right to me; you take a developer out of their flow and then they spend a lot of time getting back into it. Later, when the office grew bigger and people moved into multiple rooms, we switched to electronic communications.
There are very few distractions when I work at home. I can listen to loud music, or use a noisy mechanical keyboard, without bothering anyone. I can take breaks at any time, do house chores as a distraction, pursue my hobbies, or just catch a nap. My productivity is a lot higher than it was in the office. But of course this may not apply to everyone, for various reasons.
Don’t you miss real human interaction now and then?
Sometimes, I guess. As an introvert I can comfortably go without seeing my colleagues for months. But sometimes I do miss being able to chat with someone about work and other stuff.
When you do come to the office or meet with colleagues at a corporate get-together, do you suddenly ask yourself, “Who are all these people?”?
Exactly! It’s been that way for a while. Our company has expanded a lot in the past few years. Even those who go to the office every day still don’t know everyone from every floor. We even have multiple locations in the same city (St. Petersburg). You know your teammates and maybe a few others, but people on most other teams are strangers. So I think this applies to quite a few folks at JetBrains, not just myself.
Good point, I agree. So, how long have you been doing tech support at JetBrains?
Since January 2002, so it’s been over 15 years.
Wow! It seems that nowadays people change careers a lot more often than they used to. They get bored with doing the same thing and look to shift direction. 15 years of tech support sounds impressive. Do you ever feel like trying your hand at something else? Or maybe discovering something new in your current role?
IntelliJ IDEA is a very complex piece of software that’s developing at a great speed. Every week there’s a new feature, support for a new language, or a new technology to play with. If you want to stay on top of all that, there’s no time left to think of anything else. I think it’s already more than one person can take in, understand and memorize. There’s never really a dull moment.
I’ve heard some tech support engineers at JetBrains have branched out into software development, just to get to know our products better. How do you manage to stay an expert on the product you provide support for?
I use JetBrains tools to develop my own applications. I have a couple of ongoing little projects. One is an Android app that I started when we just introduced Android support. It’s called ClockSync and it’s designed to synchronize time. It’s been downloaded over a million times on Google Play.
Fascinating! What other apps do you work on?
Another project of mine is written in Java using IntelliJ IDEA. Philips has this technology called Ambilight for creating light effects around your television. The colors match the video content on the screen, to create a more immersive visual experience. They also make Philips Hue light bulbs, with Android and iOS apps which can be used to synchronize these light bulbs with the Ambilight on your TV. Unfortunately, this setup is not very easy to use: you have to switch on your smartphone, put it on a charging dock and run the sync process there. So, every time you want to watch something with all those nifty lighting effects, you have to go through this whole lengthy setup.
I decided to try and automate this. I made my own app for syncing the light bulbs with Ambilight. The trick is, my app is not just for smartphones – it can work on any device that runs Java: your router, your server, your home PC, Raspberry PI, whatever. The biggest challenge was that the algorithm for converting the color displayed on your TV into the color of the lamp is proprietary. I managed to work around that by using pre-compiled classes from Philips’ Android app that implement that proprietary algorithm.
I also created a more user-friendly API. For example, you can automate things to the point where, when you turn on your TV and play a movie, the bulbs are synced automatically, but as soon as the movie is over, they return to normal. I also added some ‘smart home’ automation features so you can use your PC or another device to adjust the bulb settings quickly. It’s a pretty specialized app and not that popular. I mainly worked on it for my own needs, but eventually decided to open-source it. I run a Google+ support group for it where I respond to users’ questions. The app is called HAmbiSync.
How do you come up with ideas for apps like that? Do you look around for problems you want to solve, and then find a technology and a JetBrains tool to solve them? Or do you take a technology and then look for a problem to solve with it?
For me the problem comes first. Then I look at the tools we have and pick the one that’s best for the job. I also get to know the tool better along the way. For instance, I still have some Ruby scripts for my home automation stuff, and some Python stuff too.
There’s one other old project I don’t maintain any longer. I started it before joining JetBrains. It was written in C++, before JetBrains had an IDE for that, so I used Visual Studio. It’s an AMIP plugin that integrates with many audio players and lets you grab the title of the song that’s playing right now. You can then share this information (and other tags) with other applications, write it to a file, or send it to IRC (which used to be popular). You can also create a dynamic banner, a pic that shows what music is playing, whenever you access it. You can add this banner into your signature on a forum somewhere, or share it on ICQ or Skype for example. At some point I decided to create a user interface to tweak all the settings for this app. It was around that time that IntelliJ IDEA introduced a new GUI designer for Java, so I used it extensively for my app and came up with some pretty advanced settings. It helped me learn how it all worked.
I see you use the nickname ‘CrazyCoder’ on various websites. Do you think of yourself primarily as a developer, or a tech support engineer?
It’s been a really long time since I’ve coded professionally. It’s only a hobby for me, while tech support is my job and career. But I do still consider myself a programmer, too. It’s how I got started in IT, and I still do it for fun. Not only is it a great hobby but it also helps me do my job better. I think if you’re doing tech support for customers who are developers, you do need to be a bit of a developer yourself.
You talked about providing support for all of our IntelliJ-based products. That must be a huge stream of support requests! How do you prioritize them?
It’s pretty simple. Incoming requests are queued and I go through them, one by one. If I see a request with lots of exclamation marks, or one that says stuff like “everything is down, nothing is working!”, I try to handle it first. Other than that, I just process things as they come. I do my best to reply as quickly as possible to keep the backlog down. When I wake up and start working, I may have only about 15-20 new requests pending.
So how do you handle requests so quickly? Some customers must be sending you huge pieces of code, describing their problems in a lot of detail. Doesn’t that take a lot of time to figure out?
Yeah, when I get a complex issue that needs to be thoroughly investigated, I usually set it aside. I try to answer quick questions first, so people don’t have to wait, and only then dive into the complicated ones.
Actually, many of the questions duplicate earlier ones. Then I only have to identify the problem and quickly find a similar bug report in the tracker or a known fix.
I try to write succinctly and get to the point, without long introductions and flowery language. I also use a couple of utilities that speed things up a lot: AutoHotkey script templates, clipboard history with quick search via Ditto Clipboard, and ShareX for creating and uploading screenshots and short videos. Alerts, when set up in the right way, come in very handy as well. Thanks to all these tools, sometimes a new request comes in and I can start replying immediately. Some people are shocked when they get a response in mere seconds.
Do you have a “knowledge base” of issues and fixes? Or is it all in your head?
My “knowledge base” is the Internet and YouTrack. You can find most things there. First I look in YouTrack. If that doesn’t do it, I run a keyword search on the web. A lot of the time StackOverflow has the answer. And every now and then, I find a really good answer only to see I was the one who originally posted it! There are so many issues and questions that I can’t remember them all. Our minds are unable to retain everything they process. Sometimes I look through our database of tech support requests to check if my colleagues have encountered something similar before. The most frequently asked questions are added to the public Knowledge Base. I also use AutoHotkey script templates: I type in an abbreviation and it expands into a bigger piece of text (similar to Live Templates in IntelliJ IDEA), such as links to web resources or boilerplate phrases used in my responses.
All customers are different. Some will thank you for answering their questions, while others are very negative in their complaints. Do you have a recipe for setting your emotions aside and providing a courteous, helpful and relevant response?
It was difficult for me in the beginning, but now I’ve learned to not let it bother me. Yes, some people are unhappy and even angry. The key is to put myself in the customer’s shoes and imagine how I would react. For example, I’m under a tight deadline and the software is not doing what it’s supposed to. I’m running out of time and I just need to get it to work! This helps me relate to the customer’s situation and assist them better.
Are there any customer requests that stand out to you in particular?
I remember an email from a 75-year old lady who started using RubyMine to learn Ruby on Rails. Right off the boat! She had not programmed for many years; the last technology she’d worked with before RubyMine was punch cards! It must have been quite a change, going from punch cards to advanced client/server applications. She had a ton of questions and was missing some basic concepts of how that stuff worked. I enjoyed talking with her, explaining the ABCs of it, and setting up the IDE and the environment for her.
Let’s go back 15 years. How did you get into tech support to begin with?
I was still in my fourth year at university when I decided to get a real job. I had some small jobs before that but nothing steady. I logged on to job.ru and went through all the jobs they had that I could do. Got some responses and went to a few interviews to see what they were offering. I didn’t look for tech support jobs specifically; they had more to do with software development, mostly web technologies, as I had studied PHP, Perl, HTML, CSS and so on, and some entry-level jobs in C and C++. That’s when I came across a job that was called “Java User Support.” It didn’t have a bigger description – just that title and nothing else. I sort of knew Java, I was starting to learn the language and I liked it. “User Support” sounded like I would need to help people do stuff. At that time I was already maintaining a popular plugin and a forum where I helped my users. I thought to myself, “I guess I could do support,” so I went to the interview. It was a recruitment firm hiring for JetBrains (the company didn’t have its own HR department back then). The interview went well and they invited me to the JetBrains office. We had a talk there, and as soon as I got home, I got a call with an offer.
So you didn’t mind that it was tech support? You just wanted to do something in IT that wasn’t necessarily software development?
Right. I didn’t make a difference between coding and talking to users. They told me what the product was, that it was a Java IDE, and I was interested in learning it, figuring out how it all works and writing my apps in it. It combined coding as a hobby with a job in IT, for a young and promising startup where I could learn a lot and improve my knowledge of software development technologies like VCS, Refactorings, and Unit Tests, and methodologies like Scrum and pair programming. All of that was new and exciting for me.
Have you thought about going back to full-time development over the past 15 years?
It’s only a hobby for me; I can’t see myself doing full-time coding for money. I think I would be pretty stressed out if I had to constantly fix bugs from the bug tracker, with more and more piling up every day.
Isn’t tech support a stressful activity too?
Support is different because all the requests I get can be resolved and closed. When you’re in software development—and I think this applies not just to JetBrains but to most companies—your backlog of requests to process only grows bigger. It puts you under a lot of pressure; at least it would for me.
Another thing is that a developer may have to spend a whole month coding a boring and routine software feature, or try to localize a bug for a week or more. Tech support offers more variety. It’s also important for me to see the fruits of my work immediately, like grateful customers and problems I helped them solve. Whereas a developer may spend months working on internal software improvements that no users will ever notice.
Aren’t there situations where you can’t help the customer? Sometimes your discussion just ends up as a new bug report in the tracker, doesn’t it?
That’s true. If a workaround exists, even if it’s just a crutch, I will offer it to the customer to make their life easier until our developers fix the error. But if I see that an issue is critical for many customers, I will contact the developers directly and try to get them to fix it ASAP. Prioritizing issues like that is an important part of my job too. Developers may not be aware of the fact that some issue is a show-stopper for many of our users, but I do, so I let them know about it.
Do you ever feel like going inside the code and fixing stuff yourself?
Sometimes. I’ve done it a few times. If I can locate the offending place in code on my own, I point it out to the developers. That’s if my level of understanding is enough to get a grasp on the issue. Some issues are pretty tricky so that even experienced developers don’t know what subsystem to look in. With allocated responsibilities, no single developer is probably able to locate and fix any given issue. I guess everyone should do what they’re best at.
Thanks for the interview, Serge! I hope you keep coming up with great new ideas for your apps, get more peaceful customers as you do tech support, and have fun at JetBrains!
Serge Baranov was interviewed by Anastasia Kazakova, Product Marketing Manager for CLion at JetBrains
