I believe meetups and conferences are particularly great for one reason: live collaboration and discussions. I enjoy organizing meetups and seeing how ideas are perceived by people, learning what problems and difficulties they have and how they approach them.
Each meetup has just three talks that last no more than 90 minutes. Afterwards, we dedicate just as much time to conversations with attendees.
This time, a major topic of discussion was the cultural issue companies have with quality. How can we explain the importance of prioritizing quality? How can we persuade them to implement a zero-bug policy? How can we avoid bug reporting getting stuck in Jira forever?
It also appears that the “overengineering” problem is as pressing as it was 20 years ago when I was starting my developer career. People are still struggling to find the perfect balance between quick and dirty solutions which might cause long-term risks and spending too much time on building something which is too complex for the problem at hand.
Let the tools worry — Be happy
Theodor Port of JetBrains Qodana kicked us off with his talk about code static analysis and his passion for improving code and productivity.
“Bad code really hurts, I think we all know that. When you first open the code base in a new project and you're filled with a sense of dread and anxiety, it’s not a nice feeling. I wanted to join a project that tries to make the code in the world a little bit better.”
History of code static analysis predates computers. Scientists like Turing were trying to come up with a way to check the program correctness before the program runs. The reason for the effort is simple: we want to check as early as possible to see if the code we write contains defects so that we can prevent possible defects from reaching the users.
Almost 90 years later, programmers employ various static analysis approaches, and in this talk Theodor covers most of them. To me, the most interesting part is the social, human part: when our IDE highlights the errors we make, it is a neutral, objective process that is less likely to trigger defensive reactions because it lacks the social, emotional, and ego-related factors that can arise in human interactions. I fully agree with Theodor’s point that if you have some agreement among the team on code style or other subjective matters, it’s better to encode them as custom rules for the static analysis tool. This usually reduces irritation or conflict within the team.
Beyond Testing: QA as a Product Manager?
Next, we had a talk by Uliana Federova of Talent Inc, an all-in-one-platform to make the best of your career.
In her talk, Uliana explained an essential aspect of QA: proper quality requires a shared understanding of the context between developers, QA, and product managers.
“When you have context, a broader understanding of the company and user problems, you can better prioritize your work and save time. Work involves a lot of decisions. With proper context, Developers and QAs can be more authoritative and make decisions faster.”
I agree with Uliana: the only way to properly understand others is to collaborate with them. If QAs and devs at least occasionally “wear the hat” of a product manager and talk to the users, they will gain a better understanding of the problems users have and how the product manager thinks these problems should be solved. This will save development and testing time and improve quality while making engineers happier because they will see the impact of their contributions — the things they work on help real people.
QA and Product Management: Turning Failures into Success
Dmitry Suholet and I partnered for our talk about what a product management failure can teach us about the collaboration between QA, developers, and product managers.
“Not even 70% of product hypotheses are properly validated…that’s why I believe it’s so important to have these discussions with more team members even at the hypothesis formulation stage so that they will be more scrutinized”
I believe that quality starts much earlier than development, and much, much earlier than any testing. It starts when the problem is formulated and when the hypotheses of solutions are devised. Unfortunately, engineers are rarely invited to these stages. In this interactive talk based on the real story of Dmitry’s project failure, Dmitry and I worked with the audience together on coming up with solutions for the business problem Dmitry had, brainstormed various solutions, and saw how every member of the product team could contribute to the quality from the very start.
Join us for a future meetup!
I love doing meetups. People’s curiosity and eagerness to collaborate not only amazes me, but also makes me happier: I know I’m not alone in the pursuit of quality!
Follow our Berlin meetups page to be the first to find out about future events around Berlin and follow us on Linkedin to hear about meetups throughout Europe!
