I’m in my final weeks of coding bootcamp at the Flatiron School — applauses all around for me 🥳 — and undoubtedly enrolling at Flatiron was one of my best decisions. I could not be more grateful for it having provided me this smooth transition into the tech world, as an introduction to programming could very well be overwhelming with all its different languages, libraries, frameworks, and more.
When I was a high school senior taking AP Computer Science, I looked at software engineering job posts to understand what I’d need to learn and know for my potential future. I was completely and utterly turned off by the posts’ complicated tech jargon and I prematurely decided that programming was “not for me,” proceeding to apply to colleges as a business major.
Needless to say, I found myself back to coding and as I reflect back on my overall programming journey, I wanted to similarly reflect on my last project at Flatiron. In general, I think the beginnings of any new thing (a new school year, a new chapter of your life, a new project, etc.) are the most important as they lay down the foundation. So I believe that before going into it, one needs a clear and organized frame of mind. With this said, I’m all about organization, which I try to apply to almost all aspects of my life, and after having finished a total of five projects at Flatiron, I am glad to report that I’ve (somewhat) streamlined my approach to beginning new applications/projects, which I believe as a job candidate will help me shine and later as an employee help strengthen my planning and organization for new projects at the workplace.
So, what does my process look like?
- Create a model associations chart to visually see how each of my backend models connect with one another.
Including the time to devise my overall idea and how each model and its attributes play a role in my project, this step takes about a day.
2. Create a preliminary flow chart to visually see how the user will interact with the application.
For this particular project, we were tasked to create at least 3 client-side routes, of which mine were the login, signup, and dashboard pages. I was having an incredibly difficult time with react-router 😰 and my application continued to break when I tried to add in additional routes. Although I’d already fulfilled my project’s requirements, I wanted to include the features I’d had come up with and therefore, I decided to work with modals for the first time (using MUI).
3. Design a wireframe on Figma to visually plan and imagine my end product.
During this step, I surf through Dribbble and Behance for inspiration, draw up some barebones low-fidelity wireframes on scratch paper and then proceed to creating a high-fidelity wireframe for my application on Figma, along with devising the color palette and typography. Overall, this takes about two days for me to complete.
As I design and code a product from start to finish, this step is the most crucial for me, as it helps me to see what features are doable in my timeframe and what I’ll need to include in my application. Towards the end when I add in CSS and stylize my components, this Figma file is my ultimate reference, which greatly speeds up the designing process.
While many of my classmates may not add much CSS to their applications, everyone’s priorities are different, as some may focus more on the backend capabilities, but as an aspiring front-end developer, with a strong interest in UI design, I don’t like to skimp on this part of my process. I find incredible pride and joy in being able to code my application the way I’ve imagined and designed it.
4. Start coding! Backend first, with frontend later.
This step, being the heart of my application, takes me the rest of the time I have for the project, which on average is about 10–11 days. For this project, since we had learned React most recently, I allotted more time to focus on my frontend code than my backend, which I probably only spent a day or two on.
With my planning and organization process discussed, I feel it pertinent to also admit that not everything went to plan. This is of course inescapable. The end design and features of my application stayed mostly true to my planning, but of course I had to make changes along the way as I continued to run into issues. These issues ranged from lacking enough time to lacking the patience with all the debugging, resulting in me having to cut down on some of the ambitious features I initially wanted to include, such as fetching from Google Maps/Places API, configuring Active Storage and AWS so users could hypothetically upload pictures from their trips, etc.
However, of all the issues I had with this project, I’d say the most notable was that of routes. Oh boy. Since I had configured user authentication, complete with the bcrypyt gem and JWT on the backend, it was extremely difficult with my current set of knowledge and time to solve the issue of preventing users from accessing certain pages if they were not logged in. I spent roughly three days trying configure more than the three required routes, but ultimately resorted to using modals instead, as I’d previously mentioned.
I had initially tried to add <Route /> statements across different components, so that private routes were only available in the private components (ones that were only accessible after the user logged in) but I quickly realized that my approach to this was incorrect and faulty. Instead, I decided to list all the routes in the mainApp component, like I should have from the beginning, and then render the correct component, depending on the path URL the user was on via the UserContainer.
With this, if the user was on the URL of “/login,” then the Login component would render. If the user was logged in, then they’d see the DashboardContainer component and if they were not logged in at all, they’d be redirected to the login page.
While I’m not confident that this is the correct method to go about separating components and routes for logged in users and for those who are not, this method ultimately worked and as the saying goes: if it ain’t broke, don’t fix it.
Of course, this just means I have further learning to do even after I graduate from bootcamp, but I must say given my current set of knowledge and time I was provided, I am quite proud of the application I built and I really do look forward to all the possibilities with coding as I continue to my programming journey.
