Agora eu me tornei o destruidor de mundos
2017-10-24T21:07:41+01:00

Entre os dias 5 e 11 de outubro eu estive em Belo Horizonte para participar da PythonBrasil 13. Entre rever amigos, fazer novos e participar de excelentes discussões, tive a honra de apresentar um keynote aos mais de 570 participantes. Tenho que agradecer muito à organização da PythonBrasil pelo convite e pela oportunidade de apresentar e conversar com uma das minhas comunidades favoritas.

A responsabilidade de subir no palco se tornou ainda maior após a publicação da grade de palestras. Palestras excelentes, por exemplo sobre o projeto Serenata de Amor, um dos projetos recentes que mais admiro, palestras com feras da comunidade. Eu decidi nem tentar superar o conteúdo técnico dessas palestras.

Esse ano, aliás, fazem dez anos que participo da comunidade pythonista brasileira. Não consigo imaginar uma maneira melhor de comemorar essa década do que conversando com todos os presentes e apresentando um keynote.

O vídeo da palestra vai ser publicado em breve, mas abaixo vou transcrever minha palestra para quem tiver interesse.


TUDO COMEÇA NO RIO


Eu gostaria de começar contando uma história que se passou no Rio de Janeiro, na década passada.

Na zona oeste do Rio de Janeiro, há um bairro relativamente novo, criado em 2004, chamado de Gericinó. Esse nome pode soar familiar para alguns, mas o nome do bairro que antes englobava essa área é com certeza mais famoso: Bangu.

Um dos motivos pelos quais os nomes são famosos é devido ao complexo penitenciário que se encontra alí. O Complexo Penitenciário de Gericinó, antigamente chamado de Complexo Penitenciário de Bangu, é composto por várias unidades, presídios, cadeias, hospitais penais entre outros. Duas das unidades penitenciárias do complexo possuem sistemas eletrônicos e automatizados para controle de acesso.

Uma determinada noite, o engenheiro de plantão recebe uma ligação: “O sistema está fora do ar. Nenhuma das portas está abrindo.” relata a pessoa no outro lado da linha. Durante o desenvolvimento, ele fez um bom trabalho e em caso de falha as portas permanecem fechadas ao invés de abertas. “A troca de turno dos agentes penitenciários está atrasada porque não conseguem sair ou entrar no presídio”, adicionou a pessoa no telefone. A urgência do problema era clara.

O engenheiro começa a investigar o problema. Todas as portas estão apresentando falhas, então o problema tem que ser na unidade central de controle, pensou, então gastou seu tempo analisando esse computador. Conforme o tempo passava, aumentava a pressão pela troca de turno dos agentes, ele mantinha isso em mente constantemente, mas era lembrado pelos operadores ao seu redor. Após um bom tempo, decidiu pensar quais outros cenários causariam todas as portas a travarem fechadas.

Foi então que lembrou do comportamento do sistema em caso de rebelião: todas as portas são travadas, luzes de emergência e sirenes são ativadas. Exceto pelas luzes e sirenes, estaria o sistema em modo “rebelião”? E se a falha fosse nas luzes de emergência e sirenes? Eureca, ele descobriu o que havia acontecido: um dos operadores havia acionado o botão de emergência (para casos de rebelião), infelizmente o sistema de luzes e sirenes tinha sido desativado por outra equipe de manutenção, mas falharam em documentar a mudança.

O engenheiro estava extremamente frustrado: acordado durante a noite, por um problema causado por um dos próprios operadores, inflamado pela mudança do sistema e falha de comunicação e documentação. Que perda de tempo. Retornou o sistema ao modo de operação normal e voltou a sua casa. Ele continuou a trabalhar nesse projeto por meses e o mesmo cenário de falha voltou a acontecer duas vezes.

Imagine-se no lugar desse profissional. Imagine a frustração. Tente lembrar de alguma situação semelhante, que também te deixou frustrado.

Como eu esperaria agir em uma situação dessas? Manter a calma, coletar dados dos operadores e técnicos, documentar e comunicar a situação para os stakeholders, estipular um prazo para as sessões de troubleshooting e anunciar updates, escrever um relatório detalhado sobre a falha e garantir que ações necessárias fossem tomadas para evitar reincidências.

