The Best of edw519
Wanderley Caloni, 2017-02-20

#livros #hacker #produtividade #experiencia

Ed Weissman, ou edw519 para os íntimos, é um dos comentaristas mais efusivos, pragmáticos e experientes do Hacker News. Ele tem programado profissionalmente há quase 40 anos. De mainframes a projetos web, a evolução dele passou basicamente pelo dobro de gerações que provavelmente você passou. Ele também já esteve envolvido como sócio/fundador em três empresas, vendendo tanto serviços quanto produtos. Ele trabalhou com centenas de pessoas em mais de mil projetos em mais de um milhão de linhas de código. Ele já compartilhou muitas opiniões com a comunidade, e agora juntou boa parte dessas opiniões em um livro, um ebook, disponível para qualquer um que queira observar alguém que esteve nas trincheiras por muitos anos e não tem medo de dizer o que pensa.

Clique aqui para baixar seu livro. Se quiser ter apenas um gostinho do que vai encontrar lá, leia meus recortes abaixo (tradução minha):

Algumas frases de efeito

  • Alguns caminhos são melhores que outros, mas qualquer caminho é melhor que nenhum.
  • Como hackers, tudo que fazemos ou é plantar sementes ou colhendo. Se você não vê uma colheita hoje é porque você estava plantando sementes.
  • Quanto eu contrato, eu não estou procurando por uma pessoa ou um recurso. Eu estou procurando por uma solução para meu problema.
  • O que eu realmente me preocupo é como meu software é usado. E quem o usa. Há um stream infinito de pessoas que precisam de coisas e um stream infinito de problemas para solucionar.
  • Apenas se mantenha humilde, lembre-se: nós todos estamos apenas a uma batida de cabeça da feliz ignorância.
  • É muito mais fácil julgar algo que já existe que definir algo que não existe.
  • Engenharia de software não está morta. É que o processo de depender de modelos antes de iniciar nunca funcionou em primeiro lugar.
  • A necessidade de frameworks e linguagens de alto nível só se torna aparente quando crescemos tanto que não é possível achar mais hackers experientes o suficiente. Só quando você apela para as massas medíocres que você precisa dessa ajuda.

Algumas frases de efeito terceirizadas

  • “Eu só vejo um lance à frente, mas é sempre o correto.” - mestre de xadrez Jose Raul Capablanca
  • “Você não pode resolver um problema com a mesma mente que a criou.” - Albert Einstein
  • “Foque no menor problema possível que você pode resolver que cuja solução será potencialmente útil.” - David Cohen
  • “Cada momento que você está trabalhando em algo sem estar na arena pública, esse algo está na verdade morrendo, privado do oxigênio do mundo real.” - Matt Mullenweb
  • “Quando apresentado com um crescimento exponencial, lembre-se que as pessoas tendem a superestimar drasticamente o que irá acontecer o curto prazo, mas subestimam profundamente o que acontece sobre longos períodos de tempo.” - Ryan McIntyre
  • “O que nós acreditamos é baseado em nossas percepções. O que nós percebemos depende do que estamos procurando. O que nós estamos procurando depende do que pensamos. O que pensamos depende do que percebemos. O que nós percebemos é o que aceitamos como verdade. O que aceitamos como verdade é nossa realidade.” - Gary Zukav

Guia de trabalho

  1. Comece com a resposta, então trabalhe ao contrário.
  2. Nomeie suas variáveis para que qualquer um saiba o que elas são.
  3. Nomeie suas funções para que qualquer um saiba o que elas fazem.
  4. Nunca escreva a mesma linha de código duas vezes. Use funções.
  5. Assuma que o usuário não sabe o que ele quer.
  6. Mesmo que o usuário saiba o que quer, assuma que ele não consiga verbalizar.
  7. O usuário sempre sabe o que ele não gosta. Prototipe frequentemente.
  8. Esteja preparado para cavar quantos níveis de detalhe precisar para entender.
  9. Quanto estiver travado em um problema, desligue o computador.
  10. Não ligue o computador a menos que você tenha uma tarefa específica.
  11. Beleza é importante, mas entrega é mais importante.
  12. Nenhuma variável deve ser completamente contida dentro de outra variável.
  13. Todo nome de variável deve ter no mínimo três caracteres de tamanho.
  14. Use a ferramenta certa para o trabalho certo.
  15. Quase qualquer ferramenta pode fazer o trabalho. Algumas são melhores que outras.
  16. Benchmark frequentemente para aprender o que acontece por debaixo dos panos.
  17. Tente algo que nunca foi feito. Pode ser mais fácil do que você pensa.
  18. Lembre-se dos padrões que você usou antes. Você irá usá-los novamente.
  19. Mantenha extremamente simples no começo. Complique conforme avança.
  20. Codifique todos os dias.

Filosofia de vida

  • Como aprender a programar? Ache um cliente com um dedline absurdo. Alcance-o. Repita. Não vai ser bonito, mas você será o tipo de programador que eu iria para a batalha junto: ótimo nas coisas que realmente importam e medíocre nas coisas que não importam.

  • Eu costumava ser muito desagradável em julgar os outros, “Ela é realmente esperta” ou “Ele é tão estúpido”. Então eu aprendi muito com meu primeiro mentor. Ele me ensinou que frequentemente não há muita diferença entre alguém que parece esperto e alguém que não. Talvez ninguém gastou tempo suficiente com um deles. Talvez eles tenham outros desafios, como família, saúde ou circunstâncias. Talvez eles sejam um peixe fora d’água, gastando muito tempo em coisas que não o interessam. Ou talve eles pareçam burros porque eles realmente acreditam que o são. Foi dito a eles tantas vezes que agora eles acreditam.

  • O que faz um programador sênior? Ótima pergunta. Pergunte para n programadores e você obterá n^2 respostas. Isso pode ser facilmente o assunto para outro post ou até um livro. Saindo do topo da minha cabeça em nenhuma ordem particular:

    • entender o problema em mãos antes de escrever qualquer código
    • usar a ferramenta certa para o trabalho certo
    • seguir padrões aceitos e protocolos sem sacrificar a criatividade
    • nomeia variáveis e funções como de fato serão para o próximo programador
    • antecipa o que pode dar errado antes de confiar em um depurador ou testes
    • entende a arquitetura implícita e como melhor utilizá-la
    • nunca escreve o mesmo código duas vezes
    • nunca escreve em 150 linhas o que poderia ser escrito em 100
    • Código ruim: não-comentado. Medíocre: comentado. Bom: não precisa de comentários.
    • entende o ciclo de vida do código inteiro e o escreve para durar
    • tem pena da pobre alma que tem que mantê-lo e deixa uma dica ou duas
    • escreve de maneira flexível para ser facilmente mudado antes que o projeto termine.