How to Raise Your Kids to be Asian

This article was lighting up Twitter today, so I took a peek. The premise is that Asians in America are routinely discriminated against in the college admissions process, at least among top tier private universities. This trend is nothing new, and, rather than debate the point, the article focuses on why Asians excel in the first place.

Well, as it turns out, I'm an Asian American who went to college, and therefore I have something worthwhile to say about this topic!*

*Remember when Vice President Dick Cheney shot a man in the face, and everyone, overnight, became a comedian/expert on the matter? That's kinda how I felt when this article came out.

Life isn't fair

Some people are blessed with swoopy hair and trust funds. Others are blessed with immigrant parents who work their fingers to the bone so that their children have a better life. I would fall in the latter category. Here are the unfair advantages that I had growing up:

  1. Parents who left their home country because they wanted their kids to get a better deal. I remember visiting Seoul with my mom when I was 5. On the plane ride back, when she thought I was sleeping, she cried to herself, silently. I have never, ever forgotten that -- my beautiful, unreasonably cheerful, strong-as-nails mother suddenly seeming so vulnerable and sad. I imagined how heartbroken I'd be if I had to leave her, my dad, my brother and my sister behind to go to a new country, and realized that was exactly what she did for me. I didn't know it at the time, but what I felt eating into my heart, it was guilt. That guilt stays with you. That guilt gets you into the Ivies. 
  2. A cultural community where education is everything. It's easy to ace the SATs when you start studying for them in junior high. Have you heard of Kumon? It's basically a place where you do math problems in a booklet for gold stars that map to, literally, nothing. My sister and I started that in elementary school. I began piano lessons when I was 6, then switched to flute at 11 because it was "edgier." My dad took us to the library every week, where we'd check out no fewer than 20 books at a time, followed by lunch at Arby's. Reading, writing, arithmetic, and beef 'n' cheddar sandwiches. This was life in the Kim household. 
  3. A cultural community that values grit. The power of hard work and human agency is a common thread in the Korean community. Work hard. Work harder than you can imagine. Work harder than everyone else. Don't complain. This is the norm for most Korean youth, particularly those who are fortunate enough to have immigrant parents. My parents had very high expectations for me, but these expectations were backed by unconditional love. Who was I to complain? 
  4. A really good Korean church. Korean churches are LEGIT. Organized religion kept me on the straight and narrow, and made me a better person. I did a lot of volunteer work through church, and met all kinds of people who were way worse off that I was. As a practical matter, it's hard to get into trouble when your weekends are occupied practicing flute with the praise band. My faith became especially important for me in high school after I finally grew boobs. Those boobs were for Jesus. Besides keeping me out of trouble, religion gave me a safe space to be myself -- a total weirdo -- and be OK with it because I knew there was a higher power out there who had a plan for me. And, as it turns out, hardworking weirdos at peace with themselves totally win at life. 

The majority of these advantages can be replicated by anybody. Raise your kids to work hard, teach them that they can do anything, provide a strong moral compass, and love them unconditionally. The one thing that you can't replicate is immigrant guilt. That is super powerful and amazing. I think its power comes from the complete lack of entitlement, and prevailing sense of gratitude it imparts. Growing up, we never felt anyone "owed" us anything. We were just super fucking happy that our parents moved to America! If you can find a way to instill those values somehow, you'll be good.

Inconclusive Factors

There are a few other factors of my upbringing that contributed to how I turned out, but I'm not sure were essential to success. In any case, most Asian students at top universities probably didn't have all these advantages, and they turned out fine.

  • Getting teased for being different. When I was little, kids routinely teased me for being weird. Rocking an Asian Mom Perm as a kindergartener probably didn't help. In middle school, a mean girl called me a "chink." (To which I responded, "That's not even the right racial slur!" and then cried.) I got rejected from the drill team, which is possibly the dorkiest after-school activity to get rejected from. Kids teased my brother all the time. All these things made me stronger, more empathetic, and more driven to get the hell out of Sacramento.
  • Having an autistic brother. The New York Times did an excellent series on autism in America back in 2004. One article focused on the impact that an autistic child has on his or her siblings. It can be stressful, but for me it was a healthy kind of stress. Children are far more resilient than many of us assume. More than anything, it helped me bridge cultures -- between Korean and American, and between autistic and everyone else. I dealt with a lot of complexity, and had a lot of opportunities to solve real-life problems from a very young age. 
  • Going to public schools. I'm a big fan of public schools. School taught me how to be scrappy and exposed me to a ton of diversity. Sheltered I was not. I know a lot of students get in to top tier universities from elite private schools, but that's not how I did it. I did it by going to decent public schools, and making the most of every resource I could find. I spent lunch in my high school guidance counselor's office poring over the scholarship binder. I was in every academic club. I hustled and got things done. College was a pristine bubble compared to high school. 
  • Being raised in Seoul by a loving extended family. I was born in America, but my parents sent me to my grandparents when I was baby because, with two little ones already, they needed help. I spent the first 3 years of my life being loved and doted upon by my grandparents, aunt and uncle. All of this adult attention turned me into a little monster, and is the best explanation I have for my unjustifiably high level of self-esteem today. I didn't realize this until after I read Tina Fey's Bossypants, where she recounts the boundless encouragement she received as a child after being slashed across the face by a stranger in an alley, and how that attention made her think she was special. I got all the benefits of that, without the violence.
Growing up in Korea, dressed like my grandpa

Growing up in Korea, dressed like my grandpa

"Cultivate the Karass" -- Saying Goodbye to Jake Brewer


Karass: "A network or group of people who, unknown to themselves, are somehow affiliated or linked, specifically to fulfill the will of God."   -- Kurt Vonnegut, Cat's Cradle, 1963

Jake's mom, holding the post-it that he had on his monitor at the White House

Jake's mom, holding the post-it that he had on his monitor at the White House

My So-Called Life , episode 14: "The Wagon"

My So-Called Life, episode 14: "The Wagon"

Last Saturday, we lost Jake Brewer, at age 34. He spent his life helping others, died helping others, and made the world a better place. He is survived by his incredible wife, their little girl, and a baby on the way.

In other news, absolutely nothing about life is fair.  

I met Jake 7 years ago, back when I was living in DC. We were part of the same group of friends, slouching purposefully towards adulthood together. I didn't see him often, but every month or so I'd hear from him by email, or read about something cool he was working on. 

I was sure that our paths would continue to cross, since he was working on tech policy, right around the time I left government and joined Udacity, an education startup that few people had heard of. Jake, being Jake, sent me a note of encouragement.

The last time I heard from Jake was in May. He was two weeks away from being appointed to the White House, and he took the time to respond to an email I sent to our friends group asking about contacts at 18F.  A friend of mine was interviewing there, and I wanted to put a word in for her. 

