23 changed files with 505 additions and 7 deletions
@ -0,0 +1,94 @@
|
||||
+++ |
||||
title = "Commented Links for 2020-07-26" |
||||
date = 2020-07-26 |
||||
|
||||
[taxonomies] |
||||
tags = ["links", "datomic", "advice", "developer", "google", "racism", |
||||
"logging", "delete", "product manager", "syntax highlight", "highlight", |
||||
"rust", "modules"] |
||||
+++ |
||||
|
||||
Datomic Internals, Developer Advice, Racism@Google, Logging, Code To Delete, |
||||
Being a Product Manager, Syntax Highlight, Rust Module System. |
||||
|
||||
<!-- more --> |
||||
|
||||
## [Unofficial guide to Datomic internals](https://tonsky.me/blog/unofficial-guide-to-datomic-internals/) |
||||
|
||||
Database internals are always curious, to say the least. And Datomic is also a |
||||
curious database, as everything is immutable. |
||||
|
||||
But understating internals is always good to understand where the database |
||||
fits and how to take most of it. |
||||
|
||||
## [Advice to Myself When Starting Out as a Software Developer](https://blog.pragmaticengineer.com/advice-to-myself-when-starting-as-a-software-developer/) |
||||
|
||||
When you're working in the field for too long, it is easy to forget how it was |
||||
when you started. |
||||
|
||||
I can't find anything wrong with the tips, but they feel a bit... bland. I |
||||
mean, honestly, the tips here are something that should be in every developers |
||||
list anyway, beginner or pro. |
||||
|
||||
## [Google Ad Portal Equated “Black Girls” with Porn](https://themarkup.org/google-the-giant/2020/07/23/google-advertising-keywords-black-girls) |
||||
|
||||
Oh, are you saying Google is racist? That's impossible! That's "the algorithm" |
||||
fault! Google is good, it gives me free email! |
||||
|
||||
You see how "giving things for free" and "open source" (and then not listening |
||||
to users) is purely a marketing plot? |
||||
|
||||
## [Good Logging](https://henrikwarne.com/2020/07/23/good-logging/) |
||||
|
||||
Logging is always important -- personally, I think logging (and good logs) are |
||||
more important than debugging -- but knowing _how_ and _what_ to log is the |
||||
key for properly dealing with it. |
||||
|
||||
Some of the points are quite common, like screaming logs, although the |
||||
solution is not using WARNING or INFO, but actually figuring out how to |
||||
properly set the log level for each modules -- and using modules -- feels more |
||||
correctly. |
||||
|
||||
Personally, I leave a lot of `debug` messages in some places, as "scars" of a |
||||
battle. Maybe some future developer will see that sequence and think twice |
||||
before jumping in. |
||||
|
||||
## [Write code that is easy to delete, not easy to extend.](https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to) |
||||
|
||||
That's one thing I totally agree: it is better to write code that's easy to |
||||
delete than to reuse. But simply going into copying things over and over so |
||||
you can delete one thing without breaking the other is not actually the |
||||
solution. |
||||
|
||||
I'd just adding abstractions, to the point functions are so simple they exist |
||||
without any business logic; these logic pieces are then put together in other |
||||
functions, describing _exactly_ what the business rule is: |
||||
get_info_from_server, change_info_in_some_way, and so on. If the rule change, |
||||
you just delete the abstraction in the middle of the larger function. |
||||
|
||||
"But that still doesn't solve it!" Well, if the business rule changed, then |
||||
you can either delete the larger function and write a new one to follows the |
||||
new rule or simply drop -- or add -- any of the abstractions. |
||||
|
||||
## [22 Principles for Great Product Managers](https://reeve.blog/blog/principles/) |
||||
|
||||
I didn't even get to half of the list and I was "yup, I had a hard time with a |
||||
manager that didn't do that" and "I remember when they did that and it was |
||||
awesome". |
||||
|
||||
## [Syntax highlighting is a waste of an information channel](https://buttondown.email/hillelwayne/archive/syntax-highlighting-is-a-waste-of-an-information/) |
||||
|
||||
Once again, "I can get behind the sentiment, but not the implementation". |
||||
Surely, having information about types, or some parameter, in the syntax helps |
||||
a ton, but the fact is that it depends on situation. At some point, the type |
||||
may be more important than the parameter, or vice-versa, or worse, it may give |
||||
focus to something that is not important at that time. Putting all that |
||||
together, at the same time, would be a nightmare -- or a fruit salad |
||||
of colours that would make reading the code and finding what matters completely |
||||
impossible. |
||||
|
||||
## [Clear explanation of Rust’s module system](http://www.sheshbabu.com/posts/rust-module-system/) |
||||
|
||||
Rust module system is a bit different from everything else, and the |
||||
exploration I did gave me some insights about it -- mostly, exactly what the |
||||
post says. |
||||
@ -0,0 +1,98 @@
|
||||
+++ |
||||
title = "Links Comentados de 2020-07-26" |
||||
date = 2020-07-26 |
||||
|
||||
[taxonomies] |
||||
tags = ["links", "datomic", "dicas", "desenvolvedores", "google", "racismo", |
||||
"logging", "logs", "deletar", "gerente de produtos", "syntax highlight", |
||||
"highlight", "rust", "módulos"] |
||||
+++ |
||||
|
||||
Internos do Datomic, Dicas para Desenvolvedores, Racismo@Google, Logs, |
||||
Programe Para Deletar, Sendo um Gerente de Produtos, Syntax Highlight, Módulos |
||||
em Rust. |
||||
|
||||
<!-- more --> |
||||
|
||||
## [Unofficial guide to Datomic internals](https://tonsky.me/blog/unofficial-guide-to-datomic-internals/) |
||||
|
||||
As partes internas de um banco de dados são sempre curiosas, pra dizer o |
||||
mínimo. E Datomic é um banco de dados curioso, onde tudo é imutável. |
||||
|
||||
Mas entender as partes internas é sempre bom para entender onde o banco de |
||||
dados se encaixa e como tirar o máximo disso. |
||||
|
||||
## [Advice to Myself When Starting Out as a Software Developer](https://blog.pragmaticengineer.com/advice-to-myself-when-starting-as-a-software-developer/) |
||||
|
||||
Quando se está na área por algum muito tempo, é fácil esquecer como as coisas |
||||
eram quando você começou. |
||||
|
||||
E não consigo achar nada de errado com as dicas mostradas aqui, mas eles |
||||
parecem tão... basicas. E eu quero dizer que essas dicas são algo que deveria |
||||
estar nas listas de todos os desenvolvedores, iniciantes ou veteranos. |
||||
|
||||
## [Google Ad Portal Equated “Black Girls” with Porn](https://themarkup.org/google-the-giant/2020/07/23/google-advertising-keywords-black-girls) |
||||
|
||||
O que? Você está dizendo que o Google é racista? Mas isso é impossível! Isso é |
||||
culpa "do algoritmo"! Google é bom, eles me dão email de graça! |
||||
|
||||
Vocês conseguem ver como "dar coisas de graça" e "open source" (e não ouvir os |
||||
usuários) não passa de uma jogada de marketing? |
||||
|
||||
## [Good Logging](https://henrikwarne.com/2020/07/23/good-logging/) |
||||
|
||||
Logs são sempre importantes -- pessoalmente, eu acho que logs (e bons logs) |
||||
são mais importantes que debugar -- mas saber _como_ e _o que_ logar é a chave |
||||
para fazer a coisa certa. |
||||
|
||||
Alguns pontos são bem comuns, como os "logs gritantes", embora a solução não |
||||
seria usar `WARNING` e `INFO`, mas descobrir como definir corretamente o nível |
||||
de log de cada módulo -- e usar módulos -- parece ser o mais certo. |
||||
|
||||
Pessoalmente, eu deixo uma pilha de mensagens de `debug` em alguns lugares, |
||||
como "cicatrizes" de uma batalha. Talvez algum outro desenvolvedor vai ver a |
||||
sequência de logs e pensar duas vezes antes de sair trabalhando. |
||||
|
||||
## [Write code that is easy to delete, not easy to extend.](https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to) |
||||
|
||||
Essa é uma coisa que eu consigo concordar: é melhor escrever um código que |
||||
seja fácil de ser apagado do que reusado. Mas simplesmente ir copiando |
||||
diversas partes várias vezes para que seja possível apagar uma sem afetar o |
||||
restado do código não parece ser a solução. |
||||
|
||||
Eu simplesmente iria adicionar mais abstrações, ao ponto que as funções se |
||||
tornassem tão simples que elas existiriam sem qualquer lógica de negócio; |
||||
essas lógicas seriam colocadas juntas em outras funções, descrevendo |
||||
_exatamente_ o que a regra de negócio quer faz: |
||||
recuperar_informacao_do_servidor, alterar_informacao_de_alguma_forma, e assim |
||||
por diante. Se a regra muda, é só remover a abstração no meio da função maior. |
||||
|
||||
"Mas isso ainda não resolve o problema!" Bom, se a regra de negócio mudou, |
||||
então você pode apagar a função maior e criar uma nova que segue a nova regra |
||||
ou simplesmente apagar -- ou adicionar -- alguma das abstrações. |
||||
|
||||
## [22 Principles for Great Product Managers](https://reeve.blog/blog/principles/) |
||||
|
||||
Eu nem tinha chego na metade da lista e eu já estava "É, eu tive um gerente |
||||
que fez minha vida um inferno" e "Eu lembro quando fizeram isso e foi ótimo". |
||||
|
||||
## [Syntax highlighting is a waste of an information channel](https://buttondown.email/hillelwayne/archive/syntax-highlighting-is-a-waste-of-an-information/) |
||||
|
||||
Mais uma vez, "eu concordo com o sentimento, mas não com a implementação". Não |
||||
que ter informação sobre tipos, ou de algum parâmetro, na sintaxe não ajude um |
||||
bocado, mas o fato é que essa informação varia conforme a situação. Em alguns |
||||
pontos, o tipo pode ser mais importante que o parâmetro, ou vice-versa, ou, |
||||
pior, pode dar foco em algo que não seja realmente importante no momento. E |
||||
tentar colocar tudo isso junto, em algum ponto, se tornaria um pesadelo -- ou |
||||
uma salada de frutas de cores que vai fazer a leitura do código e encontrar o |
||||
que importa completamente impossível. |
||||
|
||||
## [Clear explanation of Rust’s module system](http://www.sheshbabu.com/posts/rust-module-system/) |
||||
|
||||
O sistema de módulos do Rust é um pouco diferente dos demais, e algumas |
||||
explorações que eu fiz me deu algumas dicas sobre como esse sistema funciona |
||||
-- mais ou menos o que é dito no post. |
||||
|
||||
<!-- |
||||
vim:spelllang=pt: |
||||
--> |
||||
@ -0,0 +1,9 @@
|
||||
+++ |
||||
title = "George Wald" |
||||
weight = 103 |
||||
|
||||
[taxonomies] |
||||
tags = ["quotes", "george wald", "atoms", "physics"] |
||||
+++ |
||||
|
||||
> "A physicist is an atom's way of knowing about atoms." |
||||
@ -0,0 +1,9 @@
|
||||
+++ |
||||
title = "Grace Hopper" |
||||
weight = 103 |
||||
|
||||
[taxonomies] |
||||
tags = ["quotes", "grace hopper"] |
||||
+++ |
||||
|
||||
> "The most dangerous phrase in the language is, 'We've always done it this way.'" |
||||
@ -0,0 +1,9 @@
|
||||
+++ |
||||
title = "H. H. Williams" |
||||
weight = 104 |
||||
|
||||
[taxonomies] |
||||
tags = ["quotes", "h h williams"] |
||||
+++ |
||||
|
||||
> "Furious activity is no substitute for understanding." |
||||
@ -0,0 +1,11 @@
|
||||
+++ |
||||
title = "Hal Hickman" |
||||
weight = 104 |
||||
|
||||
[taxonomies] |
||||
tags = ["quotes", "hal hickman", "opinions"] |
||||
+++ |
||||
|
||||
> "Opinions are like assholes -- everyone's got one, but nobody wants to look |
||||
> at the other guy's." |
||||
|
||||
@ -0,0 +1,11 @@
|
||||
+++ |
||||
title = "Julius Lester" |
||||
weight = 106 |
||||
|
||||
[taxonomies] |
||||
tags = ["quotes", "julius lester", "riots"] |
||||
+++ |
||||
|
||||
> "Black people have never rioted. A riot is what white people think blacks |
||||
> are involved in when they burn stores." |
||||
|
||||
@ -0,0 +1,11 @@
|
||||
+++ |
||||
title = "Nikolai Kingsley" |
||||
weight = 110 |
||||
|
||||
[taxonomies] |
||||
tags = ["quotes", "nikolai kingsley"] |
||||
+++ |
||||
|
||||
> "Don't fear the darkness. |
||||
> Fear the things that hide in the darkness. |
||||
> Then become one of those things, and let them feat you." |
||||
@ -0,0 +1,11 @@
|
||||
+++ |
||||
title = "Robert Benchley" |
||||
weight = 114 |
||||
|
||||
[taxonomies] |
||||
tags = ["quotes", "robert benchley", "work"] |
||||
+++ |
||||
|
||||
> "Anyone can do any amount of work provided it isn't the work he is supposed |
||||
> to be doing at the moment." |
||||
|
||||
@ -0,0 +1,10 @@
|
||||
+++ |
||||
title = "Thomas Edison" |
||||
weight = 116 |
||||
|
||||
[taxonomies] |
||||
tags = ["quotes", "thomas edison", "religion"] |
||||
+++ |
||||
|
||||
> "All Bibles are man-made." |
||||
|
||||
@ -0,0 +1,9 @@
|
||||
+++ |
||||
title = "Titus Lucretius Carus" |
||||
weight = 116 |
||||
|
||||
[taxonomies] |
||||
tags = ["quotes", "titus lucretius carus", "life"] |
||||
+++ |
||||
|
||||
> "Life is one long struggle in the dark." |
||||
@ -0,0 +1,11 @@
|
||||
+++ |
||||
title = "Wilhelm Reich" |
||||
weight = 119 |
||||
|
||||
[taxonomies] |
||||
tags = ["quotes", "whilhelm reich", "hitler", "politics", "politicians"] |
||||
+++ |
||||
|
||||
> "The fact that Hitler was a political genius unmasks the nature of politics |
||||
> in general as no other can." |
||||
|
||||
@ -0,0 +1,10 @@
|
||||
+++ |
||||
title = "Woody Allen" |
||||
weight = 119 |
||||
|
||||
[taxonomies] |
||||
tags = ["quotes", "woody allen"] |
||||
+++ |
||||
|
||||
> "The lion and the calf shall lie down together but the calf won't get much |
||||
> sleep." |
||||
@ -0,0 +1,31 @@
|
||||
+++ |
||||
title = "Introducing Elixir: Getting Started in Functional Programming - Simon St.Laurent, J. David Eisenberg" |
||||
date = 2020-07-24 |
||||
|
||||
[taxonomies] |
||||
tags = ["books", "reviews", "simon st laurent", "j david eisenberg", "it", |
||||
"elixir", "2020 challenge", "4 stars"] |
||||
+++ |
||||
|
||||
[GoodReads Summary](https://www.goodreads.com/book/show/18194084-introducing-elixir): |
||||
Authors Simon St. Laurent and J. David Eisenberg show you how to write simple |
||||
Elixir programs by teaching you one skill at a time. You'll learn about |
||||
pattern matching, recursion, message passing, process-oriented programming, |
||||
and establishing pathways for data rather than telling it where to go. By the |
||||
end of your journey, you'll understand why Elixir is ideal for concurrency and |
||||
resilience. |
||||
|
||||
<!-- more --> |
||||
|
||||
{{ stars(stars=4) }} |
||||
|
||||
In a way, this is an "Introducing" book, so one shouldn't expect some deep |
||||
knowledge about the language after reading it. But also, sometimes it feels a |
||||
bit too "shallow" to gather some proper understanding of the language. |
||||
|
||||
One thing that kept bugging me was the fact that code kept changing: Not in |
||||
the "going forward" kind of change, which is good, explain the basic, then |
||||
start adding more complex/shorter solutions, but "let me bend this to another |
||||
direction and completely ignore that direction later". |
||||
|
||||
But to get a "feeling" of the language, it is a good book. |
||||
@ -0,0 +1,63 @@
|
||||
+++ |
||||
title = "How to Kill Developer Productivity" |
||||
date = 2020-07-20 |
||||
|
||||
[taxonomies] |
||||
tags = ["developers", "productivity", "programming", "ti", "onboarding", |
||||
"data flow", "architecture"] |
||||
+++ |
||||
|
||||
There are several ways to not kill developer productivity in a project. |
||||
Unfortunately, the real causes are never discussed. |
||||
|
||||
<!-- more --> |
||||
|
||||
Recently I read another post about "how to not kill your developer |
||||
productivity", that says exactly what every other post about it says: |
||||
Basically, "do not interrupt". |
||||
|
||||
But can we really avoid interruptions? Isn't the "ping!" from the coffee |
||||
machine an interruption? Isn't a full bladder an interruption? Isn't the front |
||||
door bell ringing when a package and/or food delivery an interruption? |
||||
|
||||
What's the difference between those interruptions and someone asking |
||||
something? |
||||
|
||||
And do less meetings? Why? Is it because nobody cares enough to write a |
||||
meeting agenda to point what needs to be decided? Or maybe 'cause the frontend |
||||
developers don't care enough about the problems the backend developers are |
||||
facing and vice-versa? |
||||
|
||||
Would a meeting scheduled a week in advance an "interruption"? |
||||
|
||||
I can't see how interruptions can be a problem. Imagine this: |
||||
|
||||
This developer went though an onboarding when they joined the company, and |
||||
they were shown the purpose of the company, they were shown the product the |
||||
company sells and how it works, there were shown the product architecture, |
||||
they were explained the reasons behind every solution applied, they were given |
||||
time to discuss other solutions with their pairs, they were not put on a |
||||
corner to explain every minute of their working day. |
||||
|
||||
With that, can you imagine that someone making a question about some part of |
||||
the system while whoever is coding is in the middle of a function to |
||||
frobnicate[^1] foo? Maybe they will need a bit time to find where they |
||||
stopped, but as the solution was already discussed, and they know the purpose |
||||
of the solution they are working, the interruption would do very little in |
||||
their productivity. |
||||
|
||||
Unfortunately, in IT, we are seen as "machines" and most manufacturing |
||||
techniques are applied directly without considering that we are people (or do |
||||
you think "kanban" was born in IT and not inside the Toyota manufacturing |
||||
plant?). |
||||
|
||||
A stopped machine is wasted money. Stopping production for preventive |
||||
maintenance, without the machine being really broken, having to take it and |
||||
check every part, is wasted money. |
||||
|
||||
And, unfortunately, when a developer is not "developing", they are seen as |
||||
wasted money. And that's why simple stuff, like explaining why a system |
||||
exists, what is the idea of the data flow inside the system and things like |
||||
that are completely ignored: 'Cause the "machine" is not producing anything. |
||||
|
||||
And that's why, when the production is halted, productivity goes down. |
||||
@ -0,0 +1,77 @@
|
||||
+++ |
||||
title = "Como Matar a Produtividade de Desenvolvedores" |
||||
date = 2020-07-20 |
||||
|
||||
[taxonomies] |
||||
tags = ["desenvolvedores", "programação", "ti", "onboarding", |
||||
"fluxo de dados", "arquitetura", "produtividade"] |
||||
+++ |
||||
|
||||
Existem várias formas de não matar a produtividade de desenvolvedores num |
||||
projeto. Infelizmente, as reais causas nunca são comentadas. |
||||
|
||||
<!-- more --> |
||||
|
||||
Recentemente vi mais um artigo de "como não matar a produtividades de |
||||
desenvolvedores", que diz exatamente o que todos os artigos sobre como não |
||||
matar a produtividade de desenvolvedores diz: Basicamente "Evite |
||||
interrupções". |
||||
|
||||
Mas será que dá pra evitar interrupções mesmo? Não seria o "ping!" da |
||||
cafeteira uma interrupção? Não seria a bexiga cheia uma interrupção? Não seria |
||||
a campainha avisando que chegou a encomenda e/ou a tele-entrega uma |
||||
interrupção? |
||||
|
||||
Qual é a diferença entre essas e alguém pedindo ajuda? |
||||
|
||||
E fazer menos reuniões? Por que? Porque ninguém se liga de fazer uma pauta de |
||||
reunião para ter o que decidir? Ou será que é porque os desenvolvedores de |
||||
frontend não dão a mínima para os problemas que o pessoal de backend está |
||||
enfrentando e vice-versa? |
||||
|
||||
Seria uma reunião marcada com uma semana de antecedência uma "interrupção"? |
||||
|
||||
Eu não consigo ver que as interrupções em si são o problema. Imaginem o |
||||
seguinte: |
||||
|
||||
Essa pessoa passou por um onboarding quando entrou na empresa, e foi |
||||
apresentado ao propósito da mesma, foi apresentado ao produto que a empresa |
||||
vende e como o produto funciona, foi apresentada à arquitetura do sistema, foi |
||||
explicado o motivo de cada solução aplicada, foi dado tempo para discutir |
||||
outras soluções com seus pares, não foi colocado contra a parede para explicar |
||||
cada minuto de trabalho do seu dia. |
||||
|
||||
Dado isso, vocês conseguem imaginar que alguém fazendo uma pergunta sobre |
||||
alguma parte do sistema enquanto quem está programando está no meio da função |
||||
de frobnicar[^1] foo? Talvez perca algum tempo para ver em qual ponto parou, |
||||
mas como a solução já foi discutida, e já se sabe o propósito da |
||||
funcionalidade sendo introduzida, a interrupção vai afetar muito pouco o |
||||
resultado final. |
||||
|
||||
Infelizmente, na área de TI, passamos muito tempo sendo vistos como "máquinas" |
||||
e técnicas de produção são aplicadas diretamente sem considerar que somos |
||||
pessoas (ou vocês acham que "kanban" nasceu no meio da TI mesmo e não dentro |
||||
da fábrica da Toyota?). |
||||
|
||||
Uma máquina parada é dinheiro perdido. Parar a produção para manutenção |
||||
preventiva, sem que a máquina esteja realmente quebrada, tendo desmontar a |
||||
mesma e verificar cada uma das partes, é dinheiro perdido. |
||||
|
||||
E, infelizmente, quando um programador não está "programando", é visto como |
||||
dinheiro perdido. E por isso coisas básicas, como explicar o porque o sistema |
||||
existe, qual a ideia do fluxo de dados dentro do mesmo, deixando que |
||||
programadores parem e discutam soluções e coisas do tipo são completamente |
||||
ignoradas: Porque a "máquina" não está produzindo. |
||||
|
||||
E, quando é preciso parar a produção, por qualquer motivo, a produtividade vai |
||||
lá pra baixo. |
||||
|
||||
--- |
||||
|
||||
[^1]: Eu não se tem alguma forma melhor de traduzir |
||||
[frobnicate](https://www.techopedia.com/definition/27996/frobnicate) |
||||
|
||||
|
||||
<!-- |
||||
vim:spelllang=pt: |
||||
--> |
||||
Loading…
Reference in new issue