4 Coisas que aprendi com Poker e aplico como desenvolvedor de software

Há três anos, eu resolvi estudar poker e me dedicar mais a esse jogo que gosto bastante. E nesse processo, reparei alguns pontos em comum do poker com o meu dia a dia na área de TI, que inclusive podem ser facilmente aplicados em outras áreas da vida, porém, vou exemplifica-los voltados para o desenvolvimento de software.


1 - Simplicidade:

Poker é um jogo simples. Muitas pessoas se atrapalham com esse fato, e pensam que os blefes gigantescos ou as "tricky plays" (fingir muita fraqueza com uma mão boa, por exemplo) são o único caminho para a lucratividade, quando na verdade é apenas um jogo de lógica, onde você mapeia quais cartas os seus oponentes podem ter de acordo com as jogadas.

No desenvolvimento de software, muitas vezes vejo que uma solução simples costuma ser a melhor, mas queremos estar na “hype” e usar aquele novo framework ou um novo paradigma que quase ninguém usa. Não quero invalidar essas opções, mas acredito que são ferramentas as quais podem ser usadas em alguns cenários diferentes, como quando focamos em aprender algo novo ou quando uma solução mais simples não for a melhor opção. Isso tanto no jogo quanto no desenvolvimento.

Às vezes as coisas são o que apenas parecem ser, sem nada demais.
Charles Bukowski

2 - Use a lógica:

Certo, falei que Poker é basicamente um jogo de lógica, mas o que isso significa? Quando jogamos uma mão de Texas Holdem (a modalidade de Poker mais jogada no mundo) todos na mesa recebem 2 cartas aleatórias, e começamos sem ter nenhuma idéia do que nosso oponente pode ter. Para facilitar nossa leitura é comum usar a seguinte técnica: eliminar as mãos que não fazem sentido. Analisando cada ação dos oponentes, como por exemplo aumentar ou pagar a aposta, podemos somar nossas observações e fazer uma linha do tempo imaginária de tudo o que aconteceu. Aos poucos, afunilamos o que foi observado até sobrar poucas possibilidades de mãos, e assim tomamos a melhor decisão.

Muitas vezes, durante o desenvolvimento de uma feature, ou em um throubleshooting, ficamos travados numa situação parecida com o começo de uma mão de Poker: temos uma infinidade de possibilidades de execução, e por muitas vezes nos perdemos em nossos pensamentos -(é incrível a quantidade de tempo que podemos desperdiçar nessas situações). Usando a técnica de eliminação, vamos cortando as possíveis causas até sobrar um cenário muito mais fácil de ser entendido. Pode parecer óbvio o que eu estou falando, mas quando nos deparamos com uma situação complexa e crítica, esquecemos de usar ferramentas tão elementares.


3 - Princípio é mais importante que técnica:

No poker temos princípios básicos como aposta por valor e aposta por blefe e várias jogadas com nomes Shove, check-raise, Flat, Float, 3-bet, Squeeze, etc., que possuem nome por serem jogadas estudadas e definidas, basicamente são técnicas e são muito úteis quando você entende como usa-las aplicando um Princípio, princípio é o motivo pelo qual você está usando as técnicas, sem isso, elas podem ser inúteis ou até nocivas para o seu jogo, pois vão fugir do primeiro tópico desse post, simplicidade.

A mesma coisa acontece no desenvolvimento de software. Se você usar técnicas, como o Design Patterns (Builder, Singleton, Factory), e não souber o princípio que está atrelado, primeiro que você pode aplicá-las nos momentos desapropriados e que não fazem sentido o uso, segundo que ainda que você use num momento certo, pode implementar de maneira errada. Por isso que na programação é mais importante focar em princípios claros como, por exemplo, SOLID, DRY e DDD.


4 - Longo Prazo:

Aprendi que não é possível ganhar sempre. Na realidade poker é um jogo de pouca vantagem à curto prazo, você não controla as cartas que recebe e não pode blefar toda hora. Existe uma certa dependência da situação e a única maneira de obter vantagem é procurar não cometer erros e aproveitar quando seus adversários os fazem, muitas vezes os erros que eles cometem não compensam o fator aleatório do jogo. Ou seja, mesmo quando joga-se perfeitamente ou perto disso, mesmo quando se é um profissional de poker, você pode perder ou empatar a maioria dos dias. É preciso paciência e planejamento para continuar fazendo o que é certo, muitas vezes, até que a matemática se equalize.

Se eu jogar um cara ou coroa com você valendo R$ 1,10 cada vez que você ganhar e R$ 1,00 cada vez que eu ganhar, pode acontecer de em dez rodadas eu ganhar R$ 10,00. Porém se jogarmos 10.000 vezes, com certeza você vai sair ganhando.

Acho que não preciso fazer nenhuma analogia com TI nesse ponto, é evidente que se nós desenvolvedores não pensarmos no futuro da nossa aplicação, além de deixarmos ela rígida e frágil a mudanças de negócio, vamos sofrer muito com o retrabalho por, simplesmente, sair codando sem pensar em acoplamento, complexidade, escalabilidade e coisas que só vão te dar problema quando o volume de features novas ou de usuários novos for algo que você não planejou.


A idéia desse post é trazer experiência que ganhei no poker para o desenvolvimento de software e mostrar que podemos fazer relações e analogias com qualquer coisa pois, quando você se dedica a algo, com certeza isso te faz evoluir como pessoa e é possível aplicar em outras áreas da sua vida.

E você? tem alguma experiência que te ajuda no dia a dia? comenta ai :)