Como você pode ver, o modo como eu agiria e o modo como o engenheiro agiu são bem diferentes. Pois é, eu era um engenheiro muito jovem na época e não sabia o que sei hoje.

Eu gostaria de apresentar cinco ideias que me ajudam a evitar os erros do passado. Mas antes eu gostaria de falar um pouco sobre a fonte dessas ideias.


A BOMBA


Você reconhece a referência de se tornar o destruídor de mundos? Conhece a origem dessa frase?

A versão mais conhecida dela é em inglês e se tornou conhecida quando utilizada pelo físico Julius Robert Oppenheimer. Oppenheimer era diretor do Laboratório Los Alamos nos Estados Unidos, durante o Projeto Manhattan na década de 1940. O projeto visava criar a bomba atômica e Oppenheimer era o responsável.

Em 1945, quando testemunhou a primeira explosão nuclear artificial, Oppenheimer lembrou da seguinte frase: “I am become Death, the destroyer of worlds.” - “Eu me tornei a morte, a destruidora de mundos.”

Essa frase, no entanto, é uma tradução de um verso do texto chamado Bhagavad Gita. O Bhagavad Gita, ou somente Gita, é um poema épico de 700 versos escrito em sânscrito. E faz parte do livro Mahabharata, que contém vários outros épicos. Ele é um texto religioso e faz parte da base canônica para a filosofia Hindu.

“Peraí Rodolpho! Você vai dar um sermão religioso? Vai rezar uma missa? Que papo é esse de religião?”

Quem me conhece sabe que eu não sou uma pessoa religiosa, no sentido mais comum da palavra. No entanto, eu cresci com uma influência religiosa cristã muito forte na minha família direta. Eu frequentava reuniões com cunho religioso, lia livros sobre o assunto e fazia apresentações similares a essa palestra. Só havia um problema: eu não conseguia acreditar como esperavam.

Eu não duvidava que existiam lições morais importantíssimas nos textos religiosos e que nesse sentido eram textos verdadeiros. Mas eu não consigo acreditar na veracidade histórica do que era ensinado.

Com o tempo eu deixei de frequentar os encontros e me distanciei da religião. Por outro lado, todos aqueles anos lendo e destilando lições práticas acabou se tornando um costume e eu continuo a fazer isso até hoje.

Eu abordei o Bhagavad Gita como um leigo curioso, em busca de ideias e aprendizado que poderia colocar em prática na minha vida. Não procurando me converter.

Quero deixar claro que eu não sou treinado academicamente em filosofia Hindu. Não era uma matéria optativa na escola de engenharia - não tínhamos Sistemas Operacionais segundo Krishna, ou Hinduísmo para Concretos 1. O que sei sobre a filosofia, a religião e a mitologia foi resultado de pesquisa e muita leitura. Por favor não aceitem a minha palavra como autoridade, mas sim meu convite para ler o livro e aprender como eu.

Então não se preocupe! Esse não será um texto religioso e eu vou evitar ao máximo usar palavras ou conceitos desnecessários aos pontos que quero fazer. E eu não vou cobrar conversão, nem dízimo no final!


SEQUESTRO DAS AMÍDALAS


Eu preciso dar um aviso sobre dois pedacinhos muito interessantes do cérebro humano. Esses se chamam amídalas e algumas de suas funções estão relacionadas à nossa reação emocional. Parte dos estímulos que o cérebro está processando são também recebidos pelas amídalas e caso tais estímulos sejam julgados como um perigo, as amídalas reagem antes que o córtex, ou a parte racional do cérebro, consiga instruir o que fazer.

Uma das hipóteses sobre porque disso é o resultado do processo de seleção natural: imagine um homem primitivo observando a mato alto na savana se movendo. Por um lado, ele poderia permanecer e tentar descobrir o que está movendo. Por outro, melhor fugir e não descobrir o leão que se esconde ali. As amídalas são responsáveis por sequestrar a ação do cérebro racional - pare de olhar o mato - e fazer o humano reagir ao perigo - sai correndo!

Infelizmente para o cérebro o estímulo ao ver um leão é tão verdadeiro quanto o estímulo de uma idéia e apesar de diferentes são ambos capazes de ativar a reação da amídala contra perigos.

