Interesting Articles

1. Going Criticalby Kevin Simler talks about how things go viral, and what it takes for them to die out eventually, if at all. While he talks using anology of infections initially, it is very suitable for viral posts, ideas, and knowledge as well, which are explored later in the post. The idea that stuck with me was how situations and the time have to be right for things to spread, with proper support from network, else they will easily die out.

   …it’s only the transmission rate that determines whether the network is sub- or supercritical…like trying to start a fire in a wet field. You might get a few dry leaves to catch, but the flame will quickly die out because the rest of the landscape isn’t flammable enough (subcritical). Whereas in a very dry field (supercritical), it may only take one spark to start a raging wildfire.

   Immunity (or apathy towards a post or an idea), gaps and herd immunity in the network also have very important implications in reducing the transmission rate. Then there is a concept of degree which is number of immediate connections a node has, and clusters where this degree is higher. Transmission is critical (sustainable) when degree is higher, more so when there are clusters present. Ideas that thrive is cities, for example, fizzle out in country side simply because of this.

   …elite networks are generally much denser than non-elite networks — an underappreciated fact, IMO.

   Inventions too happen through network effect, where inventors stand on the shoulders of the giants.

   Overall, a very well written, informative piece of work.

   See equally interesting HN discussion on this post.

Wise Snippets

1. Captured from How to Build Good Software

Software is limited not by the amount of resources put into building it, but by how complex it can get before it breaks down;

The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.

You cannot make technological progress if all your time is spent on rebuilding existing technology.

Building good software involves alternating cycles of expanding and reducing complexity…This two-step process is necessary because there is no such thing as platonically good engineering: it depends on your needs and the practical problems you encounter.

Even if the system is very well documented, some knowledge is lost every time a new team takes over. Over the years, the system becomes a patchwork of code from many different authors. It becomes harder and harder to keep running; eventually, there is no one left who truly understands how it works.

Having a clear problem statement lets you experimentally test the viability of different solutions that are too hard to determine theoretically.

With software, apparently obvious solutions often have fatal flaws that do not show up until they are put to use. The aim is not yet to build the final product, but to first identify these problems as quickly and as cheaply as possible.

Begin with a small number of testers who will quickly spot the obvious bugs that need to be fixed. As problems are addressed, you can increasingly open up to a larger pool who will find more esoteric issues. Most people only give feedback once. If you start by launching to a large audience, everyone will give you the same obvious feedback and you’ll have nowhere to go from there.

…the best engineers are at least 10 times more productive than an average engineer. This is not because good engineers write code 10 times faster. It is because they make better decisions that save 10 times the work.