Como incluir desenvolvedores novatos em seu projeto?

Estamos pensando em ensinar alguns funcionários com experiência em programação de nível zero ou geral para hobby a tirar a carga de trabalho de mim.

Usamos Python / Django, que possui algumas das documentações mais amigáveis ​​e muito fáceis de aprender.

Atualmente, sou um departamento de TI da minha empresa e não tenho horas suficientes para desenvolver tudo o que a empresa precisa. Não somos uma empresa de software, mas ajuda ter TI interno para automatizar tarefas, desenvolver recursos de atendimento ao cliente, analisar dados etc.

Como você lentamente integra novatos trabalhando em sua base de código? Digamos que você tenha um estagiário - o que eles fazem? Estou completamente relutante em permitir que eles projetem ou desenvolvam o código principal, pois lidaremos com seus erros / padrões de design estranhos por anos. Como desenvolvedor primário, eu serei o único que precisa contornar o código deles.

Meu pensamento era ter novatos apenas modificando o código existente, nunca construindo recursos principais. Posso descarregar o trabalho para eles com tarefas simples depois de criar o próprio recurso.

Gostaríamos que nossos funcionários aprendessem / encontrassem valor na empresa e geralmente temos pessoas 'subindo na hierarquia'.

É prática padrão ensinar pessoas com programação geral / amadora? Como o "subir na hierarquia" em uma empresa de software funciona para programadores de nível júnior? Quando eles começam a trabalhar no código principal?

Estou tentando decidir se isso causará mais danos do que ajuda e se existe uma maneira de usar a ajuda deles sem potencialmente arriscar o código do site principal (ambientes isolados?).

Se você delegar o novato em um papel ineficaz, ele nunca aprenderá nada de substancial e eles certamente não serão muito úteis para você.

Deixe-me dar um conselho: meu primeiro trabalho de TI fora da escola foi em uma empresa de manufatura relativamente pequena, onde eu iria trabalhar em software para ajudar os engenheiros de vendas a escrever citações para vários projetos. Eu também deveria ajudar o pessoal de TI que gerenciava sozinho a TI para toda a empresa.

O cara era uma bagunça estressada e sobrecarregada, e o pior perfeccionista de microgerenciamento em que já trabalhei. Eu deveria aliviar sua carga de trabalho, mas ele passou quase tanto tempo checando comigo e meu trabalho como eu gastava trabalhando (ele quase nunca saiu do escritório, acho que desprezava sua família). Se eu cometesse um único erro, ele perderia completamente a cabeça e começaria a fazer uma birra: "Eu sabia que não deveria ter confiado em você com isso, era muito importante!" e outras reclamações.

O ponto que estou tentando enfatizar é NÃO ser assim. Além de tornar os novatos infelizes e destruir o moral deles, você queimará a vela nos dois extremos, preocupando-se com o trabalho deles.

Dê a eles a chance de provar a si mesmos, mas possuem especificações técnicas formais, revisões de design e revisões de código. Além disso, você pode testar o que eles produzem para garantir que atenda aos requisitos.

Acho que você ficará surpreso com a capacidade de alguns deles.

Eu trabalhava em uma loja de software, onde estávamos codificando um projeto grande (tempo de aceleração significativo).

Os novatos foram tratados como veterinários. Eles receberam um líder técnico e começaram os recursos "por conta própria". O estilo da arquitetura foi ditado, mas eles eram livres para criar seu próprio design limpo. Os "padrões de design estranhos" foram eliminados durante as revisões diárias do código por pares.

Um erro que vi em outra loja: suponha que "core" seja difícil e "ui" seja fácil. Os novatos tiveram um tempo mais fácil no núcleo e alteraram o código de front-end da interface do usuário.

Boa sorte!

Você deseja começar dando a eles pequenas peças discretas para implementar. Defina a entrada que você promete e a saída que você espera e deixe que eles conectem os pontos. E, em seguida, use a revisão de código do líder da equipe para garantir a qualidade e a revisão por pares para treiná-los a aprender uns com os outros e a se ensinar.

Isso pressupõe que você tenha uma arquitetura geral de aplicativos que permita que unidades atômicas da lógica sejam construídas de maneira dissociada. Caso contrário, você está caminhando para um mundo de luto, à medida que vários desenvolvedores trabalham nele - esse seria o caso mesmo com profissionais antigos.

Inevitavelmente, você terá certas pessoas que aprendem rápido e aprendem rápido. Continue alimentando tarefas que estão apenas um pequeno passo além da capacidade atual. Nada educa alguém como uma tarefa que começa impossível. Inevitavelmente, você terá algumas pessoas que tentam e nunca realmente a alcançam. Essas pessoas devem ser agradecidas por seus esforços e migradas graciosamente para outra coisa.

Como sua empresa pode se dar ao luxo de se afastar de outros funcionários, mas não contratar alguém com experiência em programação? A quantidade de seu tempo de treinamento, solução de problemas e manutenção da mão é cara.

A única coisa que já fiz nesta área é ensinar às pessoas como usar um redator de relatórios ou talvez algum código VBA / Macro para Excel. Normalmente, dou os conjuntos de dados para reutilização. Tê-los aprendendo SQL é um exagero, mas já vi isso (Pago para que eles recebam treinamento externo). A maioria dessas pessoas eram analistas financeiros que têm a capacidade de aprender a codificar, mas podem não ter levado tempo. Tentar isso com algumas pessoas em operações é um tiro no escuro.

Certifique-se de pegar a pessoa certa e ela realmente deseja aprender a codificar. Você não terá tempo para ensinar tudo a eles. Eles terão que fazer muito por conta própria.

@louisgab estava certo sobre a revisão de código. Esse seria o meu primeiro passo também. Uma coisa crítica que o ajudará é garantir que eles tenham que corrigir seus próprios erros, caso você os encontre na revisão de código ou posteriormente. Eles não vencem; nem percebem que estão cometendo erros, a menos que tenham que corrigi-los. Certifique-se também de explicar por que a solução que eles usaram é um erro e por que o que você está propondo é melhor. Nas primeiras semanas, será como se você tivesse mais trabalho por ter essas outras pessoas, mas se você revisar seu código, explicar as coisas e esperar que elas aprendam, em algumas semanas elas serão muito mais úteis do que se você apenas faça tudo sozinho. Mas existe um compromisso inicial de seu tempo para atualizá-los, dos quais sua gerência precisa estar ciente.