We have liftoff! We’ve got a fully fleshed out project plan with a flowchart, a wire framed UI model and database ERD, a weekly meeting schedule, and a GitHub repository full of code. This project almost seems like it’s going to build itself, all thanks to the completion of my least favorite step and one of my weakest skills: PLANNING. It’s just not the way my brain tackles problems naturally. I like to dive in right away and figure out problems as they crop up. This approach has worked great for 90% of my coursework so far but a bigger group project like this requires a different tact, one where I must pump the brakes and take a breath. And I did! And it worked!
First of all, a quick shout out to my teammates who are SUPER on top of their game and just as invested in this project as I am. Communication has been excellent and it’s made this phase of the process a lot easier than it could have been. I’ve learned in courses past that the initial contact is the most important, and ground rules that were never laid down turn into big problems later. Fail to tell your teammates you’re expecting daily commits? Sit around stupidly waiting for non-existent pull requests to come in. Putting expectations on people without communicating and discussing them is an exercise in futility. This is a relatively easy problem to avoid, especially when your teammates are engaged and committed to success. Lucky me!
OK, so everybody is on board and ready to go. What next? Hold your horses, let’s take another breath. How about instead of immediately jumping into code we take a moment to outline our project and diagram the pieces we need to make something coherent? Just because I understand the value in breaking everything down into tasks and adding them to a project management system doesn’t mean it’s not still tedious, but I’ve now seen the massive difference it can make. Splitting up features three ways has made the project seem, well, a third of the size it was before we divvied things up. It seems kind of obvious but it’s been SO easy for me to gloss over this step. I love that we have a database ERD to consult! I love that whenever I feel unfocused I can go to my task list and just pick one! It’s not like I’m missing out on any thrills this way, there’s still a TON of ways to get lost in the weeds as I learn the ins and outs of mobile development and React Native. I still get plenty of opportunities to code my way out of a bind. The project plan gives us something to fall back on though, and I can only stray so far before coming back to the light.
Ok, so we’ve got our app all planned out and our workflow is taking shape, let’s get into development! This week I put together some boilerplate React Native code using the Expo framework and leveraged the Expo API to grab the user’s location and display it on a map. We’re off and running! Having some React knowledge has also made it pretty easy to get started fooling around with the way React Native components work, and I even got a little router working in our App.tsx file (trying to force ourselves to learn some TypeScript) using the ‘react-navigation’ library. My excellent teammate has created a Google Functions ‘server’ for handling our data, so this week’s task is to see if I can access it through the app. Exciting stuff, to be sure. Looking forward to a week of problem solving and getting to know these powerful tools and frameworks.
Until next time!
Leave a Reply