2026-06-17 09:51

#new #wip

content

references

2026-05-28 16:10

#new #source #wip #thread

An evolutionary software architecture supports guided, incremental change across multiple dimensions. There is a strong preference throughout the book for microservices or service-oriented architectures because of their decoupled and evolvable natures.

Part I — Mechanics

The mechanics of an evolutionary architecture concern the engineering practices and verification that allow an architecture to evolve.[^ford2023] This is the nuts and bolts of actually evolving the system.

Chapter 1 — Evolving Software Architecture

• Evolving architecture is hard. Were trying to hit the constantly moving target (what our business requires as it changes and grows) while standing on shifting sands (the state of the art in software development and technology).
• 202205031449 Optimize for change.
• Make incremental changes via architecture and deployment.
• Protect your architectural dimensions with fitness functions.

Chapter 2 — Fitness Functions

• 202606021226 Fitness functions
• 202109251100 Verify behaviors and assert properties
• Objective architectural fitness functions form the primary mechanisms for implementing evolutionary architecture.
• Monitors, metrics, chassis engineering, architecture testing frameworks, tests, and security scanning are just some of the tools at our disposal for measuring and upholding fitness functions.

Continue reading

2026-05-17 11:20

#wip #source #thread #new

Essays for Uneven Terrain

#source #new

A collection of essays from Rebecca Solnit about 202203231646 Affecting long-term change and hope for the future.

In Praise of the Indirect, the Unpredictable, the Immeasurable

I’ve become a love of slowness, patience, endurance, and long-term vision, because these things seem like crucial equipment for changing the world or even understanding it. (pp. 2)[^solnit2025]

as the poet Antonio Machado famously said “Walker, there is no path; the path is made by walking.” (pp. 6)[^solnit2025]

A Truce with the Trees

• Beautiful telling of the artistry of violin making and the global nature plus harmony of renewable craft, contrasted with the permanent harm we’re doing to it, the breaking of the truce.

A Sky Full of Forests

• We must tell stories: of how we got here, how things used to be, and how they could be, of how they should be. We must pour water on the fires and provide rafts in the flood. We must change minds and hearts. We must envision a humanity as it should be. (pp. 23)[^solnit2025]

On Letting Go of Certainty in a Story That Never Ends

When it comes to real life, this state of unknowing is both normal and so wildly uncomfortable that we engage in foolish and delusional imitations of knowing. (pp. 29) [^solnit2025]

Continue reading

2026-02-02 20:23

#new

A staggeringly large topic to be sure. This note does not aim to be comprehensive.

In 202602021747 A Philosophy of Software Design, John Ousterhout defines complexity in software systems in the following way.

Complexity is anything related to the structure of a software system that makes it hard to understand and modify.¹

2026-02-02 17:47

#source #wip #new

Writing software is the practice of problem decomposition. This book is about strategies to achieve that goal while reducing complexity.[^ousterhout2021] If a design pattern or strategy doesn't actually reduce complexity, simply don't use it, but a great deal of thought and experience has gone into this book so think carefully before passing judgement.

