“For those of us in the Sweden tribe, we come to exactly the opposite conclusion from the same evidence: that lockdowns only pointlessly drag out the pandemic and artificially increase its costs, since no matter how long we hide, the disease is still there to infect us when we come out.”
For many, COVID-19 has been a nightmare. Thousands have lost loved ones, most of them elderly aunts, uncles, and grandparents who may have lived years longer if not for this virus. For most, though, COVID-19 has been a nightmare for different reasons. Those who found themselves unable to work soon also found the government’s supposed safety net at best inadequate, and at worst inaccessible. The lucky ones managed to keep a roof over their families’ heads. It’s hard to say which kids had the worst academic year, the ones whose school just threw in the towel or the ones whose school put a brave face on substandard Zoom “classes” and busywork “homework”. The charitable parents hedge their experience with “Well, they’re doing their best...”. Domestic violence skyrocketed: those once figuratively trapped with their abusers now literally have no escape. Mental health hastaken a nosedive. As we stand on the cusp of another months-long semi-lockdown, we face a continuation of this waking nightmare — a nightmare of our own design. Today I want to talk about what we should have done, and where we ought to go from here.
If I like an article, I look into its author. Most good writers write well and often. This helps me find independent websites, like Ben Kuhn’s blog. In his 2018 piece, Stop Trying, Ben talks about steps he took to better his life: tracking time with RescueTime, and waking up with automatic lights. His productivity went up, and he gets out of bed on time now — because these changes required “literally zero maintenance”. He tried to make productivity and wakefulness a habit, but did not succeed until he built systems around those two goals. From Stop Trying:
“When you notice yourself avoiding something hard or uncertain ... the method is to turn towards it. Turn towards what you’re avoiding. Open to the discomfort, embrace it as training and growth. Bring curiosity. Do it even when you don’t feel like it. This is the training. The simple method makes it easier. Take it on, and see what happens.”
As I have said before, and will keep on saying, there is no shortcut, life hack, or trick; grind.
Not long after I found an old piece on attribution from Thinkst Applied Research, Cisco’s Talos Intelligence group posted an article on the same topic. Attribution is fraught, as both pieces explain. IP geolocation is woefully inaccurate, many of the tactics, techniques, and procedures tied to specific actors are either so common that they apply to several groups or so general that they might as well, and the proliferation of viable tool sets has made even this metric unreliable. At best, we can attribute activity with a degree of certainty — but never complete confidence, and you should be circumspect of anyone who does.
“Most of us have an expectation that we should feel in the mood to do something. We should be excited, rested, focused. And when we do it, it should be easy, comfortable, fun, pleasurable. Something like that. That results, predictably, in running from the things that feel hard, overwhelming, uncomfortable.”
You will not always feel like taking the hard road, but achieving success means defining a goal, making a plan to accomplish it, and then applying unmitigated daily discipline until you get there. There is no shortcut, life hack, or trick; grind.
Outsourcing has put America in a precarious position. It quietly became one of the greatest threats to national security over the course of several decades, unrealized until the Coronavirus pan(dem)ic revealed the fragility of our situation. David Adler and Dan Breznitz, in the American Affairs Journal, discuss the issue and offer some concrete suggestions for fixing it. I encourage you to give it a read. See also: On National and Enterprise Outsourcing, and Out-Sourced Profits: The Cornerstone of Successful Subcontracting.
A smart person knows everything about a single topic. An intelligent person knows as much as possible about more than one topic. Both have great value, and depending on the industry, some organizations value one more than the other. In general, though, smart people fill entry-level jobs, who then become intelligent people to move up the ladder1. A robust personal development strategy will help you go from the former to the latter.
As best I can remember, I have bought seventeen backpacks in my life. Seven backpacking ones1, and a mix of ten book bags and assault packs2. Each time I bought something new, I upgraded in some way. I went from the Teton Sports Scout 3400 to the Texsport Wolcott because it carried better. Next came the Kelty Falcon 4000 because I needed more space and wanted greater versatility and modularity. I continued pursuing those goals in purchasing the Eberlestock J79 Skycrane II, which I eventually replaced with the Mystery Ranch Terraplane. With nine more liters of space yet coming in at 60% of the weight, I could not rationalize sticking with the Skycrane II no matter how much I liked it.
“It’s tempting to simply laugh off these ‘free market’ fetishists as they get their comeuppance when Alex Jones and the Daily Stormer get kicked off the internet, but that is to miss the wider point: we are now in a speech environment where power is so concentrated that the whims of a half-dozen tech execs determine — for all intents and purposes — who may speak and what they may say. If you think that power will only be wielded against Alex Jones, there’s a bunch of trans activists, indigenous activists, anti-pipeline activists, #BlackLivesMatter activists, and others who’d like to have a word with you.”
Back in December, I applauded Mark Zuckerberg for continuing to push back on demands that Facebook clamp down on its users’ speech. As I said there, “The idea that [Facebook] should also [, in addition to commanding an unprecedented amount of the world’s time and attention, ] become the arbiter of truth boggles my mind.” Cory Doctrow, in Inaction is a Form of Action, does a great job explaining why this disturbing trend ought to concern you.
Megan McArdle making a great point, writing for The Atlantic:
“If you see a person — or a company — doing something that seems completely and inexplicably boneheaded, then it’s unwise to assume that the reason must be that everyone but you is a complete idiot who is blind to fairly trivial insights such as ”people desire inexpensive and conveniently available movie services, and will resist having those services made more expensive, or less convenient“. While it’s certainly true that people do idiotic things, it’s also true that a lot of those ‘idiotic’ things turn out to have perfectly reasonable explanations.”
Everyone has their reasons — and everyone else has a reason for why those reasons are dumb. In leadership, as in writing, it’s important to remember the latter, and recognize the patent absurdity of the former.
In a draft titled Starting Over, I try to condense a decade’s worth of outdoor gear experience. The 8,000 word missive, started in 2017, highlights “The Gear I Would Buy if I Had to Do it All Over Again”. After thousands of dollars spent searching for the best of the best, it tries help those just starting out avoid some of the expensive lessons I had to learn. That post has not left my drafts folder, though, in part because the list keeps changing. Two weeks in Arizona made me reconsider my chosen boot, the Vasque St. Elias GTX, plus I need to try the new Phantom 50 I bought while there to go with my Matador Freerain 24. I want to move to a more lightweight and season-agnostic setup, and I will have to see how that plays out before I publish the be-all, end-all list for aspiring adventurers. Until then, take a look at these sites. I do a lot of research before I buy, and that research starts here.
“As pre-Covid life fades into history, large sections of the professional classes face a version of the experience of those who became former persons in the abrupt historical shifts of the last century. The redundant bourgeoisie need not fear starvation or concentration camps, but the world they have inhabited is evanescing before their eyes. There is nothing novel in what they are experiencing. History is a succession of such apocalypses, and so far this one is milder than most.”
As far as disaster’s go, COVID-19’s direct effects have been far less impactful than its indirect ones. Once we have some distance from the event, and can look back on it with less bias, it will become clear that the panic that led to a national shutdown and then economic stagnation caused far greater pain and suffering than the disease ever could have, even if we had taken no action. This should be the legacy of COVID-19: not that of a deadly physical disease, but rather a panic-inducing mental one.
Every time I see an article like this one, I think back to something Horace Dediu said in Making rain:
“I propose a way to think about [the Facebook Home and the Google Fiber issue] as: Google tries to make a business succeed through having a huge amount of flow in terms of data, traffic, queries and information that is indexed. So think about this idea of them tapping into a vast stream. The more volume that is flowing through the system the more revenue they generate.”
Another interesting piece, among several others, on encouraging writing within an organization. As I prepare to move on to a new role, I’m happy to report that my team’s efforts to publish an internal written product on a regular schedule has gone well so far. I hope it continues in my absence, and I look forward to starting a similar project with my next team.
Today I announce a new project: Swig. Swig is a monolithic, multithreaded, micro web framework designed for an air-gapped intranet environment. Aside from Python 3, it has zero dependencies; just download and deploy. Out of the box, Swig supports IPv4 and IPv6, HTTP and HTTPS, block and chunked responses, and gzip compression. I encourage you to go through the README for more information, and to check out the code on GitHub repo.
If you looked at First Crack’s internal commit history, you would see that most features take at most a few days to write. Even the entirety of First Crack’s rewrite happened over the course of a couple weeks, in the mornings before work and on the weekends. I have stuck with monthly releases since June of last year, though, and today I want to explain why.
I happened across The Law of Requisite Variety the other day, which states that a system for which D possible disruptions exist requires R countermeasures to keep itself stable, where R >= D. Having spent some time on my projects’ more theoretical side lately, I found this idea at once interesting and then familiar. Today, I want to talk about the simple way I apply this concept to my code, as a way to architect more reliable programs.
I spent most of my development time in April working on a project that I can, at best, call tangentially related to First Crack. After fighting with Flask, Bottle, and then Python’s own http.server library, I decided to write my own web framework. I won’t spend much time on this now, since I plan to deploy it in an Intranet soon and then release it after some real use, but I will say this: I liked Flask, but it has far too many dependencies to work in my target environment. I liked Bottle even more, since it mirrors most of Flask’s functionality without any dependencies, but it lacks the ability to handle concurrent connections. The surprisingly capable http.server library has zero dependencies and supports concurrent execution, but is ill-suited for building out an entire web application. My project, Swig1, solves all of these problems. For now, though, let’s talk about First Crack — a day late, yes, but I hope not a dollar short.
I opened Tobias Pfeiffer’s article expecting something along the lines of Your configs suck? Try a real programming language. Tobias focused not on configuring the environment, though, but rather best practices for configuring the control flow in the program itself. “Early Validation” was a particularly good point. Tobias has some sound advice, most of which I incorporated into the dev projects I started during the shelter-in-place period. I hope to talk about them more soon.
Cal started strong: his recommendation that experts improve the decentralized distribution of critical information by moving beyond Twitter, the original microblog, to their own blogs hits the nail on the head. I cannot agree more. I wish I could say he finished strong as well, but he just completely missed the mark. In closing, he played up the importance of institutional backing for these sites as a way to lend them credibility. As Ben Thompson explained in Zero Trust Information, though, not only have most of the institutional players put forth bad information throughout this crisis, they actively sought to suppress critical (factual) information as well. Although not all did so knowingly (some just sought to suppress dissenting voices), some did; the idea that we can improve the shortcomings of Twitter with greater institutional oversight is unbelievable. Read the first half of Cal’s piece and then close your tab; the rest is just ridiculous.
“With over 20 years experience at the time I recognized the first obvious flaw [with test-driven design]; writing tests prior to coding is mindful of the old adage about no battle plan surviving contact with the enemy. ... The second problem here is that TDD presumes that developers should write their own tests. This is supremely ridiculous. I’ve seen this many, many times; the project appears solid to me, I can’t break it, but someone else can break it in less than a minute. Why? Because the same blind spots that I had in design will appear in my tests.”
I have avoided test-driven design for similar reasons. For my projects, I like to start by defining performance goals; I write a few test cases for each feature I finish as I finish it, then move on. This has all the benefits of test-driven design — defining requirements up-front, clear success criteria, objective verifiability throughout the development process and at its conclusion — without the downsides Chris highlights: wasted effort and lack of actual code coverage.
I cannot stress the importance of unit tests enough: when I wrote a socket web server in Python, they gave me an easy way to make sure each change did not unintentionally break a key performance objective I had already checked off. This saved me hours of periodic, manual, boring checks. I have no such affinity for test-driven design, and I would encourage you to reevaluate your loyalty if you do.
The Internet succeeded in no small part thanks to the humble hyperlink. The link enabled it to flourish as a network rather than languish as a series of closed silos, which led to its widespread adoption and the prevalence it enjoys today. Although a disturbing trend of centralization has emerged in recent years, many people have made great efforts to combat it; they may yet succeed. Their efforts have relied on the link to bring users together, re-focusing the spotlight on this unassuming yet important tool and highlighting the importance of attribution as both the currency and the lifeblood of the Internet.
Modern computers have gotten so complex that the prospect of trying to understand them intimidates a lot of people. Unfortunately, many use that fear as an excuse not to even try. Nelson Elhage has some great advice for tackling this gargantuan task.