Some Time Has Passed

I realized today that some time has passed since my last post. I don’t think I can go into great detail about what I’ve been doing in that time, but there has been a fair amount of new knowledge gained.

Working That Back Side

The most notable change in direction has been working with Node, Express, and MongoDB. I charged right through the FreeCodeCamp API Microservice projects and I’ve completed one of the full stack projects as well. Adding React into the mix was an interesting challenge, and I’ve still got a lot to learn in that regard.

One thing that I’ve found interesting in this part of the stack is how different the approach to problem solving is. For nearly any task I wish to accomplish on the back end, someone has created a library. This is not so dissimilar to the React ecosystem, but it does seem to take it to a whole new level. This has led me to a number of internal conflicts; am I wasting an opportunity to learn more by including these libraries, or would I be wasting time reinventing the wheel, so to speak, by trying to achieve on my own what these libraries are already capable of achieving?

Most talk of React and JavaScript fatigue come down to the ecosystem. To use React you need compilers, bundlers, this thingy and that thingy, and to learn React is to learn Webpack and Babel at the minimum, but more likely with Redux, react-redux, react-router-dom added in depending on the scope and complexity of your app. This is precisely how the back end feels. Sure, you can do most of it with just Node, but Express makes it so much easier. MongoDB is pretty straight forward, but why not use schemas with Mongoose? Sure, you can build your own authentication system, but Passport already has that covered. OAuth1, OAuth2, use existing social media credentials, more choices than you can imagine. At some point the sheer enormity of new libraries becomes a burden and I’ve found myself facing the fatigue that I never did experience with learning React.

So A Pause For The Cause

I took about a week off, writing no code and not really even thinking about it. Yesterday, I opened my Atom text editor for the first time in many days, feeling somewhat renewed and excited to tackle some new challenges. Today, I’m force-feeding some React into Electron, making my first desktop app. Don’t feel bad for Electron, I think it likes it.

Drawing Some Charts With D3

I have to admit, I was pretty intimidated by learning D3. This is the second part of the FreeCodeCamp data visualization section, the first part being React. After all the trouble I had learning React (or more to the point, finding anything current to learn React) I was dreading starting D3. As it turns out D3 is pretty simple, once you get the hang of the basics.

The Basics

I was surprised to find that D3 is a lot like (shudder) jQuery in syntax. Most methods return an object – allowing method chaining – which greatly simplifies the entire process. Once I started thinking of D3 in these terms the projects practically coded themselves.

The only other learning curve seems to be getting comfortable with svgs, which fortunately I have used in previous projects so there wasn’t much new there. In fact, I think most of the code I wrote for my D3 projects was to handle svgs and relatively little pertained to D3 or the data being used.

In a nutshell, D3 takes a whole lot of data and turns it into pictures. This is probably a great over-simplification which would likely irritate Mike Bostock (creator of D3), and really doesn’t do it justice, but there you go. Data to pictures.

Let’s Look At Some Code

This comes from a great, if outdated tutorial by Scott Murray written in the time of D3 v3, but all of this code will work in v4

First up, using D3 to add an SVG element to our page

const w = 500;
const h = 100;
const barPadding = 1; 

const svg ="body")
              .attr("width", w)
              .attr("height", h);

SVGs have default width and height attributes, so you do not necessarily have to specify these values, but I can’t imagine that the defaults will always be the size you’re after. So it’s good practice to specify these values.

