Inspired by CJ Quines’s original blog post, which may or may not be a joke, hard to tell… Anyway, the following are real, I promise!

• “Tomer?” (this was the whole email)

• “Transform an unsexy industry!”

• “I totally get it 😂 these emails are super annoying, right?”

• “How are you?!”

• “Another technical recruiter here, trying to gas you and see if you’d like to discuss. Annoyed, non-plussed, or charmed? Lmk for research purposes…”

• “We also offer a referral bonus – we’ll treat you to any restaurant of your choice if you refer a person that we hire.”

• “Exactly the muscle and firepower we need! 🔥”

• “The engineering team remains embryonic.”

• “Your FP iterator library (lfi) shows the design taste we need for shopping AI that feels human.”

• “Me again 🙂”

• “I came across your details via some of your impressive open source projects like eslint-config.”

• “A career is like a frog in boiling water.”

• “Quick question: What’s the difference between debugging code and my follow-up game? One actually gets results 😅”

• “With this software, there’s no way in hell Ferris Bueller would’ve had so many days off.”

• “Yo yo yo!!”

• “Dropping some more heat 🔥…”

• “Trust me I don’t want to be a pest here, Tomer, but I’d be silly if I didn’t insist on getting your attention.”

• “This could be a legacy building role.” (yes, in bold)

• 

• 

• 

• 

• “P.S. Here’s another attempt to make my emails more enjoyable: The glass is your inbox. The manatee is my email. Together they create the aforementioned bump!”

  

The programming language interpreter, and transpilers between Schoenberg and brainfuck programs, can be found on GitHub.

Semantics

The operational semantics of a Schoenberg program directly match those of a brainfuck program. Since brainfuck is Turing-complete, so is Schoenberg.

Like brainfuck, Schoenberg operates on an array of memory cells, each initialized to zero. There is a pointer, initially pointing to the first memory cell, and there are commands for moving the pointer, modifying the current cell, outputting the current cell, and looping.

Syntax

Since Schoenberg programs are MIDI files, its syntax is not text-based.

Instead, commands are controlled by pitch class distance, velocity, and overlap. Rhythm has no effect on a program’s behavior unless it causes notes to overlap.

Additionally:

• Playing the same note twice in a row, corresponding to a pitch class distance of 0, is a no-op. However, playing and overlapping two different notes with the same pitch class (e.g. in different octaves) can be used to start loops without adding other commands.
• When playing multiple notes at exactly the same time (e.g. a chord), the chronology of the notes is considered to be the ascending pitch order.

Every MIDI file is a syntactically valid Schoenberg program, although most don’t do anything useful.

Sample programs

I wrote (composed?) echo.mid from scratch in Ableton and transpiled the rest from brainfuck.

All the programs can be found on GitHub.

FAQ

What’s with the name?

The programming language is named after Arnold Schoenberg (1874–1951), who is widely considered to be the father of atonal music.

Writing tonal music, the basis of Western music composition, requires limiting yourself to the pitch classes of a chosen key, but this is incredibly hard to do when writing Schoenberg programs.

For example, if you want to decrement the pointer cell, then the next note must be 1 pitch class away. This leaves you with only two options for the next note’s pitch class, but it’s possible neither of those pitch classes is in the chosen key.

As a result, Schoenberg programs tend to be atonal.

How did you come up with the idea?

I was inspired by Piet, an esoteric programming language where programs look like abstract paintings.

The concept of a program language where programs are written in an artistic medium was intriguing to me, so I decided to create my own programming language based on music composition, the artistic medium I have the most experience with.

Is it useful for anything?

Like most esoteric programming languages, Schoenberg is mostly a meme and mostly useless.

It could be used for steganography though. For example, you could create a brainfuck program that outputs some text and further conceal the message by transpiling it to a Schoenberg program.

Is there a one-to-one mapping between brainfuck and Schoenberg programs?

No, there is a one-to-many mapping for many reasons. Here are a few:

• Schoenberg programs can be transposed without affecting behavior.
• Schoenberg’s syntax allows specifying most commands in more than one way.
• Note length can often be changed without affecting behavior.

Why did you write it in Rust?

Rust is pretty well-suited for writing interpreters, compilers, transpilers, etc. because of its “algebraic data type” style enums. It also has a user-friendly and performant MIDI parsing and writing library called midly.

Plus, I’ve rarely used Rust and this seemed like a good opportunity to learn more about it.

Is there an IDE?

Any MIDI editor is a Schoenberg IDE!

I personally use Ableton because that’s what I use for non-Schoenberg music production, but GarageBand and FL Studio are also good options.

How did you get to where you are?

What they were asking is how I developed my software engineering skills to their current levels. Over those two weeks I refined my answer and wrote it up in case it comes up again or is helpful to others.

Surface level vs deep understanding

People frequently stick to surface level thinking. Maybe not always and maybe not entirely, but often people don’t strive, knowingly or unknowingly, to dig deeper.

An example

Let’s say someone is reviewing your code. They leave a comment asking to change A to B.

The worst thing you can do is just make the change without understanding the reasoning, because you learn nothing.

The slightly better, but still not great, thing you can do is understand why changing A to B is beneficial in that particular scenario. You probably learn something, but it’s still surface level understanding because it’s unlikely you’ll be able to apply the lesson to future scenarios.

The best thing you can do is understand the principle that prompted the reviewer to leave the comment. It’s unlikely the reviewer has ever seen the exact code you sent for review. So how did they know to leave the comment? They must have consulted a larger or deeper principle, knowingly or unknowingly, to come to their conclusion.

Mental model building

Those principles are exactly what you want to collect and understand. Using those principles you can build a strong mental model of what makes good code, good technical design, good software engineering, etc. Then you can rigorously apply that mental model to future scenarios.

I used code reviews as an example, but this idea applies to any type of feedback or decision making you might encounter.

