At Rithm, we believe that one of the best ways to prepare students for jobs as web developers is by giving them opportunities to work on real-world projects. Working on personal projects can be fun, but working in a team or on an existing code base gives students insights into the day-to-day challenges of a developer that they might not otherwise learn. Our 8th cohort is nearing the end of working on these projects, so we spoke with our students Sarah Kaplan and Zac Bennet to get their perspective on the experience.
Describe yourself in a few sentences (where you’re from, what you did before the bootcamp, something unique about you).
Sarah: I started out my career as an English teacher, first in Venezuela and then as a high school teacher in Boston. I was using a variety of different apps in my classroom to try to make instruction more personalized for students at different levels. I got really interested in EdTech and decided I wanted to learn to code, and hopefully contribute to making software that helps teachers more effectively support their students.
Zac: I studied Economics in college, but worked a lot with social justice organizations. After graduating, I joined Teach for America and taught Math and Business for three years in Oakland, CA. I used technology everyday in my classroom and it allowed me to do really incredible things for student learning. But as I used technology in class, I became increasingly frustrated by the design and functionality of the products I used. I decided to transition into tech to help create products that would benefit the lives of students and teachers.
How would you describe the experience of working on these company projects? Can you tell us a little about the projects you’ve been working on?
Sarah: I was working on team Lipslut. Lipslut is an e-commerce site that sells makeup in order to benefit progressive causes. They’re about to launch a new version of their site, so we were implementing new features for the updated site.The site is built with the JAMstack, meaning it doesn’t have its own backend server and makes use of various microservices. Most of the projects we built during our Rithm school coursework had a backend server, so this was a cool opportunity to learn more about the JAMstack. Because the site makes use of many microservices, we got to tackle a wide variety of different problems, like making GraphQL queries to load data about the products for sale, or setting up webhooks to connect to an external API and update the site when a product is sold out.
Zac: I worked on the Cherries team, a branch off of the Lipslut team. My team and I were building an online earring subscription service, essentially from scratch. It was really exciting to build something new based off of the creative vision given to us. Although we were building from the ground up, we did want the code to be similar to the Lipslut codebase for the sake of consistency. We had to learn some new tech in order to contribute to the project. One new piece of tech was Gatsby, a way to build static dynamic pages using React. Gatsby compresses all of your files and assets into a single HTML page which is uploaded to Netlify, allowing for faster load times. We spent the first day playing around with Gatsby and building our own little apps to get up to speed quickly.
How large is your team? What have you learned by working together?
Sarah: Our team had 8 students, but we were divided into 2 subgroups. My group worked on the new version of the Lipslut site, and another 4 students were developing a new site for a jewelry subscription service. I had the chance to pair program with each member of my team, which was really valuable because everyone has different strengths. There was one student in our group who was a CSS wizard and did an incredible job styling components. There were students who were really efficient at debugging and troubleshooting problems. It’s great to work with different partners because you can ask each person about their process and learn from their strengths.
Zac: I worked with a team of four people. I was able to work with each person on my team to complete a variety of tasks. It was a little intimidating to be working on production level code and building such a large codebase. I was glad to have a partner to think through our approach to things and ensure we were on the right path. Towards the end of the project, a lot of us began working independently on different tasks. We had to learn how to work independently and rely on our intuition and the documentation, but also work collaboratively with our peers and instructors if we were really stuck.
What are some things you have accomplished while working on these projects?
Sarah: We created a variety of different React components, like a product details page that listed the ingredients for each product. We also implemented a voting feature so that, with every purchase, users can vote for an organization to support. The organization with the highest number of votes receives a portion of the profits. Since the Lipslut site does not use its own backend, we had to do a lot of work to send and retrieve data that was being stored in various APIs. Product inventory data was stored in one API, the product descriptions and ingredients were stored in a content management system, and the vote totals were stored in another external service. For every component, we had to write a GraphQL query or a Lambda function to connect to these external services and send or retrieve the data that was needed.
Zac: Since we were building the site from scratch, I did a lot of work with CSS to style the app and ensure the styling adjusted appropriately if viewed on a phone. We would take the design mock-ups and translate that into code to make it come to life. We also learned how to use GraphQL, a querying language, to query Contentful, our Content Management System, for the assets needed to render the page. Contentful would store all of the text and images that would be displayed on the page, so if you change a picture on Contentful, the page would update with the new image. This is helpful for people with non technical backgrounds to easily make changes to the website. Then my partner and I implemented search and sorting functionality for all of the different products. We used a third party library, Fuse.js, to search the different products and display them to the user. We were especially proud of our work on search, and gave a lightning talk to our peers on how we used the library to implement search.
What was the most challenging thing about working on your project?
Sarah: One challenge we tried to tackle was adding a data visualization that showed a map of the United States and compared the purchases per capita in each state. The dataset was very large so we had to write a function to preprocess the data before the site would build so that it would load efficiently. We also played around with how to calculate the opacity for each state as a ratio of the purchases per capita. This task was challenging because there were a lot of different options for how to represent the data, and we wanted to make sure the visual representation accurately communicated the relative quantity of Lipslut products that were sold in each state.
(Here’s what the data visualization looks like… GIF credit to classmate Andrew P.)
Zac: In the past I really tried to avoid using CSS because it was confusing to me, and I could never figure out how to center things. I wanted to use this project as an opportunity to improve, so I volunteered for as much CSS work as I could. I ran into a lot of great challenges, like learning about styled divs, resolving overlapping CSS selectors, optimizing the design on mobile and debugging my own code when it wasn’t working properly. After a while, I felt my confidence and the quality of my work skyrocket.
As a developer, what have you learned as a result of working on production code?
Sarah: For me, the biggest value of company projects was working with a codebase that used a slightly different tech stack than what we had learned. I had to do a lot of research, looking at documentation and checking Stack Overflow. Now I feel a lot more comfortable jumping into an unfamiliar framework.
Zac: Making code efficient, readable but also similar to the Lipslut codebase was a great learning experience. There were a few times where I had accomplished the task at hand, but did it in a different way than was done on Lipslut. I had to go back and change it for the sake of consistency. I had to be very intentional about how my code would be read by others, since multiple people were reading through it.
It is not only motivating, but fun to work on code and features that will be used by many people. Check out more about our company projects here!
