Programador .NET solo movendo-se para uma equipe [fechado]

Fui programador .NET solo para uma pequena startup nos últimos 8 anos. Eu montei um software bastante decente e sempre me esforcei para me aperfeiçoar e me adaptar às melhores práticas, incluindo controle de origem (SVN / TFS). Trabalhei em estreita colaboração com uma equipe de engenheiros de outras disciplinas, mas quando se tratava do software, eu era a única programação. Adoro a arte da programação e adoro aprender coisas novas para aprimorar minhas ferramentas.

Dentro de duas semanas, começarei um novo trabalho em uma equipe de 20 desenvolvedores .NET. Minha posição será de nível intermediário e estarei trabalhando com alguns programadores com experiências incrivelmente impressionantes. Mais uma vez, o aspecto de desenvolvimento da equipe será novo para mim, por isso estou procurando algumas dicas gerais de "novato" que me ajudarão a ser o mais eficaz e fácil de me conviver o mais rápido possível desde o início.

Tudo vale, incluindo dicas de alto nível e pequenas coisas do dia-a-dia sobre comunicação.

Principalmente senso comum, mas meu conselho seria:

Passe o máximo da primeira semana com pessoas e não com a tecnologia. Não perca o primeiro dia personalizando sua área de trabalho ou qualquer outra coisa que o isola da equipe. Conheça o maior número possível de colegas o mais rápido possível.

Tente descobrir quem são os cavalos de trabalho e quem também são os vagabundos. Evite os vagabundos, tanto quanto possível, cada equipe os possui e você não deseja ser classificado como um.

Participe de eventos sociais nas primeiras semanas, mesmo que seja apenas uma cerveja depois do trabalho ou do almoço.

Ouça e escreva as coisas, peça aos colegas que repitam as descrições dos procedimentos que os incomodam.

Passe os primeiros 3 a 6 meses se familiarizando, a menos que seja perguntado especificamente sobre um problema específico, não recomende alterações nos procedimentos / arquitetura / etc. Eles funcionarão de maneira diferente para você e alguns elementos podem ser ruins - mas haverá motivos para isso e raramente são causados ​​por negligência ou ignorância.

Duvido que o lado da programação seja realmente um problema.

• Aprender! Conhecer novos programadores é uma ótima maneira de aprender novos truques. Observá-los digitando, você aprenderá alguns truques do editor e, ao olhar para o código, fornecerá novas idéias.

• Não incomode seus colegas a cada cinco minutos, mas se você estiver realmente preso, não hesite em pedir ajuda. Muitos programadores ficam presos em um programa por dois dias, onde perguntar ao seu vizinho o resolveria em uma hora.

• As guerras de código são guerras religiosas. A sintaxe pode ser um pouco diferente por lá (você adiciona colchetes às frases de uma linha?), Mas raramente vale a pena brigar.

• Socializar. Se eles estão tomando uma bebida toda semana, não se esqueça de participar. Isso pode ser tão simples quanto comer juntos .

Jogando como o advogado do diabo e vou dizer para garantir que seus colegas sejam competentes. Nada é pior do que trabalhar em uma equipe em que ninguém, exceto você, faz algo da maneira "correta", porque você está sempre em menor número que as pessoas que querem fazer as coisas erradas.

Você mencionou trabalhar com desenvolvedores com um histórico impressionante, de modo que parece promissor e, nesse caso, encorajo você a aprender o que pode, mas nunca esqueça o que já sabe em nome da "mentalidade de rebanho". Se todo mundo faz algo errado e você faz certo, não se comprometa.

Além de Jonno, eu diria:

Esteja preparado para mudanças. Cada equipe trabalha diferente. Boas equipes de SW têm regras de codificação. Esteja preparado para aceitá-los, mesmo que inicialmente eles pareçam estranhos.

Esteja preparado para muito mais comunicação. Quando você trabalha por conta própria, muitas informações detalhadas estão na sua cabeça. Assim que você trabalha em equipe, esses detalhes (pelo menos alguns deles) precisam ser compartilhados e comunicados, e é necessário tempo para isso.

Ouça mais do que fala.

Faça mais perguntas do que você tenta responder (a menos que as perguntas sejam direcionadas a você). Os "veteranos" da equipe saberão quanto progresso você está fazendo no aprendizado do código pelas perguntas que você faz. Eles provavelmente têm uma lista mental de perguntas que estão esperando.

Escreva seu código para corresponder ao estilo predominante. Isso se aplica a onde você coloca espaços, chaves, letras maiúsculas, tamanho dos nomes das variáveis, tamanho médio dos métodos, densidade de comentários e tudo o mais que não deveria importar. Se você realmente tem um bom motivo para fazer as coisas de maneira diferente, pergunte a um dos veteranos por que a equipe tem o estilo determinado. Você pode aprender algumas coisas interessantes sobre a história e as personalidades da equipe. O que me leva ao próximo ponto.

Aprenda o conhecimento da equipe. Provavelmente, nenhuma parte do conhecimento está escrita em qualquer lugar, mas é um conhecimento comum da equipe. O conhecimento da equipe inclui a história de como o projeto chegou ao seu estado atual, erros cometidos no passado, sucessos feitos no passado, lições aprendidas ao longo do caminho. É referido em breves declarações como "soa como o bug do frobnitz novamente". Quando você vê / ouve os membros da equipe concordarem com um comentário enigmático que alguém faz, provavelmente há um conhecimento da equipe envolvido. Pergunte a alguém.

Não critique o código até conhecer as personalidades e a história envolvidas. Você não sabe quem pode estar ofendendo.

Faça perguntas e ouça as respostas. Pense nas respostas das perguntas anteriores antes de fazer a próxima para tentar antecipar uma resposta.

Esforce-se para fazer o melhor trabalho possível. Acostume-se a se perguntar o que outra pessoa da equipe pensará em seu código se precisar fazer uma alteração no próximo mês.

Se você vir um problema que precisa ser resolvido, faça o possível para ter uma solução razoável pronta para oferecer antes de manifestar preocupação com o problema. Assuma o controle da implementação de uma solução ao apontar um problema.