Changing the World One React App at A Time
A programmer, a mission, and a big impact.
Don’t be afraid to feel all the feels…
Technology. Maybe the first thing that comes to mind is a computer. Maybe the wheel — depending on your birthdate. Perfectly placed technology can mean the difference between shelter or sleeping on the streets.
Family Promise is an organization that caters to the “unseen homeless” — pregnant women and adults with children. In order to fund the shelter they must adhere to strict policies to protect people and gather the correct information for financiers. When a woman with small children comes in off the street, likely having endured trauma, she must wrangle her children while filling out 30 paper forms before a bed can be reserved, among other services like laundry and showers. Enter technology.
A shelter management system to be exact. The first version simply digitized the intake system giving administrators the ability to check people into the shelter efficiently. The ultimate plan is to give people the ability to sign in easily, update profiles, reserve services, and check in and out of the shelter. Also, gather data about what services are most needed.
Onboarding? Oh, that’s going to be easy!
(She said confidently before her computer burst into flames.)
One of the most difficult and tedious things you’ll do as a programmer is to read and interpret other people’s code.
Lambda School classifies projects two ways: Onboarding projects and Greenfield projects. Onboarding means to work on an existing project. Greenfield means to start a new project from the beginning. Each type of project presents its own challenges, but I thought for sure it would be easier to onboard a project than to start from scratch. I was wrong.
Two words: Technical. Debt.
Every programmer has their own style. One of the most difficult and tedious things you’ll do as a programmer is to read and interpret other people’s code — and it will be most of your job. I took one look at the largest codebase I had ever seen in my short coding career and was immediately humbled. To make matters worse, this codebase was written by multiple teams of other students who were trying new things and learning. There was a mishmash of UI elements and libraries to include Ant Design, Material-ui, styled-components, and SASS. The state management for the project was all over the place. It started with React Context, half way moved to Redux, and a lot of component state management sprinkled throughout. This “technical debt” made it difficult to follow the flow of data through the project to pick up where the last team left off.
Our Mission:
To implement an executive director dashboard that would display daily reservation information, and monthly shelter statistics. Also, give the guests the ability to sign in with Facebook and make reservations. I was assigned the UX/UI Lead role. Which meant I would design and implement the user interface for the dashboard.
The main focus was a minimalist, clean design that would convey the information without a ton of flashy distraction.The executive director needs to be able to grab information at a glance, update notes for guests, and see reservation information. Built with modular components using material-ui libraries, one can replace components as needed, possibly upgrading the data visualization with another library like Plotly.
Deliverables VS. Ugly Code
The age old programming conundrum. Do we spend the bulk of our time cleaning up a difficult to read/buggy codebase, or work with what we have and make big gains for shippable product leaving all the technical debt for the next team? Making this decision comes down to time and resources. We only had a team of 4 brand new programmers, 4 weeks to understand a massive codebase and ship 4 new features. After consulting our instructors, our team went with making big gains on deliverable features. Rather than refactoring the whole codebase, we spent our time making components functional, while keeping up a standard for our additions. Our rules were: add state to redux, and whatever UI libraries were being used — roll with it. We wanted to make gains and minimize the technical debt left for the next team, but didn’t have time to fix all of the current technical debt.
In the end we were able to deliver a working reservation system and a new executive director dashboard that would display reservation information in real time.
The lessons we learned
- Assess realistically what the team can accomplish in the time allowed.
- Stakeholders will tell you they want the world, but keep it real with expectations.
- Laser focus on exactly what needs to get done first, make it do those things really well, then go for extra.
- You may not be able to fix the technical debt in a codebase, but you can minimize what you add to it.
- Remember that the products you are making are for real people. Ask all the questions from the user’s perspective up front.
The list of lessons from this experience could go on and on. But I’ll leave you with this — At the end of the day follow your employer’s values, and your own values. Ideally, those would line up.
