Interesting articles
General
No one actually wants simplicity
Simplicity is sacrifice. See also:
Good designs expose systematic structure; they lean on their users’ ability to understand this structure and apply it to new situations.
Programming
The Configuration Complexity Clock
Programming languages, configuration files, DSLs for configuration
A unified theory of broken software
The advantages of focusing on a single language and how performance and static typing are helpful.
Finding and Fixing Standard Misconceptions About Program Behavior
About the Standard Model of Languages (SMoL)
A view I disagree on about IAGNI and the opposite concepts, but interesting
Static types are for perfectionists
Our programming style is influenced by our personality and life
The history about Hungarian notations
What We Know We Don't Know: Empirical Software Engineering
40-minute video about the power of proper sleep, working schedules and stress levels vs. engineering practices
Second of a series of three articles comparing software engineering with traditional engineering. Mostly dispels some myth and lack of knowledge about traditional engineering.
Testing
Testing on the Toilet: Risk-Driven Testing
"Your tests are a means. The bang is what counts. It’s your job to maximize it."
SMURF: Beyond the Test Pyramid
Test categories and the pyramid are excessively limited models.
Python
Python’s "Disappointing" Superpowers
A convincing defense of dynamic typing
Rust
The Mediocre Programmer's Guide to Rust
How to Avoid Fighting Rust Borrow Checker
Optimization
The Oracle Performance Improvement Method
My favorite text about performance tuning- the good advice is not Oracle-specific. Includes a bit more real-world advice than:
Rob Pike's 5 Rules of Programming
The Performance Inequality Gap, 2024
How web bloat impacts users with slow devices
About janky browser applications and websites.
Git
Git Tips 3: Really Large Repositories
Accessibility
The text mode lie: why modern TUIs are a nightmare for accessibility
Systems
In defence of swap: common misconceptions
Organizations
Pragmatism, Neutrality and Leadership
(The parts about "As a leader, your job is to succeed", "Companies with shitty cultures win all the time".) This article connects with:
Why people should multiclass engineering and management
How organisations cripple engineering teams with good intentions
Arguments for having coders code
Generative AI Is Not Going To Build Your Engineering Team For You
Bad title; it's about the need for junior coders
Things You Should Never Do, Part I
About rewriting software from scratch
Some observations concerning large programming efforts
Someone figured most of it out in 1964.
The tyranny of structurelessness
Well-Kept Gardens Die By Pacifism
About moderation in small communities
Project management
An epic treatise on scheduling, bug tracking, and triage
No non-sense opinions on project management I mostly agree with
News
The Truth Is Paywalled But The Lies Are Free
Excellent title, but the article is so-so
Society
Contra la tecnocratizaciĂłn de la vida
About the pressure of the modern age and the privilege of being mediocre
Face it: you're a crazy person
Choosing a job because you like the worst parts of it
Epistemology?
The Relativity of Wrong by Isaac Asimov
All physics theories are strictly "false", but they are very true.
Meta
Essays on programming I think about a lot
A Programmer's Reading List: 100 Articles I Enjoyed (1-50)
Infrequent but useful terms
A collective fallacy, in which a group of people collectively decide on a course of action that is counter to the preferences of most or all individuals in the group, while each individual believes it to be aligned with the preferences of most of the others.
A cognitive bias in which people with limited competence in a particular domain overestimate their abilities. Some researchers also include the opposite effect for high performers: their tendency to underestimate their skills. In popular culture, the Dunning–Kruger effect is often misunderstood as a claim about general overconfidence of people with low intelligence instead of specific overconfidence of people unskilled at a particular task.
A Statistical Explanation of the Dunning–Kruger Effect
This effect might only be caused by subjects in the bottom quartile can only make optimistic errors placing themselves into a higher quartile, while subjects in the top quartile can only make pessimistic errors placing themselves in a lower quartile.
A cognitive bias describing the tendency of individuals to critically assess media reports in a domain they are knowledgeable about, yet continue to trust reporting in other areas despite recognizing similar potential inaccuracies.
An adage that has been stated as, "When a measure becomes a target, it ceases to be a good measure".
(Also known as the quantitative fallacy) involves making a decision based solely on quantitative observations (or metrics) and ignoring all others.
An adage, or rule of thumb, that states: Never attribute to malice that which is adequately explained by stupidity.
A type of human behavior reactivity in which individuals modify an aspect of their behavior in response to their awareness of being observed.
An effect of introducing new elements on some activity or behavior.
What are the London and Chicago schools of TDD?
An adage stating "ninety percent of everything is crap".
When two or more parties working towards a common goal all claim to be holding to their original schedules for delivering their part of the work, even after they know those schedules are impossible to meet. Each party hopes the other will be the first to have their failure exposed.
Your radical ideas about society, individualism, and religion have already occurred to others
The approximate percentage of responses to a poll, survey, or quiz that are not sincere
See also:
Sources:
Lost and not found
Some articles I'd like to find here, but haven't been able to find again:
- Enqueuing function calls vs. extending your domain model: This article discussed using traditional queues for handling some actions in your application vs. doing this "declaratively". For example, enqueue "send notification about x to user y" vs. "add column 'needs_x_notification to users table". If I remember correctly, the article contained some insightful arguments for the latter approach I had not thought of.