2019 Fullstack Web Dev For Idiots (like me): Part 0 — Mental Roadblocks and Dev Environment
I wrote this post to help people out who are just getting started with development, but can’t get past setting up all the tools that they need, and might not even understand what those tools are or what they do. All of that is covered in the second section of the post, so feel free to skip ahead to that if that’s what’s most useful to you.
The first part of this post is speaking more to the mental roadblocks of getting started, and I’ve tried to address what I’ve seen as both my own stumbling blocks and the observed trepidations of others. That said, I’ve also tried to encapsulate and lay out the best advice and practices I’ve had the opportunity to receive or observe from devs that I respect a lot. Maybe not for everyone, but hopefully useful and in solidarity with some.
In the words of Frank Herbert, “fear is the mind killer”. Doubly true when it comes to teach yourself how to code in the current age, quadruply true if you suffer from a classic case of imposter syndrome (super common in the programming world) or are still just wet behind the ears in the HTML/CSS world and have no idea where to even go from there.
No matter what you do, there’s going to be a ton of depth if you want there to be. Want to be a badass designer/developer and actually understand CSS-grids, gpu-accelerated animations, be a SASS master, etc? You can definitely do that, and there’s nothing wrong with that. However, whereas 10 years ago that would have provided some decent job security, my firm belief is that unless you’re already established in a some sort of marketing/creative dev shop doing already doing this work, the ability to be a straight up frontend designer has passed you by.
Yes, there will be a continuing demand for custom Wordpress/Hubspot/Drupal sites, etc., but my prediction is that Wix/Squarespace/et al, and machine learning are going to kill the vast majority of the static site development industry. Knowing HTML/CSS and a content management system used to be enough to build a career on. Though still viable, investing in that stack will only provide diminishing returns moving forward.
2) I get it, and so do a lot of other people:
When we talk about fear, we’re talking about that hesitation to just get started, that indecisiveness driven by the massive overload of information and options, that discrete fear that because you can’t understand it now, you won’t understand it ever. Real talk, so many of us feel this fear.
Truth is, everything that drives that fear never really disappears. There will always be an unknown. There will always be something you’ll struggle with. There will always be the lingering feeling that you’re not doing enough, fast enough. The only thing that changes is how you choose to react to it. As Greg Lemond, a 3-time Tour de France winner famously said: “It never gets easier, you just go faster.” I propose a reworking of this adage to: “It never gets easier, you just start doing it faster”.
Because doing it faster, or not waiting to get in under the hood and dirty your hands, seems to be the foremost attribute of the senior engineers I have the most respect for. Sure, their lifetime knowledge base helps check all the little boxes, but when faced with something new, they don’t waste time, they just get in and do it. The sooner you break something, the sooner you have a thread to pull to start figuring things out.
In summation, embrace the fear, and let overcoming it become what drives you. If you, as I often do, feel like the dumbest person in the room, conquering that fear and proving to yourself that you actually can do it becomes an incredibly powerful and motivating validation.
The impetus for this tutorial series came from working with a group of individuals from non-technical parts of my current company who wanted to level-up their careers and learn how to code, either to enhance their current roles, or to eventually make the jump to an engineering position.
That said, working with a varied group of people who are just getting started has empirically shown 2 things. 1) The number of dev dependencies people need to get up an running can be intimidating at first, and 2) a vast amount of the tutorial/stack overflow threads/blog posts/etc. assume the dev will have a bash environment. This is generally fine when someone has a Mac, but can present an additional roadblock when Windows users are trying to get started. With that in mind, the first thing any Windows user should do is get a bash terminal emulator. My personal favorite is Cmder. Cmder will help standardize a lot of the reference information you’re going to find. (Also, re: the command line. Learn it. Love it. Live it. You’ll feel like this in no time).
A lot of resources may say to use your editor flavor of choice. For standardization (and awesomeness), I say VS Code. It’s the best thing out there that’s not an IDE right now imo, and it gets a ton of support from Microsoft and the community. Integrated terminal is pretty tops.
Get git. Git is a version control system. If this is greek to you, just understand the basic usage is for teams to be able to work on the same piece of code together. The usual process is to create a repo (file repository), most often on Github (please note git and github are not the same…), and then have team members clone that repository on their local machines and push/pull updates to that shared codebase. Usually, if one person is working on a different feature from everyone else, they’ll create their own branch from the master repository, work on their changes on that branched copy of the code, and then test to make sure it works with everyone else’s code before pulling it back into the shared repo. Here’s an example of how to use git from the command line (although there are visual interfaces for doing this, you’ll really learn best by using the cli tool):
git clone www.github.com/exampleuser/example-repo
git checkout -b my-own-branch
/* do some work in the branch */
git add .
git commit -m "this is a commit, and I'm going to leave a message here about the work I have done"
git push origin -u my-own-branch
Here’s the flow of what’s going on above:
- We’re cloning (copying) a version of the
remoterepository (from github, in this instance) to our
cd’ing (changing directories) into the directory we just cloned
- We’re creating a
localbranch off of the repository we’ve cloned.
- Do some work in the branch. Change a file’s contents, create a new file, delete a file, etc.
addall of our changes so that they’re tracked by git
commitall the files we’ve added so we can push them up. Git versioning works around the idea of commits. Each commit will get a unique commit id, and if we really screw up our code (or someone else’s), we can use the commit id to revert back to the un-screwed code like this
git reset --hard uniqueC0m1tId(there are some caveats here, so check out this rad stack-overflow post for further reading). Commits must have commit messages
-m, btw (good practice to make these messages descriptive of the work that’s new to the commit).
- Now that we’ve committed our code
locally, we’re going to push
remotebranch. The first time we push up a branch we’ve created
locally, we’ll use the
downstream, is the same as
- All further pushes to the branch can be done with
git push origin my-own-branch.
- Eventually, after all the work for our particular feature is done, we’ll want to merge our
my-own-branchbranch back into the
remote masterbranch that we originally cloned, so everyone else that’s working on the codebase can
git pull origin masterand get all the updated work you’ve done.
- Git can be confusing af. Don’t worry if it doesn’t all make sense at first. Just focus on the basics of
clone, checkout, add, commit, pushto start. You will run into the opportunity to learn more about git, I guarantee it.
So, if HTML/CSS/JS in the browser are the gateway drug, Node is the pure stuff right off the boat. The first time you write your own proxy api to bypass CORS restrictions can be intoxicating. And, if you stick at it, just like you learned those programming fundamentals with browser-side JS, you’ll learn the backend fundamentals like the HTTP protocol, RESTful services, authentication, MVC, etc., etc., etc. Node terraforms what you can do with your JS knowledge, and it’s a sublime thing to connect the full pipeline in the same language.
All that said, go get Node here. Once you’ve installed, you should be able to access it from the terminal by running
node -v . If it returns a version number, then you know Node is installed and that the executable has been added to your system path. Usually this just works on Mac, but Windows users might benefit from this article.
And with that, you should have everything you need to get started. You could literally do anything at this point. However, I highly suggest you get started by learning React.js. And then build a backend for your React app with Express.js. And then mess around with hosted infrastructure on Amazon Web Services to deploy your app.
If the above sounds pretty 0–60, don’t worry, it is. That said, check out my upcoming posts about each one of those focus areas, and by the end of everything, you should a) have a little functioning web app that acts as your own portfolio (no note-taking app here), and b) have learned a whole ton of a lot, hopefully in a way that prepares you well to go out and create some awesome stuff at will. Stay tuned for links to those posts in the near future, and please leave a comment with any pain points you run into getting your dev environment set up, and I’ll work to keep this post updated with solutions to the edge cases. Cheers!