Naturally, as you do this you might collect principles that conflict with each other. That likely means that some principles you worked into your mental model in the past were too broad or imprecise. Collecting more principles allows you to revise your mental model and make it more robust and precise over time.

Learning is an iterative approach. Don’t be afraid to admit when you are wrong and revise your understanding!

Strategies

You might be thinking that this sounds great in theory, but how does it work in practice? A good strategy for collecting principles is asking questions and following up with independent research as needed.

For example, going back to the code review, let’s say you don’t understand why the reviewer thinks B is better than A. Don’t sit there wondering. Ask them why! If their initial answer doesn’t reveal the principle, then continue asking “why” questions until the principle is clear or until you’ve learned enough to do your own research on the subject.

Warning

It’s not uncommon to discover that there was no valid principle underpinning the feedback or decision, and that it was based entirely on “vibes”. Do yourself a favor and leave vibes out of your mental model.

My answer

So my answer, after explaining all that, is that I’ve always dug for the deeper principles, from my early beginnings, and that’s enabled me to rapidly grow as a software engineer.

The date was November 8, 2021 and I was a bug triager on the Google Docs team. That day began like any other. I made myself some coffee and started looking through bug reports from the day before. But then something caught my eye.

The bug reports 🐛

There were an unusually large number of bugs reported and they all said the same thing. The user had created a reply or new comment in a Doc, but its timestamp in the UI said it had been created “tomorrow”.

The pattern 🌐

A pattern quickly emerged. These bugs were all reported:

• By users in the Pacific Time Zone (PT)
• Between 11
  and 11
  (PT) on November 7

Normally I would have dismissed that as a coincidence, but daylight saving time also ended at 2

The investigation 🕵️

This bug piqued my interest so I decided to triage it to myself.

It didn’t take long to conclude that the bug must be in Closure Library’s relative date formatting logic, which Docs was using. The code started with trying to compute the number of days between the current time and the input time by:

1. Getting the current time as a Date object (i.e. new Date()).
2. Resetting the object’s hours, minutes, seconds, and milliseconds to zero so that it represented the current day’s start time.
3. Computing the number of milliseconds between the current day’s start time and the input time, dividing it by the number of milliseconds in a day, and rounding down.

I stared at the code for a while and then it hit me! The input time, between 11

The result? There weren’t 23 hours between 12

And what does the code do when the input time is 1 day later than the start of the current day? It formats the time as “tomorrow”… 🤡

The fix 🔧

So how did I fix this?

Luckily, JavaScript’s Date class exposes a handy getTimezoneOffset() method, which returns the number of minutes between the Date object’s time zone and the UTC time zone.

I used that method to compute the difference in milliseconds between the time zone offsets of the current day’s start time and the current time, and subtracted that from the number of milliseconds between the current day’s start time and the input time (in step 3 before).

What this effectively does is remove any millisecond differences that are only due to the time zone changing between the current time and the current day’s start time. So now the number of hours between 12

Bonus bug! 🪲

This bug actually also extended to when daylight saving time starts.

In 2021, daylight saving time started at 2

You would expect there to be 23 hours between 12

And what does the code do for that number of hours? It computes the number of days between the two times as zero due to rounding down, and formats the time as “today”…

Note

This bug never actually happened in Docs because you can’t create a comment or reply in the future and view it from the past.

Why 1 hour per year, but only in Pacific Time? 🤔

I originally wrote an explanation here, but some comments on Hacker News made me realize that this bug could have theoretically happened in any time zone.

It’s possible that all the bug reports were coincidentally from users in the Pacific Time Zone. Or perhaps there’s some other factor at play that I haven’t thought of. Let me know if you have any ideas!

Conclusion 🧑‍⚖️

At the time of writing, August 2024, my bug fix has enjoyed two glorious hours of usefulness. Time well spent I guess? 😅

Here’s to hoping my bug fix becomes obsolete soon!

You can also find the track on Spotify, Apple Music, YouTube Music, and other music streaming services. Special thanks to Amanda Gomes for the album cover!

I recently came across a deceptively simple problem. I wanted to dedupe and sort a list of integers in-place.

My initial instinct was to first remove duplicates and then sort using the programming language’s built in sort function. In JavaScript that would look something like this:

const removeDuplicatesThenSort = array => {
  const seen = new Set()
  let insertIndex = 0
  for (let i = 0; i < array.length; i++) {
    const value = array[i]

    // Skip integers we've already seen.
    if (seen.has(value)) {
      continue
    }
    seen.add(value)

    // Place this unique integer at the next available index.
    array[insertIndex] = value
    // Increment to place the next unique integer at the next index.
    insertIndex++
  }
  // Shrink the array down to its new length.
  array.length = insertIndex

  array.sort((a, b) => a - b)
}

But then I realized this is not the only option. I could sort first and then remove duplicates:

const sortThenRemoveDuplicates = array => {
  array.sort((a, b) => a - b)

  if (array.length === 0) {
    return
  }
  let insertIndex = 1
  for (let i = 1; i < array.length; i++) {
    // Skip sequences of duplicate integers.
    const previous = array[i - 1]
    const current = array[i]
    if (current === previous) {
      continue
    }

    // Place this unique integer at the next available index.
    array[insertIndex] = current
    // Increment to place the next unique integer at the next index.
    insertIndex++
  }
  // Shrink the array down to its new length.
  array.length = insertIndex
}

At first I thought this option must be more efficient than the other one because it doesn’t require tracking already seen integers in a set. But then I had another realization: removing duplicates first could shrink the size of the array, and that could speed up the subsequent sorting.

So which option is better?

Note

We won’t explore the possibility of removing duplicates while sorting because that would require rewriting the programming language’s built in sorting algorithm and it’s unlikely that we can match the original performance¹.

Time and space complexity

Complexity analysis is a way to reason about the amount of resources, usually time and space, an algorithm uses as the size of its input increases. We can use it to objectively compare our two algorithms!

