Voyages of a Software Dev Intern Thru The Early Years

I've said it before, I kinda know what this program needs to do. Translating that into C# objects that will interact with each other intelligently and efficiently...that's a whole 'nother can of worms that I personally find easier as a visual. I know Students will have courses. Courses will have evaluations (like quizzes and tests). Evaluations will have Scores. Deciding how that works, from a database perspective, will help ensure I'm configuring my code to back into the correct place and identify ways to simplify the data layer--storing instructors in their own table will allow possible features down the road of letting students see how many A's a teacher hands out historically, for instance, but also makes me decide if my entity should have an instructor object attached, or should that be a domain model thing? I'm a very goal-oriented person in that if I know there's a river to cross 500 miles from now, I want to plan the next 500 miles of route t...

One of the things I learned from revisiting C#II's project, eDevices was that planning out what your database schema is going to look like is pretty key to determining how easy your life is going to be down the road. In C#II, the focus appeared to be on breaking up the bigger project into smaller iterations that were built on organically--which was GREAT until I tried to implement a feature that hadn't been planned for in an earlier iteration, one that required changing one of the fields on the Policy entity. I managed to break all functionality because the Policy entity no longer matched what was expected, and I had to completely redesign 90% of my application's business logic to account for this new feature. This led to further frustration when I realized that I didn't properly manage my code first migrations for this series of changes--again, they happened organically during the class without any thought or discussion as to how to go back and make changes. Had t...