Why Do I Write?


Why does this blog exist? Is it worth the carbon footprint to compile, host and serve this blog?

In my worldview, programming is much more about transmission of knowledge than remembering how to invert1 a binary tree. I think it is paramount for programmers of this day and age to be competent in:

  1. Communicating their ideas clearly and concisely.
  2. Using existing abstractions, or creating ones if the need arises2. Abstractions entail vocabulary.
  3. Writing documentation, decisions, and tradeoffs that are selected. Both for posterity’s sake and as a way to decant what was and was not important at that time.

I suck at these three. But that’s ok because I can work on improving 😊.

Communicating Ideas

I have a lot of experiences where I have an idea for which I can’t put words. I imagine blobs, arrows, and boxes of how things need to interact. But when I want to communicate them I usually ramble on, fail to draw what I have in my head, and by and large, those concepts are communicated imperfectly. Or not at all.

Communication is hard.

But I think that the ability to communicate is a skill that can be worked on. Improved upon. It needs time and practice. This blog is my training ground. I don’t expect most of the posts here to be life-changing. But I hope that at some point I will have a groundbreaking idea that I’ll want to share. If/when that time comes, I would like to be prepared. So I train, here.

Existing Abstractions

Writing also forces me to do some research, and expand my vocabulary (and therefore my pool of abstractions). Every new entry I explore existing material. See what others have written about it. And I’m often presented with like-minded individuals with far more experience in the subject matter, that have interesting choices of terminology.

I’ve had some ideas I wanted to explore but quickly found other resources that covered all that I wanted to explore, and then some. And even if I didn’t end up writing an entry, my knowledge did expand.

I would love to be that resource for someone else; that might be struggling to find the words for a problem, or get some guidance on a topic. Even if they disagree entirely on what I had to say, at least I can be a bad example.

“I’m not totally useless. I can be used as a bad example.” ― Victor Hugo, Les Misérables

For Posterity’s Sake

Finally and most purposeless for you, the reader, it is a way I can log my journey through life. I look forward to coming back to some old entry and think: “Oh, how naïve young Joaco was”. And if you are me, in the future, then remember: you left a pair of socks in the top left drawer in the kitchen 🧦.


  1. Why would anyone, in any domain, need to invert a tree‽‽ 

  2. More often than not, abstractions over “new” ideas already exist. It is just too hard to find them in the heat of the moment. We need some time to work on a particular problem that we start to see patterns and similarities the new abstractions have with existing ones. 

Melian

Random Posts

Limit the Problem Space!

Simply put, the “problem space” is the entire spectrum of inputs that exists in the process of finding a solution to a problem. How can we make our code less error-prone? In this post I explore some of the ways we can do so. Join me! #xpost

The essence of Event Sourcing

Event Sourcing is a somewhat trending topic, and you can find a lot of blog posts on what event sourcing supposedly is. I’ll throw my wrench in the works and try to explain what I see as “Event Sourcing”. #xpost

Dataloader, from the ground up

Ever heard of “dataloader”? From the simplest implementation to a batching and caching design pattern. Let’s dive into a brief tour of understanding this useful device.

#design

On costs, graphs and integrals

Yet another tool to pick a technology. How does the cost of the choice evolve over the complexity? Is there a one-solution-fits-all? In this blog post, we’ll delve into some visualization to understand the difference between choosing Java, Haskell, Hibernate, Ruby on Rails, or drop programming altogether for a no-code approach. Let’s dive into the world of optimizations, integrals, and many many graphs! #rambling #coding