My Experience Working With Family Promise

Approaching the Beast:

This is the first large preexisting code base I’ve ever worked on so my nerves were wracked. Delving into a codebase as large as this one represented a new world of discovery in the unknown. A place where the familiarity of mini practice projects, and personal endeavors where every time a file is so much as touched, it happens before my eyes. Every idea about structure and design echoes in my ears before it makes its way into VSCode. New challenging problems face us as we dive into the belly of the beast. “What on Earth does this function even do? I’ve never seen that method before,” we thought as we shuffled between files, attempting to make sense of how everything ties together. After some time, things began to click, and impostor syndrome subsides. I can do this.

What did I work on?

I worked on an application for a charity company called Family Promise. Its primary function is to collect data for the organization, so they can have records to show donators, as well as the U.S. government. People feel a lot more inspired and comfortable with donating money when they know the impact that it will have. Obviously outsourced contributions are a necessity to keep a charity running, because greater funds can make a greater impact. The entirety of my contributions thus far have been the entire months of May 2021. It has been a running projects for a few months before I got my hands on it, and I would estimate it will be another 5 months or so before it launches. I’m happy to have gotten the opportunity to pay my dues to an organization like this, because they provide assistance in the form of sheltering, food, and living assistance for people in need, as well as check up on them afterwards to make sure their life situation has improved. That’s an honorable mission in my eyes.

Restructuring, refactoring and redefining our vision:

We ponder how our application will be perceived and utilized by our users, how the interface would be most intuitive and approachable, the data we need to collect and the how it should be structured for scalable holding, maintaining and querying.

Our implications begin with a bumpy start of complications, because it dawns on us that our database would be better off with a complete overhaul, utilizing our relational database with actual relations. A brand new schema is born. As much of an improvement this was for the future of our application, almost our entire server-side logic needed refactoring and optimizing to correctly query our new structure. We achieved this goal by initializing a slew of intermediary tables, to allow more data to be held without repeating itself in multiple locations, instead just referencing locations it’s already held. That also allows us to make complex SQL queries to return all the data precisely how we want it, down to the way it is ordered. We thought that a more interlocking database which references within itself was necessary because as it was, for example, a single person’s name may appear in 3 different locations of the database, like in the “list of recipients,” the “list of recipients that are receiving aid from x program,” and the “list of recipients that are receiving assistance with food”. That was just not optimal for the scale that it may need to maintain once it is launched because it will take up precious storage space and cost more money, which could be used on helping more people instead. This was a roadblock that put back a lot of development for about 10 days. Me, and my two other backend focused colleagues Trenten Grede and Diego Roman, were able to design a schema that was better suited for this. Through communication and collaboration with our front end team as well, brainstorming everything that may need a place in it’s design, eventually we came to a proper foundation to be expanded upon for time to come. We divvied up tasks through front and backend, and from there, the backend team was quite easily able to dole out what we needed to do by meeting every morning, discussing the tasks that need to be done today, and just kind of saying “I’ll take this one and this one,” trying to be efficient and equivalent in how they were delegated, and picking what we wanted to do out of today’s batch, taking each other’s interest in mind. The way in ended up panning out, we each worked on most every portion of the server side logic, but I personally focused on routing, modeling and some middleware, Diego did a lot of middleware and seeding, Trenten took the lead and made most of the executive decisions in schema, thus made the migrations and filled in where need be. By the end of the month, every portion of the database can be modified exactly how we intend, fed through endpoints accessible to the user interface displayed to the end user. The timeline we intended was to be about 5 days, but there were some unforeseen complications that come with misaligning schemas, and overlapping, conflicting migrations/seeds etc. Due to every obstacle that stood in our way, that timeline ended up doubling. We solved each of these problems using the tech stack that we were most comfortable with, Node.js as the base language, Express as the framework for making http requests a bit simpler to handle than with plain Node, postgreSQL to act as our actual database, Heroku for deployment, and Okta handling authentication. Using these we were eventually able to solve the problem. The application can now create, view, modify and delete programs, program locations, services, service types, recipients, program managers, admins, program and recipient households, notes on recipients, both miscellaneous and a baseline of information, for example age, gender and ethnicity.

The Future of Family Promise Development:

Though we got our fair share of development well on the way in the direction of our stakeholders, there’s still much to be done to completion. So we pass the torch with a fully CRUDing application on to future teams, and a vision we hashed through team meetings and dialogue with our stakeholders. The future of Family Promise as and application lies in a greater extent of data visualization. We need a map implemented that allows you to select a particular program location and see all the recipients in the area that are receiving assistance from the selected program in detail, like if they are receiving food assistance, money assistance, housing, how much of it, and how much it cost the organization to provide it. When you click on a program location, you should also have the option to see things like demographic of beneficiaries, total money spent on assisting everyone in the area etc. I foresee there being a lot of hiccups in visualizing all of that on a map, especially because since the future teams will have went through more or less, the same program I did, which did not expose us to the usage of for example, a google maps API. So just due to unfamiliarity, there will be a period of familiarization before even getting to developing it at an efficient rate. As a team, we documented technical bugs, and tried to demonstrate the lay of the land as best as we could in order to facilitate the following teams to hit the ground running, and make our codebase, hopefully easier to approach than the one we walked in on. The teams before us did a great job, but it should be everyone’s goal to outdo themselves, grow and improve. That is what I intend to do on a personal level, and because I hope the best for an organization as benevolent as Family Promise, which is impacting the world in causes I care about and because it feels to me like a little piece of me lives inside the confines of that project, I hope it does the same.

It’s Impact On Me As A Developer:

Well, for one, I’ve seen a little taste of what it will be like trying to assimilate to the code stylization of other developers, and even the way some people prefer to handle data flow through a project. Though I focused mostly on backend, most of that felt familiar, but I did jump in the front end as well to assist in debugging, and the most notable difference in the entire project from anything I’ve done or seen before, is the way they packed up React components into container components, which initiated all the necessary data, then passed props into render components where they added all the styling and interactable state, then fed all that into an index for each component, and the rest of the application accessed those components by calling upon the index of each respective component. That was honestly a hassle to understand how everything flowed into each other because usually I have seen and made all three of those functionalities into a singular component, and it felt unintuitive each time I looked at it. Ironically, even though when I came in on day one thinking, I wanted to mostly work on front end but would assist with backend if necessary, I immediately found myself drawn to backend as what I actually wanted to work on more when it came down to it. That surprised me because it quite literally just happened, despite my active decision being that I thought I wanted to work on frontend. I think that this definitely tells me something about my actual place in full stack development, which is likely to be backend focused. I also learned a lot about authorization, database schema design, the necessity of querying related tables in correct order, the benefits, restraints and the benefits of restraints in the form of foreign key restraints.

How My Team Helped Me Grow:

My team definitely didn’t shy away from informing me that I should be more detailed in my descriptions on the precise changes I made in particular pull requests, or that I could sometimes be messy with branch management through GitHub. i.e. I left a lot of branches that were no longer in use open and didn’t delete them, which cluttered everyone’s workspace. Duly noted, by the end of the month I’d learned a lot from a technical perspective, as well the importance of communication in meetings, direct messages and even in descriptions on my pull requests. So, for everything that we’ve gone through and everything we’ve gotten through this month I’d like to thank all my team members… Thank you Diego, Trenten, Declan, Alex, Anthony, Trey and D’Artagnan. I learned a lot and had a lot of fun working with all of you.