D3 will loop through all provided data once it’s bound, applying your logic to each item in your dataset. That happens here:

   .attr("x", (d, i) => {
     return i * (w / dataset.length);
   .attr("y", (d) => {
     return h - d * 4;
   .attr("width", w / dataset.length - barPadding)
   .attr("height", (d) => {
     return d * 4;
   .attr("fill", (d) => {
     return "rgb(0, 0, " + (d * 10) + ")";

I’ll leave it to you to read through Scott Murray’s tutorial to see what’s going on here. You can view the final results of this code here.

To Wrap This Up

D3 is different, but not scary. It’s powerful, but not difficult. Getting a simple chart onto the screen takes very little effort and the learning curve is not at all steep. Fear not the D3.

An Ode To Flexbox

A few months ago I made the courageous decision to not use Twitter Bootstrap anymore, and instead learn some CSS. I do not regret this decision even a little. Not too long ago I was peeking under the skirt of someone’s bootstrap website in Chrome Dev Tools and noticed something really odd: the custom bootstrap grid classes were just flexbox!

Okay, this is probably not news to most people, but to me it was kind of a big deal. I had moved away from bootstrap to learn flexbox and css grid for positioning, and then find out that what I just learned is what I had been using before. The biggest difference is that flexbox has native browser support, and bootstrap requires adding some pretty hefty libraries. Granted, you can get by with just bootstrap.css but if you wander into some of the other bootstrap classes you could find yourself in need of bootstrap.js, which requires adding jQuery. I had found myself adding in 3 libraries just to position content on the page, and that seemed just a little bit silly.

About That Flexbox

It turns out, flexbox is pretty simple to learn. There are a number of great resources out there, from my favorite site to flexbox froggies and flexbox zombies. These last two are pretty entertaining and give you some good hands-on experience with flexbox.

The basic premise of flexbox seems to be creating either rows or columns as parent containers with:

.myRow {
  display: flex;
  flex-direction: row;

.myColumn {
  display: flex;
  flex-direction: column;

It’s pretty intuitive so far. We have to specify that the container is using flexbox, then we designate which direction to add the content. Worthy of note here is that the flex-direction: row is the default value and doesn’t have to be specified.

I’m not going to iterate through each available property, and I don’t intend this to be a tutorial. The remaining properties are all about how the content is displayed in the flex containers. Some handle spacing, some alignment, and there are plenty of tutorials (including those mentioned previously) which will give you a great idea of how flexbox works. I do, however, want beginners out there to know there are alternatives to Bootstrap.

But What’s Wrong With Bootstrap?

The answer to this, of course, is that there’s nothing wrong with Bootstrap. It is a well developed, well documented resource and I’m sure there are situations where I would be happy to use it. My initial statement is that it’s a bit unnecessary to import 3 huge libraries just to handle a little positioning. Bootstrap does make some tasks much easier, such as responsive design, but for me that’s not enough to justify adding it to a project. I am very fond of media queries and since I’ve discovered the wonder that is SCSS using those media queries is a piece of cake.

And Finally …

Since we’re on the topic of importing huge libraries for small tasks, I have to mention jQuery. Yes, it’s useful. Yes, it simplifies some very common tasks. Take for example, selecting items from the DOM:

/* selecting class "myClass" and changing the html to 
   "<em>Hello World</em>" and the text color to red in jQuery */

$(".myClass").html("Hello World)
             .css("color", "red");

/* doing the same in Vanilla JavaScript */

const myElement = document.querySelector(".myClass");

myElement.innerHTML = "<em>Hello World</em>"; = "color: red";

The syntax for jQuery is much cleaner, being able to chain methods off of a single selector, and I believe at runtime (at least theoretically) the jQuery will execute quicker since it’s only searching the DOM once for a single selector (I have not tested this).

It’s not enough to get me to add jQuery to my projects. Just like the gains from Bootstrap are not enough to get me to use it either. There are situations where they both would have their uses, but for me it’s not in anything I’m currently working on. Also, there’s always the fact that React.JS is very jealous about controlling the DOM and doesn’t like to share. jQuery is all about DOM manipulation so there could be some turf wars.

Soft Skills

My ultimate goal is to one day be employed as a web developer. I don’t expect that to happen today, or even within the foreseeable future. It is the end goal, though, so I continue to work towards it.

As it turns out, learning to code is only half the challenge. I’ve read stories from some recruiters saying that they do not advertise for junior web developers anymore, because the second the ad goes up they get 1000+ resumes. I can’t imagine anyone wants to go through 1000+ resumes to find the perfect candidate, and I really can’t imagine what I could do to stand out in a field that size.

So nobody advertises for juniors anymore, but they still need to hire juniors. This is where the soft skills come in.

What The Crap Are Soft Skills?

Well, I guess Wikipedia says it best:

Soft skills are a combination of interpersonal people skills, social skills, communication skills, character traits, attitudes, career attributes, social intelligence and emotional intelligence quotients among others that enable people to effectively navigate their environment, work well with others, perform well, and achieve their goals with complementing hard skills.

I know the stereotype about coders. We’re all a bunch of anti-social shut-ins, more comfortable with email and message boards than face-to-face interaction. While this is mostly false, there is a kernel of truth here. I myself do not look forward to social interaction. Rarely do I find myself thinking, “Yay, I get to talk to people! Maybe even strangers!” I’d like to think, however, that I possess the skills to get through those situations and leave a favorable impression.

Soft skills are learned skills, and they require practice. I know it sounds silly. We’ve all been talking to other people our whole lives, why would we need to practice it? I’m fortunate to have a job what requires me to interact with people daily, both inside and outside of my company. When I first accepted my current position I didn’t realize just how much of it involved dealing with other people, but having to use those skills has given me a chance to grow those skills. How does that relate to finding a job?

The old saying goes, “It’s not what you know, but who you know.” This is pretty accurate, as I understand it, when looking for a junior position. You do need some coding skill, but the way to land that junior dev job is to know the people who are looking for junior devs.

Unfortunately, I’ve not been able to find a simple, lazy way to meet hiring managers or recruiters. There is not (to the best of my knowledge) a Tinder for junior web devs, nobody is going to be swiping right on your profile looking for a match. The best thing I’ve found is to go where I know I can find other people already working in the industry.

Slack, Discord, and Meetups, Oh My.

The big one here is the Meetups. Meeting people face to face, and having the necessary soft skills to make a favorable impression will take you a long way. I’m not suggesting going to these things in full-sell mode, approaching each individual as though you were a time-share salesman desperate for commission, but do be aware that the situation is a bit more than casual. If you make a bad impression here, people will remember that when faced with the prospect of seeing you every day at work. When you put someone down as a reference, you want them to tell the recruiter that you’re a super okay person who doesn’t smell and can form coherent sentences. Okay, maybe we should set the bar a bit higher than that. When I go to these meetups I ultimately want to meet people with the same passion as I have. I enjoy reading about code. I enjoy writing about code. I enjoy writing code and I really like talking to other people about code. These meetups give me a chance to do just that and the fact that some of these people might one day be coworkers makes it even better. Always, though, remember to present yourself as someone others would want to work with.

Slack and Discord are great ways for me to stay in touch with the people I meet at these meetups. Again, in these public settings it’s important to act professionally. It takes very little effort to ruin a good impression and an awful lot to improve a bad one. Even though I am not currently trying to “sell” myself to potential employers, it’s important not to tarnish the brand before the product goes to market.

Back To The Basics

Working through the course material at FreeCodeCamp moves you rather quickly from one area of Web Dev to the next. I began with basic HTML, CSS and a little jQuery. I made a few projects using what I learned, and then the course moved on to JavaScript and algorithm scripting. After many lessons in JavaScript I created a few more projects using my new-found JavaScript knowledge. All of this culminated with me earning my front-end certificate.

some random code

Next came the Data Visualization portion of the FCC course. This starts off right away with 5 projects under the heading “React”. This was a little jarring for me. Up until this point there had been a pretty consistent pattern of “here’s how you do a thing” then “go put that thing to use”. This pattern was not only broken, but shattered here in the Data Visualization section of the course.

In all fairness to FCC, although the project introduction videos specifically instructed the students to use React and Sass for these challenges, those instructions were omitted in the assignment text. I suppose I could have just tried to complete the assignments using the HTML/CSS/JS I had previously learned but I dismissed that idea rather quickly. React seemed like a pretty useful tool and I had noticed while nosing around on that many companies were looking for people who were familiar with React. So, I set out to learn React.

This Is Not A Story About Learning React

Phew, thank the coding gods. I’ve written my thoughts on React in a previous post, so I won’t duplicate all that effort here. However, React is vastly different than most of the things I learned while earning the first certificate. Well, I shouldn’t say different, it’s more in how it’s applied. And this leads me to the crux of today’s post. While working on the third React challenge, a project to create a recipe box with persistent local storage and functionality which allows the user to create, edit and delete recipes, I found the FCC help chat room. Most of the people I encounter here are working through the first certificate, which I had completed about a month prior to discovering this chat room. They come to ask questions about the lessons they’re working on and get help from those who have already learned what they need help with. My first thought while reading through these questions was, “holy crap I’ve forgotten all of that.”

Learning The New Without Retaining The Old

I suppose charging through the front-end lessons felt good at the time, but here I was faced with the realization that I had failed to retain all but a fraction of what I had learned. It was a classic ‘use it or lose it’ scenario. This in-and-of itself was not necessarily a bad thing; I know how to find the information if I need it, but at some level I felt bad for not retaining the information.

Since having that realization I’ve made a point to spend at least a portion of most days with the FCC help chat room open. While I may not actively be helping people, I do read through the questions and answers. I think about solutions others are coming up with, read through their code and try to figure out what I would have done differently or what I could incorporate in my future projects. As more and more questions get asked, I find that I recall more and more answers. It may not be perfect recollection but it’s definitely better than I had. Also, there’s something about explaining a concept to someone else that really helps me understand it myself.

Learning How To Learn

Web dev, front-end development, programming, coding, whatever you want to call it, is not easy. I’m sure at some point people get to a place where they can get through most of a day purely on the knowledge they already have, but I don’t believe that people live in that state for very long. All technology changes at a rapid pace, and everything you are confident you know today will be deprecated tomorrow.

Such A Gloomy Outlook

Quite the opposite for me, really. The worst thing that has happened to me professionally is stagnation. I really dislike knowing that everything I do today will be a repeat of yesterday, the day before, and the day before that. This is one of the key reasons I’m so infatuated with the idea of becoming a web developer. Some day I hope to be at the top of the game, on the very cutting edge of technology. And when that happens, the game will change and I will have a whole new game to learn.

The important thing for me is to always feel like there’s another mountain to climb, another path to explore, another sea to sail. I’ve always loved the quote:

And when Alexander saw the breadth of his domain, he wept for there were no more worlds to conquer.

I don’t know if Alexander the Great really said that, or Caesar to whom it’s often mis-attributed, but I can empathize with it. Maybe it’s a product of my limited, 30-something years of life experience, but I do not like the thought of never doing or learning anything again.

Learning How To Learn

All this rambling leads here. In web dev, you will always encounter things you don’t know. For me, I’m more surprised when I encounter things I do know. For everything else the most important thing you can learn is how to find what you need and the obvious solution there is Google. I don’t know how programmers did it before Google. I’m imagining huge stacks of dog-eared books, manuals, and a whole host of other reference material which will sadly be out of date by the time it makes it to press. I feel very lucky to have Google. And I use it. A lot. One thing that amazes me is now I can ask google something quite vague and ambiguous like “what does sort return” and third result down is a link from the Mozilla Developer’s Network telling me all about JavaScript’s Array.prototype.sort() method.

I wonder if programmers at Microsoft are required to use Bing? Maybe that’s why Windows is the way it is?

I’ve spent so much time pouring through github;s, Stack Overflow, MDN. Every question I’ve ever had I’ve been able to find an answer to, but the real challenge was learning how to ask the right questions, and how to vet the answers. Many times I’ve gone down a rabbit hole of solutions only to find the answer was presented seven years ago and is no longer viable.

In summation, to bastardize a quote from John Van Buren,

Google early, and Google often.

Most of my coding time is spent debugging. Most of my debugging time is spent Googling. And cussing. It’s really about 50/50.

NPM and Building Locally

Part of learning React for me involved learning a bit about Node.JS and NPM (Node Package Manager), Webpack, and some of their associated tools.
A list of files in my node_modules folder
I do love writing code in the text editor (I currently use Atom) so getting used to the NPM way of doing things was a logical step in my learning. For anyone not familiar, NPM is a utility that tracks all of the tools you use to develop your website (node modules), keeps them up-to-date or at a certain release depending on your requirements, and makes it easy for anyone else to install your package by automatically including all the necessary modules.

All of this magic happens through a file called package.json.

Looking in my node_modules folder, I see a total of 848 files for my current project. This would be intimidating to try to manage on my own, but having NPM manage it for me means that I don’t need to know what’s in there. In fact, the first time I’ve looked in that folder was to take that picture. What I do pay attention to is the package.json file, which looks like this:

  "name": "portfolio",
  "version": "1.0.0",
  "description": "A place to show what I'm working on",
  "main": "index.js",
  "scripts": {
    "start": "webpack-dev-server --open",
    "build": "NODE_ENV='production' webpack -p",
    "deploy": "npm run build && firebase deploy",
    "firebase-init": "firebase login && firebase init"
  "babel": {
    "presets": [
  "author": "Kyle Holm",
  "license": "ISC",
  "dependencies": {
    "prop-types": "^15.5.8",
    "react": "^15.5.4",
    "react-dom": "^15.5.4"
  "devDependencies": {
    "babel-core": "^6.24.1",
    "babel-loader": "^7.0.0",
    "babel-preset-env": "^1.4.0",
    "babel-preset-react": "^6.24.1",
    "css-loader": "^0.28.0",
    "file-loader": "^0.11.1",
    "firebase-tools": "^3.6.1",
    "html-webpack-plugin": "^2.28.0",
    "image-webpack-loader": "^3.3.0",
    "sass-loader": "^6.0.3",
    "style-loader": "^0.16.1",
    "webpack": "^2.4.1",
    "webpack-dev-server": "^2.4.5"

Even this can appear daunting, but most of this is generated automatically when running commands in the console. In fact, the only lines I had to add manually are the "scripts": entries and the "babel": entries.

Looking at each section of this file makes it a bit less intimidating. All we have is a bunch of key/value pairs, each with a specific purpose. I’m not going to go into details about all the things happening in this file, but everything in my node_modules folder gets managed right here.

I’ve heard that there are other package managers out there, and maybe someday I will branch out and give them a try. For today, I really like using NPM and all the hard work it does for me. When I team it up with Webpack, I feel like I can really focus more on creating, and less on the tools I use to create. I’ll talk more about Webpack later.