Surviving a Data Science Bootcamp

About
First, a little bit about me.
I am currently working through the final week of the Flatiron Schools Immersive Data Science program, the final step being an all inclusive capstone project.
The entire course is extremely extensive and attempts to cram two years of graduate school into just five months of intense courses.
The capstone is designed to showcase my freshly acquired data scientist toolkit, and has to be created from the ground up. No pre-made datasets from Kaggle allowed.
While working on the final project I was offered a full time position as web developer AND data scientist, which had been my dream job from the beginning.
From my vantage point at the end, and with the entire experience relatively fresh in my mind, I thought it would be a great time to share my experience with others.
I’m going to share some of the concepts I used during this time that helped me stay ahead of the curve and get a job offer two weeks before the end of the course.
Community

The most important aspect of the data science Bootcamp, or any bootcamp for that matter, or actually life in general, is community.
Being part of a community that shares similar goals and interests is invaluable.
There is a saying, ‘don’t code alone’, which at first may seem trivial, but in actuality is the best advice you could follow when learning to program.
Before attending the Flatiron School, I attempted my own programming education. I used the free curriculum at FreeCodeCamp.org, which I highly recommend by the way.
I worked my way through the majority of that program over the course of a year and a half, completing thousands of hours of full stack web development material by myself.
Had I known then what I know now, about how much better it is to work as a team instead of solo, I would have immediately started searching the forums for a group of people to work together with.
The first thing I learned at Flatiron is how valuable it is to be part of a strong and dedicated community of likeminded individuals.
We worked together constantly, sharing our ideas and support with each other, all working together to achieve the same end goal.
We formed online study groups that lasted most of the day, and took turns teaching each other what we had just learned.
I was the strongest programmer, so I would teach topics relating to Programming. Topics such as web scraping, http requests and responses, object oriented programming, etc.
We had someone who was teaching math at a university who taught us the calculus behind gradient descent and about all the different types of data.
There was a place for everyone, and it felt great to be part of a team. There’s no comparison for the amount of motivation that offered, vs working alone.
Having that positive support during such a difficult process is invaluable, and even if you feel like you have it all handled by yourself, I guarantee you will gain invaluable knowledge and insight by having a team to bounce your ideas off of.
Bezos Rule

The second idea that helped me succeed came from an article I read a while ago about Jeff Bezos and the first software engineers he hired.
When he started Amazon, he put out ads looking for talented developers.
He didn’t want just any developers though, he wanted the very best he could find.
As such, his ad stated that he was looking for developers who were extremely talented and driven, but more specifically, he was looking for developers who could deliver products three times as fast as other developers.
The first time I read this I was impressed and motivated.
First, I was impressed because Bezos demanded the very best from potential employees, and he wasn’t afraid of setting the bar extremely high.
Most of us would look for developers who are ‘better’ than other developers.
The fact that Bezos wanted developers that weren’t just better, but three times as good, has changed the way I create my goals and expectations.
Secondly, I was motivated because here was a quantifiable metric for software developers.
I would like to make it clear that I DO understand a bad developer can throw up a bad product very quickly, but that is not what Bezos was talking about.
Instead, he expected the developers he hired to be able to create the highest quality product, and in ADDITION, he expected them to be able to do it in one third of the time.
Ever since I read about this I have been motivated to become one of the very best developers, to be able to apply to that job posting and know that I’m at the top of the industry.
Bootcamp was the perfect opportunity to practice this belief and to see it’s effectiveness in action.
If a module was expected to be completed in one week, and the project due by the end of the following week, I made it my goal to complete the module in two or three days.
I would then use the other half of the first week to do my first attempt at the module’s final project, and by the end of the next week, I would have finished three separate projects.
That meant that by the time everyone else had started working on their project for the first time, I had completed it once and was almost done with completing it a second time.
I know what you are thinking. What about quality vs. quantity?
What I found is each successive attempt at a project increased the quality exponentially. Not only that, but the time it took also decreased.
I have seen countless posts online confirming what I observed, that quantity is better than quality when you’re learning.
The general advice for learning web development is to create as many apps as you can, because each successive app is a learning opportunity and a chance to become more familiar with the flow, libraries, and tools you will be using.
This is how I was able to showcase some of the best student projects produced so far at Flatiron, and how I now have three times as much experience as any of the other bootcamp graduates in my cohort.
10x Developer

This last one is similar to the Bezos rule, and it’s a common myth in the software development world.
It’s more of an idea than it is a concrete label, and if not taken literally can make an excellent goal if you strive to be the best.
The idea is that there are developers who will solve your problems in 1/10th of the time, using 1/10th the number of lines of code.
Like I said, making it a goal to be 10x as fast and 10x as efficient writing code would most likely lead to disappointment, however making it a goal to be the type of developer who consistently aims to deliver the highest quality product in the least amount of time would be more realistic and would lead to an amazing developer.
There are countless arguments centered around this idea, and most of them take this definition literally like I warned not to.
Instead, I use it as a motivational tool, as a way to keep working when I could just as easily take the day off and let other developers ‘catch-up’.
I see a lot of developers do this ‘catch-up’ thing, where they finish their work for the day in a couple hours, and decide to take the rest of the day off.
With this 10x goal in the back of my mind, I’m able to continue developing after everyone else is finished.
Instead of feeling self-conscious or peer pressured to just take it easy, I remind myself that I’m not trying to be a normal developer, I’m trying to be a 10x developer, and 10x developers don’t put away their laptop just because they finished their assignment for the day.
I understand this kind of thinking is not for everyone, if it was for everyone then it would be the standard and then I would have to aim for being a 100x developer, so in a way I can be thankful that not everyone aims as high.
Conclusion

Getting through coding bootcamp is definitely not easy. I observed several people fall behind and drop out of my cohort. Some of them dropped back and retook sections, and some of them completely withdrew and chose to pursue another field.
For me, that was never even on my mind, because these goals and ideas are so far beyond the bare minimum that failure is not even part of the picture.
I’ll admit, there was a time that I failed in my personal goals.
Instead of working through the project at the end of a module three times, I was only able to do it twice.
By setting the bar as high as I did, failure meant only a sense of disappointment that I had been unable to grasp concepts quicker, though there was never any danger of falling behind in the course.
Instead of having a project built with three times as much experience, I was left with a project built on only two repetitions.
This was disappointing, but I still had a final project that was twice as polished as others in the group had created.
Coding bootcamp takes a ton of motivation, time, money, and most of all, a desire to succeed, and like many other things you get back from it whatever effort you put into it.
For me, it was a one time experience that would take me from self-taught developer to professional, and I wanted to prove both to myself and to others, that I could be great at this.
In the end, I am grateful to have the opportunity to attend Flatiron School, and the entire process was one of the best experiences I have ever had.
I got hired two weeks before the end of the program and can now say with great joy, that I’m a professional software developer.
Thanks!
Thanks for reading. I hope someone finds this information inspirational and is able to use the ideas here to become the best developer they can be.
Feel free to leave me any comments, questions, or feedback, I really appreciate the opportunity to talk about this stuff I’m passionate about.