I Wrote More than 90 Articles on 2021: Here is What I Learned
Tags: writing, tutorial, webdev, cleancode
Published: 2021-12-31 05:30:20

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

Below you will find many resources and tools, and my method and tips for writing a lot.

# My Background

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

- I use the scientific method and [Occam's razor](https://en.wikipedia.org/wiki/Occam%27s_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.

# My tools and secret sauces

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

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

- I use a different template in all my series. 

- For example, I have an empty [Code Smell template](https://dev.to/mcsee/series/9470).

- I write Everywhere 🗺️

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

- I parse the markdown in my articles and convert them to 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.

# Time management

- 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](https://dev.to/mcsee/16-simple-tips-to-boost-your-productivity-x10-1bf3) to focus when writing. 🍅

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

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

- I [Garden](https://maximilianocontieri.com/today-i-learned-the-concept-of-gardening) 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](https://dev.to/mcsee/coupling-the-one-and-only-software-design-problem-2pd7).

### 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](https://dev.to/mcsee/code-smell-20-premature-optimization-4moe) is the root of all evil. 😈

### [Helpers](https://dev.to/mcsee/code-smell-22-helpers-2j6j), [DTOs](https://dev.to/mcsee/code-smell-40-dtos-4426), [Singletons](https://dev.to/mcsee/code-smell-32-singletons-1ka), [Nulls](https://dev.to/mcsee/code-smell-12-null-la4), [Setters](https://dev.to/mcsee/code-smell-28-setters-2hih), [Metaprogramming](https://dev.to/mcsee/laziness-i-meta-programming-32a9), [Castings](https://dev.to/mcsee/code-smell-69-big-bang-javascript-ridiculous-castings-49ij), [Comments](https://dev.to/mcsee/code-smell-05-comment-abusers-2ba5) 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](https://dev.to/mcsee/refactoring-002-extract-method-1eee).  🛠️

- 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](https://dev.to/mcsee/coupling-the-one-and-only-software-design-problem-2pd7) 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](https://dev.to/mcsee/the-one-and-only-software-design-principle-3086) 🔀