Let’s define some variables that describe our input array:

• $n$ is the total number of integers
• $d \leq n$ is the number of distinct integers

Dedupe then sort

Removing duplicates and then sorting takes $O(n + d\log_2{d})$ time (on average) and $O(d)$ space because:

• We loop through all $n$ integers and perform constant time work (on average) for each one. That takes $O(n)$ time.
• We add $d$ integers to a set by the end of the loop. That requires $O(d)$ space.
• We sort the remaining deduplicated integers, which there are $d$ of. In general sorting takes quasilinear time so sorting these integers takes $O(d\log_2{d})$ time.

I used the phrase “on average” a couple of times. That’s because if the set is a hash table, which it is in JavaScript, then insertion and lookup take linear time, not constant time, in the worst case.

That means that the algorithm takes $O(n^2 + d\log_2{d}) = O(n^2)$ time in the worst case².

Sort then dedupe

Sorting then removing duplicates takes $O(n\log_2{n})$ time and $O(1)$ space because:

• We sort the input integers, which there are $n$ of. That takes $O(n\log_2{n})$ time.
• We loop through all $n$ integers and perform constant time work for each one. That takes $O(n)$ time.
• We don’t allocate any space dependent on the input size. That requires only $O(1)$ space.

Unlike the other algorithm, the average and worst case time complexities are the same.

Which is better?

The average case is most informative, but it’s still not immediately clear whether $O(n + d\log_2{d})$ is more efficient than $O(n\log_2{n})$ because we have two variables, not one. Let’s explore what happens when we assume different relationships between $n$ and $d$.

$d$ is significantly smaller than $n$

If $d$ is significantly smaller than $n$, meaning there are many duplicate integers, then the time complexity of removing duplicates and then sorting becomes $O(n)$, which is certainly more efficient than $O(n\log_2{n})$.

There’s still the matter of the $O(d)$ space complexity, but that’s unlikely to be a problem unless $d$, and consequently $n$, are very large.

$d \approx n$

If $d$ and $n$ are not significantly different, meaning there are few or no duplicate integers, then the time complexity of both algorithms becomes $O(n\log_2{n})$.

However, removing duplicates and then sorting also requires $O(d)$ space, which with our assumption is approximately $O(n)$, that the other algorithm doesn’t. Plus, in practice that space also takes additional time to allocate, insert into, and query, even if it doesn’t affect the time complexity.

So in this case sorting and then removing duplicates is more efficient.

Which is better empirically?

Our theoretical analysis suggests that we should sort and then remove duplicates if we expect few duplicates. Otherwise, we should remove duplicates and then sort. But is that empirically true? And if so, then how many duplicates does it take for switching algorithms to be worthwhile?

I benchmarked to find out! I ran each algorithm on a shuffled array of 100,000 integers with various duplicate integer percentages and this was the result:

This confirms that the overhead from the set used when removing duplicates and then sorting isn’t always offset by the reduced number of integers to sort later³.

In the case of 100,000 integers the overhead is only offset once roughly 27% of the integers are duplicates. I also benchmarked some other array sizes and the boundary varies. For example, for 100 integers the boundary was around 10%. Do your own benchmarking if you’re going to depend on this!

Conclusion

The appropriate approach depends on the expected percentage of duplicates. And problems that seem simple… aren’t.

The feature 📅

For one component of this feature, users were able to pick any date, save it, and see it displayed later. This part was implemented and working fine for a couple weeks.

The bug report 🐛

Another engineer noticed that a date they had entered as September 1, and which had previously been displaying correctly, was now being displayed as October 1. They confirmed that the date was correctly stored in our database and correctly sent from the server to the client. So my coworker concluded there was a bug in displaying the date on the client.

The unit test 🧪

My coworker successfully wrote a failing unit test that resulted in displaying October 1 for an input date of September 1. They considered debugging further, but the bug was reported late in the day, so they decided to log off and debug further the next day.

Little did they know that the next day the unit test would start passing! They could not reproduce the unit test failure no matter what they did. And to top it all off, September 1 was now displaying correctly for the bug reporter.

Eureka! 💡

It was time to get the team together to figure this out. Several of us sat down and scrutinized the code until the root cause finally dawned on us. We had a function that converted server provided dates to dates for use in the UI. It looked something like this:

const toDate = serverDate => {
  const date = new Date()
  date.setFullYear(serverDate.getYear())
  date.setMonth(serverDate.getMonth())
  date.setDate(serverDate.getDay())
  return date
}

Do you see the problem?

We realized that the bug was reported on August 31 and disappeared on September 1, the next month. Why does that matter? new Date() creates a date object for the current date and time, and it turns out that calling setMonth on the object does not reset the object’s day. It keeps the same day… but only if it can! If the current day of the month is greater than the number of days in the month passed to setMonth, then the days will “overflow” into the next month.

That’s why September 1 displayed as October 1 on August 31:

const toDate = (
  // September 1, 2021
  serverDate,
) => {
  // August 31, 2021
  const date = new Date()
  // Still August 31, 2021
  date.setFullYear(serverDate.getYear())
  // September 31 -> OVERFLOW! (September has 30 days) -> October 1
  date.setMonth(serverDate.getMonth())
  // Still October 1
  date.setDate(serverDate.getDay())
  return date
}

But the following day, September 1, didn’t have the same problem because there was no overflow. The fix was simple:

const toDate = serverDate =>
  new Date(serverDate.getYear(), serverDate.getMonth(), serverDate.getDay())

Why 29 (or 30) days per year? 🤔

So why can this bug only happen 29 (or 30) days per year? Well, the month with the lowest number of days is February, with 28 days on common years. That means displaying a common year February date maximizes the potential for date overflow; the bug will occur whenever the current date’s day of the month is greater than 28. But how often does that happen? How many dates have a day of the month greater than 28?

