Lambda School: What I Learned
Growing up, tech has always fascinated me whether it be software or hardware. In my latter years of high school, I dabbled around with different programming languages building small scripts here and there and having a blast. After high school, I was pretty lost on my future career and what I wanted to do. After lots and lots of research, I thought back on my small coding endeavor, and I found Lambda School, a rigorous, online coding school. After looking into them, I enrolled and have been working through their curriculum for the last year or so. More specifically, I’ve been working through the Full-Stack Web Development track at Lambda.
Going in, I expected the material to challenge me and push me. Let me tell you, Lambda did not disappoint. In a way, I surprised myself with what I pushed through and what information I retained. The program consists of training in Front-End, Back-End, and Computer Science material. At the end of the program, they pair you with a small team of developers from Lambda to build an application in just 2 months. This section is called LABS. This time around, we had 2 months to build an app called Express Groomer; a place for users to find pet groomers in their area.
Going into LABS, I had a few presuppositions that I had set in my head beforehand. I was very nervous about the time crunch, release date, and work load with such a small team. It turned out that the point of LABS was less about the actual code that was written and the final app’s functionality, and more so about the experience, teamwork, and planning. I will say, there was quite a bit of emphasis on the planning portion of LABS. So much so that the first 2 week of the project were dedicated to just planning and building wire frames.
My LABS team and I utilized HTML/CSS, ReactJS, and Redux, along with Ant Design, Okta, and MapBox API for the front-end. The back-end was built with NodeJS, Knex, and Postgres. Our final goal with Express Groomer was to build an app that allowed people to easily find pet groomers in their area, check availability/pricing, and book an appointment. We needed to create a profile page for both users and groomers to set up, search functionality to show groomers based on wanted criteria, rating system for groomers, appointment booking, and secure payments within the app. Needless to say, our plates were full during LABS.
Like I said before, there was a large emphasis on planning throughout LABS. I hadn’t experienced planning on such a large and methodical level with previous projects so it was quite the learning experience. Planning was sectioned off into multiple key steps. We had a general roadmap of Express Groomer given to us by Lambda. We looked at that roadmap, and put ourselves in the shoes of our users. What would they want? What would they expect? We took all the answers to these questions and added them to our Trello board. We then went in and looked at a given answer and broke down all the tasks for front-end and back-end that we would need to accomplish for that feature to become a reality for our users. Below is an example of a card that I worked on.
In this case, I was tasked with creating the migration table for users. This was one of the first tasks I worked on since users and groomers are an integral part of this app and the endpoints associated with them are used very frequently. In the case of this app, register was already created and integrated with Okta, so this users table was made for collecting data from the user to populate profile pages, section off groomers from users, etc.
Features, Challenges, and the Rubber Duck
Features wise, the project was split into 3 “releases” that each had their own tasks. Early on in the integration process, we had lots of issues with Okta verification as whatnot since we hadn’t worked with Okta in the past, and it was partially integrated coming in. Coming in, I had never used PostgreSQL before so initial setup and integration was the first hurdle we encountered. Above all, we had issues with our environment variables and all the ports matching up with a given Postgres installation. Once we figured all that out and it was running on our server, we moved on. Our first main feature was creating a profile and assigning a role when the account was registered. Like I said earlier, we were told to not worry about a sign up feature as seed account were already created for us. Profile creation came with its own challenges on both the front-end and back-end.
For me, I was on back-end with profile creation. Login was already created, but I was responsible for storing the information a user gave us and setting up extra endpoints for front-end to pull from. For this, a lot of the endpoints for profiles were already implemented, so I only had to add a few model functions and make some edits to our seed data. For the seed data, I added the randomized roles for development purposes as seen below:
In essence, I wanted the initial profile to remain the same, but all other profiles had randomized IDs and such. I also used FakerJS to add random info each time the database was seeded.
I was also responsible for all migration tables, seed data, model function, and router files. These consisted of profiles, pets, and businesses. I followed a similar approach to each. Each router operation was passed through a middleware function to make sure the user was logged in. For example, here is a put request for pets and the associated model function:
While working through an endpoint to get all profiles with the groomer role, I was a little lost and kept getting errors. Because each profile had a specific role (we didn’t allow 2 roles), I planned on just adding that functionality to the model and router files for profiles. Turns out, the URL was the issue. While that endpoint was in the profile router, the URL was /users/groomers. After much troubleshooting in the wrong direction, I realized that it was seeing groomers as a user ID. I was in a team meeting and asked if people saw anything out of the ordinary, and in asking and explaining things out loud, I realized what the issue was. I ended up putting that get request in a separate file with a separate URL. Below is the code I landed on:
From that team meeting, and from comments from my project lead, I realized the importance of what’s known as the rubber duck debugging method. In essence, it’s when you explain your code/error out loud as if you are explaining it to a rubber duck on your desk (unless you have a physical rubber duck on your desk, in which case, I salute you). It always reminds me of times in high school when I was lost on something, brought it to my teacher, and when I started talking about it, I ended up solving it on the spot without any comments from my teacher. Following that, I started really implementing that technique and it has helped me drastically with my debugging and overall understanding of my code bases.
Current State
As of right now, our app’s features are login/logout, profile creation (groomer or user), the ability to add a pet to your profile with a photo, current shots status, etc. as well as the ability to edit, or delete a pet. We also have a landing page with styling. The back-end has a few more things built out such as the ability to add, edit, or delete a business as a groomer, but they haven’t been implemented on the front-end quite yet. Below is a picture of the landing page and pets list page.
There are many features we discussed in planning that are yet to come such as groomer search for users, appointment scheduling, ability to make secure payments, and a messaging system. Each of those come with their own challenges and more in-depth planning for how we can make those a reality. An obvious one for me is secure payments. Researching a third-party software and implementing it is always time consuming and can be confusing to jump in on.
Gleaning
LABS taught me a lot. One of my largest takeaways was definitely the importance of planning in a team environment. The initial two weeks of planning made the entire experience so much smoother, and helped me stay on track with tasks. I also learned how to work as a team to accomplish tasks and openly communicate. More than anything, LABS inspired me and showed me how much fun programming is. Towards the last legs of school, I started to feel a little burnout and I didn’t have that enjoyment that I did in the beginning. LABS really showed me how satisfying, and fun coding and planning is. I am so eager to start job search and be able to put these skills to use in a real-world setting and build relationship with my future colleagues.