Bom, a idéia aqui é compartilhar algumas lições e aprendizados que tirei ao longo dos anos trabalhando como desenvolvedor, e que boa parte de quem ler isso aqui vai achar bem óbvio, e É, mas muitas vezes no meu dia a dia eu esqueci de pensar no óbvio na hora de resolver um problema e acabei gastando um tempo a mais por pura teimosia.
Quero abordar aqui alguns problemas comuns e como eu os classifico:
- Entendimento de negócio;
- Lógica/Código;
- Ferramentas e bibliotecas;
Entendimento de negócio
Aqui está algo que considero muito importante para um bom rendimento como desenvolvedor. Pra mim, desenvolvedor deixou de ser há muito tempo "digitador de código", na verdade nunca deveria ser visto só assim, mas o ponto é, desenvolver algo sem entender do que se trata, do propósito e dos objetivos, é péssimo e pode ocasionar várias situações, tais quais: retrabalho, quebra de expectativas na entrega e em alguns casos prejuízo.
Pois bem, o que aprendi até então é que é sempre importante entender o que estou fazendo, e pra isso eu pergunto, bastante, e de novo, muito óbvio né? SIM, mas ainda assim muitas vezes deixamos passar batido. Não hesite em buscar respostas na fonte, com o responsável pelo projeto/produto, nem sempre você vai conseguir cobrir tudo em uma planning ou refinamento, releia os requisitos da tarefa atentamente e se for preciso pergunte e ouça/leia com atenção, vai te poupar lá na frente de refazer algo "só" porque entendeu errado, ou na dúvida fez da forma que achava melhor sem saber que não era a melhor forma para a tarefa.
Lógica/Código
Sabe aquela pausa pro café? Quantas vezes foi ela quem me deu o estalo de como solucionar um problema que eu estava enroscado, então sim, pra essa pausa também é importante, por muitas vezes quando me vejo patinando pra resolver um problema, uma pausa pra refrescar a cabeça ajuda, volto para o problema mais calmo, me ajuda a ter uma perspectiva diferente para tentar resolver.
Por muitas vezes tive vergonha de perguntar e insisti em tentar resolver algo sozinho. Se você trabalha em equipe, saiba pedir ajuda, saiba perguntar, não tenha vergonha disso, pra mim não existe pergunta errada, se você tem dúvidas, sua pergunta é genuína, ela pode até ser "boba" pra quem já sabe, mas não é pra você. Mas não espere soluções prontas, isso não é pedir ajuda e não vai te fazer aprender nada ¯\(ツ)/¯
E por último e não menos importante, valorizo muito pair programming, é legal o quanto isso pode ajudar na hora de resolver um problema, de encontrar uma solução, com a perspectiva de outra pessoa, pensando juntos, e isso pode poupar algumas horas muitas vezes. Ok as vezes não vai passar de um rubber duck e tudo bem, não é o ideal mas acontece.
Ferramentas e bibliotecas
No item anterior eu digo que toda pergunta é válida certo? E aqui vou eu me contradizer um pouco ou complementar… Sim toda pergunta é válida, mas é importante ter em mente que se você tem recursos que podem resolver sua dúvida e você simplesmente sai perguntando ao invés de fazer uso disso, pra mim isso é só o caminho mais fácil/preguiçoso. Mas isso não é legal, você pode interromper, sem necessidade, o raciocínio de alguém, pra perguntar algo que você já tinha acesso a resposta, é aí que quero chegar.
Para uma linguagem, alguma ferramenta ou biblioteca, sempre se atente a documentação, ela existe e não é atoa. Stackoverflow é bom? Sim claro, mas as vezes é tão mais simples olhar o repositório da lib e encontrar nas issues alguém passando pelo mesmo problema, ou que já passou por isso e até já tem resposta pra isso, então, mesmo sendo óbvio, lembre-se disso, eventualmente você vai cair em algum post de stackoverflow que vai te mandar exatamente pra uma issue do repositório.
E se você não encontrar nada? Bom, pergunte, e use as issues pra isso também, assim você ainda colabora com a comunidade!
Bônus
Não é bem sobre um problema que eu quero falar aqui mas sim de algo que ajuda a evitar problemas futuros, que é a documentação, que muitas vezes é negligenciada e não deveria. Duas perguntas sobre isso: Por quê? e Pra quem?
Por quê? Você ganha tempo, você e seu time. A depender de quão extenso é um projeto, a documentação pode ser útil inclusive pra quem tem todo o contexto do projeto, aquele detalhe mais específico, bem documentado, te ajuda a não se perder. Além disso, é uma boa prática e te deixa treinado/preparado para fazer o mesmo ao colaborar na comunidade open source, uma biblioteca mal documentada dificilmente vai pra frente, fica difícil atingir muita gente se as pessoas não conseguem usar direito sua biblioteca, né?!
Pra quem? Além de ser ótimo para você e para o time, é importantíssimo para novos membros do time, ajuda no onboarding, consequentemente vai ser alguém que vai poder colaborar com o projeto mais rápido. E tem mais, imagine que você mude de projeto dentro da empresa, e deixa um projeto mal documentado para trás, o qual você tem bastante conhecimento, eventualmente isso vai te "assombrar" e você vai ter que parar pra resolver/ajudar em algo que se tivesse bem documentado não seria um problema.
Top comments (0)