My Two-Year Journey Learning Web Development while Working Full Time

July 23, 2021

--- views 21 min read


compass - Photo by AbsolutVision on Unsplash

Photo by AbsolutVision on Unsplash

It's funny how sometimes you can begin a journey without even realizing it.
The other day while reading posts on r/learnJavascript, a reddit a community which I frequent, I saw something that really brought me back. Specifically, this post titled, Where should I begin? [Total Noob here], in which the author simply asked for direction on how to learn Javascript. On the surface there is nothing unusual about this post - there are probably 20 or more posts daily in this community asking the exact same thing. However when I expanded this post, I noticed that the author linked a familiar video by the channel Programming with Mosh. As I watched the video, I realized that this was not only a video I had watched before, it was also the very first javascript video I had ever watched, more than two years before. In that moment I realized: this was the video that started my journey.As I began to respond to the post with some helpful videos to get the author going, I ended up writing more and more, turning what started as a three-bullet list into a long, rambling comment describing my journey starting from that video to where I am now with Javascript and Web Development. Therefore, it feels appropriate for my first blog post to use that as a spring board idea and introduce myself - where I started, where I am, and where I hope to go with this learning journey.

First Exposure

It started innocently enough. I had recently gotten hired 6 months prior with LMI as an Analyst, where I had been tasked with building and maintaining data-intensive business intelligence applications, primarily with Tableau. A few months in, an opportunity presented itself when a project manager on a small internal R&D project transferred off, tapping me to step in and lead the remaining effort. This was a project unlike any I had ever worked on, utilizing the infamous Javascript charting library D3.js to create visualize timesheet data on the web, representing people as small dots moving around a canvas which represented different activities & projects that LMI employees take part in (it was inspired by this amazing visualization by flowingdata, but tailored to LMI).But as a Tableau Developer, I was totally out of my comfort zone. Javascript? I had barely heard of it. D3? Seemed complicated. I remember looking at the code repository and feeling dumbfounded. Luckily the developers who created it were brilliant and there wasn't much left to do; as the project wrapped up I made a promise to myself that I would make an effort to learn how javascript worked on the web, so that next time I wouldn't be so lost when I looked at the code. A few days later, I stumbled upon that Programming with Mosh video and jumped in.

Just Tinkering

The first few attempts with JS seemed easy enough, and I wasn't coming into programming totally raw - I had actually already learned some Python before this to help me with some basic data analysis tasks and data re-structuring using the Pandas library, a skill which I still use from time to time today. The syntax was a bit different but not difficult to grasp, which makes sense because Javascript and Python are both high level languages, designed to be closer to human languages and abstracted from machine code. A few extra brackets here, an extra 'const' there, no problem.Of course, beginner videos start to wear out quickly and soon thereafter I went to a familiar source - Udemy - to try to find some content with a little bit more of a learning structure behind it. I eventually settled on a 21-hour course called Modern Javascript from the Beginning, starting with language fundamentals, moving into the Document Object Model (DOM), then DOM manipulation, Asynchronous requests, APIs, and design patterns, also featuring four small projects. Although it was a bit of blind purchase at the time, it proved to be the best $10 I have maybe ever spent as it laid the foundation for how to use the language to create applications instead of just add numbers and print things to the console. This was the beginning of a long process of building a mental model for how web applicaitons work.However while DOM manipulation with Javascript was starting to make a bit of sense, the stuff the DOM was made of - HTML, CSS - really wasn't making any sense at all. I made this discovery on the first todo list project, when I was totally lost trying to understand why the markup and styling needed to be arranged in such a specific way. Every insertion into the DOM I made only wrecked the site, rearranging the field inputs and listings in a very not-nice way. I decided that I couldn't immediately go on in good faith because I realized I had skipped something important. I then put the javascript course on hold to go back and get some basic understanding with HTML & CSS using a course by the same author, HTML & CSS from the Beginning. It took me about 3 months to finish the HTML/CSS course, where I was exposed for the first time to critical concepts such as semantic HTML, the box model, the position property, flexbox, grid, and even some common pre-compilers like Sass. When I completed this I went back to my Javascript course and spent the next 4 or so months working through it at about 5 hours per week. A quick note about time before we move on: when a Udemy course says "21 hours" that's just the total video time in the course. In reality, one should expect to spend a good deal more time than that to actually complete the course, providing one will frequently pause to write out code, pause to deconstruct copied code, pause to console log and troubleshoot problems that the instructor doesn't fully explain, etc. To put it in perspective, I spent about 67 real hours doing this course.
First Steps - Photo by Simon Infanger on Unsplash