Fomos de um texto religioso à biologia, por que? Porque algumas das ideias contidas na filosofia Hindu são extremamente diferentes das ideias contidas nas escolas filosóficas mais comuns no Brasil. E quando questionamos os conceitos mais sólidos nas nossas mentes, é muito fácil esse questionamento ser interpretado como um perigo e já vimos como as amídalas gostam de perigos!

Mas é possível ter auto-controle: respire fundo, não reaja instintivamente, deixe a ideia “marinar” no cérebro por algum tempo para depois agir. Assim você aumenta a chance que o seu cérebro racional processe a ideia e tome uma ação, ao invés de tomar uma reação irracional, só para fazer a ideia, ou o perigo, desaparecer.

É preciso esse auto-controle para interpretar e entender filosofias muito diferentes. Um exemplo, com terminologia bem “relaxada”, um dos poderes mágicos que uma pessoa pode obter com o avanço espiritual se chama Garima e é a capacidade de se tornar infinitamente pesado.

Eu gosto de usar essa desculpa quanto vejo o tamanho da minha barriga: é só Garima.

Mas piadas a parte, a ideia de se tornar infinitamente pesado é muito alienígena ao nosso dia-a-dia, então o mais fácil, a reação emotiva, é ignorar e não interpretar - entra por um ouvido, sai pelo outro. Então novamente, preste atenção a si mesmo e reaja racionalmente a ideias.



PRÍNCIPE GUERREIRO


Mas vamos retornar ao Bhagavad Gita. Além de ter sido mencionado por Oppenheimer, era também um dos livros favoritos de Gandhi. Há inclusive um artigo na Wikipedia para listar a influência do livro em autores, pensadores e outros.

O texto é a conversa que o príncipe Arjuna e seu amigo, e condutor de sua carruagem Krishna. Krishna é um avatar, ou uma manifestação, de Vishnu, que é uma das três deidades mais importantes no hinduísmo. A conversa acontece antes de uma grande batalha pelo trono de Hastinapura.

Arjuna pede para Krishna estacionar a carruagem entre os dois exércitos para observar os guerreiros. Observando os dois exércitos, Arjuna sente compaixão pelos soldados - ele vê pais, avós, filhos, tios, amigos, e a dor que viria por consequência da guerra. Arjuna começa a se perguntar se vale a pena a batalha. Ele diz preferir morrer a ter que tirar a vida de um dos homens ali. Se pergunta como justificar o pecado de tirar uma vida em guerra por um trono. Ele pergunta a Krishna o que fazer.

Sendo um dos livros favoritos de Gandhi, conhecido pela sua participação no movimento de independência da Índia através de desobediência civil não violenta, quando eu terminei de ler esse capítulo minha expectativa era clara: “mas é claro que a paz vai ser preferida à violência. Claro que Krishna vai concordar com Arjuna”. Mas surpresa!! Krishna defende exatamente o contrário! Arjuna DEVE lutar, DEVE enfrentar guerreiros inimigos, DEVE cumprir o seu “papel”.

No restante do livro Krishna vai explicar a Arjuna diversos conceitos da filosofia Hindu e como fazer “a coisa certa”. No caso de Arjuna, fazer a coisa certa era participar da guerra, mas aí está o valor do texto: as explicações de Krishna poderiam ajudar qualquer um, de acordo com essa visão de universo, a fazer “A” - maiúsculo - coisa certa.

Dois capítulos do livro e eu já sabia que essa seria uma leitura e tanto. E eu recomendo a leitura a todos, mas antes que você abra uma aba nova no seu navegador para comprar o livro acompanhe comigo as ideias apresentadas por Krishna que podem te ajudar em sua carreira.


EQUILÍBRIO E MODERAÇÃO


A primeira ideia é apresentada logo no começo do livro. Krishna explica qual o tipo de pessoa é capaz de alcançar seus objetivos: a pessoa equilibrada, moderada; a pessoa que evita os extremos e pratica auto-controle.

Um exemplo direto dessa ideia é o quanto uma pessoa se dedica ao trabalho. A dedicação ao trabalho é necessária para chegar ao sucesso, mas se dedicar exclusivamente ao trabalho pode consumir a saúde e o convívio social de uma pessoa.

