Fixed most (if not all) links

things-i-learnt/src/personal/things-i-dont-know.md

@@ -8,5 +8,5 @@ everywhere or something grabs my attention, but I don't have the time to
 research it, I put it on this task list.
 
 When I start my research, I keep some notes together, although [not on
-paper](../organization/paper-notes.md), so I can use as reference in the
+paper](../programming/organization/paper-notes.md), so I can use as reference in the
 future.

things-i-learnt/src/programming/before/cognitive-cost.md

@@ -40,7 +40,7 @@ a number". And that's two different, disparate things that you suddenly have
 to keep in mind when reading that line.
 
 That's why [types are important](../coding/data-types.md).  Also, this may
-sound a bit like [the magical number seven](./magical-number-seven), 'cause
+sound a bit like [the magical number seven](./magical-number-seven.md), 'cause
 you have to keep two things at your mind at the same thing but, although
 that's not near seven, they are not the same, with opposite (for weird
 meanings of "opposite", in this case) meanings.

things-i-learnt/src/programming/before/debuggers.md

@@ -8,7 +8,7 @@ _bad_ you should never use them. Debuggers have their use, but every time I
 had to use one, it was because there was something missing.
 
 Most recently, using a framework in Java, I had problems with my code. I'd
-expect it [to crash](./crash-it) 'cause I didn't handle
+expect it [to crash](../coding/crash-it.md) 'cause I didn't handle
 things. What actually happened is that the framework silently hid the error
 and restarted the processing. To find out what was happening, I had to attach
 a debugger and see what was wrong with the data; otherwise, I'd have no idea
@@ -22,7 +22,7 @@ in fact, was _forced_ to use a debugger.
 Besides this, in the long run, you'd end up with problems in locations that
 you can't attach a debugger -- for example, your production environment. You
 _could_ but you _shouldn't_ do this. On the other hand, if you [log
-events](./log-events), then you can see what was going
+events](../running/log-events.md), then you can see what was going
 on, without a debugger.
 
 Again, I'm not taking the merits of debuggers, but in the long run, they are

things-i-learnt/src/programming/before/functional-programming.md

@@ -42,7 +42,7 @@ it will always return the same resulting record.
 Pure functions are useful 'cause they are, first most, easy to test.
 
 Second, they are easy to chain, specially in a [data
-flow](./data-flow) design: Because they don't have an
+flow](./data-flow.md) design: Because they don't have an
 internal state (which is the real reason they are called pure functions), you
 can easily call one after the other and no matter how many times you pass
 things around, they still produce the same result. And because each function,

things-i-learnt/src/programming/before/gherkin.md

@@ -33,7 +33,7 @@ Now, why I'm mentioning this?
 
 Sometimes, specs are not the most clear source of information about what it is
 expected from the system, and up can't think of [steps to do
-so](/books/things-i-learnt/steps-as-comments). If you're confused about what
+so](./steps-as-comments.md). If you're confused about what
 you should write, asking the person responsible for the request to write
 something like Gherkin may give you some better insights about it.
 

things-i-learnt/src/programming/before/patterns-not-solutions.md

@@ -6,7 +6,7 @@ the problem it self -- to fit the pattern.
 
 My guess is that the heavy use of "let's apply _this_ design pattern" before
 even understanding the problem -- or even trying to solve it -- comes as a
-form of [cargo cult](/books/things-i-learnt/cargo-cult): "We saw that people
+form of [cargo cult](../../teams/cargo-cult.md): "We saw that people
 used this pattern and solved their problem, so let's use it too and it will
 solve our problem". Or, worse: "Design pattern is described by _Famous
 Person_, so we must use it".

things-i-learnt/src/programming/before/spec-first.md

@@ -12,7 +12,7 @@ anything that _should_ be solved.
 
 So here is the point: Try to get a small spec on whatever you want to solve.
 But be aware that even that spec may have to be [thrown
-out](/books/things-i-learnt/throw-away), as the understanding of the problem
+out](../coding/throw-away.md), as the understanding of the problem
 tend to grow as long as the project continue.
 
 Yes, it's paradoxical: You need a spec to know what to code to avoid coding

things-i-learnt/src/programming/coding/use-utf8.md

