Two years and 10 months ago, on March 16, 2016, I published the first post from this account on HackerNoon. Since then, I've started publishing every two weeks at 8 pm Australian Eastern Daylight Time. That is the way I found to unleash my Panic Monster and avoid procrastination.

In the past year, there were 5 publications worth remembering. Here's each one of them with their respective summary:

50 years ago, software started to move away from the hands of business people. Today, some programmers seem to have forgotten the real purpose of software, that is to solve a real-world problem.

This post shows how not every code is worth writing, not every bug is worth fixing, not every command is worth scripting, and not every feature is worth coding.

It also introduces the idea of The Priority Matrix, a bi-dimensional model that you can use to prioritize bugs based on how many users it affects and the severity.

It’s ok to take a loan, as long as the benefits outweigh the costs of the interest accrued. With Technical Debt, you can take the loan and at the same time reduce the cost of future payments.

As programmers, we understand Technical Debt to be something ugly, awful, that you should remove at all costs. However, that's not always the case.

This post shows how Technical Debt is a great tool that you can use to accommodate requirements without the need for speculation. The idea is that you refactor before the next feature, not after.

Refactor for the past you know, not the future you don't.

In this post, you’ll learn, as a developer, how to code software using the principles of Incremental Delivery.

This series starts on a post which tries to bring back the lost fundamentals of Continuous Integration. Later on, it tells my experience on a 6 months project that became a Vaporware. The company had to cancel the project because I was working solo and didn't apply the principles of Continuous Integration and Incremental Delivery.

This post goes beyond the buzzwords of Incremental Delivery and Continuous Integration.

It will change the way you look at them.

There was a bug very hard to reproduce on the website of a big financial company. The bug was de-prioritized by the developers until one day the CEO started asking why.

For the CEO of a big financial company to contact a team of developers about a bug, it has to be a big deal. However, in this case, it didn't seem that big. Due to how the CEO traveled around, he managed to spot an edge case that allowed him to deposit money twice in his account.

This story was controversial. Some people said the bug was the symptom of a huge architectural flaw; others pointed out the story was describing a dysfunctional team culture.

If the problem you solve is more important than the code you write, would you invest the time to solve this bug? I'll leave it to you as a thought experiment.

Years ago I was in a small project when a colleague showed me a way to write HTML faster. However, in programming, certain kinds of speed don’t represent more productivity.

As programmers, we love to learn and write tools that can help us run many commands faster. However, most of the time it’s worth optimizing for quicker ways to achieve outcomes instead of brute-forcing with tools.

You might be wasting your time, only that you don't know it yet.