Meu gosto por trabalhar com computadores começou no final da infância e sempre vi o tempo que passava na frente de um terminal como diversão. Isso tornou muito fácil perder o controle sobre quanto tempo investia no trabalho, resolvendo problemas no computador. Além do impacto na saúde - afinal 80 horas por semana no computador tem um custo - houve também o impacto na vida social. O perigo de tornar seu hobby em trabalho é ser bem sucedido: o hobby se torna trabalho! O que fazer durante sua folga? Trabalhar mais?

Outro tipo de extremismo muito comum é a convicção plena em determinada ideia. Geralmente, esse tipo de convicção serve como um bom indicador de pontos fracos - afinal aquilo sobre o qual você tem certeza pode ser seu ponto-cego. A posição extrema que algo precisa necessariamente ser verdade requer muita atenção!

Lembram da falha no sistema de controle do presídio? Eu assumi duas coisas que atrasaram a resolução do problema: primeiro, as portas não abrirem eram comportamento indesejado do sistema; segundo, por afetar todas as portas, o problema devia ser causado pelo servidor central do sistema. Eu ignorei a possibilidade do comportamento desejado ser as portas fechadas. Também ignorei a possibilidade de falhas múltiplas em outros componentes não centrais. Essas convicções se tornaram pontos-cegos.

Eu vou propor um desafio aqui: assista o vídeo abaixo. Nele há seis jogadores em dois times jogando e brincando com bolas; um time usa camisas brancas e o outro time usa camisas pretas. Agora vem a parte difícil, eu quero que você conte quantas vezes os jogadores de branco passam a bola entre si, só os jogadores de branco.

https://www.youtube.com/watch?v=Lw-YPKR0grk

Quantos passes você contou?

Se você contou doze passes, parabéns, acertou. E se você acertou, tenho outra pergunta: você reparou no rapaz com uma forca no pescoço que atravessou o vídeo?

Esse vídeo foi parte de uma campanha de prevenção de suicídio e replicou um teste já conhecido sobre atenção seletiva. O teste deixa claro como nós somos capazes de nos concentrar em algo e ignorar o resto.

O ideal é buscar o equilíbrio. Se você tem certeza de algo, então exercite essa certeza e evite que essa se torne um ponto-cego, como todas as pessoas vestindo preto no vídeo.

Seja o desenvolvedor que apesar da certeza que a infraestrutura funciona muito bem dedica tempo estudando e aprendendo sobre ela. O mesmo vale para código e bibliotecas - você tem certeza que sabe como o roteador de requisições do django funciona? Dedique um tempo estudando o código e estudando os bugs consertados recentemente.

Aqui vão algumas das convicções extremas que vejo com frequência e servem de alerta:

-   “Essa biblioteca/código/infra sempre funcionou, então está funcionando agora”
-   “O teste passou, então meu código está funcionando”
-   “O release/rollout terminou, então minha feature foi lançada”
-   E o meu favorito: “Eu fiz backup, então estou seguro contra falhas”

Cuidado com posições extremas sobre qualquer um desses assuntos. Mas digamos que você já tenha tomado esse passo: você exercita as suas certezas e verifica que essas permanecem verdadeiras, mesmo quando você está disposto a lutar pelo oposto. Aliás, atenção: exercitar sua certeza querendo que ela seja verdadeira é só metade do exercício. Você precisa atacar suas certezas com vontade de se provar errado!

E se você fizer isso, fortalecer suas ideias, agora é só esperar os resultados positivos, certo? Foca no trabalho que os resultados caem do céu, certo?


O DIREITO DE TRABALHAR


Infelizmente Krishna discorda dessa estratégia. Esse é a segunda ideia que me ajudou e foi, aliás, a ideia mais difícil para eu entender por soar tão estranha - lembrou das amídalas?

_“Você tem o direito de cumprir seu dever prescrito, mas não aos frutos da ação. Nunca se considere a causa dos resultados de suas atitudes.“_

Como assim? Como eu foco no meu trabalho e não no resultado? Eu não trabalho para obter o resultado, tanto no aspecto de projeto (entregando um produto) como no aspecto de carreira (recebendo meu salário)? Como não focar nessas coisas?

