diff --git a/content/books/things-i-learnt/_index.md b/content/books/things-i-learnt/_index.md
index 3c908d0..65316db 100644
--- a/content/books/things-i-learnt/_index.md
+++ b/content/books/things-i-learnt/_index.md
@@ -35,6 +35,7 @@ template = "section-contentless.html"
 		* [One Commit Per Change](one-change-commit)
 	* Project Organization
 		* [Organize Your Code by Data/Type, Not Functionality](project-organization)
+		* [Create Libraries](libraries)
 	* Writing code
 		* [Be Ready To Throw Your Code Away](throw-away)
 		* [Future Thinking Is Future Trashing](future-trashing)
diff --git a/content/books/things-i-learnt/libraries/index.md b/content/books/things-i-learnt/libraries/index.md
new file mode 100644
index 0000000..ac3a563
--- /dev/null
+++ b/content/books/things-i-learnt/libraries/index.md
@@ -0,0 +1,48 @@
++++
+title = "Things I Learnt The Hard Way - Create Libraries"
+date = 2019-07-15
+
+[taxonomies]
+tags = ["en-au", "books", "things i learnt", "libraries", "project organization"]
++++
+
+One thing you must learn is how to break your project into smaller libraries,
+to avoid doing rounds to deal with "the same, but a bit different".
+
+<!-- more -->
+
+I've seen a lot of projects that use things like branches for different
+things. Say, you have an e-commerce page. But you also have different clients,
+and they all have different colours and logo. Some people would take this
+scenario and, using the VCS properties, use the main branch for the main code
+and a branch for each client, merge from main branch from time to time -- and,
+thus, the branches are never merged back.
+
+This is suboptimal, 'cause that's not how VCS are supposed to be used.
+
+But you can, for example, break the main code into a library/framework and
+have one project for each client, with their assets and you just reference the
+library/framework in each.
+
+Simple and clean.
+
+But stop there for a second. Although this makes the code cleaner, avoids
+duplication and uses a VCS in the way it was supposed to be used, you can't
+start this way.
+
+Remember that [future thinking is future
+trashing](/books/things-i-learnt/future-trashing). What you can do is actually
+break your project by functionality, [making modules related to their
+data](/books/things-i-learnt/project-organization) and then, when you get a
+reasonable number of clients, you'll notice what can be reused in each, what
+modules make sense for one client and not for another. And then you'll have a
+good way to deal with those.
+
+One project that may appear when creating libraries is "How do I create my own
+library repository?" 'Cause all modern languages today have support for
+importing external libraries and, even if your libraries will never be out of
+your control, they are external to the project. So you may need to learn how
+to deal with this before creating the libraries. And, unfortunately, each
+language and build tool has its own way to manage this.
+
+{{ chapters(prev_chapter_link="/books/things-i-learnt/project-organization", prev_chapter_title="Organize Your Code by Data/Type, Not Functionality", next_chapter_link="/books/things-i-learnt/throw-away", next_chapter_title="Be Ready To Throw Your Code Away") }}
diff --git a/content/books/things-i-learnt/project-organization/index.md b/content/books/things-i-learnt/project-organization/index.md
index f86599b..f587680 100644
--- a/content/books/things-i-learnt/project-organization/index.md
+++ b/content/books/things-i-learnt/project-organization/index.md
@@ -81,4 +81,4 @@ transformations and such, but without the Data3 part). By breaking by their
 types, I managed to create small modules for each one and the new project
 would simply reference Data1 and Data2, but not Data3.
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/one-change-commit", prev_chapter_title="One Commit Per Change", next_chapter_link="/books/things-i-learnt/throw-away", next_chapter_title="Be Ready To Throw Your Code Away") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/one-change-commit", prev_chapter_title="One Commit Per Change", next_chapter_link="/books/things-i-learnt/libraries", next_chapter_title="Create Libraries") }}
diff --git a/content/books/things-i-learnt/throw-away/index.md b/content/books/things-i-learnt/throw-away/index.md
index f051141..30e445c 100644
--- a/content/books/things-i-learnt/throw-away/index.md
+++ b/content/books/things-i-learnt/throw-away/index.md
@@ -39,4 +39,4 @@ And not just code that solves the problem, but also the tests for that code.
 ... unless you focus mostly on [integration
 tests](/books/things-i-learnt/integration-tests).
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/project-organization", prev_chapter_title="Organize Your Code by Data/Type, Not Functionality", next_chapter_link="/books/things-i-learnt/future-trashing", next_chapter_title="Future Thinking Is Future Trashing") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/libraries", prev_chapter_title="Create Libraries", next_chapter_link="/books/things-i-learnt/future-trashing", next_chapter_title="Future Thinking Is Future Trashing") }}