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...

So much of this summer (and before, but it's a little different when one is being paid to solve problems) was learning that the big obstacle in development is filling in the gaps. The gaps between what a library is meant to do and what you need it to do, the gap between knowing a service can do the thing and knowing how to make it do the thing, the gap between knowing what broke your application and why it broke it, and many many more. I found the software development equivalent of "telling time by the stars" is sifting through Stack Overflow, Github wikis, discussion forums, and sometimes official documentation to find a solution. So what? That's software development. Google is your friend.  It is, but those forums--the library developers, the helpful souls on Stack, contributors to discussions of all kinds--are by and far time tellers . They *get* what is going on, and they can tell you exactly what time it is--which is great for the original asker ...

The Old Goal, Revisited Quick redirect (more to refresh myself than anyone who is going to read previous posts and then this one without feeling any gap in time--kinda like binge watching an older show on Netflix wondering why the season in 2007/8 was only 1.5 real episodes): This blog was initially created to serve in an alternate timeline where I did not have an internship over the summer. My goal was to develop a web and/or mobile app from scratch, as a way to keep my skills sharp and prepare for graduation in December. This blog was supposed to be a way to document to potential employers "Hey look--I can do the things, even if no one has paid me to yet! And I can write about them, with personality even!"  So What Changed? A late but extremely welcome change to this plan was an offer to intern at OrangeBoy, Inc here in Columbus--an exciting small firm that combines a software-as-a-service platform called Savannah with public service consulting expertise to help libra...