Eu provavelmente poderia alcançar 300% a mais em 6 anos como programador se soubesse dessas coisas quando comecei.
A codificação não é sobre a codificação
Sobre o que você acha que é programação?
Escrevendo código?
Escrevendo um bom código?
Não.
É apenas uma parte da verdade.
Programar não tem a ver com codificação, mas sim com a solução de problemas de codificação.
Os clientes finais não se importam com quais tecnologias, linguagens, estruturas ou metodologias você usa. Eles se preocupam apenas com uma coisa, se o seu produto resolve o problema deles ou não.
É por isso que ninguém se importa com as tecnologias de pesquisa do Google usando nos bastidores. Até que as pessoas possam encontrar informações relativas com ele, eles o usarão.
É a primeira coisa que eu gostaria de saber quando comecei a programar.
Eu gastaria menos tempo escrevendo o “melhor código” e mais tempo resolvendo melhor os problemas do cliente.
Não escreva código apenas para escrever código, resolva os problemas do cliente com o código.
Habilidades de comunicação são mais importantes do que habilidades de codificação
Quando comecei minha carreira, a falta de habilidades sociais não era meu principal problema. Mas quando subi para a posição intermediária, sênior e de liderança, minhas fracas habilidades pessoais se tornaram meu calcanhar de Aquiles.
Quando você trabalha em um produto com um grupo de pessoas diferentes (engenheiros, designers, gerentes), a comunicação é a única coisa que faz de você uma “equipe” e ajuda você a desenvolver o produto com eficácia.
A falta de habilidades sociais faz o oposto, diminui o tempo de desenvolvimento do produto e a produtividade geral.
Esta é a situação real que você pode enfrentar:
A equipe de liderança diz a seu gerente de produto que eles desejam criar um novo recurso de produto e colocá-lo no próximo lançamento do produto. Não é urgente, eles só querem liberá-lo o mais rápido possível (como sempre).
O gerente de produto liga para você no Zoom, diz o que você precisa construir e pergunta: “Quanto tempo você precisa para construir?”
Você está fazendo um cálculo aproximado e diz: “Preciso de 20 horas”.
O gerente de produto não está satisfeito com sua resposta. Ele quer divulgá-lo o mais rápido possível e mostrar à gerência que pode entregar resultados rapidamente (esta é uma situação muito comum).
Então ele pergunta a você: “Você pode construí-lo por 10 horas? Precisamos muito desse recurso no próximo lançamento do produto! ”
E você sabe que pode se cortar os cantos (sem testes, código confuso), mas então você precisará refatorá-lo, e isso levará mais 30 horas. Porque outros engenheiros trabalharão com seu código confuso quando você o liberar. E após a refatoração, você precisará integrar o código deles ao seu.
Então aqui está o que vai acontecer a seguir. Se você tiver habilidades sociais ruins, não convencerá o Gerente de Produto de que na verdade precisa de 20 horas para criar esse recurso.
Por quê?
Os gerentes de produto costumam ter boas habilidades sociais, por experiência própria. Então, se você não conseguir convencê-lo de que refatorar mais tarde é pior do que gastar 20 horas agora, ele facilmente argumentará com você e o convencerá de que “refatorar mais tarde está certo”. E toda a equipe perderá 30 horas adicionais para essa refatoração (não conto o tempo para corrigir bugs imprevisíveis depois).
Mas se você tiver boas habilidades de comunicação, você será capaz de convencê-lo do contrário.
Portanto, melhore suas habilidades sociais e de codificação (envie memes nos chats em grupo no Slack ou algo assim).
E lembre-se de uma verdade simples:
As pessoas trabalham com pessoas, não com máquinas.
Pausas regulares ajudam a programar melhor
Há 4 anos sempre me sinto exausto depois do trabalho. De alguma forma, eu poderia trabalhar produtivamente apenas por algumas horas. Depois disso, não tive muita energia. Até que aprendi sobre a técnica Pomodoro.
É bem simples. Você trabalha por 25 minutos e faz uma pausa de 5 minutos.
Sua rotina de trabalho se torna:
8h00-8h25 – Trabalho
8: 25-8: 30 – Pausa
8: 30-8: 55 – Trabalho
8: 55-9: 00 – Pausa
…
Eu tentei por uma semana e fiquei surpreso com o quão focado, enérgico e produtivo me tornei ( a ciência por trás do Pomodoro )
Em seguida, fui mais longe e implementei o sistema 52 + 17 e meus níveis de produtividade aumentaram 200%.
Portanto, faça pausas regulares se quiser operar em suas capacidades máximas.
10X Engenheiros não existem
No início da minha carreira, pensei que um grande programador é uma pessoa que conhece toneladas de linguagens de programação, frameworks e metodologias.
Eu estava errado.
Essa mentalidade só deu origem à minha síndrome do impostor. Achei que não mereço meu cargo atual, meu salário, que sou uma “fraude”. Então comecei a seguir todos os desenvolvedores populares no Twitter, ler todas as notícias técnicas e milhares de blogs de desenvolvedores apenas para me convencer de que mereço o que tenho e me sentir mais próximo do título de “grande desenvolvedor”.
Este não era um comportamento saudável.
Mas me ajudou a descobrir que muitas pessoas que eu seguia (pensei que fossem engenheiros 10X) na verdade não sabiam muitas coisas. Eles podem saber como fazer algumas coisas complexas que requerem muito conhecimento profundo diferente em alguns campos e ao mesmo tempo não sabem algumas coisas primitivas. Gostaria de saber como projetar arquiteturas de banco de dados altamente escaláveis, mas não sei como alinhar verticalmente um elemento com CSS.
Muito obrigado a esses desenvolvedores, como Dan Abramov (criador do Redux) por este artigo , eles curaram minha síndrome do impostor e me mostraram que está tudo bem não saber de algo.
Programar não é difícil se você souber como aprender
Quando comecei a aprender JavaScript, foi difícil. Porque aprendi da maneira errada.
Leia muita teoria sem prática, sem rotina, sem objetivo final. Caos.
Achei normal aprender assim. Até que descobri a prática deliberada.
É um tipo de prática (aprendizagem) proposital e sistemática.
A diferença entre prática normal e deliberada é que deliberado requer atenção concentrada e é conduzido com o objetivo específico de melhorar o desempenho.
Depois de aplicar uma prática deliberada, comecei a notar o quão rápido estou progredindo no aprendizado de JavaScript. Meu conhecimento começou a grudar por muito tempo, não apenas por 5 minutos após os tutoriais. Eu criei a meta final, por que estou aprendendo JavaScript e entendo o que preciso aprender e o que não.
📌 Observação rápida: estou criando um curso de JavaScript em que estou usando a prática deliberada para combinar a teoria moderna e prática do JavaScript com muita prática do mundo real para ensiná-lo a se tornar um desenvolvedor de JavaScript habilidoso com conhecimento dos recursos da linguagem moderna.
Então, aqui está o que você precisa para realizar a prática deliberada por conta própria:
- Professor: oferece atividades práticas destinadas a ajudá-lo a melhorar o desempenho.
- Desempenhe com o máximo esforço: constantemente sendo retirado da sua zona de conforto.
- Metas bem definidas e específicas: não apenas “melhoria geral”.
- Para estar em foco: dê toda a sua atenção, sem distrações.
- Faça ações conscientes: sem piloto automático.
- Resposta instantânea ao feedback e modificação de sua estratégia.
Quando você começar a aprender uma nova linguagem, tecnologia, estrutura ou qualquer outra coisa, siga essas regras para obter grandes resultados o mais rápido possível.
Não existe “melhor linguagem de programação”
Não existe o melhor “algo” em nosso mundo. Melhor apenas em alguma coisa .
Vamos pegar carros. Como podemos escolher o melhor carro do mundo? Por velocidade? Por segurança? Por quais critérios?
É impossível.
Só podemos escolher o melhor carro em uma determinada categoria. Como o carro mais seguro. Ou o melhor carro offroad.
E se olharmos mais profundamente, cada categoria resolve alguns problemas.
Por exemplo.
Problema: Temos filhos e os levamos para a escola todos os dias, queremos que nossos filhos estejam seguros no caminho para a escola.
Solução: Compre o carro mais seguro.
Problema: vamos acampar todo fim de semana, então precisamos de algum veículo que nos leve facilmente a lugares de difícil acesso.
Solução: Compre o melhor carro off-road.
O mesmo acontece com as linguagens de programação. Algumas linguagens e ferramentas são melhores para resolver alguns problemas do que outras.
Se quisermos construir um site interativo, escolhemos JavaScript.
Se quisermos usar ML / AI, escolhemos Python.
Lembre-se, não existe melhor linguagem de programação, existe a melhor linguagem de programação para …
Portanto, comece com um problema primeiro e, em seguida, escolha uma linguagem para resolvê-lo.