It's a book about North Korea taught me how far to go when running a kleptocracy.
Pretty much every chapter of this book could have started with the sentence "But it gets worse." Prison camps, kidnapping… And other nations help to keep the system shambling on because we worry that collapse would kill even more people.
- Can you starve your population, as long as you keep your army fed? Yep, you totally can. It doesn't backfire.
- Is advancing a nuclear program really a good way to get appeased? Yep, you totally can. It doesn't backfire.
This book's a little dated. It points out that Kim Jong Un should keep an eye on his uncle; past tyrant-heirs have been deposed by uncles. Since the book has come out, Kim Jong Un had his uncle killed. Maybe he read the book. This book is dark, dark, dark. If you plan to read it, plan out some get-togethers with friends and loved ones to break up the bleakness.
Wow, it's the site's 27 millionth it. As usual, these "hits" aren't a measure of humans visiting pages; that count would be much lower. It's just requests to the website: every time a robot visits some page, the count goes up. If a human views a page that contains a dozen graphics, those graphics cause another dozen hits. So it's not as impressive as it sounds. But it's easy to measure so that's what I measure. We can take a look at the log:
22.214.171.124 - - [04/Mar/2015:16:16:39 -0400] "GET /new/2010/12/04/charitable-giving-for-people-with-tiny-mailboxes/ HTTP/1.0" 200 4051 "-" "CCBot/2.0 (http://commoncrawl.org/faq/)"
This is not a human, it's a bot. It claims to be working for commoncrawl.org. There are many crawlers on the web—computer programs that try to download a copy of (much of) the web by fetching some web pages, seeing what other pages those pages link to, downloading those pages, and thus "crawling" from page to page. Many organizations do this; it's a little silly, a kind of wasted effort. Common Crawl crawls the web to get a copy and gives copies away to people. So if you're, say, a grad student studying link patterns on the web, you don't need to crawl it yourself; instead get a copy from Common Crawl and start studying.
I'm glad that Common Crawl visited my site so that plenty of grad students can try to make sense of it.
Anything worth documenting is worth documenting well. But not everything is worth documenting. And I think this guy would agree with me:
Recently I’ve started to see documentation as a psychological band-aid, and as a sidestep to improved products.
Documentation, Support, and Customer Success
"The city you love disappears
–"The City Disappears"
But not before leaving
Its mark on you"
In this memoir, Bernard Moitessier sails around the world solo. By the end, he either achieves some enlightenment or goes kinda loopy from being on his own for a few months. There is sailing. There is inter-boat communication via slingshot. There is strategic napping. No, really—rather than take on some complex navigation while sleepy, he would heave to and take a nap so he'd be rested. It makes sense—but it's not the first thing you think of when you think of tales of derring-do on the open water.
If someone asks you for a cigarette, you hand one over. That explains the guy I overheard:
If you smoke on the bus, nobody asks you for one.
I hope that remains the most antisocial thing I hear today.
If you're into election technology, a new blog to follow: Law Offices of Lowell Finley. Remember when California was reporting folks trying to sell us so-bleeding-edge-it-aint-really-working-right-yet election stuff? And other states had elections tampered with, but at least California didn't have 4chan electing Carrot Top to be our insurance commissioner or whatever. Lowell Finley is part of the team who made that happen. I bet his blog will have many cringe-worthy stories which could be pretty funny as long as they happen someplace I don't live, e.g., Del Mar.
It's a book about risk-taking at Pixar. If you're creating new things, you're taking risks: some of those new things won't work right. They almost certainly won't work right on the first try; you'll need to try them out, improve them. If "you" is a company, you have to second-guess our human tendency to shun/punish failure. It's all very well to want to learn from failure; how do you actually do it? Maybe reading how they do it at Pixar will help.
Part of the answer is simple: If we as leaders can talk about our mistakes and our part in them, then we make it safe for others. You don't run from it or pretend it doesn't exist. That is why I make a point of being open about our meltdowns inside Pixar, because I believe they teach us something important: Being open about problems is the first step toward learning from them. My goal is not to drive fear out completely, because fear is inevitable in high-stakes situations. What I was to do is loosen its grip on us. While we don't want too many failures, we must think of the cost of failure as an investment in the future.
It's not clear how well Pixar's learn-from-failure approach translates to other organizations. At Pixar, some movie-story smarties hear how projects are going and suggest changes. If you're trying to engineer better software, you might get more oomph by measuring and improving… then again, you might still need some smart folks to tell you what's worth measuring in your situation.
"You can't manage what you can't measure" is a maxim that is taught and believed by many in both the business and education sectors. But in fact, the phrase is ridiculous—something said by people who are unaware of how much is hidden. A large portion of what we manage can't be measured, and not realizing this has unintended consequences. The problem comes when people think that data paints a full picture, leading them to ignore what they can't see. Here's my approach: Measure what you can, evaluate what you measure, and appreciate that you cannot measure the vast majority of what you do. And at least once every once in a while, make time to take a step back and think about what you are doing.
I've thought a lot about about technical documentation for software developers—writing things down that, when read, help computer programmers to figure out their jobs. Alas, it's tricky to measure. Nobody's come up with a way to measure engineer "output". (Well, nobody's come up with a good way to measure engineer "output".) So we don't really know whether some document's improving that output or making it worse. Thanks to web analytics, we can measure how many times some page is read. And it's good to measure that—if you have time to polish one of two pages, you want to prioritize the one that many folks read. But you shouldn't fall into the common trap of using number-of-times-page-read as a measure of how documentation is helping an engineering organization. You're measuring a cost; it's sad that engineers are taking time to read documentation; you hope the documentation is good enough to justify this time cost.
It's like the opposite of the sunk cost fallacy. I've put hours into roughly prototyping this puzzle. Now I'm hoping that playtesters think it's totally boring so I don't feel obliged to put in the time to get it perfect.
They're not exactly self-fulfilling prophecies, but they're self-something somethings.
I got an electric hot-water kettle. I'm just that lazy, I wanted it to be easier to boil water; it seemed extravagant, seeing as how I didn't boil water so often. But that kettle turned out to be totally worth it—but only because, now that I have it, I boil much more water than I used to, because it's so easy.
It's a good thing that chocolate candy was individually-wrapped: I dropped it and it fell on the floor and it would have got dirty if not wrapped. And why did I drop it? Trying to extract the candy from its wrapper.