Como se tornar um bom jogador de equipe? [fechadas]

Eu tenho programado (obsessivamente) desde os 12 anos. Eu tenho bastante conhecimento de todo o espectro de linguagens existentes, desde assembly, C ++, Javascript, Haskell, Lisp e Qi. Mas todos os meus projetos foram por mim.

Eu me formei em engenharia química, não em engenharia de computação ou computação, mas pela primeira vez neste outono estarei trabalhando em um grande projeto de programação com outras pessoas, e não tenho idéia de como me preparar. Eu uso o Windows a vida toda, mas esse projeto será muito unix-y, então comprei um Mac recentemente, na esperança de me familiarizar com o ambiente.

Tive a sorte de participar de um hackathon com alguns amigos no ano passado - os dois maiores do CS - e, de maneira emocionante, vencemos. Mas, ao trabalhar com eles, percebi que o fluxo de trabalho era muito diferente do meu. Eles usaram o Git para controle de versão. Eu nunca tinha usado na época, mas desde então aprendi tudo o que posso sobre isso. Eles também usaram muitas estruturas e bibliotecas. Eu tive que aprender o que o Rails era praticamente da noite para o hackathon (por outro lado, eles não sabiam o que eram escopos ou fechamentos lexicais). Todo o nosso código funcionou bem, mas eles não entenderam o meu e eu não o deles.

Eu ouço referências a coisas que programadores reais fazem diariamente - testes de unidade, revisões de código, mas só tenho a menor noção do que são. Normalmente, não tenho muitos bugs nos meus pequenos projetos, então nunca precisei de um sistema de rastreamento de bugs ou de testes para eles.

E a última coisa é que demoro muito tempo para entender o código de outras pessoas. As convenções de nomenclatura variável (que variam com cada novo idioma) são difíceis (__mzkwpSomRidicAbbrev) e acho difícil o acoplamento flexível. Isso não quer dizer que eu não concordo muito com as coisas - acho que sou muito bom nisso para o meu próprio trabalho, mas quando faço o download de algo como o kernel Linux ou o código-fonte do Chromium para ver isso, passo horas tentando para descobrir como todos esses diretórios e arquivos com nomes estranhos se conectam. É um pecado de programação reinventar a roda, mas geralmente acho que é mais rápido escrever a funcionalidade do que passar horas dissecando alguma biblioteca.

Obviamente, as pessoas que fazem isso para ganhar a vida não têm esses problemas, e eu precisarei chegar a esse ponto.

Pergunta: Quais são algumas das etapas que posso executar para começar a "integrar" a todos os outros?

Obrigado!

Eu acho que você está ficando um pouco ansioso e animado em trabalhar para um grupo.

Nenhum de nós aprendeu a trabalhar em um grupo ou equipe a partir de livros ou recebeu alguns passos de bebê ou "Guia dos manequins para trabalhar em equipes".

Apenas aprendemos a trabalhar com grupos trabalhando em grupos.

Tudo o que você ouviu sobre programadores profissionais se encaixará gradualmente ao trabalhar em equipe. Você aprenderá sobre todos eles um por um, como controle de versão, teste de unidade etc.

Para mim, a linha inferior é

Torne-se parte de uma equipe.

Vou escolher algumas de suas frases e fazer alguns pontos gerais:

(por outro lado, eles não sabiam o que eram escopos ou fechamentos lexicais). Todo o nosso código funcionou bem, mas eles não entenderam o meu e eu não o deles.

...

Eu ouço referências a coisas que programadores reais fazem diariamente - testes de unidade, revisões de código, mas só tenho a menor noção do que são. Normalmente, não tenho muitos bugs nos meus pequenos projetos, então nunca precisei de um sistema de rastreamento de bugs ou de testes para eles.

...

Passo horas tentando descobrir como todos esses diretórios e arquivos com nomes estranhos se conectam ... Costumo achar que é mais rápido escrever a funcionalidade do que passar horas dissecando alguma biblioteca.

