“A good day is when there’s some tangible result at the end when you’ve completed a task or a part of it”: An interview with Olga Berdnikova, a UI/UX designer at JetBrains.

One rule for a good interview is: ask the questions you’re interested in. Anna Gasparyan, the Team Lead for the IntelliJ IDEA Technical Writing team, asked Olga Berdnikova about everything she wanted to know about UX design and the specifics of the job.

Olga Berdnikova, UI/UX designer at JetBrains

First of all, let’s sort out the terminology. I’m talking about the roles of a UX architect and a UI designer. As I see it, UX design is mostly to do with analytics and research, while UI design is about visual design. Is there actually any difference between the two, and which of them are you?

For me, there’s no real difference between a designer and a UX architect. In my experience, any attempt to divide these roles will lead to problems. Let’s imagine that a UX architect develops a wireframe with blocks and arrows, and then a UI designer gives color to these blocks, adds shadows and gradients, and the result is cool. In fact, most probably, the result won’t be cool, as this coloring stuff also implies UX. For a good visual representation you need to also understand the users’ habits, and how to draw the users’ attention to a control and help them quickly perform their tasks and navigate the UI.

So these are both stages of the same process?

Yes, I believe they shouldn’t be divided, the skillset is not that different. As I see it, a UI designer must work with the users’ problems and requirements, and, as a result, deliver a mockup that is ready to be implemented by developers.

Kotlin Developer Advocate Eugene Petrenko talked with Maria Antropova, Head of the JetBrains Marketing Research department, about her work, her team, their current tasks, and future plans.

Your team has been around for quite a while. How did you start out and what kinds of research do you do?

It was back in 2012, when I came to the ReSharper team as an analyst. As more analysts joined me over time, we formed a team as part of the Marketing department. We started with product surveys, market research, and sales analysis—small-scale tasks that addressed our colleagues’ ad hoc requests at the time.

Today, the Research team is involved in not only traditional marketing research, which mostly includes surveys and analysis of open-source information. We also conduct pricing research, design user personas, analyze the popularity of various technologies, do UX research, and build statistical models. Another area of focus for our team is serving as a kind of middleman between our colleagues and the internal statistical systems at JetBrains. Upon request, we export and analyze data from a variety of internal and external sources.

Projects

So the final entry of this project, is, in fact, going to talk about projects. Starting a project for yourself to try and use all your new found programming knowledge is the perfect way to push yourself to learn and practice the skills. Anyone who is going for a job as a programmer will need some kind of portfolio of demonstrable skills to show off to their new potential employer too so there really is no drawback to having a couple of completed projects under your belt.Continue reading →

Crafting tools and making them better is human nature. JetBrains has built its business on this tradition, by creating tools which developers love using daily and which automate the routine parts of their jobs.

Almost 2 years ago, we shared a story of how we create artwork at JetBrains, along with a cool and geeky tool you could play with to create your own JetBrains-styled art.

Today we want to reveal the progress we’ve made in advancing our generative approach to creating artwork, and give everyone a new version of the tool! We’ve kept at it since 2017 and our techniques have gotten better, our graphics more vivid, and the process even easier.

We’re now up to 22 products. Multiply that by two to three major releases a year for each, and you’ll get an idea of how many different images we are churning out. With this kind of workload, the more automation you have, the better. And just as with tools that help you format your code to a certain style (they are called IDEs, I believe), automated artwork tools can also help you standardize your images with clear unified visual boundaries.

In this version, the tool doesn’t give static images, but an animation. You can grab any of its frames as an image or save the whole animation as HTML5!

The UI is quite different now but still offers a ton of options and should be easy to grasp.

You can choose from a predefined list of product-styled presets.

Each artwork consists of 3 layers, any of which can be configured separately or removed altogether.

You can stop the animation at any moment; just click anywhere on the screen and hide controls with the Space key.

Still frames can be saved as PNGs and animation as HTML5. Make sure to choose the right size.

