X-COM seemed to come out of nowhere. Its re­lease was not pre­ceded by an enor­mous mar­ket­ing cam­paign with an enor­mous amount of hype. It had no video demo play­ing in the front win­dow of Babbages, it was­n’t ad­ver­tised twelve months in ad­vance on glossy fold­out mag­a­zine in­serts, it had no flash­ing point-of-pur­chase kiosks. It did­n’t come in a box de­signed by origamists from the school of ab­stract ex­pres­sion­ism. It fea­tured no full-mo­tion video star­ring the best TV ac­tors of the 80s; it had no voice-overs. It of­fered nei­ther Super VGA graph­ics, nor General MIDI sup­port. It was­n’t Doom-like, Myst-like, or oth­er­wise like a hit game from the pre­vi­ous sea­son; it did­n’t steal the best fea­tures from sev­eral other suc­cess­ful games. It was­n’t even on a CD-ROM!

In short, if you plugged X-COM’s vari­ables into the “success for­mula” cur­rently in use by the ma­jor­ity of large game com­pa­nies, you’d come up with a big, fat goose egg. According to the pre­vail­ing wis­dom, there’s no way X-COM could sur­vive in to­day’s gam­ing mar­ket­place. And yet it sold and sold, and gamers played on and on.

— Chris Lombardi, writ­ing in the April 1995 is­sue of Computer Gaming World

In the early days of game de­vel­op­ment, there ex­isted lit­tle to no sep­a­ra­tion be­tween the roles of game pro­gram­mer and game de­signer. Those stal­wart pi­o­neers who pro­grammed the games they them­selves de­signed could be grouped into two broad cat­e­gories, de­pend­ing on the side from which they en­tered the field. There were the tech­nol­o­gists, who were fas­ci­nated first and fore­most with the in­ner work­ings of com­put­ers, and chose games as the most chal­leng­ing, cre­atively sat­is­fy­ing type of soft­ware to which they could ap­ply their tal­ents. And then there were those who loved games them­selves above all else, and learned to pro­gram com­put­ers strictly in or­der to make bet­ter, more ex­cit­ing ones than could be im­ple­mented us­ing only pa­per, card­board, and the play­ers’ imag­i­na­tions. Julian Gollop, the mas­ter­mind be­hind the leg­endary orig­i­nal X-COM, fell most def­i­nitely into this lat­ter cat­e­gory. He turned to the com­puter only when the games he wanted to make left him no other choice.

Growing up in the English county of Essex, Julian and his younger brother Nick lived sur­rounded by games, cour­tesy of their fa­ther. “Every Christmas, we did­n’t watch TV, we’d play games end­lessly,” Julian says. From Cluedo, they pro­gressed to Escape from Colditz, then on to the likes of Sniper! and Squad Leader.

Julian turned fif­teen in 1980, the year that the Sinclair ZX80 ar­rived to set off a mi­cro­com­puter fever all across Britain, but he was ini­tially im­mune to the af­flic­tion. Unimpressed by the sim­plis­tic games he saw be­ing im­ple­mented on those early ma­chines, which of­ten had as lit­tle as 1 K of mem­ory, he started mak­ing his own de­signs to be played the old-fash­ioned way, face-to-face around a table­top. It was only when he hit a wall of com­plex­ity with one of them that he re­assessed the po­ten­tial of com­put­ers.

The game in ques­tion was called Time Lords; as the name would im­ply, it was based on the Doctor Who tele­vi­sion se­ri­als. It asked two to five play­ers to travel through time and space and al­ter the course of his­tory to their ad­van­tage, but grew so com­plex that it came to re­quire an ad­di­tional per­son to serve in the less-than-re­ward­ing ca­pac­ity of ref­eree.

By this point, it was 1982, and a friend of Julian’s named Andy Greene had ac­quired one of the first BBC Micros. Its rel­a­tively cav­ernous 32 K of mem­ory opened up the pos­si­bil­ity of us­ing the com­puter as a ref­eree in­stead of a bored hu­man. Greene coded up the pro­gram in BASIC, stay­ing faith­ful to Julian’s board game to the ex­tent of de­mand­ing that play­ers leave the room when it was­n’t their turn, so as not to see any­thing they weren’t sup­posed to of their op­po­nents’ ac­tions. The owner of the table­top-games store where Julian shopped was so im­pressed with the re­sult that he founded a new com­pany, Red Shift Games, in or­der to pub­lish it. They all trav­eled to com­puter fairs to­gether, car­ry­ing copies of the com­put­er­ized Time Lords packaged in Ziploc bag­gies. The game did­n’t take the world by storm — Personal Computer News, one of the few pub­li­ca­tions to re­view it, pro­nounced it a “bored game” in­stead of a board game — but it was a start.

The two friends next made Islandia, an­other mul­ti­player strat­egy game of a sim­i­lar stripe. In the mean­time, Julian ac­quired a Sinclair Spectrum, the cheap and cheer­ful lit­tle ma­chine des­tined to drive British com­puter gam­ing for the next half-decade. Having now a strong mo­ti­va­tion to learn to pro­gram it, Julian did just that. His first self-coded game, and his first on the Spectrum, ap­peared in 1984 in the form of Nebula, a con­quer-the-galaxy ex­er­cise that for the first time of­fered a com­puter op­po­nent to play against.

The ar­ti­fi­cial in­tel­li­gence dis­ap­peared again from his next game, but it mat­tered not at all. Rebelstar Raiders was the pro­to­type for Julian Gollop’s most fa­mous work. In con­trast to the big-pic­ture strat­egy of his ear­lier games, it honed in on in­di­vid­ual sol­diers in con­flict with one an­other in a Starship Troopers-like sci­ence-fic­tional mi­lieu. Still, it was very much based on the board games he loved; there was a lot of Sniper! and Squad Leader in its turn-based de­sign. Despite be­ing such a cere­bral game, de­spite be­ing one that you could­n’t even play with­out a mate to hand, it at­tracted con­sid­er­able at­ten­tion. Red Shift faded out of ex­is­tence shortly there­after as its owner lost in­ter­est in the en­deavor, but Rebelstar Raiders had al­ready made Julian’s rep­u­ta­tion, such that other pub­lish­ers were now knock­ing at his door.

It must have been a thrill for Julian Gollop the board-game fa­natic when Games Workshop, the lead­ing British pub­lisher of hob­by­ist table­top games, signed him to make a com­puter game for their new — if ul­ti­mately brief-lived — dig­i­tal di­vi­sion. Chaos, a spell-sling­ing fan­tasy free-for-all iron­i­cally based to some ex­tent on a Games Workshop board game known as Warlock — not that Julian told them that! — did­n’t sell as well as Rebelstar Raiders, al­though it has since be­come some­thing of a cult clas­sic.

So, un­der­stand­ably, Julian went where the mar­ket was. Between 1986 and 1988, he pro­duced three more it­er­a­tions on the Rebelstar Raiders con­cept, each boast­ing com­puter op­po­nents as well as mul­ti­player op­tions and each elab­o­rat­ing fur­ther upon the foun­da­tion of its pre­de­ces­sor. Game de­sign­ers are a bit like au­thors in some ways. Some au­thors — like, say, Margaret Atwood — try their hands at a wide va­ri­ety of gen­res and ap­proaches, while oth­ers — like, say, John Cheever — com­pul­sively sift through the same ma­te­r­ial in search of new nuggets of in­sight. Julian be­came, in the minds of the British pub­lic at least, an ex­am­ple of the Cheever type of de­signer. “It could be said by the cru­elest among us that Julian has only ever writ­ten one game,” wrote the mag­a­zine New Computer Express in 1990, “but has re­leased var­i­ous sub­stan­tially en­hanced ver­sions of it over the years.”

Of those en­hanced ver­sions, Julian pub­lished Rebelstar and Rebelstar 2: Alien Encounter through Firebird as a lone-wolf de­vel­oper, then pub­lished Laser Squad through a small out­fit known as Blaze Software. Before he made this last game, he founded a com­pany called Target Games — soon to be re­named to the less generic Mythos Games — with his fa­ther as silent part­ner and his brother Nick in an ac­tive role; the lat­ter had by now be­come an ac­com­plished pro­gram­mer in his own right, in fact sur­pass­ing Julian’s tal­ents in that area. In 1990, the broth­ers made the Chaos se­quel Lords of Chaos to­gether in or­der to prove to the likes of New Computer Express that Julian was at least a two-trick pony. And then came the se­ries of events that would lead to Julian Gollop, whose games were rea­son­ably pop­u­lar in Britain but vir­tu­ally un­known else­where, be­com­ing one of the ac­knowl­edged lead­ing lights of strat­egy gam­ing all over the world.

The road to X-COM trav­eled through the ter­rain of hap­pen­stance rather than any mas­ter plan. Julian’s ca­reer-defin­ing pro­ject started as Laser Squad 2 in spirit and even in name, the next man­i­fes­ta­tion of his on­go­ing ob­ses­sion with small-scale, turn-based, sin­gle-unit tac­tics. The big leap for­ward this time was to be an iso­met­ric view­point, adding an el­e­ment of depth to the bat­tle­field. He and Nick coded a proof of con­cept on an Atari ST. While they were do­ing so, Blaze Software dis­ap­peared, yet an­other ephemeral en­tity in a volatile in­dus­try. Now, the broth­ers needed a new pub­lisher for their lat­est game.

Both of them had been play­ing hours and hours of Railroad Tycoon, from the American pub­lisher MicroProse. Knowing that MicroProse had a British branch, they de­cided to take their demo there first. It was a bold move in its way; as I’ve al­ready noted, their games were pop­u­lar in their sphere, but had mostly borne the im­prints of smaller pub­lish­ers and had mostly been sold at cheaper price points. MicroProse was a dif­fer­ent an­i­mal en­tirely, car­ry­ing with it the ca­chet that still clung in Europe to American games, with their big­ger bud­gets and higher pro­duc­tion val­ues. In their quiet English way, the Gollops were mak­ing a bid for the big leagues.

Luckily for them, MicroProse’s British of­fice was far more than just a for­eign ad­junct to the American head­quar­ters. It was a dy­namic, cre­ative place in its own right, which took ad­van­tage of the lais­sez-faire at­ti­tude of “Wild” Bill Stealey, MicroProse’s flam­boy­ant fly-boy founder, to blaze its own trails. When the Gollops brought in the nascent Laser Squad 2, they were grat­i­fied to find that just about every­one at MicroProse UK al­ready knew of them and their games. Peter Moreland, the head of de­vel­op­ment, was cau­tiously in­ter­ested, but with plenty of caveats. For one thing, they would need to make the game on MS-DOS rather than the Atari ST in or­der to reach the American mar­ket. For an­other, a small-scale tac­ti­cal-com­bat game alone would­n’t be suf­fi­cient — would­n’t be, he said, “MicroProse enough.” After mak­ing their name in the 1980s with Wild Bill’s beloved flight sim­u­la­tors, MicroProse was be­com­ing at least as well known in this in­cip­i­ent new decade for grand-strat­egy games of or in the spirit of their star de­signer Sid Meier, like the afore­men­tioned Railroad Tycoon and the soon-to-be-re­leased Civilization. The em­pha­sis here was on the “grand.” A Laser Squad 2 just would­n’t be big enough for MicroProse.

Finally, Moreland was­n’t thrilled by all these far-fu­ture sol­diers fight­ing bat­tles in un­known re­gions of space for rea­sons that were ab­stract at best. Who could re­ally re­late to any of that? He wanted some­thing more down to earth — lit­er­ally. Maybe some­thing to do with alien vis­i­tors in UFOs… that sort of thing. Julian nod­ded along, then went home to do some re­search and re­fine his pro­posal.

He quickly learned that he was liv­ing in the midst of a fe­cund pe­riod in the pe­cu­liar field of UFOlogy. In 1989, a sketchy char­ac­ter named Bob Lazar had given an in­ter­view for a Las Vegas tele­vi­sion sta­tion in which he claimed to have been em­ployed as a civil­ian con­trac­tor at the top-se­cret Nevada mil­i­tary base known only as Area 51. In that lo­ca­tion, so he said, the American Air Force was ac­tively en­gaged in test­ing fan­tas­tic tech­nolo­gies de­rived from ex­trater­res­trial vis­i­tors. The in­ter­view would go down in his­tory as the well­spring of a whole gen­er­a­tion of starry-eyed con­spir­acy the­o­rists, whose out­landish be­liefs would soon en­ter the pop­u­lar me­dia zeit­geist via such ve­hi­cles as the tele­vi­sion se­ries The X-Files. When Julian first in­ves­ti­gated the sub­ject in 1991, how­ever, UFOs and aliens were still a fairly un­der­ground ob­ses­sion. Nevertheless, he took much from the early lore and leg­ends of Area 51, such as a sup­posed new chem­i­cal el­e­ment — called un­un­pen­tium by Lazar, elerium by the even­tual game — which pow­ered the aliens’ space­ships.

