Evan Czaplicki's talk The Life of a File.
Richard Feldman's Frontend Masters Elm courses
Explore many different data modeling options
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
Core mechanics of Elm modules
You can think of the update function as a delegator - get things to the right place rather than doing the work itself
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
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.