I am one with my code and my code is with me.

TL;DR :

"when i die i want my group project members to lower me into my grave so they can let me down one last time"

STORY TIME

Last year in College, I had two simultaneous projects. Both were semester long projects. One was for a database class an another was for a software engineering class.

As you can guess, the focus of the projects was very different. Databases we made some desktop networked chat application with a user login system and what not in Java. SE we made an app store with an approval system and admin panels and ratings and reviews and all that jazz in Meteor.js.

The DB project we had 4 total people and one of them was someone we'll call Frank. Frank was also in my SE project group. Frank disappeared for several weeks. Not in class, didn't contact us, and at one point the professors didn't know much either. As soon as we noticed it would be an issue, we talked to the professors. Just keeping them in the loop will save you a lot of trouble down the road. I'm assuming there was some medical or family emergency because the professors were very understanding with him once he started coming back to class and they had a chance to talk.

Lesson 1: If you have that guy that doesn't show up or communicate, don't be a jerk to them and communicate with your professor. Also, don't stop trying to contact the rogue partner. Maybe they'll come around sometime.

It sucked to lose 25% of our team for a project, but Frank appreciated that we didn't totally ignore him and throw him under the bus to the point that the last day of class he came up to me and said, "hey, open your book bag and bring it next to mine." He then threw a LARGE bottle of booze in there as a thank you.

Lesson 2: Treat humans as humans. Things go wrong and understanding that will get you a lot farther with people than trying to make them feel terrible about something that may have been out of their control.

Our DB project went really well. We got an A, we demoed, it worked, it was cool. The biggest problem is I was the only person that had taken a networking class so I ended up doing a large portion of the work. I wish I had taken other people's skills into account when we were deciding on a project. Especially because the only requirement was that it needed to have a minimum of 5 tables and we had to use some SQL language (aka, we couldn't use no-SQL).

The SE project had Frank and a music major who wanted to minor in CS (and then 3 other regular CS students aside from me). This assignment was make an app store using any technology you want. But, you had to use agile sprints. So we had weekly meetings with the "customer" (the TA), who would change requirements on us to keep us on our toes and tell us what they wanted done as a priority for the next meeting. Seriously, just like real life. It was so much fun trying to stay ahead of that.

So we met up and tried to decided what to use. One kid said Java because we all had it for school. The big issue is trying to make a Java web app is a pain in the ass. Seriously, there are so many better things to use. Other teams decided to use Django because they all wanted to learn Python. I suggested why not use something with a nice package system to minimize duplicating work that had already been done and tested by someone. Kid 1 didn't like that because he said in the real world you have to make your own software and not use packages. Little did he know that I had worked in SE for a few years already and knew damn well that every good project has code from somewhere else that has already solved a problem you're facing. We went with Java the first week. It failed miserably. Nobody could get the server set up on their computers. Using VCS with it required you to keep the repo outside of the where you wrote code and copy and paste changes in there. It was just a huge flop so everyone else voted to change.

Lesson 3: Be flexible. Be open to learning new things. Don't be afraid to try something new. It'll make you a better developer in the long run.

So we ended up using Meteor. Why? We all figured we could pick up javascript super easy.Two of us already knew it. And the real time thing would make for some cool effects when an app got a approved or a comment was made. We got to work and the one kid was still pissed. I just checked the repo and the only thing he committed was fixing the spelling of on word in the readme.

We sat down one day and worked for 4 straight hours. We finished the whole project in that time. While other teams were figuring out how to layout their homepage, we had a working user system and admin page and everything. Our TA was trying to throw us for loops by asking for crazy things and we still came through. We had tests that ran along side the application as you used it. It was friggin cool.

Lesson 4: If possible, pick the right tool for the job. Not the tool you know. Everything in CS has a purpose. If you use it for its purpose, you will save days off of a project.

South Africa Release notes version v3.0.2

In 1994 SA underwent one of the biggest system upgrades since 1948. In this new rolling release since the system update called apartheid the system has been annexing resources, locking it down, making it closed source, closing it off community updates and from global updates and minimizing services across the board. On 27 April 1994, the new democratic system update was released with a new system monitor, release resources and balancing efficiency in the system. Though there were remnants of the old code in the system, it was being rewritten by a new generation of users, open source resources were established, giving users the right to choose among themselves how to grow the system , and how to better the experience for all.

In 1999 a new system monitor was created by the users, it wasnt as popular as the ground breaking Madiba release but it was a choice by the community to move forward and grow. The system was stable for a few years, new users were able to develop more on the system, making it more lucrative monetary wise. There were still remnants of the apartheid code but the new generation of developers worked with it making it there own, though they had not yet had admin rights to help change the system, they created a developer culture of their own. A new system resources balancer was introduced called BBEE, that allowed previous disadvantage users more admin rights to other system resources, helping the user base to grow. Though the balancer was biased, and flawed it has helped the system overall to grow and move forward. It has major holes in security and may flood some aspects of the system with more outdated software patches, users have kept it in its system releases until the resource balancer moved the system into a more stable position.

The next interim system monitor release was unexpected, a quiet release that most users did not contribute towards. The system monitor after that nearly brought the system down to a halt, as it was stealing resources from users, using resources for its own gain, and hasn't released any of it back to the system.

The latest user release has been stable. It has brought more interest from users from other countries, it had more monetary advantages than all other releases before. Though it still has flaws, it has tried to balance the system thus far.

Bug report as of 16 Feb 2018
*User experience has been unbalanced since the 1994 release, still leaving some users at a disadvantage.
*The three tier user base that the 1948 release established, creating three main user groups, created a hierarchy of users that are still in effect today, thought the 1994 release tried to balance it out, the user based reversed in its hierarchy, leaving the middle group of users where they were.
*System instability has been at an all time low, allowing users to disable each others accounts, effectively
killing" them off
*Though the infrastructure of the system has been upgraded to global standards ( in some aspects ) expansions are still at an all time low
*Rogue groups of users have been taking most of the infrastructure from established users
*Security services have been heightened among user groups though admins were still able to do as they pleased without being reprimanded
*Female users have been kicked off the system at an alarming rate, the security services have only kicked in recently, but the system admins and system monitor has not done anything about it yet

Bug fixes for a future release:
*Recreating the overall sysadmin team. Removing some admins and bringing others in
*Opening the system more globally to stabilize it more
*Removing and revamping the BBEE system, replacing it with more user documentation, equalizing the user base
*Giving more resources to users that were at a disadvantage during the first release
*Giving the middle group of users more support, documentation and advantages in the system, after removing the security protocols from the user base
*Giving new users who grew up with the post 1994 release more opportunities to help grow the system on a level playing field.
*Establishing the Madiba release principles more efficiently in the current system