His other ma­jor source of in­spi­ra­tion was the 1970 British tele­vi­sion se­ries en­ti­tled sim­ply UFO. In fact, his game would even­tu­ally be re­leased as UFO: Enemy Unknown in Europe, cap­i­tal­iz­ing on the as­so­ci­a­tion with a show that a sur­pris­ing num­ber of peo­ple there still re­mem­bered. (I’ve cho­sen to use the American name of X-COM glob­ally in this ar­ti­cle be­cause all sub­se­quent games in the fran­chise would be known all over the world un­der that name; it has long since be­come the iconic one.) UFO the tele­vi­sion se­ries takes place in the then-near-fu­ture of 1980, when aliens are vis­it­ing the Earth in ever-in­creas­ing num­bers, ab­duct­ing hu­mans and wreak­ing more and more havoc. An in­ter­na­tional or­ga­ni­za­tion known as SHADO (“Supreme Headquarters Alien Defence Organisation”) has been formed to com­bat the men­ace. The show fol­lows the ex­ploits of the SHADO op­er­a­tives, com­plete with out­landish “futuristic” cos­tumes and sets and glo­ri­ously cheesy spe­cial ef­fects. Gollop lifted this ba­sic sce­nario and moved it to his own near-fu­ture: to the year 1999, thus man­ag­ing to nail not only his decade’s bur­geon­ing ob­ses­sion with aliens but also its un­ease about the loom­ing mil­len­nium.

The game is di­vided into two dis­tinct halves — so much so that each half is al­most lit­er­ally an en­tirely sep­a­rate game: each un­loads it­self com­pletely from mem­ory to run a sep­a­rate ex­e­cutable file at the point of tran­si­tion, caching on the hard drive be­fore do­ing so the rel­a­tively small amount of state data which its com­pan­ion needs to ac­cess.

The first part that you see is the strate­gic level. As the gen­eral in charge of the “Extra-Terrestrial Combat Force,” or X-COM — the name was sug­gested by Stephen Hand and Mike Brunton, two in-house de­sign con­sul­tants at MicroProse UK — you must hire sol­diers and buy equip­ment for them; re­search new tech­nolo­gies, a process which comes more and more to en­tail re­verse-en­gi­neer­ing cap­tured alien ar­ti­facts in or­der to use your en­e­my’s own tech­nol­ogy against them; build new bases at strate­gic lo­ca­tions around the world, as well as im­prove your ex­ist­ing ones (you start with just one mod­est base); and send your air­craft out to in­ter­cept the alien craft that are swarm­ing the Earth. In keep­ing with the time­less logic of com­puter games, the coun­tries of the Earth have cho­sen to make X-COM, the plan­et’s one real hope for de­feat­ing the alien men­ace, into a re­source-con­strained semi-cap­i­tal­ist en­ter­prise; you’ll of­ten need to sell gad­gets you’ve man­u­fac­tured or stolen from the aliens in or­der to make ends meet, and if you fail to per­form well your spon­sor­ing coun­tries will cut their fund­ing.

This half of the game was a dizzy­ing leap into un­charted ter­ri­tory for the Gollop broth­ers. Thankfully, then, they were on very fa­mil­iar ground when it came to the other half: the half that kicks in when your air­borne in­ter­cep­tors force a UFO to land, or when you man­age to catch the aliens in the act of ter­ror­iz­ing some poor city, or when the aliens them­selves at­tack one of your bases. Here you find your­self in what amounts to Laser Squad 2 in form and spirit if not in name: an ul­tra-de­tailed turn-based sin­gle-unit com­bat sim­u­la­tor, the lat­est ver­sion of a game which Julian Gollop had al­ready made four times be­fore. (Or close enough to it, at any rate: X-COM, the cul­mi­na­tion of what had be­gun with Rebelstar Raiders on the Spectrum, is iron­i­cally sin­gle-player only, whereas that first game had not just al­lowed but re­quired two hu­mans to play.) Although the strate­gic layer sounds far more com­plex than this tac­ti­cal layer — and, in­deed, it is in cer­tain ways — it’s ac­tu­ally the tac­ti­cal game where you spend the ma­jor­ity of your time, fight­ing bat­tles which can con­sume an en­tire evening each.

For all their dif­fer­ences, the two halves of the game do in­ter­lock in the end as two facets of a whole. Your re­search ef­forts, equip­ment pur­chases, and hir­ing prac­tices in the strate­gic half de­ter­mine the na­ture of the force you lead into the tac­ti­cal man-against-alien bat­tles. Less ob­vi­ously but just as sig­nif­i­cantly, your pri­mary re­ward for said bat­tles proves to be the re­cov­ery of alien equip­ment, alien corpses, and even live alien spec­i­mens (all is fair in love and geno­ci­dal in­ter­plan­e­tary war), which you cart back to your bases to place at the dis­posal of your re­search teams. And so the sym­bi­otic re­la­tion­ship con­tin­ues: your re­searchers use what you re­cover as grist for their mill, which lets you go into tougher bat­tles with bet­ter equip­ment to hand, thereby to bring back still richer spoils.

The cap­sule de­scrip­tion of the fin­ished game which I’ve just pro­vided mir­rors al­most per­fectly the pro­posal which Julian Gollop de­liv­ered to MicroProse; the de­sign would change sur­pris­ingly lit­tle in the process of de­vel­op­ment. MicroProse thought it sounded just fine as-is.

The con­tract which the Gollops signed with MicroProse spec­i­fied that the for­mer would be re­spon­si­ble for all of the de­sign and cod­ing, while the lat­ter would pro­vide the vi­sual and au­dio as­sets. MicroProse UK did hold up their end of the bar­gain, but had an oddly ca­sual at­ti­tude to­ward the pro­ject in gen­eral. Julian re­mem­bers their pro­ducer as “very laid back — he would come over once a month, we would go to the pub, talk about the game for a bit, and he would go home.” Otherwise, the Gollops worked largely alone af­ter their first rush of con­sul­ta­tions with the MicroProse mother ship had faded into the past. Time dragged on and on while they strug­gled with this mas­sively com­pli­cated game, one half of which was un­like any­thing they had ever even con­tem­plated be­fore.

As it did so, much hap­pened in the broader world of MicroProse. On the pos­i­tive side, Sid Meier’s Civilization was re­leased at the end of 1991. But de­spite this and some other suc­cess sto­ries, MicroProse’s fi­nan­cial foun­da­tion was grow­ing ever more shaky, as their am­bi­tions out­ran their core com­pe­ten­cies. The com­pany lost mil­lions on an ill-judged at­tempt to en­ter the stand-up ar­cade mar­ket, then lost mil­lions more on baroque CRPGs and flashy in­ter­ac­tiv­ity-lite ad­ven­ture games. After an IPO that was sup­posed to bail them out went badly off the rails, Wild Bill Stealey sold out in June of 1993 to Spectrum Holobyte, an­other American pub­lisher. The deal seemed to make sense: Spectrum Holobyte had a lot of money, thanks not least to gen­er­ous ven­ture cap­i­tal­ists, but a rather thin port­fo­lio of games, while MicroProse had a lot of games both out and in the pipeline but had just about run out of money.

Spectrum Holobyte sifted care­fully through their new pos­ses­sion’s pro­jects in de­vel­op­ment, pass­ing judg­ment on which were po­ten­tial win­ners and which cer­tain losers. According to Julian Gollop, Spectrum Holobyte told MicroProse UK in no un­cer­tain terms to can­cel X-COM. On the face of it, it was­n’t an un­rea­son­able point of view to take. The Gollops had been work­ing for al­most two years by this point, and still had few con­crete re­sults to show for their ef­forts. It re­ally did seem that they were hope­lessly out of their depth. Luckily for them, how­ever, Peter Moreland and oth­ers in the British of­fice still be­lieved in them. They nod­ded along with the or­der to bin X-COM, then qui­etly kept the pro­ject on the books. At this point, it did­n’t cost them much of any­thing to do so; the art was al­ready done, and now it was up to the Gollops to sink or swim with it.

X-COM bobbed up to the sur­face six months later, when the new, al­legedly joint man­age­ment team — Stealey would soon leave the com­pany, feel­ing him­self to have been thor­oughly side­lined — started cast­ing about for a game to fea­ture in Europe in the first quar­ter of 1994, thereby to make the ac­coun­tants happy. Peter Moreland piped up sheep­ishly: “You re­mem­ber that UFO pro­ject you told us to can­cel? Well, it’s ac­tu­ally still kick­ing around…” And so the Gollop broth­ers, who had been la­bor­ing un­der strangely lit­tle ex­ter­nal pres­sure for the past 26 months or so, were now or­dered to get their game done al­ready. They man­aged it, just — UFO: Enemy Unknown shipped in Europe in March of 1994 — but some of the prob­lems in the fin­ished game def­i­nitely stem from the dead­line that was so ar­bi­trar­ily im­posed from on high.

But if the game could have used a few more months in the oven, it nonethe­less shipped in bet­ter con­di­tion than many other MicroProse games had dur­ing the re­cent stretch of fi­nan­cial dif­fi­cul­ties. It gar­nered im­me­di­ate rave re­views, while its sales also re­ceived a boost from an­other source. The first episode of The X-Files had aired the pre­vi­ous September in the United States, fol­lowed by air­ings across Europe. Just like that, a game about hos­tile alien vis­i­tors seemed a lot more rel­e­vant. Indeed, the game pos­sessed much the same fore­bod­ing at­mos­phere as the show, from its muted color palette to MicroProse com­poser John Broomhall’s qui­etly malev­o­lent sound­track, which he had cre­ated in just two months in the fi­nal mad rush up to the re­lease dead­line. He could­n’t have done a bet­ter job if he’d had two years.

X-COM: UFO Defense shipped a few months later in North America, into a cul­tural zeit­geist that was if any­thing even more primed for it. Computer Gaming World, the American in­dus­try’s jour­nal of record, gave it five stars out of five, and its sales soared well into the six dig­its. As the quote that opened this ar­ti­cle at­tests, X-COM was in many ways the an­tithe­sis of what most pub­lish­ers be­lieved con­sti­tuted a hit game in the con­text of 1994. Its graph­ics were lit­tle more than func­tional; it had no full-mo­tion video, no real-time 3D ren­der­ing, no dig­i­tized voices; it fit per­fectly well on a few floppy disks, thank you very much, with no need for any new-fan­gled CD-ROM drive. And yet it sold bet­ter than the vast ma­jor­ity of those other “cutting-edge” games. Many took its suc­cess as a wel­come sign that gam­ing had­n’t yet lost its soul com­pletely — that good old-fash­ioned game­play could still trump pro­duc­tion val­ues from time to time.

The orig­i­nal X-COM‘s rep­u­ta­tion has only grown more hal­lowed in the years since its re­lease. It’s be­come a peren­nial on best-games-of-all-time lists, even ones whose au­thors weren’t yet born at the time of its re­lease. For this is a game, so we’re told, that tran­scends its ar­chaic pre­sen­ta­tion, that ab­solutely any stu­dent of game de­sign needs to play.

That’s rather ironic in that X-COM is a game that re­ally should­n’t work at all ac­cord­ing to many of the con­ven­tional rules of de­sign. For ex­am­ple, it’s one of the most fa­mous of all vi­o­la­tors of what’s be­come known as the Covert Action Rule, as for­mu­lated by Sid Meier and named af­ter one of his own less suc­cess­ful de­signs. The rule states that pac­ing is as im­por­tant in a strat­egy game as it is in any other genre, that “mini-games” which pull the player away from the over­ar­ch­ing strate­gic view need to be short and to the point, as is the case in Meier’s clas­sic Pirates!. If they drag on too long, Meier tells us, the player loses fo­cus on the big­ger pic­ture, for­gets what she’s been try­ing to ac­com­plish there, gets pulled out of that elu­sive state of “flow.”

But, as I al­ready noted, X-COM‘s tac­ti­cal bat­tles can drag on for an hour or two at a time — and no one seems be both­ered by this at all. What gives?

By way of an an­swer to that ques­tion, I would first note that the Covert Action Rule is, like vir­tu­ally all sup­pos­edly hard-and-fast rules of game de­sign, rid­dled with caveats and ex­cep­tions. (Personally, I don’t even agree that vi­o­lat­ing the yet-to-be-for­mu­lated Covert Action Rule was the worst prob­lem of Covert Action it­self.) And I would also note that X-COM does at least a cou­ple of things ex­tra­or­di­nar­ily well as com­pen­sa­tion, bet­ter than any strat­egy game that came be­fore it. Indeed, one can ar­gue that no ear­lier grand-strat­egy game even at­tempted to do these things — not, at least, to any­thing like the same ex­tent. Interestingly, both in­spired strokes are bor­rowed from other gam­ing gen­res.

