July 21

Noel Rappin
Table XI
Published in
6 min readJul 24, 2017

Five Things Give Or Take Two

JS

I’ve been working in JavaScript on and off basically since JavaScript was invented, I even kind of wrote a book on it, and I still find the current ecosystem kind of bewildering.

Ben McCormick wrote a nice essay about Ten Things A Serious JavaScript Developer Should Learn, which is based on a Reddit thread that is maybe a little too much noise-to-signal (shocking, I know). It’s a good list, and I like that it errs on the generic and not confrontational side. With a little adaptation, it’s really a reasonable list for a generic web developer.

Meantime JS marches on and we now have an ES8, here’s a look at what’s new from Dor Moshe. There’s nothing too big here, it seems to my eyes that the async function declaration is probably the biggest new thing.

Style

Two completely different articles on coding style and practice that crossed my path this week:

Here’s Sandi Metz writing about why we argue about style, basically concluding that having an enforced style guide for a team is a good thing and that you, me, whoever shouldn’t get to buck the team consensus on style. I’ve gotten a lot mellower about this in the last couple of years (having tools that automatically format actually helps a lot), and I had a similar experience to Sandi’s with the Elm formatter.

On a different style note, Scott Hanselman wrote a nice essay on coding fonts that use ligatures. A ligature is a combination character that a font uses when two characters are next to each other. Many decorative fonts use them to adjust spacing between two characters that might otherwise be spaced awkwardly. And a few coding fonts, like Fira Code use ligatures to express multiple character coding symbols like != as the combined symbol. As I may have mentioned, I currently have about 10 or so coding fonts that I like and randomly switch around on a weekly basis (because I am crazy), the three listed in this article definitely included. I find the ligatures really do make it easier for me to read code that uses them, often using a more common symbol in place of a code specific one makes it easier for my brain to get it. Most code editors can be tweaked to support ligatures, it’s worth trying.

Behind The Scenes

A couple of interesting and different behind the scenes stories:

From Karen Wickre at Backchannel/Wired is an article about what happens inside a company facing a PR disaster. I liked this piece, but it’s more a “here are good things you should do”, then “here are some war stories of what actually got done”.

Somehow I missed this from May, but The Outline has a great oral history of the spelling bee moving to ESPN. I have mixed feelings about the bee, but nothing but admiration for the kids who compete. This is a story about how the bee navigated ESPN’s televised needs and still made it work for the competitors.

Smart Stuff

Checkers. It’s like chess, but not. It’s also been conclusively solved by computers (it’s a draw if played perfectly). Here’s Alexis Madrigal with the story of two people obsessed with checkers. One of them was obsessed with becoming the best Checkers player possible, the other became obsessed with building the best Checkers AI possible. If any of that seems at all interesting, this is a great article.

More Boot Camps

What with Dev Bootcamp closing, there’s been a lot of discussion about teaching coding. Larry Cuban, who is an education professor with expertise in school reform, wrote a series of blog posts about teaching coding to all students in middle and high school: Coding, The New Vocationalism. It’s a dense article, but Cuban is generally skeptical of attempts to use public schools for vocational training, and sees coding as the latest round of the attempt. (The article starts by pairing a 2017 quote from Tim Cook, with an 1898 quote from the head of the National Association of Manufacturers). It’s good to get some historical and cultural perspective on our education debates.

Extrapolating

Finally, Amazon. Their stock keeps going up, they keep not being very profitable, their investors assume that they will eventually flip a switch and start generating profit. Brian Dew and Dean Baker at The Center For Economic and Policy Research do a little math and determine what would have to happen for Amazon’s stock price to be justified. (Hint, it could involve them being about 10% of US GDP.).

On The Podcast

The most recent podcast is Doc Norton and Table XI’s Claire Podulka talking about Doc’s book Escape Velocity (and to a lesser extent my book (Trust-Driven Development).

A few more quotes:

DOC: If you look at Velocity, it is a trailing indicator. It is a single measure of literally hundreds, if not thousands of interactions when you look at the whole system. From the moment that someone said, “Would it be nice if…” to the moment that somebody else said, “Isn’t that nice?” Analogously, body weight is a single measure of a complex system and it is a measure that is taken after the fact. From any one individual’s body weight, you cannot say with certainty that they are or are not healthy. Just like from any given Velocity, you cannot say that a team is or is not healthy.

DOC: we’ve seen fairly consistently that team joy is actually a bit of a leading indicator compared to the rest of the metrics. What I mean by that is you oftentimes see the temperature or joy measure dip an iteration or two before you start to see other measures move in a non-favorable direction.

DOC: Like in your commute home. On that commute, let’s say on average, it’s 20 minutes. It’s possible on some days for it to be 17 minutes. On a really good day, it might be 15 but it’s never going to be two. You can never get home from work in two minutes if your normal is 20. However, it is possible for the commute home to take three hours so we end up with this curve that’s shifted and we can actually figure out confidence intervals using this curve.

DOC: My analogy there is Sudoku games. If you open a book of Sudoku games, it’s usually broken down into easy, medium and difficult. If you know that your average for an easy puzzle is eight minutes, a medium puzzle is 12 minutes and a difficult puzzle is 16 and you pick up an easy puzzle and you complete it in 20 minutes, does that now mean that it was a difficult puzzle in terms of complexity? No. It was an easy puzzle. It just happened that you missed some inference so it took you longer to solve it.

One More Thing…

Next week we have Nadia Eghbal on the podcast talking big picture about Open Source, and I wanted to set the stage for it by elaborating on a Twitter conversation I had this week about what happened to “free-as-in-speech” software.

Before GitHub, like, 15–20 years ago, there were two competing visions for free software distribution. On one hand you had “free-as-in-speech”, which suggested that free software was a right. This often meant a GPL license, which is “viral”. If you used a GPL library in your code, you had to make the source for your entire codebase public.

The other way was often described as “free-as-in-beer”, and meant that releasing source was a business decision, if you used a license from this point of view (the BSD or MIT licenses, mostly), you did not obligate your users to do anything. The irony that the “freedom” license was the one that restricted future behavior was not really lost on anybody except possibly the free software advocates themselves.

Anyway, in the 2000–2005 range this was a big deal. Whether a project was GPL or BSD was important information that often determined whether your company could use the tool. Projects broke up over this kind of argument.

And now it’s been years since a project I care about has had a protracted argument over licenses. The reach of GPL tools, at least in my little world, has dropped precipitously. Nadia explains some of what happened here, and we’ll talk about it on the podcast next week. I have some follow up thoughts on why this all happened, but they’ll make more sense after you all listen to Nadia. (A newsletter can have a cliffhanger, right? I prefer to think of it as pre-deciding what I’m going to write about next week…)

See you next week,

Noel

--

--

Noel Rappin
Noel Rappin

Written by Noel Rappin

Noel Rappin is a Senior Staff Engineer at Chime. He is the co-author of "Programming Ruby 3.2", the "Pickaxe Book". Find him at noelrappin.com