O que fazer quando se depara com tarefas de programação que você nunca fez?

Comecei minha carreira como desenvolvedor .NET há 3 meses e, após um longo plano de treinamento em diversas tecnologias, padrões e conceitos, os desenvolvedores que estavam me supervisionando decidiram que estou pronto para participar de um dos muitos projetos que a empresa lida.

Estou muito animado por finalmente poder começar a codificar. A equipe na qual eu integrei é bastante pequena por enquanto, porque estava começando com um novo projeto, o que é ótimo porque me envolvo em todo o ciclo de vida do projeto. É um projeto de SPA baseado na Web com um backup que usa a API da Web ASP.NET MVC / ASP.NET e no front-end a estrutura Durandal e as bibliotecas relacionadas.

Meu problema é que, depois de me reunir com meus colegas e estabelecer as tarefas e estimativas para o próximo mês, me encontro em uma posição que não sei se sou capaz de assumir alguma das tarefas.

Nunca realizei nenhuma das tarefas criadas e não sei como devo proceder.

Por exemplo, uma das tarefas criadas é criar um mecanismo genérico de tratamento de erros para todo o aplicativo.

Como se costuma proceder diante de tarefas que nunca realizou?

Há várias coisas que você pode e deve fazer para se preparar para a tarefa:

• Pense no problema e desenhe alguns diagramas. Certifique-se de saber qual é o problema que você está tentando resolver.
• Faça uma pesquisa sobre o que você está tentando fazer. A internet é uma fonte valiosa de informação. Não estou dizendo perguntar ao Stack Overflow - estou pesquisando como outras pessoas já resolveram um problema como o seu ou o abordaram. Foi o que o google criou: "Tratamento de exceções como uma preocupação abrangente do sistema" . Pessoalmente, eu sempre tento aprender com os outros.
• Por fim, e isso pode ser o mais importante, fale com as outras pessoas da sua equipe para obter mais esclarecimentos e orientações sobre o que fazer. Eu sempre quero ver novos engenheiros pedirem orientação em projetos.

Não saber como fazer algo nunca terminará realmente. Todos os dias encontro problemas que nunca havia enfrentado antes. Ter a capacidade de descobrir como resolver novos problemas é extremamente importante. Mesmo problemas antigos nunca são totalmente antigos - na programação, quase sempre há uma nova reviravolta ou uma solicitação para que sua solução funcione de uma maneira nova ou diferente.

É por isso que sou engenheiro; Eu amo descobrir coisas novas.

Nunca pare de aprender coisas novas. Aprender é o que faz você melhorar.

Não existe uma solução perfeita, mas algumas coisas que podem ajudar:

• Divida as tarefas nas menores unidades possíveis - divida-as até ter o que pode fazer.

• Repita a tarefa ou o problema imediato em questão para garantir que você realmente o entenda. Então faça alguma análise e repita.

• Escolha a tarefa mais simples primeiro, mesmo que pareça simples demais para dar impulso . Algumas pessoas preferem a tarefa mais difícil, então o 'trabalho duro' fica fora do caminho. Descobri que a 'tarefa mais simples' geralmente funciona melhor, pois você está apenas buscando um momento e já vi o primeiro mais difícil levar os projetos a estagnar antes que eles tenham um impulso real.

• Peça ajuda para selecionar a tarefa e a abordagem corretas para começar.

• Procure um mentor que possa fornecer feedback constante (idealmente diariamente) por uma semana ou duas.

• Faça muitas perguntas, mas concentre-se em ser educado com seus colegas de equipe. Sempre pergunte se eles têm tempo e preste atenção aos sinais verbais e não verbais usuais de que eles não têm tempo naquele momento.

• Mantenha uma lista contínua de problemas que você está enfrentando e, em seguida, no scrum diário ou em um horário regular de sua escolha, analise-os com outras pessoas.

• Não tenha medo de fazer as perguntas mais básicas. É difícil contestar as suposições de outras pessoas, mas se você não puder prosseguir com o que recebeu, precisará questionar novamente.

• Se você conhece o objetivo, faça o máximo que puder até ficar preso e, em seguida, poste o progresso e a pergunta no Stack Overflow.

Claro que você não tem idéia de como escrever um "mecanismo de erro genérico". Ninguém sabe como escrever um "mecanismo de erro genérico" até que alguns requisitos sejam definidos. Parece que tudo que você tem é a noção de alguém de que um "mecanismo de erro genérico" é necessário de alguma forma para iniciar este projeto.

Pessoalmente, eu recomendaria essa noção. Escrever qualquer coisa "genérica" ​​antes de implementar os requisitos reais do usuário é quase sempre uma perda de tempo. E, como é genérico , por definição, não é específico para sua empresa ou aplicativo, portanto, provavelmente já existe algo disponível que atenderá cerca de 95% de suas necessidades.

