Ideias que mudaram
- Simplicidade não surge sozinha; é algo que exige esforço contínuo
- Percebi que não há motivo para ter orgulho de administrar ou entender complexidade
- Em equipes com níveis de experiência variados, linguagens com tipagem são indispensáveis
- Java é uma linguagem excelente justamente porque é sem graça
- O REPL não é útil como ferramenta de design, mas é útil para uso exploratório
- A programação de verdade deveria acontecer quase toda antes da etapa de escrever código
- O desenvolvimento frontend virou um território de pesadelo kafkiano e já não é mais divertido
- O conceito de elegância não consegue servir como métrica real
- Gestão de verdade é algo extremamente valioso (ao longo de uma carreira longa, quase não vi gestão de verdade)
- DynamoDB é um bom banco de dados se encaixar exatamente em uma carga de trabalho específica
- Orientação a objetos é uma abordagem excelente nos domínios em que ela se encaixa bem. Tratar apenas o paradigma funcional como verdade absoluta é tolice
Opiniões que adquiri
- O núcleo da engenharia é comunicação
- Não se deve aplicar o conceito de Monad de forma exagerada em Java
- O Query Planner é implacável
- O momento em que algo parece “fácil” é, na verdade, um sinal de que você ainda não entendeu direito
- É preciso dar aos desenvolvedores iniciantes espaço para explorar e errar
- É preciso desenvolver ativamente soft skills. O retorno do investimento aparece imediatamente
- No desenvolvimento de aplicações em geral, quase não existe “abstração verdadeiramente genérica”. É melhor escrever apenas o código necessário
- Por outro lado, desenvolver bibliotecas é projetar abstrações. Vale a pena investir tempo para encontrar a estrutura correta (forma algébrica)
- ORM tem muitos problemas em qualquer linguagem e em qualquer implementação. É melhor simplesmente escrever SQL direto
- O problema da programação funcional muitas vezes está nos seus seguidores
- Depois de tempo suficiente, você vai se arrepender bastante de ter construído um sistema em cima de Serverless Functions
- Types são afirmações que fazemos sobre o mundo ao nosso redor
- Locks distribuídos continuam sendo um problema extremamente difícil
- Capacidade de modelagem e análise formal é uma competência indispensável
- A característica mais importante de uma suíte de testes de integração é o isolamento
- DynamoDB também pode ser a pior escolha para o desenvolvimento de aplicações comuns
- A maioria das pessoas não se importa tanto assim com “artesanato” de código. Valorize quem se importa, mas colabore com o restante das pessoas a partir de onde elas estão
- Acho que linguagens gradual e dependentemente tipadas são o futuro
- Tenho convicção de que nunca há comentários demais em código de teste
Opiniões que não mudaram
- Continuo achando que pessoas obcecadas com questões pequenas como estilo de código e regras de linting são um grupo estranho. É melhor focar no que é mais importante
- Mantenho a posição de que cobertura de código não tem relação com qualidade de código (em muitos casos, há até uma tendência inversa)
- Continuo considerando o monólito uma opção perfeitamente válida
- Reconheço que é difícil superar décadas de pesquisa e melhorias acumuladas em RDBMS
- Para adotar microservices, é indispensável ter uma razão legítima (é lamentável que isso esteja sendo tratado cada vez mais como padrão)
- A maioria dos projetos (inclusive projetos internos da AWS) na prática não precisa de “escalabilidade”, e muitas vezes projetar assumindo escalabilidade acaba sendo prejudicial
- Acho que 93% dos gerentes de projeto, talvez algo como 95,2%, poderiam desaparecer sem grande impacto — ou até com ganho de eficiência (a porcentagem subiu em relação a 4 anos atrás)
- Vou ver como isso muda novamente quando eu chegar aos 15 anos de carreira
20 comentários
A maioria dos comentários faz sentido
A maioria dos projetos nunca chega ao momento em que escalabilidade é necessária, ou desaparece antes que isso se torne necessário...
O que seriam linguagens gradualmente tipadas de forma dependente..?
Pelo que ouvi por alto em um podcast, parece ser um sistema de tipos em que valores influenciam os tipos. Vendo o autor deste texto mencionar linguagens funcionais, imagino que seja isso mesmo. Como é algo pesquisado e desenvolvido mais para o lado das linguagens funcionais....
Por exemplo, um tipo
List... se os valores estiverem todos ordenados, ele vira umSortedList....Com esse tipo de propriedade, a checagem de tipos em tempo de compilação conseguiria provar muito mais coisas.
Se uma função recebe um
SortedListe retorna umSortedList... mas, se o código tiver um bug e quebrar o estado de ordenação, aí daria erro de tipo na compilação.Claro que.... o custo da checagem de tipos provavelmente seria bem alto....
Não faço a menor ideia de até que ponto isso já é algo prático hoje.
Ahá, obrigado. Parece bem curioso...
Refere-se a uma linguagem que permite transitar com flexibilidade entre tipagem estática e dinâmica, aplicando ambas conforme necessário.
Java é tão sem graça que, na verdade, é uma linguagem excelente
O que isso quer dizer?
Não importa quem faça, fica tudo mais ou menos parecido, então a manutenção acaba sendo mais fácil — acho que é mais ou menos isso que querem dizer.
Acho que a intenção era dizer que ele transmite uma sensação de estabilidade justamente por não ter nada que exija atenção especial ou surpreenda os desenvolvedores.
Como boa parte das questões relacionadas a estilo de código ou linting pode ser resolvida com ferramentas, quando encontro pessoas que, por outro lado, não se importam com isso, acabo não querendo trabalhar com elas.
Concordo. Eu adiciono uma verificação de estilo ao CI para impedir até mesmo o merge quando o estilo não é seguido.
> Ainda acho que pessoas obcecadas com questões pequenas, como estilo de código e regras de linting, continuam sendo um grupo meio estranho. É preciso focar no que é mais importante.
https://www.youtube.com/watch?v=JcY35HD77lg&t=828s
Mas também dizem que não dá para simplesmente deixar isso passar, porque, por sermos humanos, esses são fatores que dificultam a concentração; então é melhor resolver isso e seguir em frente.
> A maioria das pessoas não liga muito para o "artesanato" do código. Valorize quem se importa com isso, mas, com o restante, é preciso colaborar a partir de onde elas estão.
Concordo..
Sou uma das pessoas que se arrepende de ter construído sistemas em cima de serverless.
Cold start continua lento,
em algum momento o tráfego explode e acaba ficando quase sem diferença para on-demand,
e, mesmo recorrendo a todo tipo de artifício, o deploy é lento demais.
A cobertura de código só me parece não ter relação com a qualidade do código em dois casos:
Acho que são essas duas situações.
Na minha visão, o código de teste só passa a ter valor de fato quando há alta cobertura e vários cenários que provoquem erros, testando a mesma parte várias vezes com entradas diferentes.
Acho mais convincente interpretar no segundo sentido. Um número alto de cobertura de código não está diretamente ligado à qualidade do código; o importante é preenchê-la com casos de teste significativos.
> Java é uma linguagem tão sem graça que, por isso mesmo, é excelente
Isso é meio engraçado kkk
Concordo.
Tópicos de desenvolvimento de software sobre os quais mudei de ideia depois de passar 6 anos no setor
Comentários do Hacker News