You need to be able to argue in favor of multiple positions, theories, hypotheses, and points of view, including the ones you believe aren't accurate. Even the ones you happen to think are dangerous—it really behooves us to understand what arguments are in favor of the danger. Someone out there is working from that blueprint, and it's safer if you understand it and can calmly enlighten anyone about the mistakes in it.*

We've got this expression, "playing devil's advocate." It's a really important skill, but sometimes I think the name is unfortunate and misleading. Putting "devil" on there puts the cart before the horse; sometimes the devil's advocate position is absolutely right, and either way, I don't think the devil has much to do with this. "Playing devil's advocate" can be compared to "the devil is in the details," and in both cases it's about the thing you overlooked turning into a problem. If you DON'T play devil's advocate, that's the devil in the details that you missed. By NOT playing devil's advocate, you invite the "devil," or in other words, unexpected dangers and difficulties.

Very often when you play devil's advocate, you'll either annoy people or get them downright suspicious of you. People who don't want to make waves or seem suspicious will avoid this out of decency, and might even end up believing that to think in such a "devilish" (troubleshooting) way is wrong and dangerous. They'll block certain lines of thought from their minds and treat any mention of these lines of thought by others with stigma.

It doesn't take a lot of imagination to see what just happened there. A misguided moral instinct ruined a group's ability to talk issues through thoroughly and accurately.

-

*(It's also safer if your copy of the blueprint is completely accurate, rather than biased by upset, your personal moral code, and judgment. Many people, people of all stripes, can spot personal propaganda and straw man arguments and when they do, it undermines you.)

Am I saying anything surprising? When I check out at the supermarket and I'm paging around looking for ginger, I shouldn't eventually find it under "Root Ginger."

- SNIP - this is really boring I now recognize and admit, you can quit here -

No ever says that. It does make immediate sense from one direction, yet that's the wrong direction for a user interface: I have no doubt what it means on sight. But this is a list customers flip around through all day, every day, in every Safeway, with a name already in mind. They're looking for it by name, which they know, because they picked it and want to buy it. There is no other item in the list that has "ginger" in the name. There isn't even a "Gi-" entry.

Presumably this is the name in some more general purpose database, or else it's to help cashiers (who may be foreign and who didn't pick this item) to look up roots that look mysterious or similar to each other, and then go by the picture.

It's trivial to put an item in a database under multiple names. But I can see why they didn't - the entire catalogue is there to leaf through on the screen, so they only want to show each item in one alphabetic spot, to avoid scads of clutter. And if the "Root -" idea is to help cashiers, then that'll be the preferred name to display in the on-screen produce gallery anyway. Also, if customers can so easily type in the name to do a lookup, then this isn't a big hardship.

Except customers are less likely to know (or remember offhand) that there's a typed name lookup button. Cashiers will know and remember this and be speedy about it after the first day. So by extension, if a cashier doesn't recognize a root but they know roots are listed under "Root -", they'll know where to look: they use that typed name lookup button and type "root" (or the first couple letters), and voila, they didn't even have to page through the whole gallery of images.

Ultimately Safeway may have chosen to put their cashiers first and make the root situation more intuitive for ones who are struggling with language. Or perhaps anything else. So the listing is "Root Ginger" everywhere.

It's a compromise. Also, they're probably reluctant to change it now that many people are familiar with it.

It isn't a very good solution, though. Every time a customer gets ginger and checks out themselves, this will come up. Every single time, until they know it--and it'll only go away as long as they remember it.

It'll hit new customers and those returning after an absence the most. Like me. But I'm savvy about this stuff. So my impatience/frustration/annoyance is minimal compared to what it might be. (And I can analyze it this way, though it took conscious effort. Many people would assume "Root Ginger" has something to do with categories in the system, but I'm fairly sure that has little or nothing to do with it. It's for the cashiers.)

Putting cashiers first is good, but think about customers who don't speak English well, either. They know they picked something which they know is ginger; they likely checked the price, saw the label, and know what they're holding is "Ginger." They're less likely to look for "Root." Or... some would be very unlikely to do so. Others might think of that option faster than a native speaker fixated on the idea that "ginger" absolutely must be in here somewhere.

Things should be under their actual names in the photo gallery. Searching should include a larger database of alternate names. The downside there is that as you type, you might see several variations of the same thing (ginger, ginger root, root ginger) and not know whether they're the same. So adding synonyms to the database introduces a different moment of confusion elsewhere.

