As a programmer, you might be familiar with acronyms such as MTTR (Mean Time To Repair) or MTTF (Mean Time To Failure). Today I’m introducing a new metric called the Blog Post to Understanding Ratio or the BPUR. This new metric is pronounced as “beeper” (ˈbipər for the IPA fans) - you might remember these from folklore of the 90s.

The idea behind the BPUR is that some programming language concepts take many readings of many blog posts and other resources in order to fully comprehend. On the other hand, there are many topics that are much more readily digested. A high BPUR means that I need to consult with many resources in order to grok something, whereas a low BPUR is something that we can pick up without significant intentional thought. It helps me frame how complicated the topic is and how fast I can expect myself to understand a new topic.

For example, if someone was to start learning JavaScript from scratch, at some point they’d definitely need to understand the idea of assigning to a variable. Most developers are familiar with the typical C family of programming languages. The ideas are fairly straightforward; assignment statements have equal signs in them and I already understand the semantics of a variable assignment. I would set the BPUR for how to assign a variable in JavaScript very very low.

However, being able to understand something like prototypal inheritance and that there are actually two distinct, albeit similar, uses of the word “prototype” takes much more time. Prototypal inheritance has taken me dozens of blog posts to really understand. Many years ago, I had to Google, find some blog posts. Read them. Feel like I really didn’t understand after reading them. Then go back, read more. Then wait a couple of days. Let the whole concept sink in a little bit. Still not understand. Rubberduck a little bit with myself by thinking about it out loud. Then go to Google again, read some more blog posts. Then finally, that knowledge coalesced and then I understood prototypal inheritance. This is a topic that I would say has a very high BPUR.

That high BPUR means that I can’t expect to immediately go in and understand this. For me, thinking in this metric allows me to reset my expectations around speed of learning. I don’t want to be demoralized or frustrated by thinking that I should understand this in 30 seconds. Some topics are more complicated than that and it would be okay if it takes me a week, or even a couple weeks to fully understand and to fully grok. That’s okay. It has a high BPUR.

As I’m spending more and more time learning programming languages for fun, this is a very helpful way for me to think. It keeps my morale up and it allows me to keep persisting to learn new things. The only thing that’s missing is an understanding of what the BPUR is for all concepts in all programming languages.

This is something that I am currently thinking about how to fix. I’d love a chart like this for every programming language and every topic within it:

I’d love to hear all of your ideas and thoughts about this metric. I don’t think that 10 is necessarily the correct high BPUR, but that’s going to be something that I continue thinking about. I am going to be working in future posts on how to document and distribute information like this. Maybe we can crowdsource a shared library of BPURs for every concept in every programming language.

Comments are below and there’s always twitter for 140-character discussion!

We live in a life filled with the exciting world of buzzwords. There are tons of them around us on any given day as a JavaScript developer. In software engineering as a whole, there are even more. There’s big data, web components, transpiling, build systems and so much more.

While even I have the tendency to roll my eyes at some of these things, I want to also mention that buzzwords typically do have some actual reason to exist. All of the items that I listed earlier are actually very valuable and interesting technologies, even if talking about them might make some of us want to throw up in our mouths, just a little bit. I try to make sure that I discount some of the zeitgeist, but also consider how I can apply these buzzwords practically.

Now, let’s shift gears into the two buzzwords that are still on the tips of everyone’s tongue.

The Virtual DOM and functional programming!

The Virtual DOM

The Virtual DOM, as a concept, is extremely popular across many JavaScript development tools and mythologies. It is a very valuable tool that is inspring performance optimizations in many frameworks and libraries. At its core, the Virtual DOM is a performant, in-memory tree diffing algorithm.

Take for example, these two trees.

From the left tree to the right tree, there is one single difference. As a human, this is a bit difficult to spot, but as a machine, especially using the Virtual DOM algortihm, it’s really fast. The Virtual DOM can figure out, very quickly, that one leaf node has switched to a different parent.

Functional Programming

I’m not going to try to explain, nor pretend to understant the rigors of category theory or mathematics in the post. What I’d like to do, instead, is take you back to when functions were first introduced to you. Back in Algebra 1, you didn’t think of functions as composable, discrete units of referential transparency and purity. You just thought of it as f(x).

Do you remember seeing something like this?

How straightforward is that! Given one input value, a function produces one and only one output value. This is the crux of the functional programming buzzword and philosophy that I’d like you to keep in your head throughout this post.

React’s big win

Compared to the other popular frameworks, it’s not the Virtual DOM that sets React apart. What really makes React special is the fact that you can use it to think about your application as simply as a function.

Using React, your DOM is a function of all of your state. If there were a single high-school-reminiscient formula for what React does, it would be this…

This is very special in the single page web application landscape. Typically, using Backbone listeners, or Ember observers or Angular watchers, we end up with something a little more complicated…

