I Wrote More than 200 Articles Last Year. Here is What I Learned

I have a degree in computer science. 👨🏽‍🔬

I use the scientific method and Occam's razor.

I have researched for 30 years both in the academic and industrial fields.

I don't have the absolute truth.

I try to support my opinions with evidence. 🔍

They are my opinions and are very subject to change.

I Have a (very) long list of draft articles.

I often skip the waiting queue and write about some inspirational source (and quote it).

I use a different template in all my series.

For example, I have an empty Code Smell template.

I write Everywhere 🗺️

I proofread all my articles with HemingwayApp, Grammarly, and Google Translate (all free) 🔡

I parse the markdown of my articles and convert it into HTML to republish on many platforms at once.

I heavily use the canonical URL tag to avoid search penalties. 🔎

I Follow very interesting people on Twitter and blogging platforms. ✨

I take a new course every week, usually on a subject that is far away from my comfort zone.

I add many references and quotes to my articles.

I read a lot of articles early in the morning and bookmark them during the day. 🌅

I use Trello, Inoreader, Pocket, and Obsidian.

I Use The Pomodoro technique to focus when writing. 🍅

I avoid perfection. I publish them when they are ready.

Then I make corrections following other people's comments. Even after months.

I Garden my articles.

I have different opinions than many other developers.

Software Design is a creative activity.

My articles are suggestions and not rigid rules.

I try to have intelligent and polite discussions.

I have zero tolerance for hate speech and unprofessional comments.

I never feed the troll.

I don't have the same opinion as many people.

If you think [NULLs|Undefined|Singletons|…|Whatever] are awesome, I have a different point of view.

If you need to see long methods/scripts to understand your solution, that's fine.

I prefer to have small/reusable/testable functions.

IMHO, a 6 lines method is too long

You can always break them using refactorings. 🛠️

You don't need to see the big picture and the details at the same time. 🌳

Trust your implementation and write good tests.

I try to add code samples for clarity.

Most of the code snippets work.

Some of them are pseudo-code for educational purposes. 👨‍🏫

I have used 25+ different languages in my articles.

Whenever possible, I test the code in a repl.it

I am not an expert in NONE of these languages.

Languages are accidental, and Software design is essential.

Most of the articles are language-independent.

The solution tries to avoid language perks and cleverness.

I write about backend business software. 🖥️

This is the domain I've been working on.

I know that some tasks require more performant solutions (for example DApps).

I will always choose long descriptive names over smart performance optimizations.

First, make the code right. ✔️

Then, optimize it only if you have strong evidence.

Complexity is not enough evidence.

You need a genuine benchmark in real use case scenarios. 📈

If I need to sort 20 elements in a collection, I will always choose bubble sort because it is easier to read.

Premature optimization is the root of all evil. 😈

I write a lot on these anti-patterns with the reasons why I think we should avoid them.

You can keep thinking they are good and that's fine.

My arguments against them are in all articles.

I reply polite comments about them.

Coupling is our worst enemy. 🙅

We need to avoid direct relationships.