O que Krishna quis dizer a Arjuna é que há uma separação entre realizar o seu trabalho da melhor maneira possível e somente almejar os resultados dele. Como desenvolvedor, é a diferença entre focar em escrever o melhor código e testes possíveis, e focar em querer ser uma startup de sucesso, ou obter uma promoção.

Essa ideia é extremamente útil pois pode te blindar contra resultados diferentes. Seu projeto foi cancelado? Os usuários não se interessaram? Sua biblioteca nunca foi importada? Isso não deve afetar como você se sente sobre seu trabalho.

Como Site Reliability Engineer, eu foco em fazer o meu trabalho da melhor maneira possível, ou seja construir o melhor ambiente de produção, os melhores sistemas distribuídos e prestar a melhor consultoria para os outros times. Não me concentro nas promoções ou em me comparar com outros SREs.

Durante minha aventura consertando o sistema de controle do presídio, eu desperdicei tempo útil pensando nos efeitos do meu trabalho - nos agentes, por exemplo, que esperavam para realizar a troca de turno. Se tivesse investido esse tempo na resolução do problema, ao invés de me preocupar com o que estava fora do meu controle, talvez teria resolvido a situação mais rapidamente. De certa forma, ao me preocupar com os efeitos eu os tornei piores.

Além da perda de tempo, como eu já disse, outro efeito colateral da expectativa por determinado resultado é a frustração com resultados diferentes. Se o objetivo de seu trabalho é receber uma promoção ou um aumento, como você se sentirá se isso não acontecer? O seu trabalho não foi bom o suficiente? Ou será que outro fator impediu sua promoção? E qual seria o impacto eu sua motivação não saber a diferença?

Ou digamos que você consiga dizer a diferença e há um motivo bom para que você não seja promovido ou receba um aumento. Como lidar com isso?

Como lidar com a ligação no meio da noite que o sistema de automação de presídio está fora do ar?

Como um principe deve lidar com o fato que a batalha que liderará causará inúmeras mortes?

Cada um de nós terá que enfrentar seus próprios desafios.


ADVERSIDADE VS. OPORTUNIDADE


A recomendação que Krishna tem para Arjuna é deixar para trás as preocupações da mente e do coração, mas ver a oportunidade de cumprir o seu trabalho. Lembram do aviso sobre a amigdala? Infelizmente, a reação instintiva a um perigo ou preocupação não é analisá-lo. Com auto-controle, você pode ver a oportunidade escondida na adversidade. Essa é a terceira ideia que aprendi do livro.

Tenho uma lição de casa: se você pratica meditação, será um exercício simples; se for sua primeira vez fazendo algo do tipo, não desista de primeira.

Hoje à noite, encontre um local onde possa ficar sozinho, em silêncio. Sente-se de maneira confortável, mas não confortável demais - você não quer cair no sono! Respire fundo, feche seus olhos e lembre de algo que aconteceu recentemente contra a sua vontade - não passou em um processo seletivo, seu ambiente de produção ficou fora do ar, marretou o banco-de-dados de produção e dados foram perdidos. Lembre-se de como você se sentiu ao tomar conhecimento e como reagiu emocionalmente em seguida. Identifique sua reação emocional e, em retrospecto, será mais fácil separar “o que aconteceu” de sua emoções.

Agora analise a adversidade divorciada de suas emoções. Procure por oportunidades para aprender, para superar. Se estiver difícil de ver essas oportunidades, essas perguntas podem ajudar: “como posso evitar que isso aconteça novamente?” “se isso acontecer novamente, de que outras maneiras posso reagir?”

Infelizmente, quando a falha no presídio aconteceu, eu não conhecia esse exercício. Ao invés de aproveitar as oportunidades, eu deixei a frustração, minha reação emocional, ser o principal fruto.

Hoje em dia, recomendo a todos os times que publiquem relatórios post-mortem para seus projetos. Você já escreveu um post-mortem?


POST-MORTEM


O objetivo ao se escrever um post-mortem é garantir que determinado evento seja documentado, que todas as causas raíz são bem compreendidas e que ações preventivas efetivas são tomadas para reduzir a chance e/ou o impacto de reincidência. Mas é importante lembrar em focar no problema e nos sistemas, não nas pessoas, não em distribuir culpa.