That was Jake. No matter what was going on in his life, no matter how busy his day, he made time to help a friend of a friend. 

Later that month, I heard the news that he'd joined the White House as a Senior Policy Advisor to Chief Technology Officer Megan Smith. At the time, I was working crazy hours, and I didn't pause to congratulate him for this seriously awesome achievement. I told myself I would "later," then I forgot. That's because I'm not Jake Brewer; none of us are, or ever will be. Now that he's gone, we all need to step up our game.

Today, a friend sent me a photo of a post-it that Jake had tacked onto his monitor at the White House: "Cultivate the Karass." 

That was the perfect way to describe it. Of course, Jake! We were part of the same karass. I'm sure many people felt this way about him. Jake dreamed big and believed not only in his dreams, he believed in yours, too.

There’s a concept called Dunbar's Number that posits that a single human being can only have 100-250 “stable social relationships,” which refers to “relationships in which an individual knows who each person is, and how each person relates to every other person.”

Jake basically exploded that concept into outer space. His Dunbar Number was easily in the thousands. Which makes sense, knowing Jake. He was always an extreme overachiever, and that extended to his superhuman capacity to love and connect with others.

Jake's funeral (I can't believe I'm typing this) is this Friday at the National Cathedral, so instead of graduating from Hack Reactor as planned, I’m flying 2,442 miles to say a final goodbye and thank you to my friend. 

Jake’s passing has me thinking a lot about our purpose in this world, which I suppose is cliche, but I’m human, so bear with me. I'm going to revisit this thought in a moment, but right now, I need to tell you about something important.

When I was 10, my brother died in his sleep, a few weeks before his 14th birthday. He was mentally disabled, and two autopsies revealed no conclusive cause of death. He went to bed, and, come morning, his sweet, loving spirit had left us.

That night, I remember watching the local news intently, waiting to hear the newscaster broadcast his death. But there was no announcement. The next day, I got up at the crack of dawn to wait for the newspaper -- surely, the Sacramento Bee would print a front-page article about "the tragic passing of Edward Kim, aged 13." But there was no article. There wasn’t a single mention anywhere of the light that had gone out of my world.

To me, it was shattering. This was the most painful event of my young life, and I couldn’t understand why the whole damn world wasn’t hurting as bad as I was. People should know about my brother. They needed to know. Because he was beautiful and special and utterly important. I thought if the world only knew, it would validate my pain somehow. But the world didn’t know. And so the world kept moving, not stopping for even a glance.

The world felt a lot smaller back then. There was no Facebook, no Twitter. It was the era of dial-up and AOL (if you weren’t around for this, imagine the sound of, “oooinggeeeeonninggeeeongkk,” followed by, “You’ve Got Mail!”).

My family and our close friends were alone in our shared grief. The walls of our home enclosed it, like something finite and palpable, as if opening a window would let it seep out and escape -- the smells of Korean potluck left out in Pyrex casserole dishes, the warmth of our family room where bodies huddled on overstuffed sofas, the sounds of my mother wailing, the prayers to God sent heavenward, the voices of children crying and asking why -- our grief was contained within four walls, under one roof. Our grief was unitary, compact, an island. It was unfathomable, and it was all ours to bear.

In the years since then, I’ve lost friends and family members, as many of us have, and the act of grieving is different every time. Social media has changed the way we know each other, so naturally it’s changed the way we mourn each other. Our grief is diffuse, broad, visual, and everywhere.

When I heard about Jake last Saturday, I was in shock. I read the initial news item in the Post, and thought, “This isn’t enough. This doesn’t tell the world enough about who Jake was.”

I knew in the days ahead, his beautiful, loving family and his vast network of loyal friends would tell that story. And they did. We did. On Facebook and Twitter. On email lists and at gatherings. In the New York Times and the Washington Post. On TechCrunch and Re/code. On FOX News and MSNBC. Even from the offices of the White House, where President Obama issued a statement. Unlike my brother, the world knew who Jake Brewer was. They cared. They understood the magnitude of what was lost.

The strange thing is, the recognition, itself, hasn't made the loss any easier to process. If anything, it makes grieving more painful because you realize, objectively, how much Jake meant to so many people outside of your orbit. It's like standing before the Pyramids of Giza. You look up, overcome by the scale of the thing. It is grief, beyond measure. And it is heartbreaking.

I don't know how one person was able to touch so many lives, to be a friend to such a broad slice of humanity. At one of several memorial services that hosted this week, a friend talked about how Jake always made sure to open 5 slots for every one that he took. Another friend noted that Jake knew himself, but he also knew who he strived to be, and he worked his ass off everyday to be that person.

All of this has me wondering, with respect to my year-long journey to become a software engineer, “Why am I doing this, anyway?

Ultimately, I’m doing this because I want to build things that help people. I'm doing this because I want to solve real-life problems with code. I'm doing this because I want to, in Jake's words, "totally rock this," and, like Jake, I'm going to bring a shit-ton of people with me along the way.

So, I guess, my question to you is: Why are you doing what you’re doing? What is your life’s higher purpose?

That's a question that Jake would have loved to chew on. We can't have that conversation with him, so let's have it with each other, with Jake in mind. Let's cultivate the karass. For Jake. 

Understanding Redux (or, How I Fell in Love with a JavaScript State Container)


While researching which flux implementation to use for our team's final project at Hack Reactor, my friend Nick enthusiastically recommended Redux. (Nick is a brilliant front-end engineer who I worked with at Udacity, and is among the most curious and inventive people I know. So when he gets super excited about something, I pay attention.)

If you haven't heard of Redux yet, that's OK. The creator, Dan Abramov, announced it at React-Europe 2015, which, at the time of this writing, was 2 months ago. Was it risky adopting something so new for our team's project? Yes. But the more I learned about Redux, the more obsessed I (and my team) became. And we were not alone.

Goals of this Article

By the end of this article, you should:

  • Be able to explain to a friend what Redux is, and why it makes so much sense to use it with React.
  • Be able to describe the basic concepts behind Redux and React, particularly in contrast to traditional MVC architecture.  
  • Know where to go for high-quality resources to get started! 


  • This is not a tutorial or a code lab. There will be very little, if any, code in this article. I'm working on a Redux/React/Webpack tutorial (follow me on Twitter for updates), and there are a number of great resources listed in the last section, if that's what you're looking for. 
  • This is not a deep discussion of MV*-whatevers. We can go on and on about the pros and cons (and many have) of various frameworks, but here's the truth. No matter what you choose -- a framework, a library, or nothing at all -- every programmer needs their app to do two things: Display stuff to the user, and track data. That's it. Redux/React is just one way to accomplish those two, age-old tasks. 

