My Lambda Labs Experience

TJ Janus
7 min readFeb 4, 2021

After a tough unit of learning computer science at Lambda School, it was now time to enter the Labs program. Labs is a work-place simulation program where students are thrown into the real-world product development experience. In this program we got the chance to apply our newly learned skills to benefit a real world stakeholder.

Family Promise of Spokane is a homeless shelter in Spokane County, Washington, which equips families to end the cycle of homelessness. Family Promise of Spokane is a community nightly-homeless shelter, that provides services to help prevent families from experiencing future homelessness by assisting them in getting stable housing, and keep them there. The major task that Family Promise of Spokane wanted our development team to tackle was digitizing their intake form, and creating a daily check-in system for guests.

After meeting with the Family Promise stakeholder, J,we had direction on which tasks to prioritize and which users would have permissions and access to certain information and data. Ironing out the difference in access between a supervisor, guest, and case manager became very complex and iterative. Throughout our discussions with J, things would change very fast, and it became overwhelming to keep track of, and make sense of. Once we came to a final understanding, the project tasks became more clear and less convoluted.

My role in the project was to work on the backend with two other students. We inherited a code base from a previous group of students, that at first glance, looked very intimidating. By the middle of the second week, however, the three of us became very comfortable with database connections, permissions, and schema. This is when my insecurities went out the door, and I became very confident in my ability. Our main goal as the backend team was to create various endpoints with regard to checking in guests, and assisting the frontend team with whatever data they needed.

Diving In

The real technical challenges started right when we got the code base. Setting up your environment with a code base you’ve never worked on was frustrating. Every issue occurred from the environment variable setup to the PostgreSQL database, and it was irritating to say the least. After spending 2–3 days onboarding with the team and fixing our errors, we finally were able to start implementing changes. This daunting experience with my teammates really made us stronger as a group going forward.

As aforementioned, one of our main tasks was to set up the check-in tables, and this is where the work started. For this engineering task we ended up using the already created “logs” tables and made some additions.

logs table

This is a code snippet of what our “logs” object visually looks like. One of my main contributions was adding certain fields on this object so the frontend team can correctly pull the right information about a reservation. A request from our stakeholder to add fields such as “on_site_7pm” and “on_site_10pm” was an easy implementation so a supervisor can log if a guest is physically in the shelter during those times. After about a week and half with this version deployed we discovered a change needed to be made so our frontend team could distinguish individual guests.

We then ended up adding similar fields to the “members” tables, so we can track an individual members reservation. Below is another code snippet that represents the new updated changes on the members table. The members table also holds all the information that is generated after filling out the intake form. This is the best possible spot to see as much information about an individual at the shelter. Once we deployed the backend, this enabled my teammate, Thomas to then create a supervisor dashboard (image below) with the ability to toggle the boolean fields below.

members table (new changes — Family Promise)
Frontend design using the members / logs table (Thomas Kim)

As a backend developer team, our role this project was mainly to assist the frontend with any new implementations that were needed on top of the code base we were given. It was a rewarding experience to be able to provide code they needed in a timely manner. I felt more like a database manager, making quick fixes, checking the changes, and continuing this process throughout.

Most technical problems came in the fashion of redeployment, running migrations, and seeds. Many times we would make new changes, push our changes, and then we would be left to re-deploy our server and that’s where things went awry. With the help of our teammates, and our product manager, we were able to troubleshoot options and find a semi-consistent way of deploying.

Product Roadmap

With the efforts of the frontend team they were successfully able to pull in our data, make it display, and have it persist in key areas. The full application is not built out as there are lingering components that need to be connected for full persistence. Looking back, I wish I was able to design the database from the ground up, but I felt like inheriting the code base and understanding it, was just as beneficial in my growth as a developer.

The current state of the backend is definitely close to production level in terms of release 1 and part of release 2. The backend successfully was able to create and update the endpoints for Guest Intake, and User Dashboards. We also started implementing the Staff Messaging feature by creating the “notes” tables.

Looking Ahead

Our team at Labs30 was able to further the goals of Family Promise of Spokane by improving the digitization of the intake form and setting up guest registration. The next cohort will likely pick up where we left off by making sure all outstanding frontend components get connected and making sure the data persists. While the prior cohort had an iteration of the Staff Messaging feature, there was no access control between user types. The backend team was able to sort out the permissions of privacy between who can see what notes. I believe we left the next group with a great starting point to tackle this challenge. The “notes” router and table are set up for different user types such as Case Manager to Case Manager notes, or Guest to Case Manager and vice-versa. Here’s an example of a GET request utilizing our restrictTo middleware to get all “notes.”

Our frontend team was unable to start using this data because they were preoccupied with rounding the corners on the guest intake and reservation. I do not think these endpoints will be the final ones for the next group. I foresee potential tweaks to the “notes’’ endpoints in order to cooperate with the frontend team.

Reflecting

I was fortunate enough to work with a great group of teammates on this Labs project. I truly learned a lot from my direct teammates Kae Benton, and Cameron Lares, that assisted me with the backend. In the early stages of the project, I felt like I was a leader, rounding the troops and breaking the awkwardness. We quickly gelled together and learned about each other’s communication style in order to work at a productive level.

Throughout my Labs journey I was given the chance to give and receive feedback with my teammates. I was given a really good piece of feedback from my teammate Cameron. He said I was a great leader, but sometimes I can be too pressing, or trying to take too much control. I was already self-aware that I have a tendency to grab the reins, but this further proved my self-awareness and I wanted to try and improve in this area.

The rest of the project, I gave Kae and Cameron the opportunity to lead and take control, by laying low and making sure the input I was giving was quality. As a group we would pair program and throughout the later stages of development, Kae started driving the bus in terms of coding. I was no longer in full “control,” and this led to a more productive and spread out development process.

Working on the Family Promise of Spokane project, I was really able to solidify my backend coding skills. Whether it was modeling a database, fixing an endpoint, or adding a seed, my level of comfortability sky-rocketed during this time. I really want to explore other database options such as MongoDB in the future and round out my skill set on the backend.

On the other hand, I definitely need more experience working on frontend code, and that is an area I plan to tackle once I am done with Lambda School. Here’s to more React and CSS!

--

--

TJ Janus

Full Stack Web Developer | Lambda School Student