Project Week
Last week was project week here at Flatiron, and it was absolutely the most informative and most soul-crushing experience I've had in this program so far. Our project deliverables were simple: a simple, single page React frontend connected to a Ruby backend. The real difficulty came from our own decision to make something way more complicated than the expected scope of the project. We decided to try and create a farmville/tamogachi style game, where you would be able to create an account, plant plants, watch them grow, harvest them, and buy upgrades. This idea would fall far outside the scope of the project requirements, still meeting them of course, but also being way harder than was necessary.
The start of the project seemed to go very well, enough that I became very optimistic that we would be able to achieve all of our stated goals. Unfortunately by that time, the seeds of our demise had already been planted. Between some initial confusion in our initial designs, mismanaged division of labor, and some overconfidence in our abilities, we had already cemented some pretty extreme flaws into our project, flaws that would only rear their heads as we approached what I thought would be the finish line.
Managing Expectations
The first of the two major lessons I learned this project was the importance of managing expectations, and had I employed this skill at the beginning of our project, it is very likely that we would have been a lot more successful in our goals.
At the start of the project, I had worked with my teammates to create a division of labor that I had thought fair, one partner would begin work on the ruby backend, the other would begin work on creating JS functionality, while I would work on the structure/design of our frontend. Unfortunately this breakdown of labor left both of my partners struggling for air, while I worked ahead largely unaware. If I had been paying more attention, I might've been able to work with them, co-code as it were, to help overcome some of our struggles and save us major time. In this regard, and in the least condescending way possible, I put too much expectation on my partners, expecting them to be able to just 'handle' their own assigned tasks, and that come week end, we would just be able to slot all three individual pieces into each other and have a complete and functional project. This was naive of me, and this failure of 'management' is something I will be sure to take with me into future projects.
Another thing that caused me to learn this lesson, was when my overconfidence lead me into a dead-end. For context, my previous project week had my team creating a React based quiz game, and our relative success in that project made me believe that it could be easily replicated and expanded upon. I thought that, so long as I kept forging ahead, solving one problem and then the next, that eventually I would solve all of our problems, even if it required pure brute force. Sadly, brute force can only get you so far, by the time the week was almost over, I had unknowingly built a system with a number of functional aspects, that couldn't be completed as it was because it was structured in a way that made it exceedingly difficult to implement the final pieces. All in all, I should have taken a slower, more precise pace, and I should have spent more time planning the structure.
Understanding Limitations
The other major lesson I learned this past week, was of understanding the limitations of the tools you have available to you; namely, React is not a game engine, and trying to use it as one is likely to cause you a lot of difficulty. At the end of the day, React did not come with the tools we needed to solve all of our problems, and while we could brute force it into doing what we wanted, we were creating A LOT more work for ourselves. I thought the reason I couldn't find anyone with my problems on sites like StackOverflow, was because I wasn't searching hard enough. Now, I think it is a lot more likely that this problem was caused by us trying to do things that were incredibly unintuitive for a React project. React isn't very friendly in regards to dynamically doing most things. We ran into so many issues regarding scope and order of functions occurring that I would honestly blame less on ourselves, and more on React not being built to function as we were trying to use it, unless inside specific circumstances. These issues with React did not become apparent until the very end of project week, and it quickly became clear that to solve them, almost everything would have to be restructured ground up to make up for React's weaknesses.
I don't want to misconstrue this as a bad workman blaming his tools, but more of case of "everything looks like a nail, if all you have is a hammer". The only tool we had was React, and while it could work with enough effort, we were causing ourselves a lot of headache by not using something better suited. In the future, I will be a lot more hesitant to make plans with my tools, until I better understand what all they might be capable of. Hopefully, working to understand these kinds of strengths and weaknesses will drive me to expand the amount of tools in my toolbox, not to discourage me from trying new and interesting things.
Top comments (0)