My Project Planning Journey with Flatiron
Having finished 4 team projects so far with Flatiron, one lesson I’ve learned is that project planning is one of the more important steps, if not THE most important step in any project. It’s the time where we take a vision or idea and manifest it into graphs, designs, lists, etc. Proper project planning can lead to amazing efficiency, while poor planning can lead to detrimental workflow. The implication that anyone can do this in a rushed period of time means that their vision may not hold as much value to them as they think, or maybe they’re just really good at project planning.
Bellow, I’d like to talk about what I’ve learned from project planning in each of my 4 projects.
Project 1: ZOMBO the Game ft. Lauren Yu
“Be the Chef that builds a menu based off of a seasonal vegetable, don’t build one based off of ravioli.”
In my first project, our vision was simple. A “CLI” based game that took the classic zombie killing idea and implement that into the command line through our very fundamental knowledge of the Ruby language.
Our game pitted hero characters against zombies in a series of fights, before each fight, the user was to choose a weapon that would lead to a weapon specific mini-game. The result of the mini-game would determine if the character kills the zombie, or gets killed by the zombie.
Initially, there was no mini-game aspect to this project. But because our initial idea was so simple, a simple win/loss system that had a character be killed or a zombie be killed each round, we were able to create the cool features because of the excess amount of time we had, which in the end became the heart of our application.
Lesson: There’s nothing wrong with starting out with a smaller idea.
Project 2: ML Blog ft. Ryan Wilson
“Don’t try to make a knife just to cut a fruit. Walk to the kitchen and use the knife there. ”
Project 2 began after we learned about the basics of building a Ruby on Rails application.
Ryan and I are both very interested in programmers on YouTube especially those with an exciting success story. Therefore, inspired mostly by this Clément Mihailescu video, we decided that we wanted to build a website that would hold examples of Machine learning algorithms like path finding and sorting algorithms while also functioning as a blog to meet the requirements of the project guidelines.
We thought that throwing together a blog would be simple, and to be honest, it was. What wasn’t simple though, was my personal resistance to using a styling framework like bootstrap or semantics, which ended my project 2 career by destroying 2 entire days worth of progression while I finicked with vanilla CSS. Eventually, with Ryan’s persuasion I jumped ship and we finished the website with bootstrap by the due date. Unfortunately, without any of the cool visual algorithms that we originally planned to have.
side note: none of those cool algorithms could have been done without learning how to use JavaScript anyways. However, more features could have been implemented if it was not for me wasting time.
Lesson: Plan the stack you want to use, & don’t use pure vanilla CSS.
Project 3: Battle Code ft. Paul Kim
“Two hands are better than one, don’t use one hand to peel oranges while the other one peels potatoes. Choose one to do first. ”
At this point we were taught basic DOM manipulations with vanilla JavaScript. Our project required a JavaScript front-end, and a Rails back-end. And low and behold, a vision appears for me to create a real time coding competition with technical questions where a player can see the opponent’s code live like it’s google docs.
While the project came out successful, my biggest regret is splitting up the project where Paul worked on the back-end while I worked on the front-end. In fact, I had just read parts of the “Mythical Man-Month” a couple weeks before this project where it says…
“Complex programming projects cannot be perfectly partitioned into discrete tasks”
Because of this mistake, I had no idea what fetches to make from the back while Paul had very little idea of what the data flow was in the front end. My code was messy and I really don’t blame him for not knowing how to help.
If I could redo this project, I would rather us both to work on the back-end and the front-end together.
Lesson: Splitting large bodies of work isn’t efficient especially in code, it creates disorganization which lead to a waste of resources.
Project 4: Draw-Off ft. Alan Banks
“Drawing out what you want your dish to look like isn’t enough, it’s important to write out the ingredients and equipment you think you’ll need.”
This is the final group project for the Flatiron season, a React and Rails stack. I’ve learned my lessons from the past and so before we even ran
“npx create-react-app”
I pulled out Paint and we started to draw out what we wanted the application to look like. After a revision with the boss, we cut down our app heavily, from a Jackbox pack of 3 games to just one game, Draw-Off. Alan and I worked on the back-end together, the front-end together, and everything went pretty smooth.
However, one common problem we faced was not knowing where our props are coming from, where specific states lived, and what exactly is causing the DOM to re-render, the cause of this being a poor file management system.
Lesson: Project plan your folders, it’ll make life easier in the long run.
