Análise de erros comuns cometidos por programadores novatos, pt. 2

Olá novamente a todos! Continuaremos a considerar os problemas que um programador jovem e imaturo pode enfrentar em seu primeiro emprego. A primeira parte pode ser encontrada aqui . Vamos continuar.

13. Não cumprimento das diretrizes de estilo de codificação.

As equipes de desenvolvimento geralmente seguem um único estilo de codificação. Ou seja, os desenvolvedores individuais seguem certas regras escritas ou não escritas para garantir que seu estilo de codificação não seja diferente dos outros. Não tente se diferenciar com um estilo de codificação distinto: isso não faz você parecer bem. Se você é novo no projeto, você deve descobrir imediatamente se existe alguma documentação que defina diretrizes gerais de estilo de codificação. Pode haver alguns arquivos de estilo para seu projeto específico que você precisa solicitar e importar para seu IDE (por exemplo, IntelliJ IDEA), para que o IDE possa fornecer as dicas de estilo de codificação corretas. Por exemplo, o estilo pode exigir o uso do modificador final sempre que possível. O arquivo de estilo permite que o IntelliJ IDEA destaque em amarelo quaisquer variáveis ​​onde isso não for respeitado.

14. Desanimar com os erros

Erros são algo com os quais você precisa se acostumar. Eles foram, são e serão. Não importa se você é iniciante ou um arquiteto sério, você sempre cometerá erros. A quantidade e a gravidade dos seus erros podem mudar, mas eles o acompanharão ao longo de sua carreira. Às vezes você luta para fazer algo funcionar a semana toda, comete um erro, e então é sexta-feira à noite e você foge para casa como um cachorro espancado, sem conseguir consertar aquele maldito erro. É uma sensação indescritível, mas não algo que deva desanimar. Afinal, outra diferença importante entre um desenvolvedor experiente e um novato é como ele lida com os erros. Desenvolvedores experientes não os levam a sério, mas os consideram como experiência. Ninguém irá repreendê-lo por cometer um erro. Isso é normal – todo mundo às vezes se mete em confusão. Novamente, você pode pedir ajuda aos colegas. E não se esqueça de pessoas como gerentes de projeto (PM). Se você estiver preso em alguma coisa, entre em contato imediatamente com o PM. Ele ou ela pode ajudá-lo a encontrar alguém que seja especialista na área problemática. Em qualquer caso, o PM precisa ser mantido informado sobre quaisquer problemas encontrados no projeto. É função do PM ajudar a resolver todos os tipos de problemas, incluindo comunicação e interações entre os membros da equipe. Resumindo: erros acontecem , não deixe que eles matem você. Em vez disso, aceite-os como um desafio para você e suas habilidades. No final, é apenas parte do trabalho.

15. Falha na implementação da segurança de thread.

Nada de bom é criado facilmente. Todo desenvolvedor precisa entender que escrever uma funcionalidade específica, seja ela um módulo ou apenas um método, requer um plano sobre o que será feito e como. Via de regra, ao desenvolver funcionalidades de qualquer complexidade, você precisa seguir o seguinte procedimento: Muitos erros que surgem no código escrito por programadores novatos estão relacionados às etapas deste procedimento. Claro, você não pode descartar que há momentos em que você precisa escrever código rapidamente, sem hesitação, assim que vir a tarefa. Mas isso geralmente só funciona para certas tarefas e métodos menores cuja implementação é óbvia e não requer muita reflexão. O procedimento de desenvolvimento mencionado acima é mais adequado para tarefas complexas e grandes que podem ser divididas em subtarefas. Não é uma boa ideia começar a escrever código sem entender claramente o que você deseja escrever. Primeiro, você precisa pensar e planejar tudo com cuidado. Também pode ser útil pegar uma folha de papel e um lápis e tentar esboçar suas ideias de implementação. Sempre faço isso ao planejar funcionalidades complexas. Um programador passa a maior parte do tempo não escrevendo código, mas pensando em como estruturar a funcionalidade necessária . Na verdade, depois de planejar e pensar sobre tudo, escrever código se torna um processo puramente mecânico e descomplicado.

16. Excesso de trabalho

