Add articles to reading-entry

Jack Jackson 1 year ago
parent df876fdb49
commit 6f50defe58
  1. 28

@ -102,5 +102,33 @@ Plus [Rhythm Of War]( (re-read, incomplete)
* 12 by men, 10 by women - didn't quite make my >50% goal this year, mostly due to The House Of Niccolò taking longer than anticipated and my prioritizing of getting back into Sanderson to avoid being spoiled. In my defence, my non-re-reads this year were 10/6 female/male, but still - must do better! (Though I freely admit that I probably _won't_ next year due to the Sanderson focus)
* 16 fresh reads, 5 re-reads
# Articles
This year I cultivated a new habit of tracking notable articles I read, as well as just books. Some stand-outs:
| Title | Summary | Notes |
| [Horsehistory study and the automated discovery of new areas of thought]( | _The invention of new words provides new scaffolding for thought_ | Actually, this was read sometime earlier than 2022, but I only thought to note it down later. Nice to see a suggestion for using AI in a reasonable and justified way, as a tool within a process rather than as a magical panacea. This article also linked to the next one... |
| [Superhistory, Not Superintelligence]( | _Simple algorithms and more data beat complex algorithms and less data_ | Time-as-a-resource isn't particularly new. "Already-expended training time"-as-a-resource is cool (and the compounding effect is cooler). See also [How to become a centaur]( |
| [My first impressions of web3]( | _We should accept the premise that people will not run their own servers by designing systems that can distribute trust without having to distribute infrastructure.[...]We should try to reduce the burden of building software._ | From the creator of Signal. |
| [I Made A Linguistics Professor Listen to a Blink-182 Song and Analyze the Accent]( | "_I’m an American guy faking an English accent faking an American accent_" ||
| [Software Engineering In-The-Large: The Coordination Challenge]( | _How do you get the information into the heads of the people that need it?_ | A handy heuristic for a engineer's maturity is how much respect they give to the problems of "human scaling"; or, conversely, whether they look down on the discipline of project management. 99% of the time, the technological challenges of a large project are orders-of-magnitude easier than the organizational ones, to say nothing of the ongoing maintenance and information-management challenges after building is "complete". See also - Elongated Muskrat. |
| [What Game Are You Playing?]( | _...many of the people around me when I was growing up did not share my interest in science. I was quick to think that they were stupid. But what was really stupid was judging people by their performance **at a game they weren’t even playing.**_ | Tangentially related to the previous article ("_If you're not good at engineering, then you must be useless!_"), but also has the broader point that you should be consciously aware of what you're trying to excel at, and deliberately choosing it rather than accepting a goal you've been handed by your job, your society, etc. |
| [Guessing The Teacher's Password]( | When checking understanding, ensure you are actually doing so and not just testing pattern recognition | Eliezer Yudkowsky is a divisive figure, and arguably not a great communicator (see: the fact that this is the first article that I haven't been able to summarize with a direct quote!), but this is a great "mental shorthand concept" |
| [Make Things People Want]( | _Make Things People Want > Make People Want Things_ | I have a complicated relationship with advertizing. The anti-capitalist privacy-enthusiast in me believes it should be viewed as low-key brainwashing, weaponized memes. The idealist in me believes that it should be unnecessary if the product is good enough. The pragmatist in me recognizes that, _ceteris paribus_, the product that advertizes will beat the product that doesn't. This article takes a much less hardline approach, but the core message of that comparison rings true (there is much more to the article than just this perspective, but this was the one that resonated with me!) |
| [The Fun Scale]( | _the transient fix of \[shallow, easy, non-constructive\] fun rarely lasts, at least without something deeper, something committing_ | (Via [George]( Since hitting 30, I've been giving a lot more thought to "_how to live well_", and what that even means. My dear friend Olivia rightly scolds me when I talk about "_productivity_", worrying that I'm buying into capitalist brainwashing. While no-one is immune to propaganda and I agree that it's important to prioritize rest alongside "_doing things_", the word "_productive_" doesn't just mean "_making something that can be sold_" - it can simply mean "_doing something that results in a tangible outcome beyond just fleeting good-feelings (which are not themselves worthless!)_". You don't have to be productive _all_ the time, but equally you can be productive while resting if that rest is healthy and restorative rather than passive and over-indulgent. |
| [Markets With Interconnection: Why Are They Unfair?]( | _Advantages of scale compound, justifying corporations' obsession with growth - if you're third, you're dead_ | Via [Mel Conway](, he of Conway's Law. Christ, I hate corporations and the filthy water in which they swim. These evil egregores pollute and corrupt and grow, at the inevitable expense of real humans. |
| [Culture Matters]( | _"Three major tools that companies have to influence behavior are incentives, process, and culture_". While you cannot raise output quality _solely_ by "_encouraging people to care more_", cultivating an atmosphere of artisanship and high standards is invaluable. |
| [The Grug Brain Developer]( | "_apex predator of grug is complexity_" | An early watershed moment in my career was recognizing that Software Engineering is not about writing code, it's about delivering features. A later watershed moment was recognizing that it's not just about delivering features, it's about doing so in a way that accelerates, or at the very least doesn't slow down, the delivery of the next feature, especially with the context that the next feature will be written by someone without the context you currently have (which might just be "_you, but six months from now_".) |
| [The Most Powerful Razors]( | _Humans are wired to take shortcuts in our decision-making. These shortcuts can lead us astray—but when used appropriately, the shortcuts can be extremely valuable._ (No, not [this]( | (Via [George]( I'm a sucker for (useful!) cognitive shortcuts. One caveat to "_If someone uses a lot of complexity and jargon to explain something, they probably don’t understand it._", though - this doesn't mean that specialized vocabulary is always bad! Language is a tool, and tools can and should be evolved to particular use-cases. You need to tailor your language to the target audience, and provide explanations or definitions if appropriate (paticular shout-out to an ex-coworker who pushed back on the use of very industry-standard technical terms in a document, and in support of his position provided an article stating that Elon Musk opposed jargon. That aged well...) |
| [Good Conversations Have Doorknobs](| "_Neither \[conversational\] givers nor takers have it 100% correct, and their conflicts often come from both sides' insistence that the other side must convert or die.\[...\]When done well, both giving and taking create what psychologists call affordances - features of the environment that allow you to do something"_ | I am also a sucker for scientific analyses of social conventions that most people take for granted :) the [Hacker News discussion]( is also worthwhile for highlighting some different takes on the ideas, particularly the discussion off [this comment]( Another example where thinking about your audience's experience will make you a better communicator than if you just do what seems natural to you! |
|[Against SQL](| "_SQL is the only widely-used implementation of the relational model, and it is \[has serious drawbacks at complexity-scale\]_" | Ridiculing SQL (or [HTML]( is a good shibboleth for engineer immaturity - SQL is an extraordinarily powerful domain-specific language, and within that domain it is the undisputed winner. However, when used outside that domain it has some serious shortfalls. The broader point - "_use the tool that is optimal for your use-case_" (where "_optimality_" should take account of, but not be overruled by, "_do you currently have engineers who can use this tool?_"), also applies - reading [Seven Languages In Seven Weeks]( helped me see programming langauges as different ways of expressing concepts, with idiosyncratic strengths and weaknesses - neither better nor worse than each other, but possible to be misapplied! |
|[Why Are You Eating So Many Frogs?](| "_If you get a Chipotle gift card when you meet a deadline and a public shaming when you miss a deadline, guess what buddy: you’re in hell_" | A castigation-at-length of productivity culture |
|[The Dark Side Of Frictionless Technology](| "_Smooth simple tools reduce our patience and our attentiveness to complexity. Opaque tools, which abstract away complexity, discourage an expectation of repairability and encourage forced obsolescence._" | (via [George]( Seriously, you are already subscribed to his thoughts, right?) I have very mixed feelings on this. On the one hand, I'm also strongly opposed to [Builder Brain](, the Silicon Valley/Web3 delusion that all problems can be solved simply by building something new, rather than examining and addressing the causes of the problem (maybe with something new! Maybe with existing tools!). On the other hand, anything that advocates for _more_ friction or an upper-limit on abstraction triggers my luddite-detection circuits, no matter how much it is couched in the reasonable and worthwhile desires to remain in-touch with the real world. I'm filing this one under "_a perspective it's important to check-in with as a counterpoint to my natural tendencies, even if I mostly disagree with it_" |
|[Negative Engineering](| "_Negative engineering is the time-consuming and sometimes frustrating work that engineers undertake to ensure the success of their primary objectives.\[...It\] allows users to work with failure, rather than against it_" | Another one under the "_key part of software engineering maturity_" category. Junior engineers will implement the task as requested; middling engineers will consider ways that the task might fail, and implement safety checks for them. A senior engineer will assume that the system will fail in some way that they have not anticipated (recognizing that the system will evolve after they "finish" work on it!), and implement independent blanket monitoring and snapshot recovery methods for abstract categories of failure rather than specific foreseen issues ("_To take this a step further, consider what it means to “identify failure” at all. If a process is running on a machine that crashes, it may not even have the chance to notify anyone about its own failure before it’s wiped out of existence. A system that can only capture error messages will never even find out it failed._") |
|[On Proof And Progress In Mathematics](| Mathematicians should be primarily concerned not with proving theorems, but with expanding understanding of mathematics. Two corrolaries: "_collaboration, communication, and community are important_", and "_a proof which does not further understanding is less valuable than one that does_" ||
[^1]: I'm thinking of [Seven Habits]( or [Getting Things Done]( (Affiliate Links)
[^mistborn-is-sci-fi]: I'm a big fan of the definition of Science Fiction that it deals with "_how people or societies adapt to new capabilities provided by technology_" - under this definition, it's perfectly feasible to have a sci-fi story dealing only with established contemporary (or even historical) technology rather than lasers and robots and spaceships. I don't have a similarly pithy definition of Fantasy, but there's an interesting debate to be had about whether Mistborn even qualifies - it _probably_ does, but the discussion would be fascinating!