Por que a codificação colaborativa é o melhor hack de carreira

Dar os primeiros passos na programação é como aprender uma língua estrangeira. A princípio, a sintaxe não faz sentido, o vocabulário não é familiar e tudo parece e soa ininteligível. Se você for como eu quando comecei, a fluência parece impossível.

Eu prometo que não é. Quando comecei a codificar, a curva de aprendizado me atingiu – com força. Passei dez meses ensinando a mim mesmo o básico enquanto tentava afastar sentimentos de dúvida que agora reconheço como síndrome do impostor. Foi só quando comecei a frequentar encontros amigáveis ​​para iniciantes que percebi como a codificação colaborativa abre possibilidades incríveis. Você só precisa da comunidade certa de pessoas para praticar.

Para mim, essa comunidade foi Founders and Coders, o bootcamp JavaScript gratuito que me ajudou a mudar minha carreira de copywriting para codificação. Mesmo agora, menos de um ano depois de concluir o curso, mal posso acreditar que estou sendo pago para desenvolver software.

A codificação colaborativa tem tudo a ver com enfrentar problemas e descobrir soluções juntos. Abrange técnicas como programação em pares, que várias empresas de tecnologia levam a sério o suficiente para rastrear durante seus processos de entrevista. Também cultiva habilidades úteis que são difíceis de aprender se tudo o que você está fazendo é codificar sozinho em casa.

Se você está apenas começando no setor de tecnologia ou tem vários anos de experiência, a codificação colaborativa nunca deixa de ser útil. Neste artigo, veremos como essas habilidades permanentes preparam você para uma carreira longa e bem-sucedida no desenvolvimento de software.

Emparelhamento Perfeito

Minha primeira experiência de programação em pares foi em um encontro para iniciantes chamado Coding For Everyone. É assim que funciona: as pessoas formam pares, geralmente com pessoas que nunca conheceram, para resolver desafios de JavaScript juntos no mesmo laptop. Uma pessoa assume o papel de 'navegador' e propõe o código que acha que deve ser escrito. A outra pessoa, o 'motorista', digita suas sugestões no laptop e faz perguntas sempre que algo não está claro. Você continua fazendo isso, trocando de papéis com frequência, até o final da sessão de duas horas.

Em teoria, era simples. Na prática, nem tanto.

Achei bastante perturbador ter alguém que eu não conhecia olhando minha tela enquanto eu digitava, e estava relutante em entregar o controle quando era hora de trocar de papéis. Achei a navegação ainda mais complicada. Quando uma ideia não pode passar da sua cabeça para o computador sem antes passar pelas mãos do seu parceiro, cada palavra que você diz importa. Exigiu um grau de comunicação de nós dois a que simplesmente não estávamos acostumados, e eu tinha certeza de que aprenderíamos mais se nos dividíssemos para trabalhar separadamente.

Felizmente, continuamos com ela; Fui novamente ao encontro na semana seguinte. Desde então, passei centenas de horas em parceria com dezenas de desenvolvedores e aprendi mais do que inicialmente pensava ser possível.

A programação em pares é uma maneira incrivelmente rápida de aprender. A mágica do método – uma vez que você supera o constrangimento inicial – é que ele produz resultados imediatos. Alguns ciclos de feedback, como bolhas no mercado de ações, podem levar horas, dias ou até meses para produzir uma correção. A programação em pares leva minutos, se não segundos. Quando você perde um ponto e vírgula, dois pares de olhos podem identificar o erro mais rápido do que um. Precisa pesquisar no StackOverflow por pistas sobre uma mensagem de erro não autorizada? Você e seu parceiro podem ler tópicos diferentes, reduzindo pela metade o tempo necessário para encontrar uma resposta.

Para problemas ainda mais complicados, a programação de multidões pode ser um passo adiante. Esse método exige que uma seção multifuncional de uma equipe se reúna em torno da mesma tela do computador e faça um brainstorming de soluções em tempo real enquanto uma pessoa digita.

“Todas as mentes brilhantes trabalhando na mesma coisa, ao mesmo tempo, no mesmo espaço, no mesmo computador.”

— Woody Zuill, Agile Coach e Instrutor de Programação Mob

Embora possa parecer uma maneira ineficiente de trabalhar, os defensores da programação da máfia, como Woody Zuill, dizem que pode economizar tempo eliminando a necessidade de revisões de código individuais porque todos revisam o código em tempo real enquanto ele está sendo escrito. Produtividade à parte, acho que o mobbing é uma maneira fantástica de aprender não apenas sobre o código, mas sobre como outras pessoas abordam os problemas. Se a programação em pares duplicar o número de perspectivas às quais você está exposto, a programação de multidões gera ainda mais insights.

Isso não quer dizer que o emparelhamento - ou mesmo o mobbing - seja fácil. Algo com o qual lutei inicialmente foi colocar meu ego de lado para fazer perguntas que pensei que poderiam parecer estúpidas. Nessas situações, é bom lembrar que seu parceiro pode estar tendo os mesmos pensamentos, especialmente se vocês dois estão apenas começando.

