Modularity and Re-use (and the always omitted, more important concept: combinatoriality)

<dl> 
 <dt>Modularity</dt>
 <dd>Modularity is the degree to which a system's components may be 
 separated and recombined.</dd>
 
 <dt>Reusability</dt>
 <dd>Reusability is the use of existing assets in some form within the 
 software product development process. Assets are products and by-products 
 of the software development life cycle and include code, software 
 components, test suites, designs and documentation.</dd>
 
 <dt>Combinatoriality</dt>
 <dd>Combinatoriality is a sociological quality of software that can be 
 combined (or piped together) in any combination to meet, exactly, the 
 unique vision of the creative individual or team. This is achieved by 
 using uniform function arity, argument order, name schemes and 
 conforming to a spartan set of well-established standards appropriate 
 for the programming language and stack at hand (e.g. streams or 
 Promises).</dd>
</dl>

Combinatoriality is what we really want when we say modularity or reusability. 
 Modular code is separated code. It can be like turning a block of chocolate into
 chocolate chips with a hammer. The chocolate is not broken up, but not exactly
 designed to be fit back together in any configurations. Re-use is the right word
 for an aspect of what we mean, but doesn't get at how re-use is encouraged / or 
 when, why and how we re-use. Hence, combinatoriality to the rescue.

Combinatorializing code is one of those things in life where you just can't do it
 unless you have guiding principles for it. It's too complicated to handle it well
 any other way. The great news is that it's not so hard once you solidify the 
 principles and excersice them in a team context a few times. Team context is 
 needed because combinatorialization is not very meaningful unless there are 
 teammates to combine your creations into creations of their own.

I can't stand here and tell you what your combinatorial guiding principles are.
 I'll share a few of those that have worked for me and my teams as an example.

<ul>
 <li>Functions should never have more than 4 arguments</li>
 <li>If there's a callback, it should be last</li>
 <li>If there's an options object but no callback, the options object is last</li>
 <li>All functions should be designed with partial application or currying in mind</li>
 <li>Options objects should be prefered over individual arguments</li>
 <li>Never call a directory or module utilities when a more specific name can be used</li>
 <li>Eliminate all naming redundancies: FooView/BarComponent/BazElement/QuxVisualization—pick one</li>
</ul>

There are a few practices that will naturally aide in combinatoriality.

<ul>
 <li>Unit testing</li>
 <li>Asking people to use your code in front of you</li>
</ul>