Software-Development

Quick takeaways Domain complexity matters more than technical complexity - Most projects fail not because of technical challenges, but because they don’t handle the business domain well. DDD is a toolbox, not a religion - You don’t need to use every pattern from Domain-Driven Design. Pick what solves your actual problems. Start with the domain model - Understanding how the business works is more important than designing the perfect schema.

Quick takeaways Developers are often kept in “golden cages” - treated as coding monkeys receiving tasks without understanding the broader context or product vision Requirements are usually incomplete or wrong - understanding the business context helps developers spot issues early and deliver what’s actually needed Collaboration with stakeholders is crucial - developers have valuable product insights and should be involved in planning, not just implementation Event Storming is a powerful collaboration tool - a lightweight workshop technique that brings developers, product managers, and stakeholders together to align on complex topics Change takes time and trust - transforming company culture requires starting small, showing results, and convincing people through solving their actual problems Introduction In this episode, we talk about why software projects in regular jobs are delivered much slower compared to side projects, and what you can do about it.

Quick takeaways Go in the AI era: Go is excellent for AI applications, as the built-in concurrency makes orchestrating parallel API calls much easier than languages like Python Architecture philosophy: Clean Architecture isn’t always necessary. Start simple and add layers only when you feel the pain of complexity, not because someone said you should Career transitions: Switching roles within tech is easier internally.

Quick takeaways Prioritize reviews over new work - treat PRs as work that’s almost done and needs to be pushed to production quickly Big PRs create a deadly loop - when reviews take ages, developers make even bigger PRs to avoid multiple long waits Knowledge sharing is the hidden benefit - code reviews aren’t just gatekeeping, they spread understanding of how things work across the team One-day cycle time is possible - start work in the morning and merge by end of day with proper team culture and practices Split work vertically and horizontally - break features into small slices and layers that multiple people can implement in parallel Introduction In this episode, we discuss how to make code reviews fast and effective by keeping pull requests small.

Quick takeaways Event-driven architecture (EDA) is powerful but tricky – it’s great for scaling and decoupling, but has many hidden traps. Observability is essential – debugging async systems without tracing, logs, and correlation IDs is almost impossible. Use the outbox pattern – it’s the safest way to publish events without losing data. Design events carefully – large, generic events can lead to tight coupling and painful refactors.

Quick takeaways Start with synchronous architecture by default - it’s simpler to understand, debug, and maintain for most use cases Async architecture improves scalability and resilience - message queues and events help handle traffic spikes and failures Design matters more than the technology choice - tight coupling creates the same problems in both sync and async approaches Consider team experience - async architecture require more experienced teams and better tooling to handle new challenges Adjust as your system grows - external APIs, heavy operations, or the need to handle failures gracefully are good use cases Hybrid approach - use both sync and async where they fit best, rather than forcing one over the other Introduction In this episode, we discuss when to choose synchronous versus asynchronous architecture for backend systems.

Quick takeaways Simplicity isn’t enough for complex applications - while Go’s syntax is simple, complex applications still need proper design patterns; primitive code easily becomes spaghetti code in large projects. Reading the standard library isn’t the best way to learn Go - it’s optimized for different goals than typical applications and might be confusing for beginners. Router libraries are better than the standard HTTP package - libraries like Chi or Echo come with a nice high-level API.

Quick Takeaways High-quality code is mainly about keeping good iteration speed over time - can you add features without breaking what works? Not all code needs to be high quality - focus your efforts on the code that’s most important, changes often, or creates the most value. The right time to refactor is after you know your product has value, but before technical debt gets too big - make small improvements bit by bit.