@@ -13,7 +13,7 @@ positions, although not all accents where there).
 Today, accepting characters beyond that is not the exception, but the norm. To
 cope with all that, we have things like
 [Unicode](https://en.wikipedia.org/wiki/Unicode) and
-[uTF-8](https://en.wikipedia.org/wiki/UTF-8) for encoding that in reasonable
+[UTF-8](https://en.wikipedia.org/wiki/UTF-8) for encoding that in reasonable
 memory space (UTF-16 is also a good option here, but that would depend on your
 language).
 

things-i-learnt/src/programming/documentation/document-and.md

@@ -20,4 +20,4 @@ Ok, but you _had_ those two being called, what happens now? Well, where you
 called one, you now will need to call two. If your preferred language have
 support for function composition, you can use that to group both functions
 again. This is the kind of stuff that you'll get when you [learn to use
-functional programming](../programming/functional-programming.md).
+functional programming](../before/functional-programming.md).

things-i-learnt/src/programming/documentation/document-is-contract.md

@@ -1,7 +1,7 @@
 # The Function Documentation Is Its Contract
 
 When you start the code by [writing the general flow as
-steps](../programming/steps-as-comments.md) and making each step a
+steps](../before/steps-as-comments.md) and making each step a
 function, you're actually making a contract (probably with your future self):
 I'm saying this function does _this_ and _this_ is what it does.
 
@@ -9,7 +9,7 @@ I'm saying this function does _this_ and _this_ is what it does.
 
 Remember that the documentation must be a clear explanation of what your code
 _is_ doing and _why_ it exists; remember that good messages will make [reading
-the code only by the function documentation](./document-id.md) should be
+the code only by the function documentation](./document-it.md) should be
 clear.
 
 A function called `mult`, documented as "Get the value and multiply by 2" but,

things-i-learnt/src/programming/organization/libraries.md

@@ -23,7 +23,7 @@ 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](../programming/future-trashing.md). What you can do is actually
+trashing](../coding/future-trashing.md). What you can do is actually
 break your project by functionality, [making modules related to their
 data](./project-organization.md) and then, when you get a reasonable number of
 clients, you'll notice what can be reused in each, what modules make sense for

things-i-learnt/src/programming/running/config-file.md

@@ -12,7 +12,7 @@ testable application instead of two, or a very complex application that does a
 lot of stuff.
 
 We can even jump into the idea of [creating
-libraries](../programming/libraries.md) and say that, instead of
+libraries](../organization/libraries.md) and say that, instead of
 splitting your e-commerce application into smaller parts and making a big one
 by grouping these smaller parts, you could simply have one e-commerce
 application and, for each of your clients, you would have a different

things-i-learnt/src/programming/testing/integration-tests.md

@@ -44,9 +44,9 @@ could get a better picture of its functionality and the test actually _made
 sense_ -- as in, if you read the unit tests, they seemed disconnected from
 what the daemon was expected to do, but the integration tests actually read
 like "Here, let me show that we actually did what you asked". And yes, this
-was akin to [Gherkin](../programming/gherkin.md) tests, although I didn't
+was akin to [Gherkin](../before/gherkin.md) tests, although I didn't
 know Gherkin at the time -- and, better yet, we had tests that proved that we
-were following the [spec](../programming/spec-first.md).
+were following the [spec](../before/spec-first.md).
 
 Personally, I think over time integration tests become more important than
 unit tests. The reason is that I personally have the feeling[^2] that unit

things-i-learnt/src/programming/testing/tests-apis.md

@@ -34,5 +34,6 @@ can see how much one would suffer -- or, hopefully, enjoy -- using that.
 
 [^1]: Again, let's ignore for a second that there are no "unit" in "unit
   tests"...
+
 [^2]: And layers all the way down, [like
   turtles](https://en.wikipedia.org/wiki/Turtles_all_the_way_down).

things-i-learnt/src/programming/testing/tests-dead-code.md

@@ -16,7 +16,7 @@ _delete_ your code.
 
 But how do you know which pieces of code can be deleted?
 
-When I mentioned [integration tests](./integration-tests), I mentioned how
+When I mentioned [integration tests](./integration-tests.md), I mentioned how
 much more sense it made to me reading them instead of the "unit" tests,
 because they were describing exactly how the system would operate in normal
 (and some abnormal) conditions. If you write tests that go through the system,

things-i-learnt/src/teams/languages-are-more.md

@@ -37,6 +37,7 @@ And picking a language for something _above_ the syntax is even worse.
   leadership ignoring requests from the community and, sometimes, just
   ignoring all the hard work the community did to supply the missing bits
   because they didn't like it.
+
 [^2]: Again, I've seen this before: There was a language that didn't come with
   a build tool bundled. The community created a tool, which was widely
   adopted. Later, a new build tool appeared and, in one of the notes, the