> 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.
I’m curious now, what areas of computer science (as opposed to copy paste react development) consider 100ms low latency? Were you working with very big writes? Very old storage?
No, sorry, didn’t mean to come across rude. I wasn’t arguing, I trust that for whatever you were working on, that was indeed low latency and take your word for it. I just can’t think of what field or general area of computing you’re talking about and I’m curious to read up on something I’m unfamiliar with.
