The fallacies and numbers developers should know

Oftentimes, you could tell a developer is good or not by talking with him if he/she is aware of the common fallacies appear in Unicode and Time, or distributed systems. After all, the growth of a developer is to understand the complexity of the world and the limitation of the abstraction, so the mental model fit better to how the real world is working over time. This blog post is try to curate a list where I find it is good, especially for junior developers. There is already awesome falsehood on github, but I don’t like every link provided in the wiki. And it missed some parts where they are not fallacies, but the numbers you’d better to know.


Let’s start first by knowing the latency charts you should be aware of. This would give a sense of relativity when you analyze a program and to know which part it should be optimized for, given different kind of situation. In a distributed system, network latency dominates the share of the total time it spends. However, in a compute-intense application, you should be aware of how to optimize for cache-line hit, and to avoid the contention for cache slots.

Distributed System

The second one is the famous fallacies of distributed system. They are * The network is reliable * Latency is zero * Bandwidth is infinite * The network is secure * Topology doesn’t change * There is one administrator * Transport cost is zero * The network is homogeneous

This is especially useful when you migrate your monolith application to be several components, or even further, to be micro services working together. Some of the naive function calls need to be extended with further assumptions (or the type would be changed if there is any). The call would need a retry and it would fail if it doesn’t finish within a budget time, and you need to cancel it etc.


Unicode has grown to a beast where most of the junior developers misunderstand. There are numerous gotchas, like the common string comparison problem in Turkey when you set the wrong locale to gotchas that developers should know. I think Apple has done a good job on documenting and design the swift programming language in terms of the unicode support, and by explaining the concepts in the document.


One thing the awesome-falsehood did well is by collecting a list of blog posts that explain the time and calendar in programming well. It ranges from storing UTC is far from enough for future date., to the falsehood that you think it holds for unix time. These are the blog posts that I personally read from the list that I think it is good, but not each of them

Also, Apple’s document on NSCalendar also has some golds in it. * NSCalendar document