Verdades difíceis de engolir programação de software
Tags: career, programming
Published: 2021-05-17 01:57:55


Sócrates sempre fez perguntas difíceis de serem respondidas: Quem é o homem? Por que existo? O que é o belo? O que é o justo?

Mas convenhamos que atualmente as pessoas não gostam de         quem faz perguntas. Na verdade, elas gostam mesmo é de respostas prontas, porém quando as têm, relutam pela dificuldade de digerir certas verdades.

Conto com seu bom senso em debatermos sobre algumas verdades, e saiba que, negá-las não as tornarão em inverdades.


### **1. É preciso estudar programação todos os dias**.

Procure trabalhar com pessoas que procuram falar sobre inovação diariamente, ou encontre um par de estudos. Atuar em projetos da comunidade é um excelente meio de contribuir para o seu aprendizado de forma mais dinâmica. Leia mais sobre este tema neste meu texto: [Quem não inova, morre](https://dev.to/belintani/quem-nao-inova-morre-3leh/).


### **2. Existe sim, uma linguagem de programação melhor do que outras**.

Certamente esta é a mais polêmica, e atrai muita discussão, mas não acredite nas bobeiras do seu amigo, algumas linguagens são sim, melhores do que outras. Empresas insistem na falácia de que isto não é verdade, apenas para que haja interesse de alguém para trabalhar com uma linguagem de programação horrível e arcaica, afinal, reconstruir tudo é muito caro. 

Agora, dizer qual é a melhor linguagem não é uma resposta simples, até porque altera constantemente. Minha recomendação é olhar para algumas características: Contexto (o que você quer construir); Frequência de atualização; tamanho da comunidade; contribuição de seu(s) criador(es); performance computacional; e simplicidade na sintaxe.


### **3. A grande maioria dos programadores não são bons programadores**.

Vivemos em um mercado aquecido onde não existe desemprego para quem iniciou uma faculdade na área, e a maioria esmagadora (uns 95%?) parecem não ter aptidão para tal carreira. As empresas sabem disso, mas ficam acuadas: o recrutador tem meta de contratação, o gestor tem meta de crescimento do time, e a diretoria prefere fazer vista grossa e fingir que possuem um time forte. 

Os poucos destaques são os profissionais incríveis, e recomendo a leitura do meu texto: [O caminho do sucesso é ser incrível](https://dev.to/belintani/o-caminho-do-sucesso-e-ser-incrivel-12em/).

### **4. Não é necessário um PC gamer para trabalhar**.

Nos anos 90, programação de software já era um trabalho reconhecido, e nada impediu que grandes programadores se desenvolvessem e criassem algoritmos incríveis e software que mudaram a humanidade. Um computador gamer só serve pra uma coisa: **Jogar**. Mas todo programador usa o trabalho como desculpa para montar um “setup” cheio de led RGB e placa de vídeo de 8GB. Mas, apesar de desnecessário, recomendo jogos como um excelente passatempo.

### **5. O seu código um dia será apagado**.

Infelizmente existe ciclo para substituição de todo o código criado. Se esforce em adequá-lo aos padrões de longevidade, mas saiba que o fracasso é iminente. Leia mais sobre este tema neste meu texto: [O seu código vai virar lixo](https://dev.to/belintani/o-seu-codigo-vai-virar-lixo-1f7f/).

### **6. Performance é melhor que elegibilidade**.

Recentemente vi programadores medíocres defendendo ser uma boa estratégia alterar um código de 50ms de resposta para 250ms em prol de uma leitura “mais fácil”. Sinto muito ser o porta voz, mas isso não deve ser feito. Não deixe que as **suas limitações** no entendimento do código lhe permitam cometer tal crime. Se o código anterior entregava 5x mais rápido, com certeza absoluta ele é um código melhor, e deve utilizar corretamente as características da linguagem adotada. Aprenda com o código, melhore-o se puder, mas nunca, jamais, piore o desempenho do mesmo se não for **realmente necessário**.

### **7. Um verdadeiro bom programador só nasce depois de 10.000 horas programando**.

O conceito é bem conhecido, onde diz que para se tornar expert em qualquer assunto, é necessário contato por dez mil horas. Como programador de carreira, impossível eu não concordar com isso. Programar não é LER sobre. É experimentar, codificar front-end, back-end, mobile. Ter habilidade em codificar requer lógica, algoritmo, metodologia de estudo, e claro, desenvolvimento de um software por completo. Sou a favor das especialidades, mas defendo que, um verdadeiro programador precisa ser capaz de criar um software inteiro, mesmo que o seu forte seja só em uma vertical, o básico das outras é obrigatório.

### **8. Trocar de emprego o tempo todo mancha sim o seu currículo**.

O tempo médio de programadores em startups de tecnologia é de 18 meses. Hoje, com a alta demanda, é possível sim fazer “pula pula” a cada 6 meses no inicio da sua carreira. Mas saiba que, quando você tiver 10 anos de experiência, essa falta de foco em construir algo poderá diferenciar entre conseguir um salário baixo, ou o salário maior do que o diretor da empresa. Quando encontrar uma empresa que você goste do projeto e da equipe, abrace-a e não troque por 20% de aumento, tenha um foco a longo prazo.

### **9. O quanto antes você falar inglês, melhor**.

Existe uma grande mentira, de que é possível codificar apenas sabendo o básico do básico de inglês. Porém, nomear variáveis, métodos, e qualquer anotação requer o uso de termos claros, e escrever nomes ruins/errados em inglês é pior do que escrevê-los em português. 

Mas não se precipite, não escreva códigos em português, ou todos vão lhe odiar. Não queremos códigos limitados a brasileiros, e por este motivo, o seu código deve ser escrito em inglês. O que fazer então? Corra e aprenda logo, está perdendo tempo.

### **10. Bug é erro de desenvolvimento**.

Tal como um cozinheiro errando no tempero, ou um escritor se perdendo na história de um personagem, **bugs** nos software é um reflexo direto de um erro no trabalho de construção do código fonte. Então sim, criar muitos bugs significa que algo está errado com o desenvolvedor, seja correria, falta de foco, ou simplesmente, desânimo com a tarefa assumida. Assim como a uma década atrás era inevitável o fim dos "analistas de sistemas" (criadores de diagramas que não sabiam programar), profissionais que apenas fazem "Quality Assurance (QA)" já estão desaparecendo, dando espaço, finalmente (e como antigamente), para programadores garantindo os seus entregáveis de forma estável.  
 
## Sei que não é fácil ler tais verdades, são difíceis de engolir mesmo.