Writing is like engineering my thoughts.

Every idea that comes from a sharp mind can be expanded into a full essay. If you simply start with a single, short sentence and then elaborate the thoughts within and beyond it, like engineering them, the essay will be there in front of your eyes.

At first, it will feel as if the sentence is crystal clear. Nothing to add. Well, give it another chance, and if you still have the same feeling then just stare at it a bit longer. Criticize it. What’s right with it, and what’s wrong?

This is why writing and programming feel close to each other. It’s not just because they both require typing on the keyboard (or writing on a paper). It is because of the mindset the writer must be in.

Each sentence that you write requires a second thought. You have to imagine and evaluate the alternative ways to express the same concept. Changing and crafting the language and each word within it, multiple times, over and over. Perfection doesn’t exist, and writers are notoriously never happy with their writings, but, hey, you can always get one inch closer.

More often than not, it seems to me as if I don’t have anything to write about. Again, it’s the familiar feeling that some ideas are too simple and straightforward and therefore there is no reason to write about it, and they definitely could not be expanded into an entire piece.

The solution? Ask questions.

On asking questions to your own essay

If you find me writing in my office or in a café, you may see me mumbling words quite often, but I am not speaking to myself. I am asking questions to my essay.

Every typed sentence contains a load of ideas. Usually though, because thoughts travel at very high speed, almost all such ideas are missed by the reader as well as by the writer. The question, then, is how to bring them up from the depth of the brain they are buried in?

My solution to fight this common situation is to ask questions to my own essay. Yeah, I know, that’s like asking questions to my monitor. It’s fairly simple, effective, and here’s how it works.

I stare at a sentence for a bit. I read it over and over, more times than you’d think possible. Then I start asking questions. Is it correct? Does it miss anything? Does it explain the concept in its entirety, or neglects some variations or possibilities?

And, the most important of all: If I were to read this sentence again in five year, what would I think? What about ten years?

The first few times I made this exercise it felt very silly. I looked at a piece of text, and there’s really nothing beyond it, it’s just a sentence. It says it all!

Man, if I was wrong! Every sentence contains a bunch of ideas. Every single one.

With time, I’ve learned a few tricks to generate such ideas. One option is to look at the sentence, or paragraph, and start from the assumption that it’s wrong. Just assume somebody with a striking different opinion is reading it.

In fact, this is a common approach used to evaluate product ideas. When I hear products or engineering ideas from a colleague, I often take the approach based on the counter ideas that “This ought to be useless!”

I must say, it more often than not leads to interesting fights. On the other hand, it more often than not helps crafting and redefining that idea, overall making it better.

Another option, one that I often use in my writings, is to search for subtleties that the sentence is missing, in the way it’s written. This approach is similar to what I do with my brain when I look at a software implementation and try to find weak spots, inefficiencies or edge cases that are not well handled.

I realize that my explanation isn’t easily actionable, and probably isn’t very clear either. It isn’t because the process itself is not mathematical. When I write there are so many thoughts intersecting each other, often colliding, that it just isn’t possible to keep everything under control. And when I try to explore them (my thoughts) beyond what I put on the page, it’s easy to get lost. But what a lovely way to get lost.

For sure, the price of this work is measured in the units of time. It takes days, weeks even. I believe that an essay usually stays in my notebook for a month before I put it on my website. However, I do write multiple pieces at the same time. After all, writing is not my main activity and I find it entertaining to have several concepts growing up in multiple articles at the same time.

That’s the word I was looking for: grow up. That’s what happens to a piece of text when you question it, and then look at it from every possible perspective. It matures and grows up.

On the one hand, this process creates even more collisions between thoughts: they don’t just fight each with the others in the same essay, but even with the ones in different essays! On the other hand, it’s a lot of fun, very rewarding, and overall I claim that it makes me a better “thinker”.

As for the long time it takes to get even just one of them out of the notebook, I simply don’t mind. In fact, I enjoy the process for as long as it takes. Oftentimes I even ask a friend to review it before I put it on my blog. I am convinced that it’s the writer’s responsibility to carefully examine their own essays before putting them out there, if they genuinely care about quality above quantity.

On why programming feels like writings

There is something in the action of writing down one’s own thoughts that feels like magic.

It is like the act of creation. Thoughts become characters, every one with its own personality. Every paragraph on the page is an expression of who they are and what they think, which in turn is a subconscious (or, at times, fully conscious) expression of the writer’s mind.

What has all of that to do with programming?

I have so far purposefully given examples of things that code writers and general writers have in common. They both need to spend time seriously thinking about each sentence, paragraph or block of code. They both need to generate ideas that are hidden behind the words, and evaluate them. They both need to craft and improve the lines they type many times, to get closer to perfection at every iteration.

There are no characters in a software code (though, I would argue, some types have their own personality!). Nonetheless, the same mindset applies. Each piece of code is an expression of the style, knowledge, understanding and vision of the coder. It’s the same, awesome feeling of “writing”.

There’s one more thing they have in common, and it’s the most important of all. They both need to enjoy this iterative process, in every aspect of it.

Writers, and even more so coders, get often caught in what I call the hamster-writer loop. In short, sometimes writing feels like a repetitive act. It definitely happens to coders, as often blocks of code follow the same thinking pattern, and even if the actual typed characters are different, the text just feels the same. But it also happens to story-writers, especially those who generate a lot of text. Sometimes it feels as if I have already written enough about an idea, and I am just repeating myself in a new essay, for the sake of… what?

