My Software Engineering Bootcamp Experience or Failing Upwards
To begin, this is a summary of my experience in the Flatiron Software Engineering 3 month bootcamp. With no prior boot camp experiences on my belt, I did not know what I was getting myself into. I took a few years worth of community college at Lone Star in Texas and at University of Houston, both in study of Visual Communication and Graphic Design, respectively. The community college experience feeling not very challenging, more like high school+ and the university experience a near perfect balance of challenge and social time, I thought the boot camp might tread more in line with the university experience but I was far from correct.
My cohort started in October and day one was chaotic, some people were ready to go, but I was not one of those people. We were doing a week’s worth of work in one day. Or at least it seemed that way and, to be honest, that’s not far from the truth. And it was not until the next day that I finally got help from my instructor to get my environment set up for coding. You see, I made the mistake of purchasing a windows laptop instead of an Apple MacBook. My assumption being that a Windows laptop is like a Swiss Army knife in comparison with to a one function knife that I assumed a MacBook would be. Well, I may have been right about that but not in a good way. With the amount of freedom and capabilities unavailable in an Apple computer that come with Windows also come with an equal amount of possibilities for incompatibilities and issues not found with Apple. Since Windows personal computers are unique from one another, different chipsets, different memory, totally different version builds, the shear amount of differences make using a pc in the software engineering world an uphill battle at any moment’s notice. And yes, errors and incompatibilities still show up with an Apple computer but since it is the industry standard computer, most of those problems have been solved and are easier to correct because the lack of hardware and software diversity than on a pc where even if you have the same error, a hardware or software difference may not be compatible with the solution. Well, enough about Windows v Mac (though Mac is totally the winner in this case, no contest).
So I got my environment set up, finally, after a whole day of hoping to get help but all I got was suggestions to read the instructions again. Anyway, I gave up trying to get help till the day after the first, already behind on labs, feeling a soul crushing amount of pressure to get to a point I felt so far from, I wasn’t off to a good start mentally and that compounded with time. I did what I could to do all the labs, putting too much pressure on myself to achieve a 100% completed phase 01 set of modules. A fool’s errand to be quite honest. My mistaken study method took be as far as phase 2 but no further. It took me failing phase 2 to realize I must change my study tactic. My tactic that favored completion of labs over understanding the content both burnt me out and caused me to get pulled back a phase. It was a brutish tactic that only led me to frustration and the depletion of my willpower. I only realized there was a better way too late, too late to graduate at the earliest possible date. But being held back was the best thing that happened to me as of yet in this bootcamp. It gave me the chance to truly solidify the content in my understanding, come back stronger for the next cohort. Failing gave me one more blessing, it brought me to a cohort with a completely different, positivity charged environment. Though my previous cohort had some cool people in it, the vibe was very isolating, but not this one, no sir.
In the new cohort, I felt a sense of sincerity and openness that allowed for a very positive experience where asking questions during lecture don’t make you feel behind or stupid. Where we can approach any and all cohort-mates for help or work on a mini project together to solidify concepts easier, faster. A cohort where the instructors made it a priority to start the day positively and make it a joy to wake up in the morning to code and learn from them. Where interaction with the instructors is blanketed in mutual respect and oftentimes an epiphany of knowledge if a question was asked and answered in the clearest, quite honestly impressively understandable way possible. During the lectures before in my first cohort, no one would ask questions, most people had their cameras turned off, myself included. Heck, I didn’t bother with going over the lecture recordings until project week of phase 2, the week that I retook and failed the phase 2 code challenge. My mentality during my time in that first cohort was to go it on my own and just do labs, mistakingly assuming labs were the best source of knowledge for me since they required active use of something I was taught in a previous module but in the end, very little stuck with me from those labs since they were a bit one-time use for me, though the option was there to start them over, repeating the same code didn’t sound like a great way to learn. Even worse, I didn’t feel open to asking questions, I wanted to stay isolated as that was the vibe of that cohort. My only chance to break out of all those bad habit was to fail and learn from it.
Now, I’m in the best cohort I can imagine has existed at Flatiron School, in our first week of phase 5, coding our capstone projects. I learned to learn after failing and getting held back. And to finish this blog I’m going to leave a few tips here for someone looking into taking a code bootcamp that helped me get to near the last phase at Flatiron in the 3 month software engineering program. It was the coding along with the lecture recordings and creating my own mini apps that helped me get to phase 5. Screenshot snippets of lecture code with a self-typed explanation of what is going on with the code also helped a lot to break apart the individual code blocks and get a better understanding of how they work and what they are doing in relation to the other bits of code that all work together to push out that one deliverable. That’s another thing, I organized the screenshots by the deliverables they outputted so I could understand what the overall goal and use of those code screenshots were and collected them into a deliverable folder for the sake of organization. I got a MacBook for the bootcamp and I cannot imagine going back to Windows to code willfully and strongly recommend going this route as well. Last but not least I would not have gotten this far without the help of my cohort. It really is the best cohort and without it I would have dropped out much sooner.