Problemas comuns, soluessimples

Bom, a idia aqui compartilhar algumas lies 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 negcio;
• Lgica/Cdigo;
• Ferramentas e bibliotecas;

Entendimento denegcio

Aqui est algo que considero muito importante para um bom rendimento como desenvolvedor. Pra mim, desenvolvedor deixou de ser h muito tempo "digitador de cdigo", na verdade nunca deveria ser visto s assim, mas o ponto , desenvolver algo sem entender do que se trata, do propsito e dos objetivos, pssimo e pode ocasionar vrias situaes, tais quais: retrabalho, quebra de expectativas na entrega e em alguns casos prejuzo.

Pois bem, o que aprendi at ento que sempre importante entender o que estou fazendo, e pra isso eu pergunto, bastante, de novo, muito bvio n? SIM, mas ainda assim muitas vezes deixamos passar batido. No hesite em buscar respostas na fonte, com o responsvel 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 oua/leia com ateno, vai te poupar l na frente de refazer algo "s" porque entendeu errado, ou na dvida fez da forma que achava melhor sem saber que no era a melhor forma para a tarefa.

Lgica/Cdigo

Sabe aquela pausa pro caf? Quantas vezes foi ela quem me deu o estalo de como solucionar um problema que eu estava enroscado, ento sim, pra essa pausa tambm importante, por muitas vezes quando me vejo patinando pra resolver um problema, uma pausa pra refrescar a cabea 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, no tenha vergonha disso, pra mim no existe pergunta errada, se voc tem dvidas, sua pergunta genuna, ela pode at ser "boba" pra quem j sabe, mas no pra voc. Mas no espere solues prontas, isso no pedir ajuda e no vai te fazer aprender nada \()/

E por ltimo e no menos importante, valorizo muito pair programming, legal o quanto isso pode ajudar na hora de resolver um problema, de encontrar uma soluo, com a perspectiva de outra pessoa, pensando juntos, e isso pode poupar algumas horas muitas vezes. Ok as vezes no vai passar de um rubber duck e tudo bem, no o ideal mas acontece.

Ferramentas e bibliotecas

No item anterior eu digo que toda pergunta vlida certo? E aqui vou eu me contradizer um pouco ou complementar Sim toda pergunta vlida, mas importante ter em mente que se voc tem recursos que podem resolver sua dvida e voc simplesmente sai perguntando ao invs de fazer uso disso, pra mim isso s o caminho mais fcil/preguioso. Mas isso no legal, voc pode interromper, sem necessidade, o raciocnio de algum, 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 documentao, ela existe e no atoa. Stackoverflow bom? Sim claro, mas as vezes to mais simples olhar o repositrio da lib e encontrar nas issues algum passando pelo mesmo problema, ou que j passou por isso e at j tem resposta pra isso, ento, mesmo sendo bvio, lembre-se disso, eventualmente voc vai cair em algum post de stackoverflow que vai te mandar exatamente pra uma issue do repositrio.

E se voc no encontrar nada? Bom, pergunte, e use as issues pra isso tambm, assim voc ainda colabora com a comunidade!

Bnus

No bem sobre um problema que eu quero falar aqui mas sim de algo que ajuda a evitar problemas futuros, que a documentao, que muitas vezes negligenciada e no deveria. Duas perguntas sobre isso: Por qu? e Pra quem?

Por qu? Voc ganha tempo, voc e seu time. A depender de qual extenso um projeto, a documentao pode ser til inclusive pra quem tem todo o contexto do projeto, aquele detalhe mais especfico, bem documentado, te ajuda a no se perder. Alm disso, uma boa prtica e te deixa treinado/preparado para fazer o mesmo ao colaborar na comunidade open source, uma biblioteca mal documentada dificilmente vai pra frente, fica difcil atingir muita gente se as pessoas no conseguem usar direito sua biblioteca, n?!

Pra quem? Alm de ser timo para voc e para o time, importantssimo para novos membros do time, ajuda no onboarding, consequentemente vai ser algum que vai poder colaborar com o projeto mais rpido. E tem mais, imagine que voc mude de projeto dentro da empresa, e deixa um projeto mal documentado para trs, 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 no seria um problema.