I’ve been told that Labs and Build weeks are supposed to mimic how working as a web developer in the real world is. Thus far, every experience has been borderline anarchical chaos.
Recently I asked a jr web developer if that was her experience out ‘in the wild’ as well, and her answer: laughter, followed by “yes, definitely”.
Refactoring code, inheriting old, incomplete code bases with little or no guiding comments, an avalanche of (sometimes conflicting) information from the stakeholder, learning new stacks, poring over documentation, and a team of humans determining their own workload.
Holy moly shiskomboli! How do you navigate such a chaotic environment? read on to find out…
The Project:
Village Book Builders is a non-profit organization that sets up libraries and schooling programs in villages to bring education to remote corners of the globe.
Currently VBB is building a computer portal for every member of its programs to create a centralized system for admins, headmasters, students, and mentors to interact and view theyre dashboards.
Our focus has been creating the login and sign up pages for some members of the VBB community as well as build out the headmaster portal so the headmasters can match up the students of their villages with mentors from around the globe.
Specifically I chose to work on the mentor/mentee matching program, creating an algorithm that pairs mentors and mentees based on specific parameters and returns a list to the headmaster of the potential matches.
My fears heading into the project were that I would not be able to participate in a meaningful way, and that I wouldn’t have the knowledge, expertise, or wherewithal to contribute to the project, because sometimes I’m not even sure what I’ve learned over the past few months, since its like drinking from a fire hose. Moreover, the amount of information provided by the stakeholder was overwhelming, and some of the desired outcomes were unclear.
Technically speaking
Our teams main goals were to add functionality to the different dashboards, and I specifically chose to work on a matching component that would help headmasters of a school program to pair students with volunteer mentors from around the globe.
One of the main challenges was we were given a dummy backend that was an incomplete view of the VBB backend without data that we needed (mentors), and without the ability to change the dummy backend. As such it was difficult to try to create code that was usable without making up fictional data objects that I didn’t know would match the real backend, potentially making useless code for the stakeholder.
We overcame it by 1) clarifying with the stakeholder the structure of the backend and objects we were hoping to access — a process that took multiple weeks — and 2) scaling up a complete node backend to mimic the dummy backend provided.
Along the way it became clear from reviewing the code that the previous build team left a few portions of the code unfinished that needed to be refactored, as pages were refreshing, which would be bad for folks using slow internet connections and destroys the purpose of creating a single page application with React/Redux.
The end is only the beginning…
I refactored all the code to ensure CRUD operations were working across all relevant user roles, and implemented a matching component that returns a table of users featuring a drop-down box that dynamically displays any potential matches. The table can also toggle between viewing mentors or mentees.
After selecting a match, the headmaster can click a button to assign the respective match to each other.
If I don’t get to it this week, future features would be to get a few filters so the headmaster can select different matching options besides the current stakeholder preference of time availability (gender, interests, language, etc.).
Also, if there were a button to auto-populate the matching systems it could be very convenient for headmasters to have the component assign the matches itself instead of having the headmaster go through each student or mentor individually.
Also, there might be a better way to pare down the matches, right now its a filter inside a filter which is a O(n²) time complexity, which as student/mentee enrollments increase will quickly bog down operations for folks using older or slower machines, which might be expected in a rural, third world program setting. If there were a way to refactor into a hash table function that would drastically cut down the time complexity.
Overall this was a great project to dabble in the perils and pitfalls of working “out in the wild” and was a great experience for me to put to use my research and development skills honed over the past year with Lambda School.
