A comunicação é uma habilidade básica para programadores

Matthew Quiros Blocked Unblock Seguir Seguindo 11 de janeiro Foto de Thomas Drouault no Unsplash

Nós, programadores, atraímos muito do nosso orgulho profissional em nossa capacidade de resolver problemas – ao escrever os algoritmos mais eficientes em termos de espaço e tempo, ao projetar arquiteturas altamente escaláveis, ao criar as funções e nomes de variáveis mais elegantes e inteligentes e aplicativos de cinco estrelas que impactam positivamente a vida de muitas pessoas em todo o mundo. Assim, estrategicamente construímos nossas carreiras – toda a nossa vida, mesmo – em direção ao constante aprimoramento de nossas habilidades técnicas. Gastamos bastante tempo e dinheiro estudando para nos tornarmos full-stack e multi-plataforma. Fazemos atualizações diárias da teoria e prática da SC em Hackerrank ou Leetcode. Compramos livros sobre as melhores práticas e padrões de design que, de acordo com pessoas populares no Medium e no Quora, “todos deveriam ler totalmente”. Trabalhamos em projetos de fim de semana para manter um perfil ativo do Github. Nós cultivamos a reputação respondendo a perguntas no StackOverflow. A lista é longa e só continua.

Tudo isso é feito às custas das habilidades pessoais. Soft skills são as habilidades que se empregam no gerenciamento de si mesmo e das pessoas com quem se trabalha, como clientes e colegas. Estes incluem liderança, inteligência emocional, persuasão, escuta, motivação e construção de relacionamentos valiosos. As habilidades duras, por outro lado, são altamente especializadas e muitas vezes científicas utilizadas na tarefa de resolver um problema ou construir um produto. As “habilidades duras” da cunhagem, no entanto, são um equívoco para habilidades que são frequentemente percebidas como difíceis , levando consigo a noção desagradável de que as pessoas que têm boas habilidades, em comparação, se especializam em habilidades simples e rápidas de aprender. Na realidade, sem autoconsciência e gastando uma quantidade excessiva de tempo em reflexões profundas e ponderadas, as habilidades sutis são incrivelmente difíceis de dominar.

Uma dessas habilidades leves comumente ignoradas é a comunicação ou a capacidade de transmitir uma ideia ou informação a outra pessoa. Eu, por exemplo, como muitos programadores em seus jovens, certa vez esperei que as pessoas que são designadas para trabalhar diretamente comigo deveriam, por padrão, ter uma sólida compreensão dos princípios técnicos sem muita explicação; caso contrário, eles não deveriam estar trabalhando na indústria de tecnologia ou são idiotas. Muitos jovens programadores acham que a documentação formal e os processos são simplesmente burocracia que apenas servem para retardar o desenvolvimento de software e, portanto, não devem ser respeitados. Nos artigos que escrevemos e em nossas representações de programadores na cultura popular, celebramos introversão e excentricidades na personalidade que fundamentalmente dificultam a colaboração.

Os programadores devem, no entanto, aprender a se comunicar.

Em primeiro lugar, a grande maioria dos ambientes em que a atividade de programação é feita está dentro de uma organização onde um programador precisa interagir com não-programadores. Muitas vezes, devemos nos corresponder com um gerente de produto para detalhar as especificidades técnicas dos requisitos de negócios, de modo que a dificuldade possa ser avaliada, a viabilidade avaliada e, por esses motivos, as tarefas sejam priorizadas. Podemos precisar fornecer e justificar estimativas para um gerente de projeto que esteja certificando-se de que o projeto esteja dentro do orçamento e dentro do cronograma. Precisamos trabalhar em estreita colaboração com os designers para contornar as limitações dos ambientes de destino, identificar fluxos ausentes na interação do usuário ou detectar problemas no design das informações. E, em vez de nos ofender, devemos colaborar com o controle de qualidade para reproduzir e identificar as fontes de bugs, ou para discutir se algo é um problema para começar. Ao nos comunicarmos com os colegas nesses papéis, devemos constantemente ter cuidado com as palavras ou com o tom que usamos para transmitir nossas ideias. Um elemento crítico das equipes de alto desempenho é a dinâmica da equipe e, se a maneira como comunicamos o conflito nos tribunais ou o drama, estamos efetivamente introduzindo a disfunção na equipe.

