Alguns desenvolvedores são melhores que outros. De fato, há uma distribuição estatística: Alguns são absolutamente brilhantes, alguns são bons, a maioria é pelo menos competente, alguns são pouco competentes e alguns são realmente terríveis.
Dito isto, a diferença entre um bom programador e um ruim não é necessariamente uma habilidade de codificação. De fato, é algo ainda mais básico; Maus hábitos. E maus hábitos são difíceis de romper na vida e no trabalho.
Dito isto, nós, desenvolvedores, muitas vezes podemos adotar maus hábitos enquanto enfrentamos códigos que acabam nos impedindo de alcançar todo o nosso potencial. Embora alguns hábitos possam nos ajudar a acelerar nosso trabalho, outros (como ficar comendo docinho de caju açucarado enquanto digito...) podem prejudicar nossos negócios e nossa vida pessoal.
E muitas vezes desconhecemos nossos maus hábitos e tudo o que precisamos é de alguém para esclarecer sobre eles. Como a vida, a programação não tem regras rígidas e rápidas. Às vezes você voa para ganhar.
Vamos falar sobre alguns maus hábitos de programação dos quais você deve se livrar o mais rápido possível.
Meu código é o melhor.
Friedrich Nietzsche acertou em cheio quando disse.
“Sempre que subo, sou seguido por um cachorro chamado ‘Ego’.”
O tipo de pessoa que todas as equipes precisam são pessoas humildes, famintas e inteligentes: humilde é um pequeno ego, concentrando-se mais em seus colegas do que em si mesmos. Com fome, o que significa que eles têm uma ética de trabalho forte, estão determinados a fazer as coisas e contribuem da maneira que puderem. Inteligente, ou seja, não intelectualmente inteligente, mas interior pessoalmente inteligente.
Não critique o código de outros, ele pode ser o seu em destaque. Tente fazer observações objetivas e profissionais, mas não julgue. Seja humilde e tente aprender com todos ao seu redor.
Lembre-se sempre, seu ego é um obstáculo ao seu trabalho. Se você começa a acreditar na sua grandeza, é a morte da sua criatividade. Seu aprendizado termina no dia em que você começa a acreditar que não há mais nada a aprender.
Alguns desenvolvedores diriam: “Eu posso consertar isso em um instante.”
Angela Duckworth disse uma vez.
“Não há atalhos para a verdadeira excelência.”
Faça um favor a si mesmo. Permita-se tirar o máximo proveito da sua vida. Se você está gastando todo o seu tempo esfregando os cantos com uma escova de dentes, está meio que perdendo o objetivo. Tomar atalhos não significa atalho para o resultado final.
Tomar atalhos é muito tentador, todo mundo já fez. Na verdade, existem situações em que são necessárias, mas no geral são perigosas, muito perigosas e devem ser evitadas. Um atalho que der errado pode economizar algumas horas, mas pode causar meses de dor e perda adicional de reputação.
Leve o meu conselho a sério. Aprendi da maneira mais difícil que pegar atalhos e viver de graça não é viver de graça.
Um dos principais maus hábitos: Lembro-me de tudo. Não preciso documentar.
Dick Brandon bateu na unha quando ele observou.
“Documentação é como sexo; quando é bom, é muito, muito bom, e quando é ruim, é melhor que nada.”
A documentação é o óleo de mamona da programação. Os gerentes pensam que é bom para programadores e programadores gostam de odiar isso!
Mas dito isso, ótimos desenvolvedores, fazem dela uma parte intrínseca de sua rotina diária.
Eles percebem que, como em qualquer função comercial, as equipes de desenvolvimento de software estão sempre em movimento. Os programadores podem mudar de emprego, passar de um departamento para outro ou se aposentar. No pior cenário, doença, lesão ou morte podem afastar os membros da equipe quando você menos espera.
As idades do código também. Os desenvolvedores podem facilmente esquecer como seu próprio código funciona se não o tocarem há um ano ou mais.
Em qualquer um desses cenários, ter acesso a documentos de design, especificações de API, páginas de manual e comentários de código pode significar a diferença entre um produto de remessa e um prazo final.
E é essa atitude que os torna um ativo valioso para a equipe. Você não se torna “insubstituível” intencionalmente não documentando nada. Tudo o que você acaba se tornando um passivo “irreparável” para sua equipe.
Não era eu!
Bruce Lee disse com razão.
“Erros são sempre perdoáveis, se alguém tiver a coragem de admiti-los”
Talvez essa afirmação acima não possa ser subestimada e seja uma das características mais importantes de um desenvolvedor realmente bom.
Sempre temos uma desculpa… É como se estivéssemos dizendo que, em condições normais, nunca cometeríamos um erro, o que honestamente é muito difícil de acreditar.
Os desenvolvedores ruins culpam os clientes por não usarem o produto “corretamente“. Um desenvolvedor ruim falha em assumir a propriedade e a responsabilidade por todo o produto e bugs. Eles garantem que todos saibam exatamente quem foi o responsável quando um bug foi criado por outra pessoa.
E o que exatamente é alcançado colocando a culpa? Nada mesmo.
Tendo uma atitude saudável, onde podemos dizer algo como: “Sim, desculpe, agora precisamos fazer isso para corrigir esse problema, minha culpa” ajudará você a construir uma reputação e ser mais bem considerado pelos seus colegas.
Quanto mais cedo você admitir seus erros, mais tempo terá para aprender e corrigir o mesmo. Simples assim!!!
O seu “Concluído” não está concluído.
Rick Lemons observou corretamente quando ele disse.
“Não faça o usuário fornecer informações que o sistema já conhece.”
Se a programação fosse sexo, haveria muitos computadores insatisfeitos. Você simplesmente não pode entrar, fazer as coisas no meio do caminho e depois adormecer. Um dos conceitos que eu acho que você está enfrentando é o conceito de “Concluído“.
Lembre-se de que significa feito: testado e aprovado pelo usuário de acordo com seus requisitos. Não é feito do seu lado para ser considerado feito.
Um bom desenvolvedor está ansioso para aprender coisas novas. Em primeiro lugar, eles se esforçam para entender como todas as peças da arquitetura trabalham juntas e em que estado estão. Em segundo lugar, questionam o design e as ideias por trás dos recursos para resolver uma solução. E em terceiro lugar, desenvolvedores entendem o que faz uma boa experiência do usuário.
Um desenvolvedor ruim, por outro lado, está ligado à sua tecnologia favorita. Eles acham que um único método ou processo é o “ideal” e que a experiência e a situação do usuário nunca devem conduzir decisões. Por mais que tragam dependências desnecessárias para o projeto para atender às suas preferências.
Últimos Pensamentos. Então, qual é a única palavra que resume tudo aqui?
A resposta curta é Atitude. Livre-se dos maus hábitos!
Certamente ter uma ótima atitude é melhor do que ter qualquer número de anos de experiência a qualquer dia.
Portanto, apenas trabalhar não é suficiente, você deve de fato ter a atitude certa no trabalho e, em vez de ter a habilidade certa, a atitude certa é muito mais importante.
Ter uma atitude boa e positiva, juntamente com um pensamento positivo, no trabalho refletirá no que você faz e o tornará um funcionário mais produtivo. Isso pode determinar o quão bem você realiza seus projetos e também como os outros o percebem. Uma boa atitude é contagiosa. Carrega o local de trabalho.
Como Zig Ziglar resumiu, com razão.
“Sua atitude, não sua aptidão, determinará sua altitude.”
O texto original desse post (com adaptações) foi escrito por Ravi Shankar Rajan e você pode ler o conteúdo original aqui (em inglês).
