> it either came down to either having more energy than others at tackling a problem they thought was more trouble than it was worth, or just bringing back rand

> it either came down to either having more energy than others at tackling a problem they thought was more trouble than it was worth, or just bringing back random knowledge from previous jobs or self study, and being able to apply it to the problem at hand. From my personal experience, a few times I have worked in the "low latency" area of computer science. (Before anybody gets too excited on HN, I am talking about around 100ms per transaction, so the FPGA crowd can ignore my comments! I always say: If you ask 10 programmers what is the definition [limit] of low latency, you will get 10 different answers.) There are many, many programming strategies for low latency that are undocumented in public literature. The only way to discover them is from an existing project or teammate or trial-and-error. I would extend this thought/opinion to massively(?) multi-threaded systems.