Por que esses outros papéis existem mesmo? Alguém poderia perguntar. Nada impede que um programador interaja diretamente com os clientes para que os requisitos possam ser reunidos. Os gerentes de projeto são uma coisa do passado, quando a cascata era mais popular do que o Scrum – um programador também pode se relacionar diretamente com o CEO e justificar estimativas usando a lógica pura. Designers são totalmente inúteis; qualquer programador pode inserir fontes, cores e ícones personalizados – em vetor, até mesmo, em vez de JPG. E por que precisamos mesmo de uma equipe dedicada de testadores quando podemos apenas escrever os testes unitários?

Os produtos que são verdadeiramente valiosos e bem-sucedidos são aqueles que se tornam não triviais em escala e que exigem conhecimentos multidisciplinares; Portanto, eles são impossíveis de fazer sozinhos. Código, por si só, não faz um negócio. A realidade do trabalho envolvido nos papéis acima é que, assim como a programação, eles levam muito tempo e energia até para realizar, especialmente quando mantidos em altos padrões. Se um programador fizesse tudo sozinho, nada seria bem feito. Isso apenas consumiria todas as horas que poderiam ter sido focadas em escrever código, que é a função principal de um programador.

Além disso, a demissão desses papéis da maneira acima vem de uma posição de arrogância, mas é míope e reducionista. Os gerentes de produto não apenas escrevem requisitos de negócios para nossos propósitos – essa é apenas a parte do trabalho que os programadores enfrentam – eles também estudam constantemente o comportamento do cliente e as tendências da linha de negócios da empresa para manter os produtos valiosos. Os gerentes de projeto fazem muito mais do que justificar estimativas – planejam e ajustam cronogramas, criam orçamentos, avaliam riscos e gerenciam a alocação dos recursos da empresa. Designers, além de desenvolver um bom gosto pela arte, estudam muito sobre psicologia, interação humano-computador e até neurociência para incorporar descobertas científicas na construção dos melhores produtos dentro do espaço competitivo da organização. E os testadores, ao contrário de nossos testes de unidade, que funcionam apenas em um ambiente de desenvolvimento, garantem que os produtos se comportem conforme o esperado, mesmo após a implantação na produção. Eles são inestimáveis na eliminação do viés do desenvolvedor, pensando em "caminhos infelizes", documentando as etapas para reproduzir erros, sistematizando os processos de teste e estabelecendo procedimentos para automatizar testes no nível da interface do usuário ou do consumidor, a parte do trabalho de desenvolvimento que mais programadores consideram ser um trabalho penoso. O universo além da tela do programador é muito maior. Devemos ser humildes, pois podemos não ter um conhecimento exaustivo das operações e responsabilidades do dia-a-dia das pessoas em funções que não são as nossas. Na verdade, é estranho como nos referimos a pessoas que não codificam como “não-técnicas” quando são, de fato, técnicas para o campo em que se especializam e nas quais não.

Mas, talvez, as habilidades de comunicação derivem uma importância maior, não tanto da necessidade de interagir com papéis que não sejam de programação, mas da necessidade de se comunicar com outros programadores. Muitas vezes debatemos uns com os outros sobre os resumos, lutando por uma explicação de por que uma solução, processo ou estrutura é superior a outra, para não sermos descartados como apenas impondo nossa preferência pessoal. Muitas vezes, chegamos a uma decisão arquitetônica, nem mesmo porque é objetivamente melhor do que opções alternativas – foi meramente defendida de forma mais eloqüente. Também é comum para nós discutir e concordar com padrões de trabalho, como fluxo de trabalho de controle de versão e estilo de código. Nós gostamos de ensinar uns aos outros sobre técnicas avançadas de programação e melhores práticas. Eventualmente, à medida que nos elevamos a cargos mais altos, as responsabilidades de conduzir um para um, fornecer feedback e gerenciar conflitos tornam-se inevitáveis.

Outros podem argumentar que não há necessidade de habilidades de comunicação onde um programador é contratado especificamente apenas para receber ordens. No entanto, mesmo um programador que apenas segue as ordens ainda precisa garantir, através da comunicação , que os requisitos não negociáveis são bem compreendidos. Espera-se que até mesmo estagiários e engenheiros de software juniores falem quando encontrarem um erro nas especificações, ou façam perguntas onde houver ambigüidade. Um papel em que um programador deve produzir algo de valor sem se comunicar com outra pessoa simplesmente não existe.

A comunicação, portanto, é uma habilidade essencial para programadores.