I keep finding tons of tutorials and books about writing clean code and using design patterns. But most of them start with the assumption that you already figured out what your software needs to do. That’s the part I struggle with the most.
The real challenge for me is working with clients and team members to define what the system should actually accomplish. How do you decide what features to include? Where should you draw the boundaries? I want to keep everything simple from the start instead of building something overcomplicated and then trying to fix it later.
Has anyone found good learning materials that focus on this early planning stage? I’m talking about the stuff that happens before you start coding - understanding the problem, talking to users, figuring out requirements. Would love to hear what worked for you.
Domain-driven design has been a game-changer for this problem. Bounded contexts naturally create clear system boundaries, and event storming sessions with stakeholders show you what business processes actually matter. Alberto Brandolini’s collaborative modeling work really helped bridge the gap between tech and business teams. I’ve had great luck starting with user journey mapping before talking features. It shifts the focus from “what should the system do” to “what do users actually need to get done.” The biggest thing I learned? Treat requirements discovery as an ongoing conversation, not a one-and-done documentation task.
totally agree with u, man! it’s all about askin those questions early on. understanding why something’s needed is key. sketching out flows is super helpful too - helps u see things clearly and makes coding so much easier down the line. good luck!
Oh interesting! Have u tried sittin in on users’ daily workflows? Like literally watchin them work before discussin any features? Sometimes what they say they need vs what they actually struggle with are completely different. What kinda clients are u mostly workin with?