Ethan Mollick wxplains a recent Harvard Business School study examined the impact of large language models as collaborative “teammates” within Procter & Gamble. The findings revealed that employees augmented with AI not only outperformed those without AI assistance but also experienced notable productivity gains. Significantly, the integration of AI enabled specialists to transcend their narrow expertise, fostering more comprehensive and well-rounded solutions. This suggests that AI can effectively dismantle knowledge silos, enhancing collaborative problem-solving — a crucial insight for technical work in particular, such as in the cybersecurity field.
In Keeping Up with Current Events, I talked about the websites I turn to each morning to stay informed; in My Evening Reads, I shared the many others I follow on niche subjects. Podcasts, however, are another important part of how I learn and grow. Some offer regular updates on current events, while others dive deep into niche topics. As a complement to Keeping Up with Current Events and My Evening Reads, I wanted to start a list of the podcasts I follow here.
Let me save you some time: the Framework laptop is great, and you should buy it. The rest of this post will delve1 into the why, but that’s the “so what.�
I last wrote about my setup in May of 2019, almost five years ago. While some of those specifics have stayed the same, much has changed since then, and so I decided to write a new version of that article today. For ease of comparison over time, this post will—-for the most part — follow the same format as in 2019.
In a class a few days ago, the instructor trotted out Donald Knuth’s famous quote about premature optimization. Of course, as nearly every other instructor has ever done, he cherry-picked the catchy middle part: “Premature optimization is the root of all evil.” He did not, however, share the context around it. Here’s the full quote:
Thanks in no small part to OpenAI’s ChatGPT, the past year has seen an explosion in interest in artificial intelligence in general, and in large language models in particular. That democratization of access turned this niche research area into a common topic of conversation, and has led to a lot of fascinating writing on the subject. Although certainly not comprehensive, this article collects some of my favorite articles, papers, and resources into a single reading list.
A few weeks ago, I participated in a working group tasked with identifying areas where artificial intelligence and machine learning could improve network utilization. What, specifically, “improve” and “utilization” meant were some of the first questions we addressed. During that conversation, though, one of the participants made an insightful observation that the group promptly ignored. He told a brief story about how someone had asked him for a networking device that could aggregate multiple uplinks and then “use AI to choose the best one.” When he offered a simple WAN failover solution, a technology that has existed for decades and comes built-in to open source firewalls like pfSense, commercial appliances from the likes of Cisco, and every modern mobile phone, the customer told him, “No.” Like our working group, that customer person had a solution (artificial intelligence) driving their requirements (an AI-based WAN failover), not the other way around.
Over a year ago I read Matthew Strom’s article How to pick the least wrong colors, where he explored the fascinating intricacies of designing good color schemes. Here, “good” meant not just whether the colors looked nice, but also how distinguishable they were from each other and whether or not they accomodated individuals with conditions like protanopia, for example, who cannot see red light. He came up with a great solution and posted the NodeJS code to GitHub. Since I do most of my work in Python, though, I had few chances to take advantage of his research — until now. My latest project, Colors, helps to generate large sets of attractive and accessible color schemes. The current version of this project is, for the most part, a direct NodeJS-to-Python port of Matthew’s code from 2022 with a few minor changes, but I look forward to building on it and keeping pace with Matthew. Colors is currently available as a Jupyter notebook and a regular Python script.
I keep fielding this question in private, so I finally decided to answer it in public: “What SANS courses should I take?” Although I have a much longer answer to give about training in general, this article answers that specific question based on my own personal experience, having taken several SANS courses over the years.
I have, for years now, wanted a cool shell prompt — something worth showing off on r/linux or even r/unixporn. Not enough to dig into the weeds and figure out how to write one myself, but enough that it came up every once in a while. Then, the other day, I had a great idea: why not just let ChatGPT make it for me?
Both civilian cybersecurity practitioners and military defensive cyber operations personnel continue to push a similar idea, that to identify malicious activity one must “just get a baseline and then flag anything different.” If only! I call this the Baseline Fallacy:
Military leaders have sought hard data to drive their decisions for decades, perhaps most famously beginning with Secretary of Defense Robert McNamara’s so-called Whiz Kids’’ in the 1960s. As retrospective analysis of those decisions made clear, however, data alone does not good decisions make. Errors in collection, transmission, and presentation decimated the efficacy of this initiative.1 The Vietnam War is a cautionary tale in data-driven decision-making gone wrong, an important reminder that modernity’s insatiable need for more data is no more a silver bullet today than it was sixty years ago.
A few days ago, I mentioned that I use Git to synchronize work between several different devices and across several different platforms. This setup has served me well, and so today I want to talk about it in detail.
I have used git to synchronize work between several different devices and across several different platforms for quite some time now. Over the years, though, inconsistencies have crept in. The name attached to my commit messages, for example, might be “Zac” on one device, “Zachary Szewczyk” on another, and “Zac Szewczyk” when committing via GitLab’s web editor. The same applied to the email address attached to those messages. Elijah Newren’s git-filter-repo project made it a breeze to fix this.
My book Handbook for Defensive Cyberspace Operations contains an extensive chapter on tools and resources for cybersecurity analysts. As a closed project, however, this knowledge has had little impact outside of my niche community. This post contains a version of that chapter suitable for distribution to the public.
Like college degrees before them, professional certifications seem to be waning in popularity in the cybersecurity industry. Perhaps as a way to mitigate the well-documented workforce shortage, some companies have gradually begun to account for competence and experience, too, rather than onerous credentials alone — and in some cases, base their hiring decisions solely on those criteria. This is a localized phenomenon, though, exclusively limited to the private sector, and even there primarily limited to smaller firms. In the public sector, at many large firms, and particularly at large firms that work with the government, formal credentials such as a degree and professional certifications remain not only an important factor, but in many cases the only factor. This led me to take (ISC)<sup>2</sup>’s Certified Information Systems Security Professional (CISSP) exam earlier this summer. Even as a Cyber Operations Officer, credentials like this one carry great weight. I passed on my first attempt, so in this article I want to share my preparation strategy.
The other day, a member of SANS’s GIAC Advisory Board asked a question about Mean Time to Detection, or MTTD. In the ensuing discussion, another member cautioned against confusing key performance indicators used to assess individual efficiency, to then serve as the basis for penalties and rewards, with measures of program efficiency. Holding individuals accountable for MTTD, for example, made little sense when that detection relied on factors outside of their control such as effective data collection and efficient aggregation into a centralized platform, each of which were likely to be managed by a separate department. I alluded to the challenge of implementing metrics in part one, but did not deal with this issue specifically. This bonus article provides specific recommendations for applying SOC metrics to individuals versus an entire program.
It’s human nature to assume there’s a good reason for why things are the way they are. And that this reason is either benign, based on careful deliberation, or malignant, derived from malice or incompetence. But this is a false dichotomy that often steers us away from the simpler answer: Nobody thought about this at all.
Given an absence of information, many tend to fill those gaps with generous assumptions. At the beginning of Russia’s botched invasion of Ukraine, national security pundits considered it some sort of 4D chess game; time proved otherwise. No one knows what they’re doing, “It’s OK though — that’s not where your problems are coming from. Rather, your problems are coming from the fact that you think other people know what they’re doing.”
I went to a presentation from a large cybersecurity firm the other day. The salesmen — and they were all salesmen, as even a few post-presentation questions made clear — focused on the intelligence their company produced, but knew little about the rest of their company’s intelligence cycle. As a consumer of their products, though, I consider knowledge of the process that created them critical. After an hour on finished intelligence, and in particular a slide that touted a “globally deployed sensor grid”, I wanted to know more about that production process in general, and about their collection specifically. Unfortunately, when asked, the salesmen offered a handful of handwavy “We have millions of sensors across the globe”, and, “We ingest billions of events per day” statements, but little beyond that.
As a senior First Lieutenant, I volunteered to teach new Second Lieutenants about defensive cyberspace operations. Over the course of a year I spent more than twelve hours with three different Cyber Basic Officer Leaders Course (BOLC) classes; each time, they asked the same question: what did your missions ac- complish? Each time, I struggled for an answer.
In part one of the SOC Metrics series, I introduced the idea that success requires the right person doing the right things in the right ways. That article also described several foundational metrics, ways to measure the SOC’s ability to produce meaningful results. Part two then focused on measures of performance (MOPs), which assess whether or not (and to what degree) the SOC is doing the right things. This article delves into measures of effectiveness, the last step in defining useful SOC metrics.
In part one of the SOC Metrics series, I introduced the idea that success requires the right person doing the right things in the right ways. Measures of performance (MOPs) assess whether or not (and to what degree) the SOC is doing the right things, and measures of effectiveness (MOEs) assess whether or not (and to what degree) the SOC is doing them in the right ways. MOPs and MOEs rely on foundational metrics to produce meaningful results, though, and so I started with them in part one. This article delves into measures of performance, the next key step in defining useful SOC metrics.
I prefer a hands-off approach to management. Describe a goal, give me the freedom and resources to achieve it, and I will. The success of that approach, which the Army calls “mission command”, ultimately depends on the right person doing the right things in the right ways. Unfortunately, many focus on that first criterion but neglect the second and the third. In many cases, that leads to failure. In the final days of my last job, in a security operations center (SOC), I realized that this explained many of our systemic problems. We had the right people, they just did the right things in the wrong ways or — in some cases — did the wrong things altogether. This was not an inherent consequence of that hands-off approach, of mission command, but rather a necessary consequence of its partial implementation: we lacked measures of performance (MOPs), to assess whether or not (and to what degree) we were doing the right things, and measures of effectiveness (MOEs), to assess whether or not (and to what degree) we were doing them in the right ways. In their absence the right things and the right ways became inconsistent and subjective, and so did our success. I wrote this series to fix that.
I switched from Ubuntu to Windows 10 a few days ago. After eight years of macOS and then a year of Linux, I wanted to circle back to Windows.1 Since my latest writing project relies on XeTeX, a lesser-known typesetting engine within the already obscure TeX world, I expected some trouble recreating my workflow in Windows; I was not disappointed.2 This post explains the steps I went through to create a functional TeX writing environment in Windows 10.
The Army has a strange relationship with words. On the one hand, precision means everything: the term “seize” means something very different to a ground forces commander than the term “secure”. On the other hand, “leader” has become an umbrella term for both the entire force in general and the select few in command positions specifically. This has little impact on non-commissioned and warrant officers who — for the most part — will never command a unit; “leadership”, to them, means leadership: influence to accomplish a mission. For officers, however, the impact of this imprecision is significant.
I frequently encounter people eager to learn or interested in understanding current events but that do not know where to start. Many lack the experience to know what they should study. Others have become so disillusioned by the hyper-partisan twenty-four-hour news cycle that they just ignore current events altogether. While I have addressed those challenges in Personal Development and the two-part series Keeping Up with Current Events and My Evening Reads, respectively, those aggressively curated lists leave out many useful sources that did not make the cut. I just don’t have time to keep up with everything. This article highlights those sources as well as several other valuable resources. While I may not visit these websites often, these are my first stops when I must seek out trustworthy information on a range of topics. This article also links to several useful tools both as a way for me to keep track of them and as a way to highlight them to others.
Network defenders often struggle to obtain timely, accurate, relevant, predictive, and tailored intelligence about the enemy and other aspects of the operational environment. This document attempts to address that difficulty by detailing a single, curated list of reputable, open sources of threat data, information, and intelligence. This list combines traditional sources such as cybersecurity organizations that publish detailed reports (think finished intelligence) with non-traditional ones like social media that provide feeds more akin to information or raw data. While many others exist, I tried to stick to those with a high signal to noise ratio. That ruled out some decent sources, but I consider that a worthy trade off. Keeping up with this entire list would require a full-time job as-is, so while you may choose differently, choose wisely.
As I close in on my promotion to captain, mentorship has become an increasingly important part of my job. Many new lieutenants find the Basic Officer Leader Course just that — basic — and so they report eager to develop personally, professionally, and militarily. My article Personal Development addresses that first domain in terms of improving one’s personal, professional, and military knowledge, but neglects other areas. After several conversations with new lieutenants eager for professional development as officers and military development as warfighters, I decided to turn some of those discussion points into a post here. As a Cyberspace Operations Officer, most of this advice will target other 17-series soldiers, although some of it may help new officers in other branches. This advice is also not specific to officers, and in some cases may apply to enlisted soldiers as well.
Aside from maintaining my article on personal development, I have shared little about this profession of arms. As I close in on my promotion to captain, though, mentorship has become an increasingly important part of my job. After several similar conversations with new officers, I decided to answer a common question here: “What do I do as a new lieutenant?” While the answer to that question will change from branch to branch and from unit to unit, I decided to write about some advice that should generalize well. If you follow this advice during your first week, you will put yourself in a good spot at the beginning of your assignment and set you up for success in the long run.
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.
“You don’t have to be a genius to write fast programs. There’s no magic trick. The only thing required is not building on top of a huge pile of crap that modern toolchain is.”
Nikita makes a lot of great points about the general decline of software quality, many of which I have made before. It’s nice to hear this coming from someone else.
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.
From Paul Rascagneres and Vitor Ventura at Cisco Talos Intelligence:
“Our tests showed that — on average — we achieved an ~80 percent success rate while using the fake fingerprints, where the sensors were bypassed at least once. ... The results show fingerprints are good enough to protect the average person’s privacy if they lose their phone. However, a person that is likely to be targeted by a well-funded and motivated actor should not use fingerprint authentication.”
As I read Tomas Petricek’s On architecture, urban planning and software construction, it reminded me of an interesting point Dan Luu made in How (some) good corporate engineering blogs are written: “There’s a dearth of real, in-depth, technical writing, which makes any half decent, honest, public writing about technical work interesting.” Tomas’ piece reminded me of this not because it lacks substance, but rather for the opposite reason: his work stands out as a prime example of substantial technical writing. I recommend reading the entire piece, but I will highlight a few interesting points here.
First, on good software design:
“In Notes on the Synthesis of Form, Christopher Alexander points out that design always speaks of form and its context. A good design is not just a property of the form, but it is a matter of fit between the form and the context. The reason why we cannot evaluate an isolated form is not because we are unable to precisely describe the form itself, but because we are unable to precisely describe the context with which it will interact. ... Exactly the same limitations exist in the world of programming. No matter how precisely we can talk about programs, we also need to exactly understand the environment with which they interact. This is the hard part.”
The idea that suitability determination involves a multi-dimensional performance assessment on a scenario-by-scenario basis, rather than a simple checklist, is a departure from the process I often see. This approach represents a more complex process, and even a more fraught one, too — but, perhaps, also one that might deliver something usable.
And then on the unintended consequences of avoiding maintenance, later:
“When discussing maintenance, [Stewart] Brand mentions the cautionary tale of vinyl siding, which is used to avoid problems with peeling paint. Rather than repainting a wooden wall, you cover it with a layer of vinyl siding, which is durable and weather resistant. The problem is that vinyl siding blocks moisture and the humidity behind it can cause structural damage to the building. Many traditional materials have the attractive property that they look bad before they act bad and, furthermore, the problems with traditional materials are well understood. ... The lesson about using traditional materials has a relatively easy parallel. If you build software using tools whose problems you understand, you will be able to expect and resolve those problems. If you are using a new material, you will not anticipate where problems might occur.”
“By learning to use frameworks instead of the tools and protocols they implement, developers not only miss out on foundational knowledge that will help them become better at their job, but also hamstring themselves to the subset of features the frameworks’ creators’ felt important enough to enable. Expanding a project beyond that expected use case will require diving into those low-level tools and protocols.”
Mehul Mohan had a similar take in The Best Way to Learn Front End Web Development. I tend to have low expectations for articles that purport to have the answer, but Mehul delivered some sound advice:
“You see, frameworks exist to offload repetitive work from you. They do not exist so that you can not care at all what’s going on under the hood and rely on the fact that it’s all magic. The first time you choose a framework like React or Angular for your projects should be when you’re confident that you can create that project without React or Angular too.”
You should learn C not to use it, but because it will make you a better programmer. Learning C will help you understand the code that underlies your usable high-level language. node.js vinyl siding is cool, but do not ignore the old-fashioned tools it “replaced”: we used — and still use — them for a reason.
Steve and I came up hearing the same refrain: “Learn C, it’ll make you a good programmer — it’s how the computer works behind the scenes.” As he points out in his threepartseries, though, using C just means having a thinner abstraction layer between your code and the hardware on which it runs. That layer still exists. I do believe new developers should learn to work in this environment: understanding the code that underlies usable, high-level languages like Python will help you write better Python for the same reason that understanding assembly will help you write better C; I do not believe they should use it, though, and here’s why:
I have an innate distrust of all writing advice that seem to come from a large organization. I blame academia, for all those years I spent years reading and writing the most rigid, boring prose known to man. I prefer advice from actual writers — and that’s what I found in Harry Guinness’s recent article for The New York Times, How to Edit Your own Writing. He offers some great advice, and makes some excellent book recommendations. To add to that list, I also recommend William Zinsser’s On Writing Well, and Stephen King’s On Writing: Harry’s books focus on the mechanics, while these concern themselves with the craft.
I agree with Kev, that readers should have the ability to view my work in whatever format they please, but I still truncate the posts in my RSS feed. Here’s why:
Whenever I find a new writer, I go through everything they have ever written — turns out, good writers write good things often; this helps me find great works from their past. RSS feeds with, say, the site’s ten most recent posts make this much harder than ones with every article in them, so when I restarted this site, I took the latter route. Over a thousand posts would make my feed a hefty __ MB, though, so truncating the individual posts allowed me to strike a nice balance between the two.
Mozilla’s mistakes — although concerning — worry me less than Google’s methodical Internet takeover. Indulge me while I bring the uninformed up to speed: after eviscerating its competitors, over half the Internet now uses Chrome. This dominance gives its creator the power to force sweeping change across this decentralized system: although superficially optional, failure to comply means longer load times, lower search ranking, and lost revenue. Over the last few years in particular, the company has shown an increased willingness to wield that power with more and more aggressive mandates. Publishers who do not expose their content through Accelerated Mobile Pages lose viewers and income. Users who prefer other browsers, perhapsbecause they value their privacy, either cannot access many of Google’s popular services, or have to live with a degraded user experience. It all leaves a bad taste in my mouth. So while I find Mozilla’s mistakes concerning, I like the thought of supporting Chrome even less, so I decided to give Firefox another try.
Please don’t write your documentation in Markdown got a lot of attention last month, when Hillel Wayne said something both reasonable and familiar: Markdown’s simple syntax does not lend itself to complex technical documents. Antonio Zolotukhin made a similar point back in 2018, as others have before him, and more will in the future. Their argument makes sense; the idea that this is 1) a problem, and 2) needs addressing, however, does not.
“Some of the key management systems — 5 out of 73, in a Citizen Lab scan — seem to be located in China, with the rest in the United States. Interestingly, the Chinese servers are at least sometimes used for Zoom chats that have no nexus in China. ... The report points out that Zoom may be legally obligated to share encryption keys with Chinese authorities if the keys are generated on a key management server hosted in China.”
This just makes an adversary’s easy job even easier, though, thanks to the weak encryption scheme those keys facilitate:
“A security white paper from the company claims that Zoom meetings are protected using 256-bit AES keys, but the Citizen Lab researchers confirmed the keys in use are actually only 128-bit ... Furthermore, Zoom encrypts and decrypts with AES using an algorithm called Electronic Codebook (ECB) mode, ‘which is well-understood to be a bad idea, because this mode of encryption preserves patterns in the input,’ according to the Citizen Lab researchers. In fact, ECB is considered the worst of AES’s available modes.”
Bill Marczak and John Scott-Railton’s study, Move Fast & Roll Your Own Crypto, goes into more detail, and concludes with this key takeaway: “As a result of these troubling security issues, we discourage the use of Zoom at this time for use cases that require strong privacy and confidentiality”. Unfortunately, though, most of Zoom’s competitors don’t do much better.
Most articles focus on the negative side of giving anyone the power to publish: in recent years, it has enabled massive disinformation campaigns so effective that even its own citizens now question Democratic underpinnings of the world’s premiere superpower. In Zero Trust Information, though, Ben Thompson argues that while this power did lead to an increase in misinformation, it also lead to the proliferation of much more valuable information, too. For proof, one need only look to the Seattle doctors who defied a government gag order to share their findings on COVID-19.
In last month’s release notes, I talked about First Crack’s rewrite: the things I set out to accomplish, the changes I made, and their performance costs. Although a simple fix later slashed First Crack’s runtime, I waited to post the code until I could talk about a few things here.
I brought up preparedness for the first time last year, in Building a Better Bug-Out Bag. As I said there, though, my history with this mindset goes back much further than 2019:
While I do not feel as strongly about online advertising assome, the more I read about sensible solutions to the plethora of problems it causes, the more I come around: ban targeted advertising — if not wholesale, then perhaps to groups below a certain threshold. One article suggested a ban on targeting groups of less than 1,000 people, and that sounds like a good start to me.
“I ask where he thinks this dysfunctional system [the fragile global food distribution system] has come from. ‘There is a culture of British exceptionalism. We were the first industrial nation in the 18th century and then became the dominant imperial power in the 19th century and pursued that as a way of feeding ourselves.’ Critics often point out that we were less self-sufficient in food in the early 20th century than we are now. True, Lang says, but that was specifically because we had an empire which we ravaged to keep our tables and bellies full.”
Add a century and replace “British” with “American”, and Tim Lang’s words apply just as well to the United States. Like Tim, I hold out hope that the nation will wake up and make a change; you would have to be a fool to bank on it, though. Exercise your individual liberty now to prepare for the all too likely crises ahead. Far too many are content just to whistle past the graveyard.
“An answer to the now age-old ARM-ed Mac question now emerges: With the emphasis on the iPad Pro as a real computer, there’s no reason for Apple to move the Mac off of trusty if perhaps less glamorous Intel processors.”
If I may finish his sentence, “... there’s no reason for Apple to move the Mac off of trusty if perhaps less glamorous Intel processors, because the iPad will soon replace the Mac.” As for when this will happen, I don’t know — and if Jean-Louis does, he’s not saying. With each passing year it becomes more feasible from a technical standpoint, but it will take a sea change in Apple’s strategic thinking for this to actually happen.
This reminds me of the electric car situation: they have gotten pretty good, but at least for my use case, they aren’t quite good enough. I can see that this will change soon, but — again — it will take a sea change in strategic thinking to make this happen. In this case, that means automakers stop trying to turn a truck into an electric truck, and start designing vehicles to take full advantage of all this new technology enables.
As I start shopping around to replace my trusty 2013 MacBook Pro, I hope Apple will make its decision soon.
As I have said before, I believe in premature optimization. It leads to better products in the long run, and if optimized along the proper vectors, more secure ones, too. It’s nice to see that Oleksandr Kaleniuk agrees.
“The kernel developers view of the docker community is that in the rare case they can actually formulate the question correctly they usually don’t understand the answer.”
Hilarious. Ian also got at a critical point about the state of modern software engineers, something I touched on a few weeks ago when I linked to Good TImes Create Weak Men. Short-term, push-button fixes attempt to get around the long, hard, and expensive problem of developing and deploying expertise. Like outsourcing, while the former approach has short-term benefits, its long-term effects are debilitating.
Dan Moore’s 2018 post, When do you earn your pay?, reminded me of something I told one of my friends a few years ago. Both senior ROTC cadets at the time, he had just finished complaining about how our instructors always blamed him when other people did the wrong thing. “You’re not here for things to go right,” I told him, “the only reason our job exists is to fix things when they go wrong.” This leads into a larger point about the role of Officers in the Army, but I need to spend more time thinking about that before I start writing about it; for now, this will have to suffice.
“Americans have gone west to escape the ills of society while bringing the ills of society with them, pretty much since Manifest Destiny; one regional myth was that, once here, everyone would have the chance to experience something wild. In reality, of course, settlement always brought land-access issues, prompted human displacement, and fueled socioeconomic disparity. That remains true now, as Billionaire Wilderness makes evident through its examination of one of the most beloved playgrounds of this part of the nation.”
Simple systems deploy faster than complex ones, and fail less often; sometimes they take less time to build, too, but the pursuit of simplicity often entails a long process to prioritize some features while justifying the exclusion of others. Ironically, that process tends to take much longer than just building in all the features, so most choose the latter approach. The end result is complex software that does many things, but few things well.
As a fan of premature optimization, I like to take the opposite approach, and to take it to the extreme. My software — and even my devices — tend to do one thing well. This makes the upfront cost higher in terms of time spent planning projects, writing code, and purchasing hardware, but also — since I understand and control the entire stack — lowers the number of opaque systems that can fail as well as the knock-on effects of such an event. I consider this a worthwhile tradeoff, and I bet Greg would, too.
In a similar vein, check out 507 Movements for — get this — 507 different mechanical mechanisms. When I run into a novel engineering challenge, I always try to solve it in a simple mechanical way first. Computers are great, but there is a certain elegance to simple machinery for which I have great appreciation.
I had a busy start to the year. Between traveling and work, I did not have enough time to finish the titanic task I had given myself: rewriting First Crack. When it came time to post the January release notes, then, I did not have anything ready; today I do.
I don’t likedependencies, but excusing one language’s reliance on bucketloads of them because others use built-in libraries misses the point. I care about the number of dependencies I have to install just for your project. On a system full of libraries that could have met most of those requirements, as evidenced by other, similar projects that do not need hundreds of extra packages, the fact that yours does gives me pause. The fact that this language seems to cause this leads me to believe some fundamental shortcoming must exist. Let’s not excuse that.
Speaking of Kevin Kelly, he wrote an interesting article examining the Amish’s relationship with technology.
“They don’t adopt everything new but what new technology they do embrace, they take up about half a century after everyone else does. By that time, the benefits and costs are clear, the technology stable, and it is cheap.”
Over a decade ago, Keven Kelly put forward the idea that creators could earn a living from 1,000 fans. In this piece, Li Jin proposes that they can do the same from 100 super fans. Crucially, though, as the number of patrons goes down, the value that creator provides must go up. Many seem to forget this last point, and see headlines like these as evidence that they can somehow make it with 1,000 subscribers or 100 readers. It just doesn’t work. Understand the tradeoffs, make a realistic plan, and never quit.
I read a few of Marcus’s posts, and liked themall, but it was his link to an interview with Ira Glass that made me post this. Most have heard this many times before, but it bears repeating: doing good work means first doing a lot of bad work, and having the tenacity to get through those discouraging times. The great creators, to whom far too many aspiring creators prematurely compare themselves, made it through because they pressed on. Success is not a mystery, it’s just hard. Put in the work to get there.
“It’s suspiciously convenient that Facebook already fulfills most of the regulatory requirements it’s asking governments to lay on the rest of the tech industry. ... We already saw this happen with GDPR. The idea was to strengthen privacy and weaken exploitative data collection that tech giants like Facebook and Google depend on for their business models. The result was that Facebook and Google actually gained or only slightly lost EU market share while all other adtech vendors got wrecked by the regulation, according to WhoTracksMe.”
Suspicious, no; convenient, yes; par for the course — also yes. What a surprise.
I took two weeks off work around Christmas. I spent the first touring Arizona, and the second at my parents’ farm in Ohio. After a 605lb deadlift PR in early December, I felt like a break from the gym. Plus, I did not workout for the three weeks I spent driving up the east coast in 2018. Gym access did not factor into this trip’s planning process either, and so over those fifteen days, I worked out three times. Today, I want to share some thoughts about fitness on the road.
I like most of Leo Babauta’s work, but this one disappointed me. He titled it The Honest Guide to Mindfulness, but a more apt title would have been The Honest Guide to Meditation — because he talked about nothing else. Meditation, though, is a practice some have used to become more mindful, not the goal itself, and by no means the epitome of mindfulness.
My favorite explanation of mindfulness came from an episode of Back to Work, in which Merlin Mann described it as the ability to watch cars go by without feeling the need to jump in. The patent absurdity of this analogy made the value of mindfulness value clear, when he explained that the cars symbolized our emotions: temporary, quick to change, and far too often dictated by people and situations over which we have no control. The goal of mindfulness — which, again, some have found through meditation — is not to do the impossible, to wrestle back from a chaotic world command over those cars, but rather to regain control of the one actor in that scenario you have any hope of influencing: yourself.
You will never control which cars come, when they go by, or who drives them, but you can — with practice — learn to control their ability to hijack your life. An honest guide to that, real mindfulness, may have done some good.
This is such a cool idea: Denis Shiryaev used Gigapixel AI’s neural network to upscale a classif video from 1896 into 4k; as Timothy Bee points out, a similar approach could then add color.
One of my long-term projects involves making the small part of the internet I use every day available offline. As I lean toward a more nomadic lifestyle, I may not always have ready access to the familiar shows I stream on Netflix, for example, or that one news article from a few weeks ago. A single hard drive could store everything I have ever watched, read, and listened to, though, and so I want to make that happen. This goes well with one of my other long-term projects, which involves curating evergreen digital media for posterity’s sake. Think of the former as every movie I have ever watched, and the latter as the classics I want to save for my kids. There are many subltle challenges to this, but none so obvious as the fact that even video from a few years ago looks bad on modern displays. Denis’s demonstration gives me hope that this may not always be the case.
In the last lightning round, I promised that these posts would give me somewhere to share things that used to slip through the cracks. Today I have two.
I love stories like Adam’s. Too many people propose complex solutions to simple problems because they get excited about building something cool, and lose sight of their actual purpose: building a useful tool. I see this all the time at work. In this case, another developer used a Big Data approach for a Small Data problem, and Adam shows how a much simpler — but less cool(?) — one would have got it done much, much faster. Had this other developer understood the underlying technologies, and taken some time for premature optimization, he might have gotten there himself.
I talked about my road to weightlifting a few months ago, and then the price of trading strength for conditioning. Today I want to look at the other side of that coin. After regaining the ground I lost in February and March of last year, I want to talk about the challenges of trading conditioning for strength.