Conquering My WebDev Bootcamp: Lambda School Labs

Lambda school labs is the final boss, if you will, of the Lambda School curriculum. After some 9-ish months students are brought together to complete a cross-discipline group project. It works like this: Lambda assigns a few different teams to work on their own interpretation of the same product. For two labs cycles, the stakeholder critiques and communicates what they would like to keep, improve, or do away with for the final product. In the last cycle of labs the best of all the teams versions are brought together into one cohesive and robust final product.

(U)nderstand & (P)lan

My team consisted of four web devs (myself included) and three data scientists and we were assigned to work on the Human Rights First: Police Use of Force website. Human Rights First is an independent advocacy and action organization that challenges America to live up to its ideals. They believe American leadership is essential in the global struggle for human rights, and work to encourage the U.S government and private companies to respect human rights and the rule of law. To that end, they chose to work with Lambda School to create a website that aggregates incidents of police use of force in the wake of the George Floyd civil rights protests. The goal of the site is to arm reporters and laymen alike with the information and empower them to decide for themselves what does or does not constitute police violence.

We were the second labs cycle to work on the project and for our version we were asked to improve on an existing map component, implement additional data visualizations, and add a dashboard component meant to house a users saved data. After spending a week discussing ideas, developing user stories, and reviewing the code the last team had left us with we were ready to get to work.

(E)xecute

My contribution to the project was meant to be two-fold: I was to create a dashboard component and some additional data visuals, like a graph. I decided to first tackle the dashboard as I (foolishly) thought that would be the less time consuming of the two. The problem was that we could not seem to land on what we wanted the functionality of the dashboard to be. Was it only accesible to users with an account? Did it show saved queries or incident results? Over the first couple of weeks of labs we kept working and re-working what we wanted this dashboard to be and I kept making and subsequently abandoning a myriad of different dashboard components.

Finally, I went rogue and decided to just set it up so that we could at least have the “use can save incidents to dashboard” functionality once our backend had the necessary endpoints. Feeling slightly discouraged, I moved on to creating a chart for the incident data. The idea was that the user would be able to explore the incident data saved on their dashboard in a number of different ways. I chose to make a pie chart using amCharts that would display the data “categories” which is basically an array of strings detailing the type of force used during the incident.

Lucky for me, amCharts turned out to be an absolute powerhouse. Easy to set up and every chart option comes with default styling that looks clean and attention grabbing. No need to handle the math for the percentages or to handle toggle state for the legend, amCharts does it all with only a few lines of code.

So we had the chart, but the data it was displaying was all hard coded. Enter, my team mate, who would end up turning us all into React-Query devotees. With this powerful state management library we were able to write one hook to get the data from our backend which we could then use where ever it was needed thought having to make multiple axios calls. With that and a simple helper function that filtered the specific data we needed, we were ready to roll. Using this same methodology we were also able to integrate a team members bar graph that was ready to go, but lacked the data.

(R)eview

I think we all wish we had had more time with it, but ultimately this was the final product:

We ended up merging the dashboard with the map, which I think was a much better decision both aesthetically and for the user experience. The next labs cycle will get to bring all of the best parts of each teams project together to create the final website. They will likely have to improve on the map even more as well as the dashboard depending on what aspects of it the stakeholder wanted to keep. They will also get to really put React-Query to use as we did not have the time to implement and make use of all it is capable of.

Final Thoughts

There’s a lot that can be said about the labs experience. There are definitely areas Lambda can improve upon to make it a better experience for students. But, as with a lot of things in life, it is what you make of it. I am leaving labs with a renewed creative spirit and way more confidence in my abilities. I am excited to take the tools I have learned and use them to create projects I am proud of. Here’s to graduation🎓✨.

Full stack WebDev living the expat life