Why you should learn how to remove and not add
Tags: publicspeaking, career, coding, perfectionism
Published: 2019-11-12 11:11:10

---
title: Why you should learn how to remove and not add
published: true
cover_image: https://thepracticaldev.s3.amazonaws.com/i/mwspubq18p7sl9xxv15q.png
description: simplifying is difficult, how to know when to stop?
tags: #publicspeaking #career #coding #perfectionism
---

I am preparing lots of speeches for my [Public Speaking training at Toastmasters](https://dev.to/dvddpl/my-first-speech-at-toastmasters-pnn). What I still find very hard is figuring out how much to write to fill the allocated time for the speech.
When I have a topic in mind I try to jot down something, but as soon I try to rehearse it, I realize the draft is way too long.

Therefore I need to iterate many times **shaving off the unnecessary**, trying to be more concise and see if the speech fits the time I will have on stage.

### Removing the unnecessary - knowing what and how much to remove is extremely difficult. 

But it is an enormously important skill to master and it is not only true for public or communication in general but also in software development.

Whether you are writing a README or a JIRA ticket **you want to be clear but not verbose**.
Whether you are reviewing some code or discussing requirements/estimations with the stakeholders **you want to be honest but not blunt**.

But you might say: "that´s still _communication_ isn´t it?"
Yes, then think about all the other principle or best practices like:

- implementing a class or method (**single responsibility principle**)
- refactoring a monolith into microservices
- defining the size and scope of a React component
- granting roles, policies or permissions (**principle of least privilege**)
- and in general, the idea itself of **negative coding**! (which _does not mean writing code while grumpy and complaining and without any hope it will ever work_, but the outcome of some refactoring which brings the total line of code to be less)

When would you stop? when removing stuff might break your application or make it slower or make your code harder to read?

In regards to this topic, there is an interesting excerpt from a book by Bruno Munari.
Bruno Munari was an Italian artist, designer, and inventor from my own city ( Milan ) born in 1907 that I always found inspiring because of his fundamental contribution to many different fields:
from painting and sculpture to industrial and graphic design, from poetry to kinesthetic learning.


> To simplify you need to remove and to remove, one must know what to remove, like sculptors do when they hit through the rock with a chisel to remove all the excess material
Theoretically, every rock can have a beautiful sculpture inside it, how do you know where to stop to remove, without ruining the sculpture?

> By removing instead of adding means **recognizing the essence of things** and communicating them in their essentiality.

![Bruno Munari](https://thepracticaldev.s3.amazonaws.com/i/0hiwexcdasp2mzh87xb7.jpg)

This brings us to another quote that I love, from Antoine de Saint-Exupéry (yes, the author of _The little Prince_):

> Perfection is achieved, not when there is nothing more to add, but **when there is nothing left to take**


With this, I am not saying that we should get stuck in the mirage of perfectionism, still, we should always strive for simplicity. 

### Finding that balance is our main challenge. 


---
Photo by [Mike Kenneally](https://unsplash.com/@asthetik?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on Unsplash