Sum up the last column and we have our answer! This bug can happen on only 29 days for common years and 30 days for leap years.

Lessons learned 🏫

I was thinking about this bug for days (ha!) after solving it and reached a few conclusions:

• Don’t assume a constructor has the same behavior as a sequence of setter calls for the same fields! A constructor has access to all the inputs at once while each setter only has isolated access to each input. That can force some odd behaviors.

• Don’t underestimate the complexity of dates and times. If it involves dates and times, then test it thoroughly, even if it seems trivial. I guarantee you it’s not!

• Teamwork makes the dream work 😍

You can also find the track on Spotify, Apple Music, YouTube Music, and other music streaming services. Special thanks to Tiana Rogers for the album cover!

The bug report 🐛

The QA team found a bug where some of a table’s borders would be missing after a table cell split in certain scenarios. However, the borders reappeared when refreshing the page. That meant the document’s data was likely stored correctly and that incremental layout or rendering had a bug.

The investigation 🕵️

At the time, the team was migrating Google Docs from HTML-based rendering to canvas-based rendering. QA reported the bug about a canvas-rendered document, which made me suspect it was a bug in canvas-based rendering. So I tried to reproduce the issue on an HTML-rendered document and it didn’t reproduce!

At this point I concluded the new canvas-based rendering must have a bug. Oh how wrong I was… After much investigation, I realized canvas-based rendering was correct.

Two bugs 🐛🪲

In Google Docs, the output of layout is the input for rendering. It turned out layout had a bug and canvas-based rendering was correctly displaying layout’s incorrect output. So why did HTML-based rendering look correct? It turned out that HTML-based rendering also had a bug, and the bug coincidentally “fixed” layout’s output so that the final output looked correct.

How? 🤔

So how did the HTML-based rendering bug cancel out the layout bug? One of the reasons the team switched to canvas-based rendering, other than better performance, is that it’s more precise than HTML-based rendering.

With canvas-based rendering you effectively have to specify the location of every pixel, which means it can accurately render any layout. It did just that for the incorrect layout output!

On the other hand, with HTML-based rendering a table is rendered using a table element, which supports a limited set of layouts. HTML-based rendering could not faithfully render the incorrect layout output so it rendered the closest thing, which coincidentally looked correct.

const map = new Map()
map.set([1, 2], 3)
console.log(map.get([1, 2]))
//=> undefined

const set = new Set()
set.add([1, 2])
console.log(set.has([1, 2]))
//=> false

The code behaves this way because a Map’s keys and a Set’s values are compared using reference equality, as specified by the SameValueZero algorithm. Two deeply equal arrays are not referentially equal:

console.log([1, 2] === [1, 2])
//=> false

The following code behaves more predictably:

// A reference to a single array instance!
const tuple = [1, 2]

const map = new Map()
map.set(tuple, 3)
console.log(map.get(tuple))
//=> 3

const set = new Set()
set.add(tuple)
console.log(set.has(tuple))
//=> true

But that isn’t particularly useful because typically you’re constructing tuples on the fly using values from some external source:

const f = (x, y) => {
  // This will return undefined because `[x, y]` is a new array!
  const value = map.get([x, y])

  // ...
}

A common solution is to use JSON.stringify:

const map = new Map()
map.set(JSON.stringify([1, 2]), 3)
console.log(map.get(JSON.stringify([1, 2])))
//=> 3

const set = new Set()
set.add(JSON.stringify([1, 2]))
console.log(set.has(JSON.stringify([1, 2])))
//=> true

This works because strings are primitives, which are compared by value rather than by reference. Unfortunately, using JSON.stringify requires that the inner values are stringifiable. If they’re not, then you’re forced to write a custom serialization function.

Plus, sometimes you do want reference equality, per inner value, but serialization doesn’t preserve reference equality:

const person1 = { name: `Tomer`, occupation: `Software Engineer` }
const person2 = { name: `Tomer`, occupation: `Software Engineer` }

const salaryApplications = new Map()
salaryApplications.set(JSON.stringify([person1, Number.MAX_VALUE]), `approved`)

// Oh no! Two different software engineers named Tomer are considered the same due to stringifying!
console.log(salaryApplications.get(JSON.stringify([person2, Number.MAX_VALUE])))
//=> approved

Surely there’s a better way!

The solution: keyalesce

keyalesce is a module that returns the same unique key for the same value sequence¹. It’s perfect for this use case:

const person1 = { name: `Tomer`, occupation: `Software Engineer` }
const person2 = { name: `Tomer`, occupation: `Software Engineer` }

const map = new Map()
map.set(keyalesce([1, 2]), 3)
map.set(keyalesce([2, `b`, 3]), 4)
map.set(keyalesce([person1, Number.MAX_VALUE]), `approved`)
map.set(keyalesce([person2, Number.MAX_VALUE]), `totally approved`)

console.log(map.get(keyalesce([1, 2])))
//=> 3

console.log(map.get(keyalesce([2, `b`, 3])))
//=> 4

console.log(map.get(keyalesce([person1, Number.MAX_VALUE])))
//=> approved

console.log(map.get(keyalesce([person2, Number.MAX_VALUE])))
//=> totally approved

const set = new Set()
set.add(keyalesce([1, 2, 3, 4, 5]))
set.add(keyalesce([3, 3, 2, 2, 1]))

console.log(set.has(keyalesce([1, 2, 3, 4, 5])))
//=> true

console.log(set.has(keyalesce([3, 3, 2, 2, 1])))
//=> true

console.log(keyalesce([1, 2, 3, 4, 5]) === keyalesce([1, 2, 3, 4, 5]))
//=> true

How does it work?

keyalesce internally maintains a trie containing the sequences of values it has been called with. It creates and returns new keys for new sequences and returns previously created keys for known sequences!

For example, the following code:

const key1 = keyalesce([1, 2, 3, 4])
const key2 = keyalesce([1, 2, 3])
const key3 = keyalesce([1, 2, 7, 8])
const key4 = keyalesce([`a`, `b`, `c`])

Would result in the following trie:

And calling keyalesce([1, 2, 3, 4]) again would return key1 after traversing nodes 1, 2, 3, and 4 in the trie.

Does keyalesce cause memory leaks?

A long running program using a naive implementation of keyalesce would have a memory leak due to unbounded growth of the trie. How are unreachable nodes pruned?

Sequence value reachability

Consider the following code:

let object1 = {}
let object2 = {}

const key1 = keyalesce([1, object1, 4])
const key2 = keyalesce([1, 2, object2, 3])

// ...

Which would result in the following trie:

If the code continues like so:

object2 = null

Then object2’s original value is only reachable from the trie. keyalesce can now prune the associated sequence and its key from the trie because it has become impossible for keyalesce to be called with that sequence ever again.

I made the trie hold only weak references to objects passed to keyalesce and pruned the trie when the objects are garbage-collected using FinalizationRegistry.

After pruning in this case the trie would look like so:

Note

Although 1 was in the sequence it was not pruned because it is still needed for another sequence.

Created key reachability

Consider the following code:

let key1 = keyalesce([1, 2, 4])
let key2 = keyalesce([1, 2, 5, 7])

// ...

Which would result in the following trie:

The previous section’s logic does not apply because all of the sequence values are primitives, which are always reachable and not eligible for garbage collection. So how is the trie pruned in this case?

If the code continues like so:

key2 = null

Then key2’s original value is only reachable from the trie. Although it’s still possible to call keyalesce with [1, 2, 5, 7], keyalesce can actually prune the key and its associated value sequence because there isn’t any code that depends on receiving that specific key anymore. keyalesce doesn’t need to return the same unique key for a given value sequence. It only needs to prevent multiple keys existing simultaneously for the same value sequence.

Similarly to the handling of object sequence values, I made the trie hold only weak references to created keys and pruned the trie when the keys are garbage-collected using FinalizationRegistry.

After pruning in this case the trie would look like so:

Note

Although 1 was in the sequence it was not pruned because it is still needed for another sequence.

In summary, the trie is pruned whenever object sequence values or keys have only weak references to them.

Is it actually safe to clean up unreachable keys?

You might think up the following scenario, which shows we can’t really know whether “any code depends on receiving that specific key anymore”:

1. Use keyalesce to create a key from a sequence of primitive values
2. Add some properties to the created key
3. Depend on those added properties existing throughout your code
4. Let the key become unreachable
5. Get confused when keyalesce returns a key without those properties for the same sequence of primitive values from before, causing your code to misbehave

keyalesce prevents this scenario by freezing the created key, which makes it impossible to depend on the contents of the key. The key is a completely opaque object.

The correct alternative to setting properties on the created key is to, well, use it as a key! You can use it as a key in a:

• Map; if you want the key’s associated value to exist as long as the Map is reachable. Beware of memory leaks in this case!
• WeakMap; if you want the key’s associated value to exist only as long as the key is reachable by the rules explained before

Go use it!

Install keyalesce:

$ npm i keyalesce

And import it:

import keyalesce from 'keyalesce'

const hangouts = new Set()

const createHangoutKey = (person1, person2) =>
  keyalesce([person1, person2].sort())
const hangOut = (person1, person2) =>
  hangouts.add(createHangoutKey(person1, person2))
const didTheyHangOut = (person1, person2) =>
  hangouts.has(createHangoutKey(person1, person2))

hangOut(`Tomer`, `Samuel`)
hangOut(`Tomer`, `Amanda`)

console.log(didTheyHangOut(`Tomer`, `Samuel`))
console.log(didTheyHangOut(`Samuel`, `Tomer`))
//=> true
//=> true

console.log(didTheyHangOut(`Tomer`, `Amanda`))
console.log(didTheyHangOut(`Amanda`, `Tomer`))
//=> true
//=> true

console.log(didTheyHangOut(`Samuel`, `Amanda`))
console.log(didTheyHangOut(`Amanda`, `Samuel`))
//=> false
//=> false

Optimizing your font files and using an intelligent font loading strategy can eliminate layout shifts, but only if the web font is not immediately used on the page. Otherwise you have to ensure the text container’s height doesn’t change. Fontpie can help with this. It’s a tool for generating CSS that adjusts a fallback font’s metrics so it takes up the same amount of space as your web font. The result is no layout shifts even if the font is immediately used!

Part of what makes Fontpie great is that it’s framework agnostic, but that also means it’s a bit manual to use and I wanted something I could easily integrate into this website’s build. I was already using PostCSS so I decided to make a Fontpie PostCSS plugin. The result is postcss-fontpie. And now generating fallback font metrics for my web fonts is as easy as adding the following to my PostCSS config:

const { join } = require(`path`)

module.exports = {
  plugins: [
    // ...
    require(`postcss-fontpie`)({
      fontTypes: {
        dm: `mono`,
        'Kantumruy Pro': `sans-serif`,
      },
      srcUrlToFilename: url => join(__dirname, `src/styles`, url),
    }),
    // ...
  ],
}

You can see the generated fallback font metrics in this website’s CSS and their effects in the following before-and-after GIFs:

Check out postcss-fontpie’s usage example to use it in your own website!

Naturally this list only includes projects I’m allowed to talk about! For many projects I was not the only person who worked on it. Projects I worked on as part of my 20% time are labeled with 20%. The projects are ordered from most to least recent.

• Spearheaded the development of high-fidelity Markdown import and export for Docs, enhancing its compatibility with numerous content management systems and resulting in a user importing or exporting Markdown every second. 20%

  Several news outlets took note:

  • Ars Technica: Real, actual Markdown support is arriving in Google Docs, not a moment too soon
  • How-To Geek: Google Docs Can Now Import and Export Markdown

  And Hacker News definitely noticed.

  