The first is the in­trigu­ing mys­tery sur­round­ing the aliens, which is peeled back layer by layer as you progress. As your sci­en­tists study the equip­ment and alien corpses brought back from the bat­tle sites and in­ter­ro­gate the live aliens your sol­diers have cap­tured, you learn more and more about where your en­e­mies come from and what mo­ti­vates them to at­tack the Earth so re­lent­lessly. It does­n’t take long to reach a point where you look for­ward to the next piece of this puz­zle as ex­cit­edly as you do the next cool gun or piece of ar­mor. By the time the whole ex­pe­ri­ence cul­mi­nates in a des­per­ate at­tack on the aliens’ home base, you’re all in. Granted, a byprod­uct of this sense of un­fold­ing dis­cov­ery is that you may not feel like re­vis­it­ing the game af­ter you win; for many or most of us, this is a strat­egy game to play through once rather than over and over again. But on the other hand, con­sid­er­ing the fifty hours or more it will take you to get through it once, it’s hard to com­plain over­much about that fact. Needless to say, when you do play it for the first time you should metic­u­lously avoid spoil­ers about What Is Really Going On Here.

X-COM‘s other, even more bril­liant stroke is the sense of iden­ti­fi­ca­tion it builds be­tween you and the sol­diers you send into bat­tle. Each sol­dier has unique strengths and weak­nesses, forc­ing you to care­fully con­sider the role she plays in com­bat: a burly, fear­less char­ac­ter who can carry enough weaponry to out­fit your av­er­age pla­toon but could­n’t hit the prover­bial broad side of a barn must be han­dled in a very dif­fer­ent way from a slen­der, ner­vous sharp­shooter. As your sol­diers (hopefully) sur­vive mis­sions, their skills im­prove, CRPG-style. Thus you have plenty of prac­ti­cal rea­sons to be more loathe to lose a sea­soned vet­eran than a green­horn fresh out of ba­sic train­ing. And yet this purely zero-sum cal­cu­lus does­n’t fully ex­plain why each mis­sion is so nail-bit­ingly tense, so full of ag­o­niz­ing de­ci­sions bal­anc­ing risk against re­ward.

One of X-COM‘s most defin­ing de­sign choices is also one of its sim­plest: it lets you name each sol­dier for your­self. As you play, you form a pic­ture of each of them in your imag­i­na­tion, even though the game it­self never de­scribes any of them to you as any­thing other than a list of num­bers. Losing a sol­dier who’s been around for a while feels weirdly like los­ing a gen­uine ac­quain­tance. For here too you can’t help but em­bell­ish the thin scaf­fold­ing of fact the game pro­vides with your own story of what hap­pened: the griz­zled old-timer who went out one time too many, whose nerves just could­n’t han­dle an­other fire­fight; the fool­hardy, testos­terone-ad­dled youth who threw him­self into every bat­tle like he was in­de­struc­tible, un­til one day he was­n’t. X-COM pro­vides the mer­est glimpse of what it must feel like to be an ac­tual com­man­der in war: the over­whelm­ing stress of hav­ing the lives of oth­ers hang­ing on your de­ci­sions, the guilty sec­ond-guess­ing that in­evitably goes on when you lose some­one. It has some­thing that games all too of­ten lack: a sense of con­se­quences for your ac­tions. Theoretically at least, the best way to play it is in iron-man mode: no sav­ing and restor­ing to fix bad out­comes, dead is dead, own your de­ci­sions as com­man­der.

In one of those strange con­cor­dances that tend to crop up in many cre­ative fields, X-COM was­n’t the only strat­egy game of 1994 to bring in CRPG el­e­ments to great ef­fect. Ironically, these in­no­va­tions oc­curred just as the CRPG genre it­self was in its worst dol­drums since Ultima I and Wizadry I had first brought it to promi­nence. Today, even as the CRPG has long since re­gained its mojo as a gam­ing genre, CRPG el­e­ments have be­come the spe­cial sauce la­dled over a wide ar­ray of other types of games. X-COM was among the first to show how tasty the end re­sult could be.

I have to say, how­ever, that I find other el­e­ments of X-COM less ap­pe­tiz­ing, and that its strengths don’t quite over­come its weak­nesses in my mind suf­fi­ciently to win it a place on my per­sonal list of best games ever. My first stum­bling block is the game’s learn­ing curve, which is not just steep but un­nec­es­sar­ily so. I’d like to quote Garth Deangelis, who led the team that cre­ated XCOM: Enemy Unknown, the crit­i­cally ac­claimed fran­chise re­boot that was re­leased in 2012:

While [the orig­i­nal X-COM] may have been mag­nif­i­cent, it was also a unique beast when it came to be­gin­ning a new game. We of­ten joked that the diehards who mas­tered the game in­de­pen­dently be­longed to an elite club be­cause by to­day’s stan­dards the learn­ing curve was like climb­ing Mount Everest.

As soon as you fire up the orig­i­nal, you’re placed in a Geoscape with the Earth silently loom­ing, and var­i­ous op­tions to ex­plore within your base — in­clud­ing read­ing (unexplained) fi­nan­cial re­ports, ap­prov­ing man­u­fac­tur­ing re­quests (without any con­text as to what those would mean later on), and ex­am­in­ing a blue­print (which hinted at the pos­si­bil­ity for base ex­pan­sion), for ex­am­ple — the player is given no di­rec­tion.

Even go­ing on your first com­bat mis­sion can be a bit of a mys­tery (and when you first step off the Skyranger, the game will kill off a few of your sol­diers be­fore you even see your first alien — wel­come to X-COM!).

There’s cer­tainly a place for com­plex games, and com­plex­ity will al­ways come com­plete with a learn­ing curve of some sort. But, again, X-COM‘s curve is just un­nec­es­sar­ily steep. Consider: when you be­gin a new game, you have two in­ter­cep­tors al­ready in your hangar for bring­ing down UFOs. Fair enough. Unfortunately, they come equipped with sub-op­ti­mal Stingray mis­siles and bor­der­line-use­less can­non. So, one of the first tasks of the ex­pe­ri­enced player be­comes to req­ui­si­tion some more ad­vanced Avalanche mis­siles, put them on her in­ter­cep­tors, and sell off the old junk. Why can the game not just start you off with a rea­son­able weapons load-out? A sim­i­lar ques­tion ap­plies to the equip­ment car­ried by your in­di­vid­ual sol­diers, as it does to the well-nigh in­de­fen­si­ble lay­out of your start­ing base it­self, which makes it guar­an­teed to fall to the first squad of ma­raud­ing aliens who come call­ing. The new player is likely to as­sume, rea­son­ably enough, that the de­ci­sions the game has al­ready made for her are good ones. She finds out oth­er­wise only by be­ing kicked in the teeth as a re­sult of them. This is not good game de­sign. The im­pres­sion cre­ated is of a game that is not tough but fair, but rather ac­tively out to get her.

You’ll never use a large swath of the sub­par weapons and equip­ment in­cluded in X-COM, which rather begs the ques­tions what they’re do­ing in there. The game could have prof­ited greatly from an ed­i­tor em­pow­ered to pare back all of this ex­tra­ne­ous non­sense and hone in on its core ap­peal. Likewise, the user in­ter­face in the strate­gic por­tion op­er­ates on the prin­ci­ple that, if one mouse click is good, ten must be that much bet­ter; every­thing is way more con­vo­luted than it needs to be. Just buy­ing and sell­ing equip­ment is ag­o­niz­ing.

The tac­ti­cal game’s in­ter­face is also daunt­ingly com­plex, but does have some­what more method to its mad­ness, be­ing the ben­e­fi­ciary of all of Julian Gollop’s ear­lier ex­pe­ri­ence with this sort of game. Still, even tac­ti­cal com­bat, so widely and justly lauded as the beat­ing heart of X-COM, is not with­out its frus­tra­tions. Certainly every X-COM player is all too fa­mil­iar with the last-alien-on-the-map syn­drome, where you some­times have to spend fif­teen or twenty min­utes me­thod­i­cally hunt­ing the one re­main­ing en­emy, who’s hun­kered down in some ob­scure cor­ner some­where. The na­ture of the game is such that you can’t re­lax even in these sit­u­a­tions; get­ting care­less can still get one or more of your pre­cious sol­diers killed be­fore you even re­al­ize what’s hap­pen­ing. But, al­though per­haps a re­al­is­tic de­pic­tion of war, this part of the game just is­n’t much fun. The prob­lem is frus­trat­ing not least be­cause it’s so eas­ily sol­u­ble: just have the re­main­ing aliens com­mit sui­cide to avoid cap­ture — some­thing en­tirely in keep­ing with their na­ture — when their num­bers get too de­pleted.

All of these nig­gling prob­lems mark X-COM as the kind of game I have to rant about here all too of­ten: the kind that was never ac­tu­ally played be­fore its re­lease. For all its ex­tended de­vel­op­ment time, it still needed a few more months filled with play-test­ing and pol­ish­ing to reach its full po­ten­tial. X-COM‘s most in­fa­mous bug serves as a re­minder of just how lit­tle of ei­ther it got: its dif­fi­culty lev­els are bro­ken. If you se­lect some­thing other than the “beginner” dif­fi­culty, it re­verts back to the eas­i­est level af­ter the first com­bat mis­sion. In one sense, this is a bless­ing: the be­gin­ner dif­fi­culty is more than dif­fi­cult enough for the vast ma­jor­ity of play­ers. On the other, though… how the heck could some­thing as ba­sic as that be over­looked? There’s only one way that I can see: if you barely played the game at all be­fore you put it in a box and shipped it out the door.

To his credit, Julian Gollop him­self is well aware of these is­sues and freely ac­knowl­edges them — does so much more freely in fact than some of his game’s biggest fans. He notes the in­flu­ence of vin­tage Avalon Hill and SPI board games, some of which were so de­mand­ing that just be­ing able to play them at all — never mind play­ing them well — was an odd sort of badge of honor for the grog­nards of the 1970s and early 1980s. He would ap­pear to agree with me that there’s a bit too much of their style of com­plex­ity-for-its-own-sake in X-COM:

I be­lieve that a good game may have rel­a­tively sim­ple rules, but have com­plex sit­u­a­tions arise from them. Strategy games tend to do that very well, you know — even the sim­plest ones are very good at that. I think it’s pos­si­ble to have an ac­ces­si­ble game which does­n’t have amaz­ingly com­plex rules, but still has a kind of emerg­ing com­plex­ity within what hap­pens — you know, what play­ers do, what play­ers ex­plore. For me, that’s the Holy Grail of game de­sign. So, I don’t think that I would prob­a­bly go back to mak­ing games as com­plex as [X-COM].

Like po­ets, game de­sign­ers of­ten sim­plify their work as they age, the bet­ter to cap­ture the real essence of what they’re try­ing to ex­press.

But what­ever their fi­nal eval­u­a­tion of the first game, most play­ers then and now would agree that few fran­chises have been as thor­oughly botched by their trustees as X-COM was af­ter­ward. When the first X-COM be­came an out-of-left-field hit, MicroProse UK, who had great need of hits at the time to im­press the Spectrum Holobyte brass, wanted the Gollops to pro­vide a se­quel within a year. Knowing that that amount of time would al­low them to do lit­tle more than re­skin the ex­ist­ing en­gine, they worked out a deal: they would give their pub­lisher their source code and let them make a quickie se­quel in-house, while they them­selves de­vel­oped a more am­bi­tious se­quel for later re­lease.

The in-house MicroProse pro­ject be­came 1995’s X-COM: Terror from the Deep, which posited that, forty years af­ter their de­feat at the end of the first game, the aliens have re­turned to try again. The wrin­kle this time is that they’ve set up bases un­der the Earth’s oceans, which you must at­tack and erad­i­cate. Unfortunately, Terror from the Deep does lit­tle to cor­rect the orig­i­nal’s prob­lems; if any­thing, it makes them worse. Most no­tably, it’s an even more dif­fi­cult game than its pre­de­ces­sor, a de­ci­sion that’s hard to un­der­stand on any level. Was any­one re­ally com­plain­ing that X-COM was too easy? All in all, Terror from the Deep is ex­actly the unimag­i­na­tive quickie se­quel which the Gollops weren’t ex­cited about hav­ing to make.

Nevertheless, it’s ar­guably the best of the post-orig­i­nal, pre-re­boot gen­er­a­tion of X-COM games. X-COM: Apocalypse, the Gollops’ own se­quel, was a pro­ject on a vastly greater scale than the first two X-COM games, a scale to which they them­selves strug­gled to adapt. It was riven by bu­reau­cratic sna­fus and con­stant con­flict be­tween de­vel­oper and pub­lisher, and the re­sult­ing process of de­sign-by-frac­tious-com­mit­tee turned it into a game that did a lot of dif­fer­ent things — turned-based and real-time com­bat in the very same game! — but did none of them all that well, nor even looked all that good whilst do­ing them. Julian Gollop to­day calls it “the worst ex­pe­ri­ence of my en­tire ca­reer” and “a night­mare.” He and Nick cut all ties with MicroProse af­ter its 1997 re­lease.