Photo by Simon Infanger on Unsplash

First Steps

Learning something complicated should feel, at times, extremely uncomfortable. Take swimming, for example. When I learned to swim as a child I spent seemingly endless days in the pool, paddling from the wall to where my dad was standing just feet away. That was a useful exercise because it exposed me to the feeling of being fully immersed in water, and gave me contextual understanding of how swimming works in small doses. However, you can only learn so much from these small forays - at some point you need to actually try the thing and do it on your own, for real. In the case of swimming, the pool lifeguards made me pass a test before I was allowed to swim in the deep end unsupervised, so eventually I had to swim from one side of the pool to the other on my own. I remember that being an uncomfortable experience the first time.Learning how to build things on the web with Javascript has so far followed a similar pattern, and at this point in the story I had gotten some exposure in the form of Udemy courses, but hadn't yet tried it on my own.

Following along only counts for so much. To really learn you have to try it unguided and spend time struggling through the murky unknowns, sorting through errors screens, and all of that fun stuff.

I started building, and I started small. I built super basic things just to get more comfortable at first like
  • A page with a button on it that changes the background color
  • A basic calculator that could only add, subtract, multiply, and divide 2 numbers at a time
  • A button that would fetch jokes from a joke API and display it on the screen.
  • A page with a countdown clock, that allowed you to set the event date and even change the background image
When I started running out of ideas, I found this course which gave me ideas for projects and inspiration for features I wanted to learn how to build. As the COVID pandemic raged on outside my house, I found myself at home more often and actually took one of those project ideas and went deeper with it. Using a free recipe API, I started building my first single page application with vanilla JS. I used my knowledge of the DOM and how to manipulate it to asynchronously fetch a list of recipes and render them in a list on my site. One could click on a recipe in the list and see the full detail page where the instructions, ingredients, and everything else you'd need to make the recipe were displayed nicely on the page. You could also search, filter, and enter new data into a form to mock-add a new recipe.I didn't know it at the time, but this project was an absolutely critical learning experience that I needed to continue to move forward because the deeper I went with this project, the more disorganized my application became. The code made sense on some level, but when I wanted to add a new feature, there were too many possible ways to do it and I wasn't necessarily implementing DOM changes in the same way every time.Take for example a simple example where you want to insert a list element into an unordered list (a common situation). You could:
  • create a new paragraph element, set that element's textContent property, and appendChild it to the list.
const listItem = document.createElement('li');
listItem.textContent = "Check out my list item.";
document.querySelector('ul').appendChild(listItem);
  • Or, you could also select the list and modify the list's innerHTML property to add the item.
document.querySelector('ul').innerHTML += "<li>Check out my list item</li>"
And there are many other ways to do this same thing, all of which are correct in some instances and incorrect in other instances. In the example above the first method is preferable to the second method generally because setting innerHTML is associated with cross-site scripting risk, but there are other times when you might want to use innerHTML. What I didn't realize at the time but know now, is that I was learning about opinionation in programming and how to identify the correct design patterns to solve a problem. Building websites with vanilla javascript, HTML, and CSS is a very un-opionated process, meaning there are many, many different ways to do it. The designers of the Javascript language made it a very open ended and flexible tool that can solve almost any problem you have in a number of ways, and while this is a good thing, it can also raise important questions about the best way to do something in a specific situation. In addition, I saw how slow and tedious it was to build this kind of application with vanilla Javascript. Not only did I have to write code to fetch the recipe data and respond to events, I also had to meticulously construct HTML elements one tag at a time, adding styling along the way so that when a piece of code was inserted into the DOM it would look and behave correctly.After doing this project I no longer had to wonder why development teams tend to use frameworks instead of vanilla JS when building production-level websites which in-turn helped me understand why seemingly every high-paying job opening I saw listed either React or Angular as a requirement. I learned that these frameworks are designed to make building highly-performant websites faster and easier by removing the tedious parts of manual DOM manipulation and by encouraging developers to think about web applications as a composition of smaller components which asynchronously react to changes in the data underneath them. Frameworks also impart some amount of opinionation, which makes it easier to get started building things the right way, understand how an application works from a high-level, sort through problems, and add features to the application in a consistent way later on. Suffice it to say that by the time I had finished the recipe project I felt I had a good understanding of the shortcomings of building single page applications with vanilla Javascript, and knew that React was the first development framework that I wanted to try.
React Code - Photo by Ferenc Almasi on Unsplash

