I’m John K. Paul
an engineering manager
and a speaker

found on

contact at


about me

Often an engineering manager, with many more interests than that

Subscribe to the Monthly Newsletter

powered by TinyLetter

Don’t Wait; Keep It Up to Date

- - | Comments

Let’s start brushing our teeth as programmers.

We need to consistently prioritize updating our frameworks/libraries/dependencies. Having unit tests makes this much easier, but even if you don’t have them, it’s still necessary.

Don’t think about this like flossing

Brushing your teeth is something that you do extremely regularly and have built up such a habit that you can’t really imagine life without it. Flossing is a nice to have that many of us skip with impunity. It doesn’t necessarily have to be once a day, but thinking about updating on a regular, predefined basis will force you to need to consciously make the choice to disregard instead of absentmindedly forgetting.

On teams, you should make sure that there’s a recurring task/calendar event every month to ensure that you’re codebases are up to date. This is most important with frameworks/impactful libraries like Ember/Angular/React, but it is just as helpful for anything inside of the world of Node/Ruby/Python/Java/anything-with-dependencies.

Once you make this as much of a habit as brushing your teeth, you won’t even need to think about it because it becomes every team member’s shared expectation. Use reverse-broken-window syndrome to your advantage. If everyone is doing it, each person will keep up with the crowd.

The automated, electric toothbrushes

I still use the plain old toothbrushes that I get for free every six months from my dentist, but I know that many are bigger fans of the electric/sonic variety. Gratefully, they exist for programmers trying to keep depencenies up to date too!

  1. Greenkeeper

This is a great tool by the makers of Hoodie that will automagically open PRs against your npm project when a dependency releases a new version.

  1. Sibbell

This tool will send you emails whenever a dependency creates a new GitHub “Release”

  1. VersionEye

For open source Node projects, VersionEye will show you which entries in your package.json are out of date

Start Now

There’s nothing stopping you from starting this practice right now. You are resourceful. You could make a slackbot for this, setup a shared calendar, or any other myriad solutions. All I can tell you is that once you do, your team will be better off.

Here’s to gingivitis free software!

Tonic, a JS Bin With Npm Attached at the Hip

- - | Comments

Tonic is a new service/tool for web developers that I’ve been playing with for a couple of days. It’s very similar to an IPython notebook, but completely through a web interface. It’s very interactive, and allows you to fluently write, test, and play around with Node.js code. You can test things out very quickly, just like JSFiddle, JSBin, CodePen or Plunker, but it is backed by npm which makes it much nicer.

This is their marketing copy. They say that Tonic removes friction. I was very surprised by how true that was.

NPM is first class

Any require statement is automatically parsed, and the dependency is added to the implcit package.json file that backs every “Notebook”. You don’t have to fiddle around with the JSON yourself, but rather just add var request = require('request'); and you automagically have the current version of request. There’s also some special additional syntax to use in your requrie statement if you do happen to require specific versions.

Endpoints are first class

The killer feature of this tool though is not the npm integration, but rather its ability to create on the fly APIs. I’ve been looking for something like this from a lot of other tools. I have wished there was a way to create a one liner API and deploy to Heroku as an endpoint by only using the web. Until now, I haven’t had anything like that. Now, not only do I get an API in 2 clicks and 3 lines of code, but it also supports CORS!

Creating a new http endpoint is as easy as clicking on compose in gmail. Clicking on new Notebook, and then writing this code, got me a passthrough to a non CORS, but open endpoint in < 5 minutes.

No more needing to spin up node on my VPS just to CORS enable APIs!

This is basically a two liner (of not boilerplate) to get my own Duolingo profile. In case you don’t know, I’m extremely addicted to Duolingo and many of my side projects are tools to remind me to practice learning languages every day. Tonic is going to make that tool writing so much easier! I don’t need node proxies anymore, I can just build my apps in JS Bin, calling to this new Tonic-built endpoint and be done in minutes!

I’m really excited about this; I’m sure you can tell. See you in the comments!

The Blog Post to Understanding Ratio

- - | Comments

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!