Assumed Prior Knowledge

I assume that you've heard of React, and ideally have read Thinking in React. If you haven't, you might not get as much out of this article because Redux is really, really brilliant when paired with React. If this is all new to you, it can be hard to tell where React stops and Redux begins (it was for me anyway), so having prior knowledge of React will make these conceptual distinctions more clear. 

I also assume that you know what MVC frameworks are, and ideally have used one before. While this prior knowledge is not required to grasp the concepts in this article, it's helpful because part of how I understand and communicate  Redux/React is by comparing it to well-known MVC frameworks like Backbone and Angular. 

What is Redux? 

I'm going to start with an analogy. Imagine you have a room with a sofa and a table, like this:

You want to swap the positions of the sofa and table, and you need it done FAST, so you hire two butlers, Alfred and Rudy, to complete the task at once. 

Alfred is in charge of the sofa, and Rudy is in charge of the table. You give them instructions to coordinate, so they aren't crashing furniture into each other. 

First, Rudy moves the table out of the way, then Alfred moves the sofa in position. 

Next, Rudy moves the table where the sofa used to be. The room now reflects its new desired state.

Super! I've just described a common implementation pattern found in MVC architecture. That wasn't so bad, but let's take it up a notch.

Now imagine you have a GENIE. This Genie provides a completely new instance of the room whenever you want to make a change to anything inside of it. And by "new instance" I mean, unlike Alfred and Rudy, she does not go inside Room A and move stuff around until Room A looks like Room B. She actually creates a new, unique room that is exactly Room B. If that wasn't enough, she also reads your mind. I know, right? It's an excellent setup you've got here. 

Instead of giving instructions to multiple butlers about what goes where, all you do is think, Hey Genie, I want this room to be this other room, which right now exists in our shared mind palace.

And POOF. Your Genie returns that new room in real life, so you now have TWO rooms, like this: 

The Genie? That's what Redux achieves with React. That's right. THE GENIE IS REAL.

Why is this desirable? Let's say the new furniture configuration is problematic for some reason. Like, maybe the sofa blocks a doorway, which creates suboptimal feng shui, and, also, a fire hazard. Instead of having Alfred and Rudy go back and re-position the furniture to where it was, you can just toss aside Room B, and flip back to Room A. 

Or, you can think of a completely different configuration, Room C, and your Genie will return it. If you ever want to revisit Rooms A or B, you can flip back to them. You might think that producing new rooms in this manner is wasteful and slow. It's not. Why? Because she's a motherfucking genie. This is her thing. 

Seriously though, right now, it's not important to know why it's fast, just know that it is very, very fast -- in fact, it's faster than the "If this, do that, then do this other thing..." approach embodied in the butlers example.

The capability to create new, immutable states is somewhat grandiosely (or maybe just dorkily) called "time travel" because you can traverse between your app's states. This is what React/Redux gives you. React provides the ability to spin up new rooms, and Redux provides the Genie mind-reader logic behind their production. This logic is very important, and is different from other implementations of a concept called flux, which we'll discuss briefly, next. 

OK, What is Redux, Actually? 

Redux, according to the docs, is "a predictable state container for JavaScript apps." It's a very lightweight (2kB) implementation of flux. If you haven't heard of flux before, that's fine. Nick explained it to me in about 10 seconds. 

Basically, flux is like a sedan. It's a concept with many agreed-upon characteristics associated with it, but it's not, itself, a tangible thing. Just as there's no single definitive "Sedan" that you can go out and buy, there's no definitive "Flux" that you can download and install. Instead, you choose one specific implementation of it. I don't know much about cars, but whatever the most minimal, stripped down, yet highly performant sedan is, that's Redux. 

The basic idea behind flux is, you have a dispatcher that sends actions to the data store, and updates the view. It's an overall data flow architecture, where -- unlike the two-way data binding of MVCs -- updates only go one way. If you've ever been in getter/setter hell trying to track what view is touching what model, you can understand how a one-way data flow might be beneficial. 

Note: This isn't a knock on frameworks like Angular (which I still think is pretty magical) or Backbone (which I... respect as a thing), or any other MVC. In general, I try not to get attached to any one way as the best way for everyone. What constitutes the "best" approach really depends on your application, your use case, and your organization's needs and constraints.

With all that said, here's a helpful diagram from Facebook's Flux documentation:


One huge implication of one-way (or unidirectional) data flow is that your data store is not touched by your view. At all. 

Redux is one particular implementation of a subset of flux concepts. The main differences between Redux and full flux implementations are:

  • There are no discrete dispatchers in Redux; your store listens directly for actions, and uses a function called a reducer (more on this later) to return a new app state each time an action is dispatched. 
  • Redux holds your entire application's state in one place.
  • Your app's state is immutable.

Consider your app state as a tree, with a root and child nodes. If you want to make a change to a child node, you can't change it directly because state is immutable, so you make a copy of the target node and apply your changes. You also make a copy of the target node's parent, because it wouldn't make sense to have one parent produce two versions of the exact same node. Maybe you append a child node to the new node, too. That's fine. At the end of all this, you just need to attach the existing, unchanged nodes to your new ones. Like this: immutable

The best part is, the original state (the blue one) still exists. The unchanged blue nodes are not re-rendered in the new state, just the orange nodes. This makes debugging really easy because you can isolate the action that caused the state change, and go back and forth at any time. Redux dev tools also happen to be unusually good (see the next section for an example), and, combined with React dev tools, have basically spoiled me for life.  

Another implication of this design pattern: You really cut down on the number of dependent asynchronous operations in your data flow. Going back to the room example, recall how you managed the butlers: "Wait for the table to be out of the way, then move sofa..." 

Contrast that to the declarative statement: "Sofa and table are positioned at (fill in the x,y coordinates here)." The end. No waiting for Rudy or Alfred or whoever to clear the way first.

Intuitively, this makes sense. If you want a room with a sofa and table in it, positioned in a certain way, then why should it matter the order in which  items are placed? This straightforwardness is what really won me over -- it just feels right to me. 

How Does Redux Work?

Redux is astonishingly simple. It uses a function called a reducer (a name derived from the JavaScript reduce method) that takes two parameters: An action, and a next state.

The reducer has access to the current (soon to be previous) state, applies the given action to that state, and returns the desired next state.

Reducers are designed to be pure functions; meaning, they produce no side effects. If you pass the same input values to a reducer 100 times, you will get the exact same output value 100 times. Nothing weird happens. They are completely predictable. As someone with a prominent "NO SURPRISES" sticky note on my monitor, this is a wonderful idea to contemplate.

Reducers do not store state, and they do NOT mutate state. They are passed state, and they return state. This is what reducers look like in action (did I mention that the dev tools are awesome?):