Don’t miss the ‘I feel lucky’ button which is great for exploring the whole variety of different graphics you can create.

You may wonder why is HTML5 needed. We’re working on a way to allow creating custom screensavers and will announce it later. Stay tuned! But you can already use it for a nice endless animation in the browser.

Under the hood

For the curious (we had a feeling you’d like to know more), here’s how it’s done this time.

The UI is built on top of dat.gui. But, we’ve noticed that the generated animation looks like something from a Sci-Fi movie intro, so we developed an alternative UI (in Elm, as well) for anyone who wants to feel like they’re in a spaceship. Try it out — https://code2art.jetbrains.com/#tron!

In the eight years Natalia Chisler has been with JetBrains, the number of staff has exploded from 120 to over 800 working across 6 distributed offices. JetBrains software is used by millions of developers worldwide, and many of them dream of joining a JetBrains team to help improve the professional tools for themselves and their peers. So what does it take to become a part of JetBrains? Do you even stand a chance if you’re not a Senior Developer? Read our interview with Natalia for answers to these and other questions.

Photo by Alexander Nefedov

Today, all new hires go through the HR department before they join JetBrains. How did it work when you applied, and what is your background?

Well, most people around me are involved in programming in one way or another, including my parents, husband, son, and many of my friends. I went to the Physics and Mathematics Lyceum 239 in St. Petersburg, where I realized that even though I would not specialize in math or computer science, my life would still continue to revolve around people who do.

I liked working with people so I studied Human Resources at university. These two things, HR plus IT, turned out to be a good combination. Back in the early 2000s, the IT recruiting scene in Russia was just coming into its developing stages, so I was lucky to have been a part of really challenging large-scale projects for IT companies.

7 years later, I was invited to join the HR department of a British IT company. That’s where I met Andrey Ivanov, who later introduced me to JetBrains. That’s how this chapter ended… and then my story really began.

The Journey of One Thousand Lines of Code.

So that about wraps it up then. It has been quite an adventure discovering the world of computer programming and learning a new skill which I can take on into the future. I am sure that there are parts I could have done better and more efficiently, and I have a whole new respect for dedicated learners who are trying to change their paths in life by learning new skills outside their comfort zone. It is hard, it takes incredible discipline (which has been one of the biggest problems I have had) to dedicate your free time every day to the pursuit of something that will pay off for years to come.

It’s a trap

There are a lot of things to distract you from the goal of learning any new skill. The thing you have to remember is everything is a choice and a decision. If you decide to go on Facebook the whole night, then this is your choice. How you spend your time is your choice, there are some decisions you can make which can have a much better pay off than others and this is what you need to keep in mind. If you are going to do this, it is up to you. Distractions are going to come up, it is how you deal with them that will be the difference between success and failure.Continue reading →

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.Continue reading →

Behind every JetBrains product, there are numerous teams: developers, product marketing (PMM), technical writers, designers and many others. Each team has established their own workflows to match their goals, working habits, and the team profile. In an earlier post, we described how the YouTrack team had been cooking Scrum and had managed to transform this methodology to find the most balanced approach that works for them.

Today, we will tell you how other JetBrains teams organize their processes, customize their Agile boards to meet the team’s needs, and what strategies can be useful to become a real chef at the Agile kitchen.

Design Team

The JetBrains Design team creates all kinds of visual content for each of the 23 company products: their designs enhance our web pages, marketing materials, and printed matter.
The designers receive most of their assignments from the product marketing managers (PMMs) who often need them ready as soon as yesterday. Such a fast-paced process requires effective monitoring of new tasks and balanced distribution of them within the team.

Six years ago, the YouTrack team started developing an Agile board in YouTrack (our issue tracker and agile project management tool). At JetBrains, dogfooding is one of the key principles of product development. So while building a tool for our customers that conformed to the main principles of an agile framework, we knew we had to experience Agile firsthand. That’s when we decided to adopt Scrum.