Good voice recognition would probably get rid of this issue. Accurate photo recognition also. (But both would need a fallback, for example the current approach.) And I think better software design would also get rid of the problem. The aforementioned little problem/downside to alternate names in the database is solvable.

What this comes down to is a compromise, a workaround that doesn't require overhauling the user interface or database.

The same problem tends to come up with orange sweet potatoes (yams - both yam and sweet potato are names confused with and applied to other species), and also turnips, which are often under "Purple Turnips" where I live and shop. None of this makes sense when you already know the name. Even if you know they're purple turnips, no supermarket around here has multiple turnip varieties. If we aren't listing the cultivar of carrots or ginger or garlic, we shouldn't be listing the cultivar of turnips as a prerequisite to checking out, paying, and going home.

It might seem like a tiny, inconsequential thing I'm talking about. And while I think the impact could be larger than we intuit, that isn't my point. There's a more general concept at work here. But I can't quite put my finger on it. Something about names and alternative names, and access through those symbols.

What cryptocurrency has been teaching us should have been clear already from fiat currency, but I guess it wasn't.

When you say "money is real-world game points," that seems to trivialize money by comparing it to arbitrary rewards won in play.

What if, on the other hand, the comparison actually ennobled money?

What if realizing that currency is best created according to rules open to all players - according to strict, consistent game rules, that is - could improve the way we think about, generate, deal in, disperse, award, earn, discuss, and compete over money?

What if "money is generated according to strict rules known - or knowable - to everyone" clarified and then improved the global economy?

Until very recently, money was created behind the scenes by banks deciding to write checks to give loans.

Today, you can create your own currency that is awarded according to the rules you specify.

