In my opinion, and experience from working with a lot of different people, I usually start out by making assumptions on the overall architecture and model based on talks/briefing. Most of the time that's enough to get you started for a while, until one of those assumptions get debunked thanks to code displaying a different implementation of the model or architecture and it's back yo yhe drawing board for context etc.
In the ideal world, code shows intent and by looking at folders, files and naming you get an understanding of how it all fits together what who does what. Unfortunately, reality has its say here and dares to throw that around.
Even in high performing and clean code type of teams can this be the case, so I don't feel as if we could have a better way to tackle this. You start, revisit, go again. Rinse and repeat.
Thanks for replying!
Yeah that sounds like the only option really, try things and see if they work. I just find it hard not knowing if what I'm doing is 'right' or not - especially when working alone.
Maybe it's a good idea to share the work more and get more people's opinions/perspectives.
That's always a good idea. One of the reasons I open source my work.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.