Se você se encontrar com alguém mais experiente, talvez no trabalho, não tenha medo de pegar seus cérebros e impressioná-los com sua curiosidade. Mesmo alguém que está apenas um pouco mais à frente do que você pode pensar em coisas que não ocorreriam a alguém mais experiente. Alguns dos meus programadores de pares favoritos têm apenas alguns meses a mais de experiência do que eu, mas eles sempre parecem saber exatamente quais erros estou prestes a cometer e como me orientar na direção certa. Quando esses desenvolvedores dizem que não existe uma pergunta boba, eles realmente querem dizer isso. Os melhores programadores de pares falam livremente, sem a necessidade de parecerem fantásticos ou o medo de parecerem tolos.

A programação em pares requer prática, mas vale a pena aperfeiçoar. Estudos mostram que programadores que se unem para resolver problemas tendem a ser mais confiantes, produtivos e engajados com seu trabalho. Esteja você procurando seu próximo emprego ou integrando novas contratações, emparelhar é cuidar.

Recursos e leitura adicional

• “Pair Programming Roles”, Jordan Poulton, GitHub
• “A amizade que tornou o Google enorme”, James Somers, The New Yorker
• “Programação da multidão: uma abordagem de equipe inteira”, Woody Zuill, YouTube

Empatia da Engenharia

Quando comecei a aprender JavaScript sozinho, meu código se parecia muito com o chão do meu quarto: deixei-o ficar cada vez mais bagunçado até não ter escolha a não ser arrumá-lo. Contanto que meu navegador da Web pudesse entendê-lo, eu não me importava com a aparência.

Foi só quando comecei a revisar o código de outras pessoas que percebi que precisava mostrar muito mais empatia pelas pessoas que revisavam o meu.

A empatia pode ser a ferramenta mais subestimada no arsenal de qualquer desenvolvedor. É a razão pela qual a IDEO coloca a pesquisa do usuário no centro de seu processo de design e por que a Etsy pede que seus designers e gerentes de produto façam uma rotação de engenharia. A empatia surge quando temos a oportunidade de ver como nosso trabalho impacta outras pessoas. Não é de admirar que a codificação colaborativa seja uma ótima maneira de construí-la.

A revisão do código por pares – o ato de verificar se há erros no código um do outro – nos chama a exercer empatia. Como revisor, é importante reconhecer que alguém fez um esforço considerável para escrever o código que você está prestes a criticar. Como tal, tente evitar o uso de frases que possam implicar julgamento ou banalizar seu trabalho. Quando você se refere ao código deles, você deseja mostrar a eles as funções e linhas específicas sobre as quais você tem dúvidas e sugerir como eles podem refatorá-lo. Compartilhar recursos de aprendizado também pode ser mais útil do que dar uma solução com uma colher. Alguns dos comentários mais úteis que recebi das revisões de código vieram na forma de artigos educacionais, vídeos e até recomendações de podcast.

Escrever boa documentação para o seu código também ajuda bastante. Um ato tão simples quanto criar um readme com instruções de instalação claras mostra empatia por quem precisa trabalhar com seu código. O fundador do GitHub, Tom Preston-Werner, defende uma abordagem leia-me primeiro para o desenvolvimento.

“Uma implementação perfeita da especificação errada é inútil. Pelo mesmo princípio, uma biblioteca lindamente trabalhada sem documentação também é quase inútil. Se o seu software resolve o problema errado ou ninguém consegue descobrir como usá-lo, há algo muito ruim acontecendo.”

— Tom Preston-Werner, fundador do GitHub

Também conversei com fundadores de tecnologia que tratam a documentação como uma parte essencial de uma integração bem-sucedida. Um CTO disse que se um desenvolvedor júnior luta para atingir um nível de produtividade dentro de seis meses após ingressar em sua equipe, isso indica que a base de código não está bem documentada o suficiente. Leva apenas alguns segundos para adicionar um comentário explicativo a uma função complexa que você escreveu, mas pode economizar horas de esforço para a próxima pessoa que se juntar à sua equipe.

Recursos e leitura adicional

• “Sobre empatia e solicitações pull”, Slack Engineering, Medium
• “Readme Driven Development”, Tom Preston-Werner, GitHub
• “O que o Google aprendeu com sua busca para construir a equipe perfeita”, Charles Duhigg, The New York Times Magazine

Realização Ágil

Desde os milhões de horas-homem que são gastas para fazer filmes CGI até as intensas crunches de desenvolvimento que levam a lançamentos de videogames de grande orçamento, conquistas técnicas imponentes exigem uma quantidade incompreensível de esforço. A primeira vez que vi a base de código do meu atual empregador, fiquei chocado com a enormidade de tudo. Como diabos alguém construiu isso?