After that, MicroProse lost the plot en­tirely, stamp­ing the X-COM la­bel onto games that had vir­tu­ally noth­ing in com­mon with the first one. X-COM: Interceptor (1998) was a space sim­u­la­tor in the mode of Wing Commander; Em@il Games: X-COM (1999) was a ca­sual mul­ti­player net­worked af­fair; X-COM: Enforcer (2001) was a mind­less shoot-em-up. This last proved to be the fi­nal straw;  the X-COM name dis­ap­peared for the next eleven years, un­til XCOM: Enemy Unknown, the re­boot by Firaxis Games.

If you ask me, said re­boot is in ab­solute terms a bet­ter game than the orig­i­nal, pick­ing up on al­most all of its con­sid­er­able strengths while elim­i­nat­ing most of its weak­nesses. But it can­not, of course, lay claim to the same im­por­tance in the his­tory of gam­ing. Despite its flaws, the orig­i­nal X-COM taught de­sign­ers to per­son­al­ize strat­egy games, showed them how to raise the emo­tional stakes in a genre pre­vi­ously as­so­ci­ated only with cool cal­cu­la­tion. For that rea­son, it richly de­serves its rep­u­ta­tion as one of the most im­por­tant games of its era.

(Sources: the book Grand Thieves and Tomb Raiders: How British Video Games Conquered the World by Magnus Anderson and Rebecca Levene; Amstrad Action of October 1989; Computer Gaming World of August 1994, September 1994, April 1995, and July 1995; Crash of Christmas 1988 and May 1989; Game Developer of April 2013; Retro Gamer 13, 68, 81, 104, 106, 112, and 124; Amiga Format of December 1989, June 1994, and November 1994; Amiga Format of December 1989, June 1994, and November 1994; Computer and Video Games of December 1988; Games TM 46; New Computer Express of September 15 1990; Games Machine of July 1988; Your Sinclair of August 1990 and September 1990; Personal Computer News of July 21 1983. Online sources in­clude Julian Gollop’s X-COM post­mortem from the 2013 Game Developers Conference, “The Story of X-COM at EuroGamer, and David Jenkins’s in­ter­view with Julian Gollop at Metro.

The orig­i­nal X-COM is avail­able for dig­i­tal pur­chase at GOG.com, as are most of the other X-COM games men­tioned in this ar­ti­cle.)

My least fa­vorite Rust type is std::ops::Range.

Range is a foun­da­tional type, with magic syn­tax but a sim­ple de­f­i­n­i­tion:

Idx is typ­i­cally an in­te­gral type, but you can make a Range of any­thing, which will be­come im­por­tant later. Here’s a range of Unit:

What’s wrong with Range? This will be a cri­tique on Rust’s own terms.

Any Rust tu­to­r­ial will cover bor­row­ing, life­times, own­er­ship, etc. You think you un­der­stand, then this:

You need the bor­row be­cause you can’t like, OWN a num­ber, man!

Heh, no, it’s be­cause, what if you wanted to make a Range in­stead:

Range re­quires the bor­row, so the vastly more com­mon Range etc. forces it as well.

We’re not done pick­ing on the bor­row checker. Range makes you clone even when there’s no own­er­ship trans­fer:

Range could be Copy, but some Ranges are also it­er­a­tors and you might copy one by mis­take:

so Ranges which are not used as it­er­a­tors (many can­not be, like Range or Range) pay the price, and so does any type which em­beds a Range.

This is abus­ing the bor­row checker as a bad lin­ter. Range un­der­mines the story of life­times and own­er­ship, mak­ing the bor­row checker feel ar­bi­trary.

Rust will hap­pily con­struct a back­wards Range, which ends be­fore it starts:

Is this back­wards range valid? Its len() is 0, it con­tains() noth­ing, it yields noth­ing as an it­er­a­tor. But if you try to use it to in­dex into a slice, you get a panic! So it looks valid but is primed to ex­plode!

This is be­cause - again - you can make a Range of any­thing. If you try to en­force that start dyn Error can’t be in­valid, so a Range of int never gets to be.

A prac­ti­cal prob­lem is writ­ing cor­rect bounds checks. For ex­am­ple, con­sider the get_unchecked func­tion on slice - it says “an out-of-bounds in­dex is un­de­fined be­hav­ior” but never de­fines what out of bounds means. So how does one even call this func­tion safely?

Restated: a Range with start 0 and length 0 may be out of bounds. That’s wild.

A regex en­gine (here’s one) of­ten deals in ranges of char, for ex­am­ple /[a-z]/. Should it use Range?

No! The foot­gun is /[\u10FFFF]/, which is the largest char. Range can­not rep­re­sent this value, even though it has the bits to do so.

Is RangeInclusive a bet­ter choice? This uses an ad­di­tional bool field to mean…stuff, and it needs to be sep­a­rately checked in sev­eral places. This is a silly ex­pen­sive rep­re­sen­ta­tion, push­ing RangeInclusive to 12 bytes even though it would fit in 8, with bits to spare. Not a good choice for a perf-sen­si­tive regex al­go­rithm.

The prob­lem is Range is over­loaded: it’s too flex­i­ble, it wants to be every­thing.

* You can make silly Ranges out of any­thing

These goals are in ten­sion, and it meets none of them well.

Perhaps it’s too late and we must live with this wart, but a recipe for a dif­fer­ent ap­proach:

Limit Range to Copy + PartialOrd types. There may be oc­ca­sional uses for Range or Range, but it’s not worth forc­ing bor­row­ing for the com­mon case.

Now that Range al­ways knows how to com­pare its ends, en­force that start at con­struc­tion time. For Ranges con­structed from con­stants, this will be free. This avoids the “looks valid, ac­tu­ally ex­plodes” prob­lem and will un­lock fur­ther op­ti­miza­tions:

Range::is_empty() could be writ­ten nat­u­rally in­stead of a a bizarre way just for NaNs

[T]::get() would need to branch once, not twice

Range::len() could just be a sub and not re­quire a branch

Give Range an iter() method, like other col­lec­tions have. Now Range is not an Iterator, just like Vec is not an Iterator, and Range can be eas­ily made Copy. This does mean writ­ing for n in (1..10).iter(), but Rust al­ready re­quires that for col­lec­tions, so it’s more con­sis­tent.

Now that Range is not an Iterator, RangeInclusive can drop its ex­tra bool. It would sim­ply be a pair of in­dexes, and could not be empty (that’s what Swift does).

Firefox in­cludes a built-in PDF viewer to dis­play PDF files in­side the browser win­dow. This ar­ti­cle ex­plains how to use the built-in PDF viewer, how to fix the com­mon is­sues you might en­counter, and how to use an­other PDF viewer.

Firefox in­cludes a built-in PDF viewer that al­lows you to view al­most all PDF files found on the web with­out an ex­ter­nal ap­pli­ca­tion (exceptions to this are PDF files with a MIME type in­cor­rectly set). This built-in PDF viewer is en­abled by de­fault. When you click on a link to a PDF file or open it from the Firefox Downloads panel, it will be ren­dered with the built-in pdf viewer.

Some PDFs files have in­ter­ac­tive fields to fill in data (such as on forms). Using Firefox’s built-in PDF viewer you can fill out fields such as text, check boxes and ra­dio but­tons. After en­ter­ing data into these fields you can down­load the file to have the filled out ver­sion saved to your com­puter.

* View doc­u­ment thumb­nails or out­line: The slider but­ton on the far left will open a side­bar with thumb­nails of the doc­u­men­t’s pages. Some doc­u­ments will also have an out­line view avail­able. These make it easy to nav­i­gate through a long doc­u­ment.

* Page up and down or skip di­rectly to a page: You can use the up and down ar­rows to page through a doc­u­ment or en­ter the num­ber of the page you want to go to.

* Change the size of the doc­u­ment: Use the + and - but­tons to zoom in and out or choose a zoom set­ting from the drop­down menu.

* Fullscreen or Presentation mode: Click the fullscreen but­ton to al­low the PDF file to take over your en­tire screen. Press to exit fullscreen mode.

* Print: Click the Printer but­ton to open the print setup di­a­log.

* Download: Click the Download but­ton to save the PDF file to your com­puter or to open it with a PDF reader pro­gram.

* Copy cur­rent view: Hold down the key while you click

the cur­rent view but­ton to open the cur­rent view in an­other tab or win­dow.

* With cer­tain types of PDF files, the PDF Viewer may have prob­lems dis­play­ing fonts, col­ors or the whole doc­u­ment. If some PDF files don’t ren­der well or are blank, click the down­load but­ton on the right side of the doc­u­ment header to open it with the de­fault PDF viewer ap­pli­ca­tion on your com­puter.

* If you can’t open any PDF files with the built-in PDF viewer, a Firefox ex­ten­sion could be the cause. You can dis­able all of your ex­ten­sions, to see if one of them was the prob­lem. For de­tails, see Troubleshoot ex­ten­sions, themes and hard­ware ac­cel­er­a­tion is­sues to solve com­mon Firefox prob­lems.

You can also use a dif­fer­ent third party PDF viewer in­stead of Firefox’s built-in PDF viewer. To change from us­ing the built-in PDF viewer to an­other PDF viewer:

In the panel, go down to the Applications sec­tion.

Find Portable Document Format (PDF) in the list and click on the en­try to se­lect it.

Click on the ar­row un­der the Action col­umn for the above en­try and se­lect the PDF viewer you wish to use from the drop-down menu.

Set Firefox to ask you what to do with PDF files

If you want Firefox to al­ways ask you what to do with PDF files, fol­low the above steps to change the ac­tion for the Portable Document Format (PDF) en­try, ex­cept se­lect Always ask from the drop-down menu. The next time you click on a link to down­load a PDF file, Firefox will show you a prompt ask­ing what to do with the file. You can then choose to open it with Firefox’s built-in PDF viewer, open it with a dif­fer­ent PDF ap­pli­ca­tion, or you can choose to save the file.

For more in­for­ma­tion, see Change what Firefox does when you click on or down­load a file.

You can choose to have Firefox’s built-in PDF viewer as the de­fault for view­ing PDFs in the browser but open down­loaded PDF files with a third party tool. To open a PDF file you down­loaded in Firefox, us­ing a third party viewer:

Open the Downloads panel by click­ing the

down­load icon next to the ad­dress bar.

Right-click on the file folder icon

of the PDF file and se­lect Hold down the key while you click (two fin­ger click) the mag­ni­fy­ing glass icon

of the PDF file and se­lect

Then in the Downloads folder, on the file and se­lect and choose your fa­vorite PDF viewer.

Postgres 13 is al­most here. It’s been in beta since May, and the gen­eral avail­abil­ity re­lease is com­ing any day. We’ve been fol­low­ing Postgres 13 closely here at pg­an­a­lyze, and have been run­ning the beta in one of our stag­ing en­vi­ron­ments for sev­eral months now.

There are no big new fea­tures in Postgres 13, but there are a lot of small but im­por­tant in­cre­men­tal im­prove­ments. Let’s take a look.

Postgres 13 per­for­mance im­prove­ments in­clude both built-in op­ti­miza­tions and heuris­tics that will make your data­base run bet­ter out of the box, as well as ad­di­tional fea­tures to give you more flex­i­bil­ity in op­ti­miz­ing your schema and queries.

Postgres 13 in­tro­duces a way for B-Tree in­dexes to avoid stor­ing du­pli­cate en­tries in some sit­u­a­tions. In gen­eral, a B-Tree in­dex con­sists of a tree of in­dexed val­ues, with each leaf node point­ing to a par­tic­u­lar row ver­sion. Because each leaf points to one row ver­sion, if you are in­dex­ing non-unique val­ues, those val­ues need to be re­peated.

The de-du­pli­ca­tion mech­a­nism avoids that by hav­ing a leaf node point to sev­eral row ver­sions if pos­si­ble, which leads to smaller in­dexes.

Here is an ex­am­ple from our own pg­an­a­lyze ap­pli­ca­tion schema: We have a queries table to track all the queries we mon­i­tor, and a data­base_id field to track which data­base they be­long to. We in­dex data­base_id (so we can quickly fetch queries for a spe­cific data­base), and be­cause each data­base typ­i­cally has more than one query, there is a lot of du­pli­ca­tion in this in­dex.

New B-Tree in­dexes in Postgres 13 use the dedu­pli­ca­tion fea­ture by de­fault, but if for some rea­son, you need to turn it off, you can con­trol it with the dedu­pli­cate_items stor­age pa­ra­me­ter. Here we cre­ate the same in­dex in two dif­fer­ent ways, with dedu­pli­ca­tion ex­plic­itly on and off (though again, you don’t need to spec­ify on—this is the de­fault):

With dedu­pli­ca­tion, the new in­dex is more than three times smaller! Smaller in­dexes are faster to load from disk, and take up less space in mem­ory, mean­ing there’s more room for your data.

