Como um desenvolvedor, quando eu encontro um desafio novo - uma funcionalidade para desenvolver, um bug para corrigir, uma melhoria de performance - eu procuro sobre possíveis soluções. Isso me deixa atualizado em “o que a comunidade tem feito?”, e também é uma forma legal de aprender novas soluções.
E, durante essas pesquisas, eu achei um tipo de “problema” - todo mundo tem opinião. Essas opiniões podem ser positivas ou negativas sobre o tópico que você está procurando ou sobre a maneira que você está tentando resolvê-lo. Você pode achar opiniões boas e ruins sobre todas as possíveis tecnologias no mundo - desde linguagens, frameworks, metodologias, arquiteturas…
Eu também tenho minhas opiniões e meus gostos pessoais no desenvolvimento - as ferramentas que eu gosto, coisas que são fáceis, coisa que são boas… Não há problema nenhum nisso. O problema é ter opinião para tudo, e estar fechado para novas opiniões (não só no desenvolvimento, mas na vida como um todo).
Enquanto eu pesquisava sobre “o que usar para montar um blog pessoal?”, li vários textos falando coisas boas sobre o Gatsby, textos desencorajando o uso do WordPress, e não muitos textos sobre o Jekyll… No final, escolhi o Jekyll - porque ele resolvia o meu problema.
Alguns desses posts podem te oferecer bons argumentos, explicando problemas de performance ou segurança que você poderá encontrar, dificuldades na hora de traduzir seu site, ou até falar sobre a comunidade que ajuda no desenvolvimento do framework, ou o tamanho da curva de aprendizado que você terá… Mas também você vai achar textos que te oferecem argumentos baratos baseados em gostos pessoais, como “WordPress é tão desatualizado” - mas, cerca de 1/3 da web usa WordPress; aposto que a pessoa que usa esse tipo de argumento não sabe trabalhar com WordPress, ou é apenas mais um hater (eu chamaria de frustrado).
Agora mesmo, se você ir no Google procurar por “devo usar Ruby em 2020?”, você vai achar opiniões a favor e contrárias ao Ruby.
Alguns desenvolvedores não gostam de absolute import no JavaScript, outros amam (e eu pessoalmente gosto dessa feature). Você vai encontrar pessoas que falam bem e que falam mal sobre essa “funcionalidade”. Nós, enquanto produtores de conteúdo, ou até mesmo influencers, precisamos sempre justificar nossa posição quando somos contrários a alguma coisa - “por que eu não gosto disso?”.
Porque quando damos a nossa opinião, as pessoas vão absorvê-la e utilizá-la como base para escolhas - se são opiniões expostas de maneira correta, bem justificadas, as pessoas terão então uma boa base para justificar o porque delas estarem fazendo algo de tal maneira - ou o porque delas não estarem fazendo.
Para algumas pessoas, se você falar que o tempo de scripting de React é horrível, o React vai ser horrível para sempre - o problema é estar fechado para novas opiniões!
Desenvolvedores, no geral, são pessoas ímpares - eles defendem com unhas e dentes aquilo que eles amam, e jogam no fogo aquilo que não gostam. Eu era um desses desenvolvedores, e então percebi que o efeito Dunning-Kruger estava fazendo efeito sobre minhas escolhas. Quando eu mudei minha mentalidade de “código como o principal” para “valor como o principal”, eu parei de me importar com coisas bobas do tipo “as pessoas não gostam de WordPress” - se utilizando WordPress eu entrego valor, eu vou usar ele sim!
Cada projeto tem suas próprias características, suas implementações e seus mantenedores. Claro que é legal ter um padrão, um boilerplate; mas, você vai perceber que esse padrão não vai contemplar todos os seus projetos. Alguns projetos tem apenas uma camada de abstração, outros precisarão de mais camadas - e você só vai perder tempo tentando colocar esses 2 exempos dentro da mesma caixinha chamada boilerplate; e tempo é algo que não podemos perder!
Eu não sou muito fã do ágil. Mas, se você é um seguidor, você provavelmente vai lembrar do primeiro valor que a metodologia pega:
Indivíduos e interações mais que processos e ferramentas
A maioria das pessoas são ansiosas em discutir padrões, tecnologias, ferramentas, estruturas, e o quão boa/ruim uma coisa pode ser - mas eu não vejo a mesma quantidade de pessoas ansiosas em discutir como um padrão “aumentou o faturamento da empresa em 25%, comparado com o anterior”. Discutir código por código é bobagem, tente discutir código como uma ferramenta para alcançar um objetivo maior e sua mente vai abrir.