This is different, in that fiat currency was not ur-awarded (ok I'm playing: "minted") according to clear, programmatic rules, and it was issued as debt with interest.

The new currency is like stocks, except stocks are supposed to pay dividends. Now a company can start and instead of asking for money from investors in return for stocks, can invent its own currency to disburse according to the rules it dreams up - which must be strict and visible, not arbitrary or a matter of favoritism, and in that sense fair - and then shape public behavior with this currency. Stocks are a one-time expression, in a sense: the company issues stocks (or maybe bonds), people buy them, trade them. Crypto is so similar yet so different: the stocks issued bureaucratically, financial instruments that pay dividends, morph and become cryptocurrency that does not pay dividends and that issues according to whether you're following the rules that generate that currency. Crypto shapes the activities of the people involved directly as a reward for participation. It's like the difference between eating birthday cake once a year and training your puppy to do tricks with dog treats every day. The birthday cake isn't supposed to teach you anything, just provide calories. The dog treats are exciting because treats mean calories biologically, but what's really going on is that you're training the dog.

Helium coin is the best example of this new model I've seen. Where does Helium coin come from? You earn it by running a hotspot that helps create and maintain the Helium 5G WiFi/IoT network. In a sense you work for the company from home, and they pay you in money that they just made up, according to rules that they just made up - but, critical point, rules that are visible to everyone, and apply equally to everyone.

Voila: the concept of game points has turned into actual, investable, influential, usable money, and arguably this kind of money is better than the old kind.

Do you see what I mean? "Money is game points" doesn't trivialize money. It points out the importance of rules that we all know and that apply equally to everyone. And it suggests money can be far more democratic than we imagined.

If you ask me, this cat isn't going back into that bag. Now that anyone can create a currency, the world won't ever be quite the same.

Also, someone other than me is going to realize that game studies and money policy are intimately linked, and not just by matrix-style, Cold War-style "game theory": by the principles of game design. 

Lucky or skillful? There isn't much luck without skill, and vice versa.

They aren't the same, just typically enmeshed. Any skill you have, you once had the capacity for it, the opportunity to develop it, and the desire to do so: three pieces of luck.

In effect, skill is just luck that happened in the past. Perhaps it included effort. But the most incompetent person could also have been making efforts.

We understand the meaning and basic principle of evolution, yet we fail to recognize how much is random.

Most of what you define as yourself is the luck of the draw.

It's a little unsettling, I know. And we need to be careful not to let this undermine our efforts. But there it is, no worse for the wear of our feelings.

Many beginning coders have the feeling there's one right or best way to compute a piece of data they need. To simplify a bit, this is not so. Style isn't all surface: the way you tend to think and approach things, the way the language works, the way you and others remember or refresh their memory. By and large, you cannot easily tell which angle of attack will be the fastest for the machine. To be blunt, most of the time you will not know; you will guess and occasionally run spot measurements like the (other?) professionals, knowing these are only limited snapshots. When you write code, as when you write math or speak, you're constantly balancing factors, not the least of which is how clear what you're writing is to you, and by extension to others.

As coders, we like parsimony, we like clarity, we like correctness, we like maintainability (meaning best practices for the future and an invitation to other coders to fix and help), we like efficiency, we like fluency (ie, of both writing and reading), and, of course, we like both reliability in general and the power of raw cycles. Most people stick with coding because they like the ever-morphing jigsaw of inventing little gizmos and sculpting and honing and combining them. Like authors, we may enjoy the ideal of "le seul mot juste" (Gustav Flaubert's name for the single best word in context, the one you love and hate searching for), but we recognize that's partly subjective, and often a word that fits well is worth as much or perhaps even more than an ideal word, once you take into account the time and energy demands.

In short, coding, like writing the languages we speak, is both sculpting and engineering; but unlike spoken language, it's pretty easy to check the logic and run some numbers for a rough comparison of efficiency and effectiveness.

To generalize very broadly, the best way to write the chunk of code you need is the way you write it so that it's up and running. After that, improve as much as you need. I've found that in coding, the idea of a first draft is even more important and powerful than in English. There's a saying to go along with that insight, but it takes quite a bit of experience to appreciate how and why it makes sense: "Premature optimization is the root of all evil," said Don Knuth. It's inefficient and even crippling to spin your wheels trying to get code working perfectly before it's working at all. Get something working first, then iterate.

This is critical because of the nature of logic in human minds. Our craniums don't really much distinguish between a) little efficiencies that come from cutting corners, sadly introducing massive logical flaws; b) little efficiencies that preserve correctness only locally, causing problems when generalized or exapted; and c) little efficiencies that are totally correct in a wider context. Computers crash; humans don't even notice a difference. Iterate. Use the power of the compiler and empirical results. It's astonishingly more than kinda useful for some people; it's a deep principle.

I'm not saying per se don't try to get it right. Spend a few minutes—maybe a few hours on a big piece—working out your strategy, if you feel from experience that will help. But sometimes you will find an enormous benefit to giving up on getting it right, especially after those few minutes, and getting started. This seems almost too obvious to say, except it's truer in this domain than in many others for the reasons I've tried to present above, though at best I've only hinted at them.

Think of evolution: if the atmosphere needed to invent you before even getting started on life, none of us would be here today. Life proceeded, and proceeds still, by little perhaps totally blind steps, followed by a filter on results. In the case of evolution, the filter is as beautiful as what's already there: the atmosphere, the biosphere. In code, your little almost blind steps will be filtered by the compiler and the other code you're interfacing with—not to mention other humans who use it all.

I'm afraid I've written something too simple to be worth recording, but I'll hedge that bet by sharing it. It will not be equally apparent to everyone at all times.

You know, mummification seems irrational and superstitious, but from a genetic and identity standpoint, doesn't it make perfect evolutionary sense? If mummies have recoverable DNA and we reconstruct the genome, the individual (or the family, genes overlapping) made a reproductive gamble that worked. And even reconstructing their face, their gait, etc, sends a message through time about who they were, etc. Maybe we shouldn't see mummification as bizarre and desperate so much as we see it as old, cutting-edge tech that wasn't available to everyone yet.

The oddest thing is that what would long since have been dirt is the greatest treasure in the tomb by far. Life still works through it.

(This reminds me of something I learned recently from a museum curator, that treasure was once seen as a particular material, but now we understand it's particular information. A real treasure chest contains bundles I can investigate, puzzle out, absorb, preserve, refashion, resurrect in use.)

I don't play games for the power fantasy of being able to do whatever I want, at any time, for any reason. For that level of freedom, close your eyes and use your imagination.

No game is as powerful and free as your life and your imagination. We must accept that. It isn't a flaw. It's a fact. It's the nature of the form. When you paint on a canvas, your ideas generally go inside a frame on a flat surface. You "make life" (to steal a term from the game Go) adhere to those conditions.

A game is simply another kind of canvas. The conditions are different from those of a hemp rectangle at the museum, covered in oily pigments. But the artist—and the viewer—is constrained nevertheless. That isn't a fault. It is the meaning of art that it cannot say and do everything at once.