paint-brush
I Wrote More than 90 Articles in 2021 and Here is What I Learned in a Nutshell by@mcsee
940 reads
940 reads

I Wrote More than 90 Articles in 2021 and Here is What I Learned in a Nutshell

by Maximiliano ContieriJanuary 1st, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

In this article, you will find lots of resources and tools and my method and tips for heavy writing.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - I Wrote More than 90 Articles in 2021 and Here is What I Learned in a Nutshell
Maximiliano Contieri HackerNoon profile picture

This article summarizes my experience as a writer during the pandemic year 2021.

Below you will find lots of resources and tools and my method and tips for heavy writing.

My Background

  • 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.

11 tools and secret sauces

  1. I Have a (very) long list of draft articles.
  2. I often skip the waiting queue and write about some inspirational source (and cite it).
  3. I use a different template in all my series.
  4. For example, I have an empty Code Smell template.
  5. I write Everywhere 🗺️
  6. I proofread all my articles with HemingwayApp, Grammarly, and Google Translate (all free) 🔡
  7. I parse the markdown in my articles and convert them to HTML to republish on many platforms at once.
  8. I heavily use the canonical URL tag to avoid search penalties. 🔎
  9. I Follow very interesting people on Twitter and blogging platforms. ✨
  10. I take a new course every week, usually on a subject that is far away from my comfort zone.
  11. I add many references and quotes to my articles.

6 Tips for Time Management

  1. I read a lot of articles early in the morning and bookmark them during the day. 🌅
  2. I use Trello, Inoreader, Pocket, and Obsidian.
  3. I Use The Pomodoro technique to focus when writing. 🍅
  4. I avoid perfection. I publish them when they are ready.
  5. Then I make corrections with other people's comments. Even after months.
  6. I Garden my articles.

Dealing with Criticism

  • 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 smart discussions.
  • I have zero tolerance for hate speech and unprofessional comments.
  • I never feed the troll.

Common Criticism

I get the same comments over and over again, so these are the common critics I get and my opinions.

Readability

I need to see the complete code in a sheet.

If you need to see long methods/scripts to understand your solution, that's fine. I prefer to have small/reusable/testable functions.

The code in your articles is not Compiling/Working/has errors

  • 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.
  • I am not an expert in ANY of these languages.
  • Languages are accidental, Software design is essential.

I Have a trick in INSERT LANGUAGE to improve the code.

Most of the articles are language-independent. The solutions try to avoid language perks and cleverness.

Your solution is not performant/optimal

  • I write about backend business software. 🖥️
  • This is the domain I've been working on.
  • I am aware 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 real 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. 😈

Helpers, DTOs, Singletons, Nulls, Setters, Metaprogramming, Castings, Comments are standard. 🙈

  • 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.

A 15 lines long method is not 'long'

  • 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.

Your solutions have too many indirections

  • Coupling is our worst enemy. 🙅
  • We need to avoid direct relationships.

You have too many rules and constraints

There is just one rule: Always follow the bijection 🔀