A Developing Developer
I recently worked as part of a team for the first time on a rather big project that would potentially touch a lot of peoples’ lives. It was an amazing growing experience for me as a developer and as a person. Let me introduce you to that experience.
Meet the stakeholder.
The Boys and Girls club of Greater Conejo Valley seeks to enhance the lives of young people and their families by providing a positive environment that cultivates academic success, healthy lifestyles, good character and citizenship. Currently, the Boys and Girls club receives feedback on the programs they offer via the National Youth Outcomes Initiative (NYOI). The NYOI is a survey filled out by the club members and their parents and is meant to track if kids have fun during a given activity and at the club as a whole (on a scale of 1 to 5). You have to have a 5 to get a positive rating. All other values are ignored. The data is sent in July on how the club did in the previous school year. The feedback is not quick enough to be actionable, and nothing is measuring how the kids feel on a day-to-day basis. This is where we step in. Our job was to create an app that would give the individuals who were in charge of these clubs the information that would help accomplish their mission.
Meet the team.
The team was composed of two teams. Team A and Team B. We worked very closely together, but each team was responsible for different features that would make up this iteration of the app. Among the teams we had two design leads, frontend developers, backend developers, and data scientists. Each team was led by our amazing Technical Project Leads (TPL). We stayed in constant communication using Slack and Zoom through the working day, and collaborated using Whimsical for our designs and wireframes; and utilized the agile methodologies that we tracked using Trello.
Meet the project.
The project consisted of two main sides. The data intake side — this is where club members submitted an emoji that represented the sentiment of that member. Each emoji was tied to an integer value which would be used for analyzing the changes in sentiment. We cared about two things when looking at the reactions. How did the member feel when checking in versus checking out of the club? And how did the members feel about an activity that they participated in. The member sentiment would be input by the members themselves, but the Youth Development Professional (YDP) (usually a teacher/facilitator) would be collecting the sentiment using an iPad after each activity. Most of this functionality was already built out when we took over the project.
On the other side, we wanted to display all the member sentiment that was collected on a dashboard that only the Club directors — in charge of just their club — and the Administrator — in charge of all the clubs — could see and interact with. This is what our team worked on.
This team would work on this project for four weeks. The first of which consisted of planning and breaking down the features into user stories that would describe how a user would use a particular feature from start to finish. Those user stories were then broken down into tasks. These tasks were the smallest actionable unit of work that could be assigned to one person. This went a long way in helping the team estimate how long a given feature might take to implement by summing up the estimated time it would take to complete each task and adding a bit more time to account for meetings and other setbacks. After our Trello board was filled out, we estimated that we would be able to deliver all three major features in the three weeks we had left.
Meet the problem.
We had all this data, we just needed a way to display it. The most important part here was talking to the stakeholders and finding out exactly what information was relevant and what comparisons made sense to make and have accessible at a glance. We ended up picking a few unique ways of displaying the data that the stakeholders were really excited about.
This is where our team ran into our first big technical decision. The project already had a package called Plotly.js that was used to display some dummy data. Part of the team realized that there was not a lot of work done with plotly.js in the codebase and wanted to discuss changing the library we would be using to display the sentiment data. The main contender for the possible replacement library was D3.js which was argued for simply because it was the more popular library meaning the community was larger and therefore the access to help if we ever got stuck would be more readily available. Ultimately, we decided to stick with Plotly.js because it was the more developer friendly library and it already had the inspection and data analyzation tools we needed out of the box. Meaning we could be up and running a lot quicker, and given the timeframe we were working with, time was of the essence.
The frontend was in charge of displaying all the sentiment data of course, but that data had to come from somewhere. I was in charge of creating the endpoints in the backend using Java/Spring that would serve up that data. While creating the first endpoint I noticed a problem. The sentiment data that was being generated was completely random, and for our purposes completely unusable. For example, there was no way of calculating the difference between a member’s check in and checkout sentiment because any given member could have a reaction to any activity at any club. There could be checkouts before any check ins, and there could be multiple reactions but for different clubs entirely all at the same time. That meant that all the endpoints that needed to be created for the data visualizations that were to be displayed on the user dashboard would be serving data that just made no sense, and in some cases would not be able to be created at all.
Meet the solution.
The solution to the problem that the project as a whole presented was to break down the data into different formats. We had a leaderboard, which would rank the clubs by how much better their members’ sentiment was when they left the club than when they came in. The stakeholder was especially excited to see this feature so we built it out first. We also had an alerts page which was a collection of outliers that the stakeholder wanted flagged so that someone could reach out to a member feeling particularly low. This was important to the stakeholders because this feature could potentially help identify club members that may be going through a particularly hard time or are inflicted with a mental state that needed to be addressed. Last but not least we had the graphs that the user is greeted with upon successfully logging in. This is the more general way to analyze and compare the data.
As for the seed data issue, the solution was simple, but it was definitely not easy. I had to rewrite the seed data so that the data would make sense and mimic how a member would input their reactions while using our app. Specifically, that meant picking a random member, a random club, and between 1–4 random activities. Then generate a random reaction to each activity and sandwich those activities with a check in and checkout at that club each with their own random reactions.
Meet the result.
With the leaderboard, alerts page, and the initial dashboard we had a pretty complete set of features to display relevant data to the users of our app. We hit the minimum viable product (MVP). While the features are complete features on their own, they can definitely be improved upon for future iterations. The biggest room for improvement in the frontend would be to display additional graphs that would provide insight to other areas that we did not have time to implement. We have the average sentiment for each activity displayed, but there were a lot of comparisons and analysis that would be useful to our stakeholders.
The other major improvement would be a feature that lets the user pick a timeframe to filter the data over. This would make for better comparisons and predictions. Building out this feature will definitely bring its own challenges. From a technical standpoint, adding the date filtering functionality is going to be challenging. The data somehow needs to be altered so that the database contains data from the past. As it is now the data being generated is created within 4 seconds. Meaning if we wanted to show all the data for a given month we would only see data for one day and a bunch of empty days. The dates need to somehow be programmatically generated for the random reactions being produced by the seed data so that there is an even spread of reactions over a reasonable period of time. This is not an easy task because the creation times are being automatically generated when the data is being populated into the database. Going in to change the dates is not an easy task; made more complicated due to the fact that we do not have the same reactions by the same members each time. The data is random so there is no way to go in and grab a specific reaction and change the creation date because that exact reaction may not exist the next time the backend is restarted.
Meet the future.
My code has always been personal. I have worked on projects on my own since I started coding. Working on a team, I had way more eyes on the code I produced than ever before. My code now under scrutiny with each pull request meant that criticism and feedback were inevitable. I had never had my code criticized before. It was not a great feeling. I did not take it well at first. It felt like a personal attack… at first. After some reflection I realized that this code was not just mine. It would become part of a larger code base that other people are also working on. My code being bad or messy would lead to more work for my teammates and anyone else that might work on the application sometime down the line. By not producing clean code I was potentially making a lot of people’s jobs that much harder. Being told that my code was not up to the standards set for the codebase was hard, but getting that feedback was a growing opportunity for me. I now welcome feedback. Getting proper feedback is so important for growth. Which is why I now actively seek it out. I ask my peers and teammates to offer some kind of feedback.
Up until now most of the projects I have worked on have been personal projects. This is the first time I really worked with a team so closely and for this long. I developed communication skills during this labs experience that will definitely be worked on and refined going forward. I learned how to be a part of a team. I learned how to communicate issues and blockers that might setback the timeline on the tasks I was assigned. I also learned how to take an idea, in this case a road map, and turn it into a product. We broke down the roadmap into user stories. We then turned those user stories into actionable, detailed, atomic tasks that were assigned to developers to be completed. These tasks were worked on until we had a full feature, which was then released as part of the product. Shipping features, not just code was a big shift in thinking from how I was working with code until now.
Despite all the hardships and challenges, working on this project was definitely a positive one. I grew so much as a developer. I learned new programming skills in technologies I had never worked with. I gained experience working on an awesome goal focused team. And most of all I learned what it is like working on a project that could potentially change thousands of lives for the better. I went from a relatively inexperienced developer to a confident team player who is enthusiastic for feedback and personal growth. I’m proud of the work we did and I hope to someday see how the app we worked so hard on affected the lives of those who will use it.