That’s All, Folks! — My Journey During Lambda Labs
Lambda Labs is an 8-week intensive apprenticeship program. It takes computer-science students who just wrapped up a 2-month curriculum dealing in comp-sci theoretical la-la land and puts them into a learning environment that mimics what an actual team of engineers do day-to-day. Now, that’s not to say that computer science fundamentals are unimportant, quite the contrary — they set up any software engineer to have core knowledge of the systems that the tools they use day-to-day are built from. But moving from theoretical learning to practical learning always forces one’s brain to change gears.
My Labs team is building Apollo — an agile development tool that aims to solve the problem that often comes up with auto-generated survey notifications: they get ignored. Apollo is meant to solve this problem by requiring topic channel leaders to provide current context for every survey that goes out.
My hesitations going into this project were many: how is a team going to work efficiently together when we’re all student-developers? Won’t it just be blind leading blind?? I also was concerned with my own React front-end chops. It had been almost 8 weeks since I even touched a functional component, let alone integrating a fully fleshed out scaffolding to fit the project. I was sure I would fail out and never be able to get a working product put together by release 1. And yet, here we are at the end of the Labs portion of Lambda’s curriculum, with everything ready to go.
Into the oven it goes…
Some of the core functionality that solves the ignoring problem that so many daily notification applications face is to make sure the default questions that are asked of the users render dynamically, based on the context chosen. If the contextualized questions are simply a standard, one-size-fits-all list of typical questions such as “What are the blockers”, “How is the project going”, or “Is the timeline still accurate”, the people on the team who are expected to answer aren’t getting the best, most tailored questions.
This posed an interesting problem for us as the team of developers. We needed the context selected at the very beginning of the “Add New Topic” modal to drive which default questions were going to be passed in at the very end of the process by the topic leader.
The first step for getting the dynamic default questions to render based on which context was selected at the beginning, was to actually write out different context-specific questions that would be used as the defaults for each case. For example, if the topic relates to design, one of the default questions could be “Do you have any edits for the design team to make to the wire frames?”, or the engineering leadership may need to know, “Are the current load times up to speed requirement for the upcoming release?”
Once we had these custom default questions written out, they were ready to render dynamically — the most head-bending part of this component. What we decided to do was to log a numerical value for each of the radio buttons that could be selected on the first page of the new topic modal. Once they were selected, the topic state object would then be modified to show whichever index place of the default questions list matched the radio value.
Now we had our default questions rendering dynamically based on which of the topic radio buttons were selected on page one! We did it! We now could guarantee that the users who respond to the topic iterations would have properly selected context-based default questions that they would need to be asked.
This was a great exercise for me in re-learning the basics of component state management. We needed to pass props up and down the component structure, make sure we had our change handlers and click events all buttoned up, and ultimately were successful in getting proper context.
The (User) Story So Far…
My team and I just wrapped up the second release of our product, Apollo. The release called for the ability for a leader to generate a new topic survey submission and allow a team member so submit responses to that survey.
We have been able to ship a feature that takes in text input from a user and registers it in the database as a survey response. It then renders the full list of all responses by each member of the team. This can then be seen by all of the members of the user’s team so they can see the survey replies.
Added quite a bit to the styling. Making the frontend look clean, professional, and functional was a large goal of the last couple of weeks. And with the help of the team, we were able to achieve a very professional app.
A Look to the Future…
For hypothetical future releases, something technically challenging will be setting up notifications. We have toyed wit the idea of adding the Twilio API to send out messages to the users, but haven’t yet fully explored it.
This project has forced me to stretch my React knowledge in ways I never thought I would have to. Not only with building out components that render on the screen, but also dealing with state that touches multiple components across the entire app. It allowed me to learn new techniques for adding Redux hooks to the app to manage state, a skill I’m sure I’ll use regularly from here on out as a React Developer.