One in­ter­est­ing note here is that the in­dex en­tries point to row ver­sions (as in, a row the way it ex­ists in one spe­cific MVCC state), not rows them­selves, so this fea­ture can im­prove in­dex size even for unique in­dexes, where one would not ex­pect any du­pli­ca­tion to oc­cur.

Note that dedu­pli­ca­tion is not pos­si­ble in all cases (see above link for de­tails), and that you will need to rein­dex be­fore you can take ad­van­tage of it if up­grad­ing via pg_up­grade.

Postgres 10 in­tro­duced the con­cept of ex­tended sta­tis­tics. Postgres keeps some sta­tis­tics about the “shape” of your data to en­sure it can plan queries ef­fi­ciently, but the sta­tis­tics kept by de­fault can­not track things like in­ter-col­umn de­pen­den­cies. Extended sta­tis­tics were in­tro­duced to ad­dress that: These are data­base ob­jects (like in­dexes) that you cre­ate man­u­ally with

CREATE STATISTICS to give the query plan­ner more in­for­ma­tion for more spe­cific sit­u­a­tions. These would be ex­pen­sive for Postgres to de­ter­mine au­to­mat­i­cally, but armed with an un­der­stand­ing of the se­man­tics of your schema, you can pro­vide that ad­di­tional info. Used care­fully, this can lead to

mas­sive per­for­mance im­prove­ments.

Postgres 13 brings a num­ber of small but im­por­tant im­prove­ments to ex­tended sta­tis­tics, in­clud­ing sup­port for us­ing them with OR clauses and in IN/ANY con­stant lists, al­low­ing con­sid­er­a­tion of mul­ti­ple ex­tended sta­tis­tics ob­jects in plan­ning a query, and sup­port for

set­ting a sta­tis­tics tar­get for ex­tended sta­tis­tics:

Like with the reg­u­lar sta­tis­tics tar­get, this is a trade-off be­tween ad­di­tional plan­ning time (and longer ANALYZE runs), ver­sus hav­ing more pre­cise plans. We rec­om­mend us­ing this in a tar­geted man­ner us­ing EXPLAIN plans to con­firm plan changes.

Postgres multi-ver­sion con­cur­rency con­trol means you need to run VACUUM reg­u­larly (usually you can rely on the au­to­vac­uum process, though it may need some tun­ing). In Postgres 13, one no­table im­prove­ment is that mul­ti­ple in­dexes for a sin­gle table can be vac­u­umed in par­al­lel. This can lead to big per­for­mance im­prove­ments in VACUUM work. Parallel VACUUM is the de­fault and can be con­trolled with the PARALLEL op­tion:

Parallel VACUUM oc­curs when the fol­low­ing is true:

* Sufficient par­al­lel work­ers are avail­able, based on the sys­tem-wide limit set by max_­par­al­lel_­main­te­nance_­work­ers (defaults to 2)

* There are mul­ti­ple in­dexes on the table (one in­dex can be processed by one worker at a time)

* Index types sup­port it (all built-in in­dex types sup­port par­al­lelism to some ex­tent)

* The in­dexes are large enough to ex­ceed min_­par­al­lel_in­dex_s­can_­size (defaults to 512 kB)

Be aware that par­al­lel VACUUM is cur­rently not sup­ported for au­to­vac­uum. This new fea­ture is in­tended for use in man­ual VACUUM runs that need to com­plete quickly, such as when in­suf­fi­cient au­to­vac­uum tun­ing has lead to an im­mi­nent TXID wrap­around, and you need to in­ter­vene to fix it.

On that note, an im­por­tant au­to­vac­uum im­prove­ment in Postgres 13 is that the au­to­vac­uum back­ground process can now be trig­gered by INSERT state­ments for ap­pend-only ta­bles. The main pur­pose of VACUUM is to clean up old ver­sions of up­dated and deleted rows, but it is also es­sen­tial to set pages as all-vis­i­ble for MVCC book­keep­ing. All-visible pages al­low in­dex-only scans to avoid check­ing vis­i­bil­ity sta­tus row-by-row, mak­ing them faster.

We make ex­ten­sive use of ap­pend-only ta­bles at pg­an­a­lyze for our time­series data, and this im­prove­ment will make our lives con­sid­er­ably eas­ier, avoid­ing the oc­ca­sional man­ual VACUUM run on these ta­bles. This new be­hav­ior can be con­trolled by the au­to­vac­u­um_­vac­u­um_in­sert_thresh­old and au­to­vac­u­um_­vac­u­um_in­sert_s­cale_­fac­tor vari­ables.

Sorting data is a com­mon data­base task, and Postgres has a num­ber of fea­tures to avoid un­nec­es­sary work here. For ex­am­ple, if you have a B-Tree in­dex on a col­umn, and you query your table or­dered by that col­umn, it can just scan that in­dex in or­der to get sorted data.

In Postgres 13, this is im­proved to han­dle par­tially sorted data. If you have an in­dex on (a, b) (or the data is al­ready sorted by (a, b) for an­other rea­son), and you is­sue a query to or­der by (a, b, c), Postgres un­der­stands that the in­put data is al­ready par­tially sorted, and can avoid re-sort­ing the whole dataset. This is es­pe­cially use­ful if you have a LIMIT in your query, since this can avoid even more work.

Monitoring im­prove­ments in Postgres 13 in­clude more de­tails on WAL us­age, more op­tions for log­ging your queries, and more in­for­ma­tion on query plan­ning.

The write-ahead log (WAL) en­sures your data stays con­sis­tent in the event of a crash, even mid-write. Consistency is a fun­da­men­tal prop­erty of data­bases—it en­sures your trans­ac­tion ei­ther com­mit­ted or did not com­mit; you don’t have to worry about in-be­tween states. But on a busy sys­tem, WAL writes can of­ten be a bot­tle­neck. To help di­ag­nose this, Postgres 13 in­cludes more in­for­ma­tion on WAL us­age from your queries.

EXPLAIN now sup­ports in­for­ma­tion about WAL records gen­er­ated dur­ing ex­e­cu­tion:

You can see that the WAL line in­cludes the num­ber of records gen­er­ated, the num­ber of full page im­ages (fpi), and the num­ber of WAL bytes gen­er­ated. Only non-zero val­ues are printed in the de­fault text for­mat.

This is also avail­able in pg_­s­tat_s­tate­ments. For ex­am­ple, on our stag­ing en­vi­ron­ment, here is what we ran to get the state­ment that pro­duced the most WAL records:

Like many other val­ues in pg_­s­tat_s­tate­ments, the wal_records, wal_fpi, and wal_bytes val­ues here are cu­mu­la­tive since the last pg_­s­tat_s­tate­ments_re­set call.

This info can help you iden­tify your write-heavy queries and op­ti­mize as nec­es­sary. Note that write-heavy queries can also af­fect repli­ca­tion: If you see repli­ca­tion lag, you can use these new fea­tures to un­der­stand bet­ter which state­ments are caus­ing it.

Settings like log_min_­du­ra­tion_s­tate­ment are great to help you un­der­stand your slow queries, but how slow is slow? Is the re­port­ing query that runs overnight slow com­pared to the 5s query that runs in the con­text of a web re­quest? Is that 5s query, that runs once in a rarely-used end­point, slow com­pared to a 100ms query that runs twenty times to load your home page?

Until now, log_min_­du­ra­tion_s­tate­ment was one blunt tool for all these sit­u­a­tions, but Postgres 13 brings some flex­i­bil­ity with sam­pling-based state­ment log­ging. You can set log_min_­du­ra­tion_sam­ple to en­able sam­pling, and then ei­ther set

log_s­tate­men­t_sam­ple_rate or log_­trans­ac­tion_sam­ple_rate to con­trol sam­pling.

Both of these set­tings work in a sim­i­lar man­ner: they range from 0 to 1, and de­ter­mine the chance that a state­ment will be ran­domly se­lected for log­ging. The for­mer ap­plies to in­di­vid­ual state­ments, the lat­ter de­ter­mines log­ging for all state­ments in a trans­ac­tion. If both log_min_­du­ra­tion_s­tate­ment and

log_min_­du­ra­tion_sam­ple are set, the for­mer should be a higher thresh­old that logs every­thing, and the lat­ter can be a lower thresh­old that logs only oc­ca­sion­ally.

Another great state­ment log­ging im­prove­ment is be­ing able to log pa­ra­me­ters for failed state­ments

with log_­pa­ra­me­ter_­max_length­_on_er­ror. Here’s an ex­am­ple of set­ting this to -1 (unlimited) and try­ing to run SELECT pg_sleep($1) (with pa­ra­me­ter $1 set to 3) on a con­nec­tion with a

state­men­t_­time­out of 1s:

The time­out case is es­pe­cially use­ful: Since both the query text and the pa­ra­me­ters are now avail­able in the logs, you could run EXPLAIN on any failed query to fig­ure out what query plan caused it to hit the time-out (N. B.: you are not guar­an­teed to get the same plan that failed, but de­pend­ing on your work­load, the odds are pretty good).

The usual cul­prit in slow queries is the query ex­e­cu­tion it­self, but with a com­plex schema and an elab­o­rate query, plan­ning can take sig­nif­i­cant time as well. Postgres 13 in­tro­duces two new changes that make it eas­ier to keep an eye on plan­ning:

First, the BUFFERS op­tion to EXPLAIN gives you more in­for­ma­tion on mem­ory us­age dur­ing query plan­ning. Postgres man­ages mem­ory for your data and in­dexes us­ing a “buffer pool”, and the BUFFERS op­tion can show you which parts of your query are us­ing that mem­ory and how. The

EXPLAIN doc­u­men­ta­tion has some more de­tails. New in Postgres 13 is the abil­ity to see how buffers are used dur­ing query plan­ning:

Second, pg_­s­tat_s­tate­ments will keep track of time spent plan­ning if you en­able the

pg_­s­tat_s­tate­ments.track­_­plan­ning

set­ting:

This is turned off by de­fault due to per­for­mance over­head for cer­tain work­loads, but if you sus­pect plan­ning time is an is­sue, it’s def­i­nitely worth check­ing out. For more de­tails on the per­for­mance re­gres­sion, see

this mail­ing list dis­cus­sion; this is ex­pected to be re­solved in the fu­ture and the de­fault may change.

Postgres 13 us­abil­ity im­prove­ments in­clude bet­ter doc­u­men­ta­tion, bet­ter built-in UUID sup­port, and some handy

psql en­hance­ments.

Any com­plex sys­tem will de­velop its own jar­gon, and Postgres is no ex­cep­tion. Some of it comes from the data­base field in gen­eral, some of it is Postgres-specific. Having ded­i­cated lan­guage to talk pre­cisely about spe­cific tech­ni­cal con­cepts is very use­ful, but it can be con­fus­ing for new­com­ers.

A col­lec­tion of at­trib­utes in a fixed or­der. That or­der may be de­fined by the table (or other re­la­tion) where the tu­ple is con­tained, in which case the tu­ple is of­ten called a row. It may also be de­fined by the struc­ture of a re­sult set, in which case it is some­times called a record.

- PostgreSQL Glossary

You are likely fa­mil­iar with the terms above, but if you ever run across some­thing you are un­clear on, those and many oth­ers are now doc­u­mented in a new glos­sary. And now that there’s an es­tab­lished place to do so, we can look for­ward to other tech­ni­cal terms be­ing added here in the fu­ture.

If you use UUIDs in your sys­tem (and you should con­sider it—they’re pretty handy), you’re prob­a­bly pretty fa­mil­iar with the uuid-ossp ex­ten­sion. The base uuid type is built in, but by de­fault, there’s no sim­ple mech­a­nism to au­to­mat­icly gen­er­ate new ones. The uuid-ossp ex­ten­sion ships with Postgres, but must be en­abled ex­plic­itly to cre­ate UUID-generation func­tions like the com­mon uuid_­gen­er­ate_v4.

Postgres 13 ships with a gen_ran­dom_u­uid func­tion that is equiv­a­lent to uuid_­gen­er­ate_v4, but avail­able by de­fault. If you were only us­ing uuid-ossp for that func­tion, you no longer need the ex­ten­sion:

There are a num­ber of small psql im­prove­ments in Postgres 13. My fa­vorite is that \e, the com­mand to in­voke your $EDITOR on the cur­rent query buffer, will now dis­play the query text when you save and exit (unless you di­rectly sub­mit it by end­ing with a semi­colon or \g). Previously, the query text was saved, but hid­den. Compare open­ing your ed­i­tor and sav­ing SELECT 1 in psql 11:

It’s now clear what query text will be sub­mit­ted when you com­plete your query.

Postgres 13 also in­cludes ad­di­tional ways to cus­tomize your psql prompt. You can do so, as al­ways, with

\set (typically in your .psqlrc), but there’s a cou­ple of new sub­sti­tu­tions avail­able:

* %x will dis­play the sta­tus of the cur­rent trans­ac­tion: an empty string for no