Eu acho que a maior coisa que você precisa aprender é o seguinte:

Para um determinado padrão de habilidade do desenvolvedor, uma equipe de ndesenvolvedores faz menos do que no trabalho que um dos desenvolvedores poderia fazer sozinho - mas ainda faz mais do que qualquer pessoa .

O motivo é simples: ao trabalhar com outras pessoas, você deve gastar parte do seu tempo trocando informações com essas outras pessoas; enquanto que, quando trabalha sozinho, todas as trocas de informações acontecem na sua cabeça. O que naturalmente é mais rápido.

A outra coisa importante é:

Alguns de seus colegas de trabalho serão menos capazes que você, certamente em algumas habilidades; alguns até serão menos capazes que você em todas as habilidades

Com essas duas idéias em mente, tudo o que citei acima faz sentido. Muitas pessoas não obtêm encerramentos. As análises de teste e de código são para garantir a qualidade e diminuir o risco quando o código é produzido por um grupo de pessoas de capacidade mista . O rastreamento de erros ocorre porque quando você produz sistemas suficientemente grandes, os erros são inevitáveis. E as infinitas bibliotecas com suas convenções são porque, sem convenções, há muito código para aprender ou escrever novamente sempre que você precisar.

Realmente, acho que a única maneira de aprender a trabalhar em equipe é realmente fazê-lo; mas espero que o item acima o ajude a se preparar mentalmente. Boa sorte!

A maneira mais eficiente é fazer parte de uma equipe.

Participar de uma equipe pode parecer difícil, pois entendo que você ainda não faz parte de uma equipe, como muitos estudantes e muitas pessoas cujo trabalho é trabalhar com outros desenvolvedores por perto.

Eu recomendo que você participe de um projeto de código aberto muito ativo e que favorece a comunicação frequente nos modernos canais abertos a todos (rastreador de problemas, lista de discussão, wiki, etc.). A comunicação aberta é importante porque você provavelmente começará observando como as outras pessoas interagem, portanto, evite projetos que dependam de emails entre desenvolvedores principais ou IRC não arquivado.

Prefira um projeto que pareça acolhedor, com vários colaboradores bastante frequentes , em vez de um projeto com uma pessoa que faça tudo. Além disso, prefira projetos em que qualquer pessoa possa tocar em tudo (em vez de cada desenvolvedor ter sua área delimitada), porque é mais divertido e oferece mais oportunidades de comunicação.

Plugue sem vergonha: você é muito bem-vindo aqui !

Não vou reiterar o que todo mundo já disse sobre o efeito "just do it", mas vou acrescentar um ponto adicional que não vi mencionado: um bom gerente realmente ajudará você a se integrar à equipe.

Embora você possa ter todas as coisas certas sobre você para a parte de programação do trabalho, você pode estar perdendo algumas das coisas mais interpessoais e relacionadas ao desenvolvimento de software. Um bom gerente o guiará para as práticas da equipe (tanto em soft skills quanto hard skills) para ajudá-lo a se desenvolver e também esperançosamente lhe dirá se você fez ou fez algo que se opõe a essas práticas; porque você não pode consertar algo que você não sabe que está quebrado.

Outra dica que gostaria de lhe dar é que não há duas equipes iguais e até mesmo uma equipe existente mudará quando uma ou mais pessoas se juntarem a ela.

Uma equipe se origina da interação de indivíduos que se conhecem e tentam entender como trabalhar juntos até encontrar um caminho comum (veja, por exemplo, os estágios de desenvolvimento do grupo de Tuckman ).

Portanto, meu conselho seria não tentar encontrar respostas para suas perguntas agora, mas ver o que acontece quando você realmente começa a trabalhar na nova equipe. Alguns de seus problemas podem ser considerados não-problemáticos por seus colegas, outros serão considerados relevantes e você terá a possibilidade de discuti-los juntos ou até de promover sua própria visão sobre o assunto. E, finalmente, você provavelmente também lidará com aspectos em que não havia pensado.