A resposta é que todos podem construir muito mais do que qualquer um , com a estrutura colaborativa correta. Nas empresas que incentivam a codificação colaborativa, o software não surge dos esforços de um gênio solitário. Em vez disso, existem maneiras de trabalhar em conjunto que ajudam grandes equipes a fazer um trabalho incrível. Os desenvolvedores da Founders and Coders praticam uma metodologia popular de desenvolvimento de software conhecida como 'Agile' e, na minha experiência, ela coloca o 'funcional' em equipes de desenvolvimento multifuncionais.

Livros inteiros foram escritos sobre Agile, mas aqui está um resumo dos conceitos principais:

• Uma equipe de desenvolvimento de produto divide grandes pedaços de trabalho em pequenas unidades chamadas 'histórias de usuário', prioriza-as e entrega-as em ciclos de duas semanas chamados 'sprints'.
• Enquanto o projeto continuar, os ciclos se repetem e os novos requisitos do produto são alimentados em uma lista de tarefas pendentes para sprints futuros.
• A equipe realiza reuniões diárias para discutir seu progresso e abordar quaisquer bloqueadores.
• O processo é incremental e iterativo: o software é construído e entregue em partes e refinado em sprints sucessivos.

Como um funileiro crônico cujos projetos de hobbies solo muitas vezes sucumbem ao 'desafio de recursos', sei como é fácil perder tempo construindo coisas que ninguém nunca usa. Adoro a maneira como o Agile força você a priorizar histórias de usuários para que toda a equipe possa se concentrar em fornecer recursos com os quais seus usuários realmente se importam. É motivador saber que todos estão unidos em torno do objetivo comum de construir um produto ou serviço que continuará a ter vida depois que você terminar de trabalhar nele.

A divisão de tarefas em pequenas histórias de usuário também é uma ótima maneira de sessões de programação em pares de timebox. Não importa o quão profundo você esteja, terminar o trabalho em um recurso importante é sempre um bom lembrete para se afastar de suas mesas e fazer uma pausa. O Agile empresta estrutura à codificação colaborativa onde, de outra forma, poderia faltar.

Enquanto isso, as reuniões diárias dão a você a liberdade de falar sobre qualquer coisa que o esteja atrapalhando, e as retrospectivas de sprints fornecem espaço para compartilhar as principais vitórias e identificar onde a equipe pode melhorar. Essas cerimônias promovem um senso de colaboração e responsabilidade e nos ajudam a aprender mais juntos do que poderíamos sozinhos.

Colocar todos esses princípios ágeis em prática pode ser um desafio, especialmente quando ninguém em uma equipe está acostumado com essa maneira de trabalhar. Na Founders and Coders, a maioria dos alunos leva algum tempo para adquirir o hábito de fazer standups diários. No entanto, após 18 semanas de prática baseada em projetos, você descobre que seus processos e habilidades de comunicação melhoram imensamente. No momento em que você assume seu primeiro trabalho com o cliente, você formou um modelo mental muito mais claro de como abordar a criação de um aplicativo da Web full-stack em uma equipe.

A melhor maneira de aprender Agile é construir projetos interessantes com outras pessoas. Participar de hackathons é uma excelente maneira de se conectar com potenciais colaboradores. Muitos projetos de código aberto tornam seus quadros de projetos kanban públicos, para que você possa ver em quais problemas do GitHub diferentes contribuidores estão trabalhando. Várias contribuições bem-vindas de iniciantes, e muitas vezes você pode se atribuir a problemas em aberto e começar a gerar solicitações de pull.

Como a maioria das empresas de tecnologia adota alguma forma de Agile, não é incomum que os empregadores perguntem sobre isso em entrevistas. Qualquer experiência que você tenha pode diferenciá-lo de outros candidatos que podem nunca ter codificado de forma colaborativa, muito menos com Agile em mente.

Recursos e leitura adicional

• “O que é ágil?”, Steve Denning, Forbes
• “Abraçando o Agile”, Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi, Harvard Business Review
• “Oportunidades incríveis de solicitação de primeiro pull”, Shmavon Gazanchyan, Deloitte Digital

Recomendações da ferramenta de codificação colaborativa remota

Nos últimos anos, as ferramentas de trabalho remoto avançaram a ponto de empresas proeminentes como Gatsby e Zapier agora serem “remotas primeiro”. Embora ainda não se saiba se isso se tornará uma tendência, é seguro dizer que as equipes de desenvolvimento remoto estão aqui para ficar.

Nesse espírito, aqui estão algumas ferramentas que podem ajudar você e sua equipe a codificar colaborativamente de longe:

Se você tirar uma coisa da leitura deste artigo, quero que os jogadores da equipe superem os contribuidores individuais. Em um campo onde parece haver uma nova estrutura para dominar a cada duas semanas, nossas habilidades técnicas envelhecem de uma maneira que nossas habilidades sociais não. O resultado é que os desenvolvedores que podem trabalhar bem com outras pessoas sempre encontrarão suas habilidades em demanda. A codificação colaborativa não é apenas uma maneira eficaz de aprender; é um conjunto de habilidades procurado que qualquer um pode desenvolver com bastante prática e paciência.