NO SILVER BULLET

Full episode notes: https://threedots.tech/episode/unpopular-opinions-about-go/Quick takeawaysSimplicity 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.Struct-based configuration is better than the “optional pattern” - structs are easier to document, discover, and maintain than the popular With-options approach.There’s no one best project structure - starting small and evolving your structure as needed is better than following a dogmatic approach like the unofficial “Go project layout.”Writing stubs by hand is better than using mocking libraries - manually written stubs are easier to debug and encourage better interfaces than reflection-based mocking libraries.Code generation is better than reflect - for ORMs or dependency injection, it gives you compile-time checks and better performance.Generics are mostly useful for libraries, not application code - while everyone waited for them, they’re rarely needed in typical service-level code.Channels and goroutines can be overused - they add complexity and should only be used when concurrency is actually needed, not as a default approach.Go’s error handling is fine for most projects - explicit checks make code easier to read, though built-in stack traces would be helpful.Memory optimizations are often premature - micro-optimizations waste time for typical API services where network latency is the bottleneck.In this episode of No Silver Bullet, we share some of our unpopular takes on the Go programming language. After working with Go for eight years on all kinds of projects, we’ve seen many discussions about what idiomatic Go means. We talk about what worked for us, but we keep in mind that different projects have different needs. We question some common Go beliefs and share tips we’ve picked up along the way.Links:Wild Workouts - Our example Go project that shows a more complex application structureWatermill - Our Event-driven application library for GoHTTP Routers we recommend: Chi and EchoGo in One Evening - Our hands-on Training for learning Go quicklyClean Architecture episode - Previous episode that goes deeper into project organizationGo Developer Survey Results - Shows that ~75% of Go developers build API/RPC servicesGoogle’s Go Style Guide - Many useful ideas, but be careful about being too dogmatic about it

Full episode notes and transcript: https://threedots.tech/episode/is-clean-architecture-overengineering/In this episode of the No Silver Bullet podcast, we discuss Clean Architecture and whether it's overengineering or a best practice for organizing code.We talk about why the pattern is often controversial, when it makes sense to use it, and how to implement it effectively.We share our experiences using Clean Architecture across different projects and teams, including the common concerns developers have when first seeing it.Quick takeaways:Clean Architecture is most beneficial for complex projects with larger teams - for small teams or simple projects, it can become overengineering.Separation of concerns is the core benefit - keeping domain logic separate from implementation details makes code more maintainable.It's easy to go too far - using too many interfaces or too many layers without a clear reason creates unnecessary complexity.Start simple and evolve your architecture - don't force Clean Architecture from the start if your project doesn't need it yet.Understanding the "why" behind the pattern is crucial - blindly following it without understanding leads to poor implementations.Notes:Related patterns:The Dependency Inversion Principle: one of SOLID principles.Blog post: Introducing Clean Architecture: https://threedots.tech/post/introducing-clean-architecture/Blog post: Microservices test architecture: https://threedots.tech/post/microservices-test-architecture/Blog post: Repository Pattern in Go: https://threedots.tech/post/repository-pattern-in-go/Blog post: Combining DDD, CQRS, and Clean Architecture in Go: https://threedots.tech/post/ddd-cqrs-clean-architecture-combined/ (Mentioned as available)Example Go Project: Wild Workouts: https://github.com/ThreeDotsLabs/wild-workouts-go-ddd-examplego-cleanarch Linter: https://github.com/roblaszczak/go-cleanarch

Quick TakeawaysHigh-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.Architecture decisions need more thought than other code quality factors since they're hardest to change later - ask "how hard would this be to remove?"Balance between MVP and quality depends on your situation - for experiments, cut corners on purpose; for critical systems or enterprise products, focus on quality from the start.IntroductionIn the first episode of No Silver Bullet live podcast, we talk about the balance between writing high-quality code and taking shortcuts.Based on nearly 20 years of working together on various projects, we discuss when it makes sense to move fast rather than aim for perfect code, and how to avoid technical debt that can kill your project.We focus on making mindful engineering decisions instead of blindly following rules like "always do X" or "never do Y".Different situations need different approaches to code quality.Notes"No Silver Bullet": The classic 1986 paper by Fred Brooks that our podcast name references, discussing how there's no single development that will solve all software engineering challenges.Our Learning Platform: /learn: The project we discussed that started as an MVP and was later refactoredArchitecture Patterns:Pareto Principle: The 80/20 rule we mentioned - often 20% of the code creates 80% of the valueFuture Episodes:Development Practices:QuotesQuality is not about some kind of elegance of code because it's just an artificial thing. It's not really helpful for your team if it's pretty. - MiłoszOften you have in the code places that you don't touch often or it's not earning a lot of money... Ask what are the places that we're changing the most often? What are the places that are creating most of the value? - RobertI remember one project when we started applying Domain-Driven Design... Everyone loved it in the team... But what I also remember is that it had no paying users and we had to shut it down. - MiłoszIf you did your dirty POC, don't miss the time when you should clean it up, because it's easy to go into a spot where it's no longer possible to do that. - RobertAfter working with [legacy systems] for long enough, you might think, 'I've had enough of this, I won't allow my next project to rot like this one.' It sounds like a good idea, but it can also be a trap. - MiłoszSometimes it can be even the opposite. Having everything super consistent can actually be worse than having inconsistent things, because keeping this consistency requires effort... Sometimes it requires you to use an approach that is not optimal just because 'we're doing it consistently.' - RobertA useful mental model here is to care about the useful product first, not the technical design, which of course is important, but I think it's easy to overvalue it. - MiłoszTry to find some places where you can do refactoring in one week... Often you don't need to rewrite an entire service. You can just do some refactoring in the code and iterate on that. - RobertEpisode notes and summary: https://threedots.tech/episode/when-to-write-low-quality-code/