New chapter: cargo cult

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

@@ -34,3 +34,4 @@ template = "section-contentless.html"
 		* [If Your Data Has a Schema, Use a Structure](use-structures)
 * Community/Teams
 	* [A Language Is Much More Than A Language](languages-are-more)
+	* [Understand And Stay Away From Cargo Cult](cargo-cult)

content/books/things-i-learnt/cargo-cult/index.md

@@ -0,0 +1,41 @@
++++
+title = "Things I Learnt The Hard Way - Understand And Stay Away From Cargo Cult"
+date = 2019-06-25
+
+[taxonomies]
+tags = ["en-au", "books", "things i learnt", "cargo cult"]
++++
+
+"[Cargo cult](https://en.wikipedia.org/wiki/Cargo_cult)" is a type of cult
+which appeared in the Melanesia, in which the natives would build their copy
+of an airplane (no motor, 'cause they didn't have the knowledge to build one
+-- or even knew what went inside the airplane) in the hopes they would get the
+same results as a real airplane.
+
+<!-- more -->
+
+In I.T., a "cargo cult" is the expectation that if you use the same tools as
+some big players, you'd end up getting the same results.
+
+One example: Netflix runs a large fleet of microservices daily; they use
+Spring Cloud; if we use Spring Cloud, we can also run a large fleet of
+microservices.
+
+Although it may sound correct in a first glance, things are not like that.
+There is much more to the Netflix fleet than just Spring Cloud.
+
+Sometimes, cargo cult can appear in a form of "fanaticism" about celebrities:
+[Fowler](https://en.wikipedia.org/wiki/Martin_Fowler_(software_engineer)) said
+such and such pattern works this way and that's exactly what we should do.
+Just because Fowler is well know software engineer and architect and do have
+some very clever ideas, picking them and running exactly the way he described
+may do more harm than good -- basically, 'cause you'd end up applying a
+design pattern without worrying about solving your problem in the first place.
+
+Another example: "ProductX is sponsored by BigCompany, so it's good". It may
+be, but the fact that BigCompany is being ProductX doesn't immediately makes
+ProductX good, or even if it fits your solution. And there is much more
+[behind a product](/books/things-i-learnt/languages-are-more) than just its
+development.
+
+{{ chapters(prev_chapter_link="/books/things-i-learnt/languages-are-more", prev_chapter_title="A Language Is Much More Than A Language") }}

content/books/things-i-learnt/handle-it/index.md

@@ -27,4 +27,11 @@ occur, _deal with it_. If you have to save the save the content of the user
 somewhere else, log it to be reprocessed later or even just show an error
 message, do it.
 
+Although I seriously meant it, it doesn't mean you have to remember every
+single exception/error code and what it means when calling a function. You can
+write code that will actually go through the happy path and later fill the
+blanks. Or even, when you're working on another part of the code, if you
+remember another problem, just write on a post-it and add the handling later.
+The important bit is not to forget to handle it.
+
 {{ chapters(prev_chapter_link="/books/things-i-learnt/crash-it", prev_chapter_title="It's Better To Let The Application Crash Than Do Nothing", next_chapter_link="/books/things-i-learnt/data-types", next_chapter_title="Types Say What You Data Is") }}

content/books/things-i-learnt/languages-are-more/index.md

@@ -39,4 +39,4 @@ surface of what the whole of a language encapsulates and if you ignore the
 other elements in it, you may find yourself with a cute language in a
 community that is always fighting and never going forward.
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/use-structures", prev_chapter_title="If Your Data Has a Schema, Use a Structure") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/use-structures", prev_chapter_title="If Your Data Has a Schema, Use a Structure", next_chapter_link="/books/things-i-learnt/cargo-cult", next_chapter_title="Understand And Stay Away From Cargo Cult") }}