Religion is a hard topic to talk about. I want to make a few things clear:

- I love Mormons
- I want the Mormon church to be a good and happy place
- I take no pleasure in people leaving the church. I never encourage people to leave, nor do I encourage them to stay.

I am not mormon anymore. Also I will always be mormon in a way--it's in generations of my DNA, like green jello and funeral potatoes. I don't consider myself an ex-mormon, I prefer 'post-mormon.' I am not anti-mormon. How could I be? How could I be anti-the ppl I love or anti-me?

I do not consider myself a member of the LDS church, but I have not removed my records. Many like me I know also have not. I don't intend to remove my records--primarily out of love/respect for my family--although I think about it when I can't get out of mailing lists.

Unfortunately, there is a large wound in our community. It is a wound created as consequence of a sinister game. I call this game: Truth™.

Here's how you play Truth™. There is an important Truth. If you believe it (and act like you believe it within an undefinable margin of error covered by grace) you win. If not... you lose. These are the only two options. Not playing is losing.

The problem with this game is it feels good when you and everyone you know are winning. You can move out west together. You can make up new mini games to help the people who don't know or died before knowing to address some of the cognitive dissonance of the game.

There is one important group, however, that introduces a cognitive dissonance that is much trickier to deal with: People who were winning and then stopped playing the game.

These people are, in the minds of many winning the game, in the worst possible position. They are people who were winning and gave up. Worse than being a ignorant or a non-believer is being weak, or a traitor.

It becomes really difficult when you know this leaver closely. You test them... they still seem like the same kind, good person you knew. Maybe even nicer than some of the winners you currently know.

From within the framework of the game, this is impossible to understand. How can they not want to win? How can they lose and the mean winnner win?

Furthermore, voluntarily choosing to give up winning and deciding to lose can only be read as a signal that says: the game of Truth™ itself is Wrong™. This feels bad when you are winning, and can feel like an attack.

This is why some people who don't even know you at all, will personalize your leaving of the LDS church and make it about themselves.

This is why when people ask why you stopped playing the game, they are not looking for the answer, they are looking to make themselves feel better while continuing to play the game.

There is another group of leavers that doesn't get acknowledged as often. I was in this group for 6 or 7 years before I left. These are your prog-mormons or your nuanced mormons. People who are playing a new game, but still qualify as winners in the eyes of the old game.

The way to win this game is to create a bigger/superset game that contains the original game of Truth™, but adds more rules and nuance. Things aren't black and white anymore circa the capital T truth, but you're still playing in a way conducive to winning both.

This works for some people, but let me tell you: it is exhuasting. And ultimately, for me, I had to ask myself why I was playing at all.

Anyway, this is all way more conversation than I wanted to have about this on twitter, but I wanted to make my thoughts/intents more clear, as I have many LDS followers and friends I care about and don't want anyone to think I don't like them.

On Not Playing the Truth™ Game Anymore

We want to believe rational brain is in the drivers seat, but it’s not—feeling brain is always the driver, rational brain nudges/suggests. If you are out of touch with your body, rational brain starts to just to pursue whatever narrative makes your emotions feel good fast. https://twitter.com/avdi/status/1471311478594674696

This means “smart” people who are in positions of power and safety, where experience doesn’t force them to be present, need to be extra diligent, because all that extra compute/reasoning ability doesn’t make your decisions more rational, it helps your rationalize your decisions.

The Feeling Brain is in Charge

Lately been thinking about tests primarly in two categories: scaffolding vs structural. Some of my TDD tests are just scaffolding--they are for my verification while building, intended to be thrown away later. Others are important structural tests, and they will remain. https://twitter.com/redrapids/status/1453724820177182720

Scaffolding tests can be used also to test assumptions about how current code is working, to fix bugs, work in legacy code, and then they can be thrown away as well.

Too many folks come to loathe TDD because they keep all their tests as eternal baggage.

Automate the tests you are running, as long as you would do the manual tests.

Important note: manual != UI tests. Like, if you had a REPL would you test this in there? If so, automate it.

Scaffolding vs Structural Tests

This is absolutely correct. And this is why the arguments that somehow the gov won't be able to regulate blockchains and the dream that we will live in a libertarian fantasy will not come true. https://twitter.com/punk6529/status/1444762695811674121