trans­ac­tion, * when in an open trans­ac­tion, ! when in a failed trans­ac­tion, or ? when the

trans­ac­tion state is un­known (typically when there is no con­nec­tion to the server)

* %w will pad PROMPT2 (used when more in­put is ex­pected) to be the same width as PROMPT1 to keep things

nicely aligned

There are some other small im­prove­ments

as well. And these are all client-side changes, so they will also work if you are us­ing a new psql with an older server!

These are just a few of the many small im­prove­ments that come with Postgres 13. There are many oth­ers, like par­tial TOAST de­com­pres­sion, trusted ex­ten­sions (so you can en­able them with­out be­ing su­pe­ruser), PL/pgSQL per­for­mance im­prove­ments, and more. You can check out the full re­lease notes on the Postgres web site.

We’re very ex­cited for this re­lease. We al­ready sup­port mon­i­tor­ing Postgres 13 in pg­an­a­lyze, and are al­ready work­ing on in­cor­po­rat­ing the new mon­i­tor­ing fea­tures di­rectly into the prod­uct to give you bet­ter in­sights into your data­base.

Share this ar­ti­cle: If you liked this ar­ti­cle you might want to tweet it to your peers.

BEIJING (Reuters) - China is push­ing grow­ing num­bers of Tibetan rural la­bor­ers off the land and into re­cently built mil­i­tary-style train­ing cen­ters where they are turned into fac­tory work­ers, mir­ror­ing a pro­gram in the west­ern Xinjiang re­gion that rights groups have branded co­er­cive la­bor.

Beijing has set quo­tas for the mass trans­fer of rural la­bor­ers within Tibet and to other parts of China, ac­cord­ing to over a hun­dred state me­dia re­ports, pol­icy doc­u­ments from gov­ern­ment bu­reaus in Tibet and pro­cure­ment re­quests re­leased be­tween 2016-2020 and re­viewed by Reuters. The quota ef­fort marks a rapid ex­pan­sion of an ini­tia­tive de­signed to pro­vide loyal work­ers for Chinese in­dus­try.

A no­tice posted to the web­site of Tibet’s re­gional gov­ern­ment web­site last month said over half a mil­lion peo­ple were trained as part of the pro­ject in the first seven months of 2020 - around 15% of the re­gion’s pop­u­la­tion. Of this to­tal, al­most 50,000 have been trans­ferred into jobs within Tibet, and sev­eral thou­sand have been sent to other parts of China. Many end up in low paid work, in­clud­ing tex­tile man­u­fac­tur­ing, con­struc­tion and agri­cul­ture.

“This is now, in my opin­ion, the strongest, most clear and tar­geted at­tack on tra­di­tional Tibetan liveli­hoods that we have seen al­most since the Cultural Revolution” of 1966 to 1976, said Adrian Zenz, an in­de­pen­dent Tibet and Xinjiang re­searcher, who com­piled the core find­ings about the pro­gram. These are de­tailed in a re­port re­leased this week by the Jamestown Foundation, a Washington, D. C.-based in­sti­tute that fo­cuses on pol­icy is­sues of strate­gic im­por­tance to the U.S. “It’s a co­er­cive lifestyle change from no­madism and farm­ing to wage la­bor.”

Reuters cor­rob­o­rated Zenz’s find­ings and found ad­di­tional pol­icy doc­u­ments, com­pany re­ports, pro­cure­ment fil­ings and state me­dia re­ports that de­scribe the pro­gram.

In a state­ment to Reuters, China’s Ministry of Foreign Affairs strongly de­nied the in­volve­ment of forced la­bor, and said China is a coun­try with rule of law and that work­ers are vol­un­tary and prop­erly com­pen­sated.

“What these peo­ple with ul­te­rior mo­tives are call­ing ‘forced labor’ sim­ply does not ex­ist. We hope the in­ter­na­tional com­mu­nity will dis­tin­guish right from wrong, re­spect facts, and not be fooled by lies,” it said.

Moving sur­plus rural la­bor into in­dus­try is a key part of China’s drive to boost the econ­omy and re­duce poverty. But in ar­eas like Xinjiang and Tibet, with large eth­nic pop­u­la­tions and a his­tory of un­rest, rights groups say the pro­grams in­clude an out­sized em­pha­sis on ide­o­log­i­cal train­ing. And the gov­ern­ment quo­tas and mil­i­tary-style man­age­ment, they say, sug­gest the trans­fers have co­er­cive el­e­ments.

China seized con­trol of Tibet af­ter Chinese troops en­tered the re­gion in 1950, in what Beijing calls a “peaceful lib­er­a­tion.” Tibet has since be­come one of the most re­stricted and sen­si­tive ar­eas in the coun­try.

The Tibetan pro­gram is ex­pand­ing as in­ter­na­tional pres­sure is grow­ing over sim­i­lar pro­jects in Xinjiang, some of which have been linked to mass de­ten­tion cen­ters. A United Nations re­port has es­ti­mated that around one mil­lion peo­ple in Xinjiang, mostly eth­nic Uighurs, were de­tained in camps and sub­jected to ide­o­log­i­cal ed­u­ca­tion. China ini­tially de­nied the ex­is­tence of the camps, but has since said they are vo­ca­tional and ed­u­ca­tion cen­ters, and that all the peo­ple have “graduated.”

Reuters was un­able to as­cer­tain the con­di­tions of the trans­ferred Tibetan work­ers. Foreign jour­nal­ists are not per­mit­ted to en­ter the re­gion, and other for­eign cit­i­zens are only per­mit­ted on gov­ern­ment-ap­proved tours.

In re­cent years, Xinjiang and Tibet have been the tar­get of harsh poli­cies in pur­suit of what Chinese au­thor­i­ties call “stability main­te­nance.” These poli­cies are broadly aimed at quelling dis­sent, un­rest or sep­a­ratism and in­clude re­strict­ing the travel of eth­nic cit­i­zens to other parts of China and abroad, and tight­en­ing con­trol over re­li­gious ac­tiv­i­ties.

In August, President Xi Jinping said China will again step up ef­forts against sep­a­ratism in Tibet, where eth­nic Tibetans make up around 90% of the pop­u­la­tion, ac­cord­ing to cen­sus data. Critics, spear­headed by Tibetan spir­i­tual leader the Dalai Lama, ac­cuse the Chinese au­thor­i­ties of car­ry­ing out “cultural geno­cide” in the re­gion. The 85-year-old Nobel Laureate has been based in Dharamsala, India, since he fled China in 1959 fol­low­ing a failed up­ris­ing against Chinese au­thor­i­ties.

While there has been some ev­i­dence of mil­i­tary-style train­ing and la­bor trans­fers in Tibet in the past, this new, en­larged pro­gram rep­re­sents the first on a mass scale and the first to openly set quo­tas for trans­fers out­side the re­gion.

A key el­e­ment, de­scribed in mul­ti­ple re­gional pol­icy doc­u­ments, in­volves send­ing of­fi­cials into vil­lages and town­ships to gather data on rural la­bor­ers and con­duct ed­u­ca­tion ac­tiv­i­ties, aimed at build­ing loy­alty.

State me­dia de­scribed one such op­er­a­tion in vil­lages near the Tibetan cap­i­tal, Lhasa. Officials car­ried out over a thou­sand anti-sep­a­ratism ed­u­ca­tion ses­sions, ac­cord­ing to the state me­dia re­port, “allowing the peo­ple of all eth­nic groups to feel the care and con­cern of the Party Central Committee,” re­fer­ring to China’s rul­ing Communist Party.

The re­port said the ses­sions in­cluded songs, dances and sketches in “easy to un­der­stand lan­guage.” Such “education” work took place prior to the roll­out of the wider trans­fers this year.

The model is sim­i­lar to Xinjiang, and re­searchers say a key link be­tween the two is the for­mer Tibet Communist Party Secretary Chen Quanguo, who took over the same post in Xinjiang in 2016 and spear­headed the de­vel­op­ment of Xinjiang’s camp sys­tem. The Xinjiang gov­ern­ment, where Chen re­mains Party boss, did not re­spond to a re­quest for com­ment.

“In Tibet, he was do­ing a slightly lower level, un­der the radar, ver­sion of what was im­ple­mented in Xinjiang,” said Allen Carlson, Associate Professor in Cornell University’s Government Department.

Around 70% of Tibet’s pop­u­la­tion is clas­si­fied as rural, ac­cord­ing to 2018 fig­ures from China’s National Bureau of Statistics. This in­cludes a large pro­por­tion of sub­sis­tence farm­ers, pos­ing a chal­lenge for China’s poverty al­le­vi­a­tion pro­gram, which mea­sures its suc­cess on lev­els of ba­sic in­come. China has pledged to erad­i­cate rural poverty in the coun­try by the end of 2020.

“In or­der to cope with the in­creas­ing down­ward eco­nomic pres­sure on the em­ploy­ment in­come of rural work­ers, we will now in­crease the in­ten­sity of pre­ci­sion skills train­ing … and carry out or­ga­nized and large-scale trans­fer of em­ploy­ment across provinces, re­gions and cities,” said a work­ing plan re­leased by Tibet’s Human Resources and Social Security Department in July. The plan in­cluded 2020 quo­tas for the pro­gram in dif­fer­ent ar­eas.

Some of the pol­icy doc­u­ments and state me­dia re­ports re­viewed by Reuters make ref­er­ence to un­spec­i­fied pun­ish­ments for of­fi­cials who fail to meet their quo­tas. One pre­fec­ture level im­ple­men­ta­tion plan called for “strict re­ward and pun­ish­ment mea­sures” for of­fi­cials.

As in Xinjiang, pri­vate in­ter­me­di­aries, such as agents and com­pa­nies, that or­ga­nize trans­fers can re­ceive sub­si­dies set at 500 yuan ($74) for each la­borer moved out of the re­gion and 300 yuan ($44) for those placed within Tibet, ac­cord­ing to re­gional and pre­fec­ture level no­tices.

Officials have pre­vi­ously said that la­bor trans­fer pro­grams in other parts of China are vol­un­tary, and many of the Tibetan gov­ern­ment doc­u­ments also men­tion mech­a­nisms to en­sure la­bor­ers’ rights, but they don’t pro­vide de­tails. Advocates, rights groups and re­searchers say it’s un­likely la­bor­ers are able to de­cline work place­ments, though they ac­knowl­edge that some may be vol­un­tary.

“These re­cent an­nounce­ments dra­mat­i­cally and dan­ger­ously ex­pand these pro­grams, in­clud­ing ‘thought train­ing’ with the gov­ern­men­t’s co­or­di­na­tion, and rep­re­sent a dan­ger­ous es­ca­la­tion,” said Matteo Mecacci, pres­i­dent of U. S. based ad­vo­cacy group, the International Campaign for Tibet.

The gov­ern­ment doc­u­ments re­viewed by Reuters put a strong em­pha­sis on ide­o­log­i­cal ed­u­ca­tion to cor­rect the “thinking con­cepts” of la­bor­ers. “There is the as­ser­tion that mi­nori­ties are low in dis­ci­pline, that their minds must be changed, that they must be con­vinced to par­tic­i­pate,” said Zenz, the Tibet-Xinjiang re­searcher based in Minnesota.

One pol­icy doc­u­ment, posted on the web­site of the Nagqu City gov­ern­ment in Tibet’s east in December 2018, re­veals early goals for the plan and sheds light on the ap­proach. It de­scribes how of­fi­cials vis­ited vil­lages to col­lect data on 57,800 la­bor­ers. Their aim was to tackle “can’t do, don’t want to do and don’t dare to do” at­ti­tudes to­ward work, the doc­u­ment says. It calls for un­spec­i­fied mea­sures to “effectively elim­i­nate ‘lazy peo­ple.’”

A re­port re­leased in January by the Tibetan arm of the Chinese People’s Political Consultative Conference, a high-pro­file ad­vi­sory body to the gov­ern­ment, de­scribes in­ter­nal dis­cus­sions on strate­gies to tackle the “mental poverty” of rural la­bor­ers, in­clud­ing send­ing teams of of­fi­cials into vil­lages to carry out ed­u­ca­tion and “guide the masses to cre­ate a happy life with their hard­work­ing hands.”

Rural work­ers who are moved into vo­ca­tional train­ing cen­ters re­ceive ide­o­log­i­cal ed­u­ca­tion - what China calls “military-style” train­ing - ac­cord­ing to mul­ti­ple Tibetan re­gional and dis­trict-level pol­icy doc­u­ments de­scrib­ing the pro­gram in late 2019 and 2020. The train­ing em­pha­sises strict dis­ci­pline, and par­tic­i­pants are re­quired to per­form mil­i­tary drills and dress in uni­forms.

