Progress Or Perfection? Staying Quality-Focused as a Team Under PressureQodana Leadership Series: An interview with Vladislav Minaev and Konstantin Ulitin.Everyone from growth-mindset gurus to Agile die-hards talk about ways in which we can iterate as developers. Release an MVP, build as you go, minimize waste, maximize value to stay lean, and do it all while prioritizing user feedback.But as much merit as these principles have, what is the biggest price we pay for doing things quickly and in stages? Some research suggests code quality and maintainability in the long term suffers when teams deliver new iterations too quickly a sentiment thats echoed by software development author Martin Fowler.So, with this in mind, what does it take to find balance in a team that maintains one of the most popular IDEs in the world? We turned to Vlad (WebStorm Team Lead) and Konstantin (WebStorm Tech Lead) for some answers.In your experience, whats the biggest obstacle to defining code quality within a development team? How do you tailor this definition to the JavaScript community specifically?Vlad: Code quality is already subjective, and different devs have different backgrounds and personal preferences. Definitions of clean and quality can vary, especially from one ecosystem to another. In full-stack projects, where JavaScript parts are placed alongside the backend, developers have the ability to change code outside of their primary ecosystem. This can create friction, particularly when developers from the backend world start to engage in areas theyre less familiar with. This applies to frameworks as well.How have you seen subjective interpretations of good code lead to conflict or inefficiencies?One particular example is when code reviews turn heated because reviewers have different opinions on naming, architectural choices, etc. Feedback loops can sometimes become more about personal preference. This can take time and affect output and maintainability.Can you share an example of a time when different team members had significantly different ideas about what constituted high-quality code and how it impacted the project?Ive noticed that its not necessarily just about code coverage its a broader issue. In many cases, it comes down to code reviews and the different approaches to development. Each approach has its own strengths. One is very structured, involving detailed planning, feature design, and documentation. Its a more analytic method.The other is highly iterative, practical, and focused on implementing ideas quickly and adjusting on the fly. Rather than doing extensive upfront analysis, this approach favors immediate action. Theres no right or wrong here both can work well depending on the context.Sometimes, the structured approach pays off in the long run, especially when working with complex codebases that require collaboration between multiple developers. In these situations, a careful, well-documented process can be really beneficial. On the other hand, when it comes to building user-facing functionality, the choice between a documented versus agile process often depends on business needs. For example, in an MVP or startup environment, the main goal is usually to deliver results quickly especially when deadlines are tight or events are coming up. In these cases, speed can sometimes outweigh quality.That said, developers are often tightly aligned with business needs, and there are plenty of cases where skilled engineers, committed to code quality, find their priorities clashing with business demands. It really depends on the nature of the project. If youre working on something long-term that will need ongoing support and evolution, enforcing quality standards is definitely valuable. But if you expect to frequently revisit or rework the code, strict standards might not always be necessary.Vlad and Konstantin are from the WebStorm team a JavaScript and TypeScript IDE by JetBrains. How do you handle situations where strong opinions or ego get in the way of establishing consensus on code quality standards?I cant say that I have a silver bullet here, because as a manager, you cant simply fix people.The smarter approach is to try and harness their strengths. For example, if someone has a strong opinion, it might be helpful to assign them a specific part of the system or a dedicated project. That way, youre matching their personality to the project. But sometimes, tension is unavoidable. What we can do is try to spark discussions and facilitate open dialogue. We can also collaborate on common practices, like code reviews.For instance, we reviewed our code review practices with the WebStorm team. Konstantin can provide more technical details on that, but it was one of the artifacts.The discussion was intense. Its not simple. In real-life scenarios, you might have a strong tech lead who can enforce a clear vision, and if the rest of the team is aligned, its easy to agree on strict rules. But thats not always the case. In larger teams, youll often have several high-level, passionate developers who each have strong opinions, and those differences can lead to conflict. Connecting those people is a really tough process.Konstantin: In addition to what Vlad said, I think its important for developers to have some freedom in the specific areas of code theyre responsible for. Common code quality standards are needed because everyone is working on the same codebase and reading their colleagues code, but also its important to have a feeling of ownership. As everyone works on the same codebase together, they naturally find common ground regarding standards.Have you ever had to mediate a conflict related to code quality standards? If so, what approach did you take?Vlad: Its crucial as a team leader to provide a safe and comfortable environment for people to share their opinions, but sometimes these discussions can lead to tense dialogues, and we have definitely experienced this. As a tech leader, you should default to the technical agreements in your team rather than focusing on personal preference and sometimes speak to your team members in private. For example, you can have a separate conversation and use phrases like I really value your contribution and Thanks for a constructive and productive conversation sincerely, of course.A good example of this is applying overly strict code coverage and linting rules directly in the editor, which can be counterproductive. Pursuing exact code coverage numbers is often unnecessary and ineffective. I doubt there are exact numbers, as they vary related to the nature of the project. In some cases it leads to really weird constructions to test pieces of code, and people struggle and spend a lot of time doing that instead of moving forward with features. Being flexible on code coverage metrics is good because restrictions like 80 or 90 percent code coverage might not work well, and things like this need to be discussed.I guess thats also very tough. So one solution might be automated checks?In our case, the IntelliJ department says you cant push your changes into master if they dont pass zero tolerance inspections (provided by Qodana), which are Java inspections followed by a comprehensive suite of tests. So yes, that can be one solution.How important is documenting code quality standards, and whats the best way to make them accessible and understandable to the entire team?It depends on the project. If youre working together with one developer, its easy enough to just communicate verbally. But other situations might call for the opposite approach. Imagine a huge open-source project with a bunch of external contributors. In that case, its crucial to create some sort of contribution guide and to access project resources.How do you ensure that code quality standards are regularly reviewed and updated to reflect evolving project needs and best practices?In practice, code quality standards are often revisited reactively, typically after an issue arises. Its not something most teams schedule weekly or even annually. For open source projects, this often happens after the first few pull requests, when contributors submit code that doesnt meet unstated expectations. If quality checks arent automated through CI tools at that point, its a clear signal that they need to be introduced.If you anticipate a project will be long-running, its best to define and implement standards from the start. Experience plays a big role here. You start to recognize whats necessary early on.If I were to start a new project, especially in the open-source space, Id make a point to study similar projects. Id look at how their CI pipelines are structured, what tools they use (like Docker for isolation), and what quality gates theyve implemented. That research often inspires improvements I bring into my own projects. Its a continuous learning process driven both by necessity and by observing best practices in the wider development community.How do you tailor code quality standards to the specific context of a project or tech stack?The structure and architecture of a project play a significant role in shaping code quality standards. For example, in large monorepos or distributed systems composed of multiple microservices across separate repositories, integration testing often becomes more valuable than unit testing alone. You need to align your testing strategy and broader quality standards with the scale, structure, and operational requirements of the system.What works for a small library may not make sense for a large-scale, service-oriented architecture. Tailoring standards means considering not just the tech stack but also how the code fits into the overall architecture and deployment model.What code quality metrics do you find most valuable, and why?While metrics like cyclomatic complexity, maintainability index, and code coverage have their place, its important not to over-rely on any single one, especially code coverage. High coverage doesnt always mean high-quality tests.Static analysis tools are incredibly valuable because they catch issues early, often before code is even run. Even for small or personal projects, setting up basic static checks in a CI pipeline is worth the effort. Platforms like GitHub and GitLab make this easy, and these checks help enforce a consistent baseline of quality, especially when youre likely to forget to run them manually.In short, I prioritize metrics that contribute to early detection of issues and long-term maintainability, rather than just hitting arbitrary numerical targets.Qodana can help you prioritize code quality while you iterateThanks for reading this installment of the Qodana Leadership Series. Special thanks to Vladimir, Konstantin and the WebStorm team for their participation. Have questions? Drop them in the comment section below. You can also read another installment for more insider information on how todays team leads are tackling challenges.If youre looking to iterate without compromising on the quality of your products, try Qodana.Try QodanaNext upCheck out Leadership Strategies for Finding Quality Focused Developers.