Though some of the concepts we learned in Ruby were pretty difficult, I didn’t struggle with getting my first Flatiron project to meet the minimum requirements. Don’t worry, that doesn’t mean I didn’t struggle at all.
Since I’ve been in the working world for a while, I understand the importance of planning. It’s a bad idea to begin a project without thinking through how you’d like it to work, what features it must have, how the different pieces might fit together and what would be nice to add if there’s extra time. But is it possible to plan too much? For me it seems so, especially if all that planning gets in the way of pulling the trigger and getting things done. I’ve never considered myself a perfectionist, but I did find myelf trying to get things right the first time around in this project. Over and over, because it turns out that isn’t a helpful way to approach coding (duh)!
Before starting on my project, I wanted to watch all the videos and read up on how to do everything I might possibly want to do. But this type of approach hinders me from making decissions getting things done. After a few false starts “testing out” the creation of multiple CLI gems, I had to remind myself to just keep moving.
Repetition is one of the ways I learn best, so I have been approaching the Learn curriculum with that in mind. Knowing that even if I go on a tangent, no matter what I’m doing it’s probably going to worthwhile for me, and I’ll at least learn something. But sometimes it’s hard for me to find the balance between planning and practicing, and making decisions, moving forward, and making things happen.
While working on this project, I found myself going down so many rabbit holes. I might have been trying to make a change or a add a feature to my code, for example building a specific relationship between two objects. Instead of taking things one step at a time, I kept getting ahead of myself, thinking it all through as i made the first change. That would take me from one method to another, one class file to another, and back again until I didn’t know where I was anymore. I’d have to stop myself, confused and without having actually made a viable change to my code.
Maybe even worse, getting ahead of myself kept me from commiting my code as often as I should have, leaving me with a messy commit history at best, and at worst I’d end up inadvertantly losing work because I didn’t push my changes up before losing the IDE connection. I learned it’s important for me to break bigger tasks down and tackle them one step at a time while at the same time surrunder to the reality that i’m not going to be producing great code right away. I can always refactor later! I’m sure I’ll look back at this project and see my code for what it is: amaturish. There will be embarrassing code smells, roundabout ways of getting somewhere and obvious things left out. But at least I got it done, and in the end, that was all I needed to do.