Eu assisti no outro dia uma apresentação de Kate Gregory na conferência Pacific ++ 2018.
Kate é um bom programador e um ótimo palestrante. O próprio relatório levanta muitas coisas interessantes sobre a programação C ++ e a programação em geral (vale a pena dar uma olhada). Mas acima de tudo, fui fisgado por uma pessoa (literalmente de passagem) que ela expressou. Kate conseguiu brevemente e, no caso, identificar a motivação dos programadores. Ela soou assim: "O programador, enquanto trabalha, procura maximizar sua felicidade". Parece brega, mas realmente é.
Podemos dizer que apoiamos o projeto, o cliente, a empresa, a humanidade e a paz mundial (e isso pode até ser verdade). Mas sejamos honestos. Somos pessoas e, como todas as pessoas, em primeiro lugar, nos esforçamos para maximizar nossa felicidade - globalmente ao longo de nossas vidas, estrategicamente em nossas carreiras, taticamente no projeto atual e mesquinha aqui e agora, ao escrever esta função, esta linha de código. Sim, estamos fazendo isso e seria bom descobrir o que nos torna mais felizes e o que nos torna menos. Isso nos permitirá entender melhor nossos colegas, subordinados e nós mesmos.
Quero abordar imediatamente as questões de remuneração, condições de trabalho, superiores, funcionários e outros. Se você trabalha onde trabalha, tudo isso lhe agradará aproximadamente. Vamos nos concentrar no que nos deixa felizes e infelizes ao trabalhar diretamente no código.
Testes
Todos os projetos com testes são igualmente felizes; cada projeto sem testes é infeliz à sua maneira. Posso dizer com confiança que programadores em projetos com boa cobertura de teste são, em média, mais felizes do que em projetos sem testes em geral. Eu até vi como os programadores, com quem seus superiores não concordavam em escrever testes completos, os escreviam secretamente (às vezes mesmo depois de horas). Por que isso aconteceu? O teste escrito deixa o programador mais feliz. Sua própria existência já é um sinal de que pelo menos algo em seu projeto está sendo feito de acordo com as melhores práticas do setor (mesmo que o restante não seja). Um teste concluído com sucesso mostra uma bela marca de seleção verde, elogia o programador (e, afinal, talvez ninguém mais o elogie). A conclusão bem-sucedida de 100% dos testes fornece algum tipo de terreno estável aos seus pés, quando você já pode acreditar em algo - isso aumenta nossa confiança no hoje e no amanhã, nos torna mais felizes. E mesmo um teste com falha faz o seu trabalho - nos informa que o escrevemos por um bom motivo, elogiando-nos por nossa previsão. Se você deseja tornar um programador mais feliz, deixe-o (ou até o force a forçar) a escrever testes (é claro, tudo é bom com moderação).
Correção de bugs e desenvolvimento de novas funcionalidades
"Não vou lhe contar por toda a Odessa", mas a maioria dos programadores que conheci na minha vida gostava mais de escrever novas funcionalidades do que de corrigir códigos legados. Porque Mas porque tocar em um bug está tocando no infortúnio de outra pessoa. Algo deu errado para alguém e era tão importante que ele não estava com preguiça de levar sua dor até o desenvolvedor. Tem que entrar em sua posição, tente se reproduzir. E depois de tudo, ele conseguirá se reproduzir - e haverá um golpe no orgulho devido a um erro admitido, ou não funcionará e você terá que (oh meu Deus, não!) Entrar em contato com uma pessoa viva que descobriu o problema e tentar obter mais informações. Tudo isso não pode ser chamado de agradável.
Ao mesmo tempo, escrever uma nova funcionalidade é um toque potencial de felicidade. Ainda não quebramos nada, não é nossa culpa. Estamos escrevendo um novo código para resolver novos problemas. Talvez tenha sucesso. Talvez receberemos elogios merecidos (bônus, promoção). Isso está mais próximo dos níveis superiores da pirâmide de necessidades humanas,
segundo Maslow .
Qual é a conclusão? O trabalho do programador deve ser equilibrado, não deve haver uma correção de bug. Todo programador precisa confiar no desenvolvimento de novos recursos de tempos em tempos. Sim, não há como escapar da correção de bugs, mas podemos pelo menos tentar alcançar um equilíbrio "quase nulo" de felicidade e infelicidade nesse assunto.
Refatoração
Trabalhar com um bom código é bom. Infelizmente, um bom código não cai do céu. É até impossível pegar e escrever da primeira vez. Temos que criar códigos bons e ruins, porque não há mais nada a fazer com isso. Aqui, os programadores fazem uma escolha: todos os dias, quando chegam ao trabalho, continuam sofrendo e trabalhando com código incorreto, ou ainda tomam e tentam criar um bom código a partir dele. No segundo caso, você frequentemente precisa lutar com uma liderança que não entende em que essas N horas de tempo poderiam ser gastas se novos recursos não fossem adicionados ao produto e os erros antigos também não fossem corrigidos. Sim, você tem que lutar. Felizmente, nesta guerra, temos argumentos: códigos concisos e bonitos são menos propensos a erros, seu suporte leva menos tempo (e custa menos dinheiro), se presta melhor a mudanças quando novos requisitos de negócios aparecem, etc. Além disso, essa guerra, em regra, não é longa: termina com algum tipo de compromisso como "não, não darei um mês para refatoração, mas vamos alocá-lo 2 horas por semana às sextas-feiras". Ok, isso é bom. Acabamos de ter um pedaço de felicidade. Sim, ele ainda precisará ser construído com suas próprias mãos, mas isso já se tornou possível.
Usando bibliotecas e ferramentas modernas
Muitos provavelmente conhecem a dor de ter que trabalhar em um projeto que está parado por algum motivo em um compilador (estrutura, biblioteca) há muitos anos. Eles nos explicam que, por essas e outras razões, é impossível atualizar para a nova versão aqui e agora, mas um dia, provavelmente, se funcionar ... O que você pode fazer? Bem, em primeiro lugar, devemos admitir para nós mesmos que as circunstâncias não estão a nosso favor e a situação nos torna mais infelizes do que poderíamos ser. Em segundo lugar, a mesma idéia pode ser manifestada pelas autoridades (ou pelo cliente). É improvável que alguém discuta isso. E, neste momento, você pode tentar negociar por si mesmo: por exemplo, tempo para os próprios testes, novas funcionalidades e refatoração. (Você pode aumentar o salário, mas, no começo do artigo, prometi deixá-lo fora de cena.)
A propósito, o tempo gasto em tais tarefas úteis pode realmente não apenas deixá-lo um pouco mais feliz aqui e agora, mas também eliminar as razões muito "assustadoras" pelas quais era impossível mudar para o uso de ferramentas mais recentes. A situação real da minha vida:
- Não temos certeza de que a transição para uma nova biblioteca não trará novos problemas ...
- E aqui eu escrevi 200 testes para o código usando esta biblioteca, vamos tentar passar e vamos iniciá-los.
- Hmm, vamos lá.
Após 2 semanas - uma nova biblioteca em produção.
Você provavelmente pode continuar a explorar outros aspectos. Mas a idéia geral é a mesma: algumas tarefas e circunstâncias tornam o programador mais feliz, outras - mais infeliz. Se houver mais segundos do que o primeiro - o humor e a produtividade do programador diminuirão, mais cedo ou mais tarde isso levará a problemas no projeto ou a sua saída da equipe. Portanto, o programador e seu gerente devem pensar não apenas no "bem global" do projeto, empresa ou usuário, mas também em como permanecer relativamente feliz com o desenvolvedor. Caso contrário, qual é o objetivo?