What I Learned in Coding Bootcamp, Part 1
I’m currently a student at one of New York’s top coding bootcamps — Fullstack’s Grace Hopper Program. I just completed the first six weeks, otherwise known as “Junior Phase”. This is the “straight-up learning portion”, full of lectures and workshops, in which students learn all of the concepts that we’ll go on to apply in longer projects in Senior Phase.
Because my bootcamp has been highly successful in placing grads into jobs all around the stack, I figured it might be helpful to outline exactly what we learned in this first phase — the concepts our founders and hiring partners deem necessary to be a successful full-stack developer. Basically, if you’re trying to go the “self-taught” route, this is a curriculum that’s been success-tested.
Note: There will obviously be disagreement about what concepts, frameworks, and libraries are most important to learn, and everyone has an opinion. This is just one bootcamp’s take on a curriculum. That said, Fullstack has a reputation for constantly reworking its curriculum to stay up to date with best practices and skills most in-demand from employers, so I think it’s a pretty good starting point!
What We Learned
1. Foundations: Programming Fundamentals
- how to read Jasmine test specs
- the bare basics of HTML, CSS, and jQuery
2. Git & Terminal Fluency
Git is definitely a necessity for software developers today, as is comfort using the terminal, so we learned to use these tools early. Basic skills included: creating and moving files around in directories, initializing and committing updates to git, and setting up remote directories on Github.
3. CS Basics: Data structures & algorithms
Our first full week of bootcamp was dedicated to understanding the history and fundamental concepts of computer science. We learned to implement basic data structures — linked lists, queues, stacks, binary search trees, and hash tables — and implemented several different types of sorting algorithms. We also talked in depth about Big O notation, and its implications for the efficiency of different code implementations.
5. Servers, HTTP, and Express.js
After learning to use Node, the next step to understanding back-end development is to understand servers and routing. We began with an introduction to ports and protocols, with a focus on HTTP — its “verbs”, its filepath, its headers, its payload, its response statuses. We then learned to use Express, a Node library for request handling. We practiced modular RESTful routing, learning to handle GET, POST, PUT, and DELETE requests.
7. Databases, Schemas, Models, & ORMs
8. HTML5, CSS3, & Sass
It’s crucial for any developer to have a handle on the basic language of the DOM — HTML — and to be able to style it with CSS. This was definitely the weakest part of the curriculum, which is ok — it isn’t a design bootcamp, it’s a coding bootcamp — but we did learn the basics. We also learned Sass — “Syntactically Awesome Style Sheets” — which allowed us to use loops and other time-savers to organize our CSS and make it a little more “code-like”. To practice, we recreated a basic version of the Bootstrap library and styled a single-page web app.
9. jQuery & DOM manipulation
After building out front-ends in HTML and CSS, we learned to use event emitters and jQuery to manipulate the DOM. We worked on selecting, updating, deleting, and restyling DOM events, and learned about the concept of “event delegation”. Many argue that jQuery is dying, as front-end frameworks like Angular and React replace much of its functionality, but because so many current applications make use of jQuery, it’s important to know at least the basics. And, anyway, I would argue it’s not always necessary to use a large hammer like React for smaller apps; sometimes, a little lightweight jQuery is all you need.
10. Chrome Dev Tools
I would be remiss if I didn’t mention that we also learned to use Chrome Dev Tools for all of our front-end work. This included using the Inspect tool to examine the styling of DOM components, as well as the console, of course, to debug. Chrome Dev Tools also includes more nifty tabs, like the Network tab, which was extremely useful for testing our backend routes. In general, Dev Tools is just profoundly useful for novice web developers and experts alike.
12. Test-Driven Development
We paused for a couple of days to focus on the important concept of Test-driven Development, a.k.a. the idea that a developer should first write an initially-failing test, then write the minimum amount of code to pass it, then refactor to acceptable standards, then reiterate to cover all of the functionality desired of the app.
We had worked with Jasmine and Mocha/Chai before, simply passing tests written for us by our instructors. But now, we became the drivers and wrote our own tests. Most of us found this dull and rather unpleasant, but it’s important in order to cover as many edge cases as possible and ultimately produce less buggy code.
We only got a high-level look at web sockets, but they are highly useful, so I recommend looking into them. We learned about the WebSocket protocol, which provides back-and-forth communication channel over a TCP connection (as compared to HTTP, which is one-to-one and requires that a request be made from a client before a singular response is sent from the server.) This makes apps like realtime chatrooms possible without both computers sitting there constantly sending GET requests for new data.
We used the Socket.IO library to actually implement this protocol, though there are other options as well.
14. ES6, Babel, & Webpack
But with a changing language comes a problem: cross-browser compatibility issues. What’s a JS developer to do?
At the beginning of week 5, we finally arrived at a topic many of us were eager to tackle — React! To understand how it worked, we built a clone of Spotify piece by piece, covering the virtual DOM and the component lifecycle; stateful and stateless components, and when to use each; passing props from component to component; creating forms in React; and front-end routing with React Router. Throughout the workshops, we slowly gained a solid grasp on not only how to work with React, but why working with React is useful, and when to use it.
After learning React, we quickly refactored our Spotify clone to use predictable state container Redux — and then the react-redux library to make it all a little cleaner. We learned about action types (definitions and labels for a type of action, which we defined in a ‘constants’ file); action creators, functions that can take information and return objects formatted to be sent to the Redux state; reducers, which usually a
switch statement that describes a different update depending on the action's type; and the store, where the object representing the Redux state is kept.
Because the pretend app we were building wasn’t large enough to actually warrant the use of Redux, it was difficult to see the point of all the extra upfront code, but I do imagine that having a singular organized state and modularized code proves useful for very large apps, or apps that rely on real-time updating of the state from multiple users, like multiplayer games.
17. Authentication, sessions, & cookies
Our second-to-last curriculum topic covered a topic I’ve been curious about for a long time: how does an app accommodate users, who log in and out and have certain privileges depending on who they are?
We started by learning about sessions and cookies, small text files created by a server handling an HTTP request, and passed on to the browser to keep track of a user’s identity. Then, we ensured that those sessions persisted using the express-session library, and used it to connect login and logout pages to user models in the database, setting authorization privileges based on user identity.
18. Web security
Finally, we touched on a topic that’s becoming a critically important consideration for anyone looking to develop an app: security. We took a high-level look at different types of web security threats, alternating between “attacking” (i.e. understanding the vulnerability from the attacker’s point of view, and how a hacker might inflict damage) and then “defending” (fixing and protecting our code to prevent the attack. In particular, we covered the topics of uncovering API secrets, improper route access, data injection, XSS, and data theft.
Beyond the curriculum and stellar lectures, what truly made Junior Phase so effective was the workshops, in which we actually practiced each of the concepts, cumulatively adding them together and ultimately creating clones of actual apps, like Twitter (to learn Express.js), Wikipedia (to learn databases and Sequelize), a trip planning app (to learn Sass, jQuery, and AJAX requests), and Spotify (to learn React).
Starting this week, I’ll be in Senior Phase, in which we’ll be building bigger projects from scratch, including an eCommerce site, a personal hackathon project, and a 21-day Capstone project. We’ll also practice whiteboard interview questions daily, give a “tech talk” about a topic of our choice, learn about deployment and build systems, and attend a Hiring Day with employers.
I personally can’t wait to put all of these skills into practice in the coming weeks and in the career that awaits me. Best of luck to you on this journey we’re on!
— — — — — — — — — — —
If you enjoyed this piece, I’d love it if you hit the green heart 💚 so others might stumble upon it. You can find my code on GitHub and my other projects at http://www.sophiaciocca.me.