Capítulo 1 – Uma filosofia pragmática

Em termos de abordagem pragmática, uma das coisas mais importantes é tomarmos para nós a responsabilidade total daquilo que executamos.

Seja em planejar uma nova iteração, seja ao desenhar uma nova arquitetura ou seja fazendo um simples código CRUD. Uma das coisas mais difíceis (sim é sempre difícil e aprendemos isso com o tempo e humildade) é admitirmos nossos erros (segundo os autores) e adiciono aqui algo não mencionado pelos autores, aceitar críticas e melhorar continuamente. Se lembram do “Hoje melhor que ontem e amanhã melhor que hoje”?

Devemos ter atenção as situações em que riscos devem ser ponderados com responsabilidade, por exemplo, quando a execução de algo não depende apenas de nós, como entregas de outras equipes, contato com clientes ou prestadores de serviços externos. Estas situações, devem ser tratadas com cuidado, pois não devem servir como desculpas, ou as famosas “muletas”, para possíveis problemas do dia a dia. Uma boa abordagem a ser praticada é antes que esse tipo de problema ocorra já estejam mapeados os casos de contorno para cada um deles, ou ao menos que esteja clara a situação que futuramente pode vir a impactar de alguma forma as atividades que desempenhamos.


Além de estarmos atentos aos problemas que possam ocorrer, caso algo saia fora do planejado e sairá com toda certeza, pensemos em opções para contornar o problema, seguindo a dica #3:“Apresente opções, não desculpas”, dos autores.

As vezes essas opções serão coisas como propor a escrita de testes (unidade/integração), propor fluxos de trabalho (as vezes engessados e dolorosos), refatorar um legado problemático (ainda que nem sempre as pessoas entendam o valor de um código manutenível e escalável), dentre outras. De toda forma, tenha sempre opções, é como dizia Henry Ford “Não encontre defeitos, encontre soluções. Qualquer um sabe queixar-se”.

Um ponto sobre responsabilidade e transparência não abordado, é a questão psicológica de Ancoragem(discutida no livro Digital Work in Analog World, irei escrever sobre ele no futuro),quando somos ancorados por vieses implantados por outras pessoas, imagine a seguinte situação:

Você é um desenvolvedor experiente, conhece bem o sistema em que trabalha e seu “chefe” chega e diz: – Essa funcionalidade sai hoje né? Certeza que você mata isso ainda hoje.Nesse momento seu psicológico é posto a prova, como uma necessidade de auto afirmação, ou de confirmação do que se é, e faz com que você seja ancorado a esta afirmação, fazendo com que você (nós) caia nela, mesmo sabendo que provavelmente terminar a tarefa naquele dia é completamente infactível, ou no mínimo implicará em horas extras, ou algum contorno não desejado para finalizá-la. 

O tipo de situação acima citado pode e deve ser enfrentado sempre, com base na transparência e sinceridade sobre a situação real daquilo em que estamos envolvidos. Quando alguém fizer este tipo de abordagem, seja honesto consigo mesmo. Justifique os motivos pelo qual as coisas não são tão “simples” como aparentam, ou proponha uma solução de escopo reduzido para o que é esperado como entrega de valor (uma hora falarei sobre MVPs). 

Antes de dar qualquer resposta sobre um problema, pare e pense se a resposta parece razoável ou se ela soa completamente estúpida, seja transparente, não pense apenas no problema, pense em soluções (inclusive as de contorno, elas podem salvar o seu dia) e não se deixe ancorar, isso não faz mal apenas a você. 

Resumindo, dizer que o gato (ou cachorro) comeu seu código não é uma desculpa honesta, pense sempre em formas de superar as barreiras que venha a enfrentar e não apenas nas barreiras.

Se você gostou desde texto compartilhe e comente! =)

Leave a Reply

Your email address will not be published. Required fields are marked *