New chapter: always use VCS

content/books/things-i-learnt/_index.md

@@ -30,6 +30,8 @@ template = "section-contentless.html"
 		* [The Function Documentation Is Its Contract](document-is-contract)
 		* [If A Function Description Includes An "And", It's Wrong](document-and)
 		* [Good Languages Come With Integrated Documentation](languages-docs)
+	* Source Control
+		* [Always Use A Version Control System](always-vcs)
 	* Writing code
 		* [Be Ready To Throw Your Code Away](throw-away)
 		* [Future Thinking Is Future Trashing](future-trashing)

content/books/things-i-learnt/always-vcs/index.md

@@ -0,0 +1,33 @@
++++
+title = "Things I Learnt The Hard Way - Always Use A Version Control System"
+date = 2019-07-08
+
+[taxonomies]
+tags = ["en-au", "books", "things i learnt", "source control", "vcs", "git"]
++++
+
+"This is my stupid application that I just want to learn something" is not
+even a good excuse to not use a version control system.
+
+<!-- more -->
+
+A very long time ago, using a source control system (or Version Control
+System) required installing a server, configuring it properly, installing the
+client and _then_ you could keep track of the changes you were doing on your
+code.
+
+Today there are lots of options that can work in a standalone fashion: Just
+install the client and you're done (well, mostly done, you still need to
+initialize the environment, but that is mostly straightforward these days).
+
+And, again, there is no good reason to not start a project, as simple as it
+will be, without a version control.
+
+The VCS will allow you to explore new changes without breaking the main code.
+It will allow you to save a half-way change to make a complete different
+change.
+
+And, in the long, since you'll end up with working in team and will be
+required to use a VCS, you'll be used to using one.
+
+{{ chapters(prev_chapter_link="/books/things-i-learnt/languages-docs", prev_chapter_title="Good Languages Come With Integrated Documentation", next_chapter_link="/books/things-i-learnt/throw-away", next_chapter_title="Be Ready To Throw Your Code Away") }}

content/books/things-i-learnt/languages-docs/index.md

@@ -35,4 +35,4 @@ least, every library will pick its own format, every framework will pick its
 own format and they will never match the language format, and you'll end up
 with a mess of a documentation to decipher.
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/document-and", prev_chapter_title="If A Function Description Includes An And, It's Wrong", 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/document-and", prev_chapter_title="If A Function Description Includes An And, It's Wrong", next_chapter_link="/books/things-i-learnt/always-vcs", next_chapter_title="Always Use A Version Control System") }}

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/languages-docs", prev_chapter_title="Good Languages Come With Integrated Documentation", 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/always-vcs", prev_chapter_title="Always Use A Version Control System", next_chapter_link="/books/things-i-learnt/future-trashing", next_chapter_title="Future Thinking Is Future Trashing") }}