do filme "Clube da Luta" (1999) Talvez todo iniciante pense que, trabalhando noite adentro, ele começará a realizar mais tarefas e terá mais responsabilidades. Eu também pensava assim, mas não mais. Percebi que chega um ponto que você atinge o seu limite, que você deixa de conseguir pensar adequadamente. Você começa a ficar muito chato e a sentir uma névoa mental. Leva uma hora para fazer coisas que você poderia fazer em 10 minutos se sua mente estivesse fresca. Quase sem exceção, depois de cruzar essa linha do cansaço, você encontra algum problema que parece intransponível. Mas quando você chega para trabalhar na manhã seguinte, você resolve o problema num piscar de olhos. Então, quando você sentir que chegou a esse ponto, não fique acordado até tarde. Vá para casa e descanse bem. Afinal, se você ficar em sua mesa até tarde da noite, não apenas não alcançará resultados particularmente notáveis ​​durante essas horas de tormento, mas ao mesmo tempo corre o risco de um descanso insuficiente (insuficiente) antes do próximo dia de trabalho, quando você ' vou estragar mais uma vez. Pense na sua saúde: vale a pena prejudicá-la assim no início da carreira? Eu acho que não. É um período caro para ficar doente. E pense no seu empregador. Ao trabalhar demais, você piora as coisas não só para você, mas também para seu empregador. Quem precisa de um funcionário que está sempre com sono e que, devido à exaustão, não consegue implementar o algoritmo de classificação mais simples? Sim, sem dúvida há momentos em que você tem um prazo apertado, momentos em que tudo deu errado e momentos em que - e este é o meu favorito - "precisamos disso para ontem". Mas essas situações geralmente são raras e, depois de superá-las, você precisa sentar e considerar cuidadosamente como elas poderiam ter acontecido e como evitá-las no futuro.

17. Negligenciar o domínio do inglês

Muitos aspirantes a desenvolvedores priorizam a tecnologia de aprendizagem e adiam o aprendizado de inglês. Este é um erro grave, já que muitas vezes um programador é perfeito para uma posição júnior (ou estágio), mas não consegue o emprego devido ao fraco conhecimento do inglês. Sim, claro, há casos em que você consegue sobreviver sem o inglês. Via de regra, essas pessoas são contratadas localmente para projetos em países que não falam inglês. Mas as empresas locais não pagam os mesmos salários que as empresas estrangeiras. E será muito, muito difícil conseguir um salário decente, mesmo com o tempo. É por isso que você não deve ignorar o inglês. Em vez de deixar o inglês em segundo plano, você precisa aprendê-lo para se concentrar imediatamente em projetos de língua inglesa. Na verdade, pense nisso por um minuto – o inglês é atualmente a língua dos negócios internacionais. Qualquer que seja o país para onde você vá, você poderá encontrar um idioma comum com outras pessoas se souber inglês. O mesmo se aplica aos projetos de desenvolvimento. Não importa onde o projeto está baseado: Alemanha, Austrália, França ou outro lugar - toda a comunicação, todas as tarefas, documentação, etc. serão em inglês. E se você pensar um pouco, vai concordar que isso é muito conveniente, certo?

18. Busca por tecnologia moderna

À medida que os desenvolvedores iniciam seu caminho, eles geralmente tentam se manter atualizados com as tecnologias mais recentes. Essa é a coisa certa a fazer? Por um lado, sim: as mais recentes tecnologias, projetos... Mas vale a pena fazer disso uma prioridade máxima? Talvez seja melhor buscar o "kit de ferramentas clássico" para um especialista em sua área? Novo é certamente bom, mas você não deve se esquecer das tecnologias fundamentais da sua área. E só então, depois de adquirir um pouco de experiência e conhecimento profundo do básico, você poderá tentar algo novo. Considere também que as novas tecnologias podem ser superiores em alguns aspectos subtis, mas podem perder vantagens noutros. Até que um desenvolvedor novato entenda essas vantagens e desvantagens, é melhor ficar com as soluções testadas pelo tempo. Por exemplo, se um programador estiver desenvolvendo um aplicativo que interage com alguns dados, não se apresse em usar a solução NoSQL mais recente simplesmente porque está na moda. Um banco de dados SQL comum e comprovado (MySQL, PostrgreSQL, etc.) provavelmente possui documentação detalhada e soluções no StackOverFlow para quaisquer problemas potenciais :)

19. Aprender várias tecnologias e/ou idiomas diferentes ao mesmo tempo