That was our first attempt towards the world of Agile practices. Unfortunately, after a couple of years (when our Agile board was released), we dropped our Scrum practices for a while. In 2016, we introduced a reincarnation of our Scrum, this time pursuing completely different goals:

Switch to Continuous Delivery

Speed up the development process

Improve code quality

Improve product vision sharing within the team

We had tried various practices, made compromises, and even had to break some of the Scrum rules before we discovered the most balanced approach that worked for us.

Unconventional Scrum Team

In a perfect Scrum world, the team is relatively small and people are collocated. That makes our Scrum team less than perfect. We’re 27 people distributed between two JetBrains offices, in St. Petersburg, Russia, and Munich, Germany.

Being so big, we didn’t want our Scrum meetings to distract us from working on the product. That’s why we strictly limited the time we budget for our Scrum activities down to a total of 6 hours per two-week sprint. Of course, we heavily rely on video conferencing and make use of real-time team collaboration tools like Slack.

Scrum Roles

To launch our Scrum transformation, we had to define who would take on each of the core Scrum roles.

Product Owner

In YouTrack, the Product Owner role is taken by the Team Lead who is responsible for developing and sharing the product vision with the team. The Team Lead is the person with the ‘big picture’ in his head and the one to ensure that our product goals meet the needs of our customers, while the team searches for the best technical solutions to achieve these goals.

Scrum Master

The whole process is driven by the Scrum Master, a developer from the YouTrack team who is in charge of presenting user stories during planning, breaking them down into separate tasks, and tracking their implementation during sprints. The Scrum Master continuously monitors the progress and makes sure everyone follows the rules we agreed on. However, the real magic that our Scrum Master does is keeping the balance between the new features we are passionate about and the mundane things that we need to maintain and polish continuously. It’s like rope-walking in front of a cheering crowd.

Product Backlog

In our case, the product backlog is a set of features that we plan to implement in YouTrack. At least once a year, the team get together for a comprehensive planning session where we discuss our major goals and product vision. As a result, we create a list of the main directions to focus on and define their priorities. We also determine the minimum set of functionality we need to develop to share it with our customers as an early preview so that we can get feedback as soon as possible and tweak new features on the fly.

Based on this list, we create a set of issues in our product backlog. We keep our backlog in a separate project in YouTrack, which is visible only to JetBrains colleagues. We link our user stories from the backlog to the feature requests and bugs reported in our public project. We also synchronize the status of each public feature request based on the appropriate status of our user stories in the backlog. This way, we keep our process transparent to our customers. We continuously fine-tune our backlog, reordering user stories as they become more or less critical. This way we try to keep the balance between our product development strategy, fresh ideas, and the never-ending but essential maintenance process.

Sprint Backlog

Before the beginning of a new sprint, our Scrum Master and Product Owner review the top items in our product backlog and choose user stories for the sprint backlog. Our sprint backlog doesn’t always have to include the top user stories from the product backlog: the Scrum Master is mindful of balancing the new shiny features, improvements to existing functionality, and maintenance.

#NoEstimates Approach

Having followed the Scrum principles for a while, we have figured out the natural pace for our team and now have a good feel for the number of user stories we can complete in one sprint. Therefore, about two years ago, we introduced the #NoEstimates approach to our Scrum process. The main concept behind this approach is that our sprint goal is to deliver a set of user stories from the sprint backlog, regardless of how many tasks we need to tackle to achieve this goal. We track our sprint progress based on the number of user stories completed. Here is an example of our sprint Burndown chart:

This approach allows us to spend less time estimating user stories and calculating the burndown. We’ve also added a simple rule that helps us benefit from this approach: No task may take longer than three days to complete. If it does, it must be split into smaller units of work.

Scrum Sprint Planning

Every two-week sprint starts with a planning session. We get the whole team together, including QA Engineers, UX Designers, Support Engineers, Technical Writers, and Marketing Managers, to discuss the user stories that we want to tackle in the upcoming sprint.