Então como escrever um post-mortem? O que colocar neste documento? Vamos então pensar no caso do presídio.

Como vivemos na época do TL;DR - too long; didn’t read, ou muito longo; não li - seja caridoso com as pessoas que querem um resumo rápido do ocorrido, bem rápido mesmo: “o que”, “quando” e “porque”. Por exemplo:

_“Modo de pânico não ativou alertas visuais e sonoros.
23:00 2005-07-01 a 04:00 2005-07-02
Motivo: Manutenção não documentada desabilitou sistema de sirenes e luzes”_

Dessa forma, se alguém bater o olho no documento já sabe o mínimo necessário sobre o evento. Em seguida, apresente uma linha do tempo, com o máximo de detalhes o possível, do evento. Geralmente, para sistemas mais complexos ou distribuídos será necessário envolver outras pessoas e outros times - não se esqueça de incluir o ponto de vista deles em seu documento.

Tente obter o máximo de informação o possível para essa sessão de seu post-mortem. Quanto mais informação disponível, mais fácil será identificar o plano de ação do documento. Até aqui o documento é um trabalho de historiador - dependendo de quanto tempo o time esperou para escrever o post-mortem, o trabalho pode ser de arqueologia de logs, que não é nada divertido! Não deixe pra depois!

Após a arqueología terminada, hora de investigar a causa raíz, ou causas, do ocorrido. Dedique o tempo necessário para investigar todos os motivos, mas um aviso: foque sempre nos sistemas e processos, não nas pessoas. Isso não quer dizer que falhas humanas não aconteçam: quem nunca passou por aqueles segundos de adrenalina quando um sistema cai e você acabou de fazer alguma mudança? Você implora na sua mente: “por favor, não seja eu, que não seja eu, não eu”.

Se você passou por essa situação, com certeza saberá que a última coisa que te ajudaria, ou ajudaria os outros, ou evitaria que uma falha acontecesse no futuro, seria te responsabilizar como a pessoa que realizou uma mudança. Portanto, foque nos sistemas e processos: se alguém usou uma ferramenta de determinada maneira e a falha ocorreu, a ferramenta deveria ter evitado o problema.

Lembra da falha que a Amazon S3 teve no início desse ano? Eles publicaram um relatório e identificaram o que iniciou o problema: um operador cometeu um erro ao digitar um comando, enquanto seguia um playbook, e a ferramenta removeu mais servidores do cluster do que era esperado. Pergunta: quem deveria ter detectado e evitado o problema?

A ferramenta! A ferramenta aceitou entrada inválida e/ou não pediu confirmação antes de realizar uma operação que praticamente desligaria um subsistemas. A ferramenta precisava de melhorias.

Ao escrever a causa do problema dessa forma - focando nos processos e sistemas - fica mais fácil trabalhar para evitar ou minimizar os impactos de recorrências. O objetivo é conseguir listar todos os remédios que deverão ser aplicados para tratar o sistema.

Prepare uma tabela, com no mínimo três colunas: uma descrição da ação a ser tomada, o nome do responsável e um link para acompanhar esse trabalho.

Alguns times e empresas usam mais colunas para classificar os itens, ou destacar prioridades, mas no mínimo você precisa dessas três. Explique o que é que vai ser feito. Por quem será feito. E onde outros podem acompanhar o trabalho - pode ser um link para um Issue no github, no Jira, onde for que seja.

Escreveu esse documento, terminou! Não! É importante que todos os times envolvidos tenham a oportunidade de revisar o documento, oferecer comentários e sugestões, e se possível agende uma apresentação rápida com todos. Precisa mesmo? Você não vai acreditar quantas pessoas não vão ler seu documento até você pegá-las pela mão e guiá-las.

E por último, garanta que o plano de ação seja cumprido. Eu já vi post-mortem que tinha um item de ação e no issue desse item alguém comentou: “ou conserta esse problema, ou vai dar m…. de novo.” Algumas semanas mais tarde o autor do comentário ganhou o troféu do “eu avisei”.

Mas todo esse esforço vale a pena? Você pode pensar: eu trabalho em um time pequeno, estou sozinho, talvez uma outra pessoa. Nada muda no meu software, na minha infra, nos meus usuários. Se der algum problema, eu vou saber o que fazer, mas não vai acontecer, nada vai mudar.


