@jacob thanks again for this!

Literally invoked it today!

As you become more senior in any field, your job becomes less about being right and more about avoiding being very wrong—mostly because your work directs others on where they should focus their work.

Understanding cardinality prevents performance disasters. A dashboard with user_id filters can function just fine in QA but crashes in production because high-cardinality fields create massive joins. I know of no automatic fix for this. It just requires careful thought in design.

Why did the C programmer go to therapy?

They had too many things unresolved.

Be wrong fast. For new features, you'll get it wrong. You just will. Ship insanely fast - from whiteboard to ugly prototype within days. If users don't respond, question what you're doing.

@jacob Deming’s Red Bead Experiment seems like a perfectly fine name.

Its name reminds me a bit of a different thing called the Blue Dot Effect.

https://news.harvard.edu/gazette/story/2018/06/harvard-researchers-may-have-answer-to-why-youre-never-satisfied/

@claushc "It has to work!"

I LOVE IT! ❤️

@jens I do as well—it's just that for w/e reason he's most known for the "mythical man month" idea

@solarisfire yes, things exactly like that!

@jasonpunyon @codinghorror That's Atwood's Law, right?

Sources to blogs or books would be appreciated if you have them!

I'm trying to build a list of them! :D

Hit me with different principles or laws of software engineering.

I'm thinking of things like:
- Brooks's Law: adding people to a late project makes it later
- Conway's law: an organization tends to produce systems that are a copy of its communication structure
- Kernighan's Law: since debugging is twice as hard as writing, cleverness while writing is something to be avoided

@xanathar 🤣 🤣 🤣 🤣 🤣 🫠

Brook's Law remains true decades later: adding engineers to late projects makes them later. New team members require onboarding, communication channels increase exponentially, and integration points multiply.

Conway's Law means your org chart invisibly shapes your architecture. System design and organizational design are linked - you can't fight it but you can influence by how your structure your org.

Giving me Tron vibes

"Second: the modern internet exerts a tyranny over our imagination. The internet and its commercial power has sculpted the computer-device. It's become the terrain of flat, uniform, common platforms and protocols, not eccentric, local, idiosyncratic ones. This is out of necessity: if two or two hundred or two million or two billion computers are going to communicate with each other, they simply must agree on quite a bit."

https://github.com/timhwang/nyrc/blob/main/NYRC%201%20-%20The%20Computer%20is%20a%20Feeling.md

Recognize the Blue Dot effect: as major problems are resolved, your threshold for what constitutes a "problem" shifts dramatically. Without calibration, teams spend disproportionate time on increasingly trivial issues.

The best time to plant a tree was 20 years ago. The second best time is now

The 10x engineer myth persists because some engineers avoid time traps. More directly, some engineers get stuck implementing service catalogs for 3 services, starting an RFC process for 5 people, or creating "future-proof" abstractions. They also tend to be uncompromising in "doing things right" which means lots of time and heavy processes for relatively little value.

The stages of debugging a race condition:

2. anger
4. depression
3. bargaining
5. acceptance
1. denial