The Flexible Work Location Tool (FWLT) is an application being built for Interior Health as part of my capstone project for Okanagan College. FWLT is needed to streamline the process of handling forms submitted by employees as currently it is done through sharing pdf files or physical copies. The forms are related to applying to work from home. Employees will fill out forms and submit them through the application then managers can review the forms and approve or deny these forms. The forms take a data-driven approach, meaning all the questions and the answers are stored in a relational database instead of being hard-coded in the front end.
Admins of the application can use a custom What You See Is What You Get (WYSIWYG) form builder for creating new forms that can then be filled out by users.
HR users can view varoius analytics related the application, like form approval rate, average manager response time, and employee workplace by province.
One of the major parts I've worked on is the form builder WYSIWYG. This includes breaking done the problem in smaller sizable chunks, building out a general structure, and actually programming large portion of the component.
The project is being developed as part of a group of ten others using Agile, Scrum, and some Extreme Programming methodologies. During the project, I have learnt a ton about working with large groups, communication, software development, and software engineering.
How important it is to ask for help when stuck (especially from those with more experience) and put aside a bit of ego for the success of the project. While working with others in XP pairs, learning to effectively communicate ideas back and forth, read other's code live and provide feedback and assistance take the feedback as well. Effectively discuss and resolve disagreements in a friendly productive manner.
Lots about developing software in an Agile and Scrum approach, learning to self manage and being proactive enough to take on new tasks. Discussing what we have done, will do etc. almost every day. Meeting with clients regularly to gain a better understanding of the kind of software that they need, and applying their feedback to our project.
The critical role of version control, and being strict on uploading new features or fixes to their own branch. Submitting and reviewing pull requests to have more eyes so that hopefully no bugs slip through. I've read a lot of code reviewing my peers' work and found it incredibly useful for understanding the project well, but also as practice for being able better read and learn from others' code.
Since others will be reading my code as well I've learnt to better write self-documenting code and better descriptive comments too, for more complex sections. I've also got to write tons of documentation for the project (which I can't show, unfortunately), and gotten lots of practice writing clear and in-depth explanations of the software.
In short, I have learned how better work and communicate in large groups, applying agile methodologies, and have become a better programmer and software developer in general.