Chapter 1: Introduction (It's All About Complexity)

• Simpler designs allow us to build larger and more powerful systems before complexity becomes overwhelming. (pp. 1)
• The first approach to fighting complexity is to eliminate it by making code simpler and more obvious. (pp. 2)
• The second approach to fighting complexity is to encapsulate it so programmers can work on the system without being exposed to all its complexity at once. (pp. 2)
• Software developers should always be thinking about design and reducing complexity is the most important aspect of design; therefore, software engineers should always be thinking about complexity. (pp. 3)

Chapter 2: The Nature of Complexity

• The ability to recognize complexity is a crucial design skill. (pp. 5)
• It's easier to be able to tell if a design is simple than it is to create a simple design. (pp. 5)

Continue reading

2025-12-04 14:33

#new #wip

In an organization, technical clarity is when non-technical decision makers have a good-enough practical understanding of what changes they can make to their software systems.[^goedecke2025clarity]

Technical clarity in an organization can be the difference between a functional engineering group and a completely dysfunctional one.[^goedecke2025clarity]

The default quantity of technical clarity in an organization is very low. In other words, decision-makers at tech companies are often hopelessly confused about the technology in question.[^goedecke2025clarity]

From the perspective of non-technical leaders, those engineers are an abstraction around technical complexity.[^goedecke2025clarity]

If I say “no problem, we’ll be able to roll back safely”, I’m not as confident as I appear. When I’m giving my opinion on a technical topic, I top out at 95% confidence - there’s always a 5% chance that I missed something important - and am usually lower than that. I’m always at least a little bit worried.

Why am I worried if I’m 95% sure I’m right? Because I’m worrying about the things I don’t know to look for. When I’ve been spectacularly wrong in my career, it’s usually not about risks that I anticipated. Instead, it’s about the “unknown unknowns”: risks that I didn’t even contemplate, because my understanding of the overall system was missing a piece. That’s why I say that shipping a project takes your full attention. When I lead technical projects, I spend a lot of time sitting and wondering about what I haven’t thought of yet.

Continue reading

2025-11-16 08:42

#new

1. Binding the model and the implementation — it’s important to start immediately with a crude prototype of both the model and the implementation and then develop them both simultaneously. Doing so prevents the model and implementation from drifting apart or contradicting one another.
2. Cultivating a 202511151211 Ubiquitous language based on the model — domain experts and software engineers should understand each others’ terminology and adopt a shared language for talking about the domain, the model, and the software.
3. Developing a knowledge rich model — the model is more than the implementation, but contains it. The implementation is more than code, and contains the knowledge of the model. There are behaviors, rules, constraints, limitations, scoping, abstractions, and more that are part of the model and need to be part of the implementation. Make sure you have a method for capturing all kinds of domain knowledge in your model and implementation.
4. Distilling the model — important concepts are added, but also importantly, dropped from the model over time. When an unneeded concept is tied to a concept that is needed, every effort should be made to find a model containing only essential concepts so extraneous ones can be dropped. It may be a good idea to record when these decisions and changes are made so that people will know the decision making behind a dropped/unincorporated concept.

Continue reading

2025-11-15 11:48

#wip #new

A Domain in the context of a model, is the actual subject of the model. It is the reality that we are modeling.

[A domain model] is a rigorously organized and selective abstraction [...] loosely representing reality to a particular purpose.¹

It is important to remember that 202203210830 When your model and reality conflict, reality is always right, 202203210831 Models are immutable but reality isn't, and 202203210832 Models are necessarily incomplete. In these ways, our modeling of a domain will never be perfect. Therefore we should strive to model the relevant domain as closely as we can, but also enable the continued iteration and evolution of the model as we learn more about the domain or require adding more of the domain to our model. In fact, domain modeling is not an attempt to make the most realistic model possible. We choose the parts of the domain and the abstractions used for a particular purpose.

2025-11-14 14:10

#thread #souce #wip #new

Absolutely fantastic keynote tech talk given by Bryan Cantrill at TalosCon 2025 on simplicity in programming.

Abstraction

The essence of software systems is the creation of abstraction. They allow us to build software systems that do sophisticated things. They are the shoulders we stand on and provide to others. Abstractions are qualitative. The good ones allow us to hide gory implementation details in order to build "castles atop them and tunnels beneath".[^cantrill2025] The bad ones leak, seeping implementation details instead of sealing them, yielding systems that are unwieldy and brittle.

One of the primary roles of any software or computer science engineering education is imparting the humility that anything works at all.[^cantrill2025]

Complexity

Complexity blossoms in bad or non-existent abstractions. Fred Brooks famously called this accidental complexity in his essay No Silver Bullet. (Where are my notes from this when I read it? #thread #wip) This is differentiated from the essential complexity endemic to a particular problem. Complexity can explode. Accidental complexity in one component can become the essential complexity in something that must interact with it! Complexity doesn't merely accrue.

Continue reading

2025-11-12 08:53

#source #new #wip

content

2025-11-12 08:46

#new #source #wip

Eric Evans's seminal book about domain driven design in 202109061338 Software Engineering. Also referred to as The Blue Book among DDD aficionados.

todo: 202606170951 Bounded Context

Part 1 - Putting the Domain Model to Work

• Definition of 202511151148 Domain

Chapter 1: Crunching Knowledge

• 202511160842 Ingredients of effective modeling
• Effective domain modelers are knowledge crunchers. They take a torrent of information and probe for the relevant trickle. They try one organizing idea after another, searching for the simple view that makes sense of the mass.¹ (pp. 13)
• Domain 202109060836 Knowledge should accumulate in the model.
• #wip type up the paragraphs on page 14 about org pathologies in development for discussion and inclusion in 202511151207 Domain modeling exercise.
• 202511161359 We never know enough to begin a project

Chapter 2: Communication and the Use of Language

• 202511151211 Ubiquitous language

Chapter 3: Binding Model and Implementation

• 202512241101 Model Driven Design

2025-10-04 11:19

#wip #new

Some quotes from Walden.¹ This note should probably go away in favor of individual things once recorded better.

202112291821 The things we own end up owning us

Pause! Avast! Why so seeming fast, but deadly slow? P103

Classics end of 108

Books are the treasured… 111

Loneliness relative to working p144-145

Be a Columbus to whole new continents and worlds within you, not of trade, but of thought. Every man is the lord of a realm besides which the earthly empire of the Czar is but a petty state, a hummock left by the ice. P338 except criticizing travel as a way to avoid thinking or being alone. I believe travel helps one chart interior and exterior

Paragraph beginning “I learned this, …” on p341

2025-08-19 23:13

#new

The only way to truly know if an idea works is to test it.¹ 202203210830 When your model and reality conflict, reality is always right, which means that the only way to know for sure if an idea (which is just a mental model of a possible thing) works or is good, right, or accurate is to test it in reality.

This also implies that 202508192317 If you want the best, test everything.

2025-08-11 22:41

#new

Sometimes we need to come at a situation from a fresh perspective and disregard our conventional wisdom or contextual information in order make progress. This is commonly referred to as “taking a step back” or “working from first principles”. Another way of putting this is to “try to have a beginner’s mind” about it.¹ What would a beginner think or ask about this? What would I do if I didn’t have all of this conventional wisdom or normative bias? What do the fundamentals tell me about this situation? What does the data say?

It can be hard to have a beginner’s mind (202406201458 I've lost the knowledge of how I learned what I know), but making the effort to disregard assumptions can be valuable.

2025-08-10 22:35

#new

In order to develop and intuition for greatness, whether artistic, creative, technical, philosophical, practical or anything else, you should submerge yourself in great works that correspond to that intuition.¹

When starting out, it may be difficult to recognize greatness and we typically have to lean on the judgement of others. Slowly, we build our own intuition and judgement as well as personal style or particular lens for evaluating great works. We also become more discerning and capable of finding themes, threads, and pieces of greatness in many other works.

This built 202408021018 Intuition and instinct are implicit knowledge that we retain and can draw on later to create our own great works (the height of 202107282144 Bloom's taxonomy of knowledge)

2025-07-26 12:54

#new #thread

For the longest time, writing was more expensive than reading. If you encountered a body of written text, you could be sure that at the very least, a human spent some time writing it down. The text used to have an innate proof-of-thought, a basic token of humanity.

Now, AI has made text very, very, very cheap. Not only text, in fact. Code, images, video. All kinds of media. We can't rely on proof-of-thought anymore.[^martsinovich2025]

This article by Alex Martsinovich was concerned mostly with the changes that AI is causing to writing as a proof that someone had to think about something to write it down. It is a form of 202606031426 Output-competence decoupling. I agree with the article, but I still think the idea of writing (or other actions or outcomes) as a proof-of-thought is interesting. (oxide RFD about the presumption that the writer has put in the greater effort than the reader #thread)

How can we prove that something was thought through? How can we prove something had any thought put into it at all or perhaps whether it had a great deal of thought put into it? I suppose that there are tells for these things and like the article mentions, they are getting harder to discern in the current "AI" context.

Continue reading

2025-07-23 23:18

#wip #new

Turning something from an idea into a reality

can make it seem smaller.

It changes from unearthly to earthly.

The imagination has no limits

The physical world does

The work exists in both¹

There is a fundamental difference between an imagined idea and a reified one. Even the most faithful creation of an idea will lose some quality that is present in our minds.

Sometimes this is because of something as simple as the differences in my experience vs yours. If an idea evokes in me a feeling because of a related memory, then it won’t evoke that feeling in you. Other times it’s simply impossible to describe the full scope and nature of the idea precisely. There are countless ways that this can manifest.

A good example of this is this Zettelkasten. I attempt to make my ideas explicit and show the connections between them, but it’s not always perfect. Sometimes the ideas connect in strange ways too.

This concept reminds me of “the compression of reality” discussed in the 202408220851 Willful ignorance of reality in organizations Zettel (update link when breaking out that Zettel #wip)

2025-07-23 23:08

#new #wip

To every thing there is a season,
  and a time to every purpose under the heaven

A time to be born,
  and a time to die
A time to plant,
  and a time to reap
A time to kill,
  and a time to heal
A time to break down,
  and a time to build up
A time to weep,
  and a time to laugh
A time to mourn,
  and a time to dance
A time to cast away stones,
  and a time to gather stones together
A time to embrace,
  and a time to refrain from embracing
A time to get,
  and a time to lose
A time to keep,
  and a time to cast away
A time to rend,
  and a time to sew
A time to keep silence,
  and a time to speak
A time to love,
  and a time to hate
A time of war,
  and a time of peace.

Ecclesiastes 3

references #wip

2025-07-23 22:51

#new

Creativity does not have to mean artistic creativity. Creativity is not a rare ability and is not difficult to access.

Creativity is a fundamental aspect of being human. It’s our birthright.¹

We are all engaged in creative acts all the time. We all perceive the world and create our worldviews unconsciously even. When we interact with the world we create outcomes, decisions, and responses that affect the world around us. This is a generative — a creative — act.

Some are also engaged in actions that bring something into the world. 202109061338 Software Engineering, writing code, building software, creates something from nothing.

2025-04-11 14:51

#new

A moment’s thought would have shown him. But a moment is a long time, and thought is a painful process.¹

Accuracy

On p. 315 of The Profit Motive in Ethics, Vol. 86, No. 4, pp. 312-322 (July, 1976), Flew quotes Housman differently:

A moment's thought would have shown him this. But thought is a painful process. And a moment is a long time.

Perhaps Flew was attempting to recall from memory the following passage from p. xi of the Preface to Housman's Juvenalis Saturae (revised edition, Cambridge University Press, 1931), which is reprinted on p. 56 of A.E. Housman: Selected Prose (edited by John Carter, Cambridge University Press, 1962):

Three minutes' thought would suffice to find this out; but thought is irksome and three minutes is a long time.

2025-01-30 17:05

#wip #source #new

Programming as Theory Building by Peter Naur is an amazing, thoughtful, penetrating understanding and description of the act of programming. It suggests that the act of programming is an act of theory building. This contradicts with the common view of programming as industrial production (e.g. queues, assembly lines, lean, scrum etc.)

[P]rogramming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to the what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.¹

• quality is related to understanding 393
• theory as technical term (what is a "theory") 395, 396 w/ links to Bloom's taxonomies.
• intellectual activity vs intelligent behavior 396 (maybe)

2024-11-30 11:47

#new #wip

In economics, someone can be 10 or 100 times more effective (in terms of the wages they make) just by crossing a border. A taxi driver in one of the poorest countries on earth would make a lot more money doing the exact same work in New York City.

In 202109061338 Software Engineering, we talk about “10x developers”. Many people talk about it derisively while others believe in it fanatically. The idea is that one developer can be better than 10 others. Whether you believe in that interpretation or not, the economic interpretation of a 10x developer can hold water. If a developer makes the system they’re in better and more effective, they can leverage those changes to be 10x or w/e… #wip had to stop writing finish this note better and cite sources

Crafting code podcast 027

2024-11-29 23:05

#new #wip

Also known as the Jevon’s paradox or The Coal Problem. Initially formulated as

Why did coal consumption not drop when engines became more efficient?

The answer is that people did more work with those engines and had the same “cost homeostasis”. That is, they were always willing to spend that amount on coal or put up with that amount of “cost” whether monetary or labor or whatever, so when the engine got more efficient they adjusted their consumption to meet that new equilibrium.

This concept was introduced to me through the excellent talk from Peter van Hardenberg from Ink and Switch titled Why Can’t We Make Simple Software (23:29 cite this and maybe even make a source for it. It’s a really great talk #wip) In it, he discusses our threshold for tolerating complexity and how we’ll put up with it in a system until it crosses that threshold. Once it does, we’ll make the changes needed to bring it back under the threshold and repeat this cycle.

references

2024-11-26 14:17

#new

There can never be an agile process.¹

Agile means able to move quickly and easily. More broadly, it means you can change direction easily and are adaptable. If you were to make a process that "was the agile process", then it would definitionally not be capable of change, thus invalidating itself. No single plan can adapt to unforeseen circumstances. 202312161343 You don’t do Agile.

To be contrarian, one could define a enormously vague process as something like "do whatever is best and adapt to your context". This skirts the definition and purpose of "processes" in organizations though. It also ends up being too vague to be helpful and more of a platitude than a plan of action or way of working.

2024-11-16 14:34

#wip #thread #new

Why should we have children in an age where everything seems to be going wrong? First off, consider that we may be biased and it's a good time to be alive 202109100838 Positive History (and #thread on how now is the best time to be alive as a human. But also acknowledging how there's problems that we need to fix).

Tom Whyman proposes the idea that even if we are in the worst of times, children, new generations, and just more time passing have always been the greatest forces of positive progress in our world. Things have — though wanderingly — always been getting better and people have driven those changes. Therefore, we need to have more people and more time for that to happen. We also need to treat our children like the invaluable resource that they are, tending to their education and upbringing.

Infinitely Full of Hope

Being a More or Less Compendious Disquisition on The History of the Architecture and Furnishing of the Domestic Bookroom

2024-07-28 12:42

#wip #source #new

The Private Library is the domestic bookroom: that quiet, book-wrapt space that guarantees its owner that there is at least one place in the world where it is possible to be happy. The history of its architecture and furnishing extends back almost to the beginning of history and forward toward a future that is in equal parts amazing and alarming.

All libraries are magical rooms. All their windows look out onto Faërie, and all their carpets can fly. […] Entering our library should feel like easing into a hot tub, strolling into a magic store, emerging into the orchestra pit, or entering a chamber of curiosities, the club, the circus, our cabin on an outbound yacht, the house an old friend. It is a setting forth and a coming back to center. [^byers2021] (pp. 1, 3)

A visitor standing before this instantiation of language must have felt the true, right sense of the numinous.[^byers2021] (pp. 14)

A private library is a place for rest and relaxation, but also contemplation and thought. It is a place for the individual to find respite and transport oneself to new worlds. In its purest form, a library is only a library if that is its sole purpose. A study or an office can have many of the qualities of a private library but it may not truly be one if it can’t provide the enveloping nature of a pure library.

Continue reading

2024-07-01 09:52

#new #wip

People must have the freedom to act and the responsibility to act wisely. Without the freedom to act, responsibility is pointless; the system decides what actions can be taken and the responsibility or lack thereof for those actions is vested in the system, not the individual. Without the responsibility to act wisely, the freedom to act is risky and unfair; consequences for those free actions have to be upheld, both positive and negative; accountability for outcomes and whether the act was taken with proper consideration lie on the free person.

Note that this doesn't mean that we all have to be risk-averse. Just because you are responsible for your actions, doesn't mean we have to exact painful consequences. We can create a culture that gives freedom, demands responsibility in return, and then is benevolent with punishment for bad outcomes. If the action was taken in good faith — responsibly — and didn't work out, we can accept that as one of the tradeoffs for the other benefits we gain from F&R. If someone makes an honest mistake, they don't need to be shamed, hurt, or expelled. In fact, this honesty and transparency about outcomes combined with the lenient forgiveness of failure is what drives true freedom to do, build, create, innovate, and achieve.

Continue reading

2024-06-28 22:45

#new #wip

Locality of Behavior

references

2024-06-13 17:15

#source #wip #new #structure

The fundamental subject of The Myth of Sisyphus is this: it is legitimate and necessary to wonder whether life has a meaning; therefore it is legitimate to meet the problem of suicide face to face. The answer, underlying and appearing through the paradoxes which cover it, is this: even one does not believe in God, suicide is not legitimate. Written fifteen years ago, in 1940, amid the French and European disaster, this book declares that even within the limits of nihilism it is possible to find the means to proceed beyond nihilism.

– Albert Camus, Paris, March 1955¹

One must imagine Sisyphus happy.¹ (pp. 123)

2024-05-17 09:38

#wip #new

Pratt parsing (alternatively Top Down Operator Precedence or Precendence Climbing) is a method for writing language parsers.

Resources:

• YouTube Discussion of the method
• original Pratt paper, rehosted
• An ALGOL 60 Translator for the X1
• The Shunting Yard Algorithm
• Parsing expressions by precedence climbing
• Crafting Interpreters
• Pratt Parsers: Expression Parsing Made Easy
• Writing An Interpreter in Go
• Simple but Powerful Pratt Parsing
  • Resilient parsing

references

2024-02-25 14:54

#new #wip

content

2024-02-25 14:53

#new

This systems trap is the trap of addiction. This can be individual things like alcoholism or drug addiction, or it can be larger scale things like dependence on fossil fuels or government subsidies. This is caused by a state that must be maintained through constant intervention (the taking of pain killers or the powering of a nation via non-renewable, extractive means).¹

As with all traps, the best way out is by not getting into this trap to begin with. In this case, it's not simply rhetoric, but an important step to take by attempting to strengthen the system to shoulder its burdens by itself instead of intervening. This can also be a way out of the trap once we've fallen into it. Ask yourself: why are the natural correction mechanisms failing? How can obstacles to their success be removed? How can mechanisms for their success be made more effective?

2024-02-25 14:52

#new

Also known by the saying "the rich get richer" or in ecology "the competitive exclusion principle", the "success to the successful" trap of systems theory is that an actor's previous success advantages them towards success in the future. This results in a feedback cycle where only initial winners continue to win.¹

Marx observed that similar to ecological competition, market competition systematically eliminates market competition rather than encouraging it. This has been proven true economically many times over in the spanning years in the automotive, tech, telecommunications markets and many more. Thus, regulation such as anti-trust, "leveling the playing field" taxation, social norms (noblesse oblige), diversification of the system, or strengthening the weaker actors are required to get out of this systematic trap.

2024-02-25 14:51

#new

The escalation trap of systems is an exponentially increasing feedback loop predicated the goals of actors in the system being relative to the state of the system. For example, the United States and the Soviet Union escalated their nuclear arsenals so that they would have more, bigger, better weapons than each other, not based on some absolute amount of capability.¹

There are countless examples of this trap in our world. Typically the system will only break down when one of the actors breaks. Instead we should set limits and stopping points for these systems. There must be an off-ramp for actors that does not come at one of their expense over the other. Mutual disarmament agreements are hard to obtain though. Easier, and surprisingly (given the internal logic of the feedback system) effective is unilateral disarmament. One party should simply stop playing.

2024-02-25 14:50

#new

Also known as "eroding goals" or "boiled frog syndrome", this systems trap is a gradual process of letting standards and goals get worse and worse over time. It is often caused by feedback from weighing previous negative results more highly than positive ones.¹

In order to fix this, we should weigh previous positive results more highly than negative results. This will use the same gradual drift mechanism but push us upwards to better results, higher performance, or more ambitious goals. If this is not possible, we should keep standards at absolute levels instead of relative ones so that they can't drift (downward or upward) over time.

2024-02-25 14:49

#new

In a commons system there is a resource that is shared (e.g. a shared pasture for cattle grazing). For these systems to be tragedy, the shared resource must be erodible (i.e. the further it's degraded, the harder it is to regenerate the resource) and the users of that resource must be incentivized to use the resource even in the face of the erosion (e.g. immigrants may hurry or increase in numbers if they hear immigration laws are going to become tougher).¹

The way out of this trap is to educate people on the value of the resource and the necessity of conservation. If that doesn't work, privatization (splitting up and assigning portions) will create the feedback signal (cost) to individuals for them to feel the effects of everyone's actions. We could also regulate everyone's access to the resource in order to conserve it (e.g., limited entry to a popular national park).

2024-02-25 14:34

#new

A policy-resistant system is one where fixes don't produce changes. They exhibit balancing loops that make their undesirable behavior resilient to changes.

Imagine a system that has a strong balancing loop that produces some outcome that's continually being injected with some imbalance. It doesn't matter that there's something constantly pushing the system in a direction, the balancing loop overcomes that push and keeps the behavior consistent. Many governmental policy changes are examples of fixes for resilient systems that will simply result in the same outcomes due to the inherent structure of the system.[^meadows2011]

Many of these systems arise when the goals of the subsystems are different and incongruous with each other. In some cases, the effect of one subsystem pulling towards a goal causes the other subsystem to redouble its efforts to pull back. For instance, the end of prohibition drastically decreased the crime and chaos of the underground, illegal alcohol culture that had been developed during its enactment. Zealots often run afoul of this type of thinking: creating stringent rules by force causes the opposite outcome by intensifying the resentment and backlash from otherwise uninterested parties.

Continue reading

2024-02-25 14:30

#new

Problem-generating systems have to be completely restructured in order to be fixed. This is because these problem generating structures are resilient and self-organizing for the exact problematic behavior they exhibit (202402201202 Resilient systems, 202402201203 Self-organizing systems). No amount of policy changes, lever pulling, tinkering at the margins, or hope will produce a different system. Only a total restructuring of the system can produce a different behavior.¹

2024-02-25 12:32

#new

The rationality of actors and systems in the real world is bounded. People are not perfectly rational consumers in an economy. Organisms do things that are irrational for seemingly no reason and sometimes to their own detriment (e.g. the lumber industry deforests their environment unsustainably until their company fails).

The economist Herbert Simon coined the phrase "bounded rationality" for this. His definition of bounded rationality is that most often, people act rationally with the information they have on hand. The bounding of that rationality comes from inadequate or misleading information — such that their rational choice is actually an irrational one given the true information — or simply a "good enough" need to only sufficiently satisfy ourselves instead of rationally optimize everything.¹

2024-02-25 12:24

#new

In accordance with 202402251213 Hofstadter's Law, delays are everywhere. In 202203210833 Systems thinking, all stocks are a form of delay because 202402171455 Feedback can only affect future behavior. When modeling a system it is important to remember that 202203210832 Models are necessarily incomplete including the element of time. We may see a neat system of supply and demand, but even rational actors will exhibit "irrational" behavior — i.e. behavior that they would not take without delayed information (202402251232 Reality has bounded rationality) — in the presence of feedback delays.¹

2024-02-25 12:13

#thread #new

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.¹

A self-referential adage about how 202402251224 Delays are ubiquitous. It has continued to gain popularity in programming culture in particular connection to The Mythical Man-Month and the concept of estimating how long any sufficiently complex task will take to complete.

In Gödel, Escher, Bach, Hofstadter talks about the difficulty in creating a chess engine that could beat the top grandmasters. For years, the proponents of engines claimed that they would be able to win at the highest levels within the next few years. Such predictions always came to pass, then doubled or more and the goal was not achieved. Compare this to the AI bulls today. There are claims that artificial general intelligence is upon us and we can expect that breakthrough any day now. More than likely it will take a long time to ever achieve (if it's even truly possible technically or philosophically #thread)

Why is it so difficult for us to accurately predict things like this? #thread

2024-02-25 12:02

#new

The 202402251159 Limiting factor of a system can change over time. Take the example where adding potassium won't help crops if they don't have enough nitrogen. Now imagine that we add sufficient nitrogen to the soil, it's possible that the limiting factor might be the potassium or something else entirely like water or sunlight.

This can cause a "whack-a-mole" style expansion problem for optimizing a system. It's even possible that the shifts in the limiting factors could be at cross purpose with each other so that the result of helping one hurts the other.

In a business, it's important to remember this concept. Adding more salespeople to sell a product that you can't build fast enough won't help.

In engineering, it's an interesting analogy for quality, speed, and productivity over the long run. The limiting factor may not be quality now, but it could be in the future. Whether it's acceptable to trade that depends on many factors including the probability of making it to that future without failing.

2024-02-25 11:59

#new

There always will be limits to growth. They can be self-imposed. If they aren't, they will be system-imposed.¹

A limiting factor in a system is the one element that is most important to the overall behavior of the system.¹ For instance, when growing crops if there isn't enough potassium in the soil, your crops won't grow no matter how much nitrogen is available. The next logical conclusion here is that 202402251202 Limiting factors can change.

2024-02-24 18:23

#new

There are no separate systems. The world is a continuum. Where to draw a boundary around a system depends on the purpose of the discussion — the questions we want to ask.¹

When you draw boundaries too narrowly, the system surprises you because it doesn't sufficiently account for the reality of the situation. Conversely, when you draw boundaries too broadly, you fail to find something sufficiently descriptive and useful for reasoning about a system. The lesson here is that boundaries are a useful fabrication whose delineation amounts to an art rather than a science.¹

2024-02-24 18:21

#new

Our minds are very capable of rationalizing about cause and effect in a direct way. These direct (linear) relationships are often too simplistic to describe the reality of a system (202203210830 When your model and reality conflict, reality is always right). We simply need to remember that 202402241823 Boundaries don't exist in the real world and that 202203210832 Models are necessarily incomplete. These simplifications that are necessary, but always cast doubt on whether we're describing the true nature of a system or rather describing a useful mental model for thinking about an underlying reality.¹

2024-02-24 17:22

#new

Hierarchies — in particular biological hierarchies — enable iterative progress. They do this by allowing continual development of sub-assemblies that are stable on their own to combine with other sub-assemblies into a higher level assembly. If something is wrong with one sub-assembly, then it can be discarded without discarding the whole high level assembly. For example, molecules combine into biological components, into cells, up into organs, systems, and a whole human. Each cell is dispensable and replaceable without needing to discard the human. Growth proceeds simply one cell at a time iteratively from a single cell into the uncountable complexity of life.¹

Consider also how 202401291458 The purpose of the parts may not be the purpose of the whole and how this 202104291540 Emergence comes about from the parts.

This property is somewhat contrasted with (but maybe is more a subset of) things that are a 202109060904 Heterarchy.

2024-02-24 16:58

#new

Stability and resilience are not the same thing. Just because a system is stable, doesn't mean it can recover from a disturbance (which is the defining characteristic of 202402201202 Resilient systems).¹

For example, imagine a system that has an equilibrium on a fine edge where any change will cause it to rapidly diverge from the equilibrium. Even though it's stable on that "ridge line", it is not resilient to disturbance. A system that is stable and not resilient may follow the 202207272000 Garbage in, garbage out rule where 202207271958 Stability or instability dominates a system.

2024-02-24 15:50

#new

One example of a system with a renewable stock that's constrained by another renewable stock is the fishing industry. Similar to the oil economy example of 202402241536 A renewable stock constrained by a non-renewable stock, the capital and resource are constrained in the same ways but the resource can be replenished. The competing rates of these different loops can cause drastically different behaviors of the end system ranging from extinction to exponential population growth.¹

2024-02-24 15:45

#new

There always will be limits to growth. They can be self-imposed. If they aren't, they will be system-imposed.¹

In all physical systems, there must be at least one growth reinforcing feedback loop and one balancing loop. There are no physical systems that can grow infinitely. Eventually there will be a limit to the space, availability, or possibility of more of that thing.¹

2024-02-24 15:36

#new

An interesting two-stock system arises when there is a renewable stock constrained by a non-renewable stock. This system differs from one-stock systems because it is constrained by its surroundings. An example of this type of system is an oil economy. The non-renewable stock of oil, its production, and its long-term availability constrains the stock of capital in the industry. Investment — a renewable source of capital — and oil extraction and sales increase the capital of the oil industry, but the non-renewable availability will eventually limit the growth of that capital to the point where no investment will happen and the industry will dry up when oil is gone.¹

2024-02-24 15:30

#new

Business inventories are examples of single stock systems with delays. The inflows to the system are the supply of goods whether produced or bought. The outflow is the sales of those products. The feedback loops are the flow of information that dictate how much ordering or production of goods should be done based on things like the current rate of sales and the predicted demand in the future. These delays across time can be extreme in the case where custom production takes a long time per order or minimal in the case where flow is predictable. There can also be informational delays like lagging perception.¹

2024-02-20 15:26

#new #thread

Everything we think we know about reality is a model. Our models do have a strong congruence with the world. Our models [also] fall far short of representing the real world fully.¹

The purpose of 202203210833 Systems thinking is to make useful models of reality. There are major conflicts here: 202203210832 Models are necessarily incomplete, 202203210831 Models are immutable but reality isn't, and 202203210830 When your model and reality conflict, reality is always right. We know tremendous amounts about the world we live in and the systems we study, but at the same time we know preciously little. Our ignorance always far outpaces our knowledge (epistemology #thread and "I know that I know nothing" 202109071225 Socrates #thread) but at the same time, it's important for us to develop methods for rationalizing about reality. Otherwise, we wouldn't be able to actually exist, live, and thrive in the real world.

2024-02-20 12:04

#new

Often 202402201202 Resilient systems that are also 202402201203 Self-organizing systems will produce hierarchies in the process of self-modifying and self-organizing.¹ There are many reasons that hierarchies can be desirable — notably 202402241722 Hierarchies enable iterative progress and cohesion (202204272309 Modules should be loosely coupled, 202204272308 Modules should be highly cohesive).

Outside of the desirable traits of cohesion in man-made systems, biological or emergent systems that are modularly cohesive allow for less understanding and dependence on other parts. They are more resilient because there are parts that can take the place of other parts as long as they provide the same "interface" or function of the replaced part. For example, the human body is remarkably adaptable and there are parts of the brain that can completely rewire themselves to function as other damaged parts if needed.

2024-02-20 12:03

#new

The most marvelous characteristic of some complex systems is their ability to learn, diversify, complexify, and evolve.¹

Self-organizing systems are higher level 202402201202 Resilient systems. They have the ability to repair, modify, or produce their own feedback loops through complex interactions of loops acting on the loops themselves. This ability to modify their own structure is exactly what it means to be self-organizing.¹

Human bodies are remarkable examples of resilient, self-organizing systems.

Self-organizing systems can be so complex that they verge into the realm of chaos theory. In other cases, they can be more like a fractal, where a simple law produces infinite complexity. See The Computational Beauty of Nature.

2024-02-20 12:02

#new

Systems that work well are resilient: they can recover after being stretched or strained. Most often, resilient systems have rich feedback loops and interactions that allow a system return to some equilibrium, state, or function even after a large disruption.¹

Sometimes systems will exhibit even higher level resilience where they can repair, produce, or modify feedback loops themselves. These are 202402201203 Self-organizing systems.

Human bodies are remarkable examples of resilient, self-organizing systems.

Also, note that 202402241658 Stability and resilience are not the same thing.

2024-02-17 15:20

#new

Whenever you’re confronted with a scenario, as yourself questions to help you decide how good of a representation of reality the model is — but always remember 202503301254 The map is not the territory and 202203210830 When your model and reality conflict, reality is always right.¹

Some questions that might be helpful:

• Are the driving factors likely to unfold this way? Models of dynamic systems are usually not designed to predict what will happen. Rather they’re designed to explore what would happen if a number of driving factors unfold in a range of different ways.
• If they did, would the system react this way? Regardless of whether you think the driving factors will do something, would the system actually behave like that if they did?
• What drives the driving factors of the system? Who watches the watchmen?

2024-02-17 15:12

#new

The principle of shifting dominance in 202203210833 Systems thinking is when one loop dominates another, having stronger impact on behavior. Because systems often have multiple competing 202110231515 Feedback loops operating simultaneously, the ones that dominate the others will therefore dominate the behavior of the system as a whole. Finally, these dominating factors can change over time causing shifts in the behavior of a system as the dominance of loops wax and wane relative to the others in the system.¹

2024-02-17 15:07

#new

An example of a stock with one reinforcing loop and one balancing loop is population. The reinforcing loop is the birth rate and the balancing loop is mortality. Depending on the relative strengths of these loops, the stock will either increase, decrease, or remain completely unchanged. In reality the rates of these types of things are not constant and so the real system exhibits complex periods of moving in any direction. This is an example of 202402171512 The principle of shifting dominance.¹

2024-02-17 14:55

#wip #new

While mostly tautological — or physical based in relativity and information transfer — the statement that feedback can only affect future behavior is important. It describes “lag” and requires our attention to the lag time — if I’m ordering stock for my store inventory, I need to account for the continued outflow of inventory as the resupply of inventory is arriving after ordering it.¹

More generally, it means that flows can’t react instantly to other flows. They can only react to changes in stocks and after a delay. (huh? #wip)

2024-02-17 14:39

#new

An example of a one stock system with two competing balancing loops is a thermostat. The competition between to 202110231515 Feedback loops that are pulling a stock towards different goals. In the case of the thermostat, the climate control is pushing the room temperature towards the desired temperature and the differential between the room temperature and the outside world is drawing it towards the outside temperature. An interesting case is when the desired temp and the outside temp are the same and they both move to the same goal.¹

Todo, not right:

graph LR
  furnace-->|heat|room
  room-->|loss|outside
  room-->|discrepancy|furnace
  room-->|differential|outside

2024-01-29 14:58

#new

In 202203210833 Systems thinking, the purpose of all the elements of a system may be aligned to individual or shared ends. However the result of the system may not align with those purposes. It’s even possible for the purpose of the whole to be counter to the purpose of the elements.¹

This can also result in a hierarchy of sub-systems (202402201204 Resilient, self-organizing systems will generate hierarchies). It can be challenging to keep this hierarchy aligned to the desired outcomes.

2024-01-29 14:41

#new

Though we should use all of our different lenses for viewing and thinking about the world, a Systems Thinking lens has distinct benefits:¹

• It hones our ability to understand parts of the whole
• It allows us to see interconnections
• It gives us tools to ask questions about future behavior and get answers
• It gives us the power to understand and be confident at 202203231646 Affecting long-term change in the system

2024-01-29 14:25

#new

So what is a system? A system is a set of things — people, cells, molecules, or whatever — interconnected in such a way that they produce their own pattern of behavior over time. The system may be buffeted, constricted, triggered, or driven by outside forces. But the system’s response to these forces is characteristic of itself, and that response is seldom simple in the real world.¹

Systems are combinations: sets of things that combine to create behavior. Systems exhibit 202104291540 Emergence.

We our complex systems — our own bodies are magnificent examples of integrated, interconnected, self-maintaining complexity.¹

Systems must consist of elements, interconnections, and a function or purpose. Elements are easy to see, interconnections harder, and purpose hardest.

2024-01-29 14:11

#source #structure #wip #new

Donella Meadows lays out a concise, thoughtful, and thorough introduction to systems theory in Thinking in Systems.[^meadows2011]

Chapter 1 - The Basics

• 202401291425 Definition of system
• 202401291441 Systems thinking benefits all thought
• 202401291458 The purpose of the parts may not be the purpose of the whole
• 202401291554 All systems thinking is a simplification
• 202308281423 Ship of Theseus
• 202205021252 Stock and flow
• 202110231515 Feedback loop

Chapter 2 - A Brief Visit to the Systems Zoo

• One Stock Systems
  • 202402171439 One stock with two competing balancing loops
  • 202402171455 Feedback can only affect future behavior
  • 202402171507 A stock with one reinforcing loop and one balancing loop
  • 202402171512 The principle of shifting dominance
  • 202402171520 Ask questions to assess the validity of a model
  • 202402241530 One stock with delays
• Two Stock Systems
  • 202402241545 Physical systems cannot grow infinitely
  • 202402241536 A renewable stock constrained by a non-renewable stock
  • 202402241550 A renewable stock constrained by another renewable stock

Chapter 3 - Why Systems Work So Well

Continue reading

2023-12-20 14:32

#new

Ninety percent of everything is crap.[^wikipedia2023sturgeon]

Coined by Theodore Sturgeon in a 1957 edition of Venture Science Fiction, the quote was used in the context of critique. Sturgeon argued that science fiction — which at the time was derided for its low quality — was no different than other genres. He argued that all genres were mostly poor and therefore valid criticism against a genre (or anything really) should be leveled against the best examples of that genre rather than the 90% that's crap.

This is one of the most common problems that I have with modern writing, argumentation, and criticism. Many books, articles, blog posts, etc. level arguments in bad faith against a poor example of how something works in order to advocate for some other thing.

There is a small counterpoint, or perhaps more accurately, footnote to this idea though. It can be valuable for criticism to be leveled against the whole of an idea. For instance, if you focus your criticism against the best 10% of the idea and feel you've come to a conclusion or alternate idea, it can still be valuable to talk about the other 90% as an example of the scope of the downsides. If the worst 90% of my position result in better outcomes than the worst 90% of another position, that's a valuable data point.

Continue reading

2023-12-16 14:42

#new #thread

Software craftsmanship is a long journey to mastery. It’s a mindset where Software developers choose to be responsible for their own careers, constantly learning new tools and techniques and constantly bettering themselves. Software craftsmanship is all about putting responsibility, professionalism, pragmatism, and pride back into software development.[^mancuso2015]

Or more shortly

Software craftsmanship is about professionalism in software development.[^mancuso2015]

Software craftsmanship is a movement in 202109061338 Software Engineering. Though it is broadly a movement about professionalism and quality, most people active in this movement are proponents of things like Test Driven Development #thread, Pair Programming #thread, Mob Programming #thread, and “Clean Code” #thread. This reality directly contradicts the statements made by Mancuso in his book 202312091323 The Software Craftsman. Because of this contradiction, I have trouble feeling like the movement is net positive in the way that the Agile movement, eXtreme Programming (XP), and Lean Programming have all also failed as religions without context or flexibility. “You’re not doing it right or hard enough”. However, similar to those movements I do still agree with many of the underlying values even if the commodification of those values inevitably fail.

Continue reading

2023-12-16 13:43

#new

Agile is an adjective. You can’t do agile: you either are agile or are not.¹ More broadly, agile consultants, processes, systems, and the like are fundamentally not agile because they are prescriptive and not flexible or reactive. 202411261417 There can never be an agile process.

For all the effort in the 202109061338 Software Engineering industry to codify things that will automatically make you agile, it’s simply not possible. It’s a simple relationship between feedback and the autonomy and capability to act on that feedback. Get more feedback and treat all instances as individual instances in individual contexts. Remember that 202205031219 Agility is not equal to speed.

2023-12-10 18:39

#thread #new

There’s a saying in the medical field,

When you hear hoof beats, think horses not zebras.

Which is another way of expressing Occam’s Razor (make note #thread), where the simplest explanation is often the correct one.

The explanation of the saying is that zebras are rare in almost all circumstances, whereas horses can be found anywhere in the world. So it’s more likely that a horse is making the noise than a zebra.

This can be applied to programming in many ways, for instance when debugging the cause of some issue.¹

Be careful though, when you’re in the right circumstances it may actually be that zebras are the explanation or the more likely one. See this excellent talk about this side of the coin: Zebras all the way down #thread add citation better and stuff.

2023-12-09 15:34

#new

Before fixing a bug, we should write a failing test so that the bug can't be reintroduced later.

This is common collective wisdom, but mentioned specifically in 202307241042 The Pragmatic Programmer¹

2023-12-09 15:31

#new

When debugging code (or examining an argument or thought) it's best to remove all prior assumptions and knowledge. All code is suspect.¹ Furthermore, we need to stay calm, go back to basics, and take it slow and methodically.

2023-12-09 15:26

#new

Any skill that requires use of instruments or tools can be improved by increasing your proficiency with those tools.

As a programmer, these tools are things like editors and shells, reporting systems, languages, and more. Simply investing the time to be good and fast at using these tools will dramatically increase the quantity and quality of your output.¹

More broadly, what we're achieving here is a reduction in the explicit thought and effort that goes into turning our ideas into reality. Whether it's just typing out the code that I'm attempting to produce or soloing on a guitar, being better at the physical actions so that more of my mind is devoted to higher level thinking will yield positive results.

2023-12-09 15:20

#new

The limits of language are the limits of your world. – Wittgenstein

Our ability to express our thoughts as language limits our ability to perceive the world around us and imagine new possibilities.

In programming, this can be important because a language that has a tool or does not have a tool, may affect how you solve a problem.¹

2023-12-09 15:17

#new

MVPs should contain a full vertical slice of the application. Instead of delivering a UI or API without the other, we should fully scaffold and build each layer of the system and deploy it before releasing an MVP. This way, users get a real experience, we get real feedback on our designs, and a path to incrementally building functionality instead of doing big lifts.

This is also known as Tracer Bullet design.¹

2023-12-09 15:11

#new

All code is changeable. All code can be suspect. All developers can change any code with enough time and knowledge. 202312091509 There are no final architectures.

In organizations, we should strive for strong ownership of code on teams while encouraging people to contribute to other teams' projects when needed. Collaboration and quality of code goes up when we don't tell people that this code is "not their problem" or "that other team's responsibility".

Why would we want to block progress on code by requiring specific people to be the only ones to make the changes? Certainly owners should be involved or consulted at some point, but if someone writes a good PR, then those owners should accept it.

2023-12-09 15:03

#new

Make reversible decisions quickly and irreversible decisions deliberately.

This saying has been popularized in the tech world (though I don't know the original source to attribute here, it's also mentioned in 202307241042 The Pragmatic Programmer¹).

We tend to spend too much time in 202109090909 Decision paralysis when it's more often the case that either direction is fine and even if one is bad, we can reverse course. Because of this mis-attribution of weight on the importance of our decisions, we need a reminder like this one to push through that and take action.

Another interpretation of this is that 202312091509 There are no final architectures and 202312091511 There is no such thing as sacred code. Everything is subject to change and re-evaluation at any point in time. The only thing we should surely do is 202205031449 Optimize for change, which means making decisions with the knowledge that they'll be changed later.

2023-12-09 14:49

#new

We should code systems that encapsulate external systems at the boundaries of our system.

For example, if I'm building an app that consumes an API, I should encapsulate the specifics of the API at the very edge of my system. This is a translation layer that turns the calling and results of the API into a shape that I control.

This is a particularly powerful — and nearly required — pattern when working with type systems. We take in values that are unknown, spend the effort to well-type them at the boundary, and then the rest of our app does not need to check if that external value was good or not since they only use the internal representation. Using this pattern, you only 202312091445 Rely on what you control

See also: 202205121023 Use values as the boundary

2023-12-09 14:45

#new

Don't design systems to rely on properties of things you don't control.¹

A simple example of this is building an integration with a 3rd party. You may need to understand and implement specifics of an API that you don't control, but you should always write that code defensively and ensure that changes or bugs in their system won't affect yours. Of course, there are times when that system needs to be online for yours to operate correctly, but you can still ensure that your data isn't corrupted, or your users still have a good experience even though that other system is broken. Remember to 202312091449 Encapsulate at the boundary.

2023-12-09 14:34

#new

Every piece of knowledge must have a single, unambiguous, authoritative representation in your system.¹

Even though I do not generally like the DRY principle because of its over-generalization, misdirection, and ease of misuse (202204262054 Prefer duplication over the wrong abstraction), I do think that it can be helpful when discussing sources of truth.

For instance, an application should only have one authoritative way to get an object or model where important invariants and business rules can be housed. Then we know that everyone who's making a new user or something will have e.g. the same validation requirements.

2023-12-09 14:13

#new

In most areas of work, there's a time when the work done is good enough.¹ This point is reached when there's less value in continuing to work on the project than there is in finishing it.

The difficulty lies in knowing where this point is. It can be extremely challenging without concrete data or if we can't 202309011327 Define metric to value transfer functions using sensitivity analysis.

2023-12-09 14:00

#new

It's hard to argue with working code.

It's easier to ask for forgiveness than permission.

Creating change is tricky. A good way to go about it is to produce the change you want to see and share that experience widely.¹ If your change is positive or better than the existing way of doing things, then people will see. The evidence of something real and tangible that's already happening is undeniable and you won't get bogged down in theoretical arguments. 202208131431 Everybody loves an existence proof.

2023-12-09 13:23

#structure #source #new #wip

• 202312111413 Seniority is transient and relative

Chapter 2 - Agile

• 202312161343 You don’t do Agile
• 202411261417 There can never be an agile process
• (18 discussion) “Focusing purely on the process and treating software development like a production line leads to average 9-to-5 developers doing what they are told — they become factory workers.” This is what we do here with mobbing
• (19 discussion) bad faith argument in paragraph 2
  • See 202312201432 Sturgeon's Law

Chapter 3 - Software Craftsmanship

2023-10-30 11:05

#wip #new

Cure the lack of momentum and feedback.

1. Add some (very few for now) tests even if they verifies a bug continues to be a bug.
2. Set up CI/CD that tests and pushes always.
3. Continue to add tests
4. If it hurts, do it more and automate it more.

Crafting Code Podcast Ep. 2

2023-10-24 15:10

#new #thread

Instead of starting many things and splitting your attention, you should focus on finishing things that you've started. Note that "finishing" doesn't have to be seeing that project to completion. For example you can finish a project by deciding that you don't have time for it and won't continue with it. This relates to 202110181246 Limit work in progress to increase throughput. It can also mean focusing on finishing one fully working independent vertical slice of something before moving on to other pieces. This helps us always have useful versions of projects that can be put down or picked back up at any time.

How does this idea work with creativity learning or the fact that 202110212227 Moderate procrastination facilitates creativity? Creativity learning is about chasing the many interesting things that we see without worrying about becoming an expert in them. This leads to generalized knowledge (T-shaped etc.) #thread and this 202304031221 Breadth of knowledge fuels analogy.¹

2023-09-02 16:20

#new

When considering important trade offs, we can see that in many situations graphing the value of the cost or benefit of the two things will vary indirectly, forming an X shaped graph. Therefore, minimizing the total cost in the trade off will be a U shape sitting in the middle above the X. Similarly, maximizing the benefit in a situation might mean leaning fully into one direction.¹

2023-09-01 13:33

#thread #wip #new

If you're only going to quantify one thing, quantify the cost of delay.¹

We simply have no business trading money for cycle time if we do not know the economic value of cycle time.

202402251224 Delays are ubiquitous, so the cost of delay is the measure that returns the most value while building an economic framework for a project. It will lead to our ability to quantify other important variables such as the cost of queues, batch sizes, and variability.¹

How to quantify it? #wip #thread (should be answered later in the book)

2023-09-01 13:27

#new

When building an economic framework in a complex system, we should strive to understand the transfer function between measurements and value output. In order to understand how (for example) reducing response latency impacts total life-cycle profits for a project, we can vary that measure independently and see the outcome. We then put it back and vary a different measure. Doing this is called performing a sensitivity analysis. In this way we get the information we need to make economically based decisions (202309011312 The primary goal in product development is to make good economic decisions) for our complex product development systems (202309011322 We need more information for complex decision making).¹

2023-09-01 13:22

#new

Most complex systems have interconnected variables. We can't just make one change in isolation from others. If we could, then making decisions and affecting system-wide changes would be easy. In fact, one of our primary goals as developers is to 202312091440 Eliminate effects between unrelated things. In that case, we'd only need to know the direction of the change for that variable. In the case of a complex, interconnected system, we still need to know the direction of the change on each variable, but we also need to know its magnitude and be able to express all the variables' changes in direction and magnitude in the same unit of measure.

In the context of product development, this lends support to the theory that 202309011312 The primary goal in product development is to make good economic decisions. We build an economic framework, express each variable in terms of that singular cost, and can measure complex changes.¹

2023-09-01 13:12

#new

The primary goal in product development is to make good economic decisions. All other objectives should be viewed as secondary to the economics. This gives us a common comparison between (for example) quality and delaying go-to-market. This means that we should select the actions that we take based on an overall, quantified economic impact.¹

How though, does ethical concerns factor into this. We can say that we simply have be ethical even if it's not the best economic decision, but what happens when the ethics of a decision are not cut and dry. How does one keep these other — equally, or even more important — concerns around while also striving for a single economic decision mindset?

2023-08-27 10:55

#new #thread

Along with 202308141518 Be a pack rat for little facts, we should become capable at many things. We should try to be familiar with many different systems, languages, technologies, paradigms, etc. The value of being broadly capable may be less than apparent at first, given our current jobs might require us to only specialize in one tool. But when taking a wide view #thread of things, we realize that all of the things we learn and can do will influence our specialized actions as well. Breakthroughs rarely come from specialists #thread.¹

Range #thread

2023-08-24 17:43

#structure #source #wip #new

• 202309011312 The primary goal in product development is to make good economic decisions
• 202309011322 We need more information for complex decision making
• 202309011327 Define metric to value transfer functions using sensitivity analysis
• 202309011333 Quantify your cost of delay
• 202309011342 Measure output instead of activity
• 202309021620 Important trade-offs have u-curve optimizations

2023-07-24 10:42

#new #structure #source #wip

Book Website

Preface to the Second Edition

• 202308141544 Make the future less painful
• 202308281423 Ship of Theseus
• What makes a pragmatic programmer?
  • 202308271043 Be an early adopter
  • 202308141518 Be a pack rat for little facts
  • 202308271047 Be a realistic critical thinker
  • 202308271055 Be a jack of all trades
  • 202308281402 Care about your craft
• 202308271610 Quarry workers' creed

Chapter 1 - A Pragmatic Philosophy

• 202308282340 No broken windows
• 202312091400 Be the exemplar of change
• 202312091413 Know what's good enough
  • 202205031410 Design stamina hypothesis
• Think critically
  • 202304112152 Intellectual investment is like compound interest
  • 202208211352 There is no shortcut to learning
  • 202109060816 Do your own thinking

Chapter 2 - A Pragmatic Approach

• Good design is easier to change than bad design. Almost all other patterns boil down to "easier to change" or ETC or 202205031449 Optimize for change or 202204262114 Write code that's easy to delete, not extend.
  • This is a value (spectrum) not a rule.
  • This is why I don't like frameworks that lift a lot (tailwind style string classes everywhere in code) or rails magic. It's everywhere and pervasive and not good. Or things w/lots of non-standard tooling (bit or graphql)

Continue reading

2023-04-21 20:16

#new #wip

Water is life. Connection to humanity through water and rain. The smell of the earth after a warm rain.

2023-04-05 10:01

#wip #new

unless you have a good reason write it in [new tech]

Have to give autonomy, have to spend the effort to justify the reason not to, have to allow people to do the right thing without you dictating what that is.

• 202203231647 Leading from vision
• 202107240951 Visionary leadership style
• 202205111310 Migrations are the only solution to tech debt

Software unscripted change management minute 30

2022-09-18 20:13

#new #wip

• Pay attention to weak signals
• Resist the urge to be unreasonably optimistic
• Teach employees how to conduct emotionally uncomfortable conversations
• System operators need to feel safe in speaking up
• Realize that oversight and monitoring are never-ending

https://danluu.com/wat/

2022-08-22 16:35

#wip #new

Beauty will save the world.¹

2022-07-18 19:46

#wip #source #new

Category theory is abstract, but its abstraction makes it apply to many things around us in ordinary life.

What is category theory?

Category theory is the mathematics of mathematics

Mathematics is the logical study of how logical things work.

In order to study things logically, we have to ignore some details of reality that make things behave illogically. It's only in the abstract world where things do behave perfectly logically

Category theory is the logical theory study of the logical study of how logical things work.

The map of the London underground is a good example of a "mathematics", where the geographical map of the exact tubes are not the purpose. The slightly unreal, more representative version helps us in a certain situation navigate more easily. We choose to ignore certain details to represent things more logically.

Objects and morphisms

$A \rightarrow B$ means there's a $morphism$ between $A$ and $B$.

So if we have

$$A \xrightarrow{\text{is the mother of}} B \xrightarrow{\text{is the mother of}} C$$

We can deduce

$$A \xrightarrow{\text{is the grandmother of}} C$$

Instead of looking at things based on their intrinsic characteristics, we can learn a lot about them (and other things) by their relationships to other things: hence the "Category". This gives us more context

Continue reading

2022-06-28 20:18

#source #wip #new #thread

I want to teach computer science, what should I do?

vs

I want to make software, what should I do?

Need to ask questions about the desired solution to figure out things like goals, constraints, and methods before you can build that solution. In the education case, the “solution” is the curriculum.

Ask things like:

• What age are the students?
• What exposure have they had before?
• Is this required? An elective? An extracurricular?
• How long is the class? How often does it meet?
• Is it even a class or something else?
• How many students are in the room?

etc. but also think about things like

• Is there internet access?
• Is the teacher new to programming?
• Can the students type?
• Are there students with disabilities?
• Do the students have regular computer access at home?
• Do the students have regular computer access at school?

Think about

• Equity, Rigor, and Scale

Methods

1. Required courses

• Don’t scale though, need certifications for teacher. The economy for experts means that they’ll go to Jane Street and learn a huge amount more than public HS
• Rigor has to take a hit because everyone has to pass the course to graduate

2. Elective courses

• Not equitable. Hugely biased (currently) to white and asian males, failures and achievement gap #thread lead to further disparity.

Continue reading

2022-06-28 14:49

#source #wip #new

From a talk[^minsky2019] by Yaron Minsky of Jane Street.

Typed vs. Untyped

• Untyped — scripting, lightweight, friendly, and slow.
• Typed — Serious, professional, unfriendly, verbose, and fast.

Some definitions

• Values — data, things
• Variables — can be different values, part of the lexical portion of the language
• Expression — composed out of variables, values, and other things
• Types — categorization system for values; groups values into named groups; strings, integers etc.
• In untyped language, values have types
• In typed languages, values, variables, and expressions all have types. (For instance, variable is typed when it always contains a variable of that type)

Why types?

• Make programs faster, typically through compilation/interpretation loop having “hints” and more information.
  • V8 for instance can be super fast, within a factor of 3 or so from a compiled language (but this is through herculean effort of thousands of people over tens of years and complicated things like tracing compilers and things)
  • This is predictable performance vs V8
• Make programs more understandable

So why don’t people always use them?

• Often make programs more verbose — when the language doesn’t have a convenient way to express something, it’s difficult to express it at all or in a good way

Continue reading

2022-06-11 22:36

#new #structure #wip

Defining what makes an engineer a “senior engineer” is a murky task. There will always be differences from one company to another, but there are some general patterns that most people agree on.

Skill

• Achieved mostly independent ability to solve any task given.
• Knows when they need to involve others for things that they don’t have the skills for or believe should be group efforts

Responsibilities

2022-05-11 13:10

#wip #new

Migrations are both essential and frustratingly frequent as your codebase ages and your business grows: most 202205131318 Software only supports one order of magnitude before becoming ineffective, so rapid growth makes them a way of life.

In fact, if your software survives an order of magnitude increase, it may have been over-designed in the first place. Add to that the simple fact that they are usually the only available avenue to make meaningful progress on technical debt¹ and it follows that we have to know how to do them well.

So how are we going to deal with these inevitabilities?

• 202304051001 Use a simple heuristic to guide gradual adoption
• #wip

2021-09-08 08:47

#thread #structure #source #wip #new

A seminal essay on machine augmented thinking written by Vannevar Bush in 1945.[^bush1945]

He urges that men of science should turn to the massive task of making more accessibly our bewildering store of knowledge. For years inventions have extended man's physical powers rather than the powers of his mind. [These inventions] are new results, but not the end results, of modern science. Instruments are at hand which will give man access to and command over the inherited knowledge of the ages. The perfection of these pacific instruments should be the first objective of our scientists as they emerge from their war work. Like Emerson's famous address of 1837 on The American Scholar this paper calls for a new relationship between thinking man and the sum of our knowledge.

Consider a future device [...] in which an individual stores all his books, records, and communications, and which is mechanized so that it may be consulted with exceeding speed and flexibility. It is an enlarged intimate supplement to his memory.

Knowledge evolves and endures throughout the life of a race rather than that of an individual

Publication of research has been extended far beyond our present (1945) ability to make real use of the record.

Continue reading

2021-04-29 15:22

#structure #source #wip #thread #new

This is the main entry point into my knowledge graph. At the risk of being prescriptive about categories and connections, a single top-level entry point is useful to maximize discoverability. If you're looking for other things I do, check out my home page.

The lofty goal of this project is to contain all of my knowledge. I hope this will be a lifelong project where I can learn, collect, and create a record of my thoughts in a simple, plain-text format that should never become obsolete.

Workflow

This will change drastically over time, but in an effort to keep myself organized, here's my process.

1. Find a source of information
2. Create a #source note with solid citations (managed in Zotero) for taking notes while consuming the source.
3. Create, link, and manage the Zettel and my Zettelkasten.

For more information on the why and how of using a Zettelkasten, see 202107272242 The Art of using a Zettelkasten.

Tags

• The #structure tag is used for structure notes. These are hubs of Zettel that are connected under some sort of idea. They help with discoverability and maintenance of the Zettelkasten as a whole.
• The #source tag is a single Zettel to organize the notes I take while working through some source material. Each Zettel that's a #source is also a #structure Zettel. For example, I take notes while reading a book in a Zettel that's named for the book's title and tag it with the #source tag. These notes aren't technically needed if we do a good job citing sources, but it's helpful during the initial reading and note taking for long-form content that requires multiple sessions.

Continue reading