It’s crazy to think that the end of my Flatiron journey is actually here. When I started, I hadn’t planned on finding such an amazing and challenging bootcamp, much less getting accepted to it. My wife and I were having our first (and only) daughter, and I already had a stressful full time career. Over two years later, I recently left my career to finish Flatiron full time, my wife has changed careers, and raising our daughter has brought an amazing amount of joy and laughter.
During all this change, my learning has always been there. It’ll be strange to not tackle any new labs, or to not get stuck on a detail in a lab that was purposely included to make you struggle. A detail that was actually new, and would be introduced a couple lessons ahead in the curriculum. Sound familiar to you too? Those were great learning experiences. Learning that the answers are out there and can be found. And practicing those searches for answers helps you get better at recognizing the good information from the bad.
I ran into a lot of new learning experiences in my final project, too. I spent more time planning for my final project and working out all the details. I’ve done this before, but this time I wrote it all out, the views, the routes, the files, the models and tables, etc. I watched some project tutorials on Learn, and kept some notes. This really helped me get my project set up and running with the Rails API connected to the React front end pretty smoothly. Then eventually as I got into the detailed interactions of the front end, things naturally slowed down.
I definitely hit some walls that took a long time to figure out. I expected this to happen. One thing that I’m proud of though, is that the answers that I eventually found made sense. Usually, when I get stuck on something, I’ve had a tendency to go into trial-and-error mode. I’ll try changes to my code (sometimes even just guessing) that seem to make sense to resolve the issue.
But this time, when I was pretty stuck, I actually decided to just write the code out the way I expected it should work. I was surprised how well this played out. After writing what I thought should work, I would then address each error one at a time. This logically unfolded into code fixes that made sense, and helped me connect the differences between what I had expected to work and what was actually happening.
I think it’s a good technique to try if you feel pretty good about your ability to write something that you feel should work. If it doesn’t, you’ll learn one step (error) at a time why, and the learning will happen. It might seem counter-intuitive to just keep writing code when you see that it stopped executing the way you expected. But by finishing what you were writing, if there’s only one or two errors in your code, you’ll feel more confident knowing that you knew the rest of it and wrote it correctly. If you were to stop at every error you run into, you may not give yourself the opportunity to see that you can write your code correctly. And when you start making changes to your code to try and resolve an error, you can quickly find yourself down a ‘rabbit hole’ of changes, and not feel confident in your abilities.
Trust yourself and what we’ve learned at Flatiron. We’re all aware of ‘the imposter syndrome’, and the fear that we don’t know what we’re doing. I recently interviewed a CTO who admitted that everyone has it, that everyone worries about not knowing what they don’t know. So I think it’s more important for Flatiron students to feel assured by the quality of our education and how intentional each lesson has been. Most important, is that we’ve learned to be comfortable struggling through new concepts, and we’ve learned to keep going until we find (and understand) the problem and solution. If we draw on that experience, we’ll be very adept to handle the next challenge.
For me, the next challenge will be to find work that allows me the flexibility to be with my new family, the rewards of continually learning, and the support from kind people. I’ll let you know how it goes…