O DESTRUIDOR DO UNIVERSO


Para responder essa pergunta, chegamos à quarta ideia contida na frase que o Oppenheimer lembrou após o teste da primeira arma nuclear e ao principe Arjuna. Arjuna escutou Krishna falar por algum tempo e já tinha se convencido que o seu amigo era mais do que só condutor de carruagem, então ele pede para Krishna mostrar sua forma divina. O que Arjuna vê é algo grandioso demais, ele não consegue entender o que está vendo, entre outras visões, vê seu exército e o inimigo sendo engolidos por Krishna.

Arjuna se assusta, pede para Krishna explicar o que isso significa, a resposta é a frase que Oppenheimer citou, mas uma tradução melhor é a seguinte:

_“Eu sou o tempo envelhecido para destruir o mundo, embarcado no curso da aniquilação do universo.”_

O que Krishna quis dizer é: “Eu posso esconder minha forma verdadeira, posso esconder meu lado assustador, posso voltar a ser seu amigo, mas isso não muda uma verdade: o tempo está aqui pra todos e tudo é passageiro”.

Então você pode querer se apegar a essa ideia que nada vai mudar, que nunca haverá uma falha, porque o passado foi bom, sem mudanças, sem falhas. Mas você não pode enganar o tempo e ele é quem vai trazer ótimas surpresas!

Nós já conversamos sobre o perigo das certezas. Eu diria que a pior certeza é a certeza que você não se engana, principalmente sobre as coisas que não vão mudar.

Os desenvolvedores mais experientes já terão aprendido a lição e se preparado para mudanças inesperadas. Infelizmente se fossemos conversar sobre os métodos para minimizar o impacto de mudanças, precisaríamos de alguns meses de curso.

Voltando ao problema exemplo, ao publicar o procedimento de manutenção no presídio, um dos requisitos era realizar todo o processo durante um único turno da equipe de operação. Não imaginávamos que teríamos uma troca de equipe e, dessa forma, seria necessário passar informação de uma equipe para outra sobre quais sistemas estavam fora do ar. Muito menos manutenções com mais de um dia de duração.

Lutar contra essas mudanças é um gasto de energia em vão. Melhor é se preparar cedo para adaptar e adaptar quando necessário. Quando estiver escrevendo a especificação do seu sistema, dedique um tempo a identificar todas suas premissas - em quais outros times, ferramentas e sistemas o projeto depende? Em quais pessoas? Identifique os pontos de falha não só no design do seu sistema, mas também na execução do projeto.

Com os riscos documentados, o próximo passo é imaginar como reduzir o prejuízo no pior caso. Por exemplo, você é o desenvolvedor principal de um sistema; há outros colaboradores, mas você é quem sabe de tudo. Qual é o risco? Você ficar indisponível. “Ah mas isso nunca vai acontecer!” - sério, você é a pessoa que nunca fica doente e está imune a acidentes? Muito prazer! Para o resto de nós, como minimizar esse risco? Documente e treine os demais colaboradores, evite silos de informação e pratique - fique uma semana fora, intencionalmente, deixe que os outros tomem o seu lugar em uma situação controlada, para que quando a situação fora de controle aconteça eles saibam o que fazer.

Outra dica valiosa é compartilhar sua lista de riscos e reações com outras pessoas o quanto antes. Quando você está escrevendo algo sozinho, é muito fácil de se esquecer de outros pontos de vista. Outras pessoas podem te ajudar a detectar premissas que são tão fundamentais para você que passam despercebidas como tais.

Agora olhe todos esses métodos que mencionei e todas as instruções que Krishna receita a Arjuna, apesar de serem ótimas ferramentas para equipes, o foco principal é em melhorar a si mesmo.


VOCÊ É O RESPONSÁVEL


Krishna sabia que o que esperava por Arjuna não seria fácil. Fácil seria largar o campo de batalha e não ter que enfrentar o desafio militar, mas muito mais moral, que o aguardava. Essa é na minha opinião a lição mais importante do livro, a quinta ideia:

_Não são obstáculos que nos impedem de atingir nossos objetivos, mas nós mesmos ao ter caminhos mais fáceis em mente._