The planning session takes typically from 60 to 90 minutes. The Scrum Master introduces each user story chosen for the sprint, and the discussion begins. Our planning session is divided into two parts: general and technical. The general part is devoted to discussing the business scope and requires the presence of all the team members.
Next, in the technical part, the developers discuss technical details and split the user stories into tasks. This part is obligatory only for developers and QA engineers. We firmly believe that these regular sessions help the whole team stay on the same page and focus on what’s important to everyone.

Scrum Sprint

When the planning session is over, the Scrum Master adds the planned user stories from the backlog to the sprint board and creates the appropriate tasks for each story. Everyone is free to take an open task from the uppermost swimlane if possible and start working on it.

At the top of the board, we add critical bugs and tasks we consider important to accomplish during the sprint. This swimlane helps us keep an eye on important activities that are not related to any user stories.

We have two swimlanes dedicated to customer support activities for every sprint. Critical problems are added to the uppermost swimlane, while common and major support issues go to the support swimlane at the bottom of the board. If we don’t resolve these issues during the current sprint, we move them to the top swimlane in the next sprint.

Scrum Sprint Demo

One of the major Scrum principles is the idea of transparency. All team members involved should be aware of what everyone else is working on, progress being made, and what the team is trying to accomplish. Sprint Demo and Sprint Retrospective are excellent tools for that.

The Sprint Demo, held at the end of every sprint, is one of the most exciting Scrum activities for our team, as every presenter enjoys their moment in the spotlight supported by the teammates. During the demo, the author of a user story demonstrates various usage scenarios on a large shared screen and explains how the new functionality works. Discussion and feedback are encouraged. In the end, the presenter receives a hero’s welcome and joins the audience to give the floor to the next author.

The Sprint Retrospective takes place after the Sprint Demo, normally on Friday. This one-hour session helps us get feedback about the completed Sprint and collect ideas for the ‘small cool feature’ for the next sprint.

By collecting, prioritizing, and discussing feedback from each member of the team, we continue with activities that have a positive impact and eliminate negative behaviors.

We also vote for the new features suggested and define the winner. We discuss this suggestion, and if we find it useful, we schedule it for one of the upcoming sprint.

The Bottom Line

All in all, adopting Scrum has helped us increase our team’s performance. The team is always delivering a functional part of the product at the end of one Scrum iteration, and everybody gets in the habit of finishing things up. This feeling of achievement keeps everybody motivated. It’s easier to estimate the effort needed for the tasks, and the whole team can address issues immediately whenever they arise.

What we have achieved with Scrum:

We’ve decreased the number of critical bugs form 792 in 2015 to 123 in 2017.

Shorter release cycles: we rolled out 4 major releases in 2017.

Team members have a better understanding of the current product state and are more engaged in the overall product development.

Tips and Tricks

We’ve been following several principles to find our own secret ingredient in the variety of the Agile cuisine:

We set the rules and agree to follow them.

Each team member owns their work and feels responsible for creating a great product.

Self-management is an essential part of our process.

Processes require continuous tuning, as there is no endpoint on this path.

Tools should be customizable enough to fit your process, not the other way around.

For us, Scrum has become a foundation rather than a big strict plan that we have to follow. We’ve found that that experimenting with workflows, finding out how to combine different strategies to progress more efficiently, and continuously working on new setups are all keys to improving our daily work life and being agile in our own way.
To get a fuller picture of our Scrum transformation, read this series of related posts on the YouTrack blog.

Adaptive Python

Now comes the really fun part, putting all the things that have been learned over the past 5 months into practice. It should be a nice final finish to the process of learning how to program as we can see what we know and test out what we have learned, but also see where there are still gaps in our knowledge which we can work on in the future. My final challenge then is to take the Adaptive Python Course which runs with PyCharm Edu and the online learning platform Stepik and finish up my quest on learning to program to the level I set out to achieve. The platform has a few different courses available for different programming languages like Kotlin and Java, but we are getting right back to what we came here for, Python.