Making and Shipping an App with a Team: The Origins of Hamster Wheel
What is Hamster Wheel?
Hamster Wheel is an early childhood education app that includes three learning activities for children ages two to six. The activities include a spelling game, a coloring book, and a drag and drop game. The idea is to provide enough choice to keep little learners engaged, while giving them opportunities to learn and gain real skills while having fun. If you want to check out the app, you can download it here:
Why build a kids app?
Some believe that people are too attached to their devices — starting kids that young on screens is irresponsible. I hear that, and I agree to some extent. But here is the reality. Sometimes toddlers need to be engaged, and phones and tablets can aid in occupying them while the adults handle their business. Wouldn’t it be nice if kids were busy doing something productively fun instead of consuming mindless cartoons?
So I rationalized making an app for kids, I still needed to find my inner reason for making this product. What would be the driver that would keep my motivation up to see it to the finish line, especially when things get hard. I had to find the why for myself, as in why do I even want to be a developer? Why build apps? What it really comes down to is that I want to create products that allows users to do what I want for myself. I want to have fun while learning new skills. That led me to building an application with games for kids.
I found a team of like-minded developers, and we embarked on the journey to build this thing. Our challenge? Six weeks to bring an idea from a spark of inspiration to a viable product. Our team? Developers much like myself, in the early stages of our engineering studies. Our goal? Launching our app on the Apple Store, our users enjoying it, and we all become better developers in the process. Did we succeed?
Spoiler alert, you wouldn’t be reading this if we hadn’t. Nobody wants to read that story. 😉
Challenges of developing in a team
When first learning to code, I worked on a lot of solo challenges and tutorials. The benefits to working alone, is that I code at my own pace. While this certainly has it’s benefits, overall progress can be slower as there is only myself to complete all the tasks.
Another obvious drawback is that when I would get stuck in implementation, I had only myself to get unblocked. Thankfully I had an academic coach who helped me discover new approaches and helped me with vocabulary to find what I was looking for on Stack Overflow. Where would we all be without Google and Stack Overflow, lol. 🤯
With a team comes new types of stress
While working in a team is certainly preferable, there are some things that make working in a team harder than working alone. One obvious reason is I had to navigate other people’s ideas and take each into consideration. When you are the person that dreams up the idea, and you are the person to implement the tasks, you only have yourself and the end product to check in with. In a team, a project might be rolling right along, and someone comes up with an idea you hadn’t thought of. More often than not, it’s a brilliant idea that should be heavily considered. The draw back is that it usually means refactoring the code to accommodate the new idea.
Depending on how far along the project is, or how modular the code is, it could be a messy and complicated refactor. This can often mean missing initial deadlines and pushing the project back. This can also lead to long work days trying to unravel and reroute how data is flowing through the application.
While working in a team can bring new challenges to overcome, in the long run the benefits definitely outweigh the drawbacks. So how to you build a good team?
How do you find a great team?
First of all, start small. We made the mistake of trying to work in a 5 person team from the start. This meant that 5 different people with 5 different schedules had to try to come together to ideate, and get the ball rolling. Big mistake. I discovered that a great idea needs to be fleshed out to a certain point before adding more heads to the discussion. But before you add people, you need to know them well enough to take the chance on working with them. I now understand why tech interviews are designed as they are. Not every skill can be taught in the time you have to release the product. And soft skills are valuable skills to bring to a team.
One of the greatest lessons I learned while at developer school was how to identify good teammates. And believe me, it isn’t always about who is able to code what. I learned that personalities of developers, work style, and commitment to the product are equally important as to being able to write clean code.
When we first got together as a team we were given six weeks to design, code, and ship our product. This was an ambitious goal, however we were all up to the challenge. The first two weeks we brainstormed and researched. Since we hadn’t created any momentum, things moved at a snail pace. Additionally, each member on the team was balancing multiple obligations. A full load of classes with their required home works, internships, remote contract work, and commuting from the east bay to SF daily.
Even though the team had other obligations, we were all passionate about what we wanted to build. So passionate, that we made a classic novice error…YOU GUESSED IT. We waaaaaaay over scoped. By the time six weeks was over, we barely had met any of our deliverables.
The project pivot
Noticing that some of our blockers came from over scoping, we decided to
re-scope the project, ice box most of the feature creeps, and move forward with a leaner team ready to bang out the product in two weeks. I learned that changing direction in a project is normal, and not to fear moving forward with a product without moving forward with the entire original team.
We made a schedule that had us working together side-by-side for 15 hours per week. The thing I noticed that helped us gain momentum was to work in the same office. This lead to us being able to help each other get unblocked, and it kept us focused. The other thing we accomplished by working so closely is that we were able to form bonds that lead to ownership of the product, and accountability to each other. I also learned that forming a highly productive team that has fun working together is no easy task. Even though the final Hamster Wheel team was a dream to work with, the original team was challenging. I had to make a decision about whether the product goals were a higher priority than friendships. Sometimes you will have to make this choice, and it is never easy.
We shipped our app with a team of three developers in the end. We were wrong about shipping in two weeks though, it took us six more weeks to ship. Total time from start to v0 on the app store was 12 weeks.
While developing a product alone has its benefits, working in a team brings so many positives that I highly prefer to work in teams. I’ll still continue to work on personal projects, because I enjoy getting to make something for myself. However I know that I can accomplish a lot more when working with others, so I will continue to do side projects in small teams.
While in school I consumed a lot of knowledge. Most of it focused on leveling up my developer skills, but a fair amount of my education was about how to bring a product from an idea to a reality with a team of engineers. I also learned that I enjoy being an engineer more than I enjoy being in a leadership role. This is a very good piece of information to know about myself, so I can make sure that my actions are aligning to my career goals.
*When I started this article we had just shipped the first version of our app, and I wanted to share my experience for others who are embarking on the path of becoming a dev/engineer. By the time this article is being published so much happened. We released v1.1 of Hamster Wheel on the app store after presenting our product at demo night. I got a full-time position at an Oakland based startup as an engineer. And I started learning some new languages for the purpose of helping to re-architecture one of the micro-services at my company.
I’m going to try to keep writing about my experiences, without giving away any company secrets. Keep an eye on this space if you want to know what it’s like for someone to go from being an art teacher to an engineer.
Until next time. Ciao! 👋🏼