Frameworks vs Libraries (or Systems vs Tools)

Frameworks tend to make your design decisions for you before your project ever exists so you are always going to be constrained to the framework's approach, which invariably yields a selection of the problem space much smaller than the total space advertised by the framework that it is the solution of. These blind spots arise mainly from the designers' ignorance and/or bliss. Also there are always hidden and abstracted layers of auto code that you don't know about and/or don't want to know about.

Libraries tend to be collections of utilities where each is maximized to their most useful and basic utility without diluting the value of each utility below the threshold of convenience, novelty, or beauty. Good libraries don't impose state or evolutionary patterns on your project.

Conclusion: Use a framework for something dreadfully time or resource constrained with the idea to redo it later.

On Selecting, Editing, and Using a Development Pattern or Design

Often trivial design elements, whether used for pedagogical work or because they posit a facile but expressive symmetry, are extrapolated due to affinity for their deceptively elegant ontology into absurd abstrusions that abrade utility in a most vexing and distracting counterpoint. When the prescribed design presides over the dictates of the existential problem or need set, the design eclipses the problem by a scale measured in orders of magnitude.

Conclusion: Don't code to a design when the design malevolently subverts the problem you are trying to solve.

The Proper Method of Maintaining Institutional Knowledge

Ideally, each engineer on a team will actively promote and disseminate their essential institutional knowledge until at least one complete logical copy thereof exists in and can be assembled from the P2P context of the team's total knowledge collective.

Conclusion: Don't hide or allow to be hidden essential knowledge from the team's communication network.