Falamos acima sobre iniciantes tentando aprender tecnologias da moda. Bem, que tal estudar simultaneamente muitas tecnologias ou idiomas? Obviamente, você já ouviu falar de programadores que conhecem mais de uma linguagem de programação e dominam muitas tecnologias. Mas vou salientar rapidamente que essas pessoas estão longe de ser novas em programação. São pessoas com muitos anos de experiência. Eles dominaram sua tecnologia original e foram cada vez mais longe. Os iniciantes que tentam dominar tudo de uma vez devem lembrar o excelente provérbio: "persiga duas lebres e não pegará nenhuma delas". A consequência pode ser que você não domine bem nenhum assunto, mas apenas aprenda os assuntos superficialmente. Haverá mais demanda por um especialista que conheça profundamente um único idioma do que por alguém que saiba um pouco de tudo. Portanto, se você deseja conhecer muitas linguagens e tecnologias, precisa abordá-las com sabedoria. Para começar, você precisa escolher uma linguagem básica que deve aprender profundamente. E só então você deverá começar a estudar outras áreas. Por exemplo, torne-se um guru de Java e aprenda Python como segunda linguagem. Depois disso, você poderá aprender algo sobre react/angular para o frontend. Nesse caso, estamos falando de tecnologias que não são intercambiáveis, como C# e Java, mas sim complementares, ampliando suas oportunidades de carreira. Mas repito novamente: você não deve tentar aprender tudo de uma vez. Você precisa ir sequencialmente. Pegue uma lebre de cada vez, por assim dizer.

20. Metas formuladas incorretamente

Como você define metas para si mesmo? Torne-se um desenvolvedor legal? Lembre-se disso de uma vez por todas: você precisa definir metas concretas, ou em outras palavras – metas alcançáveis. Do que estou falando? Por exemplo, você estabeleceu a meta: “Quero ficar rico”. Mas como você saberia se alcançou esse objetivo? Ou como você mede o quão perto está de alcançá-lo? Bom, se você definir a meta “Quero ganhar um milhão de dólares”, isso fica um pouco mais claro, não é? Depois de ganhar $ 10.000, você estará $ 10.000 mais perto de sua meta - faltam apenas $ 990.000. Ainda há muito a ser conquistado, mas você poderá sentir seu progresso e entender onde está a linha de chegada, assim estará motivado para continuar. Em termos de carreira, que tal estabelecer uma meta mais tangível? Por exemplo: quero me tornar um líder de equipe. Ou um desenvolvedor sênior. Ou, em última análise, um arquiteto. Bem, toda grande tarefa precisa ser dividida em pequenas subtarefas. Você não se torna um líder de equipe no início de sua carreira. Estabeleça prazos, se possível e apropriado, e concentre-se no estágio atual.

1. Se estamos falando em se tornar um desenvolvedor sênior , então o primeiro pequeno objetivo seria encontrar um estágio ou emprego como desenvolvedor júnior em uma empresa.
2. A seguir, você pode definir metas para aprofundar seu conhecimento sobre determinadas tecnologias. Em relação ao Java, você pode se preparar para a certificação Nível 1 da Oracle. Estabelecemos um prazo para a nossa preparação e enfrentamos o objetivo.
3. Então, por exemplo, você pode definir uma meta de melhorar seu inglês em um nível (digamos, de B1 a B2). Elaboramos um plano de aprendizagem, agendamos o horário e avançamos em direção ao objetivo.

É assim que podemos atingir nosso objetivo final passo a passo (ao mesmo tempo em que ganhamos experiência em desenvolvimento de software).

21. Teoria sem prática

É fato indiscutível que nos tornamos melhores profissionais estudando novas tecnologias e nos aprofundando em temas que já conhecemos. Mas no início da jornada, os desenvolvedores raramente percebem que devorar livros técnicos um após o outro não traz grandes benefícios se o novo conhecimento não for testado na prática. Eu pessoalmente já me deparei com isso mais de uma vez. Se você dedica muito tempo a um livro, mas não pratica nada com ele, então quase todo o conhecimento recém-adquirido será esquecido: você ficará apenas com uma vaga lembrança geral de como tudo funciona. O resultado é muito tempo perdido sem nenhum resultado tangível. Por que deveríamos perder nosso tempo? A vida não dura para sempre. A conclusão é que quando você está aprendendo uma nova tecnologia, você não deve se prender à teoria: escreva os exemplos dados paralelamente à sua leitura, experimente a nova tecnologia. Esta é a única maneira de fazer com que seu cérebro retenha as informações. Sim, você consumirá novos materiais mais lentamente, mas assimilará significativamente mais o que lê. Além do mais, se você dominar bem uma tecnologia, a próxima será ainda mais fácil de dominar (assim como acontece com o aprendizado de idiomas).

22. Perfeccionismo excessivo

