My experience as a developer working for a non-profit with a dev team
The nonprofit organization that I worked with is called Story Squad. The goal of Story Squad is to give children between the ages of 8 and 12 to engage in creative activities, specifically reading and drawing to boost there creativity and nurture creation over consumption.
On the project I worked on the back-end using Node.js and Express. The problem I chose to work on was probably the hardest problem I’ve ever tried to solve. In all honesty, I probably chose it because it seemed harder than the rest of the problems and I had a good idea for how to solve it.
You may be wondering what’s this problem that was so hard? Well, the problem I was trying to solve was a problem in the app that caused it to crash, more specifically in the app the players are matched up against each other with 2 teams of 2 facing off against one another. During the face off phase of the user-flow, the app would crash if there where less than 4 people in total in a face off. The feature I worked on that me and my team dubbed “ghost users”, and the stakeholders called the “remainder problem”. We spent a week planning as a team and getting a “10,000 foot view” of what we where planning on doing. After all the planning was finished, and we had the opportunity to look at the code, my biggest concern with this project was that I would be writing bad code that wasn’t maintainable.
Once I got into looking at the code it was almost overwhelming, this was the biggest codebase I’d ever worked on and I wanted to utilize best practices when going into this, but I also knew I had to write clean code, as well as code that didn’t break anything that was currently in the codebase. I decided that I should focus on writing clean code that’s maintainable, using the existing styling and practices within the project such as naming conventions, and adding semicolons at the end of each line of code. Instead of doing what ive done on personal projects and just built something out as quickly as possible, not caring if the code is maintainable or not. I also decided to look at all files that where even slightly related to the problem I was working on. Once I had a good understanding of how everything worked together, I decided to make a plan using existing plans I had made and taking into consideration what had already been written in the code. I decided I would go with a data driven approach. I noticed that the previous teams who worked on this project did the same, and I decided that it would be easiest to generate users from database tables that are prepopulated and filled with the data from all users that don’t exist in the current squad, and using there submissions and name to make it appear as though an actual user is playing instead of a bot.
We broke down the features we all had to build into shippable tasks using a Kanban board. Me, and my other team members looked at the production description, as well as the Figma design doc. Since we knew which features we’d be working on for the app as a whole, we decided to break each task into smaller tasks. Once we did this we determined as a team who would work on each feature.
The problem I worked on was one that previous teams had problems solving. It was called the remainder problem, below is the user story that we created highlighting the problem.
Some of the problems i ran into working on this project
The feature that i worked on was actually just a bug that other teams hadn’t had time or the ability to squash.
The biggest problem i ran into was that when i was looking for the code in the backend, everything seemed to lack cohesion as well as the code being highly interdependant causing the code to be tightly coupled. Once i realized this, i had to dig deep into multiple files to see how everything worked together because i didn’t have time to refactor all the existing code to make it clean. Because of this i decided to dig into every file that couple be remotely related to the faceoffs. A problem i seemed to constantly run into, was inconsistent naming conventions, lack of comments or documentation, and ambiguity in alot of the database tables. For example, there was a table called Squads but there was also a table called Cohorts and another one named teams, and no documentation informing me of the purpose of the table or even a ER diagram to explain how everything worked together. I decided the best thing to do would just be to spend a whole week understanding how everything worked since I was working in a less than optimal situation.
One idea i had was to create a few new tables that where specifically for the “Ghost Users” and add a bunch of random user data to the new tables and add those tables to the existing user tables for the faceoffs, but ultimately i decided against that because due to my time constraints i wouldn’t have the ability to finish even half of that solution in the 4 weeks of time that i had for the whole project.
The other idea that i had, was based on the assumption that all submissions from every user is saved to the database, as well as every Squad. I decided that i could join the squads table and the submissions table excluding every squad that is in the current faceoff.
Since the whole premise of the remainder problem was that when less than 4 users where returned in a faceoff the game would crash, i decided to look into the code that generated the faceoffs. I found a function called getFaceOffsForSquad() that took a parameter of SquadID It was in this function that i learned that the submission id and the squad id where both needed to generate faceoffs and that is where i got the bases for the query i referred to above. I noticed that the faceoffs where returned as an array, and there was a line of code that checked to see if the length of the faceoff was less than or equal to 0. I thought, well if it is returning an error when the length is less than 0 ,why can’t i add some code to this to check if the length is less than 4 and if it is, calculate the difference between the length and 4 and generate that many ghost users by calling the query i made.
The current state of the application
Currently the Story Squad product has the emoji reactions finished for the front-end as well as the backend, and the faceoff / matchup shouldn’t crash when there are less than 4 players in a squad.
On the figma design doc, we worked on the matchup and voting phase shown below
One feature of the match-up phase that my team thought would be crucial for a good user experience is adding an animation to the padlocks when a user matchup is revealed. So when its revealed the padlock gets unlocked and goes away. We all agreed we would be disappointed if that didn’t happen and kind expect it as a user. Given the time frame we have being only 2 weeks i can see challenges with the animation part of this. We thought that maybe greensock would be a good tool to use for the animations. But this is definitely a challenge that we foresee that would add a better experience.
Some feedback i received from my peers was that i have a tendency to “play it safe” and try to understand how the whole system works with the feature im working on before deciding to write any code. This is sometimes crippling because i don't want to break anything, but my project lead informed me that its best to just write something that may not be 100% complete but provides partial functionality than to not write any code at all.
This project furthers my career goals by allowing me the opportunity to not only work on a team. But also work on a live product for a stakeholder. The way i described it to an interviewer was that “Lambda is like a intensive apprenticeship program” and labs is like the proving ground where you use all the skills you gained an apply them to a real project so you can show that you have what it takes to do the job. Labs is like the job simulation, and it has definitely helped me to prove to myself that i can not only do the job, but it also allowed me to understand how others view me and how i deal with feedback from my colleague’s and manager’s point of view.
