• Evan Czaplicki's talk The Life of a File.

• Richard Feldman's Frontend Masters Elm courses

• Explore many different data modeling options

• Make Impossible States Impossible Elm Radio episode

• Wait until you feel the pain vs create abstractions before you need them

• Does the code quality metric of line count apply in Elm since there's no spooky action at a distance

• Aim for loose coupling, high cohesion

• Localized reasoning

Core mechanics of Elm modules

1. (Organize) Grouping functions values types
2. (Hide) You can hide some of those things. Allows encapsulation, shielding from breaking changes, avoiding coupling.

• Create modules around domain concepts
• Use ubiquitous language

Giant update functions

• You can think of the update function as a delegator - get things to the right place rather than doing the work itself

• elm-review

• TCC (test && commit || revert)

What are you gaining from extracting a module?

• Protecting invariants

• Hiding internals

• Decoupling

• TDD helps drive module design.

• Experiment, but review your experiments before they become deeply ingrained.

• Pain in code is for sending a message.

• Technical debt isn't about "clean code". It's abstractions that serve what the code is doing. Abstractions are inherently expensive and a type of tech debt if they don't serve a purpose for your specific needs.

• Be proactive - immediately as soon as there is a clear way to make code better (not perfect, small improvement) - do it

• Relentless, Tiny Habits

• elm-test Elm Radio episode

• Testing is helpful for identifying modules - see keystone testing habit blog post

• Property based testing is a sign that something is a module - it has a clear property, which means you want to protect the internals

• It's okay to get it wrong, just don't get it all wrong up front with premature abstractions.