Assuma Intenção Positiva: meios de comunicação por texto não passam nuances da comunicação que geram laços e confiança, então assuma que a pessoa tem uma boa intenção ao se comunicar com você.
Aprendendo e Buscando soluções
Uma boa pessoa desenvolvedora também é um bom usuário:
Relate erros com evidências, dando uma boa descrição e mostrando evidências
Não tenha medo de ler. Leia código, leia a documentação, leia livros, leia os logs (principalmente de erro), leia bem as mensagens que recebe. Leia até entender bem;
Não tenha medo de escrever. Separe uma parte do seu tempo para documentar em lugares colaborativos algo que você sabe e inclusive suas dúvidas.
Conheça o nível abaixo da tecnologia que está usando, por exemplo, conheça bem a linguagem em que o framework que você utiliza é feito;
Não automatize apenas porquê você precisa fazer algo repetitivamente, automatize porque você pode errar processos manuais.
Reflita bem antes de dar respostas, peça um pouco mais de tempo se necessário.
Testes podem ser automatizados, mas evite excesso de abstrações deixando eles mais declarativos.
Melhor dois testes `test_function_should_return_integer` e `test_function_should_throw_exception` do que um único `test_function` que faz tudo isso a abstrai em parâmetros de ambos.
Valide todos os valores, não apenas as quantidades
Não confira apenas se o processo (função, request, chamada de API) foi executado sem erros, confira também se as informações estão onde devem estar (bancos de dados, caches, arquivos e etc);
Faça testes de integração, veja o código rodar como seu cliente verá;
Alterou uma chamada de integração? Verifique como o outro sistema se comportará.
Programação funcional é uma boa mesmo para não linguagens não funcionais, fique de olho neste conceito;
Antes do Commit
Remova código comentado antes do commit;
Confira cada alteração que está adicionando no commit;
Execute o linter e os testes;
Fazer PRs pequenos ajuda o revisor, se não for possível, faça commits com limites bem definidos;
Deixe os commits mais limpos possíveis:
Tente encaixar as alterações nos commits corretos, evitando commits desnecessários (ex: FIX TYPO, ADJUST COMMENT);
Não crie commits quebrados, por exemplo, commit 1 gera um erro, commit 2 corrige esse erro, neste caso é melhor juntar os dois commits;
Revisão de código
Faça o review do seu próprio PR antes de abrir aos outros;
Seja simpático nos reviews, o ambiente deve ter uma cultura acolhedora, não é fácil se expor colocando seu trabalho para revisão;
Tente discernir entre opinião e qualidade: as vezes a forma como algo foi feita não é como você faria, mas é tão boa quanto (ou até melhor).
Revisar no browser nem sempre é legal (apenas em coisas muito simples), revise no seu IDE predileto;
Não avalie apenas o código produtivo, testes são importantes de serem avaliados. (Ver seção sobre testes unitários);
Assuma Intenção Positiva (sim, de novo): comentários ao seu código não são ataques a sua dedicação e esforço, mas sim uma maneira de todos melhorarem e aprender mais.
Subiu em produção
Apesar de todo o esforço para desenvolver, a coisa só vale algo quando tiver em produção sendo utilizado;
Acompanhe a execução com mesmo afinco que você desenvolve, programa rodando vale mais que código sendo digitado;
Mesmo com testes unitários, integração e ambiente de staging, sempre valide em produção;
Monitorando
Crie alertas automatizados para sua aplicação
Não se acostume com falsos positivos, se um alerta pode ser ignorado ele deve ser desligado;
Use métricas para monitorar a saúde do sistema, leia os logs para descobrir a doença;
Troubleshooting (caçando bugs)
Problemas devem ser encarados com frieza, não entre em pânico!
Ao receber o relato de um problema valide você mesmo se o problema está ocorrendo como descrito;
Delimite os cenários onde o problema ocorre e o tamanho real dele;
Tome sempre decisões embasadas em dados coletados;
Restarts e rollbacks podem fazer você perder evidências, antes de fazer isso colete logs e dados;
O seu ambiente de desenvolvimento local deve rodar o mais próximo possível como produção para análises e debug;
Confira valores por inteiro, não compare por partes:
Ex: 1928293 é diferente de 1923293.
Confira as variáveis de configuração (ambiente, arquivos de configuração e etc);