• Co-led a foundational rearchitecture of the Docs backend, frontend, and data model to implement tabs in Docs, including updating all cross-cutting features, resulting in ~1.75 tabs on average for recently opened documents. The Verge took note: “Google Docs is making it much easier to organize information”.

• Delighted users with some easter eggs in Docs. Try typing @tictactoe or @fourinarow! 20%

• Integrated Gemini into Docs to enable GenAI content generation and rewrites, complete with headings, lists, tables, and other rich content, as a member of a large team, resulting in ~150,000 weekly usages.

  Many news outlets took note:

  • Forbes: Google Stock Jumps As It Puts Artificial Intelligence Into Google Docs
  • Fortune: GPT-4 debuts and Google beats Microsoft in race to add generative A.I. to consumer office tools
  • Reuters: Google unveils ‘magic wand’ to draft documents as AI race tightens
  • The Verge: Google announces AI features in Gmail, Docs, and more to rival Microsoft
  • USA Today: Google unveils new features for Docs, Gmail and more amid AI race
  • The Washington Post: Google is adding AI to its work apps. Here’s what that means.

• Jointly implemented code block support in Docs, including automatic Markdown detection and conversion, resulting in ~90,000 weekly code block insertions, with 25% from Markdown conversion. The Verge took note: “Google’s making code formatting a breeze in Docs”.

• Independently empowered Docs users with improved data organization by developing an option to split table cells, leading to ~1.15 million weekly cell splits. 20%

• Boosted Google Docs collaboration by 8% by developing a real-time email alert system, complete with subscription settings and document diffs for recent edits, that sends ~300,000 weekly emails, as a member of a 3-person team.

• Increased developer productivity by implementing automatic Markdown detection and conversion for Docs, Slides, and Drawings¹, resulting in ~1.2 million automatic weekly conversions. 20%

  Several news outlets took note:

  • WIRED: “How to Use Markdown in Google Docs”
  • The Verge: ”# Google Docs is getting more Markdown support”
  • TechCrunch: “Google adds limited Markdown support to Google Docs”

  And tech Twitter definitely noticed.

• Simplified Docs, Slides, and Drawings authoring with shared prefix substitution rule support, and en- and em-dash substitution, resulting in a 45% increase in substitutions and no change in undo rates. 20%

• Increased the width of comment threads in Docs. They were way too narrow and it was bothering me! 😅 20%

• Developed dynamic Drive sharing emails that automatically update with the latest thumbnail, owner, and edit details via a high-performance endpoint handling 300 queries per second, resulting in 6% fewer short sessions from the emails.

• Expanded link previews in Docs, Sheets, Slides, and Drawings to links in comment threads. Previously, they only appeared for links in the editor itself. 20%

• Streamlined finding new and important comments in Docs with comment badging and filtering, boosting reply creation and comment resolutions by 2%. USA TODAY took note: “Google Docs upgrades comments feature to make collaboration easier”.

• Interned on the Sites team in the Summer of 2019 and enabled site viewers to provide feedback on published Sites.

You can also find the track on Spotify, Apple Music, YouTube Music, and other music streaming services. Special thanks to Emily Kazenmayer for the album cover!

You can also find the track on Spotify, Apple Music, YouTube Music, and other music streaming services. Special thanks to Jill Marbach for the album cover!

• Generation of Personalized and Structured Content Using a Collaborative Online Generator · October 3, 2024

  Systems and methods for generating personalized and structured content using a collaborative generator provide a user interface to a user computing system and receive a prompt from the user computing system via the user interface. The systems and methods provide the prompt to a generative model, with the generative model being a machine-learned model trained to process language input prompts to generate a language output. The systems and methods receive a generative output generated by the generative model in response to the prompt. Additionally, the systems and methods generate a modified output by modifying the generative output based at least in part on historical user data for a user associated with the prompt, and then provide the modified output via the user interface.

  The techniques described in this patent were used for integrating Gemini into Google Docs.

• Language Agnostic Incremental Real-time Code Highlighting · June 5, 2024

  This disclosure describes techniques of fast, real-time highlighting of code snippets with low algorithmic complexity. The techniques are suitable to enable highlighting of code sections within relatively lightweight environments such as general-purpose word processors. Delimited ranges of characters within code are identified. Changes within delimited ranges are tracked using a sparse array. The use of a sparse array enables operations on the delimited range to be tracked at a low computational complexity. The highlighted color of a word is the color of its delimited range. The color highlighting maintains real-time synchronization with edits being made simultaneously on a document by collaborating developers. The overhead to define a language is kept low, such that highlighting can be provided without building knowledge of the entire syntax and grammar of the language into the code highlighting implementation.

  The techniques described in this defensive publication were used for adding code blocks to Google Docs.

• Synthesis cost-optimal targeted mutant protein libraries · April 18, 2024

  Protein variant libraries produced by site-directed mutagenesis are a useful tool utilized by protein engineers to explore variants with potentially improved properties, such as activity and stability. These libraries are commonly built by selecting residue positions and alternative beneficial mutations for each position. All possible combinations are then constructed and screened, by incorporating degenerate codons at mutation sites. These degenerate codons often encode additional unwanted amino acids or even STOP codons. Our study aims to take advantage of annealing based recombination of oligonucleotides during synthesis and utilize multiple degenerate codons per mutation site to produce targeted protein libraries devoid of unwanted variants. Toward this goal we created an algorithm to calculate the minimum number of degenerate codons necessary to specify any given amino acid set, and a dynamic programming method that uses this algorithm to optimally partition a DNA target sequence with degeneracies into overlapping oligonucleotides, such that the total cost of synthesis of the target mutant protein library is minimized. Computational experiments show that, for a modest increase in DNA synthesis costs, beneficial variant yields in produced mutant libraries are increased by orders of magnitude, an effect particularly pronounced in large combinatorial libraries.

