Merge pull request #264 from eugenioamn/master

Update pt-BR translation

translations/pt-BR.md

@@ -1,11 +1,10 @@
 # 💻📖 hacker-laws
 
-Leis, Teorias, Principios e Padrões que desenvolvedores acham úteis.
+Leis, teorias, princípios e padrões que desenvolvedores acharão úteis.
 
-- 🇨🇳 [中文 / Versão Chinesa ](https://github.com/nusr/hacker-laws-zh) - Obrigado [Steve Xu](https://github.com/nusr)!
+[Traduções](#traduções): 🇧🇷 [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./de.md) [🇫🇷](./fr.md) [🇬🇷](./el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr)
-- 🇰🇷 [한국어 / Versão Koreana](https://github.com/codeanddonuts/hacker-laws-kr) - Obrigado [Doughnut](https://github.com/codeanddonuts)!
+
-- 🇷🇺 [Русская версия / Versão Russa](https://github.com/solarrust/hacker-laws) - Obrigado [Alena Batitskaya](https://github.com/solarrust)!
+Gostou deste projeto? Por favor, considere [me apoiar](https://github.com/sponsors/dwmkerr) e [apoiar os tradutores](#traduções).
-- 🇹🇷 [Türkçe / Versão Turka](https://github.com/umutphp/hacker-laws-tr) - Obrigado [Umut Işık](https://github.com/umutphp)
 
 ---
 
@@ -13,54 +12,86 @@ Leis, Teorias, Principios e Padrões que desenvolvedores acham úteis.
 
 * [Introdução](#introdução)
 * [Leis](#leis)
-    * [Lei De Amdahl](#lei-de-amdahl)
+	* [Princípio 90-9-1 (Regra do 1%)](#princípio-90-9-1-regra-do-1)
+    * [Lei de Amdahl](#lei-de-amdahl)
+    * [Teoria das Janelas Quebradas](#teoria-das-janelas-quebradas)
     * [Lei de Brook](#lei-de-brook)
     * [Lei de Conway](#lei-de-conway)
+    * [Lei de Cunningham](#lei-de-cunningham)
     * [Número de Dunbar](#número-de-dunbar)
+    * [Lei de Gall](#lei-de-gall)
+    * [Lei de Goodhart](#lei-de-goodhart)
     * [Navalha de Hanlon](#navalha-de-hanlon)
     * [Lei de Hofstadter](#lei-de-hofstadter)
+    * [Lei de Hutber](#lei-de-hutber)
     * [O Ciclo Hype e Lei de Amara](#o-ciclo-hype-e-lei-de-amara)
-    * [Lei de Hyrum (A lei de interfaces implicitas)](#lei-de-hyrum-a-lei-de-interfaces-implicitas)
+    * [Lei de Hyrum (Lei das Interfaces Implícitas)](#lei-de-hyrum-lei-das-interfaces-implícitas)
+    * [Lei de Kernighan](#lei-de-kernighan)
+    * [Lei de Metcalfe](#lei-de-metcalfe)
     * [Lei de Moore](#lei-de-moore)
+    * [Lei de Murphy / Lei de Sod](#lei-de-murphy--lei-de-sod)
+    * [Navalha de Occam](#navalha-de-occam)
     * [Lei de Parkinson](#lei-de-parkinson)
+    * [Efeito de Otimização Prematura](#efeito-de-otimização-prematura)
     * [Lei de Putt](#lei-de-putt)
-    * [A lei da Conservação de Complexidade (Lei de Tesler)](#a-lei-da-conservação-de-complexidade-lei-de-tesler)
+    * [Lei de Reed](#lei-de-reed)
-    * [A lei das Abstrações gotejantes](#a-lei-das-abstrações-gotejantes)
+    * [A Lei da Conservação da Complexidade (Lei de Tesler)](#a-lei-da-conservação-da-complexidade-lei-de-tesler)
-    * [The Law of Triviality](#the-law-of-triviality)
+    * [A Lei das Abstrações Gotejantes](#a-lei-das-abstrações-gotejantes)
-    * [The Unix Philosophy](#the-unix-philosophy)
+    * [A Lei da Trivialidade](#a-lei-da-trivialidade)
-    * [The Spotify Model](#the-spotify-model)
+    * [A Filosofia Unix](#a-filosofia-unix)
-    * [Wadler's Law](#wadlers-law)
+    * [O Modelo Spotify](#o-modelo-spotify)
-* [Principles](#principles)
+    * [Lei de Wadler](#lei-de-wadler)
-    * [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
+    * [Lei de Wheaton](#lei-de-wheaton)
-    * [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law)
+* [Princípios](#princípios)
+	* [O Princípio Dilbert](#o-princípio-dilbert)
+    * [O Princípio de Pareto (Regra do 80/20)](#o-princípio-de-pareto-regra-do-8020)
+    * [O Princípio de Peter](#o-princípio-de-peter)
+    * [O Princípio da Robustez (Lei de Postel)](#o-princípio-da-robustez-lei-de-postel)
     * [SOLID](#solid)
-    * [The Single Responsibility Principle](#the-single-responsibility-principle)
+    * [O Princípio da Responsabilidade Única](#o-princípio-da-responsabilidade-única)
-    * [The Open/Closed Principle](#the-openclosed-principle)
+    * [O Princípio do Aberto/Fechado](#o-princípio-do-abertofechado)
-    * [The Liskov Substitution Principle](#the-liskov-substitution-principle)
+    * [O Princípio da Substituição de Liskov](#o-princípio-da-substituição-de-liskov)
-    * [The Interface Segregation Principle](#the-interface-segregation-principle)
+    * [O Princípio da Segregação de Interface](#o-princípio-da-segregação-de-interface)
-    * [The Dependency Inversion Principle](#the-dependency-inversion-principle)
+    * [O Princípio da Inversão de Dependência](#o-princípio-da-inversão-de-dependência)
-    * [The DRY Principle](#the-dry-principle)
+    * [O Princípio DRY](#o-princípio-dry)
+    * [O Princípio KISS](#o-princípio-kiss)
     * [YAGNI](#yagni)
-* [Lista de Livros](#lista-de-livros)
+    * [As Falácias da Computação Distribuída](#as-falácias-da-computação-distribuída)
-* [Em Progresso](#em-progresso)
+* [Lista de leitura](#lista-de-leitura)
+* [Traduções](#traduções)
+* [Projetos relacionados](#projetos-relacionados)
+* [Contribuindo](#contribuindo)
+* [Em construção](#em-construção)
 
 <!-- vim-markdown-toc -->
 
 ## Introdução
 
-Existem muitas leis que as pessoas discutem quando falam sobre desenvolvimento. Esse repositório é uma referencia e uma visão global dos mais comuns. Sinta-se a vontade para contribuir e compartilhar.
+Existem muitas leis sobre as quais as pessoas discutem quando falam sobre desenvolvimento. Este repositório é uma referência e uma visão global das mais comuns. Sinta-se a vontade para contribuir e compartilhar.
 
-<!--There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs! <!-->
+❗: Este repositório contém explicações sobre algumas leis, princípios e padrões, mas não _advoga_ nenhum. Se eles devem ser aplicados é uma questão de discussão, e depende diretamente no que você está trabalhando.
-
-❗: Esse repositório contém explicações sobre algumas léis, pincípios e padrões, mas não _advoca_ para nenhum. Se eles devem ser aplicados sempre é uma questão de debate, e depende diretamente no que você está trabalhando.
 
 ## Leis
 
-Lá vamos nós!!
+E lá vamos nos!
 
-### Lei De Amdahl
+### Princípio 90-9-1 (Regra do 1%)
 
-[Lei de Amdahl na Wikipedia](https://pt.wikipedia.org/wiki/Lei_de_Amdahl)
+[1% Rule on Wikipedia](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture))
+
+The 90-9-1 principle suggests that within an internet community such as a wiki, 90% of participants only consume content, 9% edit or modify content and 1% of participants add content.
+
+Real-world examples:
+
+- A 2014 study of four digital health social networks found the top 1% created 73% of posts, the next 9% accounted for an average of ~25% and the remaining 90% accounted for an average of 2% ([Reference](https://www.jmir.org/2014/2/e33/))
+
+See Also:
+
+- [Pareto principle](#the-pareto-principle-the-8020-rule)
+
+### Lei de Amdahl
+
+[Lei de Amdahl na Wikipédia](https://pt.wikipedia.org/wiki/Lei_de_Amdahl)
 
 > A lei de Amdahl, também conhecida como argumento de Amdahl, é usada para encontrar a máxima melhora esperada para um sistema em geral quando apenas uma única parte do mesmo é melhorada. Isto é frequentemente usado em computação paralela para prever o máximo speedup teórico usando múltiplos processadores. A lei possui o nome do Arquiteto computacional Gene Amdahl, e foi apresentada a AFIPS na Conferência Conjunta de Informática na primavera de 1967. 
 
@@ -74,6 +105,24 @@ O diagrama abaixo mostra alguns exemplos de melhoria na velocidade:
 
 Como pode-se perceber, mesmo um programa que teve metade da sua implementação de forma paralela, o benefício é menos de 10 _processing units_. Porém, um programa 95% paralelo, o ganho pode passar de 20 _processing units_.
 
+### Teoria das Janelas Quebradas
+
+[The Broken Windows Theory on Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory)
+
+The Broken Windows Theory suggests that visible signs of crime (or lack of care of an environment) lead to further and more serious crimes (or further deterioration of the environment).
+
+This theory has been applied to software development, suggesting that poor quality code (or [Technical Debt](#TODO)) can lead to a perception that efforts to improve quality may be ignored or undervalued, thus leading to further poor quality code. This effect cascades leading to a great decrease in quality over time.
+
+See also:
+
+- [Technical Debt](#TODO)
+
+Examples:
+
+- [The Pragmatic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-broken-window-theory/)
+- [OpenSource: Joy of Programming - The Broken Window Theory](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)
+
 ### Lei de Brook
 
 [Lei de Brooks na Wikipeia](https://en.wikipedia.org/wiki/Brooks%27s_law)
@@ -103,6 +152,18 @@ Veja também:
 
 - [Modelo do Spotify](#modelo-spotify)
 
+### Lei de Cunnigham
+
+[Cunningham's Law on Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)
+
+> The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.
+
+According to Steven McGeady, Ward Cunningham advised him in the early 1980s: "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." McGeady dubbed this Cunningham's law, though Cunningham denies ownership calling it a "misquote." Although originally referring to interactions on Usenet, the law has been used to describe how other online communities work (e.g., Wikipedia, Reddit, Twitter, Facebook).
+
+See also:
+
+- [XKCD 386: "Duty Calls"](https://xkcd.com/386/)
+
 ### Número de Dunbar
 
 [Número de Dunbar na Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number)
@@ -117,6 +178,46 @@ Veja também:
 
 - [Lei de Conwy](#lei-de-conway)
 
+### Lei de Gall
+
+[Gall's Law on Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
+
+> A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
+>
+> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
+
+Gall's Law implies that attempts to _design_ highly complex systems are likely to fail. Highly complex systems are rarely built in one go, but evolve instead from more simple systems.
+
+The classic example is the world-wide-web. In its current state, it is a highly complex system. However, it was defined initially as a simple way to share content between academic institutions. It was very successful in meeting these goals and evolved to become more complex over time.
+
+See also:
+
+- [KISS (Keep It Simple, Stupid)](#the-kiss-principle)
+
+### Lei de Goodhart
+
+[The Goodhart's Law on Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law)
+
+> Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
+>
+> _Charles Goodhart_
+
+Also commonly referenced as:
+
+> When a measure becomes a target, it ceases to be a good measure.
+>
+> _Marilyn Strathern_
+
+The law states that the measure-driven optimizations could lead to devaluation of the measurement outcome itself. Overly selective set of measures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) blindly applied to a process results in distorted effect. People tend to optimize locally by "gaming" the system in order to satisfy particular metrics instead of paying attention to holistic outcome of their actions.
+
+Real-world examples:
+- Assert-free tests satisfy the code coverage expectation, despite the fact that the metric intent was to create well-tested software.
+- Developer performance score indicated by the number of lines committed leads to unjustifiably bloated codebase.
+
+See also:
+- [Goodhart’s Law: How Measuring The Wrong Things Drive Immoral Behaviour](https://coffeeandjunk.com/goodharts-campbells-law/)
+- [Dilbert on bug-free software](https://dilbert.com/strip/1995-11-13)
+
 ### Navalha de Hanlon
 
 [Navalha de Hanlon na wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor)
@@ -127,8 +228,6 @@ Veja também:
 
 Esse principio sugeste que ações negativas não são sempre resultado de má vontade. Em vez disso, é mais provável que o resultado negativo seja atribuido à ações que não foram totalmente entendidas.
 
-
-
 ### Lei de Hofstadter
 
 [Lei de Hofstadter na Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law)
@@ -142,6 +241,17 @@ Você já deve ter ouvido sobre essa lei quando se fala em estimar tempo para fa
 
 This is from the book '[Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de-livros)'.
 
+### Lei de Hutber
+
+[Hutber's Law on Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> Improvement means deterioration.
+>
+> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
+
+This law suggests that improvements to a system will lead to deterioration in other parts, or it will hide other deterioration, leading overall to a degradation from the current state of the system.
+
+For example, a decrease in response latency for a particular end-point could cause increased throughput and capacity issues further along in a request flow, affecting an entirely different sub-system.
 
 ### O Ciclo Hype e Lei de Amara
 
@@ -160,7 +270,7 @@ O Ciclo Hype é uma representação visual da empolgação e desenvolvimento da
 Em curto prazo, o ciclo sugere que acontece uma explosão de empolgação a cerca de uma nova tecnologia e seu impacto em potencial. Equipes geralmente entram juntas nessas tecnlogias de forma rápida e em alguns casos ficam desapontados com os resutados. Uma das possíveis causas para isso é o fato da tecnologia em questão não ser madura o suficiente, ou aplicações do mundo real que não estão totalmente prontas. Depois de um certo tempo, a capacidade da tecnologia aumenta e oportunidades práticas para uso dela aumentam, as equipes finalmente podem ser produtivas. A citação de Amara resume isso de forma sucinta - "Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo".
 
 
-### Lei de Hyrum (A lei de interfaces implicitas)
+### Lei de Hyrum (Lei das Interfaces Implícitas)
 
 [Lei de Hyrum site](http://www.hyrumslaw.com/)
 
@@ -178,6 +288,36 @@ Veja Também:
 
 - [XKCD 1172](https://xkcd.com/1172/)
 
+### Lei de Kernighan
+
+> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
+>
+> (Brian Kernighan)
+
+Kernighan's Law is named for [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) and derived from a quote from Kernighan and Plauger's book [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style):
+
+> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
+
+While hyperbolic, Kernighan's Law makes the argument that simple code is to be preferred over complex code, because debugging any issues that arise in complex code may be costly or even infeasible.
+
+See also:
+
+- [The KISS Principle](#the-kiss-principle)
+- [The Unix Philosophy](#the-unix-philosophy)
+- [Occam's Razor](#occams-razor)
+
+### Lei de Metcalfe
+
+[Metcalfe's Law on Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law)
+
+> In network theory, the value of a system grows as approximately the square of the number of users of the system.
+
+This law is based on the number of possible pairwise connections within a system and is closely related to [Reed's Law](#reeds-law). Odlyzko and others have argued that both Reed's Law and Metcalfe's Law overstate the value of the system by not accounting for the limits of human cognition on network effects; see [Dunbar's Number](#dunbars-number).
+
+See also:
+- [Reed's Law](#reeds-law)
+- [Dunbar's Number](#dunbars-number)
+
 ### Lei de Moore
 
 [Lei de Moore na wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law)
@@ -191,6 +331,44 @@ Esta lei serve de parâmetro para uma elevada gama de dispositivos digitais, al
 
 Esse padrão continuou a se manter, e não se espera que pare até, no mínimo, 2021.
 
+### Lei de Murphy / Lei de Sod
+
+[Murphy's Law on Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law)
+
+> Anything that can go wrong will go wrong.
+
+Related to [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) _Murphy's Law_ states that if a thing can go wrong, it will go wrong.
+
+This is a common adage among developers. Sometimes the unexpected happens when developing, testing or even in production. This can also be related to the (more common in British English) _Sod's Law_:
+
+> If something can go wrong, it will, at the worst possible time.
+
+These 'laws' are generally used in a comic sense. However, phenomena such as [_Confirmation Bias_](#TODO) and [_Selection Bias_](#TODO) can lead people to perhaps over-emphasise these laws (the majority of times when things work, they go unnoticed, failures however are more noticeable and draw more discussion).
+
+See Also:
+
+- [Confirmation Bias](#TODO)
+- [Selection Bias](#TODO)
+
+### Navalha de Occam
+
+[Occam's Razor on Wikipedia](https://en.wikipedia.org/wiki/Occam's_razor)
+
+> Entities should not be multiplied without necessity.
+>
+> William of Ockham
+
+Occam's razor says that among several possible solutions, the most likely solution is the one with the least number of concepts and assumptions. This solution is the simplest and solves only the given problem, without introducing accidental complexity and possible negative consequences.
+
+See also:
+
+- [YAGNI](#yagni)
+- [No Silver Bullet: Accidental Complexity and Essential Complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Example:
+
+- [Lean Software Development: Eliminate Waste](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
 ### Lei de Parkinson
 
 [Lei de Parkinson](https://en.wikipedia.org/wiki/Parkinson%27s_law)
@@ -199,6 +377,18 @@ Esse padrão continuou a se manter, e não se espera que pare até, no mínimo,
 
 A lei de Parkinson foi publicada por Cyril Northcote Parkinson num artigo na revista The Economist em 1955, sendo depois reimpresso com outros artigos no livro Parkinson's Law: The Pursuit of Progress [A lei de Parkinson: a busca do progresso].Em seu contexto original, essa Lei foi baseada em estudos de burocracia. E pode ser pessimisticamente aplicado a desenvolvimento de software, a teoria diz que equipes serão ineficientes até os prazos finais, quando irão dar o máximo até o prazo final.
 
+### Efeito de Otimização Prematura
+
+[Premature Optimization on WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
+
+> Premature optimization is the root of all evil.
+>
+> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
+
+In Donald Knuth's paper [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: **premature optimization is the root of all evil**. Yet we should not pass up our opportunities in that critical 3%."
+
+However, _Premature Optimization_ can be defined (in less loaded terms) as optimizing before we know that we need to.
+
 ### Lei de Putt
 
 [Lei de Putt na wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
@@ -216,8 +406,19 @@ Veja também:
 - [O Principio de Peter](#em-progresso)
 - [Lei de Dilbert](#em-progresso).
 
+### Lei de Reed
 
-### A lei da Conservação de Complexidade (Lei de Tesler)
+[Reed's Law on Wikipedia](https://en.wikipedia.org/wiki/Reed's_law)
+
+> The utility of large networks, particularly social networks, scales exponentially with the size of the network.
+
+This law is based on graph theory, where the utility scales as the number of possible sub-groups, which is faster than the number of participants or the number of possible pairwise connections. Odlyzko and others have argued that Reed's Law overstates the utility of the system by not accounting for the limits of human cognition on network effects; see [Dunbar's Number](#dunbars-number).
+
+See also:
+- [Metcalfe's Law](#metcalfes-law)
+- [Dunbar's Number](#dunbars-number)
+
+### A Lei da Conservação da Complexidade (Lei de Tesler)
 
 [A lei da Conservação de Complexidade na wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
 
@@ -227,7 +428,7 @@ Alguma complexidade em um sistema é "inadvertida". É uma consequência da estr
 
 Um elemento interessante para essa lei é a sugestão de que, mesmo simplificando todo o sistema, a complexidade intrínseca não é reduzida, ela é “movida para o usuário”, que deve se comportar de uma maneira mais complexa.
 
-### A lei das Abstrações gotejantes
+### A Lei das Abstrações Gotejantes
 
 [The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
 
@@ -249,7 +450,7 @@ Real-world examples:
 
 - [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - an issue I encountered in the past. Photoshop would be slow to startup, sometimes taking minutes. It seems the issue was that on startup it reads some information about the current default printer. However, if that printer is actually a network printer, this could take an extremely long time. The _abstraction_ of a network printer being presented to the system similar to a local printer caused an issue for users in poor connectivity situations.
 
-### The Law of Triviality
+### A Lei da Trivialidade
 
 [The Law of Triviality on Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality)
 
@@ -259,7 +460,7 @@ The common fictional example used is that of a committee approving plans for nuc
 
 The fictional example above led to the usage of the term 'Bike Shedding' as an expression for wasting time on trivial details.
 
-### The Unix Philosophy
+### A Filosofia Unix
 
 [The Unix Philosophy on Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy)
 
@@ -267,7 +468,7 @@ The Unix Philosophy is that software components should be small, and focused on
 
 Modern practices like 'Microservice Architecture' can be thought of as an application of this law, where services are small, focused and do one specific thing, allowing complex behaviour to be composed of simple building blocks.
 
-### The Spotify Model
+### O Modelo Spotify
 
 [The Spotify Model on Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
 
@@ -275,7 +476,7 @@ The Spotify Model is an approach to team and organisation structure which has be
 
 The Spotify Model also popularises the concepts of Tribes, Guilds, Chapters, which are other components of their organisation structure.
 
-### Wadler's Law
+### Lei de Wadler
 
 [Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
 
@@ -294,11 +495,38 @@ See also:
 
 - [The Law of Triviality](#the-law-of-triviality)
 
-## Principles
+### Lei de Wheaton
 
-Principles are generally more likely to be guidelines relating to design.
+[The Link](http://www.wheatonslaw.com/)
 
-### The Pareto Principle (The 80/20 Rule)
+[The Official Day](https://dontbeadickday.com/)
+
+> Don't be a dick.
+>
+> _Wil Wheaton_
+
+Coined by Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), this simple, concise, and powerful law aims for an increase in harmony and respect within a professional organization. It can be applied when speaking with coworkers, performing code reviews, countering other points of view, critiquing, and in general, most professional interactions humans have with each other.
+
+## Princípios
+
+Os princípios são como diretrizes relacionadas à design.
+
+### O Princípio Dilbert
+
+[The Dilbert Principle on Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle)
+
+> Companies tend to systematically promote incompetent employees to management to get them out of the workflow.
+>
+> _Scott Adams_
+
+A management concept developed by Scott Adams (creator of the Dilbert comic strip), the Dilbert Principle is inspired by [The Peter Principle](#the-peter-principle). Under the Dilbert Principle, employees who were never competent are promoted to management in order to limit the damage they can do. Adams first explained the principle in a 1995 Wall Street Journal article, and expanded upon it in his 1996 business book, [The Dilbert Principle](#reading-list).
+
+See Also:
+
+- [The Peter Principle](#the-peter-principle)
+- [Putt's Law](#putts-law)
+
+### O Princípio de Pareto (Regra do 80/20)
 
 [The Pareto Principle on Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle)
 
@@ -320,7 +548,24 @@ Real-world examples:
 
 - In 2002 Microsoft reported that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in windows and office would become eliminated ([Reference](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
 
-### The Robustness Principle (Postel's Law)
+### O Princípio de Peter
+
+[The Peter Principle on Wikipedia](https://en.wikipedia.org/wiki/Peter_principle)
+
+> People in a hierarchy tend to rise to their "level of incompetence".
+>
+> _Laurence J. Peter_
+
+A management concept developed by Laurence J. Peter, the Peter Principle observes that people who are good at their jobs are promoted, until they reach a level where they are no longer successful (their "level of incompetence"). At this point, as they are more senior, they are less likely to be removed from the organisation (unless they perform spectacularly badly) and will continue to reside in a role which they have few intrinsic skills at, as their original skills which made them successful are not necessarily the skills required for their new jobs.
+
+This is of particular interest to engineers - who initially start out in deeply technical roles, but often have a career path which leads to _managing_ other engineers - which requires a fundamentally different skills-set.
+
+See Also:
+
+- [The Dilbert Principle](#the-dilbert-principle)
+- [Putt's Law](#putts-law)
+
+### O Princípio da Robustez (Lei de Postel)
 
 [The Robustness Principle on Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle)
 
@@ -332,7 +577,7 @@ The goal of this principle is to build systems which are robust, as they can han
 
 ### SOLID
 
-This is an acronym, which refers to:
+É um acrônimo para:
 
 * S: [The Single Responsibility Principle](#the-single-responsibility-principle)
 * O: [The Open/Closed Principle](#the-openclosed-principle)
@@ -342,7 +587,7 @@ This is an acronym, which refers to:
 
 These are key principles in [Object-Oriented Programming](#todo). Design principles such as these should be able to aid developers build more maintainable systems.
 
-### The Single Responsibility Principle
+### O Princípio da Responsabilidade Única
 
 [The Single Responsibility Principle on Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle)
 
@@ -357,7 +602,7 @@ See also:
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
 
-### The Open/Closed Principle
+### O Princípio do Aberto/Fechado
 
 [The Open/Closed Principle on Wikipedia](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle)
 
@@ -374,7 +619,7 @@ See also:
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
 
-### The Liskov Substitution Principle
+### O Princípio da Substituição de Liskov
 
 [The Liskov Substitution Principle on Wikipedia](https://en.wikipedia.org/wiki/Liskov_substitution_principle)
 
@@ -391,7 +636,7 @@ See also:
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
 
-### The Interface Segregation Principle
+### O Princípio da Segregação de Interface
 
 [The Interface Segregation Principle on Wikipedia](https://en.wikipedia.org/wiki/Interface_segregation_principle)
 
@@ -410,7 +655,7 @@ See also:
 - [Duck Typing](#todo)
 - [Decoupling](#todo)
 
-### The Dependency Inversion Principle
+### O Princípio da Inversão de Dependência
 
 [The Dependency Inversion Principle on Wikipedia](https://en.wikipedia.org/wiki/Dependency_inversion_principle)
 
@@ -429,7 +674,7 @@ See also:
 - [Inversion of Control](#todo)
 - [Dependency Injection](#todo)
 
-### The DRY Principle
+### O Princípio DRY
 
 [The DRY Principle on Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
 
@@ -445,6 +690,20 @@ See also:
 
 - [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
 
+### O Princípio KISS
+
+[KISS on Wikipedia](https://en.wikipedia.org/wiki/KISS_principle)
+
+> Keep it simple, stupid
+
+The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.  Originating in the U.S. Navy in 1960, the phrase has been associated with aircraft engineer Kelly Johnson.
+
+The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication of the tools available to repair them, not the capabilities of the engineers themselves. 
+
+See also:
+
+- [Gall's Law](#galls-law)
+
 ### YAGNI
 
 [YAGNI on Wikipedia](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)
@@ -463,17 +722,77 @@ See also:
 
 - [Reading List: Extreme Programming Installed](#reading-list)
 
+### As Falácias da Computação Distribuída
+
+[The Fallacies of Distributed Computing on Wikipedia](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
+
+Also known as _Fallacies of Networked Computing_, the Fallacies are a list of conjectures (or beliefs) about distributed computing, which can lead to failures in software development. The assumptions are:
+
+- The network is reliable
+- Latency is zero
+- Bandwidth is infinite
+- The network is secure
+- Topology doesn't change
+- There is one administrator
+- Transport cost is zero
+- The network is homogeneous
+
+The first four items were listed by [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) and [Tom Lyon](https://twitter.com/aka_pugs) around 1991 and first classified by [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) as the "Fallacies of Networked Computing". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) added the 5th, 6th and 7th fallacies. In the late 90's Gosling added the 8th fallacy.
+
+The group were inspired by what was happening at the time inside [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
+
+These fallacies should be considered carefully when designing code which is resilient; assuming any of these fallacies can lead to flawed logic which fails to deal with the realities and complexities of distributed systems.
+
+See also:
+
+- [Foraging for the Fallacies of Distributed Computing (Part 1) - Vaidehi Joshi
+ on Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
+- [Deutsch's Fallacies, 10 Years After](http://java.sys-con.com/node/38665)
+
+## Lista de leitura
 
-## Lista de Livros
 
 If you have found these concepts interesting, you may enjoy the following books.
 
 - [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Covers the core principles of Extreme Programming.
 - [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - A classic volume on software engineering. [Brooks' Law](#brooks-law) is a central theme of the book.
 - [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - This book is difficult to classify. [Hofstadter's Law](#hofstadters-law) is from the book.
+- [The Dilbert Principle - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - A comic look at corporate America, from the author who created the [Dilbert Principle](#the-dilbert-principle).
+- [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Another comic look at the challenges of larger organisations and people management, the source of [The Peter Principle](#the-peter-principle).
 
-## Em Progresso
+## Traduções
 
-Hi! If you land here, you've clicked on a link to a topic I've not written up yet, sorry about this - this is work in progress!
+Thanks to a number of wonderful contributors, Hacker Laws is available in a number of languages. Please consider sponsoring moderators!
 
-Feel free to [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) requesting more details, or [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) to submit your proposed definition of the topic. 
+| Language | Moderator | Status |
+|----------|-----------|--------|
+| [🇧🇷 Brasileiro / Brazilian](./translations/pt-BR.md) | [Leonardo Costa](https://github.com/leofc97) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pt-BR/badge.svg)](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge) |
+| [🇨🇳 中文 / Chinese](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Partially complete |
+| [🇩🇪 Deutsch / German](./translations/de.md) | [Vikto](https://github.com/viktodergunov) | [![gitlocalized ](https://gitlocalize.com/repo/2513/de/badge.svg)](https://gitlocalize.com/repo/2513/de?utm_source=badge) |
+| [🇫🇷 Français / French](./translations/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [![gitlocalized ](https://gitlocalize.com/repo/2513/fr/badge.svg)](https://gitlocalize.com/repo/2513/fr?utm_source=badge) |
+| [🇬🇷 ελληνικά / Greek](./translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [![gitlocalized ](https://gitlocalize.com/repo/2513/el/badge.svg)](https://gitlocalize.com/repo/2513/el?utm_source=badge) |
+| [🇮🇹 Italiano / Italian](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Partially complete |
+| [🇰🇷 한국어 / Korean](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Partially complete |
+| [🇱🇻 Latviešu Valoda / Latvian](./translations/lv.md) | [Arturs Jansons](https://github.com/iegik) | [![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)](https://gitlocalize.com/repo/2513/lv?utm_source=badge) |
+| [🇷🇺 Русская версия / Russian](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Partially complete |
+| [🇪🇸 Castellano / Spanish](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Partially complete |
+| [🇹🇷 Türkçe / Turkish](https://github.com/umutphp/hacker-laws-tr) | [Umut Işık](https://github.com/umutphp) | [![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)](https://gitlocalize.com/repo/2513/tr?utm_source=badge) |
+
+If you would like to update a translation, just [open a pull request](https://github.com/dwmkerr/hacker-laws/pulls). If you want to add a new language, log onto [GitLocalize](https://gitlocalize.com/) to create an account, then open an issue asking to administer the language and I will add you to the project! It would also be super helpful if you can open a pull request which updates the table above and link at the top of the file.
+
+## Projetos relacionados
+
+- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receive a daily hacker law/principle.
+- [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - List, view and see random laws from the terminal!
+
+## Contribuindo
+
+Por favor, contribua! [Abra uma issue](https://github.com/dwmkerr/hacker-laws/issues/new) se você deseja ver aqui algum conteúdo novo, sugerir uma alteração/correção, ou então [abra uma pull request](https://github.com/dwmkerr/hacker-laws/compare) e proponha suas próprias modificações.
+
+Certifique-se de ler as [Diretrizes de Contribuição](../.github/contributing.md) para saber sobre os padrões de texto, estilo etc. Esteja ciente do [Código de Conduta](../.github/CODE_OF_CONDUCT.md) ao participar de discussões sobre o projeto.
+
+## Em construção
+
+Olá! Se você parou aqui, clicou em um link para um tópico que não foi escrito ainda. Desculpe por isso, este trabalho está em andamento!
+
+Sinta-se livre para [abrir uma issue](https://github.com/dwmkerr/hacker-laws/issues) solicitando mais detalhes, ou [abra uma pull request](https://github.com/dwmkerr/hacker-laws/compare) para submeter suas modificações.