It is not clear what pro­por­tion of par­tic­i­pants in the la­bor trans­fer pro­gram un­dergo such mil­i­tary-style train­ing. But pol­icy doc­u­ments from Ngari, Xigatze and Shannan, three dis­tricts which ac­count for around a third of Tibet’s pop­u­la­tion, call for the “vigorous pro­mo­tion of mil­i­tary-style train­ing.” Region-wide pol­icy no­tices also make ref­er­ence to this train­ing method.

Small-scale ver­sions of sim­i­lar mil­i­tary-style train­ing ini­tia­tives have ex­isted in the re­gion for over a decade, but con­struc­tion of new fa­cil­i­ties in­creased sharply in 2016, and re­cent pol­icy doc­u­ments call for more in­vest­ment in such sites. A re­view of satel­lite im­agery and doc­u­ments re­lat­ing to over a dozen fa­cil­i­ties in dif­fer­ent dis­tricts in Tibet shows that some are built near to or within ex­ist­ing vo­ca­tional cen­ters.

The pol­icy doc­u­ments de­scribe a teach­ing pro­gram that com­bines skills ed­u­ca­tion, le­gal ed­u­ca­tion and “gratitude ed­u­ca­tion,” de­signed to boost loy­alty to the Party.

James Leibold, pro­fes­sor at Australia’s La Trobe University who spe­cial­izes in Tibet and Xinjiang, says there are dif­fer­ent lev­els of mil­i­tary-style train­ing, with some less re­stric­tive than oth­ers, but that there is a fo­cus on con­for­mity.

“Tibetans are seen as lazy, back­ward, slow or dirty, and so what they want to do is to get them march­ing to the same beat… That’s a big part of this type of mil­i­tary-style ed­u­ca­tion.”

In east­ern Tibet’s Chamdo dis­trict, where some of the ear­li­est mil­i­tary-style train­ing pro­grams emerged, state me­dia im­ages from 2016 show la­bor­ers lin­ing up in drill for­ma­tion in mil­i­tary fa­tigues. In im­ages pub­lished by state me­dia in July this year, wait­resses in mil­i­tary cloth­ing are seen train­ing at a vo­ca­tional fa­cil­ity in the same dis­trict. Pictures posted on­line from the “Chamdo Golden Sunshine Vocational Training School” show rows of ba­sic white shed-like ac­com­mo­da­tion with blue roofs. In one im­age, ban­ners hang­ing on the wall be­hind a row of grad­u­ates say the la­bor trans­fer pro­ject is over­seen by the lo­cal Human Resources and Social Security Department.

The vo­ca­tional skills learned by trainees in­clude tex­tiles, con­struc­tion, agri­cul­ture and eth­nic hand­i­crafts. One vo­ca­tional cen­ter de­scribes el­e­ments of train­ing in­clud­ing “Mandarin lan­guage, le­gal train­ing and po­lit­i­cal ed­u­ca­tion.” A sep­a­rate re­gional pol­icy doc­u­ment says the goal is to “gradually re­al­ize the tran­si­tion from ‘I must work’ to ‘I want to work.’”

Regional and pre­fec­ture level pol­icy doc­u­ments place an em­pha­sis on train­ing batches of work­ers for spe­cific com­pa­nies or pro­jects. Rights groups say this on-de­mand ap­proach in­creases the like­li­hood that the pro­grams are co­er­cive.

Workers trans­ferred un­der the pro­grams can be dif­fi­cult to trace, par­tic­u­larly those sent to other parts of China. In sim­i­lar mass trans­fers of Uighur peo­ple from Xinjiang, work­ers were dis­cov­ered in the sup­ply chains of 83 global brands, ac­cord­ing to a re­port re­leased by the The Australian Strategic Policy Institute (ASPI).

Researchers and rights groups say trans­fers from these re­gions pose a chal­lenge be­cause with­out ac­cess they can’t as­sess whether the prac­tice con­sti­tutes forced la­bor, and trans­ferred work­ers of­ten work along­side non-trans­ferred coun­ter­parts.

Tibetan state me­dia re­ports in July say that in 2020 some of the work­ers trans­ferred out­side of Tibet were sent to con­struc­tion pro­jects in Qinghai and Sichuan. Others trans­ferred within Tibet were trained in tex­tiles, se­cu­rity and agri­cul­tural pro­duc­tion work.

Regional Tibetan gov­ern­ment pol­icy no­tices and pre­fec­ture im­ple­men­ta­tion plans pro­vide lo­cal gov­ern­ment of­fices with quo­tas for 2020, in­clud­ing for Tibetan work­ers sent to other parts of China. Larger dis­tricts are ex­pected to sup­ply more work­ers to other ar­eas of the coun­try - 1,000 from the Tibetan cap­i­tal Lhasa, 1,400 from Xigaze, and 800 from Shannan.

Reuters re­viewed pol­icy no­tices put out by Tibet and a dozen other provinces that have ac­cepted Tibetan la­bor­ers. These doc­u­ments re­veal that work­ers are of­ten moved in groups and stay in col­lec­tive ac­com­mo­da­tion.

Local gov­ern­ment doc­u­ments in­side Tibet and in three other provinces say work­ers re­main in cen­tralised ac­com­mo­da­tion af­ter they are trans­ferred, sep­a­rated from other work­ers and un­der su­per­vi­sion. One state me­dia doc­u­ment, de­scrib­ing a trans­fer within the re­gion, re­ferred to it as a “point to point ‘nanny’ ser­vice.”

The Tibetan Human Resources and Social Security Department noted in July that peo­ple are grouped into teams of 10 to 30. They travel with team lead­ers and are man­aged by “employment li­ai­son ser­vices.” The de­part­ment said the groups are tightly man­aged, es­pe­cially when mov­ing out­side Tibet, where the li­ai­son of­fi­cers are re­spon­si­ble for car­ry­ing out “further ed­u­ca­tion ac­tiv­i­ties and re­duc­ing home­sick­ness com­plexes.” It said the gov­ern­ment is re­spon­si­ble for car­ing for “left-behind women, chil­dren and the el­derly.”

You can pause and play au­dio or video in Firefox right from your key­board or head­set, giv­ing you easy ac­cess to con­trol your me­dia when in an­other Firefox tab, an­other pro­gram, or even when your com­puter is locked.

In ad­di­tion to our de­fault, dark and light themes, with this re­lease, Firefox in­tro­duces the Alpenglow theme: a col­or­ful ap­pear­ance for but­tons, menus, and win­dows. You can up­date your Firefox themes un­der set­tings or pref­er­ences.

For our users in the US and Canada, Firefox can now save, man­age, and auto-fill credit card in­for­ma­tion for you, mak­ing shop­ping on Firefox ever more con­ve­nient. To en­sure the smoothest ex­pe­ri­ence, this will be rolling out to users grad­u­ally.

Firefox sup­ports AcroForm, which will soon al­low you to fill in, print, and save sup­ported PDF forms and the PDF viewer also has a new fresh look.

Our users in Austria, Belgium and Switzerland us­ing the German ver­sion of Firefox will now see Pocket rec­om­men­da­tions in their new tab fea­tur­ing some of the best sto­ries on the web. If you don’t see them, you can turn on Pocket ar­ti­cles in your new tab by fol­low­ing these steps. In ad­di­tion to Firefox’s new tab, Pocket is also avail­able as an app on iOS and Android.

As the pop­u­la­tion in­creas­ingly moves to­wards tech jobs, there’s now a short­age of co­conut har­vesters in India. That’s why sci­en­tists there have built a tree-climb­ing co­conut-har­vest­ing ro­bot, that could per­haps some­day take up the slack.

The pro­to­type de­vice was cre­ated by a team at Amrita Vishwa Vidyapeetham University, led by Asst. Prof. Rajesh Kannan Megalingam. Known as Amaran, it’s cur­rently in its sixth in­car­na­tion, and has been in de­vel­op­ment for three years.

In a 15-minute process, users start by man­u­ally as­sem­bling the ro­bot’s ring-shaped body around the base of a co­conut tree. Utilizing its eight in­ward-fac­ing om­ni­di­rec­tional rub­ber wheels, Amaran then makes its way up to the top.

A user wire­lessly con­trols it from the ground, uti­liz­ing ei­ther a joy­stick unit or a smart­phone app to move it up and down, and to ro­tate it around the trunk.

Once the ro­bot has reached the co­conuts, its arm is ex­tended and po­si­tioned at the base of a bunch of ripe co­conuts. Utilizing a cir­cu­lar saw blade on the end of the arm, Amaran then cuts through that base, al­low­ing the co­conuts to fall to the ground.

In field tests con­ducted at a co­conut farm, the ro­bot suc­cess­fully climbed trees up to 15.2 m (49.9 ft) in height, with trunk in­cli­na­tions of up to 30 de­grees. Additionally, while hu­man co­conut har­vesters were found to work faster, Amaran could work for longer, po­ten­tially mak­ing up the dif­fer­ence.

A pa­per on the re­search was re­cently pub­lished in the jour­nal IEEE/ASME Transactions on Mechatronics.

The ro­bot can be seen in use, in the video be­low.

The mys­tery of why an en­tire vil­lage lost its broad­band every morn­ing at 7am was solved when en­gi­neers dis­cov­ered an old tele­vi­sion was to blame.

An un­named house­holder in Aberhosan, Powys, was un­aware the old set would emit a sig­nal which would in­ter­fere with the en­tire vil­lage’s broad­band.

After 18 months en­gi­neers be­gan an in­ves­ti­ga­tion af­ter a ca­ble re­place­ment pro­gramme failed to fix the is­sue.

The em­bar­rassed house­holder promised not to use the tele­vi­sion again.

The vil­lage now has a sta­ble broad­band sig­nal.

Openreach en­gi­neers were baf­fled by the con­tin­u­ous prob­lem and it was­n’t un­til they used a mon­i­tor­ing de­vice that they found the fault.

The house­holder would switch their TV set on at 7am every morn­ing - and elec­tri­cal in­ter­fer­ence emit­ted by their sec­ond-hand tele­vi­sion was af­fect­ing the broad­band sig­nal.

The owner, who does not want to be iden­ti­fied, was “mortified” to find out their old TV was caus­ing the prob­lem, ac­cord­ing to Openreach.

“They im­me­di­ately agreed to switch it off and not use it again,” said en­gi­neer Michael Jones.

Engineers walked around the vil­lage with a mon­i­tor called a spec­trum analyser to try to find any “electrical noise” to help pin­point the prob­lem.

“At 7am, like clock­work, it hap­pened,” said Mr Jones.

“Our de­vice picked up a large burst of elec­tri­cal in­ter­fer­ence in the vil­lage.

“It turned out that at 7am every morn­ing the oc­cu­pant would switch on their old TV which would, in turn, knock out broad­band for the en­tire vil­lage.”

The TV was found to be emit­ting a sin­gle high-level im­pulse noise (SHINE), which causes elec­tri­cal in­ter­fer­ence in other de­vices.

Mr Jones said the prob­lem has not re­turned since the fault was iden­ti­fied.

Suzanne Rutherford, Openreach chief en­gi­neer’s lead for Wales, said any­thing with elec­tric com­po­nents - from out­door lights to mi­crowaves - can po­ten­tially have an im­pact on broad­band con­nec­tions.

“We’d just ad­vise the pub­lic to make sure that their elec­tric ap­pli­ances are prop­erly cer­ti­fied and meet cur­rent British stan­dards,” she said.

“And if you have a fault, re­port it to your ser­vice provider in the first in­stance so that we can in­ves­ti­gate.”

Content avail­able un­der the CC-By 3.0 li­cense

How to take meet­ing notes­Sign up to like post­Long time no chat. I’ve spent August fig­ur­ing out how learn­ing works and how we can ap­ply spa­tial cog­ni­tion and com­put­ers to im­prove how we learn. And I’ve got some pretty ex­cit­ing stuff com­ing out in the next few weeks. Spoiler: if you’ve ever tried learn­ing how to pro­gram but failed mis­er­ably, you’ll ap­pre­ci­ate this even more. But to­day I want to talk mem­ory.A few months back, I’ve started tak­ing ex­ten­sive meet­ing notes as a part of my mem­ory ex­per­i­ment. In four weeks, I trained my­self to re­mem­ber about 90-95% of every­thing that hap­pens at a meet­ing. And I’m still fas­ci­nated by how de­lighted peo­ple are to re­ceive a de­tailed note with every­thing we dis­cussed (ideas, con­cepts, pro­jects, etc.). After pol­ish­ing my method for two months, I’m now ready to share it with you. Here’s why you might be in­ter­ested:You can de­light the peo­ple you meet with by send­ing a de­tailed note with every­thing you cov­ered on a meet­ing (very few peo­ple do that)You can fos­ter re­la­tion­ships with friends by shar­ing rel­e­vant meet­ing notes aroundYou can turn meet­ing notes into novel, rel­e­vant, and per­son­al­ized con­tent for your au­di­enceEn­joy your read­ing & take bet­ter notes,