Mas como você é o membro júnior, recuar pode não ser uma ótima idéia. Portanto, você precisa conversar com as pessoas que pensam que precisam de um "mecanismo de erro genérico" e descobrir quais serviços eles esperam que esse mecanismo forneça. Em seguida, pesquise na rede para ver se algo já escrito será suficiente. Se você encontrar algo, proponha simplesmente usá-lo. Eles provavelmente não concordam, porque quem pede um "mecanismo de erro genérico" provavelmente está sofrendo de um caso grave de não-inventado aqui.

Se isso falhar, o próximo passo é definir uma interface para o mecanismo de erro e aprová-lo pelas partes interessadas. Depois disso, a implementação provavelmente será trivial.

=================

PS Existem alguns programadores que pensam que o caminho para iniciar qualquer projeto é escrever uma "plataforma" para fornecer todos os serviços comuns que serão necessários pelos módulos de aplicativos. Isso geralmente se traduz em meses de trabalho trivial, reinventando coisas já prontamente disponíveis gratuitamente. Até atingir os limites de desempenho das soluções disponíveis, não há razão para escrever serviços de "plataforma". Também não há motivo para escrever wrappers nas APIs existentes. Se você refatorar continuamente, o invólucro exato exigido pelo seu aplicativo aparecerá magicamente.

Eu acho que você está sofrendo mais de ansiedade do que um déficit de habilidade. Em algum momento, não era tudo novo? Você já recebeu uma tarefa e não conseguiu resolvê-la até certo ponto? Você é pago para descobrir as coisas.

Utilize sua equipe - Se você estiver em uma boa equipe, poderá pedir ajuda. Há coisas que você saberá que nem os mais idosos saberão. Pedir ajuda não é um sinal de fraqueza (não é mais do que correr para algum site de perguntas).

Pesquisa - Uma pesquisa na Web sobre tratamento genérico de erros não resultou em nada? Você pode não encontrar uma solução inteira. Você precisará trabalhar nele e ajustá-lo ao seu aplicativo de qualquer maneira.

Protótipo - altere sua perspectiva da tarefa, de produção para protótipo. Basta ter algo para trabalhar e construir a partir daí. Quando você chegar ao ponto em que puder usá-lo, comece a pensar nele como produção. Agora você não verá a tarefa como algo que nem sabe por onde começar.

Supere isso - apenas fazer coisas que você sabe fazer será entediante. Isso também leva você a uma armadilha de força bruta, forçando algumas soluções, repetindo as mesmas coisas repetidamente (se você gosta de repetir coisas, trabalhe em uma linha de montagem). Esteja preparado para cometer erros. Aqueles que dizem que sabem tudo, nunca pedem ajuda ou fazem buscas, estão apenas mentindo.

É a velha piada sobre médicos ainda "praticando" medicina; eles também não têm todas as respostas.

Alegre-se por não estar fazendo algo que já fez centenas de vezes antes. Você encontrou a alegria do desenvolvimento de software (para mim, de qualquer maneira, YMMV) - aprender a dirigir enquanto percorre a estrada a velocidades extraordinárias. Esse é o tipo de coisa pela qual um grande desenvolvedor vive e se destaca.

Meu processo pessoal é algo como isto:

• Pesquisa. Descubra se e como esse problema, ou um problema semelhante, foi resolvido antes. Mesmo que você possa encontrar apenas informações sobre soluções para diferentes idiomas ou plataformas, elas ainda podem ser extremamente informativas.
• Protótipo. A melhor maneira absoluta de fazer algo certo é fazer errado primeiro. Crie uma solução, inventando tudo à medida que avança, com base em sua pesquisa. Tente ajustá-lo aos principais requisitos, levando em consideração os requisitos auxiliares. Não se preocupe em torná-lo bonito ou perfeito ou extensível ou flexível ou com desempenho, apenas faça com que funcione. Faça anotações das lições aprendidas - o que funcionou, o que não funcionou, possíveis obstáculos, etc. Em seguida, jogue fora o código. Se você está preocupado em parecer tolo por demorar demais, faça isso no seu próprio tempo. Beneficia você pessoalmente, em termos de conhecimento.
• Desenhar. Combine seu conhecimento externo (pesquisa) com conhecimento pessoal (lições de protótipo aprendidas) e formule um design do que você acha que seria o Caminho Certo para fazê-lo.
• Colaborar. Encontre um membro da equipe sênior, mostre a ele o design proposto e obtenha feedback. Mostre a outra pessoa, obtenha feedback. Refine seu design.
• Iterar. Se você ainda não tiver certeza da sua solução, verifique se as revisões por pares fazem parte do seu ciclo de iteração. Leve sua implementação a um membro sênior da equipe regularmente para obter feedback.
• Seja feliz - você avançou seu conhecimento e sua carreira e precisa fazer algo novo e interessante, em vez de algo antigo e chato que já fez milhares de vezes. Tente fazer do seu próximo projeto um desafio ainda maior.

E, por último, não se preocupe muito com as aparências. Como gerente de equipe de desenvolvimento, eu prefiro ter alguém que possa provar que pode aprender o que precisa aprender do que precisa, do que alguém que possa provar que já sabe a única coisa que estamos tentando fazer agora. O primeiro será mais útil para o que acabarmos fazendo amanhã, ou no próximo mês ou no próximo ano.