I write a lot about software engineering bootcamps, talking about the good, the bad, and the reality. If you have read any of these other pieces, you’ve probably come across some discussion on the reframing of expectations. Having attended one myself, and having had several years to reflect, I understand that a good bootcamp will teach you the absolute minimum that you need to go out and be a software engineer, because that alone is a very sizable task. Anything more in the several months they get is just unrealistic.
Given this, most curriculums jump into the complex stuff, only briefly alluding to or entirely skipping over many of the basics. I can easily reason that this is because these basics are much easier for us to teach ourselves than the complex stuff is. Through this lens, the trade off seems abundantly reasonable. We don’t want to be paying upwards of $15k a year to spend time on what we could otherwise learn from Codecademy or a $20 course on Udemy.
In my experience though, when someone new in the field receives this message, it is interpreted as something different. The messages reads more like, “These basics are rather unimportant, so we aren’t going to spend time on them” instead of “We have more to get through than we have time for, so teach yourself the basics”. This leads to engineers in interviews and on first jobs who can spin up a server or a client in 30 minutes, but can’t tell you the difference between the HTML elements ul and ol, or why you should bother with these when you can just use div.
These basic skills are fairly straightforward. If you can get through a bootcamp, you can definitely master them, but you do have to know that they are there and that they are in fact important. Here are five great frontend basics to start with to round out your bootcamp studies.
HTTP REQUESTS
Clients making requests to servers is pretty simple stuff, right? We make the request, we get the response, done. But what actually happens when we make a request? What is the accept-language header used for, and what are all of these errors about cross-origins and same-origins that pop up? The HTTP request/response cycle is so core to every dynamic modern web application, and yet it is so easy to implement without actually understanding what is happening. There are two main pieces that I want to highlight in this section. The first is the actual HTTP request and response objects; the second is what happens when one is sent or one is received.
Understanding the structure of a request and a response object is really a pre-requisite to understanding the cycle. Each type of request (ie, post, get, etc) will be structured differently and have different options that can be leveraged for sending information. They will also expect different responses. Additionally, things like the meaning and proper use of HTTP status codes fall under this umbrella. Once the structure is understood, we can move on to understanding what happens when a request is sent, received, processed, and then responded to.
SEMANTIC HTML
HTML is designed to be used semantically. There is inherent meaning to the sheer presence and configuration of elements. This is, in my opinion, the number one thing that is underemphasized in bootcamp. Personally, I left bootcamp thinking I could just use div for everything (yes, I know, I’m not proud of it). I thought HTML was frankly rather unimportant. After all, I knew JavaScript and React, and why would I waste time learning to build a bike when someone is giving me a car to drive?
This could not have been more misguided. What I failed to understand was that React (and other frontend frameworks/libraries) serve a fundamentally different purpose from HTML, and are not a replacement for it. They definitely expand the world of what we can build to run in a browser, but that is an entirely different need from the one that HTML fills. JavaScript is better at doing something, but HTML is better at being something. It is better at being a button, or being a list, or an input, but as the saying goes, when all you have is a hammer, everything looks like a nail.
When we don’t know all of the tools HTML already gives us, but we do know that we can do pretty much anything we want with JavaScript, we naturally reach for the latter. On this path, we end up writing lines and lines of JavaScript to recreate something that HTML would effectively give us out of the box, like flipping the order of a list or styling based on a very specific attribute. HTML is definitely a “you don’t know what you don’t know” kind of thing, and I highly recommend spending time digging in.
ACCESSIBILITY
Accessibility is the degree to which a given web application is accessible to all people, regardless of physical disabilities, situational limitations, and such. Aside from being something we should care about on a human level, accessibility is also just good business.
This point is listed directly after semantic HTML because the two are highly related. HTML offers a variety of accessibility tools, like the aria (Accessible Rich Internet Application) roles and attributes that it natively supports. Accessibility tools like screen readers know to look for these fields to better inform the user. Remember how we said “semantic HTML” was about using the markup to create meaning in and of itself? Accessibility is a great use case for this, because it can extract that meaning that we have created, and use it to communicate our web applications through other channels.
CSS
If I’m being honest, I fought diving into CSS for a long time, preferring to learn more about architecture and solving complex logic problems than UX styling. Wow was this a mistake. It doesn’t matter how smoothly your app works under the hood — if people arrive and it looks like trash, they will leave. It’s that simple. They either won’t trust that it’s a legitimate site, or it will be so unwieldily that they will decide wrestling with it just isn’t worth it.
As humans, we can’t help but judge books by their covers. The polish is important. Users expect a certain level of visual cohesiveness and shine when they reach a web app today. Anything less than this sets a tone from the jump. Really though, CSS is much more than just polish. CSS is what facilitates a smooth presence across all of the devices, screens sizes, and operating systems a modern web application is expected to run on. It allows us to find fun branding moments, and to create and maintain a consistent visual presence online. Styling can also be a serious pain when done incorrectly or ad hoc. CSS is definitely another “you don’t know what you don’t know” situation.
MODERN BROWSERS (& JAVASCRIPT)
So what actually happened when you arrived at the current website that you’re on, in between typing in the URL and reading this line? This one is a bit more general, but fresh out of bootcamp, I don’t think that I or anyone in my cohort could answer this question.
This answer could span the explanation of what exactly a domain is, to where the entry point of an application is, to how JavaScript is bundled and served — so yes, it is certainly broad. But it is important. It is valuable when discussing things like infrastructure, deployment, and general production maintenance. Spinning up a new app is great but does very little good if it can’t get off of your local machine, or can’t survive in the real world.
ABOUT THE AUTHOR:
Based in Los Angeles, CA, Bryn is a full-stack engineer with a background in the music industry. Her career started at Velvet Hammer Music and Management Group, where she worked with artists such as System Of A Down, The Smashing Pumpkins, Alice In Chains, and others.
After leaving to pursue software engineering, she joined the Syntx team as a full-stack engineer. Here, she used Node and React to build applications from the ground up, as well as collaborated with other teams to add new functionality to existing software. Bryn now works at a stealth startup in the FinTech space, building cool but secret stuff.