This is the exact argument he makes in this viral thread: other stuff can be hijacked by guns, but... not all these things that 'is people' https://twitter.com/punk6529/status/1443923889319518214

We have already seen that governments can and will regulate crypto. (it's way easier than regulating taxis like he talks about in his thread).

Worse, we have also seen multiple times crypto fail to regulate anything (COMP threatening with IRS, ppl wanting gov to stop Elon manipulating markets).

Government is enFORCEment https://twitter.com/Jarsen/status/1442559034251362304

You think someone with a gun can't take your crypto wallet? Fine, what you've done is shift from A) give me your wallet or I kill you and then maybe take it anyway to B) give me your wallet or I kill you. Congratulations.

(incidentally, all that secures your crypto wallet is some sort of secret. a secret is also what secures your bank account. they are the same fundamentally)

Although, depending on how your wallet is secured you still are in A, not in B. All that matters is possession of the key.

Do you know what else might happen with your crypto wallet? You die, and you cannot distribute your funds to your inheritors.

I remember in my security classes in college learning an important principle: added levels of protection almost always carry unforseen consequences.

Example: Person gets very fancy car with biometrics. Thieves chop off hand AND take car instead of just taking the keys.

Everything that is digital, is actually physical. Not everything that is physical is digital. Remember this.

1's and 0's on memory or disk are physical. The internet is physical -- eletrical signals going across physical cables. Hackers know this. They can work the system from outside the system. Your digital systems are closed. The physical world is an open system.

The value of the 1s and 0s is relative--to humans. Humans and physical world will always be a fundamental constraint of any digital system. Social engineering, physical theft. Crypto cannot deal with this. The government may be able to.

It's People!

feeling this again this week https://twitter.com/Jarsen/status/1418599496770998274

I understand that saying blockchain is "just a database" is reductionist, and that what's interesting about it is not necessarily that it's distributed--it's that anyone can write to it and have a copy of it and you have an algorithm for consensus...

It's just not solving any of the problems people say it is. And not just because it's in its infancy, it's because many of the problems it wants to tackle are intractable human problems--and no amount of technoptimism can change that.

Any many of the problems of centralization, big corps owning platforms, etc., have many viable solutions already. The internet was designed as the ultimate decentralized network. Most of the tools are there already.

mastadon, etc. p2p. all this has existed and will continue to exist. what's missing is not blockchain. its adoption.

The other, very real and frightening reality, is that the physical underpinnings of the internet are very much centralized.

We don't need blockchain for 'web3'

I feel like so many people in the crypto/nft community are missing critical components. There is a fundmamental misunderstanding of "ownership" and "rights" and what they are and where they come from. and _WHO_ enforces them.

Rights and ownership ultimately are this: threats of violence. You cross this line, someone will do some sort of violence to enforce it. Fines, sanctions, isolation, corporal punishment, etc. All are punitive measures that requires a GOVERNMENT.

"Ah but this is a 'distributed' government!" ok, whatever that means. all that matters is this: when someone comes and takes what is yours, what do you do about it? Wave your pointer/token around in the air? You still don't have the thing in any meaningful way.

person points gun at you and says: transfer your BTC/NFT to me. what do you do??

but at least its on the chain, amirite?

all these folks want to be soveriegn citizens? what that really fundamentally means is the 'democratization' of violence.

a database will not protect you. distributed or not.

Someone shows up at your door: "Hi, this house belongs to me, this NFT says so."

The NFT doesn't matter. The authority of whoever granted it does.

Let’s say the “proper” authority decides to change their database to be a blockchain. Fine. Who cares? It’s an implementation detail. I don’t care if They use Postgres, MySQL, Hadoop, or invented their own.

“Ah but since they are NFTs the records won’t be fungible!!” Paper records aren’t fungible either. And there are plenty of problems with deeds and such that have to go to court.

Which brings me to another point. You want NFTs to show ownership? You gotta figure out who owns it first.

Fundamentally I don’t see a problem that NFTs actually solve.

Some artists are loving them… but the problem they solved for them (for now) was making some sales. Artists made money off people not understanding and/or wanting to signal.

What is "ownership?"

Software Development is like the story of the blind men and the elephant. We need a more _wholistic_ approach. 🐘

https://allpoetry.com/The-Blind-Man-And-The-Elephant

