A Team Built To Build
Fourteen months ago dozens of students joined a new cohort at Lambda School and have been learning together to become the worlds next wave of Full-stack Web Developers. I am one of those students.
“The Problem”
During the last week of September 2020, I and four other students were randomly selected and put on a team to try and fix the problem of pet owners not having an easy way to find local pet groomers and schedule appointments for their animal family members. This was a tall order for 5 people who may have only started coding about a year ago*, but daunting as it was we all took the leap into the unknown…again.
*See my previous blog post for more background.
Joining Lambda School in and of itself was large leap into the unknown. I myself left a promising career in biochemistry to pursue a career in full-stack web development. So far it has been completely worth it, and I haven’t even graduated yet or started hunting for a job. In just one year my fellow students and I have learned about a dozen coding languages and libraries. On top of that we’ve been trained in user experience design, how to collaborate as a team, giving and receiving feedback, and many other crucial “soft” skills. So although we are relatively new to this, we have been built up individually to work as a team in order to build something even greater.
Our Situation
Now that we’ve been built as individuals and a team it’s time to understand what we will be dealing with during this build. We were given a code base that was built using a lot of libraries that we’ve never used before including a third party authentication for users. This means that it would not be a simple build, but a large researching and learning experience. Not gonna lie, this made me nervous.
It’s one thing to be taught how to use a certain library and another to have to figure it out yourself. To compound the issue there were multiple different libraries that interacted with each other which really complicated things. A finely tuned google-fu would come in handy, and a great plan would be a must.
The Plan
The plan for any build can be just as complicated as the coding itself. We really dug deep to make user personas, user stories, user flows, wireframing, and design systems. We had two basic user personas, customers and groomers. User stories are things that each user persona would potentially like to get from the app. Using our combined backgrounds and life experiences we were able to create in depth user stories which is the most important step that will steer how you go about the user flow, wireframe and design systems. Each user story is also essential to breaking down the project into tasks.
A large task that I worked on applied to several user stories dealing with both user personas. User stories like, “As a user I want to be able to create a profile,” “As a user I want to be able to select wether I’m a customer or groomer,” “As a customer I want to be able to add my pets to my profile,” As a groomer I want to be able to add all of my business locations,” “As a user I want to be able to schedule appointments,” etc. Can you guess what this task was all about? *drum roll* …… building the database in the backend!
We used Trello.com to keep track of all of our tasks. Here is the task card with a high level checklist overviewing what we needed to do to build the database for Release 1. We used knexjs to build it.
“Sorry. We are experiencing technical difficulties.”
If you build and app and never run into bugs, “Do you even code?”
Bugs in the code is basically the life of a developer, and boy did we live the life during the last two months. Our fears were realized again and again while working with an existing code base built of libraries we’d never seen before. And the complications of working with an a third party authentication service went about as we expected as well. We had a lot of questions and when the answers weren’t readily available we went through days of trial and error to fix the bugs. Some of the fixes ended up being super complicated while others…well they took a long time to figure out but….
I spent most of my time pair programming in the backend and playing the role of quality control by reviewing pull requests for our github repos. The pull requests had their own kind of bugs that by the time we figured out the solution we were facepalming ourselves so hard that I can still feel the fingerprints in my forehead. It was one of those “Well it took a long time to figure out but…man, the solution seems almost petty.”
The bug that stands out the most came from linting errors. We spend hours trying to figure out why it kept telling us to delete empty spaces (not to be confused with empty lines). It would say to delete 5 empty spaces on lines 5, 9, 12, 13, and 15. So we’d delete them. But then it would say to delete 2 empty spaces and the paragraph marker at the end of the line, for the same lines of code! So we’d delete those and then it would say to add a semi-colon to the end of the line and an empty space on the next line. We added the semi-colon then be back to where we started! It was baffling. We had our indentations done very nicely for readability but our code should work even if there was no indentation. It was commit after commit before we realized the problem.
Built-in formatting specifications. Our code base included an opinionated code formatter called Prettier. It required our files to be formatted in a very specific way or else we would be forever doomed to run into these linting errors. After going through each and every file and reformatting them using Prettier we finally had a fix to our quandary.
Delivery! …sort of
We only had a short amount of time to work on building this app, so as with many projects of this type we delivered an updated code base for the next team of devs to continue our legacy. But this doesn’t mean that we just added more libraries to a repo. We actually built a functioning and deployed web application that can be found at https://g.expressgroomer.dev.
It may not be everything that we had hoped and dreamed, but it works! And with our contributions the next team to pick up where we left off will be much better off.
What does it include?
What you can see:
- Users can log in
- Login is authenticated by Okta
- Upon logging in users reach a home page displaying the app logo, welcome message with username embedded, and links to other pages in the app.
- From the home page users can reach the “profile-list” page, “my-profile” page, “edit-profile” page, or log out.
- Each page on the site has a link back to the home page.
- On the “profile-list” page users can view a list of test user profile cards.
- On the “profile-list” page users can filter the list of test user profile cards using the search bar.
- On the “profile-list” page each test user profile card displays the user’s picture, name, user type, has a place for a user rating to be visible, a button to view the user’s profile (functionality will come with a future release), and a button to flip the card over (in the future the back of the card will display more user information).
- On the “profile-list” page there is an icon for the “map-view” where the customer will be able to see groomer locations by area on a map (functionality will come with a future release).
- On the “my-profile” page users can view their profile.
- On the “my-profile” page users can see a short welcome message, their username, e-mail, and photo.
- Users can edit their profile on the “edit-profile” page.
- On the “edit-profile” page users can update their name, e-mail, and avatar URL by submitting the built in form.
- Submitting the form redirects the user to their “my-profile” page which displays their profile with the updated information.
Here are some videos showing how to navigate of the site and the features listed above:
What you can’t see:
The backend database now has tables already created to support future releases of the app. Most of the tables are also seeded.
Future releases can now include features like:
- Users can choose their user-type (Customer or Groomer).
- All users can have user ratings (customers and groomers can rate each other)
- Groomers can add multiple business locations.
- Each business location can add their address, phone number, business hours, and animal specific services that they provide, etc.
- Customers can add pets to their profile including animal type, name, color, birthday, and a photo.
- Customers can schedule pet specific appointments with groomers.
- Customers can add payment options.
- etc.
The repos for both the front-end and back-end have updated README files, documentation, and even more libraries and dependencies than the original code base.
What does the future hold?
Thanks to the work of our team future releases of this app can be wonderful. We strengthened the foundation so that our successors won’t have to deal with all of the same hardships that we faced, like authentication, linting errors about formatting, state handling, database scheming, etc. I foresee a lot of possibilities from future releases.
I look forward to seeing functionality for customers to be able to add pets to their profile, search groomers by area on a map, schedule appointments, share their location, and pay groomers.
I anticipate groomers being able to add multiple business locations to their profile, complete with addresses, phone numbers, business hours, and animal specific services.
What do I expect most of all for future teams? “Sorry. We are experiencing technical difficulties.” Because what is a developer without bugs to fix? Although our additions to the codebase are many, and our data base schema in depth, we built some of these things without knowing exactly how they would interact with each other.
For example: We knew that we would be using mapbox for location services, but we weren’t exactly sure how a user’s address needed to be formatted to be able to work well with the mapbox library. So we did the best we could to anticipate what mapbox would require and built data tables to reflect our assumptions. Using the given database to make user locations appear on the map is something that a future team will have to figure out and I don’t suspect that it will be easy.
My Takeaway
I learned a lot about myself during this build. Admittedly the biggest thing I learned is that some of my soft skills are much better than some of my technical skills. Other things I learned are that: I could definitely use a refresher on some front-end skills like redux state management; I am better at building a back-end than I am at building a front-end; I am very good at finding flaws in someone else’s code; and my decorating skills could use some help.
So most of my time was spent building the back-end database, reviewing pull-requests to find flaws, and helping a teammate who was dealing with some serious language barriers and needed someone to help explain things that were discussed in team meetings and other school requirements.
To give an idea of my input through reviewing pull-requests a teammate had this to say:
“Hey man just wanna say i appreciate your feedback in the github PR…really helpful and involved… honestly inspires me to give better feedback and will be more in depth going forward. It’s really helpful and makes me feel we’re on the same page so thanks again.”
And the teammate with language barriers told me:
“Thanks Tyler you are life saver.”
All in all I have more determination and clear goals to sharpen my technical front-end skills and overall strengthen my technical back-end skills as well as soft skills that employers are looking for. I plan to do this through reviewing previous school lectures, Udemy courses to help me learn how to more quickly adjust to languages/libraries I haven’t worked with before, and building out my own side projects.
