[demilicious]

This makes a whole lot of sense to me. However, one of the elements of truly productive learning is _focused_ practice; that is, practice with mindfulness and intentionality directed at a specific element. One won't necessarily get any better at decoupling unless it is specifically practiced. To that end, _how_ would one truly practice the skill of decoupling? Or maybe, what resources or heuristics or strategies would you suggest to help draw the lines between behaviours or modules?

The first thing that comes to mind is Gary Bernhardt's talk on Boundaries, or "functional core, imperative shell", but I'm not sure that this is entirely what you're discussing here.

[wellpast]

I think you're hitting the nail on the head. It is specific and focused practice. I've been thinking about working on a book or set of blog posts or something to try to flesh out what a regimen would look like.

Most writing on software of course is technical (on PLs, algorithms, processes) but there seems to be very little to guide the software practitioner who really wants to seek mastery.

> what resources or heuristics or strategies would you suggest to help draw the lines between behaviours or modules?

The best I can come up with for teaching this would be to create some concrete "problems"/scenarios that would exercise the skill set, and then reveal various ways the problem could be decomposed and quantify the degree of decoupling and even reveal the practical consequence of the coupling by introducing new "requirements"/dimensions to the scenario.