1. Deixe o ego na porta
Os desenvolvedores têm egos inchados. É um fato. Mas por que? Eu diria que quem leva sua profissão a sério se considera uma pessoa de arte. Sim, não cantamos para milhões de pessoas e não desenhamos "Mona Lisa", mas às vezes escrevemos códigos que resolvem problemas complexos de maneira tão eficiente e elegante que não podemos deixar de nos orgulhar de nosso trabalho. Acho que o desenvolvedor, por sua abordagem aos problemas, é tanto um homem de arte quanto um matemático. Como tal, tendemos a rastrear o código como uma mãe ursa em torno de sua prole. Nós escrevemos, amamos e odiamos quando as pessoas ao redor discutem sobre o quão errado o código está ou não.
Por outro lado, ainda não ajudou ninguém. Amamos nosso trabalho, mas devemos entender que estamos resolvendo problemas. Ao discutir nossas idéias e soluções com outras pessoas, uma alternativa melhor pode surgir. Não há nada errado. Na verdade, a colaboração tende a produzir melhores soluções. Observei todos os tipos de ego, mas nunca vi uma situação em que o ego funcionasse para um desenvolvedor.
Que conselho posso dar? Desde o minuto em que você começa a trabalhar como desenvolvedor, deixe o seu ego na porta. Engula e ouça o que outras pessoas têm a dizer sobre o seu trabalho. Aceite que as melhores ideias podem não estar na sua cabeça e que podem aumentar o seu profissionalismo. Você só vai ganhar se ouvir o feedback.
2. Os idiomas são uma ferramenta. Você só conhece o martelo? Então todos os problemas são como pregos
Pare de se chamar de desenvolvedor Java ou desenvolvedor JavaScript. Sim, existem idiomas de que você gosta por causa de sua sintaxe ou recursos. Isso é completamente normal. No entanto, você ganha se passar algum tempo estudando outra coisa. Aprender novos idiomas, especialmente se eles estiverem seguindo um paradigma diferente do usual, pode ajudar a abrir sua mente para diferentes abordagens de resolução de problemas.
Eu nem sei o quão importante isso é: aprender novos idiomas e aplicá-los irá beneficiar suas habilidades. Eu li o livro Sete Línguas em Sete Semanas há alguns anos, e ele me abriu muitas opções apenas porque mostrava os métodos de resolução de problemas disponíveis em outras línguas.
Somos desenvolvedores. Sabemos como resolver problemas com código. Não se limite. Olhe além dos limites, pense fora da caixa, aprenda outras opções, linguagens, maneiras de resolver problemas. Mesmo se você não fizer isso por muito tempo, você retornará à sua ferramenta familiar com novas idéias e pensamentos mais amplos.
3. Não se trata de memorizar algoritmos, mas encontrá-los
Alguns desenvolvedores novatos acham que precisam saber os algoritmos de cor, então se sentem mal no minuto em que percebem que começaram a esquecer como escrever o loop for. Isso não é apenas normal. Eu diria que é até útil. Nós simplesmente temos muito para lembrar. Mas isso também é desnecessário. Precisamos aceitar que a Internet é apenas mais uma ferramenta tão necessária quanto nosso IDE para encontrar respostas.
Todos nós fazemos isso. E se isso faz você se sentir mal, não perca tempo com esse sentimento. Basta pesquisar no Google pela resposta e entender seu problema. Pense sobre isso. Cada linguagem tem maneiras semelhantes, mas ligeiramente diferentes de implementar o padrão Observer. O que é mais útil? Compreender para que serve um padrão e para quais problemas ele resolve, ou lembrar como implementá-lo em cada linguagem com a qual você trabalha?
Se você sabe que o padrão resolverá seu problema, então você já o resolveu. Todo o resto é apenas uma busca pela melhor forma de implementá-lo no Google. Essa busca não tira nenhum respeito por você, seu trabalho ou sua experiência. O mesmo se aplica a qualquer outra pesquisa. Concentre-se no que é importante, em resolver o problema e deixe o Google aumentar sua memória. É por isso que existe.
4.
Ou melhor, você tem que estudar para toda a carreira. A decisão de seguir os desenvolvimentos mais recentes da indústria depende de você. Mas é melhor fazer isso se você quiser combinar.
Linguagens e tecnologias estão evoluindo, e isso é perfeitamente normal. Claro, alguns ecossistemas mudam mais rápido do que outros, e acompanhá-los pode parecer uma tarefa titânica, mas concentre-se nas coisas importantes, lembre-se de que você é apenas humano e não pode saber tudo. Portanto, se você precisa aprender alguma coisa, sugiro aprender a aprender.
Eu sei que isso pode parecer bobo, mas talvez o desenvolvedor tenha essa habilidade número um. Devemos aprender a aprender novas habilidades rapidamente. Caso contrário, você corre o risco de obter o rótulo "desatualizado".
É aqui que entram algumas das outras lições deste artigo. Variação, mudança, novos desafios, falta de ego - tudo isso o ajudará a aprender e expandir sua gama de habilidades. Quanto mais você praticar, melhor. Eventualmente, você descobrirá que todos os idiomas são semelhantes. Você começará a ver suas raízes comuns e será capaz de trabalhar com qualquer uma delas. Tudo o que você precisa fazer é ler algumas coisas importantes. Ao longo de sua carreira, você estudará:
- Novos idiomas.
- Novos (e antigos) paradigmas de programação.
- Novas abordagens de trabalho.
- Novas maneiras de resolver problemas.
- Novas maneiras de interagir com companheiros de equipe.
- Novas abordagens para revisar e testar seu código.
Se você não está pronto para ser um estudante eterno, pondere se essa carreira é para você. Observe que eu não disse: "Saia imediatamente", mas considere se você está pronto para abrir sua mente para o aprendizado contínuo.
5. Funciona melhor que o ideal
Como gerente, já ouvi isso muitas vezes. Mas, como desenvolvedores, tendemos a pensar que o código deve ser perfeito antes do lançamento. E isso não é apenas falso, mas potencialmente um problema. A otimização antecipada é um problema porque você acaba gastando muito tempo e esforço em coisas que podem não precisar de otimização. E em algumas situações, ao fazer essa otimização, você faz suposições que quebram a funcionalidade.
Portanto, concentre-se no trabalho a ser feito e no problema que você está tentando resolver. Depois de resolver o problema, teste-o, repita os resultados e veja o que sua equipe pensa sobre sua solução, mesmo se você já puder ver maneiras de melhorá-la. Se você vai passar mais dois dias apenas tornando o código perfeito, mas ele pode entrar em produção agora, é provável que já esteja em produção.
No final, você resolve o problema. Quanto mais rápido você corrigir o problema, melhor para os usuários.
6. Faça o código funcionar e, em seguida, otimize
De acordo com alguns dos pontos anteriores, não caia no buraco negro da otimização inicial. Mesmo se você achar que obterá o código rápido, uma vez que ele for lançado (se isso acontecer), você descobrirá que o efeito de dilatação do tempo é real.
Sua primeira prioridade como desenvolvedor de software escrevendo um novo recurso ou consertando um bug é fazê-lo funcionar, não importa quão feio o código possa parecer ou quão ineficiente a solução possa ser. Se o código funcionar, você acabou de provar que é possível escrever código. Esta é a metade da batalha.
A segunda etapa é a otimização. Esta etapa é opcional. Detalhes que algumas pessoas tendem a esquecer. O tempo que você tem à sua disposição para otimizar seu código depende de muitas variáveis que você às vezes não controla. Portanto, concentre-se em fazer o código funcionar e, em seguida, descubra se você realmente tem tempo para otimizá-lo.
Otimizar cedo significa otimizar seu código conforme você o escreve. Essa é uma prática perigosa porque, ao otimizar, fazemos suposições sobre o tempo de execução, requisitos de dados, requisitos de memória e outros fatores que ainda não vimos em ação. Qualquer uma dessas suposições pode estar errada e, no final, você introduzirá erros em sua lógica.
Pense no fluxo de trabalho do TDD:
- Escreva um teste para entender tudo o que precisa ser feito para sua função (o teste falhará).
- Escreva seu código para que o teste seja aprovado.
- Agora se preocupe em otimizar seu código.
A segunda etapa é necessária. Primeiro você precisa cuidar do teste, o que significa que a função está funcionando. O teste não se importa se você usar três instruções if aninhadas em seus algoritmos. Isso se tornará importante, possivelmente na fase de revisão do código.
7. Os últimos 10% do projeto levam 90% do tempo
Isso é especialmente importante se você trabalha sozinho, mas as equipes também sofrem por não acertar esses pequenos detalhes matemáticos. Qualquer pessoa que tenha concluído um projeto dirá o mesmo (e, francamente, esse não é apenas o caso em nosso setor). Primeiro, você se apressa em muitos detalhes para pensar mais tarde.
E isso é completamente normal. Temos a tendência de nos concentrar principalmente em grandes recursos, deixando pequenos detalhes ou até mesmo bugs conhecidos no final. Mesmo assim, você precisa combatê-los - e aqui aparecem mais 90%. Você deve testar, corrigir o código, testar novamente, ensinar aos usuários como lidar com a solução, enviar a versão final da solução e assim por diante. Claro, tudo depende do contexto, de quem é o seu cliente e de muitos outros fatores, mas sempre há algo. Portanto, lembre-se, quando você acha que está quase terminando o código, provavelmente se esqueceu de algo.
8. Quando você está em uma equipe, você precisa de abstração.
A codificação trata do comportamento das abstrações. Ao abstrair a lógica geral, podemos reutilizá-la em outro lugar, mas no início esquecemos a importância das abstrações. Esta é minha regra pessoal: se o código se repetir em dois lugares, ele é enviado para uma função (método, módulo); Você entendeu a ideia. Se duas repetições parecerem um número pequeno aos seus olhos, lembre-se de que pode haver outros lugares no futuro para aplicar o código que você acabou de abstrair. E abstraindo o código imediatamente, você terá acesso imediato a ele.
A abstração está aumentando. Uma parte da lógica abstrata pode ser usada muitas vezes com o mínimo de esforço, enquanto copia e cola (embora seja fácil de fazer) - quanto mais você a usa, mais esforço é necessário. Pense no que acontecerá se, devido a um bug, você precisar alterar uma parte da lógica que se repete 5 vezes. Para corrigir um bug, você altera literalmente a mesma parte do código 5 vezes.
A mesma lógica se aplica às tarefas diárias. Se você fizer algo mais de uma vez, provavelmente poderá ser automatizado de alguma forma. Esta é a chave para a eficiência, portanto, procure a repetição não apenas em seu código, mas também em suas ações. Se você automatizar uma tarefa que leva 10 minutos por dia, economizará 5 horas por mês.
9. Projetos paralelos são opcionais, mas podem ajudar
Alguns dizem que se você quer ser um desenvolvedor de sucesso, precisa de projetos paralelos. Eu não acho que isso seja verdade. Eu pessoalmente conheço muitos grandes desenvolvedores que só escrevem código no trabalho, "das 9 às 17". Para ser honesto, eu os admiro. Eles são mestres em seu ofício e, em seu tempo livre, fazendo outra coisa, eles aproveitam a vida. Não há absolutamente nada de errado com isso. No entanto, às vezes você precisa de alguma prática extra. Às vezes, você sente que está ficando para trás em relação aos colegas; aqui e projetos paralelos de ajuda.
Não estou falando de uma revolução na indústria - desenvolver uma estrutura com milhões de usuários. Escreva se quiser, mas estou falando sobre copiar os projetos de outra pessoa para aprender com ela. Também estou falando sobre contribuir com projetos de outras pessoas, consertar bugs e adicionar funcionalidades.
Você pode escrever projetos paralelos para experimentar outros aspectos do desenvolvimento que normalmente não tocaria. Se você escreve testes de unidade 8 horas por dia, pode pensar em escrever algo do zero ou desenvolver alguma funcionalidade. Se você está cansado de trabalhar sozinho, contribua para um projeto existente de outras pessoas e experimente o que significa coordenar seu trabalho com outras pessoas. Você pode escrever um projeto paralelo para melhorar seu nível de habilidade abordando os pontos fracos. Mas, novamente, não sinta que precisa trabalhar neles com uma barra de atividades verde do Github para ser considerado um desenvolvedor sério. Isso é simplesmente bobo.
Conclusão
Aqui estão minhas 9 lições difíceis como desenvolvedor nos últimos 18 anos. Espero que, ao compartilhar minha experiência, eu possa lançar alguma luz sobre seu futuro ou carreira atual. Você aprendeu algo mais que gostaria de compartilhar? Eu adoraria ouvir de você nos comentários, gostaria de aprender algo com você.
Outras profissões e cursos