De novo: Não são obstáculos ou dificuldades que nos impedem. Não são os outros, não é o sistema. Somos nós mesmos ao seguir caminhos menos desafiadores.

A PythonBrasil tem um certo gosto de ano novo para mim. Todo ano novo vem com ideias grandes, tudo o que vamos fazer diferente, o que vamos criar de novo, é uma oportunidade de se reinventar. Conferências de qualidade com amigos têm esse efeito também: todos os projetos novos que eu vou tirar do papel, tudo que vou fazer de maneira diferente, o potencial de revolução profissional na conferência é incrível!

Infelizmente, assim como ano novo, o dia 2 de janeiro chega. Para a 13a PythonBrasil, o dia 12 de outubro chega, um feriado para atrapalhar ainda mais. Espero que a sexta-feira 13 de outubro não tenha sido um filme de horror para o potencial que tínhamos alí.

Uma boa parte, senão todas as oportunidades que você terá vão exigir esforço, trabalho e dedicação. Assim como os projetos mais interessantes que foram divulgados durante a conferência foram resultado também de esforço e dedicação. Não será fácil, por isso não se deixe distrair com caminhos mais fáceis.

Já que estamos falando do que é fácil e difícil, fácil é palestrar e falar. Difícil é desenvolver e manter a disciplina e auto-controle para focar no seus objetivos.

De fato, será mais difícil manter essa disciplina por longos períodos de tempo, durante projetos longos, do que por intervalos mais curtos e em projetos menores. Acredite, isso vale para todos, eu inclusive. Esse texto já está longo e com certeza já está cansativo ficar sentado, lendo. Então acorda aí que vou dizer qual o truque que eu uso para alcançar esses objetivos de longo alcance:

-   Escreva claramente onde você quer chegar, inclusive os critérios de sucesso.
-   Imagine seu caminho até esse destino, tudo que você precisa aprender, desenvolver, testar e entregar até seu objetivo.
-   Quebre esse caminho em blocos de três meses.
-   Para cada um desses blocos, imagine um começo, um meio e um fim. Descreva o que você vai fazer, suas premissas e como você vai minimizar os riscos. Trabalhe para entregar o que foi planejado e, no final dos três meses escreva um post-mortem (mesmo em caso de sucesso!)
-   Estude o post-mortem e ajuste o seu plano: atualizando os ciclos futuros com o que você aprendeu (talvez você demore mais ou menos para fazer algo).

O objetivo é quebrar a viagem longa e árdua em caminhadas curtas, mais leves, e aprender durante o processo. Se você fizer isso, dividindo seu longo projeto em etapas menores, durante a sua viagem entre o aqui e agora para o seu objetivo no futuro, quando sua energia começar a fraquejar, você terá o seu aprendizado em cada um dos mini-projetos documentado em post-mortems, a sua clara evolução será motivador para continuar em seu caminho.


QUAL MITO VOCÊ VIVE?


Um professor disse em uma palestra: todo mundo está vivendo de acordo com um mito, mas são poucos que conhecem os seus mitos. E decidir qual é o seu mito é algo muito importante, porque você pode estar vivendo uma tragédia grega e talvez você não queira viver uma!

As ideias passadas por Krishna são valiosas até hoje, eu as utilizo diariamente. Se eu as conhecesse naquela noite em Gericinó, ou Bangu, teria traçado um caminho diferente, teria seguido agido com moderação sobre minhas certezas, teria focado no meu trabalho e não em seus resultados, teria utilizado aquela oportunidade para aprender e melhorar o sistema, mas principalmente a mim mesmo! Eu teria controle sobre o caminho que segui, ao invés de cegamente deixar a inércia me levar.

Se você colocar essas ideias em prática, no dia em que encontrar o seu Krishna, mesmo em sua forma divina e assustadora, você não terá medo do destruidor de mundos: você terá planejado seu caminho, tomado controle sobre você mesmo e alcançado seus objetivos.

Obrigado!

–

ps: após a palestra, algumas pessoas me perguntaram qual tradução do Gita eu recomendo. Há diferentes traduções e editoras, algumas mais fáceis de ler do que outras, mas minha recomendação é essa aqui.

http://www.amazon.com/Bhagavad-Easwarans-Classics-Indian-Spirituality/dp/1586380192/