• Table cell splitting in an online document editor · April 11, 2024

  Techniques are described herein for table cell splitting in an online document editor. A method includes: responsive to a request to split a cell in a table, determining a target number of rows and a target number of columns, automatically inserting rows adjacent to rows of the cell to reach the target number of rows, automatically inserting columns adjacent to columns of the cell to reach the target number of columns, and automatically merging groups of cells within an initial boundary of the cell, each group spanning a determined number of rows per group and a determined number of columns per group.

  The techniques described in this patent were used for adding table cell splitting to Google Docs.

• Language Agnostic Code Highlighting in Word Processors · June 16, 2022

  This disclosure describes techniques for highlighting code snippets included in text documents edited via a word processor. A text block containing code is received and analyzed using a tokenizer to identify specific words included in the text block. The words are classified by the tokenizer into a finite set of types (categories) by matching the words with a list of words defined for different computer languages. Words or characters are colorized based on whether the word is a language specific reserved keyword or a user-defined identifier. Multiple coding languages can be supported, with low maintenance, since only the active dictionary of reserved words needs to be updated when adding a language. The techniques can support live updates, highlighting code even as the user enters text. Incremental highlighting can be implemented with relatively minimal additional effort by analyzing only a small block of code near the altered text character(s).

  The techniques described in this defensive publication were used for adding code blocks to Google Docs.

• Decodon Calculator: Degenerate Codon Set Design for Protein Variant Libraries · August 1, 2020

  We have designed and implemented an algorithm that, given any set of amino acids, produces the minimum number of decodons necessary to code for exactly this set, i.e. without coding for extraneous amino acids or STOP codons. There are 15 nucleotide codes (“letters”), ranging from the completely unambiguous A, C, G and T representing a single nucleotide, to the completely ambiguous N representing all 4 nucleotides. There are 153 = 3, 375 decodons that can be assembled from this 15-letter alphabet of ambiguous codes, compared to the 43 = 64 codons that can be constructed from the standard 4-letter alphabet of unambiguous nucleotides.

console.log(value == null)
console.log(value === null)
console.log(value == undefined)
console.log(value === undefined)
console.log(value === undefined || value === null)
console.log(typeof value === 'undefined')
console.log(typeof value == 'undefined')
console.log(typeof value === 'undefined' || value === null)
console.log(typeof value === 'undefined' || value == null)
console.log(typeof value == 'undefined' || value == null)
console.log(typeof value == 'undefined' || value === null)
console.log(!value)

Which one is right?

Absent values

JavaScript has two representations of an absent value.

Undefined

undefined is a JavaScript primitive type. The typeof operator returns 'undefined' for undefined:

console.log(typeof undefined)
//=> undefined

The value of a declared unassigned variable is undefined:

let x
console.log(x)
//=> undefined

The access of an absent object property returns undefined:

const object = {}
console.log(object.absentProperty)
//=> undefined

The return value of a function that doesn’t explicitly return is undefined:

function f() {}
console.log(f())
//=> undefined

The void operator always returns undefined¹:

console.log(void 0)
//=> undefined

console.log(void 'hello')
//=> undefined

console.log(void (3 + 2))
//=> undefined

console.log(void (/* any expression */))
//=> undefined

Lastly, undefined is not a literal! It is a property of the global object, which always exists in the global scope.

Null

null is also a JavaScript primitive type, but typeof returns something unexpected for null:

console.log(typeof null)
//=> object

Ideally typeof null would return 'null', but typeof null has returned 'object' since JavaScript’s inception and it would break existing code if the behavior were changed now.

null does not appear as a “default” value in JavaScript in the same way that undefined does. Instead, developers typically make functions return null when an object can’t be found or constructed. For example, in browsers document.getElementById returns null if there’s no element in the document with the given ID:

console.log(document.getElementById('some-id-that-no-element-has'))
//=> null

Unlike undefined, null is a literal. It is not a property of the global object.

Equality

Now that we’ve covered undefined and null, let’s address the difference between == and ===.

Strict

Strict equality is invoked using ===. For two values, a and b, a === b evaluates to true if a and b have the same type and their values are equal. Otherwise, a === b evaluates to false:

console.log(0 === 0)
//=> true

console.log('hello!' === 'hello!')
//=> true

console.log(null === null)
//=> true

console.log(undefined === undefined)
//=> true

console.log(0 === 5)
//=> false (same types, but different values)

console.log(0 === '0')
//=> false (different types)

console.log(0 === 'hello!')
//=> false (different types)

console.log(null === undefined)
//=> false (different types)

const object = {}

console.log(object === {})
//=> false (because objects are compared by reference)

console.log(object === object)
//=> true (because the object is referentially equal to itself)

Loose

Loose equality is invoked using == and often produces unexpected results. For two values of the same type, a and b, a == b behaves like a === b. If a and b have different types, then JavaScript coerces the values to the same type and strictly equates them:

console.log(1 == 1)
//=> true

console.log(1 == '1')
//=> true (because the string was converted to a number)

console.log('1' == 1)
//=> true (because the string was converted to a number)

console.log(0 == false)
//=> true (because the boolean was converted to a number)

console.log(0 == null)
//=> false (because absent values are not considered equal to non-absent values)

console.log({} == {})
//=> false (because objects are compared by reference)

console.log(0 == undefined)
//=> false (because absent values are not considered equal to non-absent values)

console.log(null == undefined)
//=> true (because both are absent values)

console.log(undefined == null)
//=> true (because both are absent values)

console.log('hello!' == false)
//=> false

console.log('' == false)
//=> true (because the string was converted to a boolean and an empty string sort of represents false in the realm of strings I guess)

console.log([] == false)
// true (because the array was converted to a boolean and an empty array sort of represents false in the realm of arrays I guess)