We often get caught up in a myopic view of the product & delivery we consider to be our domain, rather  than working as a Whole Team™. We deliver a wall with a spear poking through it and a fan hanging on a rope... instead of an elephant.

One of the key stumbling blocks is identifying with our roles/titles above identifying with our teams and customers. I may be a software engineer, and I bring certain expertises and points of view, but my job is to deliver value to the customer and build a good team.

Another stumbling block is conflating our titles with things that they reference. https://twitter.com/Jarsen/status/1419665451634749442

I love the Continuous Delivery principle: Everyone is responsible.

Who is responsible for delivering a product customers want to pay for? Everyone. The product is the value we deliver as a team to the customer. Sales, Marketing, Product, Eng, etc., all must work together. The product is much more wholistic than the Product Dept.

Who is responsible for a good User Experience? Everyone. A good experience is what people are paying for. UX is what we are selling. UX is the product. UX is the value. Someone with UX in their title does not exclusively own UX. Everyone is responsible for UX.

As a user my experience of the product (the value I am paying for) is a combination of the capabilities it gives me, the capabilities it does not have, the accessibility and ease of use, the learning curve, reliability and quality. UX is way bigger than a role. It's the business.

As a user, when I have a poor experience, I don't blame the QA department, or the engineers, designers, or Product. I just think it's a product I don't want to pay for.

Startups tend to understand this wholistic approach better. With fewer resources people need to wear multiple hats. People learn to BUILD AND SELL. This is powerful and you may want to recreate it at other scales. https://twitter.com/naval/status/1002104154737684480

Now, there are real roles and a need for people who are good at different areas of the product development process. We need PMs, UX Designers, Engineers, testers, etc. We just can't lose sight of the forest for the trees. 🌲

What we need to do, as a Whole Team™, is get together, and like blind folks experiencing an elephant describe what we see. "Oh you feel a fan?! Interesting. I'm sensing a rope over here." via COMMUNICATION and ITERATION the team approaches elephant.

There are many techniques to design our teams in a way that encourages this sort of holism. XP and others offer many principles and practices. I loved this idea from @GeePawHill the other day as well. https://twitter.com/GeePawHill/status/1438546197233426438

Anyway, there is no Silver Bullet here. There are only principles and practices we can try, and COMMUNICATION and ITERATION. Remember principles, and treat our practices as tools--models that are wrong but we use as long as they remain useful. https://twitter.com/Jarsen/status/1428749013495422979

We need to build our product from a wholistic point of view. We cannot do this, without the Whole Team™. Focus on building a team that communicates well, internally and with customers, and a team that knows how to iterate.

The Blind Team and the Software Elephant

Systems as a tool to align Purpose and Values 🧵

A system is a made up of three things: elements, interconnections, and a purpose/function.

Elements are the components that interact.

Interconnections are how the elements interact and flow.

The purpose of a system is what the system does.

Systems live in our heads. They are models we build based on our observations of the world. They model our experience of the real world, not the real world.

All models are wrong, some are useful.