The above is the console after two actions: "Fetch Friend," followed by "Save Gifts." The first action passed FETCH_FRIEND to the reducer with an updated friend object that is returned in the next state. The second action passed SAVE_GIFTS to the reducer, along with an array of 4 gifts. The next state reflects this updated gift array. As usual, you can see exactly what existed in the state before and after this action occurred by simply inspecting each object.

Note that the reducer is passed only the slice of state that requires updating (the friend object and the gifts array, respectively), and it returns a new state after each action is dispatched.

How Do I Get Started? 

Woohoo! You are entering a brave new world with me! Yay! It is very exciting, and also, at times, a real pain in the bottom. So before you dive in, some caveats:

  • Redux and React are often used with a module bundler called Webpack. Webpack is incredibly powerful, and one day, it will be well-documented and easy to use (or it will wither and die of JSPM). In any case, that day is not today (Sept. 15, 2015). For now, do NOT worry about it, and just focus on learning the fundamentals of Redux and React with the resources below. 
  • Most code examples you see will use ES6 syntax. This can be confusing, and looks sort of... like Python and Coffeescript got drunk and had a baby. Fear not! Use Babel's transpiler tool. Just cut and paste the ES6 on the left, and you'll see familiar old ECMA5 on the right. Believe it or not, you'll get used to ES6 pretty fast (even the switch statements, I promise).

If you are looking for polished, well-documented code examples, and stable builds, then this is not the right time for you to try Redux. And that's totally fine. You can always come back in a few months, or when you have more time to dig through documentation. 

Selected Resources 

I've gone through a horrifying quantity of material on flux, Redux, React, Webpack, ES6/7, and god knows what else. I think at one point I was reading about Drupal (don't ask). Below are the best resources I've found, optimizing for fundamentals, clear examples, and sound teaching strategies. 

Required Basics (listed in order)

Live React -- 30-min talk by Dan Abramov, who basically invented Redux on accident (just like penicillin!). He explains Redux in beautiful amazing live code. It's especially useful to see, step-by-step, how he came upon reducers while paring down his flux workflow. 

Thinking in React -- A fantastic guide to React by Facebook's Pete Hunt that helped me fully grasp how React and Redux are perfect for each other. 

Redux Tutorial by François Bonnefont -- Of all the Redux tutorials and code examples I've reviewed (at least 20), this is easily the best at explaining the fundamentals, and walking you through each step. I recommend forking and cloning the repo, and replicating the code samples as you go along. Make sure to read the README. It includes important instructions on how to run the code examples from your terminal. 

Advanced: After you complete the above, and are ready to build a full-stack app from scratch using Test-Driven Development practices, check out @Teropa's Full-Stack Redux Tutorial

Extra Credit 

Immutable Data and React -- 30-min talk by Facebook's Lee Byron from React-Europe that explains why persistent, immutable data structures are the way of the future. 

What the Flux, Let's Redux -- A good overview of why Redux is exciting. The author, Henrik Joreteg, also made a great Webpack template, if you need it later. But, as I said, don't worry about Webpack while you're still learning the basics of Redux. 

Building CircleCI's Front-End with Om -- While not about Redux, specifically, Brandon Bloom does a really nice job of explaining the benefits and trade-offs of a similar implementation in the wild.  

Important References

Official Redux Documentation -- Redux is still new, so keep in mind that documentation is still a WIP. Check out the examples when you're ready. Implement the Counter example to get a quick start. The most helpful example for me was the Real World one. 

Awesome Redux -- A comprehensive resource list of everything Redux. I found this a little overwhelming to start with, but once you know what you're looking for, it's a great resource. 

Official React Documentation -- The React docs are kind of hit or miss, but definitely worth reviewing and bookmarking. You will be referencing them a lot as you get to know React. 


Calculating days between dates in JavaScript

I'm working on a React/Redux app that pulls your friends' upcoming birthdays from Facebook, and recommends gifts for them based on their profile data. Our team finished the MVP (aka, "minimally viable product") this week, and one of the last TODOs was to render a user's friends list by upcoming birthday. We wanted the soonest birthday to show up first. 

I took on the task, and had a lot of fun understanding the problem, and discovering edge cases. I also learned more about JavaScript's Date object, which is very handy. 

My Approach

  1. Get today's date, which you can do with JavaScript's Date.getDate() method. This will return the number of milliseconds between January 1, 1970 and today (long story). Add 1 to the month because JavaScript starts counting at 0, and you want to set January to 1, not 0.
  2. Get friend's birthday from Facebook, also in milliseconds
  3. Change friend's birth year to the current year, since their upcoming birthday is what you care about
  4. Subtract today's date from friend's birthdate. If result is negative, that means that your friend's birthday has already passed, so add 365 to get the number of days until their next birthday (TODO: account for leap years)
  5. Do some work to order your friends by upcoming birthday, soonest first

You can find the commented code on GitHub here. I also added it below, for convenience.

