DEV Community: Adam Friedl

Learning and Working and Family-ing

Adam Friedl — Wed, 07 Mar 2018 15:15:59 +0000

There are literally thousands of resources these days that can help you learn how to code. Do you have the desire and the grit? You can become a software developer. This is definitely true as far as it goes, but it often silently assumes that you have an infinite supply of other equally important resources — namely time. If that's true for you, mazel! Take advantage. But, for many of us, it isn't true — particularly those raising young kids and working full-time.

All of that is to say how much I really appreciated hearing a recent episode of the CodeNewbie podcast that took a minute to shout out to those folks. The ridiculously talented Sarah Drasner and always-awesome host Saron Yitbarek took a minute to say "props to you all! We don't know how you do it," and it's hard to express how validating that felt.

When I try to convey to folks how passionate I am about coding, I explain that I went through an online bootcamp when my daughter was an infant and I was working a full-time lawyer job. I try to take advantage of every free second to learn or practice. I still frequently get up at 4:30am and stay up late into the night to make the time. I'm hardly alone. There are so many of us, many folks with time crunches much more challenging than my own. They're sacrificing sleep and family time because they love this thing and want to be good at it.

I've often found it frustrating that there is not more discussion of this topic in the dev community online. So many thanks to Saron and Sarah for the good words!

A Parade of Text Editors

Adam Friedl — Mon, 15 Jan 2018 15:59:43 +0000

I suspect that many folks attracted to programming share this trait, but long before I ever read a line of code, I was particular about my "tools." I'd spend hours trying different pens, or search all over town for a notebook with just the right size, binding, paper thickness and ruling (dot grid, anyone?). And occasionally I'd find a setup that really made me happy, although I could never shake the idea that there might be something out there just a little bit better.

When I got interested in coding a few years back, the only text editor I knew of was Text Wranger. That's what this guy at work used, and I thought he must be a genius coder (later I realized that he'd never learned CSS and laid out web pages with HTML tables). I started watching lots of web tutorials online, and it wasn't long before I saw someone open Sublime Text (he just called it "Sublime," because he was cool like that). And I soon found that Sublime Text was in fact pretty awesome. You could spend (waste(?)) days perusing all the different extensions and options.

As great as Sublime Text was, though, I always had my eye out for something better. When I finally got serious about coding and attended an immersive program, they recommended Atom, which was the new-ish kid on the block. I used it for most of a year and it has a lot to recommend it: it's free (which Sublime Text definitely wasn't), open-source, built by Github. What's not to like? Well, mainly that it's painfully slow to start up and hangs often... So when I saw one of my coding heroes using Visual Studio Code, you know what happened next.

VS Code is the best text editor I've come across. It's quick and flexible. It has a seamless integrated terminal and a robust ecosystem of extensions. As someone who currently writes mostly JavaScript, I find its version of tools like ESLint, Prettier, npm Intellisense, as well as snazzy visuals like VS Code Great Icons, to be easy to incorporate.

Is there still something better out there? Probably! Let me know what you think.

Hoist with his own JS Petard

Adam Friedl — Tue, 12 Dec 2017 12:49:17 +0000

In JavaScript, hoisting refers to the idea that declarations — of both variables and functions — are automatically moved to the top of their scope. Note that this doesn't mean they are physically moved in your file. Rather, it's shorthand for explaining a key aspect of execution context — specifically, the order in which the JavaScript interpreter, well, interprets the information in any given scope. We'll illustrate with some examples in a minute, but, first, an important question: what does "hoist" even mean?

Liberal Arts Interlude

Hoist is a mid 15th-century English word derived from similar words in other Germanic languages (e.g., Dutch and Low German) meaning "to lift up" or "to raise." Its most famous use in English is undoubtedly by our friend Shakespeare, in Hamlet. Hamlet, realizing that his supposed friends are actually carrying a letter with Hamlet's death warrant, secretly alters the letter so that they will be killed instead, and remarks "For 'tis the sport to have the enginer / Hoist with his own petar'." A petard was a small bomb used by military engineers, raised onto gates or obstacles to blow them up when breaching a fortification, and, so, to hoist with his own petard became an English idiom meaning "to blow oneself up with his own bomb" or "to fall into one's own trap." A bit like what can happen to the software engineer who doesn't take hoisting into account when putting together JS code.

Code Examples

So, back to it. The JS interpreter in the browser works as a single thread, meaning only one thing can happen at a time. Every time it considers a new scope, it does these several things in the same order. Among them are looking through the entire scope for function and variable declarations and executing functions and assigning values to variables — the former always before the latter. The practical effect is to interpret the code as if all declarations were hoisted to the top of their respective scopes, while assignments stay in their original places. For example:

badDude = 'Kylo Ren';
var badDude;
console.log(badDude) // prints 'Kylo Ren'

Even though we never assigned a value to badDude after declaring it as a variable, it still logs 'Kylo Ren' because the declaration was hoisted to the top of the scope before the code was executed, as if we had written:

var badDude;
badDude = 'Kylo Ren';
console.log(badDude) // prints 'Kylo Ren'

Note that this is the case for variable and function declarations. In fact, function declarations are hoisted first.

goat(); // prints "Messi is the greatest of all time!"

function goat() {
  console.log("Messi is the greatest of all time!");
}

Here we declare the function in the global scope, the same scope in which goat() is called, and thus the function declaration was hoisted to the top of the global scope, above the function call.

Note that this is not the case, however, when a function is the assigned value of a variable. If we modified our example so that it read:

goat(); // undefined

var goat = () => {
  console.log("Messi is the greatest of all time!");
}

var goat is hoisted to the top, but the expression assigned to it stays in place — below the function call — so that goat() prints undefined.

Remember the Scope!

Declarations are hoisted to the top of their scope, not necessarily to the top of the file. For example:

var leadSinger = 'Diamond Dave';

(function vanHalen() {

  console.log('First lead singer was ' + leadSinger);  // prints undefined

  var leadSinger = 'Sammy Hagar';
  console.log('Second lead singer was ' + leadSinger); // prints "Sammy Hagar"
})()

How anyone might not know that David Lee Roth was the first (and only true) lead singer of Van Halen is beyond me, but that's JavaScript for you. Here, the re-declaration of leadSinger variable jumps to the top of its scope (in this case, the local or function scope), while its assignment stays in place. It overwrites the assignment made in the global scope and is thus undefined when we arrive at the first console.log(). If we wanted to to give Diamond Dave his due, we could simply not re-declare leadSinger, but just reassign it.

var leadSinger = 'Diamond Dave';

(function vanHalen() {

  console.log('First lead singer was ' + leadSinger);  // prints "Diamond Dave"

  leadSinger = 'Sammy Hagar';
  console.log('Second lead singer was ' + leadSinger); // prints "Sammy Hagar"
})()