Selection
Blog

Change The World - Project Analysis

My Senior Capstone project was hands down the most positive and influential experience I have had thus far at CNU. The passion I was able to put into my Capstone as a result of how geared it was to my skillset really made it such a positive experience for me. The structure, a fully open-ended exploration of anything of my choosing computer science related as an illustration of my skillset, perfectly fit my direct, passion-driven, and inquisitive work style. Being able to redefine my understanding of the professional world and work with industry standards was an added bonus. Winning the Software Faire and getting recognition for my hard work was simply icing on the cake.

One of the key requirements of the capstone project was having the ability to teach oneself new concepts and skills, which served me quite well as I am primarily self-taught. Over the course of the capstone I Google’d perpetually, having to close 30+ open tabs after each night of work. Furthermore, I was able to utilize freenode IRC channels to enjoy the environment I flourish in best for coding discourse: one or more individuals actively and directly engaging in conversation with and teaching me various things over chat. These selfless, faceless, and nameless individuals were crucial to my database/frontend/backend learning, encapsulated one of my favourite means of educating myself, and are thanked in my GitHub for their services. Finally, my Algorithms/Capstone professor was instrumental to my Capstone in pointing me in the right direction of working with Entity Relationship Diagrams (ERD’s). The ERD-focused mentality of database design combined with easy visualization and exporting to a Debian Server using MySQL Workstation greatly improved how I went about every step of the database process, which ultimately powers the finished product.

Although I learned a lot directly, the challenges I faced also served as a powerful teacher. One of the biggest struggles I experienced while coding was navigating the balance between fixing a problem or implementing a feature a certain way versus taking an entirely different approach to the situation at hand. In one instance, I spent multiple hours analyzing a User Interface (UI) component implemented with a certain View the way I liked, only to decide that it was not worth my time and instead visualized the UI element with a completely different View subclass. Situations such as these taught me a great deal about knowing when and how to give up strategically. Programming is an art, and one must know when to switch brushes in order to utilize their time wisely. I developed a powerful tactic of not only writing down a log of what I did and how long I spent each session, but also began adding items on my agenda to two separate lists as either bugs to fix or future features to be implemented. This was not only extremely rewarding, but served an additional means of addressing the aforementioned struggle. I found myself fixing lots of these issues later indirectly or in a manner unforeseen at the time, teaching me an important programming lesson on how to better code in a substantial modular environment.

One of the things I know I would do differently in my future applications would be to conform to Android design standards. I spent a serious amount of time creating a unique bar across the top of the screen, as I wanted my app to look very seamless. But after undergoing User Experience (UX) testing and reading books on UI/UX, I began to realize that the more directly an app conformed to design standards, the better. How comfortable a user feels when an application is laid out traditionally, how easily they are able to rapidly navigate an application without additional instruction, and how painlessly they recover from doing the wrong thing is extremely important from a UI/UX perspective. After initial UX testing, I ascertained that I had taken a mediocre approach to design. I redid my colour scheme then underwent UX testing and altered my UI accordingly. Unfortunately, individuals still at times attempted to use a certain common Android design standard that was ingrained in their brain that my app did not implement. In the future, I will read up on a devices design standards before creating an application for that specific platform.

Ultimately, this project completely transformed me as a developer. I gained professional insight on my previously sub-par coding attitudes and learned significantly about full stack development and other current industry buzzwords and standards. I ended the experience with a wide breadth of knowledge that I did not have when I started. But the ultimate boon of this experience, as generic as it may come across, was being forced to tie all my skills together constructively. In order to do so, I relearned some of the areas I was less proficient in. But when forced to do so with the desire to come out a better developer, I ended up learning more than I had ever before in each subject area. Furthermore, when inhabiting the environment of skilled developers on IRC or implementing required functionality between each aspect of my application (UI/UX, Front-End, Back-End, Database, Server), quality code in each component of my Capstone was perpetuated. The Capstone processes itself felt like one long positive feedback loop, from start to finish. I can only hope my future forays into full stack development are as rewarding as this experience has been.