Instead, writing and coding are such creative efforts! But creativity must be cultivated, and the best way to cultivate it and make it grow is to keep the mind sharp by asking questions.

In less words: you must challenge your own thoughts when you write.

The hamster-writer loop keeps the brain engaged in a semi-automatic action: writing about things that are already crystal clear in the brain. It can be a C function, or it can be the explanation of why you like music. Either way, it’s something that you already know very well, almost by heart, and writing it doesn’t require effort: words flow automatically from your brain to the paper, through your fingers. Maybe you’ve written thousands of similar C functions, and dozens of articles on your favorite music.

As cool as it sounds, this loop puts the brain in an automatic pilot that makes it lethargic eventually. And that is when creativity goes to sleep.

There’s one hint that you can perceive as alarming because it means you might be in the hamster-writer loop: it’s that feeling of doing something effortless. I know it feels nice, but the reality is that we must suffer a bit to improve ourselves. Just doing the same thing over and over doesn’t take you anywhere. For sure, repeating is important, but it must be paired with progressively increasing difficulty, or it won’t take you very far. The hamster-writer loop keeps the writer stuck in the same place, writing “the same” stuff. No challenge, no improvement. No pain, no gain.

You need to keep yourself engaged with your writing, by questioning everything you “say”. Think of writing like saying something to hundreds of thousands of readers: before they get back to you with questions, you should try to anticipate as many of these questions as possible, think through them seriously, and come up with good answers.

Of course, peer review is the best way to do it, but it often isn’t available. Funny story: when I am lucky enough to have peer review available (usually for a piece of code), either as a reviewer or as reviewed, I ask a lot of questions. I believe that often the others involved in the review think I am annoying, but all I am doing is really just trying to uncover as many ideas as possible, evaluate them, and make the final text better. In fact, I ask questions even to my own review requests!

My point here is that it doesn’t matter how brilliant and skilled you are. There’s only one way to get better and that’s through brainstorming, analysis and suffering (a bit). Brainstorming can’t be done alone, you need to receive feedback from others on your ideas.

This is true for storytellers, and it’s very true for software coders. Forget the “best and only way to do it”, as there’s no such a thing. Whatever you are trying to accomplish in a block of code, there are a dozen ways to do it and all of them may or may not be correct. What’s worse, evaluating them is extremely difficult because software is always changing.

Software is not like a bridge that you build and it stays the same for thirty years. It needs constant maintenance. Therefore, whether a block of code is optimally written or not is something that depends on the future! This is why I spoke about vision earlier. The better your vision about where the thing is going, the more chances that your approach is correct. But it’s very unlikely that it will be perfect.

When you exchange ideas with others about your writings, and constantly review it, the concepts in it grow for the better. It takes some care to avoid going totally off-road, but the final result is much better. This is a great example of a group of brains being better than just one, no matter the individual abilities.

In my experience, this is the point when a big clash happens between these ideal scenarios and the more terrain needs, in particular the need for monetization.

Business, in other words, doesn’t like to spend time thinking exceedingly over a problem, with the pure intention to craft a better solution. In business’ eyes, that is not time spent; it’s time lost.

I have fought this battle several times, with many different businesses, and it’s a battle with no winner. It’s a battle of concepts, where the concepts involved can’t just get along very well. On one side, the need for intellectually satisfying activities. On the other, the need to monetize assets (or, as I provocatively say, to sell stuff).

And even though it looks like in this world business and money have the louder voice, I am an optimistic person and am certain that out there is full of people who can see the beauty of doing things well and the joy of thinking deep, no matter if it takes a bit longer.

That’s ultimately why I have been slowly moving toward nonprofit (at the point of starting one). I look at them and I see a fuzzy mix of business and intellectual needs that, despite the confusion, gives me hope. In my nonprofit, quality matters more than quantity, and quantity matters more than money. With this order of things firm in mind it’s easy and it makes a lot of sense to spend one more week over-thinking a piece of text or a block of code, and having fun with the process, because what we are most interested in is sharing knowledge of outstanding quality (a rare thing, nowadays), learning and improving ourselves while at it.

Not that it’s the only thing that matters. The materialistic business view that pushes hard to get stuff out of the door, often settling for lower quality, has good points too. Sometimes you just need to get things done, period. Philosophers and over-thinkers have the tendency to procrastinate things, and in doing so they don’t make any good to their own ideas. Ideas must go outside in the real world, because they need to be confronted with other people’s ideas.

If it sounds like I am struggling to come up with a firm opinion on this matter, it’s because I don’t have one. I recognize the need for monetization, as well as the fact that deadlines help to move forward and to make progress. The “engineer inside me” understands that, and he always strives to push products out of the door.

At the same time though, quality matters a lot to me. And chasing perfection is the only way to improve. The same engineer inside me loves the feeling of chasing perfection, even if he knows that touching her isn’t possible. But it doesn’t really matter, because chasing perfection is the purest way to keep things moving, more pure than monetization.

One thing is certain: the hamster-writer loop doesn’t affect those who go after perfection. But be sure to not get lost during the chase!

Back to posts