// Redux uses switch statements in its reducers. 
// It's not so bad once you get used to it, I promise.

  var getDaysFromToday = function(birthday) {
    if(!birthday) {
      return null;
    // create new Date for today
    var today = new Date();

    // add 1 to current month because getMonth returns months starting at 0
    var currentMonth = today.getMonth() + 1;
    var currentYear = today.getFullYear();
    var currentDD = today.getDate();
    // create new Date for today, reflecting adjusted month
    today = new Date(currentYear, currentMonth, currentDD);

    // initialize array to hold friend's 'MM/DD/YY' bday as [ 'MM', 'DD', 'YY' ]
    var friendBdayArray = birthday.split('/');
    var friendBdayMonth = friendBdayArray[0];
    var friendBdayDD = friendBdayArray[1];

    // create new Date, replacing birth year with current year
    var friendBday = new Date(currentYear, friendBdayMonth, friendBdayDD);

    // calculate time between now to friend's day -- getTime() returns time in ms
    // NOTE: if day is in the past, elapsed will be negative
    var elapsed = ( friendBday.getTime() - today.getTime() );
    // divide by 86,400,000 to convert milliseconds to days
    var daysFromToday = Math.floor(elapsed / 86400000);
    // add 365 to any negative daysFromToday value to get days until next year's date
    daysFromToday > 0 ? daysFromToday = daysFromToday : daysFromToday = daysFromToday + 365;
    return daysFromToday;    
  // append daysFromToday to each friend object and push to friends array
  var friends = [];
  action.friends.forEach(function(friend) {
    friend.daysFromToday = getDaysFromToday(friend.birthday);

  // sort friends in array by daysFromToday in descending order
  friends.sort(function(friendA, friendB){
    if (friendA.daysFromToday === null) {
      return 1;
    if (friendB.daysFromToday === null) {
      return -1;
    return friendA.daysFromToday - friendB.daysFromToday;
  // finally, return the updated state (es6 syntax)
  return Object.assign({}, state, { friends: friends });

How to run/build JavaScript code in Sublime

Confession: I setup a Node build system in Sublime before I even know what Node was. As soon as I installed Sublime, I wondered, "Why can't I run anything in JavaScript in here?" 

So I googled and figured it out. Of course, I promptly forgot how I did it (people at Hack Reactor have asked, and I just stare at them blankly). 

Luckily, Eliot Winder has documented this process for us! Check it out.

CMD-B, y'all. It's a game changer. 

Hack Reactor Mail Bag!

Hello, reader! 

I've gotten a variety of questions about Hack Reactor, and am batching them here since they are often repeat questions. My goal is to help prospective students without undermining Hack Reactor's admissions or assessment processes (I'm not going to repeat what questions were asked, and how I answered them, for example). 

Keep in mind that Hack Reactor updates their processes regularly, so my experience may not be relevant to whatever is in place by the time you are reading this. 

With all caveats declared, on to the questions! 

About that Hiring Day Assessment...

Question: In "Day 41 of Hack Reactor: Hiring Assessment and Solo Week", you mentioned the repercussions of not passing the assessment. If you don't pass it, is there an opportunity to take it again? Does anything else happen if you don't pass? Have you heard if you have passed yet and do you know the pass rate?


If you don't pass, there is not a second chance to take the exam. The point of the assessment is to do just that -- assess where you are, at that point in time -- not to pass the exam, itself. What matters is that you and the teaching team at Hack Reactor have a solid understanding of where you are, relative to the bar they set for hirable engineers, and if you aren't where you need to be, then you have a good basis for planning how to get there. 

I cleared the bar, but I found that the assessment was a legitimate challenge. I don't feel comfortable disclosing the pass rate because it's going to vary per cohort, and cohorts are relatively small (40 students in mine), so even one person not passing will have a non-trivial impact (on an absolute scale) on the pass rate. I can say a very small number of students did not pass the assessment. If you don't pass, then Hack Reactor cannot recommend you to their network of companies, BUT they will still help you strengthen all the skills you need in order to get a job as an engineer (technical skills, professional skills, interview prep, etc). 

Just to be clear, passing or not passing the Hiring Assessment (or ANY test), says nothing about your potential. It says nothing about how hard you've worked, or how hard you will continue to work to reach your goals. It says nothing about you as a person. All it reveals is where you are, on some pre-set scale, at some arbitrary moment in time.

Had I not passed, I would continue to make the most of every opportunity to learn and grow, which is what I've done my whole life, and what has gotten me so far in the first place. I would continue to have the same, positive attitude about learning and finding solutions to novel problems, and I'd continue to seek out help and feedback in areas where I need to improve.

Most importantly, I would be just as proud of how far I've come, whether I had passed the test or not. No test could ever change that.  

Admissions: If you get asked to submit a project...

Question: How did you decide on what project to create? More specifically, how did you decide on something that might show the growth you've had since your last interview, without picking something too ambitious? 


I took the Udacity Javascript basics course (all content/projects free) and did the resume project. I also made a TODO list after taking a Treehouse course (paid). I submitted both, and am not sure if one or the other was more responsible for getting me a second interview.

If I had to do it again, I would pick ONE project that involves taking a user action (i.e. a click), and having that action render something to the DOM (i.e. display a photo) on the screen. I would not focus on style, just on pure functionality.

The "Cat Clicker" project in JS Design Patterns (free) is a fantastic model.

Don't feel like you need to rush to complete the project just so you can say that you did it. What's important is that you actually understand what is going on in your program, so you could explain it to someone if asked.

You should be able to explain your app logic, for example: What happens when a user clicks on the button? What is communicated to your program? How does your program handle the click action, and what does it do as a result? 

If you take the time to build and fully understand a project like the Cat Clicker (or anything else that involves a user interacting with the DOM, and something happening to the DOM as a result), you will be in a really, really good place entering Hack Reactor, and should have no problem with the interview because you'll learn so much through building the project. 

The callback struggle...

Question: I am having the same issues with understanding callbacks as it look like you were when applying. I applied to MakerSquare and got the same " you're so close" email as you and am supposed to interview again in two weeks. Would you be willing to or know someone who could talk to me about callbacks at some point? I'd really appreciate it!!!


If you are struggling with callbacks, you are not alone. This is one of the most common questions I get. I recommend looking for JavaScript meetups (Google "javascript meetups") in your area to find other developers who you can talk to. Keep looking until you find just at least one actual, living, breathing human being who has an interest in teaching (or just likes helping aspiring engineers). Buy that person food and/or coffee and ask for an hour of their time. 

If you live in the middle of nowhere and/or are not physically able to go to events like this, then it's going to be harder for you unless you're willing to commit to self-directed learning and don't give up easily. If you aren't getting anywhere after a few weeks and you've done the related section in Eloquent JavaScript and JavaScriptisSexy, then you could try hiring an online tutor through a service like eLance.

And if you can't hire anybody, my best advice is to get to know the Google Developer Tools console because it is every JS developer's BFF. Practice writing and calling simple callback functions, and track what happens at every step of the program using Dev Tools. I find that making callbacks explicit (i.e. actually seeing what value is getting passed to what function at what time) can really help demystify the concepts. And, bonus, Google Dev Tools is something you will use throughout your time at Hack Reactor (and as an engineer), so your time familiarizing yourself with it is going to pay off no matter what. 

One App, Three Ways: PhotoMVC with Backbone, Angular and React

There's a great resource called TodoMVC that takes the classic Todo app, and implements it using every MVC/MV* framework imaginable. This weekend, I embarked on my own version of TodoMVC with a photo app that displays a selected photo from a list, and lets you give that photo a rating.

Here's the finished product:

Angular version, with help from Bootstrap 

Angular version, with help from Bootstrap 

I built all three apps from scratch. My experience was all over the map. I had moments of great enlightenment, and I had stretches where everything felt like a godawful ordeal. If you're at all shaky on MVC/MV* frameworks, I strongly recommend doing this exercise with the frameworks of your choice. It really drives home the concepts of state management and rendering, and gives you a newfound appreciation (or, at times, outright dismay) for how different client side frameworks manage the age-old tasks of updating data and displaying views. 

Here's a quick breakdown of my impressions (repos linked): 

  • Backbone is the least magical experience of all
  • Angular is super magical and intuitive, but it can feel kind of hacky at times
  • React is the Backbone of the future, and -- coupled with Redux -- is the most exciting thing that I'm learning right now 

I'll post more about React/Redux and the One State Container to Rule Them All later this week, so watch this space if you're interested in such matters.  Until then, commence hacking! 

Prime Numbers and the Sieve of Eratosthenes

A friend of mine pointed me to Harvey Mudd's CS for All, and I fell madly in love with this section, in particular: The Sieve of Eratosthenes

In fact, I believe my exact words upon learning about this method of finding primes was, "WHERE HAS THIS BEEN ALL MY LIFE?!" 

Now I'm working on a function to implement it in JavaScript, and it's super fun. 

Highly recommend checking out the Harvey Mudd link -- it's an awesome CS resource.


Back to JavaScript Basics: VARIABLES!

We are officially in the "senior" portion of the program at Hack Reactor, and are moving towards more project-based work, and hiring/career skills prep. To help prepare for mock interviews, I'm reviewing some of my notes from earlier in the year. It's been nice to go back and get a refresher on the basics, this time coming with a much stronger sense of the subject material.

So, let's talk about variables. First, a definition:

Variable: A label that points to a value that is stored in memory. Once a variable is assigned, you can refer to it later in your code.

OK, that's nice, you might think. But what's the big? There are TWO big reasons why we care about this property of variables that I'll go over real quick.

Building efficient programs

var storedNum = (1+1)*2;
console.log(result); // 4
console.log(result); // 4
In this example, the variable storedNum is computed only once, and the computed result is logged twice. If you ran console.log((1+1)*2); each time you needed to access the stored number, the computer would have to compute the result each time. Maybe that's fine for this super simple example, but you can imagine how this would be meaningfully inefficient if you had a complex computation that required a non-trivial amount of memory. What else should you know about variables? You can use them to point to the values stored in other variables!
var storedNum = (1+1)*2;
console.log(storedNum); // 4
var other = storedNum; 
storedNum = 5;
console.log(other); // 4

If you're wondering why other still evaluates to 4, even after storedNum is set to 5, it might help to think of variables as physical labels, or nametags.

Let's say you have a "cookie" nametag on a box of Oreos, and then you stick a "milk" nametag on the same box. Now imagine you peel off the "cookie" nametag and put it on a box of Teddy Grahams. What happens to the "milk" nametag? It's still on the box of Oreos. Just because you moved the "cookie" nametag to the Teddy Grahams box, it doesn't mean that the "milk" nametag moves to the Teddy Grahams. The "milk" nametag stays on the Oreos until it's moved and affixed to something else.

Man. Now I really want Oreos.

Here's another way to think about variables pointing to other variables:

var storedNum = (1+1)*2;
console.log(storedNum); // 4
var other = storedNum + 0; 
storedNum = 5;
console.log(other); // 4

One helpful trick is to assign other a value of storedNum + 0. This the exact same thing as before, but makes it clearer that other is independent of the storedNum variable.

* But, seriously, why do we care? *

Accessing certain values

The second major reason that we care about variables is because sometimes it's not possible to type out a literal that represents a value in your program. For example, let's say you need a random number:

var randomNum = Math.random();

Since you don't know what the random number will be, you have to store the value in a variable if you want to access that random number value later.

Finding the Perfect Color Scheme

I love colourz!!

I've spent entirely too much time perusing color schemes while designing my apps, and you can too! 

Recommended Resources

Color Hunt

  • Updates daily with a new theme of 4 colors.
  • Dead simple to use. Color values are super easy to copy/paste into your CSS.
  • No login required to pin and save your favorite themes.
A few of my favorite swatches

A few of my favorite swatches

I'm partial to "Mustang"

I'm partial to "Mustang"

  • 5 colors per theme. 
  • Requires login to save favorite themes, and/or to create your own custom themes.
  • More advanced functionality than Color Hunt, but the interface can be confusing.
  • Pro Tip: Click "edit copy" to get the RGB and HEX values all in one view.
  • Super Pro Tip: Definitely read the comments under your favorite swatches. Listening to people talk about colors is... weirdly uplifting.

Favorite Schemes

Quiet Cry

Screen Shot 2015-08-20 at 10.16.06 AM.png

I think what I love best about this theme is the name. I can imagine the colorist weeping softly while adjusting RGB values to achieve the precise mixture of coolness and melancholy that captures a quiet cry in the bath. 

Also, the user comments for this theme are touchingly intimate.

I've been using this theme on my personal resume site. It has a nice combination of weight and cheerfulness to it. Color Hunt doesn't give names to their themes, so I made one up!


How to Use ESLint (and JSHint) with Sublime Text

I used to be a copy editor and pride myself on catching syntax errors, so the fact that I've named the superhero version of myself the "Human Linter" is not at all sad. In spite of my linting prowess, if it's late, or if I'm staring at 5 nested callbacks, using an actual linter can be a godsend. 

What is a linter, you ask? A linter is like a spell-check/grammar-check tool for code. Linters are very useful for catching syntax errors in static code that could break your program.

JSHint vs. ESLint

For the last few months, I've been using JSHint with Sublime Text.  This is a pretty good system and catches most major errors right out of the box. JSHint is a fairly relaxed linter by default. For example, it doesn't catch anything here:

Can you spot the flaws in this code? 

Can you spot the flaws in this code? 

You can configure JSHint to be stricter, but if you need advanced customizations, you might be better off starting with ESLint. It takes a few more steps to install using command line and Sublime's Package Manager, but it has a ton of rules that are easy to configure exactly how you want. You can even make your own rules. 

The default settings will extend ESLint's recommended rules, which are fairly strict. Here is the same file linted with ESLint, using its default settings:

Two errors caught in ESLint that we didn't see with JSHint.

Two errors caught in ESLint that we didn't see with JSHint.

I configured a few ESLint rules to match my workflow and style preferences. Specifically, I relaxed the no-console rule to be a warning (in yellow) vs. an error. I also enabled the no-comment rule to detect "TODO" statements and mark them as warnings. Finally, I added a style warning to enforce spaces after keywords ("if," "else," "for", etc) and before blocks. 

This is the test file again, with my customizations added to the ESLint defaults:

My linted heart is happy.

My linted heart is happy.

Here is my .eslintrc configuration file. As you can see, it's simple to override and specify rules:

Rules rules rules... 

Rules rules rules... 

I changed the default indent to use spaces instead of tabs, with a width of 2 spaces per indent. You can find more info on indent rules here

To install and set-up ESLint, follow the instructions in the documentation, here

After you run eslint --init, answer a few questions and your .eslintrc file will be created for you. Then just open that file and modify it to your heart's content!

Using both ESLint and JSHint

If ESLint is too heavyweight for what you need right now, but you can imagine using it in production, you can toggle between linters easily in Sublime, with the keyboard shortcut CTRL + CMD + T (in Mac). That way, you can use whichever linter makes the most sense for your project at the time. 

Toggle between linters for maximum flexibility (or if you're just indecisive).

Toggle between linters for maximum flexibility (or if you're just indecisive).

Happy linting!

How to Give GREAT Presentations

I have witnessed (and delivered) some crappy presentations. You all know what I mean. I don't understand why we continue to present with Powerpoint slides that are crammed full of text and read out loud. 

If you're interested in improving your presentation skills, I highly recommend this video. Scroll ahead to 1:57 if you want to skip the intro and dive right in. 

Side note: I am of the belief that presentations should be as BRIEF AS POSSIBLE. If you're showing off a product to your company or team, it shouldn't take you more than 5 minutes to demo it and be done.

My general rule of thumb is, no one should be talking for more than 10 minutes straight. Getting from the red square to the green square should be a sprint, not a marathon. Sprints are focused, motivated and quickly rewarding. Marathons are laborious, chafing, and people start dropping from exhaustion.

My first full-stack app: Forget Me Not

Last week at Hack Reactor, we each had to build an MVP (Minimum Viable Product), from scratch, and have it ready to present the next day. Up until this point, we had been working on structured projects in pairs, so this was the first time that we were all on our own. 

The Idea

I approached this project with a mix of trepidation and morbid curiosity of just what, exactly, I could hack together in 2 days. I thought of an app idea while at the gym, came back and sketched out the user flow and features on a piece of paper, and then just went from there.

My app is a simple memory helper for teachers who have trouble remembering their students' names. You can read about it in this mock press release.

The Process

I (once again) was grateful that I'd taken Javascript Design Patterns, which taught me how to approach building the app structure from the very beginning. After I had my sketches done, I set up my file structure and read up on MEAN stacks, which I decided would be a good fit for this project and just cool to try out. 

MEAN stands for Mongo, Express, Angular and Node, which together comprise an end-to-end Javascript tech stack. 

After 12 hours of solid hacking, I had the views running, and one of my two features working. The app would accept a user's guess, and return the appropriate response. I also set up my server routes, and tested my POST, GET and PUT requests to ensure they all did what they should. Huzzah!  

On day 2, I tackled the task of saving and storing a user's hint. I also hooked up the app to Mongo. Up until this point, I'd been using hard-coded data. I wasn't able to refactor the app by mid-day, so decided that I would just use the hard-coded data for my presentation. I talked with a Hacker in Residence (analogous to a TA), and they said that would be perfectly acceptable, given the "minimum viable" nature of the project. 

The App

Here's how it turned out! You can check out the repo here, with the understanding that the code works, but is far from final. 

Home screen. Styling courtesy of the ubiquitous Twitter Bootstrap 

Home screen. Styling courtesy of the ubiquitous Twitter Bootstrap 

Student photo shown with a simple prompt

Student photo shown with a simple prompt

If the guess is incorrect, the user can write and save a hint about that student to connect their name with their face.

If the guess is incorrect, the user can write and save a hint about that student to connect their name with their face.

If the user gets the name right, a "correct" response is shown, and they are encouraged to keep playing.

If the user gets the name right, a "correct" response is shown, and they are encouraged to keep playing.

Lessons Learned

First, and most important, I learned that I'm capable of hacking something together in a constrained period of time that isn't a total disaster. And that I can learn the technologies I'm going to apply while I'm trying to apply them. That was pretty cool. The project also reinforced the value of just getting your hands dirty and building stuff as the best way to understand the technology you're using. 

More technically, I learned that how you manage your data is very, very important! Next time, I would spend a little more time on deciding how best to handle the data for my app, and plan that out first. I think it would have made all the other decisions I had to make more self-evident. 

I also saw firsthand the value of time-boxing, and being able to manage yourself competently. I have a lot of practice managing myself and others while building user-facing products, and that experience served me well for this sprint. Staying focused on the user persona I had created (a teacher who has trouble remembering students' names) was essential to keeping the project scope manageable, and ultimately ensured that I'd have a product with a clear story to deliver.



Day 41 of Hack Reactor: Hiring Assessment and Solo Week

The last 6 weeks have flown by like... um... a fly. Or a bee! Or other such creature that flies by really fast. 

As of tomorrow, we are in Solo Week, which is the week in between the "Junior" and "Senior" parts of the program. This is very exciting because it means we're working on our group projects from here on out, and it feels very rewarding to be able to build real full stack apps from scratch.

Hack Reactor has a big exam called the Hiring Day Assessment that we took yesterday. It's a comprehensive set of tasks that you have to complete in order to show mastery of the subject material from weeks 1-6. If you don't pass, then you don't get to participate in Hiring Day at the end of the program, and you also don't get to call yourself a "graduate" of Hack Reactor (and therefore don't have alumni status afterwards). So yeah. It was kind of stressful.

For me, the test was useful because it helped reveal where I feel comfortable vs. where I need to improve. Some of the tasks felt very natural -- almost automatic -- to me, which was unfathomable 6 weeks ago. I guess programming for 12-16 hours a day for 41 days straight will do that to you.

Other tasks felt like a slog, though I never felt hopeless at any point (this is a profound attitudinal change from where I was even a month ago). I didn't have time to get everything working, but I was able to form a plan and describe my logic, so later on I can revisit those tasks and find solutions.

I'm not sure if I passed or not (we find out next week). If I don't pass, it won't be because I didn't work hard enough over the last 6 weeks, which to me constitutes a success no matter what happens. It also won't be because any task was "too hard" for me, just that I couldn't complete a working solution in the time allotted. There's a huge difference between those two states. 

Anyway, I'm just excited to focus on learning more and building cool things in the next 7 weeks! 

Day 28 of Hack Reactor: Backing the Back-End

Somehow, 4 weeks have sailed by since my cohort started, and I can't even begin to process the amount of learning that's happened during that time.

Last week, we focused on back-end architecture and server-side techniques, specifically building a custom back-end in Node, implementing an ORM, understanding promises, and building databases. Next week, we move on to authentication and Angular.

I've enjoyed this back-end stuff more than I expected. I think partly because there are so many intellectual challenges associated with designing and configuring a back-end, and fewer of the semantic challenges that tend to accompany front-end work.

Interested in learning more? Here are some resources I've found helpful (free, unless noted):

Stuff I'm Bad At: The Art of Abstraction

"Learning is any change in a system that produces a more or less permanent change in its capacity for adapting to its environment."

-- Herbert Simon 


Usually, I write about things that I'm comfortable with, and maybe even reasonably good at doing. Because a blog called "Stuff I'm Bad At" would be full of parallel parking, deciding how much food to order, and writing thank you notes on time. Who wants to read that? 

But today, I'm going to talk about an immense learning challenge I have, and it's going to be way more interesting than anything else I could write about. My problem lies in the task of abstraction. Specifically, I have trouble abstracting away from the internals of the "black box" of what a program is doing without mixing it in with the interface (what the user or, in our case, programmer, sees). This applies both to understanding and writing code, and it is the biggest hurdle I face on my path towards becoming a software engineer.

"Wonderful, but not incomprehensible."


What I love about programming is that it can explain and generate wonder, all at the same time. As Herbert Simon writes in The Sciences of the Artificial:

For when we have explained the wonderful, unmasked the hidden pattern, a new wonder arises at how complexity was woven out of simplicity.

The idea of unmasking simplicity is very much connected with the concept of abstraction, which I refer to in the context of programming as the practice of concealing unnecessary or irrelevant details of a program, and surfacing only its essential features. A programmer who is able to abstract her way around a seemingly complex system and grab ahold of only the relevant details of that system to apply to her particular task has potentially endless power. For me, learning how to do this is akin to discovering a new natural law. 

Programmers rely on abstraction to build clean and intuitive interfaces that allow others to interact with their programs. An interface, broadly speaking, is the meeting point between an inner and outer environment.

For example, imagine you have a mug (hopefully you don't have to imagine too hard because mugs are pretty awesome). Your mug is made of a solid material, has a capacity of 16 fluid ounces, and has a handle -- these qualities serve as affordances that guide you to the mug's proper use: to hold liquid and physically maneuver that liquid with one hand. The mug is your interface to drinking coffee, tea or other beverage. In order to understand the mug's intended task, you don't need to know how the mug was constructed, or whether it's ceramic or porcelain or glass. You just need to know that it's a mug. 

Applying this model to a code example, consider Underscore's function signature for the array method _.indexOf:

_.indexOf(array, value, [isSorted]) Returns the index at which value can be found in the array, or -1 if value is not present in the array.

  _.indexOf([1, 2, 3], 2);
  => 1

Just like how anyone can pick up a mug and know what it's for, a programmer should be able to read the _.indexOf function signature (the interface) and quickly grasp the essential features of the function it represents, without needing to "go to the mug factory" by diving into the code that comprises the function line by line.

And just like how a mug is designed to present its most obvious use to the external world (the outer environment), so too must a programmer take care to design an interface with clarity and precision; by naming functions and inputs appropriately, for example. This helps account for weirdos like you and me who otherwise might try to use their program in some way it was never designed for.

So, what happens when we breach the mug factory and go "under the hood" of _.indexOf?

From the Underscore documentation:

_.indexOf = createIndexFinder(1, _.findIndex, _.sortedIndex);

That doesn't look so bad, right? As it turns out, _.indexOf is simply an invocation of a generator function, createIndexFinder, which takes in 3 parameters. Let's find that helper function...

function createIndexFinder(dir, predicateFind, sortedIndex) {
  return function(array, item, idx) {
    var i = 0, length = getLength(array);
    if (typeof idx == 'number') {
      if (dir > 0) {
          i = idx >= 0 ? idx : Math.max(idx + length, i);
      } else {
          length = idx >= 0 ? Math.min(idx + 1, length) : idx + length + 1;
    } else if (sortedIndex && idx && length) {
      idx = sortedIndex(array, item);
      return array[idx] === item ? idx : -1;
    if (item !== item) {
      idx = predicateFind(, i, length), _.isNaN);
      return idx >= 0 ? idx + i : -1;
    for (idx = dir > 0 ? i : length - 1; idx >= 0 && idx < length; idx += dir) {
      if (array[idx] === item) return idx;
    return -1;

Welcome to the mug factory! At this point, you've likely forgotten why you're even here. I have, and I'm writing this thing.

My challenge is to avoid taking unnecessary tours of mug factories, while also building my own super awesome mug factories. I'm making good progress on the first part of the task: it takes some discipline, but I've definitely become more sensitive to internal and external flags telling me when I don't need to know the internals of some piece of code, and it's OK to move on. 

What's much, much harder for me is building the mugs and the mug factories, or programming both the interface and the "black box" code that you shouldn't worry about.

It's a super weird sensation to know that you're writing code that a future version of yourself will deliberately ignore, and at the same time having to remain cognizant of how Future You and other programmers will interact with the interface to that code. Coding becomes something of an out-of-body experience.

For me, the real problem is that I've never been particularly good at thinking in abstract terms. My mind jumps into details and keeps digging until every possible nugget is unearthed. This impacts how I reason about a program because I can easily lose sight of what the hell it is I'm supposed to be returning.  

In other news, I've learned that I have far less mathematical intuition than I previously assumed. Apparently being able to do basic math in your head really fast doesn't actually make you a mathematical thinker.

"The best thing that can happen to a human being is to find a problem, fall in love with that problem, and live trying to solve that problem, unless another problem even more lovable appears."

-- Karl Popper 


I am in love with my problem. I'm positively obsessed with it. Who could wish for a better, more lovable problem? We all should be so lucky to be made aware of any deficiencies impeding us from doing our best work. Otherwise, we would never know to improve!

After sharing my situation with a number of people who I respect and admire, I've put together a few strategies to help address this challenge:  

  1. Draw pictures. I've found that mapping out a problem on paper helps me tremendously, which makes sense since the very act of drawing something to represent something else is a method of abstraction. 
  2. Write your test suite first. As the maybe 3 readers of this blog know, I'm a big fan of test suites. By keeping your eye on the prize, you're less likely to go astray. At the very least, always know what a function or a program is expected to return to the person who calls it. Write it down in a comment at the top of your code if you need to.  
  3. Stay vigilant. I spend a good portion of my day wrestling with myself to stop thinking so much like myself, and imagining what it's like to think in this totally different way. It's a little exhausting. Eventually, it will become less so (I hope). 
  4. Find examples. When I witness a classmate making a cognitive leap, I'll ask how they got from Point A to Point B. I find it super interesting to hear how others visualize and reason about problems, and I hope that I'll eventually get to a similar level of intuitive cognition. 
  5. Have empathy. This particular strategy is fairly easy for me to enforce. It feels very natural for me to imagine how someone else would feel in one situation or another, and this will help me build better interfaces that account for a variety of potential users. 

If you have other strategies to share, please do so in the comments! 



Learning HTML/CSS with Dash

If you recall, I've harbored a general dislike for HTML/CSS for a while now, but I think I'm coming around to something like... lukewarm acceptance. Yeah! Let's go with that. 

I finally checked out General Assembly's Dash, and it is really, really well done. It's project oriented and has a slick interface. Like many beginner courses, it can be a little too "hand-holdy" at times, but it's still a very worthwhile use of an hour or two if your HTML/CSS is rusty. Besides, it's HTML/CSS. You might like it just fine, but you're probably not going to spend hours and hours trying to look into its soul. That's what JavaScript is for!