Introduction
If you're wondering if you can complete Flatiron's software engineering bootcamp as a flex student, you definetely and most certainly can. But I hope that I can get the message across that it is not easy, and your life is going to look a lot different over the next 20, 40, or 60 weeks (or 59 weeks in my case).
I originally planned to finish the program between 20 and 40 weeks, but ending up doubling that due to work commitments, relationships, traveling, and becoming an expat in the strange land that is Argentina.
I have worked on completing the program. from Austin, Seattle, Puerto Vallarta, Buenos Aires, Patagonia (even stuffing myself in a cabin for a month to refocus), Belize, and Guatemala, where I am currently writing this post. I have done all of this while doing third-party monitoring of USAID-funded aid assistance in post-ISIS Iraq, which is more remote-work-accessible than you think.
The beauty of this program is that all this is indeed possible, at the price of some measurable level of sanity, but possible nonetheless. I would recommend this program to anyone with a full time job or other serious responsibilities to confront, and those who are clinging to remote work in the face of consistent return-to-office requests post COVID. It is not easy balancing responsibilities, and I would have to count the number of times I’ve had to reschedule 1:1s with my instructor on three hands, when work somehow has the ability to schedule meetings exactly during my 1:1 slot.
Journey throughout the phases:
Phase 1:
From the very start, I immediately began to reexamine normal tasks in my daily life and applying coding to them. I thought about how I could store mundane information in arrays and objects, and once spent an hour to sweep a kitchen in terms on functions and event listeners.
I still believe that this is the most challenging phase. You are presented with something completely new and have essentially re-learn how to think, especially if your someone with no formal STEM education (other than acing physics in high school, thank you Mr. Canafax). I took many notes trying to drill the concepts in my head, but found that I did not use them that much. I freaked out many times, and congratulated myself too early many more times.
Phase 2:
Things are still hard, but I found that it is much easier to learn new concepts and immediately apply them. I wondered why they didn’t introduce React earlier, as it truly makes front end programming easier, and I found myself saying in my head ‘why didn’t they tell me this existed before, this just makes life so much easier and why did I spend all that time learning phase 1 when I could have just been doing this?” A little flawed logic, but if you’re like me you’ll find that half your logic is flawed anyway.
By this time I really began to know the concepts by heart. I hand-wrote several fetch requests on full sized pieces of paper (I didn’t have sticky notes and forgot Amazon Prime existed). I remember once when I. think it then took me an hour and half of thinking through broom sweeps of my kitchen floor, in terms of increments, setting and updating state, and clearing that state whenever I left the Kitchen.
My daily remote work and my remote coding bootcamp became a living application itself, and I began to think of each room as a component and how I could pass information between rooms and deciding where shared state should live so to speak (in the living room most often than not).
Phase 3:
This was the most deflating phase for me, as it felt like I had just been taken several steps back. You start with a completely new language (and the syntax and the code just looked ugly to me in my opinion, big gripe there). There are completely new concepts, such as object orientation, SQL, and relationships between back-end data.
I think I just got frustrated that this phase seemed not be not to be a natural extension of phase 1 and 2, and I often wondered why this information was relevant, especially SQL which still holds a personal grudge.
But just stick with it, things started to click for me when I learned about Active Record and Active Record Associations. Things will ultimately click during the last module of Web API with Sinatra, and I finally knew why I spent close to two months trudging along. The phase is all just really about the relationship between the front-end and the back-end, and I saw the benefit as I started to work through my project.
Phase 4:
I worked through this phase relatively quickly as I finally just committed myself to sit down with the code with nothing else to do, and did so from a small little cabin in the woods (you might not need to go this far, but if you feel that you’re falling behind and not catching up, sometimes extreme measures are warranted). This seemed to balance out anyway, as I took a long break after the curriculum for the holidays and spent a lot of time developing my project.
This phase goes back to the comfort afforded by phase 2 and the prevailing manta of “Hey, things are still hard, but I’m getting a hang of it a lot better now at least.” The lesson of Model-View-Controller is one of the most important conceptual lessons in the curriculum in my opinion. I had similar thoughts of “wait, we could have just been using Rails this entire time?” Again flawed logic, but I now have a deeper appreciation for both phases 1 and 3.
As I worked through the rest of the program, I found myself continuously coming back to the lessons in the early part of the curriculum, especially concerning migrations, generators, routing, params, strong params, and error validation.
Similar to my insanity demonstrated in phase 2 with the oversized fetch requests everywhere, I applied the same with error validation. The fetch requests were replaced with voice memos of the process of the validation. I spent a lot of time in the guides outside of the curriculum and learned much about the roles of each of controller, model, and serializers.
I never thought that before starting this phase this would make sense to me…
.. but it very much does. These lines concern protecting the database from bad data being saved, rejecting that data with an understanding of just when those validations would be checked, the relationship between dependent resources and displaying nested JSON in fetch requests, and having another resource (menu item) exist without having to be assigned to to parent menu resource.
I explain data validation in more detail in a previous blog post I wrote here.
Thanks to the long break I had around the holidays, where I gave myself permission to finally take a rest and revisit these concepts, and because of the relatively slow pace of working on the project once I began, I believe this project review was my strongest.
Phase 5:
This is where it all comes together, and it is definetely the scariest phase. It kinda feels like you’re forcibly thrown into the pool, but in contrast to the old analogy, you actually know how to swim this time. The pool just happens to be much larger and deeper than you expect.
I struggled to come up with an idea of just what to do for this project, and went through several ideas either ruled out by my instructor or myself. But once I got going, the going got, and it seemed natural enough and fitting enough to finish out the program proudly. This phase gave me ideas on the next scary step: the actual job search. As much it was challenging, I found it be a good reflection of just how I could demonstrate all that I’ve learned in the program, and I feel like I can continue to develop the application even after the program ends (which I guess is kinda the point).
You can check out my phase 5 project here.
A Send Off
To conclude, I’d like to finish with some of my biggest tips for success in the Flatiron flex program. If you’re thinking about doing it, please take these tips to heart. I like to think that I can now speak with some authority on this.
Please Read These:
My biggest tips for any poor soul that stumbles upon this blog post:
1. Relation to Daily Life: No matter the pace, integrate coding into your daily life. You don’t have to code everyday, and I would go so far as to say that could be detrimental. The concepts need time to digest, and proving to yourself the concepts still make sense after some time means that I have learned them, not just memorized them (thank you school tests). Think of how you can think about mundane tasks and chores in terms of JavaScript and Ruby. Say it out loud. Even if people think you are a tad crazy.
2. Work according to your interests and profession: Create projects that are relevant to your interests or work. It makes them much more engaging, and it feels less of a requirement and more of something that you can use. I still use my phase 2 books application for my guilty procrastinations. I then moved to creating applications that are more relevant to my work in my phase 3 and phase 4 projects. They loved it, and we are working now to develop some basic CRM software (sub-contractors in Iraq still use Skype and WhatsApp for important work notifications). My phase 5 project is the most relevant to daily life. I plan to live in Argentina for the remainder of my job search, or until I get something going on my own. The 100% inflation in Argentina wreaks havoc. My local pub has already agreed to start using in some capacity upon completion, and that’s enough of a start for me (but comes with a whole new sense of anxieties).
3. Connection to others: My biggest regret from the program, by either extension of conflicting work schedules, travels, grasping for some semblance of free time, or just plain unwillingness on the false belief that I can do this on my own, led me to not interacting much with other students. Flex students will feel isolated, it’s part of the nature of the program unless there is active effort to not feel that way. I reached out to live students residing in Austin and we had a picnic in the park. That single interaction went a long way knowing that’s actually other human beings experiencing this. You don’t have to meet up, but respond when others are asking about a problem, attend community events, go to office hours. Do what is necessary to feel that connection and shared identity with other students.
4. Program pacing: Truly work at your own pace to the best of your ability. It’s helpful to commit yourself to a pace, but it is not necessary if that creates more stress than it relieves, and if you feel can keep yourself accountable to meet general deadlines you have set for yourself.
5. Pacing of Projects: As an extension of the above, take your time with your projects. Don’t rush it. This is your time to cement your learning and review all the concepts you learned. Do a little each day, not a lot. Even I had no other responsibilities, I think I would struggle heavily completing a project within a week or 10 days.
6. Accountability: If you aren’t in touch much with other students, at least tell others who you trust in your life what you are doing. They can keep you accountable, ask about your progress, and ask about something that you learned. If you’re surrounded by all non-techy people such as myself, this is a really good opportunity to truly explain concepts like they're five. If you can explain it simply, and if they have no coding experience and they can understand it, you’re doing it pretty well (keep in mind these explanations probably won’t work during project reviews and live coding). If somehow the other person is still interested, teach it to them! Maybe you can even perhaps trade Spanish lessons for some basic JavaScript principles, which worked for me until I started to explain things in a way too complex manner, signaling to me that I didn’t really know the concept.
7. Resources: Use other resources outside of the curriculum! The curriculum is not the be-all end-all source of omnipotent knowledge you need to figure problems out. As I advanced through the program, I continuously found the curriculum to be used as a starting point, not the final solution for challenging bugs. Use the resources often included at the the bottom of each lesson. Watch videos. See what others have done and how they fixed it.
8. Working through bugs: Reexamine your relationship with bugs. When starting the program, I thought bugs were a reflection of my poor coding skills. They are not. They can be something as simple as overthinking a concept or simple mistakes in syntax, or they be a strong signal that you are just not understanding a concept all that well. Use your debugging tools, see the values of state as you navigate your applications in the react tools, see how your redux state changes (pro tip, click that ‘diff’ tab and take away approximately 17% of your frustration).
9. Permission for yourself: The biggest tip I can give is patience, and giving yourself permission to be flexible on your expectations. This program isn’t easy, and it wasn’t meant to be. Take breaks, change the timeline on yours goals accordingly. As part of the flex program, no one is going to tell you that you need to speed up (except perhaps on weeks 50-59, and everyone will tell you on weeks 58-59). There are many success stories of new students completely changing gears and getting jobs in less than a year and having a completely new life. That’s great, but it should not be expected, especially when you have other big factors in your life that deserve attention. The biggest plus of the flex program is that ability to be, well, flexible, and you shouldn’t beat yourself up just for being inflexible.
10. Cheeky note: Do your blog posts. More than one per phase. Just do them. Don’t wait until April 29th, 2023 for a March 2022 start date :)
Top comments (0)