🧠 Lode Coding: Giving Your AI Assistant a Persistent Memory
AI coding assistants can write code, but without project context, every new session can feel like starting from scratch.
📅 September 22 - join us to explore Lode Coding, AI-owned knowledge bases, AGENTS.md, preserving architectural decisions, and lessons from months of real-world experience.
🎤 Speaker: Pavel Osadchuk — Principal .NET Engineer & Software Architect, 15+ years in software development.
⏰ 16:00 CEST | 🕒 45 min | 🗣 English | 💻 Online
🔗 Save your spot: here
💡 Less context loss, more value from AI. See you there! 🚀
👁🎨 Back to BI dashboards!
On September 17, we're meeting with Darya Drobova again for “Best Practices for Effective BI Dashboards” 🎯
We’ll talk about:
→ why dashboards fail even when they look good;
→ how to reduce visual clutter;
→ UI/UX practices for faster data understanding;
→ real-world examples + practical checklists.
🎙 Darya Drobova, Principal BI Developer at EffectiveSoft, 12+ years in BI.
⏰ 19:00 Minsk / 18:00 CEST
🕒 1 hour | Russian
📍 Offline: Andersen office, Minsk
💻 Online: stream link after registration
🎫 Register here
🔥 Ready to make your dashboards clearer and more useful? Join us on September 17!
One SQL topic especially useful for backend testing is subqueries.
A few patterns worth remembering:
🔹 IN (SELECT...) - dynamically filter records without manually copying IDs.
🔹 EXISTS - quickly check whether related data exists.
🔹 NOT EXISTS - find missing relationships. Very useful for spotting data inconsistencies.
🔹 WHERE value > (SELECT AVG(...)) - compare records against an overall value, such as an average.
The key takeaway: you don't need to memorize every syntax pattern. Think about what your main query needs and how another query can provide it.
For QA, this is especially useful when investigating API responses and checking what actually happened in the database.
How to Prioritize Test Cases When You Have No Time
You’ll never have enough time to test everything. The real skill is knowing what to test first.
When deadlines are tight, I use a simple risk-based approach:
🔹 Prioritize high-impact and high-risk areas
🔹 Check what actually changed in the release
🔹 Cover critical user journeys
🔹 Use automation to identify testing gaps
🔹 Focus on modules with a history of defects
🔹 Timebox testing to avoid getting stuck
🔹 Be transparent about what was and wasn’t tested
The goal isn’t to test less — it’s to make better testing decisions under constraints.