Photo by Ferenc Almasi on Unsplash

Hello, React

I don't exactly remember how I first started using React. What I do remember is that it felt confusing, new and gnarly; seemingly every time I used it I was dealing with bright-red error screens that totally destroyed any shred of confidence I had tried to have in myself. Looking for a sense of structure in my learning, I went back to the same Udemy instructor I had used for the other courses and for just $10 purchased his React course, working through it at about 5-10 hours per week over the next several months (According to my time tracker, I spent just shy of 50 hours to complete this course). This course was a great decision, as it gave me a broad exposure to React and its ecosystem across 3 comprehensive projects. Through this course, I worked with:I really enjoyed this course because through it I was seeing weekly growth in my own mental model of React and by the end felt like it was starting to make sense. While following along with the instructor I had built bigger and better applications than I could have ever dreamed of without using React and started to hunger for more, but I knew I had not fully tested my understanding of it yet. Going back to the same approach I used after learning vanilla Javascript, I knew that in order to actually learn how to use the thing, I had to use the thing to build things, so I created a list of project ideas. As I built out my project list with ideas (many of which involved creating and deploying both a back end and front end), I started to realize that I wouldn't have time to build all of them - in fact, the more I thought about it, even building 1 or 2 items on my list was probably going to take months. Where was I going to find the time to build my portfolio? Should I even try? Before diving in blindly, I had to take step back to make sure I knew what I was working for.
Clock - Photo by Sonja Langford on Unsplash

Photo by Sonja Langford on Unsplash

It's Time to Get Serious

