My Lambda Labs Experience

Going into Lambda Labs I had no idea what product I was going to be helping build, I did however know this was going to be the biggest codebase I had ever worked with.

I have been through multiple build weeks at Lambda School creating simple full stack apps with my peers going through the Web development track. This was my only reference. Build weeks could be accurately described as frantic sprints that involve conflicts (merge conflicts), a lot of pressure, and of course a time limit. Lambda Labs, on the other hand, lasts 4 times as long as build weeks. My simple assumption was “We must be building something huge!”. Though the product I went on to work with was definitely large; it was not the hackathon experience I was originally expecting.

Express Groomer is an app that connects Groomers directly with pet owners for basic grooming services. The problem that express groomer is trying to solve is to massively reduce friction between groomers and pet owners connecting and transacting peer to peer. Express Groomer achieves this by letting pet owners actively search by location and various other criteria in order to quickly find a promising groomer that lives nearby. Both the groomers and pet owners have personal profiles with the pet owners additionally having simple pet profiles to give groomers more information and context about the pet they might be servicing. This is just a small overview of the various features and functionality embedded in Express Groomer.

Reading over all of these moving parts and pieces for this first time made my head spin. I was already overthinking, pondering on details, and wondering how it would all fit together. This was in hindsight a foolish response given that I had a whole team of full stack developers along side me to tackle this project. I had a great feeling from the very first standup with my team and our project lead Cory. Everyone seemed enthusiastic, friendly, and capable. After sometime having ice breakers and getting onboarded into the whole labs experience my team and I began the process of mapping out our build.

This planning phase was not your typical group project format. We expressed each feature we would be building on as a user story. We were taught this approach to help us get familiar since it is a common industry practice, and additionally it gives us an opportunity to look at this feature set from the users point of view. A user story is essentially just a problem or desire expressed from the users perspective. With this user need defined we can see how our feature will potentially address it. Each of these user stories were laid out on a shared trello board with each story having an associated checklist for the given feature attached to that story. This protocol was a totally new experience for me and a valuable practice for shifting my perspective on planning a build.

Here are the two feature releases we were working with during labs:

• Account Authentication (release 1)
• User Profiles (release 1)
• Groomer Profiles (release 1)
• Ability to search for Groomers (release 2)
• Advanced search capability for Groomers (release 2)
• Appointments / Scheduling (release 2)

After some time familiarizing ourselves with the codebase we decided to begin the build process by doing some refactoring and cleaning up around various parts of the front end repository. My first task and the first trello card I was assigned to was refactoring the Redux state management system currently implemented in the app. Redux is definitely one of the more intimidating areas to work within but I was happy to start out with a bit of a challenge.

Next we had to refactor how the routing was being done throughout the app. Much of the dashboard which is the center of the users experience was setup with a conditional rendering design. This conditional rendering mostly worked but did not change the routes which is a huge problem for a frontend that is getting all of it’s resources from a RESTful API. This refactor ticket alone took about 2 days and had us stumped more than once, luckily we figured out a balanced trade off for a relatively simple solution.

Closing out this initial cleanup phase we felt much more comfortable with our experience in the codebase. From here we mostly began breaking up into teams of two to tackle features ticket by ticket. In these teams of two we would switch back and forth between navigator (support) and driver (writing code). This role swapping was a great system and I enjoyed popping back and forth between the more microscopic view of writing code and the macro view of navigating and continually looking ahead. One of the early tickets that really stands out in my memory was the basic implementation of the Groomer search component. Most of the pieces were in place but I had to revisit the conditional rendering to get each individual groomer profile page to render with the correct route whenever a user clicked on them from the search component.

After tackling my first handful of tickets I felt comfortable and confident with the full dev cycle. Certain lazy coding habits I had adopted (such as making very few commits) were easy to avoid and stay cognizant of in this transparent team environment. I knew that every commit I pushed on any particular pull request would get carefully reviewed by at least two of my peers. This process was not friction-less though, we ran into our fair share of failed PR reviews, merge conflicts, and database scares.

Once I had helped build and merge a few other disparate PR’s I began to settle down into a set of features that were much more closely tied. At that time there was a pets button on the dashboard that led nowhere. We had a pet grooming app with no pets. This is what I began to work on starting from the backend. Me and my peer Gui began to dive into the all of the migrations previously implemented and run on the backend to get a better understanding of the tables and their connections. With a bit of tinkering around we updated the backend to have a pets table that was associated to the pet owners in a one-to-many relationship. The one (Owner) could have many (Pets) but not the other way around.

With the backend aspect of the pets feature set working we had now had to write the pets API, implement the API calls on the frontend asynchronously through Redux, and create all of the front end components and forms to plug into it. All three of these tasks were quite different undertakings and each had their own unique challenges and curve balls. When everything was said and done we had 6 PR’s, 4 tickets completed, and the fully implemented pets features! There are definitely a number of things I would have liked to polish and touch up but I and my teammates all grappled with a lot of complexity and came out with a working product so that’s what really matters.

As it currently stands Express Groomer has its release 1 and release 2 feature set fully functioning. You can register as a User or Groomer, search through all the groomers, customize your profile, set your rates (groomer), add your pets (user), and search by location and pet specific criteria to find a suitable groomer.

Completing Lambda Labs I haven’t just improved my coding skills and knowledge I have gained valuable experience across the entire software development lifecycle along side an agile team of full stack engineers.