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.


  1. Javascript, and why you should:

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.

All that is to say: Javascript. Learn it. Don’t be afraid of it. Dive in with both feet. It has become an amazingly versatile language, and it’s ecosystem grows by the day. Pick a frontend js framework and get going. Don’t wait around until you “feel more comfortable” with HTML and CSS, because a) You’ll still learn a ton about those fundamentals when building an app, and b) JS, or JS frameworks, imo, should now be considered one of those fundamentals. If you want to become a web developer, or even a software engineer, but have pretty much no experience, build your fundamentals in a language that can be used both on the backend and the frontend (thank you Node.js), and then use that context to learn other languages. Don’t spread yourself thin trying to do everything at once, because you don’t have to. And most importantly, don’t be scared. Fear is the mind killer.

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.


Dev Environment:

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).

If’n yer on a Windows box.

Text Editor:

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
cd 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:

  1. We’re cloning (copying) a version of the remote repository (from github, in this instance) to our local machine.
  2. We’re cd’ing (changing directories) into the directory we just cloned
  3. We’re creating a local branch off of the repository we’ve cloned.
  4. Do some work in the branch. Change a file’s contents, create a new file, delete a file, etc.
  5. add all of our changes so that they’re tracked by git
  6. commit all 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).
  7. Now that we’ve committed our code locally , we’re going to push upstream to the remote branch. The first time we push up a branch we’ve created locally, we’ll use the -u flag for -upstream. (upstream/downstream, is the same as remote/ local ).
  8. All further pushes to the branch can be done with git push origin my-own-branch .
  9. Eventually, after all the work for our particular feature is done, we’ll want to merge our my-own-branch branch back into the remote master branch that we originally cloned, so everyone else that’s working on the codebase can git pull origin master and get all the updated work you’ve done.
  10. 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, push to start. You will run into the opportunity to learn more about git, I guarantee it.


Node is a beautiful thing, in my humble opinion. Still a bit of the redheaded stepchild of the backend world at the enterprise level (although that is changing, https://www.monterail.com/blog/nodejs-development-enterprises), Node allows developers to code their backend server and api logic in the same language they use in the frontend: Javascript.

If we look at the traditional front-end developer learning path, it usually goes like this: learn some HTML and super basic CSS. Now learn some more advanced CSS. Now learn some Javascript, maybe for simple animations, show/hide | expand/collapse functionality, etc. Now learn more advanced JS to dynamically generate some markup, fetch data with api calls, creating tracking objects in browser, etc. And, for a long time, that was about as far as you could go with JS, because you were constrained to using it in the browser. If you wanted to build a backend, you had to go learn php or python or .NET or Java or any of the myriad other languages that allowed for server side coding.

Now, frontend web dev, though requiring it’s own expertise and definitely not without its challenges, seems to have gotten a bit of a rep for being the “softer” side of programming. But, that’s precisely why it’s a great medium for getting into coding. At the outset, it can provide tangible early results (“Look, I got something to show up on the screen!”, “Look, I made the background blue!”, “Look, I made a little animation!”, and so-on and so-forth), and by the time one really starts digging into Javascript, they’ll already be learning the fundamentals of “real” programming: loops, conditionals, operators, etc.

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.

Your/the future


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!