Walking Into a Construction Site With Grace
Lambda School is a six month boot camp that covers the basics of web development. More specifically, starting with HTML, CSS, and JavaScript, then moving to frameworks like React and Express for frontend and backend respectively. The last month of Lambda School is reserved for Labs. Labs is meant to simulate a fast-paced work environment where you are put into a team of about eight people. In the team, you are either handed down a project from a previous team along with a roadmap and an MVP (minimum viable product) to work towards, or you are tasked with creating a product from scratch. In either case, we would have regular meetings with the stakeholder(s) to make sure the vision was right and a product meetings to discuss anything technical. I had the opportunity to work on the Lambda Alumni Network (LAN) project which was handed down to us from the previous team. This product is meant to be a forum-based networking platform for Lambda alumni.
Since this project was handed down to us, we had a codebase to work off of. We were tasked to develop a moderation system and improve UX/UI. Our first technical problem started on the very first day of receiving the project. One of the features of LAN was the ability to login using LinkedIn, which also means we had to have valid developer tokens to access the app. It took us about four days to get that issue figured out along with other bugs that were preventing us from getting the app running. We made sure everybody on the team was good to go and we updated the documentation to avoid this happening to the next team.
Once we started looking at the app itself, we could figure out what we needed to do to achieve MVP. As a team, we ended up splitting into three groups: UX/UI, bug-hunt, and backend.
One of the things that the backend group was looking into was the implementation of an authorization. The way the project was handed down to us, the authorization was based on a number system where if you had a role_id of “1”, you were a normal user. If you had a role_id of “2” you were a moderator. The problem with this was that these roles were global and we wanted to scope a users “role” to a specific room (like a subreddit on Reddit). Taking a step further, we wanted to accomplish this with permissions instead of a pre-defined role. This means that instead of having role_id = 2 we could define what a moderator is with permission codes. So by default, every user is just a user, but when they enter a room they might have special permissions. In the end this implementation didn’t work out.
The UX/UI group (this is where I spent most of my time during Labs) started by looking through the current app as it stood. In all honesty, the app itself didn’t look very good so we established that we wanted to completely redesign the UI. In terms of the UX, things weren’t great either, so after a lot of discussion among the UX/UI group and the rest of the team, we chose to start from scratch. After the first week of planning, creating wireframes, and user flow charts, we had another decision to make. The previous team had strictly been working with Styled Components, and since we were starting fresh, we could either stay with Styled Components or switch to a component library. The component library that is currently recommended by Lambda School is Ant Design.
Considering we only had three weeks to build an entire app, we chose to go with Ant Design. This is where the first technical problem popped up for the frontend. I’m assuming this project has been around for a while because when we went to install Ant Design, the react-scripts dev dependency was very outdated. In hindsight, this was a very easy problem to solve, but it wasn’t very clear what the problem was at the time.
After we got Ant Design working, the work flow was much faster. Within the first day of working with it, we had the new dashboard up and running. Then we worked on showing the contents of each room. At this point we were also discussing the option of changing the verbiage of “post” to “discussion”. In the end we settled on “discussion”, but it’s inconsistent with the backend verbiage.
With that being said, the frontend codebase was a complete mess when we started working on this project. The way it stands right now, not much has changed. The approach we took in working on this was creating a separate app on top of the current app. All of the work we did lives inside of an inappropriately named “assets” folder where we could access the new app by going to a /sample route.
Obviously, this isn’t ideal, and if we had an extra week, we would have had this figured out and organized before handing it off to the next group. The best we can do right now is to document our work during Labs and give suggestions on how to go about organizing this mess of a codebase.