Annelore Egger
Software Engineer, OpenValue Switzerland
Brugg, Switzerland
Actions
Annelore is a passionate software developer from Switzerland who values high-quality code, likes working in teams, and sharing her knowledge. She also likes to meet new people, so if you see her around, feel free to say hi!
Links
Badges
Area of Expertise
Topics
Why Bad Code Quality Is Not (Only) Your Fault
Code quality is often seen as the developer's responsibility, but the reality is that many roles influence the quality of code—starting with business decisions. In this talk, I will share a real-world example where simplifying redundant business rules, identified by a business analyst, led to cleaner, more maintainable code. We will dive into how collaboration between developers, business analysts, product managers, and other stakeholders can shape code quality from the ground up.
By understanding how business logic, requirements, and communication impact the codebase, teams can avoid unnecessary complexity and create software that is simpler to maintain and scale. Whether you are a developer, product manager, or analyst, you will leave with a new perspective on how your role plays a part in building high-quality software.
If you have ever thought code quality is solely a developer's problem, this talk will show you how it truly is a shared responsibility.
In a past project I was approached by the business analyst of our team to some changes in a story I was doing a refinement for. He showed me that he had found some duplications that were unnecessary and also led to more actualisations inside the application, making the performance worse. Even though the performance is not an issue in this application, simplifying the business logic also led to simplified code. At the moment there are a lot of bugs in this particular part of the application and introducing the simplification that the business analyst proposed will lead to better code and most likely to less bugs in this part of the application.
Taking Shortcuts Beyond Your IDE
Taking shortcuts in software development is often perceived as risky, but it does not have to be. In this talk, I will show you how adopting smart shortcuts can enhance your productivity without sacrificing code quality. While IDE shortcuts are just the beginning, we will explore ways to streamline your workflow across the entire development process. From key combinations to advanced automation techniques like code generation, I will demonstrate how you can optimize your time and enjoy coding more. Whether you are a seasoned developer or just starting, this talk will help you identify areas where you can work faster and smarter. By the end, you will be equipped with practical strategies to always be on the lookout for opportunities to improve your workflow.
Colleagues were often astonished how many shortcuts I used and how much quicker I can do certain things. As it is always good to check where developers can make their workload lighter I want to show different ways we can take shortcuts without compromising quality.
How Unit Testing Saved My Career
When I first started programming and the code did not behave as I expected, I struggled to understand why, leading to a lot of frustration. It was only after I discovered unit testing that things began to click. Testing not only helped me validate my work but also taught me how to write clearer, more structured code.
However, as I gained more experience, I encountered projects where testing became a source of frustration itself. Overly complex unit and integration tests made it difficult to understand what was actually being tested. When these tests failed, it was sometimes hard to tell whether the problem was in the code, the test, or the setup around it. The confidence that testing had once given me started to disappear.
In this talk, I will share what these very different experiences taught me about making tests genuinely useful during development. Using Java, JUnit and Mockito, I will explore testable code, mocking, parameterized tests and what to question when a test setup becomes harder to understand than the code it is supposed to test. I will also share some of my more recent experiences using artificial intelligence at work, including what happens when generated code comes with passing tests but still misunderstands the requirement.
Testing can do much more than tell you whether your code works. I want to show how it can help you understand the code you are writing, shape its structure and give you confidence while changing it. The interesting part is what happens when tests stop doing that.
Learning about unit testing was one of the most valuable things that happened to me while I was learning to program. It gave me a way to understand what my code was doing, helped me structure it better, and made programming feel much less frustrating.
Later, I also experienced the opposite side of testing, where complex setups made tests difficult to understand and trust. In this talk, I share how those different experiences changed the way I think about testing and why I now see unit tests as much more than a way to check whether code works. They can also be a tool for understanding, designing, and changing code with more confidence.
Testcon 2026 Upcoming
How Unit Testing Saved My Career
BED-Con 2026 Sessionize Event
Voxxed Days Luxembourg 2026
How Unit Testing Saved My Career
DevBcn 2026 Sessionize Event
GeeCON 2026
Why Bad Code Quality Is Not (Only) Your Fault
Voxxed Days Ticino 2026
Why Bad Code Quality Is Not (Only) Your Fault
IT-Tage 2025
Wie Unit-Tests meine Karriere retteten
The San Francisco Java User Group
Taking Shortcuts Beyond Your IDE
WeAreDevelopers World Congress 2025 Sessionize Event
JNation 2025 Sessionize Event
JCON EUROPE 2025 Sessionize Event
JavaLand 2025
How Unit Testing Saved My Career
Devnexus 2025 Sessionize Event
Annelore Egger
Software Engineer, OpenValue Switzerland
Brugg, Switzerland
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top