A maioria dos desenvolvedores são perfeccionistas: pessoas que buscam a perfeição. Isso significa que o código deles também deve ser perfeito. Portanto, seu código foi escrito, testado, ajustado e parece que é hora de enviá-lo ao branch principal. Mas você ainda não está satisfeito com o código, então começa a torcê-lo de um jeito ou de outro, gastando muito tempo nesse esforço. E neste caso, o tempo é o dinheiro do seu cliente. Programadores iniciantes são mais suscetíveis a essa busca pela perfeição. Desenvolvedores experientes estão acostumados com a sensação de que o código nunca será perfeito e que deveriam tentar escrevê-lo melhor. Mas ao mesmo tempo não vão a extremos no esforço de se aproximarem do “ideal”. Portanto, lembre-se de aprender como alcançar um meio-termo: não de maneira descuidada e sem tentar recriar a Mona Lisa em código.

23. Falha em pensar em arquitetura

Deixe-me repetir: você não deve escrever códigos confusos. Além da legibilidade e do desempenho, você também precisa pensar em como seu código pode afetar o restante da sua aplicação como um todo. Por exemplo, quão difícil será estender seu código e assim por diante. O problema é que os desenvolvedores iniciantes, devido à falta de experiência, podem não perceber imediatamente como suas novas funcionalidades afetarão o aplicativo no futuro. Essa previsão certamente requer muita prática para ser desenvolvida. Mas o que então os novatos devem fazer? Não escrever código? Nestas situações, vários paradigmas de programação vêm em nosso auxílio. Por exemplo, princípios SOLID ou vários padrões de design que podem transmitir práticas úteis para você. Estes paradigmas também devem ser tratados com cautela e não levados demasiado longe. Mas como você determina o ponto quando está exagerando? É aqui que uma revisão de código feita por um colega mais experiente o ajudará. Ao trazer um olhar novo e objetivo, seu colega pode apontar a direção certa.

24. Síndrome do Impostor

A síndrome do impostor é um fenômeno psicológico no qual uma pessoa é incapaz de atribuir suas realizações a qualidades, habilidades e esforços pessoais. Apesar da evidência externa do seu desempenho consistente, as pessoas suscetíveis a esta síndrome continuam a acreditar que são fraudes e não merecem o sucesso que alcançaram. Muitos desenvolvedores têm essa síndrome. Talvez nos dê a persistência que nos impulsiona para novos conhecimentos e tecnologias. Você olha para colegas mais experientes e talentosos e se sente desconfortável, como se não valesse o seu salário. Acredite em mim, isso não é verdade. Existem e sempre haverá desenvolvedores melhores ou piores que você. Alguém olha para você e se sente desconfortável, pensando que nunca se tornará como você. E isso é normal. O feedback da sua equipe, revisões de código e discussões ajudam a combater um pouco esse sentimento. Acredite, a opinião de alguém de fora irá surpreendê-lo agradavelmente, mas somente se você realmente não negligenciar seu trabalho e desenvolvimento profissional. Se você negligenciar essas coisas, então escolheu a profissão errada. Nesta profissão, você precisa estar sempre aprendendo algo novo e buscando o melhor. Mas acho que as pessoas reunidas aqui estão longe de serem preguiçosas. Em vez disso, as pessoas aqui estão avançando firmemente em direção ao seu objetivo querido. Se isso descreve você, então você não tem nada a temer.

25. Raramente fazendo commits

Lembre-se de realizar commits com frequência! Não a cada meia hora, veja bem. Se você passar uma semana implementando alguma funcionalidade, então você não deverá realizar um commit na sexta à noite, mas, digamos, cinco commits. Quase todas as tarefas grandes podem ser divididas em tarefas menores por conveniência. Então você conclui essas tarefas menores e se compromete. E não se esqueça de enviar esses commits para o servidor remoto imediatamente. Caso contrário, você pode fazer commits durante toda a semana e então seu computador apresentar uma falha de hardware na sexta-feira na hora do almoço, e então você perderá uma semana inteira por nada! Mas se você carregou seus commits para um servidor remoto, basta puxar o branch com seu último commit para outro computador e continuar trabalhando. Mais uma coisa: não envie novas funcionalidades para um servidor de produção ativo na sexta à noite. Apenas confie em mim. Você não precisa disso. É altamente provável que erros inesperados venham à tona e você passe o fim de semana corrigindo-os. E isso não é divertido. Você precisa descansar no fim de semana. Acho que é tudo por hoje. PS Uma última dica: escreva muito código. PPS Escreva uma quantidade INSANAMENTE grande de código, porque essa é a única maneira de ganhar a experiência necessária.