- VI do not take notes dur­ing the meet­ing. I’ve tried this many times and al­ways found it to be dis­tract­ing. I could­n’t con­cen­trate on writ­ing and lis­ten­ing to the per­son at the same time. This led to bad notes and poor con­ver­sa­tion.In­stead, I take notes af­ter the meet­ing. Whenever I meet some­one, I try to pay at­ten­tion to what they’re say­ing and be fully en­gaged. If I’m tak­ing this meet­ing, then I bet­ter pay at­ten­tion to it. And if it’s not worth my full at­ten­tion, then I should­n’t spend time on it.Im­me­di­ately af­ter I come back home, I sit down and pull out a piece of pa­per and my iPad with the Drafts app. In Drafts, I be­gin what I call de­scrip­tive writ­ing. I write in the first per­son just about every­thing I re­mem­ber from the meet­ing. Usually, to get go­ing, I be­gin with some­thing like:“Just came back from meet­ing such and such, we went to this nice new sushi place in the city that just opened a few weeks back..” Writing from the first per­son helps avoid the writer’s block that arises be­cause you’re try­ing to con­vert the stuff you hear in your head (in the first per­son) into the stuff how it’s sup­posed to be writ­ten (in the third per­son) [2].The pur­pose of re­call­ing these seem­ingly ir­rel­e­vant de­tails is to ac­ti­vate the brain’s ar­eas that store in­for­ma­tion that you need. In a tech­ni­cal lan­guage, to use im­plicit mem­o­ries of space, things, and faces to in­crease the like­li­hood of re­call­ing more ab­stract things like ideas and con­cepts.Here’s how my Drafts file looks like when I be­gin re­call­ing ideas:Once I get go­ing, I turn to my piece of pa­per and start writ­ing & sketch­ing con­cepts and ideas that I re­mem­ber from the meet­ing. I do not write them in a list; in­stead, I scat­ter them around the pa­per piece and use lots of rough sketches, ar­rows, lines, and boxes. This leads to en­hanced spa­tial cog­ni­tion be­cause I can see un­ob­vi­ous re­la­tions be­tween ideas that are im­pos­si­ble to see in a list view.Here’s how my pa­per notes look like when I’m in the mid­dle of the re­call process: I be­gin from any level here. If we talked about ed­u­ca­tion for two hours, but I re­mem­bered the marathon that we dis­cussed when we were or­der­ing food first, I’d jot down the marathon first. On this step, I use cat­e­gories [3] to pull out even more mem­o­ries from my head. If we talked about nu­tri­tion, I’d tell my­self: “OK I re­mem­ber we’ve talked about nu­tri­tion, but what’s the next layer above nu­tri­tion? Oh, that’s health. And have we talked about any­thing else health-re­lated such as fit­ness? Oh yeah, marathons!” I switch back and forth be­tween the two in­ter­faces but spend 90% of my time on pa­per be­cause of how pow­er­ful it is. It just feels dif­fer­ent. Unfortunately, there’s no soft­ware for think­ing that uses more than two modes of thought [4].I also do not write fully formed sen­tences on pa­per; they’re more like hooks to re­mem­ber things when I’ll be writ­ing a note. I sus­pect this also helps to com­press ideas into chunks, which leads to higher speed of thought (that is au­da­cious spec­u­la­tion, I know). Once I feel like I’m slow­ing down (usually af­ter 5-7 min­utes of do­ing the Drafts/paper part), I be­gin do­ing three other things: draw­ing the per­son, draw­ing the map, and draw­ing the time­line.Here’s how it looks:First, I sketch the per­son in the bot­tom right cor­ner of the piece of pa­per. Drawing helps me bring back many other emo­tion-re­lated things be­cause I be­gin re­mem­ber­ing emo­tions I’ve im­plic­itly stored (i.e., when the per­son was an­gry, happy, loud, etc.). I’m by no means good at draw­ing, but the idea is to pro­duce at least a some­what close rep­re­sen­ta­tion of a per­son as you can get to aid your mind with re­call­ing thoughts. See the im­age above for de­tails.Sec­ond, I draw a map of where we’ve been. If we went for a walk, I draw a map of the space that we cov­ered. If we were in­side, I draw a map of the room we were sit­ting in. Creating a map helps ac­ti­vate the brain’s area re­spon­si­ble for space, and I get many mem­o­ries out of it [5]. Plus, it’s a lot of fun! One in­ter­est­ing ob­ser­va­tion here: when­ever I draw a vi­sual rep­re­sen­ta­tion of the place (i.e., if it’s a cof­fee shop, then ta­bles, other peo­ple around, the bar, etc.), I be­gin re­call­ing space-re­lated ideas that we’ve cov­ered with the per­son (i.e., coun­tries, travel, routes, even loosely re­lated things like the bi­og­ra­phy of a per­son who lived some­where). I don’t yet know how to ex­plain this, but it works every time. Last week, when I watched Peter Thiel’s speech at the WIRED UK, and I jot down the scene, I in­stantly be­gan re­mem­ber­ing how he talked about China and new cities in the ocean; all space-re­lated ideas from the talk.Third, I draw a hor­i­zon­tal time­line di­a­gram of the meet­ing and map dif­fer­ent things that we cov­ered on that time­line. I haven’t fig­ured out how this works yet, but draw­ing a time­line and then map­ping var­i­ous con­ver­sa­tion top­ics helps to iden­tify things that were be­fore or af­ter this par­tic­u­lar topic in time, left or right on the time­line. The time­line also un­cov­ers ad­di­tional ideas that I missed. In ad­di­tion to that, I go for­ward and back in time when I’m re­call­ing con­cepts. I try to re­mem­ber things se­quen­tially, both from the be­gin­ning and from the end of the meet­ing.Once I feel like I’ve reached a crit­i­cal mass and hit the in­flec­tion point of un­der­stand­ing what the meet­ing was about, I get back to my in­put en­vi­ron­ment, Drafts, and start writ­ing notes. I’m bilin­gual and meet with many Russian-speaking folks, so I write in Russian if I need to. During the spa­tial think­ing process on pa­per, I usu­ally iden­tify clus­ters such as “education” or “health”, and draw a cir­cle around them to make them stand out. So when I be­gin writ­ing tex­tual notes in my in­put en­vi­ron­ment, I start from those clus­ters and use them as sec­tion ti­tles, such as Notes–Education or Notes–Health. Clustering seems to im­prove my abil­ity to re­call things that were left be­hind when I was do­ing the spa­tial think­ing process and vi­sual think­ing with il­lus­tra­tions. Another in­ter­est­ing ob­ser­va­tion is that clus­ter­ing helps to con­nect ideas from the meet­ing to my own think­ing, sup­pos­edly be­cause I fo­cus my at­ten­tion on the things I’m writ­ing, which trig­gers as­so­cia­tive thought. The whole process takes about 30 min­utes per 1.5-2h meet­ing. When I fin­ish writ­ing notes, I add ma­te­ri­als that I think are rel­e­vant to what we cov­ered. As a re­sult, I get about 500 words with links that I send to the per­son.Here’s how a full notes file looks like (in Russian):To build a habit, you need to tie the process of tak­ing meet­ing notes to a spe­cific thing you do with no ex­cep­tion. For ex­am­ple, you can com­mit to be­gin writ­ing meet­ing notes im­me­di­ately af­ter re­turn­ing home and get­ting your shoes off. That’s how you make it stick [6].As for the process it­self, this is some­thing you learn best by do­ing. So when­ever you meet some­one, try to pay at­ten­tion to what the per­son is say­ing. There’s no need to use spe­cial mnemon­ics or con­vul­sively writ­ing down notes. Once you come back home and take your shoes off, do the fol­low­ing:Open up your fa­vorite text ed­i­tor on your com­puter or phoneFind a piece of pa­per and a pen (I use plain white A4 pa­per and a black gel pen); pa­per needs to be dis­pos­able so that you would­n’t be afraid to sketch things and go re­ally fast­Be­gin writ­ing in your text ed­i­tor; if you don’t know what to write or don’t seem to re­mem­ber any­thing, be­gin de­scrib­ing the pre­vi­ous 5-10 min­utes in the first tense and ideas will come. For ex­am­ple, “Just came back home af­ter meet­ing such and such, we’ve been to such and such place and had such and such food”Once you be­gin re­mem­ber­ing things, jump to the piece of pa­per and con­tinue think­ing there in­stead of writ­ing them in the in­put en­vi­ron­ment; this will un­lock a new stream of ideas and help you see new things be­cause of spa­tial cog­ni­tion­Ap­ply cat­e­gories, draw­ings, maps, and time­lines to bring back even more ex­cit­ing ideas­Con­tinue switch­ing the in­ter­faces un­til you feel like you’ve got enough writ­ten on pa­per­Jump to your text ed­i­tor and write notes based on what you have on pa­per­Add rel­e­vant links and ma­te­ri­als and send to the per­son­How to turn meet­ing notes into con­tentAfter months of tak­ing notes, I’ve fig­ured that meet­ing notes are a unique con­tent type. I’ve be­gun edit­ing them slightly to omit per­sonal de­tails and send­ing them to peo­ple who I thought would be in­ter­ested. It worked sur­pris­ingly well; from ~150 peo­ple I shared a note with about 95% replied and said they loved it. The big learn­ing is that meet­ing notes might be an in­ter­est­ing new con­tent type that peo­ple aren’t yet bored with. Nov­elty. We don’t re­peat things at meet­ings be­cause we know the per­son al­ready knows them. Rel­e­vance. We talk about things & ideas that are in­ter­est­ing to both par­ties; we un­der­stand this by track­ing hun­dreds of sig­nals from their face, body lan­guage, and words in real time. On Facebook, the only feed­back chan­nel is likes; I don’t see their “meh” faces when they’re read­ing my stuff and can’t un­der­stand what kind of re­ac­tion my ideas trig­ger. Qual­ity. The qual­ity of in­for­ma­tion shared dur­ing the meet­ing is higher than in one-to-many pub­lish­ing on Facebook.Personalization. Sharing ideas with peo­ple I know loosely and adding a per­sonal touch (i.e., “hey I thought this would be in­ter­est­ing to you be­cause..”) in­creases the prob­a­bil­ity of a note to be read, which, in turn, in­creases the like­li­hood of the learn­ing process hi­er­ar­chy to be com­pleted, changes in the long-term mem­ory cre­ated, and trans­fer to real life oc­curred.Chan­nels. More and more peo­ple stop us­ing so­cials for con­tent dis­cov­ery be­cause of ads/​low-qual­ity in­for­ma­tion. This change sug­gests there’s an op­por­tu­nity for a new, more per­sonal chan­nel.That’s why I’m do­ing an ex­per­i­ment and putting my meet­ing notes on­line. You can sub­scribe to re­ceive up­dates by re­ply­ing to this email. Whenever I meet some­one, I’ll email you my meet­ing notes (approximately once in 2 weeks). Other thoughts that did­n’t fit the main sto­ry­lineIt seems that the process trains my men­tal ma­chin­ery to pay at­ten­tion; I have no proof but my re­mem­ber­ing ac­cu­racy (how much I can bring back) and ease of re­call has in­creased ~2-4x af­ter two months of do­ing this; I’m now able to re­call about 90-95% of a meet­ing.The use of dif­fer­ent cat­e­gories of in­for­ma­tion (i.e., ques­tions we dis­cussed, when a per­son was an­gry or ex­cited or happy, con­cepts we cov­ered, math­e­mat­i­cal no­ta­tions we ap­plied such as graphs or ma­trixes or spec­trums, peo­ple we ref­er­enced, etc.) seems to help with re­mem­ber­ing by dis­sect­ing the whole body of things we cov­ered into dif­fer­ent di­men­sions and sec­tors. I’m cu­ri­ous about how this first-time ac­tive re­call aids im­pact long-term mem­ory; be­cause things that make the cog­ni­tive process eas­ier usu­ally don’t get re­mem­bered well. I use the same process and three re­flec­tions ques­tions to any piece of con­tent that I con­sume, and it works ex­cep­tion­ally well. When I fin­ish read­ing or watch­ing some­thing, I ask my­self:What are the key ideas? How can I ap­ply this knowl­edge that I learned? How do these ideas re­late to what I al­ready know?[1] A good place to jump into rel­e­vant ac­tive re­call stud­ies is this Wiki page.[2] I sus­pect the term came from Stephen King, but it’s also very of­ten re­ferred to as “Dear Joel.”[3] For more in­for­ma­tion on cat­e­gories, re­fer to Barbara Tversky’s Mind in Motion book, p.35 & p.51.[4] My dad de­signs fur­ni­ture for 30 years and he feels the same about AutoCAD. If you’d like to learn more about modes of thought and how we ended up con­strain­ing our­selves in a small rec­tan­gle that sits on a table, watch this talk from Bret Victor.[5] For more in­for­ma­tion on how grid cells work, Barbara Tversky’s Mind in Motion book, p.69.[6] And yes, such se­quenc­ing works for any habit.Sign up to like post