Over the past month I really challenged my self to take an idea in my head and build out a product. I wanted to build something that not only could be shown off to potential employers, but something I could eventually use. The app is a cookbook where a user can: search for recipes, add searched recipes to a menu, then generate a shopping list based on those recipes. To build this app the main tools I used were React, Redux, Rails, and PostgreSQL. I learned a lot going through this process, but there are three main lessons that stood out.
You will crash your app. When this happens don’t panic, take the time and work through the problem. Some problems will take an hour to solve, some will take weeks. Don’t let the fear of tackling a problem for a week stop you from implementing something new. Initially, I let this happen. I took out features from my app because they lacked a clear defined path for implementation. My app was losing the core things that made it cool because I didn’t know how to build them. When you strip away all the features that make your app cool what you're left with is a glorified todo list, and no one wants to spend a month building that.
There's no harm in making a new branch and experimenting/testing some ideas. I learned more trying and breaking things than I ever did on set lesson plans. Worst case scenario switch back over to your stable branch with no harm done.
Whenever you are implementing an external library in your app, read up on it. I spent many hours trying to solve problems that could have been fixed with a quick glance at a repo’s issues page. Quality of an external library’s docs was a big factor, for me, on whether I'd use it or not. This was my process in researching certain libraries.
- Read the official documentation for the library
- Check out the repos Issues
- Look up questions related to the library on stack overflow
- Read articles about the library
Initially, I felt this process was excessive. It felt I was wasting time reading instead of actually trying to implement with code. What I found was that I had a better understanding of the library, and when it came time to actually use the library I knew potential problems that could arise and where to look to solve them.
Please, if there is one thing to take away from this post it is this, spend time designing. My design process was: sketch out what the app would look like, then jump into code. I suffered. Without proper design you can really lose control of your apps. Here are some problems I had that were attributed to poor design.
- Duplicate components
- Too many class based components the could have been functional
- Unnecessary CSS
- Duplicate code
- A lot of unnecessary local state
- A way too complicated file tree
As of today my app is functioning and works, but maintaining it would definitely be difficult. For me, I think a good exercise would be a rewrite with an emphasis on design and maintainability using tools like esLint and standards like airBNB style guide.
Overall, I really enjoyed the process. It really is satisfying taking an idea in your head and transforming it into a product. Even more satisfying were the lessons I learned along the way. If you have any questions or want to share things you've learned feel free to reach out!
In this article, we’re going to explore why young programming languages with modern features can’t be adopted quickly. Additionally, we’re going to take a look at one exceptional example that got specific parameters right to be both young, modern and mature, just ready for adoption at small and big scale.