Concordo com ElYusubov de que você precisa de muita paciência e oferece a si e aos colegas uma equipe para aprender a trabalhar juntos até que você se torne uma equipe. Se você pratica algum esporte de equipe, já deve ter experimentado isso.

Um comentário final sobre gastar muito tempo entendendo o código de outras pessoas. Trabalhar em equipe significa que você trabalhará no código de outra pessoa e outros desenvolvedores trabalharão no seu código. Às vezes, o código é complexo demais para ser reescrito do zero. Uma solução típica é solicitar ao desenvolvedor original que revise suas alterações, para que você tenha um pouco mais de confiança de que não está quebrando nada no código.

Isso foi para mim um grande salto na transição de um programador solo para um programador de equipe: você trabalha com código que entende apenas parcialmente e precisa se acostumar. Isso envolve muito mais comunicação com seus colegas, muito respeito (sim, eles têm convenções de nomes estranhas para suas variáveis, e daí?) E confiança mútua (mesmo que eles tenham um estilo de codificação diferente, eu sei que eles entregam código de trabalho) .

Ser um bom membro da equipe significa comunicar-se sem medo, confiar em suas faculdades e superar obstáculos em um projeto como equipe edeliver project as a team.

Leva tempo , leva paciente e requer aprendizado para se sentir confortável e confiante como programador. Também é verdade que nem todo programador é um bom jogador de equipe , e eles compartilham seu sucesso e aprendem lições com falhas.

Seria útil destacar alguns personagens de um bom membro da equipe .

a) Um bom membro da equipe é uma pessoa orientada para objetivos, em vez de orientada para si mesma.

b) Qualidades: pensar mais no panorama geral do que na satisfação pessoal. Este é o ponto chave. Todas as outras qualidades (como confiabilidade, comunicação construtiva) herdam dessa

c) Como melhorar: tente qualificar como você interage com sua equipe durante o dia, defina pontos positivos e negativos, preste atenção a eles nas próximas reuniões. Além disso, tente analisar as decisões da equipe de vários ângulos. Coloque-se no papel do outro, pense em como você pode afetar o trabalho dos outros.

Primeiro, parabéns por ser o tipo de pessoa que parece realmente gostar de programação. No entanto, a programação não é o começo e o fim do fornecimento de sistemas úteis. Você terá um desafio à sua frente e dependerá de você voltar aos programas de hobby ou seguir uma carreira em que possa fazer o que ama e ser pago por isso.

Você está em desvantagem por não ter formação em construção de software. Nessa educação, há várias coisas ensinadas (não apenas como programar) que, para graduados em CS e desenvolvedores de software experientes, serão uma segunda natureza. Não que ele apareça frequentemente no local de trabalho (embora tenha acontecido comigo uma vez), mas NP-hard é um exemplo de termo que eles podem entender e você pode não. Provavelmente, você não tem formação em teoria formal por trás da computação, mas tudo bem, desde que esteja disposto a aprender sobre isso. Talvez um mestrado em CS no seu futuro? Parece que parte do seu código pode ser idiomática, no sentido de que você tem um estilo de programação que parece claro para você, mas não para outros. Preste atenção nas revisões de código e esteja disposto a aceitar críticas e aprender. Isso vai dar trabalho, e você pode ficar frustrado,

O que você tem a seu favor não tem preço. Você parece realmente gostar de programar. Acho que você também gostará dos outros aspectos do desenvolvimento de sistemas, como design, arquitetura, teste, otimização etc. A programação é uma parte do quebra-cabeça e você terá que aprender outras habilidades para ser um desenvolvedor de software. Hackathons à parte, muitos negócios envolvem comunicação, aprendendo uns com os outros, ouvindo e planejando. Eu trabalhei com muitas pessoas que são graduadas em CS e gostaram mais do desenvolvimento de software do que vender carros ou pintar casas, mas não gostavam muito disso.