Focus on the word “try” in there. That’s the key. React doesn’t try to keep data and view in sync. The view is always a function of the data, so there is no extra work needed to keep everything in sync.

Unidirectional Data Flow

In React, you never need to directly create any DOM. React creates DOM for you and updates the DOM for you. All you have to do, as a developer, is specify what the DOM should look like for any given state of your application. This allows you the freedom to only need to think of any one view as a whole instead of having to think through everything that needs to change when your data changes.

This concept is called “Unidirectional Data Flow” in React. Your data changes in only one place, and whenever that data is changed, the view is updated accordingly.

Want to learn more?

I gave a talk form of this post, in much more detail at React Rally and NationJS last year. Click play below if you’d like to learn more.

I’ve spent the past month away from social media. A hell of a lot has happened and I’ve enjoyed every minute of it. I’m coming back to it though, and this time, including blog posts.

In that time, I’ve gotten married. I did happen to tweet one picture of it. It was one of the few pictures (grainy, and from a cell phone) that we had for a while.

I loved @jennshiffer’s response to it

@johnkpaul @kosamari @rhodesjason @janecakemaster @jsconf @SkylarPanuska Poland Spring: what it means to be from Jkp and skylar's wedding™

— jennmoneydollars (@jennschiffer) December 6, 2015

And am grateful for all of the many wholehearted congratulations and well-wishes we received that day, and many times since.

The reason we ended up with the Poland Spring was that most of the night, we were like this picture below. 🎉 🍸🍷 🍸🍷 🎉 Also, wow, professional photographers are awesome.

I was and am still pretty damn happy about the wedding. We have another month to get the rest of the pictures, and in the meantime there’s a whole slideshow of amazing pictures in case you’d like to take a look.

The trip to Neverland

Since all of the hubbub around the wedding has happened and the planning that took many many months, I’ve been slowly slipping away from Twitter, my social media drug of choice. I still read it every day, but I was engaging with it less and less. Except for when I was at conferences, a few of which coincided with this exciting time in my personal life, I didn’t pay that much attention. 

My honeymoon was at a cabin-hotel in the Poconos where you’re not supposed to use the internet in public. The cell service isn’t even that great in the middle of nowhere. My time away from social media was awesome. It was filled with long conversations with human beings, a favorite pastime of mine for a long time anyway. Typically, this was with my new wife, but there were also more conversations with other friends and most notably, family. 

I didn’t really expect to find how much a wedding can bring family together. I am still consistently surprised (kind of an oxymoron, right?) at how much my family has been communicating more frequently and about more varied subjects since then. What before used to just be “So you’re still alive and have a job right?” is now more like “How was your day?” 

Apparently all of this time away from social media opened up a whole new world of closeness and warmth between me and my family, but eventually we all have to get back to the real world. The real world with jobs, obligations, regular outings/dinners/karaokes with my own social circle, planning my own meetup and all sorts of other non-wedding related things. Since New Years Day, the last day that I saw anyone in my family but my wife, I have been trying to come up with ways to continue this closeness without losing sleep or sanity.  

The unexpected path back from Neverland

This transition to family and friends coalensence has been really fun for me and I’m finding that keeping it up requires something quite unusual for me.

I have had a Facebook account for over a decade, but I have logged into it a total of maybe 10 times since 2006. That’s approximately one time per year. It’s pretty much only when it’s my birthday, as it is today, that I log in to see all of the warm wishes and regret/be guilty that I’m not individually responding to every happy birthday message.

My family, on the other hand, has been using Facebook EXTREMELY regularly for that entire decade. Every week, they post over 10 times what I have posted in the entire time that I’ve been on Facebook. My job, according to Facebook, is my first job out of college and I’ve never updated it. 

Apparently, to keep in touch normally, I have to learn how the youths communicate nowadays and use Facebook. I know that the real youths are on snapchat and vine now, but please give me some credit. I’m not old and crotchety yet, but since Facebook was starting while I was in college, I can’t imagine a world where only the old people are using Facebook.

I never thought I’d get here, let alone, at my age. I am going to start trying to use Facebook like a normal person. Well, somewhat like a normal person. I don’t want to waste hours mindlessly scrolling (not that that’s what you do, that’s just what I would do). I do want to consistently communicate and update my family and friends. Consistently. Not Frequently. I don’t want to be letting you know about every cupcake that I ogle and don’t buy or every disruptive startup idea that pops into my head. I do want to make sure that the people that I care about and the people that care about me know what I’m up to, and vice versa. 

Maybe this means there’ll be some pruning or organization. Maybe this means that I’m going to declare friend bankruptcy. I might even respond to a poke or two from a decade ago. I don’t really know. I’ll figure it out sometime in 2016, I’m sure.

If you have any advice for someone joining Facebook this late in the game, please let me know. Honestly, I’d love to hear your thoughts.   I feel like I’m the only person that’s ever gone this direction.