Sean Moubry moubry

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

Clarify and agree on the scope of the system

User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?

Ableist Language in Code: Sanity Check

Removing ableist language in code is important; it helps to create and maintain an environment that welcomes all developers of all backgrounds, while emphasizing that we as developers select the most articulate, precise, descriptive language we can rather than relying on metaphors. Quite simply, avoiding ableist language lets us make sure we are inclusive of all developers, while moving toward language that is simultaneously more acccessible to developers whose first language might not be our own.

The phrase sanity check is ableist, and unnecessarily references mental health in our code bases. It denotes that people with mental illnesses are inferior, wrong, or incorrect, and the phrase sanity continues to be used by employers and other individuals to discriminate against these people.

There are a ton of alternatives, and one of the best ways to select one is to ask yourself: What am I actually checking? and select something more descriptive. In everyday c

	h = {
	'a' => :a_value,
	'b' => nil,
	'c' => false
	}

	h.fetch('a', :default_value) #=> :a_value
	h.fetch('b', :default_value) #=> nil
	h.fetch('c', :default_value) #=> false
	h.fetch('d', :default_value) #=> :default_value