21 July 2026

Disabling Ubuntu Tile Groups via gsettings

In Ubuntu 25.10, clicking window B (to focus it) can unexpectedly raise a sibling window A above an overlapping window C. This happens because A and B are in the same Tile Group — a spatial grouping the Ubuntu Tiling Assistant forms when windows are snapped/tiled edge-to-edge. The extension's "Raise together" rule raises the entire tile group whenever any member is raised, so raising B drags A upward too. The fix is to disable that group-raise behavior while keeping tiling itself intact:

gsettings set org.gnome.shell.extensions.tiling-assistant enable-raise-tile-group false

To verify it took, run gsettings get org.gnome.shell.extensions.tiling-assistant enable-raise-tile-group — it should print false.

16 July 2026

Money and Recognition: The Two Axes of Compensation

(The following observation, including its linkage to Aristotle, is fun but not novel as noted at the end of the essay. The text/references came from Kagi's Research Assistant)

Compensation has two parts that work like directions on a plane. One direction is money. The other is recognition. Every job pays out along both, but the mix is different for each one. The mix is a two-vector and getting it right matters.

Examples abound. A doctor earns good money and high respect. Both directions are strong. A ballet dancer earns little money but receives great prestige. The recognition direction does almost all the work. A soldier may earn modest pay but gains deep honor, especially in moments of sacrifice. Respect, prestige, and honor are three words for the recognition axis — the one that money cannot buy.

Money and recognition are different goods for different kinds of merit. Paying someone in the wrong way causes problems. A wealthy person does not need more money. A person who cannot buy groceries does not care about awards. The right reward is the two-vector that addresses what the person actually lacks on both axes.

This is an old idea, with concepts going back to at least Aristotle. He saw that honor (not "recognition") and money were separate goods. He tied each to a different kind of contribution. He warned that mixing them up causes political trouble. The passages below trace his argument.

Concept Aristotle's Words Source
Honor and profit are two distinct currencies of reward. In unequal friendships, each party should receive more — but not more of the same thing: the superior receives the larger share of honor; the needy party receives the larger share of material gain. "both parties should receive a larger share from the friendship, but not a larger share of the same thing: the superior should receive the larger share of honor, the needy one the larger share of profit; for honor is the due reward of virtue and beneficence, while need obtains the aid it requires in pecuniary gain." Nicomachean Ethics VIII.14
Honor and property are independent axes of competition. People compete for them separately, and inequality along each axis produces discontent in opposite directions: the masses resent unequal property; the upper classes resent equally distributed honors. "civil strife is caused not only by inequality of property but also by inequality of honors, though the two motives operate in opposite ways—the masses are discontented if possessions are unequally distributed, the upper classes if honors are equally distributed." Politics II.7 (1266b)
"Merit" is not a single dimension. Different political traditions measure it differently — by free birth, by wealth, or by virtue — so what counts as a fair reward depends on which axis of merit is being applied. "all men agree that what is just in distribution must be according to merit in some sense, though they do not all specify the same sort of merit, but democrats identify it with the status of freeman, supporters of oligarchy with wealth (or with noble birth), and supporters of aristocracy with excellence." Nicomachean Ethics V.3
Paying along only one axis gives poor outcomes. Each group is partly right but wrong when it claims the whole. "All those who dispute about the forms of constitution assert a part of the just principle." Politics III.9 (1281a)

This article's two-axes presentation is not original. For example, Nancy Fraser, in her contribution to Redistribution or Recognition? (co-authored with Axel Honneth), proposes a two-dimensional theory of justice in which economic redistribution and cultural recognition are distinct, irreducible axes. Her redistribution and recognition map directly onto the money and recognition axes described here.

11 July 2026

Screen Time extensions are Intermittent Reinforcement

(The following observation/structure is mine but the text/references came from Kagi's Research Assistant per this specific prompting.)

Your child's iPhone or iPad locks. They look up at you. "Can I just have a little more time?"

You say yes. Or maybe no. Next time, you say the opposite. It feels like parenting. It isn't. It is one of the most powerful addiction triggers in psychology, and Apple has built it directly into Screen Time.

Psychologists call it intermittent reinforcement. The concept is simple. When a behavior is rewarded sometimes, but not always, that behavior becomes more persistent, not less. The uncertainty is the point. As one introduction to the subject puts it, "unpredictability can create a stronger association between the behavior and the reward, making it more compelling and often more difficult to extinguish." [1] This is why slot machines work. You keep pulling the lever because this time might be the one. The reward doesn't have to come often. It just has to come sometimes.

Apple's Screen Time feature is marketed as a parental control tool. It lets parents set daily limits on how long a child can use an app or a device. When a child hits that limit, the iPhone or iPad locks. Apple describes what happens next on its own child safety page: the child "can ask parents for more time." [2] CNET, reviewing the feature approvingly, puts it plainly: "your child can send a request for more time if more time is needed." [3] The parent then decides. Yes, no, or no answer at all. The child never knows which it will be.

That uncertainty is not a minor flaw. It is the mechanism. The behavior is using the phone until the limit hits, then sending the request. The reward is more screen time. The schedule is unpredictable. That is a textbook variable-ratio reinforcement schedule. It is the same structure that makes gambling compulsive. [1] The child is not being taught that the phone has limits. The child is being taught that the phone has a lever. Pull it enough times and it pays out. The parent, intending to set a boundary, has instead become the slot machine.

The fix is not complicated. Set the limit. Hold it. Every time. No exceptions. A limit that bends is not a limit. It is a reward on a variable schedule. The parent who always says no to extension requests is not being cruel. They are being consistent. And consistency is the one thing that intermittent reinforcement cannot survive. [1] Your child does not need more time on their phone. They need a parent who means what they say. Do not use time extensions.

References

  1. "The Power of Intermittent Reinforcement in Psychology." Unplugged Psych. https://www.unpluggedpsych.com/the-power-of-intermittent-reinforcement-in-psychology/
  2. "Child Safety." Apple. https://www.apple.com/child-safety/
  3. "Apple's Screen Time Feature Saves Parents from Being the Bad Guy." CNET. https://www.cnet.com/tech/services-and-software/apples-screen-time-feature-saves-parents-from-being-the-bad-guy/

04 July 2026

Tinkering on old projects

Over the past year I've dusted off several projects hosted at https://github.com/RhysU/:

RhysU/ar
Autoregressive process modeling tools in header-only C++.
RhysU/ESIO
Parallel-HDF5 library for high-throughput I/O of structured turbulence simulation data.
RhysU/suzerain
Spectral, direct numerical simulation of the compressible Navier-Stokes equations for turbulence research.
RhysU/c99sh
Shebang interpreter that runs single C99, C11, and C++ files with rcfile support.
RhysU/jobserver
Nestable Python jobserver with thread-safe futures, callbacks, and type hints.
RhysU/droll
Command-line implementation of the Dungeon Roll dice game.
RhysU/tuna
Lightweight autotuner that picks the fastest among interchangeable code chunks at runtime.
RhysU/war
Simulation of the card game War.

30 June 2026

Underling

Thirteen years ago, while working on the dissertation, I put together a 3D pencil transform library atop FFTW MPI called underling. It looked great in isolation. It never integrated correctly with my dissertation code. I eventually ran away because spending time on it wasn't time spend graduating

In the last couple of days I learned that there was no problem with the library from a correctness perspective. Instead, the mysterious problem was MKL exposes an incomplete FFTW implementation that simply returns NULL for a lot of methods. After some linking tinkering in my dissertation's primary codebase, my little pencil decomposition library snapped right into place.

This is both immensely satisfying (it worked after all!) and frustratingly painful (would have loved to benchmark/publish during the grad school days!). Alas.

28 June 2026

Two Sons

Written back in August 2020

I have two different sons. However, at the West End Suprette each one chose the same Häagen-Dazs ice cream bar. Something with dark chocolate. I chose a Nestle Crunch ice cream bar from another part of the freezer. I paid while they continuously touched things that I asked them not to touch.

We three walked a block south to a tiny park, Septuagesimo Uno, and plunked ourselves on some benches. I handed the Häagen-Dazs bars, which came boxed-then-wrapped, to the boys. They tore open the boxes but the wrappers stymied them. I chuckled and wondered if, sufficiently motivated, they'd get the packaging open by themselves. They endeavored.

I opened my Crunch bar, lifted it by the popsicle stick, caught half a bite, and the whole bar fell away from the stick and onto the nasty city ground. Evidently the Crunch bar had passed its days in a warmer freezer spot. The old Eddie Murphy ice cream man skit, where a kid loses a whole cone, ran through my head while I debated if anything could be salvaged. My wife would rightly kill me if she heard I taught the kids that food could be eaten off the nasty city ground. And the kids would certainly tell her. I sighed, shook my head, and then looked up into two pairs of wide eyes.

Each boy gazed into my disappointed face while still ineffectively fumbling with a wrapper. I got out “Too bad” before twice “Dad, would you please help me open this?” arrived. I held out my hand, the little one handed me his package, I opened it, and I handed back an unmelted ice cream bar. A pause, then into the mouth. I held out my hand, the bigger one handed me his package, I opened it without looking, and I passed back a second bar. Turning down again, I couldn't resist a tiny bit of the chocolate coating. Perhaps, adequately distracted, the kids wouldn't report me to their mother.

“Dad, would you like some of mine?” spoken softly startled me. A dark chocolate Häagen-Dazs bar floated into my gaze attached to a popsicle stick attached to an outstretched arm attached to my nine-year-old son. He had offered me his very first bite. I choked up briefly, politely declined, told him how kind that was, and hugged the boy. He blinked, stepped back, and then launched into his bar.

Fortunately, neither kid made so much of a mess that their not-yet-broken tendency to wipe their mouths on their shirts didn't solve said mess. I collected then threw away the two boxes, three wrappers, and three sticks. Starting home, I hugged the big one again. He ran ahead maybe twenty feet.

The six-year-old generally lags behind me on the street. Now, however, he kept pace as we walked in silence. Halfway home he says “Dad, I would have offered you mine but I knew you wouldn't eat it so I didn't offer it.” And I tell him thank you and I hug him too. Quickly thereafter, we enter our building lobby and call the elevator.

26 June 2026

The Greatest Skit in the World

Inspired by "Tribute" by Tenacious D and another meta-bench skit. Arrived at through prompting and re-prompting Claude until it cried...

A Campfire Skit for 5 Scouts (~2 minutes)

No props. None. That’s the whole joke. Play it big. The crowd should get the ending long before the characters do.


CAST

  • DIRECTOR — the Camp Director. Gruff.
  • SCOUT 1 — the leader. Certain. Wrong.
  • SCOUT 2 — the loud one.
  • SCOUT 3 — small, nervous. Keeps blurting the right answer.
  • SCOUT 4 — eager. Quick to strike a pose.

THE SKIT

(The FOUR SCOUTS stand in a row, in order 1–2–3–4. The DIRECTOR storms in.)

DIRECTOR: Scouts! I need a skit tonight. A GREAT one. Or it’s latrine duty till you can vote!

SCOUT 1: Director… we will perform THE skit. The greatest skit this camp has ever seen. We did it once. The Scoutmaster wept.

SCOUT 2: The whole crowd was on their feet! They wouldn’t stop cheering!

SCOUT 3: (quietly) A raccoon stood up and clapped.

DIRECTOR: (arms folded) Then do it.

SCOUT 4: Positions!

(All four strike a dramatic pose. They hold it. Their faces slowly fall.)

SCOUT 3: (through his teeth) …What was it?

SCOUT 2: I thought YOU remembered.

SCOUT 1: I remember it was GREAT. I don’t remember what it was.

SCOUT 2: (flat) There were no props. That was the whole thing. We had nothing. (pregnant silence)

DIRECTOR: (throwing up his arms) Nothing?! You’re telling me the greatest skit ever was a bunch of Scouts with NOTHING?! (throws up his hands) I give up. (walks behind the row of Scouts and lowers himself into a seated position at bench height — knees bent, arms crossed, sulking, perched on nothing)

SCOUT 3: (brightening) We just… sat down.

SCOUT 2: On what?

SCOUT 3: On the bench.

SCOUT 2: WHAT bench?

SCOUTS 1, 3 & 4: (slow, together) …Exactly.

(On the word, the DIRECTOR topples backward off the invisible bench and crashes to the ground. Hold. Bow. Everyone runs off.)


PERFORMANCE NOTES

  • Stand in numeric order. Every handoff passes to the Scout next to the speaker, so the focus slides down the line instead of jumping across it.
  • The Director sells the ending. He sits behind the row on “I give up,” perched on nothing the whole time the Scouts talk — then topples on “…Exactly.” The longer he holds the sit, the bigger the fall.
  • Land “…Exactly.” big. All three say it together, dead serious, gesturing at the empty air.
  • Let the silence breathe before the Director’s last line.

20 June 2026

A nestable Jobserver with thread-safe futures, callbacks, and type-hinting

I have been hacking on https://github.com/rhysu/jobserver for a long time. Today I put the jobserver package up on PyPi: https://pypi.org/project/jobserver/.

My initial motivation was improving robustness over the process-pooling approaches that I was using back in August 2019. I needed something where my worker tasks could SIGSEGV or SIGPIPE without my entire pool crashing. I also needed extension hooks for a few specific applications, like advisory flocking when a worker was active and being mindful of RAM limits.

It's stayed fun to intermittently hack on. From the tag messages, you can tell I began using LLMs with this project after tag v1.12. Some features, like JobserverExecutor, were simply beyond my personal bandwidth before employing coding agents. I've tried to keep the technical quality at least as high as if I'd been hand-coding.

The timeline's been...

v1.0 — 2020-02-17
First feature-complete release of the jobserver.
v1.1 — 2020-02-22
Added when_done callbacks along with grammar and type-annotation improvements.
v1.2 — 2020-03-03
Introduced per-submission env and preexec_fn support, and adopted black/flake8/mypy tooling.
v1.3 — 2020-03-04
Added grandchild polling, configurable defaults, and a pluggable sleep_fn.
v1.4 — 2020-03-09
Simplified both the public API and the internals.
v1.5 — 2020-03-10
Wrote the README and made assorted touch-ups.
v1.6 — 2020-12-18
Removed the sentinel push/pop at work submission, since __getstate__/__setstate__ are now handled explicitly.
v1.7 — 2021-01-08
Exposed reclaim_resources on the public API.
v1.8 — 2021-02-16
Added support for CPython 3.9.
v1.9 — 2021-03-18
Exposed MinimalQueue and improved test robustness.
v1.10 — 2022-04-06
Added Python 3.10 support and the ability to unset environment variables.
v1.11 — 2024-09-29
Confirmed Python 3.11 and 3.12 work correctly.
v1.12 — 2026-01-01
Confirmed Python 3.13 works correctly.
v1.13 — 2026-03-28
Added JobserverExecutor (a concurrent.futures.Executor wrapper), Jobserver.map(), and signal-based cancellation via Future.done(..., signal=...). Also hoisted submit defaults, named worker processes, fixed re-entrant CallbackRaised double-wrapping, and shipped nine worked examples.
v2.0 — 2026-03-30
Added context-manager support to MinimalQueue and Jobserver, rewrote reclaim_resources() as O(k) using wait(), and added repr(). Fixed a Future.wait() sentinel/waitpid race and added Future.done() as a wait(timeout=0) shorthand.
v2.1 — 2026-03-31
Corrected timing, resource-leak, and type-safety issues found after v2.0, including a py.typed marker, a fixed queue-timeout overrun, and event-driven dispatcher polling. Replaced asserts at public boundaries with explicit TypeError/ValueError.
v2.2 — 2026-04-01
JobserverExecutor can now own a default-constructed Jobserver automatically, making it drop-in, and slot acquisition became O(k) via a persistent selector. Also let preexec_fn return a context manager, added resource/callback warnings, and generalized nesting examples across all start methods.
v2.3 — 2026-06-01
Child tracebacks now survive Future.result() via __cause__, escaping BaseExceptions became diagnosable, and concurrent.futures.Future.cancel() was wired through the executor. Many hardening fixes followed for map() slot reclamation, submit/shutdown races, MinimalQueue, validation, and the public API surface.
v2.4 — 2026-06-01
Fixed nested fan-out under the fork start method via a lazy per-process selector that rebuilds when the PID changes. Also deduplicated pickle-error handling and the env type signature, and added a stdlib-only benchmark harness under draft/.
v3.0 — 2026-06-20
Major API redesign: Jobserver became a thin handle over a shared, reference-counted Resources object, submission controls moved off submit()/map() into sibling handles (revise_env(), replace_preexec(), replace_sleep()), and SubmissionDied was renamed LostResult. Added a __version__, eager timeout validation, a redesigned queue hierarchy, suppressed worker traceback noise, hardened deserialization, and modernized packaging, docs, tests, and examples.

26 May 2026

To differentiate unsuccessful from successful experiments

I chased down this quote by Robert H. Goddard via The Goddard Papers Database . The original context of the letter, often omitted when using the quote, makes Goddard's words all the more delightful:

R. H. Goddard to F. T.*, Jeffersonville, Indiana
Roswell, February 5, 1942

It is not a simple matter to differentiate unsuccessful from successful experiments, since most work that is finally successful is the result of a series of unsuccessful tests in which difficulties are gradually eliminated...

*This was in response to a young experimenter who complained that many of his tests had been unsuccessful

SOURCE: Goddard, Robert H. The Papers of Robert H. Goddard. Edited by Esther C. Goddard and G. Edward Pendray. Vol. 3, 1941–1945: JATO and Variable Thrust for the Military. New York: McGraw-Hill, 1970, page 1453.

01 May 2026

Scam Likely

A first person temporal tragedy to the tune of "Let It Be"...

[Verse 1]
When I call during time troubles
You won't answer though I plea
Call shows "Scam Likely"
Scam Likely
And in my hour of darkness
Past you won't pick up for me
Phone shows "Scam Likely"
Scam Likely

[Chorus]
Scam Likely, Scam Likely
Scam Likely, Scam Likely
Need to change history
Scam Likely

[Verse 2]
And when my parents never meeting
Means I'll cease to ever be
Still phones show "Scam Likely"
Scam Likely
For historic missed connection fears
Haunt me that no one will ever see
Past the words "Scam Likely"
Scam Likely

[Chorus]
Scam Likely, Scam Likely
Scam Likely, Scam Likely
Nah, please Lord make them answer
Scam Likely
Can't I be?! Scam Likely
Scam Likely, Scam Likely
Insert myself in history
Scam Likely

[Instrumental Break]

[Guitar Solo]

[Chorus]
Scam Likely, Scam Likely
Scam Likely, yeah, Scam Likely
Need to change history
Scam Likely

[Verse 3]
And when the timeline's getting cloudy
There's hope shining yet in future me
Light more digits tomorrow
Scam Likely
Frantically dial numbers
Every phone rejects my plea
All show "Scam Likely"
Scam Likely, yeah

[Outro]
Scam Likely, Scam Likely
Scam Likely, nah, Scam Likely
Oh, there must be an answer
Scam Likely
Can't I be?! Scam Likely
Scam Likely, yeah, Scam Likely
Oh, there must be an answer
Scam Likely
Might not be? Scam Likely
Scam Likely, nah, Scam Likely
Insert myself in history
Scam Likely

13 April 2026

Tidbits from the World

Just quotes, etc. where I frequently want the original source… 

  1. “Legacy” is not a pejorative.

  2. “Invert, always, invert”

    1. Jacobi originally but popularized by Munger : “...it is in the nature of things that many hard problems are best solved when they are addressed backward”

    2. Algorithm for inversion:

    3. Define the problem - what is it that  you're trying to achieve?

    4. Invert it - what would guarantee the failure to achieve this outcome?

    5. Finally, consider solutions to avoid this failure

  3. “[Not naming software tools] is actually a lesson that originates from the early days of Call of Duty at IW. From what I’m told, IW never named their engine, because any time you name something it becomes a bit more of a thing, and you start working for it. And they were a studio making games, the game is the thing. Nothing else.” [source]

  4. “You have to do basic science on your libraries to see how they work…” [Sussman as reported by Wingo]

  5. “A pointer is an integer with a shiv” [source]

  6. Optimal stopping problems are solved with the odds algorithm, e.g. the  classical secretary problem.

  7. “The Statistics of Sharpe Ratios” by Andrew Lo [paper]

  8. “You are in a drawdown.  When should you start worrying?” [paper]

  9. NIST has several excellent references:

    1. Dictionary of Algorithms and Data Structures  (DADS), a dictionary of algorithms, algorithmic techniques, data structures, archetypal problems, etc

    2. Engineering Statistics Handbook with chapters Explore, Measure, Characterize, Model, Improve, Monitor, Compare, and Reliability

  10. “If you have a procedure with 10 parameters, you probably missed some.” [source]

  11. Driscoll Kraay Standard Errors are robust to both cross-sectional and temporal dependence.

  12. The  Python Graph Gallery is a visual reference over many graphs along with the source code to produce them.

  13. Total least squares  minimizes errors on both dependent and independent variables.

  14. Bottom Line Up Front (BLUF) writing [HBRWikipedia]

  15. Dennis Ritchie: “Our habit of trying to document bugs and limitations visibly was enormously useful to the system. As we put out each edition, the presence of these sections shamed us into fixing innumerable things rather than exhibiting them in public. I remember clearly adding or editing many of these sections, then saying to myself 'I can't write this,' and fixing the code instead.” [source]

  16. A bestiary of regression variants , including:

    1. Linear Regression

    2. Polynomial Regression

    3. Logistic Regression

    4. Quantile Regression

    5. Ridge Regression

    6. Lasso Regression

    7. Elastic Net Regression

    8. Principal Components Regression (PCR)

    9. Partial Least Squares (PLS) Regression

    10. Support Vector Regression

    11. Ordinal Regression

    12. Poisson Regression

    13. Negative Binomial Regression

    14. Quasi Poisson Regression

    15. Cox Regression

    16. Tobit Regression

  17. A Bestiary of Functions for Systems Designers  is a nice visual guide

  18. Karpathy blogged A Recipe for Training Neural Networks :

    1. Become one with the data

    2. Set up the end-to-end training/evaluation skeleton + get dumb baselines

    3. Overfit, recalling deep double descent

    4. Regularize

    5. Tune

    6. Squeeze out the juice

  19. Agustin Lebron’s The Laws of Trading :

    1. Know why you are doing a trade before you trade.

    2. You're never happy with the amount you traded.

    3. Take only the risks you're being paid to take.  Hedge the others.

    4. Put on a risk using the most liquid instrument for that risk.

    5. If you can't explain your edge in five minutes, you don't have a very good one.

    6. The long-term profitability of an edge is inversely proportional to how long it takes to explain it.

    7. The model expresses the edge.

    8. If you think your costs are negligible relative to your edge, you're wrong about at least one of them.

    9. Just because something has never happened doesn't mean it can't.

      Corollary: Enough people relying on something being true makes it false.

    10. Working to align everyone's interests is time well spent.

    11. If you don't master technology and data, you're losing to someone who does.

    12. If you're not getting better, you're getting worse.

  20. Shellhaters.org has a great POSIX Shell and Utilities Quick Reference

  21. Practical SQL for Data Analysis: What you can do without Pandas [source]

  22. Taguchi methods are statistical methods, sometimes called robust design methods, developed by Genichi Taguchi to improve the quality of manufactured goods, and more recently also applied to engineering…. See also orthogonal arrays , optimal experimental link, and notice Sandia’s Dakota implements many of these ideas.

  23. Prefer to change the code rather than write a workaround [source]

  24. By nature, bugs are found in places that you didn’t think to look [source]

    1. A cold path is a path through the code or situation that rarely happens.

    2. By contrast, hot paths happen frequently. You don’t find bugs in hot paths.

    3. Bugs are always in cold paths — every bug is found in a path colder than all the paths you tested.

    4. Don’t have cold paths and avoid fallbacks

  25. Your Makefiles are wrong is an opinionated approach to GNU Make:

    1. Don’t use tabs with .RECIPEPREFIX

    2. Always use (a recent) bash in strict mode

    3. Change some Make defaults, with a nice TLDR pre-amble

  26. Mike Acton’s Expectations of Professional Software Engineers [summary]

  27. Scalability! But at what COST? says “Big data systems may scale well, but this can often be just because they introduce a lot of overhead” and is often referred to as “The COST Paper”

  28. strace Wow Much Syscall by Brendan Gregg includes useful strace  one-liners

  29. Richard Sutton’s The Bitter Lesson starts “The biggest lesson that can be read from 70 years of AI research is that general methods that leverage computation are ultimately the most effective, and by a large margin….” and begins to conclude “One thing that should be learned from the bitter lesson is the great power of general purpose methods, of methods that continue to scale with increased computation even as the available computation becomes very great. The two methods that seem to scale arbitrarily in this way are search and learning.”

  30. Syntax across languages  is a gigantic survey of language design, e.g. operators/functions/etc. The survey can often inform what some collection of users will find natural or unnatural based on their existing skills.

  31. Nick Higham’s “What Is” article series  gives brief descriptions of concepts in numerical analysis for upper-level undergraduates with mathematical inclinations

  32. Long names are long observes “identifiers that are too damn long.”

    1. Omit words that are obvious given a variable’s or parameter’s type

    2. Omit words that don’t disambiguate the name

    3. Omit words that are known from the surrounding context

    4. Omit words that don’t mean much of anything

      (e.g. data, state, amount, value, manager, engine, object, entity, and instance)

    5. Ends with a humorous application to waffles.

  33. How to help someone use a computer : “Computer people are fine human beings, but they do a lot of harm in the ways they "help" other people with their computer problems….”

  34. Common statistical tests are linear models:

    1. Exposition in R

    2. Exposition in Python

  35. Hoeffding’s test for dependence was proposed by Wassily Hoeffding (1948) as a test of correlation for two variables with continuous distribution functions (wikipedia, random blogpost). Hoeffding’s D is a nonparametric measure of the distance between the joint distribution F(x, y) and the product of marginal distributions F1(x)F2(y). The advantage of this statistic lies in the fact that it has more power to detect non-monotonic dependency structures compared to other more common measures (Pearson, Kendall, Spearman)

  36. Data systems often fall into one of schema-on-write or schema-on-read:

    1. Traditional databases are schema-on-write: “we can't upload data until the table is created and we can't create tables until we understand the schema of the data that will be in this table.”

    2. Newer systems, e.g. “Big Data” is often schema-on-read, requiring all code that handles the data to understand it’s implicit schema.  Still “some level of schema design is inevitable”.

    3. Martin Kleppmann’s book Designing Data-Intensive Applications often comes up.

  37. Simple sabotage for software , taking CIA sabotage manuals for inspiration, enumerates many horrid, insidious ways to sabotage a software organization.  To do better as an organization, work to prevent even accidental sabotage.

  38. The Internet Was Designed With a Narrow Waist:

    1. A narrow waist is concept, interface, or protocol that solves an interoperability problem.

    2. Picture an hourglass with M things on one side, N on the other, and an important concept in the middle.

    3. It avoids O(M × N) code explosions, letting us write O(M + N) amounts of code instead.

    4. Byte streams and text are essential narrow waists in software, particularly in distributed-systems like the Internet.

  39. On achieving high-level goals [source pp 138-9]:

    1. Write down your five biggest goals for the year.

    2. Pick the one that will make the biggest difference in your life.  Tackle that one first.

    3. Write your chosen goal in the past tense as though it's already happened. This will not only tell you whether you truly want it by how you feel as you look back at it from the future, it will also help you identify (in imagined hindsight) all the critical steps it will take to get there.  Outline as many critical steps as come to mind.

    4. Write out twenty different things you could do right now to make it happen. Really stretch your thinking in new directions to get all twenty.  Now pick the one goal that will have the greatest impact on the achievement of that goal.  Try to knock one off your list each day, or week (depending on the goal).  Keep going with twenty more, and twenty more, until the goal is achieved.  Focus on only one goal at a time, putting all your energy in that one direction.  (Trying to work on them all at once can be overwhelming and diffuses your effectiveness and focus).

  40. Thompson sampling is commonly used as a multi-armed bandit algorithm. I have personally used it for an older side project.

  41. “Shipping is a social construct within a company.”

  42. There’s a CLAUDE.md containing Karpathy-inspired Claude Code guidelines.

  43. Every layer of review makes you 10x slower by he of apenwarr/redo fame.