In other words, a system is not intended to be a logical, complete, and consistent description of reality. This is impossible anyway. (See Godel's Incompleteness Theorem and Wittgenstein “The limits of my language means the limits of my world.”)

A system is intended to be a useful model for us to interpret our experience, and to inform when, where, and how to act for the highest probability of movement towards a desired outcome.

Adapt your model over time. Treat it as a heuristic, not an ideology. A heuristic serves you. You are the servant of ideology.

Alignment (harmony, peace, happiness) between experience and desire is a fundamental topic of many philosophies and models for how to live 'well.' You can do two things:

1. Change your expectations to match your world (acceptance)
2. Change your world to match your expectations.

Acceptance can be hard, but it is usually the most direct route to this alignment; we have much more influence over our expectations than we do over the world.

Acceptance is at the core of stoic philosophy, and much eastern philosophy.

“If you are distressed by anything external, the pain is not due to the thing itself, but to your estimate of it; and this you have the power to revoke at any moment.” - Marcus Aurelius

However, acceptance does not mean surrender. Acceptance is the opposite of ignorance or denial. Sometimes, when things matter, we should "be the change we wish to see" in the world. But we have to prioritize.

Thinking about systems can be a useful tool.

1. Being able to model how your world currently works gives you something to accept.
2. Being able to model how your world currently works can help you identify the most impactful changes.

One of the most impactful things about systems thinking to me is a definition of system's purpose: *A system's purpose is what it does*.

This captures the heart of acceptance. So much of our suffering is misaligment between what a system does, and what we want it to do. We might say something like "the system is broken." It's not. The system is doing exactly what it was designed to do.

This may sound uninsightful and pedantic. I think it is powerful--it decouples our values from the system and allows us to think better about solutions, and see the problem space better.

For example, over the past years, when we see awfulness in America I hear fellow American's exclaim: "This is not who we are!" But the proof is in the tasting of the pudding. By their fruits shall ye know them. Our screams of denial don't change the facts of what we can see.

So how do we create change? Personally? At home? Work? Community? Country? World? There is no one simple answer. But the further left in that list, the less complex the system and hopefully easier, and perhaps sound places to start.

Whatever we choose, for me I think one of the (maybe the) hardest things is prioritization. What matters *most*? Only one thing can be most important. One thing can be second most important. Figure that out (they can change! you and the world are dynamic. we contain "multitudes")

Once we know what matters--what the higher level outcomes we want are, the Theory of Constraints offers one point of view on how to do next: find the biggest constraint and focus on that. The system can only be as effective as its least effective part.

If my washer takes 30 min and my dryer takes 40 min, getting another washer will not increase how fast I can do laundry. The dryer is the constraint. Another washer will just start creating a queue, aka increase WIP https://twitter.com/Jarsen/status/1425474612855377931

Let's say there is a several cultural change I want to make at work. If those changes compete with each other for the same resources (attention, time, energy) and push all at once, I am working against myself. Can I identify and evangelize for the most impactful one first?

This is hard. All of the changes may be important. But the system has real constraints--limited capacity for adaptation at a single time. We may be pouring water over an already-saturated sponge. It's not going to do anything.

Anyway, I don't know much. But I have been thinking about this a lot lately as I look at myself. As I work day to day. As I read the news. There is so much to change. It feels overwhelming. Overwhelmed, I feel like shutting down.

The only way I keep going: 1) Accept the system. 2) Identify the most impactful place for change I can be a part of, 3) put my energy into where I can do the most, accepting the things I cannot change (for now). Then back to 1.

Systems as a Tool for Alignment

Continuous Integration. Principles. A Practice. A Pipeline.

There is a lot of ambiguity around CI. I'm a broken record here, but I will never give up. 🔁💿💛🧵👇🏻

"Team programming isn't a divide and conquer problem. It is a divide, conquer, and integrate problem." -- Kent Beck

First, principles: Nonlinearity ⤴️, Continuity 🟢, Small Batches 🥃

⤴️ Nonlinearity: If we were to model the risk of a change over time, we would not likely not have a line—our model would probably look exponential. The longer we work on something without delivering, the exponentially more risk we assume.

