by 𝒟αήielle (ĀFK.) Ālex. Foήg *Khαῄ Solo* ∆天方鄺芳象形天!!!
alt. he-is-en-thought, as in, he is in thought, don’t disturb him… (thanks to Marc Chung @heisenthought)
1. A thought subject to mental collapse triggered by interruption.
2. A mental event or sequence characterized by coexistence of loosely related, sometimes contradictory, sets of knowledge or tasks. Highly dispersed in knowledge space, though it may support well defined momentum. Apt to tunnel through imposing technical or energetic barriers.
Collapse triggered upon the observation of the state of current knowledge by a third party. During the beginning states of observation, keen thinkers engage in a mad scramble to save mindstate, which may at some later time be partially reloaded. Status reports are heisenthought’s natural predator. Occasionally, members of a team will spontaneously ‘go dark’, in an attempt to think through some difficult problem — sometimes the only strategy which will work to extricate oneself from local extrema in solutionspace.1,2 Caution should be taken when observing said people, as doing so will both collapse their progress into a single, likely suboptimal path, and be likely misinterpreted as disloyalty, hubris or laziness, since they have disengaged from discussion with no apparent progress.
3. A mental event or sequence characterized by firmly specified and demarcated generating bodies of knowledge, and ill discernible forward movement. Induced by overspecification of problem, method, or solution. Collapse upon observation of current direction of progress by a third party. “‘Are we moving forward on this?’ ‘The heisenthought collapsed; we’re moving, just not in the right direction…'”
4. A coherent collection of thoughts sufficiently isolated from random outside influence. Obeys the relation Δknowledge Δmomentum ≥ ħ/2.
5. A tongue-in-cheek term invented to cast off workplace ‘pings’, ‘check-ins’, ‘status-reports’ and ‘how’s it goings?’.
Max discusses how he went dark for a year, and came up with the something that really mattered — a way to fight fraud.
We had this merger with a company called X.com. It was a bit of a tough merger because the companies were really competitive—we were two large competitors in the same market. For a while, Peter took some time off. The guy who ran X.com became the CEO, and I remained the CTO. He was really into Windows, and I was really into Unix. So there was this bad blood for a while between the engineering teams. He was convinced that Windows was where it’s at and that we have to switch to Windows, but the platform that we used was, I thought, built really well and I wanted to keep it. I wanted to stay on Unix. […]
I had this intern that I hired before the merger, and we thought, “We built all these cool Unix projects, but it’s kind of pointless now because they are going to scrap the platform. We might as well do something else.” So he and I decided we were going to find ourselves fun projects. […]
It was me acting out, but it was kind of a low time for me because I was not happy with the way we were going. Part of having a CEO is that you can respectfully disagree, but you can resign if you don’t like it that much. But then eventually I became interested in the economics of PayPal and trying to see what’s going on in the back end, because I was getting distracted from code and technology. I realized that we were losing a lot more money in fraud than I thought we were. It was still early 2001. If you looked at the actual loss rates, they were fairly low. You could see that we were losing money, but, given the growth of the system and the growth of the fraud, fraud was not that big of a problem. It was less than 1 percent—it was really low. But then, if you looked at the rate of growth of fraud, you could see that, if you don’t stop it, it would become 5 percent, 10 percent of the system, which would have been prohibitive.
So I started freaking out over it, and this intern and I wrote all sorts of packages— very statistical stuff—to analyze “How did it happen; how do we lose money?” By the end of the summer, we thought, “The world is going to end any minute now.” It was obvious that we were really losing tons of money. By midsummer, it was already on a $10 million range per month and just very scary.
 – Blake discusses how, by necessity, they closed up the source and process during the early stages of work on Firefox.
Phoenix was basically a fork of the Mozilla code base that we controlled. We closed off access to the code, because we felt it was impossible to create anything consumer-oriented when you had a thousand Netscape people in search of revenue and a thousand open source geeks who shunned big business trying to reach consensus. We just wanted to close it off and do what we thought was the right thing. We went through a couple name changes, Mozilla offered us more support, and that’s kind of how it all got started.
Thanks to Marc Chung and Joel Muzzerall for reading drafts of this.