If you’re feeling confused, then you wouldn’t be the only one. This operand conversion table and article about “truthy” and “falsy” values explain loose equality more fully. For a handy reference on the behavior of == and ===, look no further than this JavaScript equality table.

The right way to check for an absent value

Now we can check which expressions from the beginning of the post work! Let’s take a look at the first expression:

console.log(value == null)

• Does it evaluate to true for undefined? Yes, because undefined and null are loosely equal.

• Does it evaluate to true for null? Yes, because null is equal to itself.

• Does it evaluate to false for everything else? Yes, because null is only loosely equal to itself and undefined.

value == undefined would also work for roughly the same reasons, but value == null is safer because undefined could be shadowed or reassigned in pre-ES5 JavaScript environments. This can’t happen with null because it is a literal.

Undeclared variables

These methods work except for one lurking issue. If value is undeclared, then our code would throw a ReferenceError.

That may sound like a nonissue, but consider that some JavaScript needs to be compatible with both the browser and Node.js, and that the two environments differ in which global variables are declared. For example, in the browser the global variable window is declared, but there’s no such variable in Node.js. Can we access the window variable only if it exists and avoid a ReferenceError?

It turns out that the typeof operator returns 'undefined' for an undeclared variable instead of throwing a ReferenceError. This is convenient because typeof undefined also returns 'undefined' so typeof value === 'undefined' checks for both undeclared variables and undefined. To check for null as well we can add an additional check using logical “or”.

console.log(typeof value === 'undefined' || value === null)

• Does it evaluate to true when value is undeclared? Yes, because the typeof operator returns 'undefined' for an undeclared variable.

• Does it evaluate to true for undefined? Yes, because typeof undefined returns 'undefined'.

• Does it evaluate to true for null? Yes, the first condition evaluates to false, but the second condition evaluates to true because null is equal to itself.

• Does it evaluate to false for everything else? Yes, the typeof operator only returns 'undefined' for undeclared variables and undefined, and null is only strictly equal to itself.

This method works in every situation, but it is only preferable over value == null when you don’t know if value has been declared².

The problems with the other expressions

A few of the expressions at the beginning of the post look almost identical to the expression we just evaluated. In fact, the following expressions are equivalent to typeof value === 'undefined' || value === null:

console.log(typeof value === 'undefined' || value === null)
console.log(typeof value === 'undefined' || value == null)
console.log(typeof value == 'undefined' || value == null)
console.log(typeof value == 'undefined' || value === null)

So why choose the expression that uses strict equality for both conditions? I prefer to avoid loose equality because it’s confusing and in this case it’s not required for correct behavior.

Let’s evaluate the rest of the expressions from the beginning of the post:

// Doesn't account for undefined
console.log(value === null)

// Doesn't account for null
console.log(value === undefined)

// Works, but is much more verbose than value == null
console.log(value === undefined || value === null)

// Doesn't account for null
console.log(typeof value === 'undefined')

// Doesn't account for null
console.log(typeof value == 'undefined')

// Erroneously evaluates to true for falsy values such as false, '', [], and 0
console.log(!value)

Absent object properties

An object property can be set to an absent value, but the property itself can also be absent:

const object1 = {}
const object2 = { property: undefined }

console.log(object1.property == null)
//=> true

console.log(object2.property == null)
//=> true

The result for the two objects is the same because the access of an absent property returns undefined. This makes value == null a good solution when checking for null, undefined, and absent properties. However, specifically checking for an absent property requires a different method.

One way is to use the in operator:

const object1 = {}
const object2 = { property: undefined }

console.log('property' in object1)
//=> false

console.log('property' in object2)
//=> true

Note that the left-hand side of the in operator must be a string or Symbol, not an identifier. This may seem like a good solution, but consider the following case:

const object1 = {}
const object2 = { constructor: undefined }

console.log('constructor' in object1)
//=> true

console.log('constructor' in object2)
//=> true

Probably not what you expected right? The expression 'constructor' in object1 returns true because the constructor property was inherited from the object’s prototype chain. The in operator considers both the specific properties of the object as well as its inherited properties.

This a nonissue when the object has a null prototype because there are no inherited properties:

const object = Object.create(null)
console.log(`constructor` in object)
//=> false

But most of the time the object doesn’t have a null prototype or we don’t know if it does. A more robust solution is to only check the uninherited properties using the hasOwnProperty method, which is inherited from Object:

const object1 = {}
const object2 = { constructor: undefined }

console.log(object1.hasOwnProperty('constructor'))
//=> false

console.log(object2.hasOwnProperty('constructor'))
//=> true

There are a couple of pitfalls to using the hasOwnProperty method:

const object1 = { hasOwnProperty: () => true }
const object2 = Object.create(null)

console.log(object1.hasOwnProperty('property'))
//=> true

console.log(object2.hasOwnProperty('property'))
//=> TypeError: object2.hasOwnProperty is not a function

object1’s hasOwnProperty method was shadowed by a method that always returns true. object2 was created with a null prototype so it does not inherit hasOwnProperty from Object. There are two ways around these pitfalls:

• Access Object’s hasOwnProperty method directly:

  const object = { hasOwnProperty: () => true }
  console.log(Object.prototype.hasOwnProperty.call(object, 'property'))
  //=> false

• Use Object’s static hasOwn method:

  const object = { hasOwnProperty: () => true }
  console.log(Object.hasOwn(object, 'property'))
  //=> false

  hasOwn was added to JavaScript to avoid hasOwnProperty’s pitfalls, but at the time of writing it is relatively new.

Recap

Checking if value is set to an absent value:

value == null

Checking if value is undeclared or set to an absent value:

typeof value === 'undefined' || value === null

Checking if 'property' in object is absent or set to an absent value:

object.property == null

Checking if property in object is absent:

!Object.prototype.hasOwnProperty.call(object, 'property')

Checking if property in object is absent in modern browsers:

!Object.hasOwn(object, 'property')