What Risks? Not delivering. Not delivering on time. Delivering the wrong thing (wrong from the start, or needs changed and didn't adapt). Delivering a buggy solution. Delivering a less valuable thing. Internal politics and conflict. Team burnout.

🥃 Small Batches:Smaller batches reduce overall risk in nonlinear environments. You can see in the new graph that the shaded area under the curve is much less. We still have risk, just less risk. Want even less risk? Make the batches even smaller.

(A great, more in depth read on this topic by @jessitron here): https://jessitron.com/2021/01/18/when-costs-are-nonlinear-keep-it-small/

In the view of CI, a batch is "done" when it is merged into the main branch of code. This act of delivery is called Integration.

🟢 Continuity: Uninterrupted flow. Things are continuous (e.g. unbroken line) or discrete (a disconnected dot). If we put the dots close enough and squint, the dots start to look like a line.

When we are looking for continuity in the dimension of time:

🥇 "Always" is best (actually continuous)
🥈 "As frequent as possible" is probably the best we can do.

CI is a practice designed to help address risk. The base assumption is that our risk over time is exponential, and that smaller batches will reduce that risk. The solution is: integrate as frequently as we can to drive our risk towards 0.

The pipe dream of CI, like Lean Manufacturing, is a Continuous Flow of value. The reality is messy.

To integrate more frequently, we need to take hard look at traditional quality control methods. PR review, manual QA, and other human gatekeeping constrain flow. But removal of these bottlenecks requires replacement principles+practices to to make sure we build quality in.

Since these human costs are expensive overhead that makes it difficult to push our batch size even smaller, we turn to automation whenever possible. The automation of the build and test phases are the "CI" part of a CI/CD pipeline.

In a twist of irony, CI/CD pipelines often now automate the _opposite_ of CI. The CI Pipeline has begun to become seen as the actual practice of CI itself. It doesn't help that this service is continuously running "integration tests."

I like to call this: Continuous Disintegration. (It's more fun that discontinuous integration). Folks continuously create new branches to try to solve problems in isolation, seeking to delay integration as long as possible.

CI is not easy. It can require a shift in mindset in how you approach problems. It may require a broader cultural shift. There is always room for continuous improvement

It also can leave questions around "how do avoid integrating bad batches?" This is where other principles and practice (like Continuous Delivery) come in. But we'll leave that for a later thread, or you can read some of what I wrote about it here https://cogitator.substack.com/p/antifragile-continuous-delivery

You Might Not Be Doing CI

A list of pithy, trite, loosely organized (and held) personal opinions, theories, and heuristics around software development. 🧵👇🏻

Change is the only constant. Build sociotechnical systems that embrace change.

You must understand feedback loops to build systems that embrace change. Agile, XP, CI, CD, DevOps, DevSecOps, etc., are all about "shifting left." Always be trying to smoosh your process into the quickest, wholistic feedback loop you can.

There are no best practices, only tradeoffs. What do you want to optimize for? Priorities. You must first understand and align as a team along your values and desired outcomes.

Systems are not good or bad, only relatively efficient or inefficient at influencing desired outcomes.

Create feedback loops and align incentives with desired outcomes.

Alignment is not "top-down" or "bottom-up". Alignment is bidirectional in its simplest form, multidimensional in others. Leadership is about alignment, and everyone can be a leader.

Authority is the weakest form of leadership. Real leadership does not look like an org chart.

Optimize systems for business outcomes, not individual productivity.

Fit your team to the problem, not the other way around.

Ethics: Do not accept business outcomes you believe detrimental to higher priority values. Fight. Blow the whistle. Quit. Do what is necessary.

Dependencies/prioritization are the fundamental problem in software development. We want to remove dependencies and priorities until we are left with only the essential. This is a Hard Problem™.

Computers are good at multitasking because they do what they are told. Humans are bad at multitasking, because dependencies are hard. (and usually write buggy concurrent/parallel software dependencies are hard)

Software architecture is a sociotechnical system. You must not consider software architecture without thinking in terms of humans and human systems. It is not a technical vacuum. Humans first.

Work in small, vertically integrated batches.

Resist horizontal platform teams like the plague. You may need them, but they need constant resistant feedback to reinforce healthy boundaries.

10x, and maybe 100x or 1000x engineers __do__ exist.

>= 10x:  They are not lone-wolf code hero genius A-Team unicorns. They probably aren't even the best "programmer" you know.

>= 10x: They are outcome focused people with great team skills ("force multipliers") who ask good questions, and know how to identify the high priority/impact tasks and break them down into small, meaningful batches.

>= 10x engineers lead regardless of role or title. They know how to elevate their team via a patient game of "yes, and".

If somone claims to be a >= 10x engineer, they are probably not.

This is a job. Coding outside is not necessarily positively correlated with your impact on the team and business outcomes. See: burnout, ego, optimizing for the teams flow over individual productivity.

Everyone has an inner pragmatist, and an inner dogmatist. Surround yourself with people who bring out the former.

The only question that matters about the quality of code architecture is: "is it easy to change?"

Stop talking about "clean code", "clear code", and code that is "easy to understand."

The best architectures tend to be variations of Functional core, Imperative Shell. (onion, hexagaonal, clean... all look the same from enough distance).

Abstraction is a tradeoff. Prefer duplication to the wrong abstraction. DRY is a tool, not an ideal.

All programming languages, software, and systems are beautiful garbage. Have fun but don't worry about them so much. Learn to have more fun solving problems. Delivering great software to users if the highest fun.

Your standup is probably ineffective and standup is not necessary for Agile. But it is fun to get the team together for 15min.

If you are trying to go from a known A to an exact known B in as little time as possible, a Waterfall process may be preferable to an Agile one.

Software development is a giant fractal system. The processes, principles and practices at the level of a class or module interface repeat at the boundary of a service, of a cluster of services, repeat in teams processes, departments, and orgs structures. Look for the patterns.