At this point it was early November 2020. I had been working from home during COVID since early April and had been able to devote more time to learning than when I was going to work every day 9 to 5. What had started as a basic javascript intro video more than a year ago (at this point) had snowballed into several months of more serious study and an actual hobby. I even found myself cancelling plans to stay home and code. Yes, it was that serious! (also it was kind of unsafe to be around people, plus I'm an introvert). Learning to code was becoming a real time-suck and I found myself at an important moment: I had to consider how far I wanted to take this and what I wanted to build towards. You see, up to this point I had just been working without any real goal, doing what seemed interesting and fun. But If I didn't care to take web development towards a full-time occupation, well then it wouldn't make sense to keep devoting so much time to it, and it wouldn't make sense to actually build out a portfolio because that would take months. And if I did want to take it full time one day I probably needed to actually devote more time because after all of this, I was just another generalist with a basic mental model of how React works and no portfolio to show for it. After spending winter break ruminating on this question, I began 2021 with a new objective: I was going to actually, deeply learn React and spend the entire next year building a suite of portfolio projects. I knew I would be working from home most of the year, so I figured I would have ample time to work towards this goal, at least until the summer when my job was going to consider going back to in to the office.
Agile Sprint - Photo by Daria Nepriakhina on Unsplash

Photo by Daria Nepriakhina on Unsplash

A Casual, 8-Month Sprint

As 2021 began, I found myself spending up to 20 hours a week working on my projects, reading documentation, and watching youtube how-to videos specific to the tech stacks I was interested in. These are the 4 biggest projects that I worked on, starting from scratch and using online resources to aid in helping me work through issues.Dec 2020 - Jan 2021 A simple weather application, a single page app bootstrapped with create react app that presented the current day and next 2 days of weather forecast summary to the user, and expanded into an hour-by-hour temperature graph when clicked. Using pure client-side data fetching and an external weather API I worked through this project with mostly no issues. Some of the big takeaways for this project were handling loading states correctly when requesting data from an API, and learning how to sort through libraries in the React ecosystem to choose the best one (in this case, a charting library called ChartJS). Doing this project helped me realize that using free, public API's can only go so far - I was going to have to learn how to create my own API's for my react apps.Jan 2021 - Mar 2021 An email survey application which allows an authenticated user to create an email survey using a validated form, send out that survey to a number of participants, and track responses to the survey using a dashboard. This project was all about learning how to create a backend for my react application, using Node and Express. It was also my first steps into the world of authentication, where I used Passport's google auth strategy to allow users to sign up and sign in with google. For what its worth, I really liked passport for this, though there are probably easier methods to handle auth, such as using Firebase. I gained a ton of new exposure to the NodeJs ecosystem in this project, on topics ranging from integrating Stripe payment intents to working with webhook data from Sendgrid, all of which forced me to pay close attention to the structure of my backend application and optimize routes to facilitate data requests on the frontend. I can't overstate how much new material I was exposed to in this project. Feb 2021 - June 2021 Roommates-Hub, a CRUD application where authenticated users can post about room vacancies to others interested in group living. This was by far my largest and longest project to date, building on my experiences in the Email Survey project. In this project, I went deep with MongoDB and its NodeJs cousin library, Mongoose, in creating API routes that facilitated CRUD functions for Users and Posts. In this project I made strides in my understanding of how to build database models that relate to each other, how to query sub-document collections efficiently usine Mongoose query/projection operators, how to handle large image uploads (I used Cloudinary which works well for this non-scaled project), and how to model a 'likes' voting system to allow users to like and unlike posts. The most serious issue I faced with this application was actually how to deploy it - I had originally planned to deploy the frontend to Netlify and the backend to Heroku, but even after updating my CORS policy and the baseURL in the client folder, the application was failing to send authenticated requests cross-origin. I eventually scrapped the cross-origin deployment idea and restructured the project to deploy it all on Heroku, using a postBuild.June 2021 - Aug 2021 My Portfolio. I wanted a nice, clean, and convenient way to showcase my work to prospective clients and employers, and I felt that a personal website was the best way to go as a developer. For this, I learned NextJS and used Chakra UI as my CSS library & Design system, and Contentful as my portfolio's CMS. I might write a whole post about this at a later time, but I really love Next JS and the structure it gives me when creating react applications, plus deployment is such a breeze with Vercel. Chakra has also emerged as my favorite UI library after this project, as I feel it gives enough extendable components to get off the ground quickly, yet provides a structure around how to customize the design of Chakra components used in my applications, as well as enforce specific themes and designs of my own.Of course this isn't an exhaustive list, but these projects were the main objective, and I'm glad I spent the time to fully build them out. According to my time tracker app, I spent over 400 hours between these projects.
Backpacker - Photo by Mukuko Studio on Unsplash

Photo by Mukuko Studio on Unsplash

My Journey is Far From Over

I started from a semi-technical background and have spent the last 2 years learning how to build web applications with Javascript. At the beginning of the year, I set an ambitious goal to finally learn React. It's now August and while the year is far from over, I feel that I'm very close to being able to marking this goal as complete - though honestly it's hard to say when you've fully "learned" something. Despite this progress and despite having spent nearly 800 hours since Jan 1 2020 to learn HTML, CSS, Javascript, Python, React, NextJS and some Amazon Web Services, I truly feel like I've just started down this path and can't wait to see what awesome, interesting techs I'll learn in the future. Moreover, taking 8 months to focus on building applications has definitely exposed some blind spots that I very much need to address in order to become a better, more complete developer. Here's some techs that I plan to explore in the back-half of 2021 and into next year, in order of relative priority:
  • Data Structures and Algorithms - My College major was Business Admin, so I never went through a rigorous Computer Science curriculum. While I did take some CS courses at a local community college in 2020, I never took a Data Structures or Algorithms course. This is by far my most glaring weakness, and will be the thing I most aggressively address throughout the rest of the year. I plan to work through this Udemy course to begin with and later, either go back to the community college or obtain a certification from a more accredited source.
  • Typescript - Silly errors in development are better than insane errors in production! Not only can TS catch up to 15% of all Javascript bugs in development, it enables new developers to join projects with existing codebases more easily, reducing technical debt and increasing team efficiency. I'm generally a huge fan of developer tools, and based on some early experiences with Typescript, it's something I want to learn this year.
  • PostGres SQL - I'm not a stranger to SQL, in fact I've used it in my day job in the past, however I currently haven't used it in any React applications. To this point, MongoDB's NoSQL databases have been easy and simple enough for my applications needs. However I think when you start to get into highly relatable data structures, it makes more sense to use SQL databases and take advantage of those relationships instead of spending your time debugging the odd sub-document collection queries that you have to do in NoSQL setups.
  • GraphQL - the REST API alternative that I've been hearing so much about has the community buzzing. Strongly-types schemas, optimizing the amount of data fetched per request, minimizing total requests, and ease of developer experience are all convincing selling points that make me want to check it out.
  • Docker & Containerized Applications - I've seen it used in deployment of some complicated tutorial applications, and I think it could be a great tech to add to my area of expertise. More of a long-term target.
The Journey Continues.

Get In Touch

EmailGithubLinkedIn

Designed & Created by Michael Corey Munn, 2021

Built with Next & Chakra.