I spent most of my free time this week working on my island in Animal Crossing and the rescue project; but this week’s articles include an article from FB Engineering about rebuilding their main site, an article about distractions, and a host of shorter articles.
Rebuilding our tech stack for the new Facebook.com
This is a Facebook Engineering blog post talking about a rearchitecting of the Facebook.com desktop site. Their two technical mantras were:
As little as possible, as early as possible. We should deliver only the resources we need, and we should strive to have them arrive right before we need them.
Engineering experience in service of user experience. The end goal of our development is all about the people using our website. As we think about the UX challenges on our site, we can adapt the experience to guide engineers to do the right thing by default.
One major change was in generating atomic CSS at build time. This helped to control a slow ballooning of their CSS; by the time of writing, they were serving over 400 KB compressed / 2 MB uncompressed of CSS.
Another was incremental code downloading—they split the website loading into three “tiers” to help performance. The first is the basic layout: where things are and UI skeletons. Tier 2 is all the code to render what appears on the screen; after this, nothing should be visually changing as a result of code loading. Tier 3 is behind-the-scenes work like logging and subscriptions for live data.
Other interesting architectural choices include:
- dynamically loading components or pieces of code when users are part of an A/B test, instead of loading both and not using one
- setting JavaScript budgets to stop code from ballooning in the future
- using GraphQL to get data as early as possible, and streaming data for e.g., News Feed posts but deferring data that’s not needed immediately
I found the decision to do a complete rewrite interesting:
A complete rewrite is extremely rare, but in this case, since so much has changed on the web over the course of the past decade, we knew it was the only way we’d be able to achieve our goals for performance and sustainable future growth.
Conventional wisdom says to never rewrite your whole codebase—but Facebook is large enough (and has enough engineers) that they can rewrite both conventional wisdom and, apparently, their entire website.
Stop trying to make hard work easy
This is a an interview with a behavioral design expert, Nir Eyal.
The problem is, when we expect work to be effortless and it ends up being difficult, we often blame ourselves. So the very tools we’re using to make work easier, can instead make it easier for us to give up.
The barrier to getting work done, Eyal uncontroversially says, is distraction. This I’ve heard before, but what I haven’t is that Eyal argues that distraction is an emotional reaction to the discomfort of sitting down to work.
Eyal contrasts traction and distraction, saying that since “traction” is any action that pulls you towards what you want to do, distraction is anything that pulls you away from what you planned to do. This includes things that feel productive. Most moments of distraction are caused by “internal triggers,” in contrast to external triggers like notifications or noise.
Eyal has strategies for handling internal triggers (write it down and wait ten minutes, then decide to deal with it; or keeping two hours of time during which he will only write), but the key “is that sometimes this stuff just isn’t easy.”
When people say, “I want to start a habit,” what they’re really saying is: “I want something that’s difficult to become effortless.” They’re saying: “I want the benefits, but I don’t want it to be hard.”
That’s why there’s this myth of habits, because people know the definition of a habit is a behavior done with little or no conscious thought. But I have news for you folks: writing, like many other behaviors, is hard, it requires a lot of conscious thought, at least it is for me.
The post continues with the necessity of planning your time, to make time for traction. “Your schedule should be defined by your values”—wow, that’s a throwback to my emotional intelligence class in my last quarter of school, in which we drove home the importance of making values-based decisions.
The rest of the interview is long, and I read it but don’t really want to write about it. But honestly, it’s hitting home so hard that I think I will just read Eyals’s book.
Shorter articles
Working with data* by Chuxin Huang is a reflection that Huang wrote about data-related careers.
Both at work and in the book, I have to constantly remind myself that asking the right questions and building relationships are the most effective ways to help me become productive.
“Asking questions helps you understand the details of your job more quickly. Building relationships allows you to understand the context of your role in the organization.”
Huang also summarized the paper Algorithmic Effects on the Diversity of Consumption on Spotify, which I’m adding to my reading list.
Modern JavaScript Cheatsheet was a quick reference of newer, more idiomatic ways of doing things in JavaScript. A lot of these were things that I didn’t know existed—e.g., for array manipulation routines, I had used lodash as recently as 2017. Seeing the new way of doing things helped me to write better code.
Perhaps more importantly, though, it helped me to appreciate JavaScript more by showing me how it’s matured over such a short time. In some ways, working on this project has made me feel like I owe an apology to JavaScript—the newer syntax, plus incredible debugging tools, have in some ways made it more fun than writing the Python code here.
Graduate student solves decades old Conway knot problem is an article about Lisa Piccirillo, a mathematics grad student who solved an open question about a knot that John Conway created. The details of the problem are above my head, but this article is amazingly well-written. It is written in an approachable way without dumbing things down the way that lots of popular science articles do.