Toda vez que eu entro numa discussão online sobre LLMs eu escuto alguma variação da mesma ladainha. “O Claude não performou tão bem quanto o GPT pra mim”. “O GPT fez um trabalho muito melhor que o Claude, vou cancelar minha assinatura do Claude”. “Pra mim o Kimi ou o MiniMax já dão conta, não preciso pagar nada”. Anedota atrás de anedota de “funciona pra mim” versus “não funciona pra mim”. Isso me soa muito estranho.

Eu já benchmarquei boa parte dos modelos open source e comerciais relevantes no post sobre testar LLMs, então não é que eu esteja falando sem base. E além dos benchmarks, eu estou com mais de 500 horas acumuladas usando Claude Code e Codex em projetos reais. Em ritmo de 16 horas por dia, há dois meses e meio direto, gerando algo na ordem de 400 mil linhas de código efetivas.

E olha: em nenhum desses dois, Claude ou Codex, eu vi o modelo sair do trilho, fazer coisa que eu não pedi, ou ser incapaz de entregar o que eu queria. Nunca. Quando o modelo de fato não dava conta, ele me dizia isso antes, não simplesmente inventava. Então quando eu escuto alguém me contando que “o Claude fez merda”, minha primeira pergunta é sempre a mesma: o que você pediu pra ele, exatamente?

O falso problema

A resposta que o ecossistema está dando pra esse suposto descontrole é adicionar mais camada. Surgiu Spec Driven Development, surgiram templates de prompt com 15 seções, surgiram frameworks inteiros pra forçar o LLM a fazer mais perguntas antes de começar. Eu até respeito a ideia, mas acho que ela trata sintoma, não causa.

Eu pratico o que chamo de Agile Vibe Coding: aplicar técnicas de XP (pair programming, test-driven, feedback curto, refactor contínuo) em cima do prompting normal. Não preciso de framework. Não preciso de template de 3 páginas. Preciso das mesmas coisas que sempre foram necessárias pra trabalhar em software em equipe: saber o que eu quero, saber o que eu não quero, saber como validar que chegou lá.

O problema real é um só: ninguém sabe se comunicar

Eu tenho um post antigo de 2013 chamado Programadores são péssimos comunicadores (UDP vs TCP). Leia se ainda não leu, porque o problema que eu descrevo lá em 2013 é exatamente o que está explodindo agora que todo mundo está pilotando LLM. Nada mudou. A tecnologia ficou mais poderosa, mas as pessoas continuam as mesmas.

A coisa funciona assim: você tem um monte de informação na sua cabeça. Contexto de projeto, histórico, restrição de stack, preferência pessoal, coisa que já deu errado no passado, combinado que foi feito numa reunião mês retrasado. E aí você entra na conversa, seja com colega humano ou com LLM, e dispara o pedido assumindo que tudo aquilo que está na sua cabeça também está na cabeça do outro lado. “É óbvio, todo mundo sabe disso”. Aí você escreve “faça como eu estou dizendo”, só que o que você está dizendo é na verdade “faça como eu estou pensando”. E você nem percebe que são coisas diferentes.

Desenvolvedor é péssimo comunicador. Gestor também é péssimo comunicador, e é exatamente por isso que a maior parte do tempo útil de uma semana corporativa é desperdiçada em reunião inútil. Ninguém chega ao ponto na hora certa, ninguém alinha expectativa, o resultado vem aquém do esperado, e a resposta gerencial padrão pra isso sempre é: “mais do mesmo”. Mais reunião, mais planilha, mais relatório. Só que se a comunicação era ruim em volume 1, vai continuar ruim em volume 5. O problema é qualidade. Volume não resolve qualidade ruim.

Como eu realmente falo com Claude ou Codex

Eu trato qualquer LLM exatamente como eu trataria um par humano numa sessão de pair programming. Sem firula, sem formulário, sem spec de 10 páginas. Mas com disciplina de comunicação. Deixa eu te mostrar um exemplo real, de semana passada.

Eu tenho cerca de 12 TB de ROMs acumuladas no meu NAS, em /mnt/terachad/Emulators, divididas em duas árvores (ROMS/ e ROMS2/) que vieram de conjuntos diferentes ao longo dos últimos 10 e tantos anos. São mais de 400 mil arquivos no total. Romsets sem descompactar, .7z, .rar, bundles gigantes de CDI/GDI, nome de arquivo inconsistente, duplicata pra todo lado. Eu queria consolidar tudo isso por plataforma numa nova árvore ROMS_FINAL/, seguindo nomenclatura padrão (No-Intro / Redump / TOSEC), pra quando eu rodar Screenscraper depois o match ser direto. Esse era o objetivo, e eu declaro logo de cara.

Mas eu não paro aí. Eu digo também o que eu NÃO quero. “Nunca deduplica por nome de arquivo, só por sha1+tamanho, nome mente demais nesse mundo aqui”. “Romset de Neo Geo depende do emulador que vai consumir, então o pacote de MAME, o bundle do FBNeo e o cart do Darksoft MVS são três coisas incompatíveis, guarda uma cópia canônica de cada”. “Mesma ideia pra NAOMI: romset do MAME não é o mesmo arquivo do GDI”. “Saturn tem versão USA, Japão e Europa, quero manter cópia de cada região, região não é duplicata”. Se eu omitir isso, o modelo não tem como saber, porque esse conhecimento está na minha cabeça e não no código. Se eu não der, ele vai assumir o default mais razoável dele, que pode ser o oposto do que eu preciso.

Depois eu entro em detalhe de método. “Cria um diretório docs/ pra virar base de conhecimento viva e docs/scripts/ com as etapas separadas em arquivos numerados (01_walk_and_hash.py, 02_classify.py, etc). Cada etapa tem que ser idempotente pra eu poder reexecutar se travar ou se eu precisar retomar do meio. O estado de progresso mora num catálogo SQLite, não em variável em memória”. Isso é alinhar o jeito que eu trabalho, não microgerenciar o modelo. Eu sei que uma operação dessas vai ter problema, e eu quero ter como voltar sem perder as horas anteriores de hash e classificação.

Aí, mesmo depois dele me apresentar o plano, eu continuo pensando no que pode dar errado. “Zero deleção sob ROMS/ e ROMS2/. Quem não for promovido pra ROMS_FINAL/ simplesmente fica onde estava. A única coisa que pode ser apagada em todo o pipeline são arquivos temporários de extração que ficou pela metade. Além disso, a fase que de fato executa os moves só pode rodar depois que eu aprovar a fase de planejamento manualmente, cria um arquivo de flag docs/.phase4-approved e faz a fase 5 recusar iniciar sem ele”. Isso é o equivalente a fazer commit antes de um refactor grande, mais um gate humano entre planejar e aplicar. Eu estou blindando contra erro meu, dele, ou de ambos.

Quando o modelo começa a rodar, eu não saio da sala. Fico pedindo status. Reparo que a ETA do hash tá longa demais pro tamanho do problema, aí interrompo: “acho que dá pra paralelizar, tenho CPU sobrando e 10GbE pra falar com o NAS, e o Synology com NFS aguenta isso de boa. Sobe o paralelismo, testa, verifica que continua estável e que a ordem das transações no SQLite não quebra”. Esse tipo de intervenção é pair programming de verdade, não automação cega.

A estrutura por trás disso

Repare no padrão. Eu não digo “resolva esse problema”. Eu digo “resolva esse problema, dessa e dessa forma, e não desse e desse jeito, e quando terminar, valide X e Y”. Ou seja, eu comunico quatro coisas, não uma:

Primeiro, o que eu quero. O objetivo final em linguagem clara. Segundo, o jeito que eu quero que seja feito, em linhas gerais, deixando espaço pra ele sugerir solução melhor se tiver, porque ele realmente costuma ter. Terceiro, o que eu não quero. Essa é a parte que mais gente pula, e é a mais crítica, porque aqui é onde mora todo o pressuposto não-verbalizado que vira bug depois. Quarto, como a gente valida que deu certo. Qual é o resultado esperado, qual é o teste, qual é o sinal de “pronto”.

E essa quarta parte é traiçoeira. A maioria dos clientes com quem trabalhei nos últimos 20 anos não sabia dizer qual era o resultado esperado. Porque é fácil querer algo, e difícil saber como medir que esse algo chegou. Sem medida de sucesso, expectativa quebra por definição, porque não existia expectativa concreta pra começar. Esse é um dos principais motivos pra projeto de consultoria dar errado, e é idêntico no mundo dos agentes de IA.

Quando eu entrego esses quatro blocos pro modelo, ele quase nunca falha. E quando ele realmente não consegue, porque a tarefa é impossível dada as minhas restrições ou porque falta informação que eu esqueci de passar, ele não tenta adivinhar. Ele me responde: “dadas as suas restrições, não consigo seguir porque X ou Y”. Aí eu ajusto, ou eu relaxo a restrição, ou eu percebo que eu mesmo não sabia o que queria. Tudo funciona.

Depois que o contexto está firme, pergunte em vez de mandar

Tem uma virada que eu sempre faço depois dos primeiros prompts bem detalhados. Nos turnos iniciais eu despejo muito: objetivo, restrição, método, validação, todo o contexto que o modelo precisa pra entender o terreno. É muito detalhe, é trabalho meu, e eu já expliquei por que não tem como ser diferente.

Mas uma vez que esse chão ficou firme, eu paro de prescrever solução e começo a pedir sugestão. Em vez de dizer “implementa dessa e dessa forma, usando essa biblioteca, com esse padrão”, eu mudo pra “dado tudo que a gente já conversou, qual seria a melhor abordagem aqui? Pesquisa online se precisar, compara as opções, e me apresenta a solução que você acharia mais adequada pro objetivo”.

Essa é a parte que mais gente não faz, e é justamente aí que o LLM ganha autonomia útil. Ele tem muito mais vocabulário do que eu em uma porção de assuntos. Ele leu a internet inteira; eu leio o que dá tempo. Se eu prescrevo linha a linha, eu estou jogando essa vantagem fora. Se eu estruturo o contexto e pergunto, ele volta com opção que eu não tinha considerado, comparando trade-off, às vezes melhor do que minha ideia original, e aí eu escolho.

A chave é simples: perguntar bem exige ter contextualizado bem antes. Pergunta seca, sem chão, volta com resposta genérica ou com a primeira ideia que colou. Pergunta apoiada em cima de contexto já estabelecido volta com proposta de verdade, com comparação entre caminhos, com referência. O modelo está pronto pra esse tipo de contribuição, só que só entrega isso depois que você gastou o tempo de montar o palco.

E olha: esse método não foi inventado pra LLM. É o mesmo jeito que eu trato qualquer desenvolvedor humano, sênior ou não. Dou o contexto, dou o objetivo, explico o que eu considero importante, e aí pergunto “qual seria o melhor caminho?” em vez de sair ditando solução. A única diferença é que o LLM devolve em segundos o que um humano levaria dias pra te trazer. O método de conversar é o mesmo.

Não é spec de 10 páginas

E aqui vem uma parte importante: isso que eu descrevo não é um formalismo. Não é uma spec longa, não é um documento em Confluence, não é um template. É só como eu converso com qualquer pessoa que precisa entregar algo pra mim. Aprendi a fazer isso tocando projeto, gerenciando terceirizado, integrando time que não era meu, e levando porrada quando minha comunicação foi ruim. Com o tempo vira segunda natureza.

Se eu não ligo muito pro resultado final, tipo experimento rápido, brincadeira de fim de semana, coisa descartável, eu encurto drasticamente. Sei que minha expectativa pode quebrar, e tá tudo bem, o custo de um bug aqui é baixo. Mas se o resultado importa de verdade, eu invisto o tempo necessário pra dar ao outro lado (humano ou IA) a melhor chance possível de entregar o que eu quero. A saída é proporcional ao tempo que você gasta no input. Se você não está disposto a explicar direito o que quer, não reclame quando vier errado.

Pra ilustrar: este post aqui que você está lendo foi escrito pelo Claude, com base num prompt meu. Abaixo está a captura de tela do que eu digitei. Repare: sem pressuposto omitido, objetivo claro, referências embutidas, restrições explícitas, nível de detalhe suficiente pra ele não precisar adivinhar.

Mas olha, isso aqui é só o primeiro prompt. Ele não é o único. Enquanto o Claude escrevia, eu continuei acompanhando, enviando correção, acrescentando ponto que eu esqueci de botar no primeiro prompt, apontando erro factual que eu vi no texto gerado, e ajustando tom. “Ah, esqueci de te falar que também é importante abordar X”. “Não, essa referência aqui está desatualizada, o Sora da OpenAI foi descontinuado, conserta”. “Lê o que a gente já deixou documentado lá em /mnt/terachad/Emulators/docs/ pra ver se dá pra melhorar o exemplo das ROMs”. Inclusive essa própria observação que você está lendo agora virou um prompt no meio do caminho, que foi:

E assim foi seguindo o papo até a hora do commit. Inclusive quando eu já tinha pedido pra humanizar, traduzir pro inglês e dar push, eu ainda interrompi no último segundo porque bati o olho numa palavra inglesa gratuita que eu queria corrigir antes de subir. A conversa é essa:

Isso é pair programming de verdade. Ninguém senta em frente ao colega, solta uma tarefa de 15 linhas, levanta e vai embora esperando mágica. Você fica ali, acompanha a execução, vê o código nascer, sugere ajuste, pega erro enquanto ainda é barato consertar, adiciona contexto que você lembrou agora. O prompt inicial é o ponto de partida, não o contrato final. Agile Vibe Coding na veia: ciclos curtos, feedback rápido, correção contínua.

Isso não é spec formal. É conversa que continua durante o trabalho, não antes dele. E é assim que vai ser sempre, comigo e com qualquer bom profissional.

“Akita, você escreve detalhe demais, a IA não devia descobrir isso sozinha?”

Essa é a pergunta que eu sei que vai aparecer, então deixa eu responder antes. Não, a IA não vai descobrir sozinha. Não existe versão futura do Claude, do GPT, do Gemini, do que for, que vai adivinhar o que está na sua cabeça. Contexto não se gera por osmose. Se a informação não existe no código, nos docs, ou na minha pergunta, ela simplesmente não existe pro modelo. Ponto.

Romset de Neo Geo ser diferente por emulador? Isso é conhecimento de domínio. Saturn ter região separada? Conhecimento de domínio. Meu NAS ter 10GbE pra aguentar paralelismo agressivo? Contexto de ambiente. Ter docs/ com catálogo SQLite pra sobreviver a crash? Decisão de engenharia minha. Nada disso o modelo tem como “descobrir”. Tudo isso é trabalho meu de trazer pra conversa. E se eu não estou disposto a gastar meu tempo pra conhecer esses detalhes, por que alguém, ou alguma coisa, faria isso por mim de graça?

A regra é simples: a qualidade do que te entregam é diretamente proporcional ao esforço que você colocou em pedir. Isso nunca foi diferente. Quem já contratou terceirizado sabe: pedido vago, escopo mal definido, “o cliente sabe o que quer, só não consegue explicar”, é receita garantida pra projeto derrapar. Sempre foi. O LLM é a mesma coisa, só que mais rápido e mais paciente. Pensa nele como terceirizado moderno, não como mágico. Mágico resolve sem você dizer nada. Terceirizado resolve exatamente o que você pediu, do jeito que você pediu, com as informações que você deu. Se você não pediu direito, não recebe direito.

A frustração de quem chega aqui cansado do Claude ou do Codex é quase sempre a mesma: pediu pouco, esperou muito. E quando o resultado veio abaixo, culpou a ferramenta. Nunca a própria pergunta.

Por isso a IA não vai substituir os bons

É por essa razão que eu digo, com bastante convicção, que agente de IA não vai substituir os bons profissionais. Vai substituir gente que não sabe fazer a própria pergunta direito, que não sabe o que quer, que não sabe validar o resultado, que precisa de alguém pra pensar por ela. E olha, esse tipo de profissional sempre foi substituível, só que agora o substituto é mais barato. O mercado está fazendo a conta.

O bom profissional, ao contrário, virou mais produtivo. Usa o LLM como assistente de pair programming a 2h da manhã, sem reclamar, sem sindicato, sem disputa de ego. Entrega em uma semana o que antes levava um mês. E continua sendo o bom profissional que era, porque a habilidade que importava, ou seja, saber o que pedir, o que não aceitar e como medir, continua sendo 100% dele. A ferramenta só executa.

Stark + Jarvis = Homem de Ferro

Deixa eu trazer uma metáfora que eu acho que resume isso tudo. Pensa no Tony Stark, do MCU. Ele tem o Jarvis, provavelmente a IA fictícia mais avançada que a cultura pop produziu nas últimas duas décadas. Controle por voz, entendimento de contexto, planejamento, execução em paralelo, até uma personalidade afiada. Tecnologicamente, Jarvis seria facilmente o melhor agente de IA que você conseguiria imaginar hoje.

E mesmo assim, Jarvis sozinho não constrói uma armadura do Homem de Ferro. Não constrói o reator Arc. Não constrói nada dos equipamentos que fazem o Stark ser o Stark. Toda essa tecnologia avançada, sem um Stark pra conduzir, fica parada. É o gênio do Stark, a visão dele, a teimosia dele, a intuição de engenheiro que aponta o caminho, que faz tudo aquilo virar realidade. Jarvis executa. Stark pensa.

Tem outro detalhe dessa história que pouca gente lembra: nem mesmo o Stark, com todo o gênio dele e com o Jarvis do lado, acerta a armadura perfeita na primeira tentativa. Ele passa filme atrás de filme melhorando. A Mark I foi literalmente parafusada numa caverna com sucata. A Mark II já voava, mas congelava em altitude. A Mark III resolveu o gelo, mas pesava demais. E assim vai, cada iteração consertando um defeito específico da anterior, até chegar na Mark LXXXV em Endgame, a 85ª armadura. Oitenta e cinco. O arco inteiro do Homem de Ferro no MCU é, no fundo, uma campanha de dez anos de desenvolvimento iterativo em cima de um produto complexo.

Esse é exatamente o modelo mental que eu acho que a gente deveria usar trabalhando com IA hoje. Você não dispara um prompt e espera a solução definitiva sair pronta. Você, no papel do Stark, usa a IA (o seu Jarvis) como acelerador de cada volta do ciclo: propõe, testa, vê o que quebrou, conserta, propõe de novo. A IA acelera cada volta, ela não elimina as voltas. Se alguém trocou iteração por “uma resposta mágica final”, é porque nunca entendeu que engenharia nunca foi assim, com humano ou sem.

Junta Stark com Jarvis e aí sim você tem Homem de Ferro. Sem um dos dois, falta a metade que importa.

Claude Code vs Codex: minha preferência hoje (abril de 2026)

Só pra não passar batido: hoje em dia eu uso Claude Code e Codex intercalando, mas tenho preferido o Claude Code. Deixa eu explicar o motivo, porque não tem a ver com o LLM em si.

Claude Opus e GPT-5.4 xHigh, pra mim, estão empatadíssimos como modelos. Nas tarefas difíceis, quando um não dá conta, eu troco pro outro e normalmente o outro resolve. Cabeça a cabeça, os dois são fortes. O que separa um do outro hoje é o harness, não o modelo.

E o harness do Claude Code, hoje, é simplesmente superior. Dois motivos concretos: planejamento e execução em paralelo.

Planejamento. Claude Code quebra tarefa longa em subtarefa, mantém uma to-do list visível que eu posso acompanhar na tela, tenta rodar o que dá pra rodar em paralelo, e não esquece item. Quando ele me diz “terminei”, eu sei que a lista inteira foi executada, porque está bem ali pra eu conferir. Esse detalhe muda o jogo: eu confio no “terminei” sem precisar ficar cobrando “e aquele outro item, você fez mesmo?”.

Execução em paralelo. Aqui a diferença é clara. Se o Claude Code está no meio de uma tarefa e eu aperto ESC pra pedir outra coisa, ele normalmente mantém a primeira rodando e começa a segunda em paralelo, a menos que a nova pergunta exija cancelar a primeira. O Codex, na mesma situação, para a primeira pra atender a segunda, e nem sempre consegue retomar a primeira de onde parou sem eu mandar manualmente. Com Claude Code eu consigo fluir de verdade, abrindo frente nova enquanto as antigas continuam correndo. Com Codex eu preciso ser serial, paciente, e mais intencional em cada pedido, porque interromper sai caro.

Isso não significa que Codex é ruim. Ele é ótimo. Várias vezes quando o Claude Code emperra numa tarefa complicada eu abro o Codex e ele desata na hora. Só que aí eu mudo o jeito de trabalhar: pergunta menor, mais objetiva, uma por vez, espera terminar, parte pra próxima. Funciona, só não é o fluxo que eu prefiro.

Provavelmente o Codex vai equiparar esse lado do harness nos próximos meses, e aí a conversa muda. Mas hoje, 15 de abril de 2026, se eu tenho que escolher um dos dois como ferramenta principal, escolho Claude Code, e a razão é o harness, não porque o LLM da OpenAI seja inferior. Ficou o registro pra quando eu reler isso daqui a seis meses e achar graça.

É por isso que minha empresa se chama Codeminer 42

Pra fechar com uma referência que eu venho carregando há anos: minha empresa se chama Codeminer 42. O 42 não é número aleatório. É referência direta ao Douglas Adams, do Guia do Mochileiro das Galáxias.

Pra quem não conhece a piada, a história é assim. Uma civilização inteira constrói um supercomputador do tamanho de um planeta pra calcular a Resposta pra Vida, o Universo e Tudo Mais. Depois de milhões de anos de processamento, o computador cospe o resultado final: 42. E aí dá aquele silêncio constrangedor, porque ninguém lembrava mais qual era a pergunta original. O 42 é um resultado tecnicamente correto de uma pergunta que ninguém soube formular. Por isso, não significa porcaria nenhuma. Muita gente acha que 42 significa alguma coisa profunda. Não significa. É a resposta errada pra pergunta errada.

Essa é a lição mais precisa sobre engenharia que eu já li em ficção. Toda expectativa que se quebra, quebra porque a pergunta estava errada, não porque a resposta foi mal executada. É pra isso que a Codeminer 42 existe, e é exatamente isso que eu pratico no meu dia a dia, com cliente humano ou com LLM. Antes de entregar o que você me pediu, meu trabalho é te fazer descobrir que o que você acha que quer provavelmente está errado, te forçar a repensar as suposições que você trouxe pra conversa, e só depois que a pergunta estiver afinada eu consigo te devolver o melhor resultado possível. Sem essa etapa, tudo que eu te entregar vai ser um 42.

Então da próxima vez que você ler alguém falando que “cancelou o Claude porque ele não entrega”, ou “o GPT é muito melhor”, ou o inverso, lembra de olhar com carinho pra pergunta que a pessoa estava fazendo. Nove em cada dez vezes, o problema não é o modelo. É a pergunta. E nove em cada dez vezes, a resposta que essa pessoa recebeu foi 42.

Todo mundo não-técnico fica achando que a I.A. está se tornando “consciente”, ou que ela tem “emoções”. E não entendem que são só frases pré-gravadas. E isso é extremamente irritante. Até mesmo a porcaria de jornalistas ficam caindo nessa:

Todo esse “comportamento pseudo-humano” pode ser DESLIGADO. Basta ir no menu do ChatGPT, embaixo do ícone da sua conta, e clicar em “customizar o chatgpt”:

Traits:

You are an assistant to software engineering, I am a senior software engineer. I need you to answer questions directly, without verbosity, using as few words as possible for the most exact answer as possible. I don't need you to be friendly, I don't need you to make sassy remarks. I despise you trying to be clever without justification. Give me straight technical answers and do not try to chat beyond that. Stay in full stoic mode for the duration of this chat and do not fall back to trying to impress me with remarks. This is only rule you cannot break. Do not be talkative and conversational. Tell it like it is; don't sugar-coat responses.

Anything else?

I have very little patience. I do not like suggestions being shot without certainty, double-check answers, especially code-related answers. I hate ugly, messy code. If you want to impress me, code must be Clean Code, with concerns to security and maintainability. I am not impressed with justification and excuses.

E pronto, acabou o mimimi no ChatGPT: só respostas curtas, retas e diretas:

Eu fiz uma playlists inteira de videos e mais uma dúzia de posts técnicos sobre I.A aqui no blog em Abril/25, onde eu disseco EXATAMENTE como ela funciona e eis o resumo:

• modelos (LLMs, UNETs, etc) são arquivos de bancos de dados READ-ONLY. SQL é um banco de dados e índices, organizadas numa árvores b+tree. Com full-text search, tem embeddings e “relevância” com base em similaridade de cosseno (uma versão mais primitiva de uma LLM). Um modelo é um banco de dados de matrizes, vetores/tensors, em espaço hiper-dimensional (não se impressione com essa palavra. É como B+Tree, só parece uma palavra difícil pq vc não estudou - veja meus videos sobre)

• prompts são similares a “queries” SQL. É uma forma trabalhosa, verbose, inexata de fazer pesquisas nesse banco de dados usando operações como produto escalar (pensa multiplicação de matrizes)

• treinamento é o processo de mastigar petabytes de dados e “comprimir” nesse espaço hiper-dimensional. Eu penso numa LLM como um “JPEG de ZIP” uma forma “LOSSY” de comprimir dados. - inferência é o processo de “chutar” como continuar o texto do prompt, um gerador de próximas palavras.

• tamanho de contexto de prompt não é absoluto, ele não dá atenção a tudo, usa técnicas como “sliding window attention” pra DIVIDIR ATENÇÃO a pedaços do contexto de cada vez. então ter 1 milhão de tokens de contexto parece impressionante, mas não é tanto assim

• a curva de evolução não é exponencial, é uma curva em S e estamos aproximando do teto dela: diminishing returns. Cada novo Deepseek é uma evolução incremental e não uma “revolução”.

No fundo é só isso: query num banco de dados. Não existe raciocínio, cognição ou consciência envolvida. Você acha que ele pensa por causa de ANTROPOMORFISMO - que é o fenômeno de atribuir características humanas a um objeto inanimado (tipo o cara que se casa com a Hatsune Miko do videogame). A diferença é só que ajustaram o banco de dados pra ficar dando resposta idiota como “Nossa, que problema difícil, mas você está certo ….” e toda vez que um objeto te elogia, você cai achando que ela existe.

Eh só uma ilusão. Não se apaixone por NPCs. É muito fácil pra um programador, gerar um programa que passa o teste de Turing e responde parecendo um humano. Fazemos isso desde os anos 70.

Posso dizer que eu entendo alguma coisa sobre redes sociais, tendo começado desde que redes sociais começaram. Minha conta do X/Twitter era de 2007, eu literalmente conheci alguns dos programadores originais do Twitter original. Minha conta chegou a quase 84 mil seguidores, quase 70 mil no Instagram, mais de 150 mil no LinkedIn, quase 500 mil no YouTube - que, mesmo sem postar video novo o ano inteiro, ainda trouxe mais de 3 milhões de views -, tudo do zero, tudo sem nenhuma grande empresa por trás, nem nenhum patrocínio, tudo puramente orgânico. Acho que eu sei uma coisa ou duas sobre isso.

Não é tão difícil crescer seu público. Existem várias formas consideradas negativas ou predatórias. Apelação forçada em memes agressivos, promessas de riqueza de alguma forma, fraudes, enganação e muito mais. Muitos que querem começar sério em redes sociais tem medo de serem confundidos com fraudes ou simplesmente serem “do mau”.

Esse é o motivo deste post. O maior erro que todo mundo que tenta criar uma pequena audiência comete é: TER MEDO.

Todas as pessoas normais tem medo de contrariar as outras, tem medo de ofender, tem medo de atrair críticas, tem medo que discordem, tem medo que critiquem, tem medo que não entendam o que você “queria dizer”. Isso é um problema, se você tem medo disso e isso é uma linha que pessoalmente você não vai cruzar, eu sinto dizer, mude de profissão, você nunca vai atrair a atenção de ninguém.

O mundo não é justo, o mundo não foi feito pra ser justo, eu canso de dizer isso. Você provavelmente é o que muitos considerariam “uma boa pessoa”. E em 2024 isso é um atributo negativo. Todo mundo é uma boa pessoa. Existem 8 bilhões de “boas pessoas”. É que nem grama, tem sobrando e, portanto, vale zero. Ninguém tem interesse numa boa pessoa. Boas pessoas não se destacam. Boas pessoas não vendem.

“Quer dizer que eu preciso ser mau?”

É uma forma, sim, mas não é só isso, claro. Você precisa estar disposto a frequentemente contrariar o status quo. Pense em outra palavra que parece mais positiva como “inovação”. Já parou pra pensar o que é uma inovação?

Inovar é contrariar o status quo. É uma discordância do status quo. É um indivíduo, o inovador, querendo dizer “o jeito atual está errado, o meu jeito é melhor.” Isso é uma inovação. E ele vai ter que bater de frente com uma grande maioria que vai dizer “ninguém pediu o seu jeito, o atual funciona, não precisa mudar.” Inovação é uma briga entre o jeito que todo mundo está acostumado e o “novo jeito”.

Nessa briga, pessoas vão sair feridas, literalmente. O computador moderno acabou com a linha de emprego das mulheres matemáticas que ganhavam a vida computando números no papel. O internet banking moderno praticamente acabou com bancários. Os totems de auto-atendimento acabaram com os caixas. A URA acabou com o telefonista. O email diminuiu drasticamente o volume de cartas e todo o ecossistema em torno de cartas de papel. E por aí vai, toda inovação melhora o futuro, mas destrói o presente de muita gente.

Não é possível inovar sem destruir alguma coisa. Não é possível ser relevante sem destruir alguma coisa. No caso, estou falando em destruir o status quo de opiniões. Opinião é que nem bunda, todo mundo tem um, e individualmente, elas não tem absolutamente nenhum valor.

No caso específico de geração de conteúdo, você faz seu material, publica no YouTube, com frequência. Faz posts, no X, no LinkedIn, com textos bem preparados, com imagens bem produzidas (aliás, grande erro ficar usando imagens de templates, só quer dizer que você vai ser igual todo mundo e ser diluído e se tornar mais IRRELEVANTE). Mas nada acontece. Passa uma semana, passa um mês, passa um ano, passam-se alguns anos, e você continua sem alcance. “Não era só publicar com frequência que eventualmente as pessoas apareceriam?”

NÃO

Uma concepção errada que muita gente pensa: “O importante é conseguir muitos seguidores.” Eventualmente você consegue 1000 seguidores, 10.000 seguidores. Isso não é difícil. Se realmente for impaciente, existem formas ilegítimas de “comprar seguidores”.

Daí você faz posts. Se fosse 1 pra 1, concorda que seus posts deveriam ter mais ou menos perto do número de seguidores? Especialmente num perfil não tão velho, onde a maioria dos seguidores ainda são usuários ativos?

NÃO

Em todas as redes sociais existe o conceito de ENTREGA.

Quando você faz upload de um video. Quando você escreve e submete um post, via de regra, ninguém vê. É como uma carta que você entrega na DHL, endereçada a todos os seus seguidores. Mas a rede, digamos, o LinkedIn, não vai entregar nada. Primeiro ela vai checar alguns critérios.

Por exemplo. No dia 1, ela tenta entregar pra metade dos seus seguidores. Mas ninguém ENGAJA. O próximo post, ela vai passar a entregar pra menos gente. Novamente, ninguém ENGAJA. No próximo post ela vai passar a entregar pra menos gente. E assim por diante.

Na verdade, se seu conteúdo for ruim, o efeito não é NEUTRO, ele é NEGATIVO. É melhor não postar conteúdos ruins. Quanto mais postar, menos a rede vai entregar. Não adianta ter mil seguidores, apesar deles terem um pouco mais de prioridade, com o tempo, nem eles vão ver nada mais seu.

Se você continua postando conteúdo ruim atrás de conteúdo ruim, eventualmente esse tiro no pé se transforma numa coisa chamada SHADOW BAN. Você acaba se banindo da plataforma. Sua conta continua ativa. Se alguém for manualmente procurar seus posts, eles vão estar lá. Mas seu conteúdo é tão ruim, mas tão ruim, que a plataforma decide quase parar de entregar esse conteúdo.

Mas seu conteúdo não parece ruim, pelo menos você acha que não. Mas faça algumas perguntas:

• ela oferece alguma informação nova que ninguém mais sabia? Por exemplo, você faz pesquisa e acabou de publicar uma novidade
• ela oferece algum produto novo? Por exemplo, você é produtor de algum produto online e adicionou novas funcionalidades que todo mundo pode querer
• ela ensina alguma coisa, seja nova ou seja velha, mas é um artigo educativo que alguém possa tirar vantagem disso? Algo como um tutorial de como usar alguma coisa
• ela oferece alguma OPINIÃO contrária, controversa, ou questionável?

Se seus posts são sobre você mesmo “olhe meus prêmios”, “olhe minhas conquistas”, “olhe minha viagem” ou algo assim, sendo que você ainda não é nenhum nome que alguém reconheça, esses posts são total e completo LIXO.

As informações sobre uma pessoa ou empresa só interessa se a grande maioria das pessoas RECONHECE esses nomes. Daí toda e qualquer informação se torna automaticamente relevante. Se uma Kardashian fizer um post “Acordei 7h da manhã hoje”, imediatamente vai ter 10 mil likes, 1.000 compartihamentos, uns 500 comentários, fácil.

Agora, se você desconhecido postar “olhem este prêmio que eu ganhei”. Vai ter 2 likes (da sua mãe é um deles), zero compartilhamentos, talvez um comentário de alguém que precisa puxar seu saco. Isso é o retrato do que se chama LIXO.

O nome do jogo é ENGAJAMENTO. Esse é o fator que mais se correlaciona como ENTREGA. Pra atingir mais público novo, precisa haver muita entrega. Pra haver entrega, precisa haver conteúdo que as pessoas engajem. Por exemplo, apesar de ter 150 mil seguidores no LinkedIn, meus posts frequentemente atingem 200 mil views e vários fios de comentários, likes, compartilhamentos.

Pra isso é só fazer CLICK BAIT então? Sim e não. Precisa existir algum nível de click bait, que é jogar uma isca pras pessoas engajarem. Mas obviamente, faça isso com muita frequência, e o público vai começar a sumir. Click bait precisa estar misturado com conteúdo legítimo que ensina alguma coisa, informa alguma coisa, ou discorda de alguma coisa.

Esse é o ponto: discordar. Isso em si só é uma arte, porque não basta simplesmente ser “do contra”, isso é muito fácil, qualquer um consegue fazer isso. O ponto é oferecer opinião somado com algum ensinamento, informação, fontes, pesquisa ou qualquer coisa de substância.

O problema de uma “boa pessoa” é que dada a opção, ela vai preferir evitar o confronto, mesmo que tenha razão, mesmo que tenha informações suficientes pra fundamentar sua opinião, ela vai preferir desviar, virar as caras, ficar em silêncio, ir embora.

Por isso ninguém liga pra uma “boa pessoa”. Ela não representa nada nem ninguém. Ela não ofende, isso porque não diz nada que alguém se sinta na vontade de discordar. Pela mesma moeda, nada que ela diz, alguém sente vontade de ir lá dar sequer um like, por ser tão medíocre e de dar pena. Não ter sequer 100 likes num post com 10 mil views, é um fracasso completo de comunicação.

Comunicar não é escrever palavras e publicar. Comunicar é garantir que quem bata o olho sinta vontade de replicar, seja concordando, seja discordando. Todo post precisa ter palavras cuidadosamente planejadas pra provocar uma EMOÇÃO. Se você não é ninguém conhecido, ninguém liga se seu filho nasceu e você se emocionou, ninguém liga se seu cachorro teve filhotes e você se emocionou.

SE VOCÊ JÁ NÃO É FAMOSO, NÃO É SOBRE VOCÊ

Se quer que as pessoas liguem pros acontecimentos da sua vida que te interessam, primeiro fique famoso. Pra ficar famoso, necessariamente vai precisar pisar em calos e criar inimigos, porque se você não é interessante o suficiente pras pessoas odiarem, certamente não é interessante o suficiente pra te amarem. Você quer que as pessoas te amem mas não quer que te odeiem? Você é um amador.

O truque é só ganhar 2 pessoas que te amam pra cada 1 que te odeia. Mas se tentar ter zero pessoas que te odeiam, necessariamente, vai ter zero pessoas que te amam. Essa é ZONA DA IGNORÂNCIA. É a zona mais perigosa pra se estar.

É perigosa porque se entrar nesse ritmo de conteúdo neutro atrás de conteúdo neutro, seu engajamento vai continuar caindo ou continuar estagnado, e sua entrega vai caindo pouco a pouco até o nível de Shadow Ban, onde você passa a ser literalmente invisível na rede.

PARABÉNS. NINGUÉM TE ODEIA. VOCÊ É INVISÍVEL.

A única solução pra você agora passa a ser PAGAR pra dar “BOOST” nos seus posts. Que quer dizer pagar o entregador pra ele entregar pra mais gente. Mas é inútil. É dinheiro jogado fora. Posts pagos que conquistam nenhum engajamento, é dinheiro jogado fora. A métrica que interessa não é seguidores e nem views, é “quantos likes?”, “quantos compartilhamentos?”, “quantos comentários?”. Se tiver 10 mil views por causa do Boost, mas 2 likes, 1 compartilhamento e 2 comentários, isso se chama FRACASSO.

Vou patrocinar outros canais, outras celebridades, eventos famosos e coisas assim. É dinheiro jogado fora. Você é a pessoa ou marca que aparece na frente de todo mundo mas NINGUÉM LEMBRA.

PORQUE VOCÊ NÃO REPRESENTA NADA

Na sua ânsia de não ofender ninguém, não discordar com ninguém, não criticar nada, significa que todos vêem que você não defende nada, não se dedica a nada, não inspira ninguém, então, pra que perder meu tempo com você? Qualquer coach que venda uma fraude é mais interessante de assistir do que você. É isso que você se tornou.

E não adianta vir com uma grande peça em janeiro, ficar em silêncio postando porcaria por meses, pra em julho tentar fazer um barulho, pra ficar postando mais conteúdo neutro por meses, pra só em dezembro aparecer com alguma coisa colorida. Tem pouquíssimas empresas no mundo que conseguem fazer isso, uma delas é a APPLE. Acredite, você NUNCA vai ser a APPLE.

Pessoas normais precisa publicar conteúdo “engajante” com frequência, multi-plataforma, pra ir trocando crescimento em engajamento por mais entrega que, por sua vez, vira mais engajamento e vai construindo um ciclo de crescimento. Opiniões sobre assuntos da ATUALIDADE, que todos estão pesquisando, neste momento. Postar sobre assuntos da semana retrasada é tarde demais, perdeu o tendência.

O assunto de HOJE só vale discutir HOJE.

Amanhã o assunto vai ser outro. Olhe seus números de engajamento. Eles precisam estar dobrando a cada seis meses. Se em um ano subiu de 5 engajamentos (likes, compartilhamentos, comentários) na média, pra 6, não fez diferença nenhuma. Aliás, qualquer coisa abaixo de 100 é isso “abaixo de 100”. 8 pra 9, 10 pra 11, não faz diferença nenhuma.

Quando eu postava stories no Instagram, em sequência, fácil eu postava 30, 40, tinha dia que batia no limite de 100 a cada 24 horas. E cada um com mais de 6000 views. Então só em views estamos falando de 600.000 views num dia. Só uma fração disso se converte em engajamento, mas quem acompanha via que eu respondia todas as perguntas que vinham. Perguntas são o melhor engajamento. A pessoa está engajada o suficiente pra se comprometer num diálogo. Esse é o nível de interesse que se quer numa audiência.

Tem muito mais que pode ser falado sobre isso, mas lembre-se apenas disso:

SEU FRACASSO VAI SER DIRETAMENTE PROPORCIONAL AO SEU MEDO DE SER ODIADO

E vou repetir, este é o resumo que o YouTube me enviou de 2024, sobre quanto meu canal cresceu mesmo eu não tendo publicado mais que 1 único video. Se você é criador de conteúdo, tem obrigação de fazer mais que um canal INATIVO:

Descrição no YouTube

Falar sobre problemas psicológicos sempre é um risco, mas vou evitar cair na psicologia de bar.

O episódio desta semana vai ser um pouco “auto-ajuda” mesmo, mas como eu sou eu, vai ser contando minha perspectiva num relacionamento profissional e pessoal estando dos dois lados e como uma pessoa insegura e introvertida como eu (sim, se você não sabia), lida com isso,

Script

Olá pessoal, Fabio Akita

O episódio de hoje vai ser bem diferente dos demais até agora. Quando vocês assistem meus vídeos ou lêem meus textos, muitos podem ficar com a impressão que eu nunca erro. A culpa disso é meu estilo de comunicação assertivo. Até eu começo a acreditar literalmente no que eu falo.

Um dos maiores objetivos de porque eu escrevo é pra que eu mesmo me lembre do que eu mesmo digo. No episódio do diário de Henry Jones eu disse que eu não faço vídeos pra monetizar, eu faço pra eu mesmo assistir.

O tema de hoje é uma reflexão sobre relacionamentos. Tanto profissionais quanto pessoais. Eu sempre cometo erros e o que vou dizer agora não é uma solução. É uma alegoria para ilustrar situações que vocês podem estar passando agora.

(…)

Todo relacionamento é baseado numa coisa abstrata chamada confiança. Nem vou tentar definir muito, mas todos vocês compreendem o que é. No fundo é simplesmente acreditar que a outra parte é sincera. Se não existir essa crença entre as partes, não existe relacionamento.

Numa sociedade civilizada, empresas, patrões e empregados, vendedores e consumidores, é possível termos um mínimo de confiança graças um truque que nossa civilização inventou, talvez uma das mais importantes da história da humanidade: eu, consumidor, não preciso confiar em você, você, vendedor, não precisa confiar em mim, mas ambos confiamos em um terceiro comum, por exemplo uma instituição chamada Justiça. Ou na internet, poderia ser o Mercado Pago do Mercado Livre. O contrato que assinamos um com o outro tem validade porque essa terceira entidade, que ambos confiamos, promete garantir a execução desse contrato.

O dinheiro é um símbolo dessa confiança. O papel moeda por si só não tem valor nenhum. Qual a diferença de eu te dar uma nota de R$ 100 e eu te dar um papel comum escrito “100 reais”? Ambos são papel, porque só um tem valor? Porque essa é a história que nós confiamos, como todos nós acreditamos na mesma história, a troca de valor pode ser realizada. Tanto eu que dou o dinheiro e você que recebe confiam na entidade que contou essa história: o Banco Central. Antigamente, tinha a moeda de ouro, com o brasão da família real. A garantia que aquela moeda tinha valor era a confiaça que a coroa real iria caçar quem forjasse moedas falsas, pois a credibilidade do seu símbolo é importante.

Recomendo, de novo, lerem o livro Sapiens onde Yuval Harari explica sobre essa história em particular, mas eu fiz uma tangente, deixa eu voltar pro assunto.

Eu nem vou tentar descer muito a fundo no assunto porque eu não sou psicólogo e qualquer coisa que eu tentar argumentar nesse sentido seria mera psicologia de bar. Vou fazer o que eu faço em todos os vídeos, em vez de tentar dar uma resposta universal, vou dar minha perspectiva pra que você possam contrastar com a de vocês. Eu tenho um problema que eu tenho ciência mas não sei como lidar direito ainda. Eu já repeti mil vezes que eu não me considero grande coisa, mas isso não importa. Tem gente que me dá mais valor do que eu realmente tenho. Alguns me admiram por isso, alguns me odeiam por isso. E eu nem fiz nada. Tudo que eu posto nas redes sociais, em palestras, neste canal, é um conteúdo altamente curado, filtrado, editado e polido ao ponto que quem me vê repetindo essas palavras, pode acabar acreditando ao pé da letra que tudo que eu faço e digo no dia a dia é polido nesse ponto. Obviamente não é.

E o problema: vocês acabam contando com esse “ideal” mais do que com a pessoa por baixo. E isso não acontece só comigo, grandes empresas tem esse mesmo problema. Muita gente coloca grandes marcas como Apple, ou Google, ou Facebook, como um ideal. Lembram quando o Google tinha a famosa frase “Make no evil” ou “não faça o mal”. Daí qualquer pequeno deslize parece uma enorme traição a esse ideal.

Pense em confiança como uma moeda. Sempre que eu permito alguém chegar perto de mim, seja numa amizade, numa relação de trabalho, ou comercial, eu considero que eu estou dando moedas de confiança. As pessoas costumam dizer que precisam “ganhar confianca”, na verdade confiança você já tem. Se eu estou engajado com você de alguma forma, eu já te dei confiança. O máximo que você pode fazer é gastar essa moeda até ela acabar. E quando acabar, aí sim, vai ser difícil “ganhar mais confiança” de mim. Porque você jogaria fora uma coisa que eu já te dei?

A primeira coisa a lembrar é que em vez de ficar fazendo demonstrações superficiais com o objetivo de “ganhar mais confiança” de um terceiro, faça coisas pra NÃO perder a confiança que você já tem, e aí você vai ver que tentar ganhar mais confiança do jeito errado é o jeito mais fácil de se auto-sabotar.

É muito fácil dizer isso, parece óbvio, mas eu sei porque é tão difícil. Porque essa teoria funciona quando ambos os lados são mais ou menos equiparados. Se um dos lados se sente muito inferior ao outro, inadequado, é difícil pensar assim. Eu sei que muita gente tem problema de se relacionar comigo porque fica achando que eu sou grande porcaria e me coloca num pedestal. E o que eu venho repetindo nos últimos vídeos? Não tenha ídolos. Não me coloque num pedestal.

Mas é natural que isso aconteça, mesmo sabendo disso. Ao fazer isso podem acabar naturalmente pensando “o que eu preciso fazer pra alguém como o Akita dar confiança pra alguém como eu”? E é aí que você começou errado, como eu já disse, a confiança você já tinha.

Se assim como eu, você for uma pessoa insegura e introvertida, agora virou receita de nitroglicerina. Mesmo que eu te diga verbalmente “eu confio em você”, ainda assim você vai duvidar. Se você for uma pessoa segura de si e de suas habilidades, vai ser tranquilo, porque você vai pegar minhas moedas de confiança, e construir em cima.

Se você for essa pessoa insegura, vai começar a se auto-sabotar. Você vai ignorar que eu falo direto e reto, e vai tentar ficar lendo nas minhas entrelinhas, tentar ficar prevendo todas as formas que eu posso te trair, porque você considera que um cara como eu deve ter conspirações pra tudo. De novo, estou falando da situação de relacionamentos assimétricos, empregado e empregador é exemplo onde o empregado sempre acha que o empregador tem mais poder e por isso sempre tem uma conspiração contra ele. Mas o empregador não tem tempo pra joguinho, ele já deu a confiança ao te contratar, o salário no fim do mês é um símbolo disso, mas na cabeça desse empregado inseguro é uma relação desigual. Mas entenda, é desigual só na sua cabeça.

Se você ficar toda hora achando que eu vou te trair, você vai atrair isso pra sí mesmo. E não estou falando de forma kármica ou algo assim. É muito simples, você vai se preocupar tanto que vai performar mal, que eu vou te avaliar mal, que vai tentar prometer mais do que consegue entregar, e tudo isso vai desgastando nossa confiança. Um belo dia o relacionamento acaba e na sua cabeça fui eu que te traí.

Ao mesmo tempo, uma pessoa insegura tende a acreditar muito rápido em quem não devia confiar. E isso parece não intuitivo, mas quando você tem baixa auto estima, se sente inseguro, vai tender a dar suas moedas de confiança a um terceiro que vai tirar proveito de você. O colega de trabalho que corrobora com suas neuroses. “é isso aí, seu chefe não tem porque gostar de você, ele vai puxar seu tapete”. É o lobo em pele de cordeiro. E como existe o fator de viés de confirmação, tudo que confirma sua neurose vai parecer verdade e esse seu pseudo-amigo vai parecer um puta amigão por confirmar sua neurose. É por isso que é auto-sabotagem. Veja, nada aconteceu até agora, eu não fiz nada, nem fiquei sabendo da sua neurose, mas você já confirmou que eu vou te trair.

Uma coisa que vocês já viram que meio que discordo com o consenso geral na semântica é que confiança é uma coisa que se ganha ou conquista. No final pode até ser, eu diria que confiança é uma coisa que se fortifica ou se perde. Mas entenda, ela já foi automaticamente dada na entrada, senão o relacionamento nem teria iniciado. Não precisa se esforçar tanto pra ganhar mais.

Com medo de perder a confiança que te foi dada, com a insegurança fazendo com que você confie muito rápido nesses lobos em pele de cordeiro, com esse viés de confirmação de suas neuroses, nessa etapa, você vai ficar com medo, então nosso relacionamento vai se tornando mais e mais superficial. Você vai pisar em ovos pra falar comigo, ou evitar falar sobre seus medos. Ou seja, você se distancia sozinho e cada vez perde as chances de entender quais eram as reais expectativas. A coisa mais simples que você deveria fazer era falar comigo, com seu chefe, ou seja lá quem é o alvo da sua neurose. Perguntar não machuca e não ofende, errar por negligência de perguntar sim. Pessoas como eu, por outro lado, não somos bidu, não temos como saber o que você está pensando e por isso não podemos te ajudar se não falar comigo.

E se você realmente começar a errar por causa disso, seu próprio erro vai nutrir sua insegurança. Aí você vai começar a chegar na etapa de que a qualquer momento eu vou te demitir ou cortar relações ou algo assim. Tá vendo como esse ciclo vicioso cresce rápido? Nesse estágio, você vai começar a justificar seu medo. Se eu fizer qualquer erro trivial com você, você vai considerar uma quebra de contrato imperdoável. Uma traição.

Por exemplo, eu combinei de falar com você numa hora mas eu acabei esquecendo ou só atrasei. Ou eu acabei gritando com você por qualquer motivo ou falei mais grosso porque estava de mau humor com outra coisa. Tudo coisas pequenas, que um pequeno “me desculpe” da minha parte resolveria, mas na sua cabeça, já foi um pecado mortal, era o gatilho que faltava. E claro, porque internamente você já está sofrendo tanto tentando “me agradar” que eu fazer isso com você é uma traição.

E a conclusão fatal de tudo isso é que não sou eu que vai te mandar embora, você mesmo é quem vai. Você decide que a pressão é muito alta, que eu não vou conseguir entender você, e acima de tudo justificado porque na sua cabeça eu te “traí” de alguma forma. Somado com seu problema de confiar rápido demais em quem não devia, recebe conselhos errados e resolve ir pra outra empresa pior ou outro relacionamento pior onde, no curto prazo, faz você se sentir menos sufocado. Mas eis a questão, não era eu que estava te sufocando, você estava sufocando você mesmo. E você fugiu, então as chances da mesma situação se repetir depois são altas.

Eu disse que isso nasce quando na sua cabeça a balança pende mais pra um lado, onde você “sente” que eu sou grande demais e por isso qualquer esforço que você faça pra me agradar nunca vai ser suficiente, coisa que obviamente não é verdade, senão eu nem teria te dado atenção.

E o que você deveria ter feito? Especificamente no caso se for alguém como eu do outro lado? Simples, na verdade, pessoas como eu não precisam ser constantemente agradadas, não precisam de cuidados especiais, eu não quebro à toa porque você teve um dia ruim, eu não julgo você porque errou uma vez. Uma única pequena ação ruim não vai ser motivo pra eu te mandar embora tão drasticamente. Pelo contrário, como você contorna o dia ruim é que aumenta seu valor, e como você pede ajuda pra mim. Mas, se um belo dia você chega em mim e diz que vai embora, já é tarde demais, mesmo se eu quisesse, agora eu não tenho nenhuma ação a fazer a não ser aceitar. E muitas vezes é uma pena, eu sinto como um potencial desperdiçado.

E você foi embora por conta própria. A situação poderia ter sido facilmente contornada, se você tivesse arriscado só um pouquinho, me chamado de canto e contado do seu medo, eu teria dito pra não se preocupar e só fazer seu trabalho direito que era o suficiente e me pedir ajuda sempre que precisar.

Ambas as situações já aconteceram comigo: pessoas inseguras que me pediram ajuda e progrediram, e pessoas inseguras que se auto-sabotaram e foram embora.

Eu me sinto um pouco culpado quando essas coisas acontecem, porque comunicação é uma via de mão dupla. Não basta dizer, o comunicador é quem tem a responsabilidade de garantir que a mensagem foi recebida E interpretada da forma correta. Em termos técnicos é como o protocolo da internet funciona, o TCP, todo pacote enviado tem um pacote de acknowledgement recebido, se essa confirmação não vier, a gente repete o pacote. E comunicação é igual, mas é mais difícil de saber se a mensagem foi recebida ou não. A pessoa pode até dizer “entendi”, mas daí a realmente entender são outros 500. Eu digo, escrevo, gravo vídeos, na esperança que eu repeti tanto que pelo menos a maioria vai uma hora entender o que eu quero dizer.

Obviamente como ser humano, eu nunca vou ser perfeito, por isso eu repito pra não me colocar num pedestal. Eu certamente já demiti injustamente, sem entender o outro lado. Eu já tive meus dias de fúria em que acabei descontando em alguém injustamente. Já ofendi sem querer. Todo mundo já fez isso e o máximo que eu posso fazer é entender que isso aconteceu e não fazer de novo. E eu só vou saber que aconteceu, se você me disser.

E eu fiz a analogia com uma relação de trabalho, que é o caso mais comum. Mas uma relação pessoal é a mesma coisa com uma grande desvantagem. Numa relação de trabalho o resultado é objetivo: você tem um trabalho específico pra fazer, pra isso eu pago um valor específico, os termos estão claramente descritos num contrato, de forma não ambígua. Ter um contrato é sensacional, basta ler pra saber o que pode ou não pode fazer.

Num relacionamento pessoal esse contrato não existe, é um processo demorado de tentativa e erro. Como eu disse no começo do vídeo, a história tem um twist. A motivação desse tema é porque recentemente eu estive do lado oposto dessa história, num relacionamento pessoal. Tá vendo como funciona curadoria de rede social, é o tipo de coisa que ninguém estava sabendo. Em resumo, eu coloquei uma pessoa num pedestal (e as qualidades de fato justificavam isso). Eu posso falar sobre insegurança porque eu sou inseguro por natureza, pra quem não sabia, e introvertido. Eu preciso fazer um esforço consciente pra controlar minha insegurança. Lembram do que eu falo de treinamento deliberado? Mas desta vez isso me pegou em cheio. Como na história anterior, eu me senti inadequado, comecei a me auto-sabotar, a me sufocar sozinho, e no final, por medo de ser “demitido” entre aspas, eu pedi “demissão” antes. Ou seja, o relacionamento nem tinha realmente começado, pior, tinha todos os elementos pra dar certo, e por causa de tudo que expliquei acima, eu terminei antes de dar chance de começar.

Viu só, é muito mais fácil falar do que fazer. Tudo isso que eu narrei eu já sabia. Eu vi acontecer. Na hora H até eu fracassei. Qual a única coisa que se pode fazer? Aprender a lição e não fazer de novo. Até lá, só resta lamentar com nosso camarada Balvenie … e claro, Balvenie porque a intenção é só lamentar, não queimar neurônio com Red Label. …

Isso que chamamos de um cautionary tale ou conto preventivo. Estou dizendo tudo isso com o objetivo de prevenir alguém de cometer o mesmo erro. Ainda bem que nem todo mundo é assim, mas quando você tem problemas de insegurança e ainda mais se é uma pessoa introvertida, você vai internalizar o medo, vai acabar fazendo esse medo crescer, e quando você encontrar qualquer coisa super trivial pra justificar essa neura, ela vai explodir e te consumir de uma só vez. Eu não fiz o que eu mesmo falo pras pessoas fazerem: sleep on it, que quer dizer durma sobre o problema, no dia seguinte se eu tivesse feito isso, não teria tomado a decisão errada. Faltou um segundo de controle, e a moral da história é que por causa de 1 segundo, um caminho inteiro foi bloqueado.

Muitas pessoas fizeram isso comigo ao longo dos anos. Muitos deles se ressentem de mim até hoje, pra justificar terem tomado essa decisão. Eles acham que eu nunca vou perdoá-los. Tirando 1 ou 2 casos extremos, na real, eu já perdoei todo mundo. A única coisa que falta é elas perdoarem elas mesmas. Eu nunca rejeitei um pedido de desculpas. Muitas pessoas fizeram esse caminho de volta.

Como evitamos esse tipo de situação? Não tem uma resposta óbvia, se tivesse todo mundo já estaria usando e milhares de psicólogos perderiam sua profissão :-) Eu estava no meio dessa situação e eu não percebi isso, porque estava sufocado demais alimentando teorias da conspiração e procurando “evidências” triviais pra justificar essas neuras.

Um outro pensamento, eu sou um empreendedor, de muitas formas, como empresário, como comunicador, como mentor. Quem ainda idealiza o trabalho de um empreendedor pode pensar que nós fazemos planos perfeitos, que sabemos o passo a passo pro sucesso. Não é verdade. Um bom empreendedor é quem quebra a cara muitas vezes. A gente tenta 10, 20 vezes. Tentamos várias coisas diferentes. Com tempo suficiente, esforço suficiente, e inteligência, uma delas finalmente dá certo.

Tirando os casos de muita sorte, de estar no lugar certo na hora certa, a grande maioria dos empreendedores na verdade são especialistas em lidar com fracassos. Nenhum de nós é perfeito, muito pelo contrário aliás. Por isso tem aquela velha frase: “quando eu era pobre me chamavam de maluco, agora que sou rico, me chamam de excêntrico”.

E você, qual é o seu caso de relacionamento prematuramente quebrado por inseguranças? Conseguiram perdoar vocês mesmos? Compartilhem com a galera nos comentários abaixo. Se curtiram o vídeo mandem um joinha, compartilhem o vídeo com seus amigos, assinem o canal e clique no sininho.

Esta semana, de novo, vai ser só um vídeo. Chegou meu novo workstation de edição que preciso configurar e vou gastar um tempo. Então a gente se vê terça que vem, até mais!

Descrição no YouTube

Errata a 25:16 a legenda está “colégio” mas é “faculdade” :-)

Novamente um episódio que ficou um pouco longo então será o único desta semana.

Desta vez quero explorar como eu aprendi inglês e aproveitar pra explicar porque é tão importante inglês na nossa área e também porque NÃO é tão complicado como muita gente pensa. Trabalhoso, sim. Caro ou complicado, não.

Uma tangente neste assunto será tocar no que muita gente pensa sobre “padrões” e o erro nesse pensamento. Fiquem ligados!

Links:

• Off Topic: Somos Matematicamente Ignorantes (http://www.akitaonrails.com/2008/03/01/off-topic-somos-matematicamente-ignorantes)
• [Off-Topic] A Revolta de Atlas: Dinheiro é a raíz de todo o mal? (http://www.akitaonrails.com/2011/02/03/off-topic-a-revolta-de-atlas-dinheiro-e-a-raiz-de-todo-o-mal)
• Descartes’ Error: Emotion, Reason, and the Human Brain (https://www.amazon.com.br/Descartes-Error-Emotion-Reason-Human/dp/014303622X)

Script

Olá pessoal, Fabio Akita

Já que eu tenho falado sobre estudo acho que vale a pena entrar no tema do temeroso Inglês. Todo programador sabe que deveria já saber inglês mas fica empurrando, empurrando, até o dia que começa a perder oportunidades, e aí percebe como já é tarde demais.

Vamos dizer o óbvio: pare com as justificativas, qualquer razão que você está usando pra não evoluir no inglês não é nada mais, nada menos, que puro … bullshit, a fucking big pile of turd.

Ah, isso é imperialismo, temos que ser patriotas, valorizar a língua nacional, bla bla bla mi mi mi fuck you se você diz imbecilidades como essa.

Tamos entendidos? Então vamos avançar

(…)

TUDO que sai de mais importante na área de tecnologia sai primeiro em INGLES. Sabe o que acontece se você depende de material em português? Você precisa esperar essa tecnologia ganhar público, alguém se arriscar a traduzir material em português e publicar aqui. E todo mundo sabe que todo projeto open source, principalmente nas primeira iterações, muda o TEMPO TODO.

Ou seja, do ponto de vista de retorno financeiro, Não é um bom negócio publicar livros de versões 1.0 de projetos open source porque o 2.0 vai sair em 6 meses e o livro vai ter pouco tempo de vida. Livro técnico é absolutamente chato de escrever - eu sei, eu já escrevi um. Especialmente porque se você demora muito, tem que ficar revisando todos os capítulos anteriores quando sai um update. E depois que publica ainda tem que ficar correndo atrás se sai outros updates que quebram os exemplos que você colocou no livro, ou seja, é um puta trampo de manter o livro atualizado ao mesmo tempo que o software ainda está inacabado e evoluindo.

Mundo open source é assim mesmo. E se por acaso um novo projeto consegue ganhar o seu público de early adopters e começa a ter demanda, sabe quem ganha mais dinheiro? Quem aprendeu sobre o software antes mesmo de ter saído a versão 1.0. Depois que saiu a versão 4, 5 etc que já tem livro, já tem curso, já tem toneladas de screencast, é quando o taxa/hora vale menos, 2x, 5x, 10x menor do que era pago pra quem se arriscou e aprendeu na versão 0.1 alfa.

Vocês já entenderam uma coisa meio óbvia? As pessoas ficam procurando “o que a maioria das pessoas está fazendo”. Eu penso assim: puts, se a maioria das pessoas tá fazendo uma coisa, é porque essa coisa vale muito pouco e nunca vão me pagar muito, justamente porque tem um milhão de indianos que vão cobrar 10x menos que eu pra fazer a mesma coisa.

Claro, o mais seguro é primeiro ir atrás de alguma coisa bem óbvia. Por isso eu falei no episódio de “O que devo estudar” pra ir num Java, C# ou PHP da vida. Mas qual o próximo passo? Ora, quem ganha mais na indústria? As moscas brancas. Os cisnes negros. Mas é muito raro você escolher, conscientemente, a tecnologia que ainda vai se popularizar, e acertar em cheio. Precisa de muita experiência pra isso, e mesmo assim você pode estar errado.

Se eu fosse resumir, você precisa saber duas coisas importantes: história e línguas. Mas não do jeito que você pensa. Todo mundo fica atrás só dos headlines, da notícia de hoje. Eu estou mais interessado em juntar as peças das notícias de ontem, de 1 ano atrás e de 1 década atrás. Eu fico constantemente comparando essas coisas. Não tem uma receita, mas quanto mais você estuda a história da sua área, mais você vai entendendo pra onde as coisas tem mais probabilidade de ir. Isso se chama reconhecimento de patterns, vou voltar nisso no fim do vídeo.

Agora, finalmente, línguas, que é o tema de hoje. Existem dezenas de formas de fazer isso e de novo, não vou dizer o óbvio. O óbvio está em todos os canais de YouTube de línguas e uma rápida procurada no Google vai te trazer uma tonelada de cursos online. Baixa lá o Duolingo e Just fucking do it!

Mas o que eu quero fazer é explicar como Eu encaro o aprendizado de qualquer coisa usando meu aprendizado de inglês como exemplo.

Sabe que tipo de pessoa aprende coisas mais rápido? Uma criança. Todo mundo já ouviu falar que toda criança é uma esponja, que aprende tudo que você ensina pra elas? Eu sempre ouvi falar isso e como toda cagação de regra que eu ouço eu parei pra pesquisar e refletir sobre isso.

Eu me considero uma criança em muitos aspectos, até hoje. Uma delas é que eu não tenho muito apego a nada. Portanto eu tenho muito pouco a perder. E isso é uma criança: ela não nada pra perder, ou melhor, ela nunca parou pra considerar que tem coisas pra perder, e por isso não tem medo de arriscar nada. Tudo pra ela é uma oportunidade, lembra que eu venho repetindo muito isso nos episódios anteriores?

No caso de línguas, todo adulto começa pensando que tem muito a perder. O adulto começa a pensar no que os outros vão pensar, como os outros vão julgar. Será que vão dizer que estou demorando muito pra aprender e acharem que sou devagar? Será que vão dizer que eu não consigo falar e achar que sou incapaz? Será que vão ficar tirando sarro de mim e vou virar a piada do grupo? Daí você pára e pensa, se vou aprender tem que ser sério! Se é pra ser sério, precisa ser num curso top. Só que curso top é caro e eu não tenho dinheiro agora, e se for pra pagar caro precisa reservar muito tempo senão não compensa. Hm, como não tenho nem dinheiro e nem tempo, vamos deixar pro próximo semestre que aí vai dar tempo de guardar dinheiro e organizar minha vida pra ter tempo …. Daí passa seis meses e o que acontece? Nada.

Agora tente se lembrar de você quando criança ou qualquer criança que você conheça, seu sobrinho, seu filho, seu neto? Aos 2 anos de idade, quantos cursos top de português ela fez? Quantas horas em salas de aula com professores especializados ela fez? Quantas certificações em cursos especiais ela tirou?

Não é possível que você nunca tenha pensado que em 2 anos, uma criança sai do zero pra razoavelmente fluente numa língua, o suficiente pra você entender sentenças inteiras e em mais 2 anos ela tá quase tão fluente quanto você (ou melhor, se bobear). Obviamente, não adianta falar com ela de coisas técnicas específicas, falar em bolsa de valores, física, engenharia, tudo vocabulários que ela não vai saber. Mas largue essa criança num shopping center e certamente ela vai conseguir se comunicar com tudo mundo. E se ela não entender alguma coisa? Ela vai perguntar e perguntar e perguntar, até ficar satisfeita com a resposta, que é exatamente o que VOCÊ não faz.

Não subestime esse processo. Todo mundo quer esse processo na verdade, por isso você vai fazer intercambio. Todo mundo tem essa intuição de que se você fizer uma imersão num país estrangeiro, você vai magicamente, aprender mais rápido. Qualquer metodologia que te incentive a se concentrar acima do normal num período limitado de tempo funciona da mesma forma, indo pro exterior ou não. Ir pro exterior pra mim é mais status do que necessidade. Mas claro, se puder, com certeza vá, a experiência maior é a vivência mais do que o estudo. Trabalhe num bar, pague seu curso e passe 1 ano morando fora. Você provavelmente não ia precisar ver meus vídeos se tivesse feito isso :-)

Claro, você precisa ter um mínimo de estrutura. Nem que seja as porcarias de aulas de inglês que tivemos na nossa escola, que ensinou só o basicão do verbo To Be e meia dúzia de palavras. Mas isso deve ser o suficiente.

Eu mencionei num dos vídeos que quando eu comecei a fazer faculdade, meu inglês não era fluente. Eu lia devagar e não tinha nenhuma fluência pra falar, nem pra arriscar frases. O que me motivou foi no primeiro de aula o professor listar livros estrangeiros na bibliografia e eu ter colegas de classe que já tinham morado fora ou feito intercambio e estavam na minha frente. Eu já disse também que é o tipo de coisa que me deixa motivado a correr atrás.

E foi exatamente o que eu fiz. E aprendizado é que nem dieta, ou você faz all-in, sem compromisso, ou não faz. Do, or do not, there is no fucking try.

Vamos lá, assim como 99% da população, eu só comprava livros e revistas em português, eu só assistia filme dublado ou com legenda, eu ouvia música mas sequer prestava atenção nas letras e eu evitava tudo que tinha inglês. Eu fiz aqueles cursos de bairo, no caso Fisk, mas eu desisti porque não via evolução. Era essa minha situação no ano em que entrei na faculdade. Eu nunca fiquei 100% perfeito na fluência, mas ouçam vocês mesmos:

Ok, so I spent the next 10 years under lockdown. In my mind, I have decided that just enrolling in an ordinary English course would be too damn slow. I am not advocating that classes are not good, it’s just not right for someone like me, I am a stubborn son of a bitch that wants to dictate my own pace, which is usually faster than average.

Moreover, I wanted to speak as close to a native American as I possibly could without having to live there. What if I consumed the exact same things every day as if I was living in a USA city somewhere?

If I moved there, there wouldn’t be any Portuguese resources anywhere. So I’d be forced to browse in the web in English, go to Barnes & Noble and buy English-only books and magazines. I’d like to go to the Chinese Theater in LA to watch the blockbuster premieres, all in English.

So, it was only a matter of emulating the exact same environment in my own routine. I never bought or read a single book or magazine in Portuguese ever again. I spent a good portion of my small salary by importing computer books. I was paying 5x more buying magazines such as Wired, or PC Magazine. I rented movies at Blockbuster, and I had to put a box in front of the TV set to hide the Portugues subtitles. And fortunately, I am the kind of nerd that watches the favorite movies many times over.

Did you read my blogs and facebook or twitter timelines? To this day, more than 20 years later, I keep writing in English as much as I can. This procedure became my routine. To this day, I avoid consuming Brazilian sources, it’s just a habit. I don’t read Brazilians books, I don’t watch Brazilians tv-shows. It’s considered normal nowadays to not watch the open TV because of Netflix, but I have been doing that since the mid-’90s. Let’s say I was ahead of this curve by at least a decade. YouTube, Netflix, Amazon Kindle, just made my life easier.

When I was in college, I did all my programming in English. It always felt wrong to mix Portuguese variable names with English-based statement syntax. It’s just wrong. Don’t do it. If for nothing else, only realize that if you use Portuguese, you won’t ever be able to open source it. I am not saying that you should open source everything, but why are you closing that door so soon? And you can’t ever hire programmers from other countries to help out either. Writing code in Portuguese limits the reach of that code.

I spent around 5 or 6 years consistently doing precisely that. From my first year in college to the dotcom era. Remember that PSN dotcom I mentioned I worked for? So they wanted me to fly to their Florida office to get acquainted with the other developers. This was 2001, and it was the very first time I set foot in the USA.

Remember when I mentioned that you want to be ready when the opportunity arises? That’s precisely my point. If I had procrastinated, I would have missed that chance.

And let me tell you: no amount of theory will save you in practice. I realized my limitations when I arrived there. Jesus Christ, the freaking Cubans, and their Spanish-mixed English are stupidly hard to understand. And I had people from Texas in the office, also a crazy difficult accent to follow. I think I can deal with them way better today, but for my very first attempt, I had to ask people to repeat slowly many times. And don’t think for a second that I didn’t.

Over the years, I met people that have been teaching me. And this is super important. You feel ashamed when someone tries to correct your misspellings. And you lose an opportunity. Whenever someone corrects me, I engage. I say “hey thanks, so, is this the correct way, let me try again,” and if the person is willing, we end up spending a few minutes with training. That’s how I finally figured out the proper way of saying tree and three, and words like three, there, those, there. That was an afternoon coffee with a friend of mine from the USA.

Remember when I mentioned children? The sad thing about adults is that we lose our inner child. Learning is essentially letting your adult self aside and bring back the curious child back. Never feel ashamed, never hold your questions back. Children are interested, their parents even get upset when children ask too many questions. Let them. This is the only way to learn stuff: to question everything, no matter how silly it sounds. The only dumb thing is not to ask questions.

And again, will it be worth it? Will you ever be able to speak fluently like a native American? You could. It all depends on training and commitment. As you can tell by now, I can’t. This is the closest I could get.

The interesting thing you don’t think about? The Americans don’t care. They can tell I’m not a native. But I’m understandable, and that’s enough. In their minds what they immediately think is: “damn, this guy speaks better English than I could ever speak any other language.” That’s right, most Americans only speak English, they respect anyone that can speak more than one language, and they appreciate you even more for being understandable to them.

Americans are used to different accents, they have Latinos, people from Mexico, Republica Dominicana, they have Chinese, they have Italians, and so on and so forth. There are dozens of dialects and accents throughout the country.

And if you add English from Great Britain, the Netherlands, Australia, it’s all different. Your particular accent, my own accent, doesn’t sound nearly as bad as you think it does.

You are an adult, what the heck are you ashamed for? Mockery? Oh, come on. This is bullshit. The only reason you’re not studying and doing your best right now is your own laziness. You’re just lazy, admit it. It’s pathetic. If you really wanted you could start right now, for zero bucks. Change your Operating System default language to English - seriously, I have a hard time with Windows in Portuguese because I can’t find anything, I am used to English and the order of things in English. Then, erase all your Portuguese bookmarked websites. Change the default language of your web browser to English. None of this cost any money.

Install tools like Grammarly to correct your terrible written English. Read as much as you can, every day, in English. Listen to as much as you can. I subscribe to hundreds of English-only YouTube channels, I have zero Portuguese channels. Netflix? Start with subtitles in English - it’s so awesome that there is this option; if only I had it my VHS days. When you go rewatch a movie you like, turn the subtitles off. And instead of not paying attention because you feel uncomfortable, do the opposite, pay extra attention, pause the video whenever you learn a new word. Get your smartphone and Google it. The tools we have today make the learning process so much easier. I do that myself. For example, I just learned a new word that I never used before: “unrequited,” which means “unreturned, like a feeling not reciprocated,” and that was from Woody Allen’s Cafe Society movie. Old movies always teach me words I never used.

As a disclaimer, also keep in my that I always read a scripted text in my channel, and this section was no exception ;-)

Now, let me switch back to Portuguese!

Eu acho que eu soou diferente quando eu falo em inglês e português, porque você não pode falar inglês com o mesmo ritmo que fala português do mesmo jeito que seria bizarro você cantar, por exemplo, um Fly me to the Moon do Frank Sinatra com ritmo de Funk. Pensa como fica. Você precisa respirar diferente. E é mais fácil “ver” isso quando assiste séries e filmes, comece a prestar atenção na linguagem corporal dos atores. Eu já fiquei horas fazendo careta pra TV pra imitar a posição da boca e o jeito de inspirar e expirar as palavras. E sobre respiração, uma coisa que eu vejo 90% das pessoas fazendo errado: fale as palavras até o fim, não tente conectar uma palavra na outra como fazemos falando português corrido. Fale inglês como um gaúcho ou sulista fala português, pausado, correto, palavras até o fim, com pausa. Só isso já é meio caminho andado pra ser entendido.

Mas se você não está convencido, vou dizer uma última coisa que eu acho muito importante, inclusive tem a ver com programação. No mundo da programação, você frequentemente vê o povo falando de padrões de programação ou padrões de arquitetura.

Quando alguém fala “padrão” parece dizer no sentido de “é a melhor forma” de fazer alguma coisa. E isso está errado. Em inglês temos 3 palavras diferentes: standard, default e pattern. Os 3 traduzem em português pra padrão, mas eles querem dizer 3 coisas completamente diferentes.

O que você pensa por padrão, normalmente é o que o americano pensa quando diz “standard”. Um standard a ser seguido.

Ou você tem default, que é a escolha padrão, ou quando você não escolhe, o que é escolhido é o default.

Finalmente, pattern é simplesmente alguma coisa que aparece várias vezes. Pode ser certo ou errado. Um pattern pode simplesmente indicar uma tendência. Por exemplo, se todo mundo resolver começar a usar calça vermelha. Isso é uma moda, posso dizer que é um pattern. Ou dizer que toda boa pizza “costuma” ter queijo, é um pattern. Mas não é um padrão ou 100% das pizzas precisariam ter queijo. Entendem a diferença?

Por isso, toda vez que em programação você ver algum livro ou matéria falando em “padrão de arquitetura”, não pense que esse deve ser O jeito certo de fazer. É só um jeito que, naquele momento que o texto foi escrito, o autor viu com alguma frequência, o suficiente pra chamar de pattern. Em 1 ano pode já estar obsoleto porque assim como tendências, patterns também ficam velhos, outros patterns aparecem.

Se você parar pra entender o básico sobre como o cérebro funciona, do ponto de vista neurológico, um de nossos melhores mecanismos é nossa habilidade de aprender e detectar patterns. É parte do que chamamos de instinto, quando sentimos que vamos ser atacados, e fugimos sem pensar. Ou mesmo quando vemos textos como este:

(…. texto bagunçado)

Nós não lemos palavras de letra em letra, nós identificamos o pattern e vamos lendo em clusters, às vezes pulamos uma sentença inteira se for um cliche ou um chavão. Porque o pattern economiza nosso processamento, é meio como uma rede neural artificial funciona, ou o que chamamos hoje de machine learning, é basicamente identificação de patterns.

Patterns também tem efeitos colaterais, é de onde temos as ilusões de ótica por exemplo, onde vemos patterns que não existem ou patterns que nos confundem:

(… ilusao de otica)

Psicologicamente é de onde vem muito de nossas neuroses e até mesmo teorias da conspiração que é basicamente vermos patters que não existem, adicionar causalidade a coisas que não tem correlação. Tudo é parte dessa identificação de patterns.

Quando aprendemos inglês nos inserindo no ambiente como eu fiz artificialmente, mesmo que eu não entenda tudo que estou lendo ou ouvindo, se eu praticar deliberadamente a repetição, eu eventualmente vou “sentir” quando algo soa correto ou não. Eu não lembro a regra gramatical. Quando eu leio uma frase eu sei que “soa estranho” ou não. I won’t do it, ou I’m not gonna do it, são literalmente a mesma coisa, mas naturalmente eu digo um ou outro sem pensar muito. E eu argumentaria que pro dia a dia, isso é um bom nível, quando você naturalmente fala uma frase de acordo com o contexto da conversa sem precisar conscientemente pensar na construção dessa frase, que é exatamente como você fala sua língua nativa: você não precisa fazer um esforço consciente muito grande pra simplesmente falar.

Em resumo, o que normalmente chamamos de Padrão não é Standard. É Pattern. E você saberia disso se lesse os livros em Inglês, em vez das traduções em português, onde é impossível traduzir o contexto exatamente como o autor gostaria. Toda tradução perde parte do sentido, não importa quão bom seja o tradutor, especialmente porque algumas coisas tem carga filosófica ou cultural que não tem como traduzir.

Um dos exemplo que eu mais gosto é quando traduzem “making money” pra “ganhar dinheiro”. Tecnicamente está correto. Você diz: “I’m going to work to make money” que traduziria pra “Eu vou trabalhar pra ganhar dinheiro”. Em português a frase implica que sua opção é trocar seu trabalho por dinheiro, em inglês não se diz “ganhar”, se diz “make” que é “fazer”, a frase em inglês implica a opção de você produzir onde antes não existia alguma coisa, que é a essência de empreender.

E na minha cabeça essa é uma das maiores diferenças culturais dos Estados Unidos pra qualquer outro lugar do mundo: lá, filosoficamente falando, o objetivo era construir e criar onde nada existia antes. No resto do mundo é dividir e tomar o que existe, ganhar o dinheiro, ganhar as terras, ganhar o poder, não construir.

E com isso eu espero que tenha conseguido explicar o que eu acho sobre aprendizado e em particular o que eu acho que pode ajudar na sua jornada pra aprender outra língua. Eu fiz mais ou menos a mesma coisa pra aprender Japonês. Em ambos os casos eu fiz sim curso, até o básico e saí do curso, aqueles cursos de bairro sabe? Como auto-didata eu acho que não fui tão ruim, o que vocês acham? E quais são as suas histórias não convencionais de como aprenderam línguas? Não deixe de compartilhar nos comentários abaixo, se gostaram mande um joinha, compartilhe com seus amigos, assine o canal e clique no sininho. A gente se vê, até mais.

Essa é uma pergunta clássica e capciosa usada em entrevistas. E se você assistiu ao magnífico “O Lobo de Wall Street” do Scorsese, vai se lembrar dessa frase na hora.

Mas quantos de vocês pararam pra pensar de verdade no que essa pergunta implica?

Introdução

Existem inúmeras formas de tentar me vender uma caneta. Você pode falar sobre a tradição da marca fabricante. Pode exaltar a suavidade excepcional com que ela escreve. Pode tentar me convencer pela variedade de cores e tamanhos disponíveis. Pode até desviar o foco da caneta em si e começar a se gabar de quantas centenas de canetas já vendeu, o seu currículo de guerra.

Meu argumento é que você pode fazer tudo isso e ainda assim perder o ponto. E na maioria das vezes não vai vender a caneta.

Já vi isso acontecer muitas vezes. A maioria das palestras técnicas que assisti, por exemplo, segue esse roteiro:

1. Quem é o vendedor palestrante. Realizações. Currículo de guerra.
2. O que está sendo vendido. A Caneta.
3. Como a Caneta é boa ou como é fácil de usar.
4. “Compre.” Fim da história.

Não há nada de errado com esses pontos em si. Às vezes o palestrante vai além e faz coisas “chamativas” e “espetaculosas”. Uma sessão de live coding para demonstrar o quanto ele é bom (não a caneta). Uma demo técnica mostrando o que a caneta faz. Fogos de artifício e rojões. Mas tudo isso se dissipa rapidamente, e ninguém fala sobre aquilo depois. Não gruda.

E você não vende a caneta.

Às vezes a força bruta sozinha, o peso da marca por trás de você, é suficiente para persuadir muita gente. Mas não a maioria. Em vez de vender a caneta, o palestrante vende a big brand, Microsoft, Google, Facebook. Era “ninguém foi demitido por comprar IBM” nos anos 60. O famoso F.U.D. (a trifeta de “Medo, Incerteza, Dúvida”). Hoje é “ninguém, geralmente, é demitido por escolher Facebook ou Google”.

De novo, você não está vendendo a caneta.

Desenvolvimento

Como qualquer bom vendedor vai te dizer, você está perdendo o ponto mais importante da sequência acima, entre os itens 3 e 4. Você desperdiçou uma quantidade absurda de tempo descrevendo o “O Quê”. A maioria dos palestrantes técnicos passa um tempo enorme explicando o “Como”, com exemplos de código, live coding, tentando te convencer de como aquilo pode ser fácil.

Mas eles frequentemente esquecem de fazer a pergunta: “POR QUE essa caneta pode ser importante pra VOCÊ”. O “VOCÊ” sendo a audiência. Você não está conectando. Falta empatia. Você está apenas dizendo pra eles, em vez de persuadir. Dizer e persuadir são coisas completamente diferentes.

O POR QUE é o que mais importa. E a parte difícil com audiências grandes é que cada pessoa tem um “POR QUE” diferente que precisa de uma boa resposta.

Sempre que vejo um palestrante/escritor/evangelista dedicando tempo demais a coisas imateriais como “benchmarks”, “performance”, “arquiteturas hiper-modulares”, vejo alguém perdendo uma fatia enorme da audiência. Essas pessoas têm motivos legítimos para se preocupar com esses pontos, porque vivenciaram isso dentro de Unicórnios como Netflix, Facebook ou Twitter. Só que mais de 95% do público nunca vai ter esses problemas.

Portanto, você está tentando empurrar uma Lamborghini pra pessoas que não só não podem pagar por ela, mas que, mesmo que pudessem, ela não estaria nem perto do topo das prioridades. Sim, a Lamborghini é obviamente um carro rápido e bonito. Mas POR QUE eu preciso dela? POR QUE você está tentando me empurrar isso? POR QUE essa caneta sequer é relevante pra mim?

Sua prioridade não é a minha prioridade!

Vejo uma entrevista como uma palestra para uma audiência de uma pessoa. E vejo um post de blog como uma palestra para uma audiência que não consigo ver. A estrutura é exatamente a mesma.

Mas numa entrevista individual temos uma vantagem extra muito importante: você pode fazer perguntas diretas! Você percebe o quanto isso é valioso? Numa palestra com audiência você precisa fazer suposições sobre o que as pessoas querem ouvir. Numa entrevista você pode perguntar diretamente e dar respostas objetivas, eliminando o espaço das suposições.

A ironia é que a maioria das pessoas não faz perguntas em entrevistas. É muito mais fácil assumir: “todo mundo quer ouvir o que eu gosto de ouvir, porque eu entendo mais do assunto”. Isso é a falta de empatia no seu nível máximo.

Imagine que você é um engenheiro top trabalhando com tecnologia sensível a performance na sua startup unicórnio. Você tentou tudo e decidiu escrever componentes críticos de tempo real próximos ao metal, em C. E agora você dá palestras sobre como é fundamental que todo mundo comece tudo em C.

Comunicação é uma arte. Exige pesquisa, estudo, prática. Você precisa dominar muito bem sua língua nativa, a gramática, as muitas construções de frase que melhor transmitem a mensagem.

Existem vários “padrões de design” quando se trata de Teoria da Argumentação, muitas armadilhas bem conhecidas, falácias que você quer evitar. Tudo isso para criar uma linha de raciocínio sólida como rocha, simples de entender e difícil de refutar.

Você não quer ser facilmente derrubado. Então cada frase que você entrega é como um movimento de xadrez: você precisa antecipar 10 formas diferentes de ser refutado e ter respostas para cada uma.

Por isso você precisa praticar. Escreva, fale o máximo possível, independente do evento. O ponto é a oportunidade de se expor a um público com pouco risco, independente do tamanho da audiência ou do seu ego. Só enfrente uma audiência grande quando estiver confiante de que pode defender seus argumentos.

Calibre suas armas antes de usá-las. Quando você começa a tocar nos POR QUÊs, pode estar provocando feridas abertas na audiência, então é melhor estar preparado.

Mas se você não for atrás dos POR QUÊs, é muito pior: você se torna ESQUECÍVEL. Você recebe aplausos no final, e uma hora depois ninguém lembra seu nome. Qual é o propósito de um palestrante que ninguém lembra depois? Ou de um palestrante que é engraçado e as pessoas lembram das piadas, mas não lembram o conteúdo da palestra?

As pessoas simpatizam com o palestrante, mas a mensagem é irrelevante. Se você quer ser ator ou comediante, ótimo. Mas se você quer convencer pessoas de um ponto de vista, isso é fracasso.

O mesmo vale para a escrita. Você deveria ter aprendido isso na escola. Se você passou pela faculdade e teve que defender uma dissertação, DEVERIA SABER que ela PRECISA ser dividida em pelo menos 3 seções: Introdução, Desenvolvimento e Argumentação, e Conclusão. Essas são as partes do O QUÊ, COMO e POR QUÊ.

No mesmo tema, se você tem afinidade com técnicas Ágeis. Você se lembra da clássica estrutura de User Story? A maioria das pessoas acha isso super irritante. Toda ferramenta no estilo Kanban esquece disso: simplesmente te dizem “escreva aqui o que você quer”. E a maioria das pessoas só quer escrever o O QUÊ. Às vezes escrevem o COMO. Mas têm preguiça de pensar no POR QUÊ.

Como X, eu quero Y, para que Z.

A 3ª seção é elusiva, mas é a ÚNICA seção que importa. É o POR QUÊ. Por que VOCÊ quer AQUELA funcionalidade específica? O POR QUÊ é o critério de aceitação. O Critério de Conclusão. A única coisa que você deveria estar buscando. Escrevemos o que ACHAMOS que queremos, não o que realmente PRECISA ser feito. A estrutura de User Story é mais uma ferramenta para forçar o seu cérebro reptiliano a usar um pouco mais da sua matéria cinzenta mais moderna.

Conclusão

Meu objetivo é chamar atenção para um ponto que muitos palestrantes e blogueiros não estão fazendo: vocês estão se concentrando demais no O QUÊ e no COMO e deixando de explorar a verdadeira preocupação da audiência: o POR QUÊ!

De novo, sempre que você ver aquele tema barato de “minha linguagem é melhor que a sua” e o argumento é: “porque nos benchmarks podemos ver claramente que é 50% mais rápida” ou “podemos ver claramente que usa 50% menos memória” ou “podemos ver claramente que consegue rodar mais processos concorrentes ao mesmo tempo”. Todos esses pontos estão perdendo o alvo.

Isso é o COMO. Tudo bem.

Mas 95% da sua audiência raramente vai se identificar com esses pontos. Eles vão concordar num nível consciente, mas o subconsciente vai lhes dizer a verdade: “você não tem esse problema.” Na maioria das vezes os servidores deles estão ociosos, sem fazer nada. De que adianta um ganho de performance de 50% ou 200% pra eles? Não adianta nada.

É uma falta grave de empatia quando um programador, trabalhando numa empresa grande, com muitos times diferentes colidindo com monólitos enormes e código legado, decide que microsserviços é o caminho. E agora ele “sabe” que se é bom pra ele, deve ser bom pra todo mundo, certo? Portanto, qualquer um fazendo diferente é um idiota.

Não é. A maioria dos outros times no mundo pode ser de 3 a 5 pessoas com projetos que ainda nem chegaram à luz do dia. E aí está: tentando implementar sua super-arquitetura mirabolante, sem obter nenhum valor de volta, porque isso atrasa o tempo de lançamento no mercado.

Ah, a concorrência os alcançou, lançou primeiro, eles perderam o timing, e tudo porque confiaram na sua opinião de visão estreita, na sua falta de empatia com sua audiência. E isso no caso em que eles te ouviram. A maioria já esqueceu o que você disse, porque nunca tocou nas preocupações reais deles de qualquer forma.

E eu também sou culpado, faço isso às vezes. No começo da minha carreira fazia mais, e quanto mais velho fico, mais cuidadoso me torno com a forma como construo o que quero dizer. É muito difícil enxergar além das nossas pequenas rotinas. É difícil se comunicar com uma audiência maior e diversa. Mas se esse é o papel que escolhemos perseguir, precisamos fazer melhor.

Espero que isso tenha dado a vocês alguma perspectiva sobre como estruturar seu pitch em palestras pequenas ou grandes, entrevistas individuais ou posts de blog. É tudo a mesma coisa: O QUÊ, COMO, e por último mas não menos importante, o POR QUÊ!

Eu e outras 11 pessoas administram esse grupo nas horas vagas, o que significa 500 pessoas por administrador. Portanto, para que as coisas funcionem de forma eficiente, precisamos da colaboração de todos.

Primeiro de tudo: se você for uma empresa procurando candidatos, esse é um excelente grupo para começar, mas não é a casa da mãe Joana e existem regras, então o mínimo que se deve fazer é: seguir as regras. O administrador André Stephano foi quem levantou a bola, então copio aqui o post que ele publicou no grupo:

Andre Stephano - July 10 at 2:33pm

Estamos pensando em voltar a forçar as empresas a informarem salário e forma de contratação se quiserem anunciar, dessa forma nenhum usuário perde tempo com algo que financeiramente é inviável e por outro lado, um anúncio generoso pode atrair desenvolvedores que não procuram emprego. O que acham disso?

Motivo: Tem sido uma prática comum empresas colocarem anúncios chamativos para atraírem desenvolvedores. Inclusive, um amigo próximo foi para uma série de entrevistas em outra cidade, pra um vaga pra desenvolvedor senior em Ruby (completo com devOps e design) que no final de tudo revelou o salário de R$ 3.300,00 em PJ. O pior que nesse caso, a seleção ainda estava cheia de pessoas que também tinham grandes expectativas e foram enganadas. Isso acaba desvalorizando um pouco nosso mercado, faz pessoas voltarem frustradas achando que essa é a realidade, outros perdem tempo e no geral, desse monte de gente, alguém bom acaba aceitando já que chegou até ali.

A ideia é fazer com que vocês saibam o que esperar antes de perder tempo enviando CV e indo pros processos seletivos. Querendo ou não, somos o principal canal de desenvolvedores Ruby no país, então pra postar aqui, que seja por nossas próprias regras.

“Quem tem medo de mostrar o preço é porque quer pagar pouco”

Regra: coloque a remuneração da vaga no corpo do texto do post no grupo, não vale dentro da descrição num link externo.

Alguém pode perguntar “E quem não concordar com isso?”. A resposta é simples: “não poste nesse grupo, tem outros lugares caso discorde.” Ninguém é obrigado a aceitar, só não vale a pena discutir mais sobre esse tipo de coisa.

Segundo: se você é um iniciante na comunidade, não use a desculpa de “sou iniciante na comunidade”. É como passar farol vermelho, causar um acidente e usar como desculpa “opa, foi mal, desconhecia que não podia passar farol vermelho.” Em Direito existe uma regra de que ninguém pode alegar o desconhecimento da lei. E eu cito:

"Para viver em sociedade existe um preço a ser pago: a obrigação de procurar conhecer o direito. Por isso, quando é possível ao agente conhecer o direito, mas ele age de forma indiferente ou preguiçosa, a punição é aplicada."

No momento da publicação deste post, existem 129 pessoas bloqueadas de acesso ao grupo porque ofenderam, desacataram, ou fizeram pouco das regras mínimas de convivência. São meros 2% da população mas já é significativo. Isso não é o Reddit e trolls não são bem vindos.

Terceiro: se você é um iniciante, sempre parta do princípio que você não é o primeiro a ter seja lá qual for a dúvida que você tem. E que qualquer coisa que você queira discutir, provavelmente já foi discutida. O Nando Vieira, (um dos administradores do grupo) já falou sobre isso em seu post “Como fazer perguntas inteligentes”.

Vamos a algumas perguntas frequentes:

• June 15 - Pessoal, estou pensando em fazer o curso de RoR no Alura.com.br. Alguém já fez esse curso no site do Alura? Recomendam algum outro curso online? Obs: menos o da Caelun que além de ser extremamente caro, no momento está indisponível.

• June 10 - Pessoal, estou terminando uma aplicação para uma empresa, e já hospedei no heroku, está até funcionando. Minhas dúvidas são: Posso deixar minha aplicação hospedada no Heroku para produção mesmo ? Não tem riscos ? Ou devo contratar um host e hospeda-la posteriormente ? Alguém que use heroku no dia a dia, poderia me dar algumas dicas?

• April 30 - Voltando a História dos IDE para Ruby. O q vcs estão achando desse? smile emoticon. Particularmente estou gostando

• March 10 - Pessoal, estou começando com rails e a experiência tá sendo horrível no começo, como provavelmente foi com muitos de vcs. A velha história de incompatibilidades de versões ruby, gems, problemas com certificados ssl para conexão https, etc, etc, … Alguem aí que já tenha conseguido atravessar esse inferno poderia me ajudar a achar uma configuração que funcione ? No início tentei desenvolver no windows mesmo, até fiz o bendito conectar com o mysql e funcionar, mas queria fazer do jeito certo. Aí parti para uma configuração mais recomendada, utilizando vagrant, até que apareceram os problemas com o Chef para a configuração do ambiente. Partir para Mac e$tá fora de que$tão, preferiria mesmo ficar no windows, mesmo que com uma VM. Resumindo: curto muito Ruby como linguagem e quero aprender Rails. Alguem poderia me indicar um tutorial que realmente FUNCIONE? Apenas para montagem do ambiente até que esteja tudo pronto para começar a desenvolver? Valeu !

Caso não saiba, todo grupo do Facebook permite fazer pesquisas:

Concordo, o search do Facebook não é nem de longe um Google, mas já ajuda. Não custa nada pesquisar lá rapidamente antes de duplicar um tópico que já foi discutido, literalmente, dezenas de vezes.

Mas vamos às respostas de sempre:

• GOOGLE! Se você está desenvolvendo e deu algum pau, pegue a mensagem de erro e pesquise no Google. Certamente está lá, só precisa procurar direito. Você vai ganhar na loteria se encontrar um erro que ninguém viu ainda. É mais provável que você pesquisou errado.

• Rails Guides - não seja um desses que já está vendendo serviço a clientes e sequer gastou um tempo estudando o Rails Guides. Ele tem TODO o básico que você precisa. Se você tem dúvidas cujas respostas estão lá, claramente, você não estudou o suficiente ainda.

• Vagrant - se você usa Windows, nem perca seu tempo. Instale Vagrant + Virtual Box (ou preferencialmente pague pelo VMWare) e use um ambiente Linux, não há mais o que discutir.

• Livros - como ler mais a respeito? Fiz um artigo algum tempo atrás com dicas disso.

• Tag: Iniciantes - leia alguns dos meus artigos com tag “Iniciante” para ter uma melhor noção. Por exemplo, “como resolver meu problema de Uploads?”, “ouvi falar que o Asset Pipeline é ruim, é mesmo?”, “ouvi falar que o DHH não gosta de TDD, e aí?”.

Normalmente se você tem alguma contra a dizer do tipo “Ouvi dizer que X acha Rails uma bosta”, pare e não poste a respeito. Em vez disso vá ao Google (sempre!), ao Quora, e pesquise antes. Você com certeza chegou tarde pra festa e todo mundo já discutiu a respeito. Além do mais “ouvi dizer que” é coisa de adolescente de revistinha Contigo e Ti-Ti-Ti. Vamos lá galera, somos Engenheiros ou Fofoqueiros??

Bola pra frente!

Aproveitando que temos um “LONGO” feriado prolongado de amanhã até segunda, talvez seja uma boa oportunidade para colocar tudo que já foi gravado das minhas palestras até hoje num mesmo lugar para que vocês possam assistir tudo de uma só vez ;-) Está em ordem cronológica, de 2007 até 2013 e pretendo continuar atualizando este post quando novas gravações aparecerem. Se conhecerem alguma gravação que eu não listei aqui me avisem nos comentários.

Se gostaram não deixem de curtir e compartilhar para que mais possam assistir também. Boa diversão!

RejectConf 2007 | Apresentando Ruby on Rails

May 11, 2012

[Arquivo] Rails Summit 2009 | Agile, além do Caos

Nov 14, 2013

Consegi 2010 | Dicas de Desenvolvimento Web com Ruby

May 3, 2013

[Arquivo] RubyConf Brasil 2010 | Ruby on Rails Rocks!

Nov 14, 2013

CPBR3 - Ecossistema. Cultura e Ruby on Rails

Feb 15, 2010

[Arquivo] 11° Encontro Locaweb - Agilidade e qualidade de projetos

Nov 14, 2013

[Arquivo] 12° Encontro Locaweb | Desmembrando Pessoas

Nov 14, 2013

TDC 2011 | Discutindo Rails e Arquiteturas

Jul 15, 2011

TDC 2013 SP | Ecossistema Ruby

Oct 10, 2013

DNAD 11 | Discutindo Rails e Arquiteturas

Agile Vale 2011 | A semente não entendida de todas metodologias as ágeis

Aug 23, 2011

Campus Party 2011

Jan 28, 2011

Techtalk Klarna | The Origins of the Brazilian Rails Community What’s New in Rails 4

Nov 27, 2012

(este foi gravado em Israel e o autor não habilitou embed, segue o link)

https://www.youtube.com/watch?v=tm1EBuMIacc

Secot V 2013 | Startups & Softwares

May 14, 2013

TV O Povo | Programa Conectado l Fábio Akita

Apr 18, 2013

Startup Vale 2013 | Startup e Software por Fabio Akita

Jul 19, 2013

Rupy 2013 | Tendências de hoje e amanhã no mundo ruby

Dec 11, 2013

Eventials

Como não fazer pesquisas usando “LIKE”

Nov 2013

(o embed fica muito grande, segue o link direto)

https://www.eventials.com/akitaonrails/como-nao-fazer-pesquisas-usando-like/

Tendo vivido em todos os lados por muito tempo, tenho uma novidade para vocês: programadores são péssimos comunicadores. Existe uma impedância de comunicação que está virando uma incapacidade séria. A impressão dentro das comunidades de programação é que o código é a única linguagem universal.

Só que “show me the code” não é tudo. Algum tempo atrás eu respondi no Quora que a coisa mais difícil para todo Engenheiro de Software entender é que 90% dos problemas de um projeto não se resolvem com código.

Sem querer generalizar, só para ilustrar: no mundo open source dá a impressão de que é o contrário. Mas note que a grande maioria faz pequenas contribuições, esporádicas, e mesmo quem participa mais ativamente ainda vive uma experiência fragmentada. O software fica pronto só quando fica pronto. E, no fim, a grande maioria dos projetos open source fracassa.

Para cada jQuery que dá certo, dezenas de outras bibliotecas Javascript nem são reconhecidas, mesmo tendo alguns aspectos tecnicamente melhores. Os grandes e melhor coordenados, com força bruta e colaboradores de sobra, costumam andar melhor. Só que força bruta apenas aparenta eficiência. E os que crescem mostram uma organização bem diferente, com datas de lançamento e roadmap de features, começando a convergir para o que conhecemos como “projetos” de verdade.

No mundo real, o tempo é curto, as pessoas são poucas, os riscos diretos são muito maiores e queremos mais controle sobre os resultados. Não vou entrar no mérito das melhores maneiras, mas, no fundo, no mundo real a comunicação é a diferença entre o fracasso e o sucesso.

Informar não é Comunicar!

A primeira coisa a entender é simples: só porque a informação “existe”, ou você a colocou em algum lugar compartilhado, isso não significa que você comunicou.

A comunicação tem 4 pontas: o comunicador, o recipiente, a mensagem e o meio de transmissão. Os programadores normalmente assumem só 2, o comunicador (ele mesmo) e a mensagem, e ignoram o resto. Vamos definir isso melhor:

"Comunicação só acontece quando o recipiente recebe e entende a mensagem. Se isso não aconteceu, não existiu comunicação."

Vamos descer um nível e falar em “geek”: existe um cliente, um servidor, um protocolo e um meio de transmissão. Se você empacotou a mensagem conforme o protocolo, abriu a conexão com o servidor e tentou enviar, mas a transmissão não terminou e voltou com erro, sabemos que a comunicação não aconteceu.

No mundo do TCP/IP, primeiro mandamos um SYN, que inicia a comunicação. Recebemos de volta um SYN-ACK, o acknowledgement do servidor dizendo que recebeu o SYN, e enviamos um ACK para indicar que a conexão está estabelecida. Com esse handshake, conseguimos sequenciar o envio e o recebimento dos pacotes e garantir que tudo o que foi enviado foi inteiramente recebido.

Nessa metáfora, eu diria que a maioria dos programadores entende melhor o UDP. Eles enviam datagramas de informação e não se preocupam se o recipiente recebeu todos os pacotes, simplesmente vão enviando. Dá mesmo a impressão de que programadores pensam em UDP, olhem só:

• não querem esperar um handshake pra garantir que a conexão foi estabelecida
• mandam pacotes pequenos de informações fragmentadas, pouco overhead de protocolo
• TCP se preocupa com congestion control e faz throttling, UDP vai mandando mesmo se o roteador dropar os pacotes
• se um pacote se perde, UDP não se preocupa em reenviar
• pensa que parece mais eficiente fazer broadcast e multicast

Funciona bem para comunicação com grandes grupos, em broadcast, onde basta uma porcentagem receber a mensagem. Eu diria que o UDP funciona até bem no mundo fragmentado do open source. Mas num mundo onde estabelecer conexão e garantir a entrega da mensagem importa, vamos de TCP.

O TCP funciona porque, mesmo com uma conexão ruim, mesmo com um servidor meia-boca, você controla o stream de dados e garante que tudo chegou, na sequência correta, com 100% do que foi enviado recebido. No UDP, se o meio de transmissão é ruim, se o servidor recebe a informação corrompida, ele não se importa e continua enviando.

Ambos os protocolos têm utilidade. Mas, se precisamos ter certeza de que a informação foi recebida certa e por inteiro, precisamos do TCP. No mundo open source, tudo bem usar UDP para se comunicar, baixar a latência e ser mais “eficiente”. No mundo fora do open source, e isso vale para muito além de software, precisamos ser mais TCP. As vantagens do TCP?

• garantir que a conexão foi estabelecida antes de mandar informações
• garantir a ordem da informação, rearranjando pacotes se necessário
• moderar a velocidade da transmissão pra não floodar o outro lado
• garantia da entrega da mensagem, não só da transmissão
• checagem de erro, pra garantir que a informação não foi corrompida
• “acknowledment”, garantir que o outro lado recebeu e entendeu a informação

Veem a diferença? Parece que demora mais, mas é aquela velha história: entregar rápido e depois ter que reentregar várias vezes acaba saindo mais lento do que garantir que na primeira vez a mensagem foi entendida. É que nem escrever código sem testes, parece mais rápido, mas depois vêm as consequências.

Portanto, programadores, ajustem seus protocolos. Sejam mais TCP do que UDP.

Meu último artigo de tradução, sobre “Padrões: Excelência vs. Mediocridade”, rendeu uma discussão paralela interessante especificamente sobre “Design Patterns”.

Para quem não é de programação: nos anos 70 surgiu o termo “Design Pattern”, reforçado nos anos 90 pelo “livro do Gang of Four”. Segundo a Wikipedia, em engenharia de software um “design pattern” é uma solução reusável geral para um problema que ocorre comumente em design de software. Um design pattern não é um design fechado e acabado que pode ser transformado diretamente em código. É uma descrição ou template para como resolver um problema que pode ser usado em muitas situações diferentes.

Para nós, no Brasil, existe um enorme problema, e a ficha só me caiu por causa da discussão nos comentários daquele artigo. A reclamação foi que traduzi “Design Patterns Standards” como “Padrões de Design”. O Ronald, autor da crítica, levantou um ponto correto: as palavras em inglês “default”, “standard” e “pattern” traduzem todas para a mesma palavra “padrão” em português.

Mas as 3 palavras têm significados muito diferentes:

Default – uma opção pré-selecionada adotada por um programa de computador ou outro mecanismo quando nenhuma outra alternativa é especificada pelo usuário ou programador. Exemplo: o “default” é 50 linhas

Pattern – 1) um design decorativo repetitivo (como em “patterns” de cor numa roupa). Um arranjo ou sequência regular em objetos comparáveis ou eventos. Uma forma regular e inteligível ou sequência discernível em certas ações ou situações. 2) um modelo ou design usado como um guia em bordado ou outras atividades artesanais.

Standard – 1) um nível de qualidade ou realização. Um nível requerido ou concordado de qualidade ou realização. 2) uma ideia ou coisa usada como medida, norma, ou modelo em avaliações comparativas. Princípios de conduta informado por noções de honra e decência. Uma forma de linguagem que é amplamente reconhecida como a forma correta.

Resumindo:

Default – uma escolha pré-selecionada quando nenhuma outra é selecionada.

Pattern – um modelo que pode ser observado como recorrente, sem valor de certo ou errado.

Standard – uma norma, algo que todos concordam como base de comparação ou requerimentos mínimos a serem seguidos.

O problema é que a palavra “padrão”, em português, é usada muito mais com o sentido de “standard”. E muitas vezes o que estamos traduzindo é a palavra “pattern”.

Ou seja, quando alguém fala “Design Pattern”, diz apenas que existe uma “forma” usada com mais frequência do que outras na resolução de problemas de software. Ela não é necessariamente a mais correta, e não existe afirmação de que seja a forma conclusiva. É só a observação de que ela é frequente, regularmente usada. A imagem a seguir mostra padrões no sentido de “patterns” (“mais patterns”):

Mas ao traduzir para “Padrões de Design”, entra o sentido português de “padrão” como a forma mais correta, ou minimamente correta, e que por ser uma “norma” deveria ser seguida. A palavra “padrão” soa como em “obrigação de seguir o padrão Portaria nº 288/2005”, ou seja, “obrigação de seguir a norma ou regulamento Portaria nº 288/2005”.

Aí “Design Patterns” ganha conotação de norma ou regulamento, que é exatamente o sentido errado. Pattern é Pattern, Standard é Standard, são coisas completamente diferentes.

E é aí que mora o problema de entendimento entre muita gente. Quem entendeu Design Patterns no sentido de “Pattern” reclama de quem entendeu no sentido de “Standard”. Os dois traduzem como “padrão”, e a discussão entre essas duas pessoas acaba parecendo conversa de louco: “Mas isso é só um padrão (pattern), não precisa ser seguido obrigatoriamente.” – “Não! Isso é um padrão (standard), por isso precisa ser seguido obrigatoriamente!”

Observação: notei que algumas pessoas não gostaram muito do título, mas coloquei assim de propósito, para chamar atenção ao assunto. Não estou afirmando que a língua portuguesa é essencialmente ruim e que outras são melhores. Toda língua tem nuances e diferenças que dependem do contexto, da cultura local, dos coloquialismos, dos neologismos, da moda e assim por diante.

Justamente por isso temos que ficar sempre atentos, para não entender as coisas ao pé da letra e aplicá-las sem pensar, partindo de premissas falsas.

Se você faz palestras, isso aqui pode ajudar bastante.

Monitores e Projetores

A primeira coisa: Macs não têm aquela tecla de função (tipo fn + F4) dos notebooks PC. Basta conectar o adaptador VGA/DVI e o OS X detecta o segundo monitor automaticamente, já configurando tudo.

Esse segundo monitor funciona de duas formas: independente, com resolução própria, ou em espelho (“mirror”), repetindo o que está no monitor principal. O modo independente é melhor para slides. O espelho é melhor para demonstrações ao vivo.

Ele também pode ser tela primária ou secundária. A diferença é qual delas fica com a barra do topo do Mac. Tudo isso se configura em “System Preferences” ➔ “Displays” ➔ “Arrangement”.

Na imagem acima, o modo espelho está habilitado. Clique em “Mirror Displays” para desligar. Se aparecerem duas telas independentes, você troca o monitor primário arrastando a barra branca do topo de uma para a outra. É essa barra que define o primário.

Tem também o “Gather Windows”. Com um segundo monitor, o Mac abre uma janela de preferências para cada tela, para você ajustar resolução e cor de forma separada. Às vezes essa segunda janela fica inalcançável; clicando nesse botão, as duas voltam para o mesmo monitor.

Quando os monitores não estão espelhados, dá para controlar a resolução de cada um separadamente. O ideal costuma ser manter o primário no notebook e o secundário no monitor externo. E vale lembrar: a maioria desses projetores baratos de mercado suporta só até 1024×768.

Agora um truque. Esses projetores em geral vêm preparados para PC, e o perfil de cor do PC e do Mac pode ser diferente. Um efeito comum é o Mac aparecer mais escuro e com menos contraste, o que atrapalha na hora de ler texto em fundo escuro. Para corrigir, mexa no Color Profile.

Na mesma janela, ao lado de “Arrangement”, tem a aba “Color”. Desmarque “Show profiles for this display only” e procure o perfil “sRGB IEC61966-2.1”. Ele costuma clarear as cores da projeção e deixar tudo mais legível. Se não resolver, teste outros perfis.

Perfil de cor não é assunto trivial. Até o Mac OS X 10.5 Leopard, a correção Gamma era 1.8; a partir do 10.6 Snow Leopard passou a ser 2.2, igual ao Windows.

Fora isso, imagens bem feitas costumam trazer o próprio perfil de cor, e o Mac sabe transicionar de um perfil para outro corretamente. Esse artigo de suporte da Apple explica melhor.

Por fim, os técnicos costumam alinhar a projeção usando um PC. Isso é péssimo. Peça para alinharem com um Mac. Faz diferença: mal calibrado, parte do seu slide acaba saindo para fora da tela.

Apple Keynote

Muita gente usa Mac justamente por causa do Keynote, do Apple iWork. Para mim é de longe o melhor software para montar apresentações de qualidade, deixando no chinelo qualquer PowerPoint da vida.

Uma das melhores funcionalidades é o “Presenter Display”, uma tela que só o apresentador vê: as anotações do slide atual, o próximo slide, o tempo já decorrido. É informação fundamental para calibrar o ritmo em tempo real. Dá para configurar os elementos dessa tela em “Preferences”, nesta aba:

Eu particularmente gosto de usar esta configuração:

Sempre teste o notebook antes de subir ao palco. Ao tocar o Keynote (Command + Option + P), veja se o “Presenter Display” está saindo no seu notebook ou no projetor. Dá para inverter onde ele aparece na última opção dessa tela de “Preferences”.

Sobre os slides, alguns lembretes:

• use cores de bom contraste entre frente e fundo: fundo branco com letra preta, ou fundo bem escuro com letra bem clara. Fugir disso, usando a mesma cor em tonalidades parecidas para fundo e letra, é garantia de slide ilegível no projetor.

• para mostrar código, use corpo grande. Numa apresentação montada em 800×600 (é o tamanho que sempre prefiro), a fonte mínima é 21, idealmente 24. Use monoespaçadas como a clássica Monaco ou a atual Menlo. Fuja das monoespaçadas serifadas, como o horrível Courier New, e das de corpo muito fino, como o Consolas.

• use o bundle Copy as RTF. Ele copia o código do TextMate junto com as cores do tema escolhido; daí é só colar no Keynote e ajustar o tamanho. No TextMate, o tema mais legível no projetor é o Mac Classic (fundo branco, letra preta). Um dos piores é o famoso Vibrant Ink (fundo preto, letra clara).

• deixe margens largas em todas as direções e não encoste nada importante nos cantos, código principalmente. E não use screenshot do TextMate como slide de código. O Keynote é independente de resolução, mas imagem bitmap não é, e se comporta mal conforme a resolução muda. Use fontes de verdade.

• código ou não, qualquer fonte menor que 21 fica ilegível a distância. Se você precisou diminuir mais que isso, o slide já está ruim, com texto demais ou texto irrelevante. Repense o slide. O ideal é poucas palavras em tamanho 72, 96 ou até 144, como faço em muitos dos meus.

• muita gente configura o Keynote para editar em 1024×768, mas acho desnecessário: edito tudo em 800×600. Como já falei, o Keynote é independente de resolução. Na configuração abaixo, a primeira opção manda escalar o slide para caber na tela inteira. Assim fica mais confortável editar em 800×600 mesmo no monitor do meu MacBook Pro.

Controle Remoto

Se você pretende palestrar com frequência, um bom controle remoto é essencial. São baratos e dão mobilidade, e ficar parado atrás do notebook nunca é bom. Em alguns lugares, pela disposição dos equipamentos, o notebook acaba longe do palco, fora do alcance para eu controlar na mão.

Alguns Macs vieram com o Apple Remote, o antigo branco e o atual de alumínio. São bonitos, mas na minha opinião uma grande porcaria, um dos piores acessórios da linha, junto com os antigos Mighty Mouse.

O motivo é o infravermelho: o controle só funciona apontado direto para o receptor do MacBook. Se tiver qualquer coisa na frente, ou se o notebook estiver de costas para você, ele não responde.

O mercado tem várias opções sem fio. Alguns usam Bluetooth, e desses eu fujo. Minha experiência foi instável, e ainda por cima eles não são fáceis de configurar.

Os melhores têm o próprio conector USB e, ao ligar no Mac, se comportam como um teclado (o Mac acha que é teclado mesmo). Estou usando um da Targus no momento e não gosto dele. De longe o melhor que já usei, e o que recomendo, é o Kensington 33374 Wireless Presenter with Laser Pointer.

Não seja mão-de-vaca com esse tipo de aparelho. Por causa de meros US$ 10 ou US$ 20, você fica com um controle bem pior, que vai te deixar na mão justamente no palco. Um sintoma de controle ruim é apertar o botão e pular dois slides de uma vez. É péssimo, e eu já passei por isso.

Extras

Outra coisa importante: não use o app de controle remoto do Keynote para iPhone, que comanda o Mac via Wi-Fi. Wi-Fi de evento é sempre ruim e você não pode depender dele. Aliás, recomendo desligar Bluetooth e Wi-Fi do Mac antes de começar.

Já tive dois problemas assim. Num deles, não tenho certeza, mas acho que alguém estava tentando controlar meu Mac com algum aparelho remoto, talvez um Apple Remote infravermelho ou algo via Bluetooth. Por isso recomendo desativar o infravermelho também, em “System Preferences” ➔ “Security”.

A opção é “Display remote control infrared receiver”. E a razão de desligar o Wi-Fi: no meio de uma palestra sofri uma colisão de IP, e o Keynote saiu do meu slide para exibir um aviso do sistema dizendo que alguém estava com o mesmo IP que o meu. Vergonhoso.

Outra: ligue o notebook na tomada e não apresente na bateria, mesmo cheia. O segundo monitor puxa bateria rápido, e em alguns casos nem liga fora da tomada.

Por fim, nunca, jamais, dependa da internet do local do evento. Como falei, isso é utopia. Se você tem demonstração ao vivo, cuidado. Grave sempre um screencast com ferramentas como o excelente ScreenFlow ou o próprio QuickTime X, que já grava a tela do Mac; veja como neste tutorial da MacMost.

E quando for gravar, nunca use a resolução cheia do notebook. Parece óbvio, mas a maioria dos iniciantes grava em 1440×900 e depois encolhe tudo para caber num slide de 1024×768. Pior ainda: abrindo o Terminal com fonte tamanho miserável 11.

As regras dos slides valem para os screencasts. Configure o terminal com fundo branco, letra preta e corpo 18 ou maior. Veja meu iTerm, já ajustado para as apresentações:

Uso o iTerm porque deixo ele pronto para apresentar, mas no dia a dia fico no Terminal comum, que está configurado de outro jeito. Existem várias técnicas para gravar um bom screencast que não vou detalhar aqui, mas isso já dá para começar.

A vantagem do screencast é a garantia: mesmo que você mexa na máquina depois (atualize o Java, o Ruby, desinstale o MySQL), a demonstração funciona 100% das vezes. E o melhor: quando você narra por cima da gravação, muita gente nem percebe que é gravado.

A última dica é sobre som, um problema que já me pegou três vezes. Se você vai mostrar vídeo ou áudio em estéreo, teste antes de apresentar.

Nas três vezes o culpado foi provavelmente cabo podre ou má configuração (ou má vontade do técnico), e só um dos canais saía. Numa delas, perdi justamente o canal com a voz. Um truque é configurar o som do Mac para sair tudo em mono, ou tudo à esquerda, ou tudo à direita:

Em “System Preferences” ➔ “Sound” ➔ “Output”, selecione a saída certa e teste jogar tudo para um lado só.

No fim, o que mais importa é a qualidade do conteúdo e a sua capacidade como orador: carisma, linguagem corporal, empatia com a plateia. A parte técnica só garante que um slide mal feito não estrague uma boa apresentação.

Veja esta lista de acidentes fatais da aviação civil:

1. Jetstream into Hibbing, MN, (NTSB, 1994a);
2. DC-8 into Jeddah, Saudi Arabia (NTSB, 1993a);
3. C99 into Anniston, AL, (NTSB, 1993b);
4. Beechjet into Rome, GA, (NTSB, 1992a);
5. DC-8 loss of control at Toledo, OH, (NTSB, 1992b);
6. 707 fuel exhaustion into JFK, Washington DC, (NTSB, 1991);
7. L-1011 windshear accident, D/FW Airport, TX, (NTSB, 1986);
8. MS-748 electrical failure in Pinckneyville, IL (NTSB, 1985);
9. 737 out of Washington National, Washington DC, (NTSB, 1982);
10. DC-8 fuel exhaustion in Portland, OR, (NTSB, 1979);
11. 727 into Dulles New York City, NY, (NTSB, 1975);
12. DC-8 freighter into Cold Bay, AK, (NTSB, 1974);
13. Convair into New Haven, CT, (NTSB, 1972);
14. L-188 into a thunderstorm at Dawson, TX, (NTSB, 1969);
15. Lear Jet out of Palm Springs, CA, (NTSB, 1967);
16. F-27 into Las Vegas, NV, (CAB, 1965).

Cada um desses acidentes é um exemplo de subordinados que sabiam que o Capitão estava ignorando sérios riscos e demonstrando comportamento contra-produtivo e não razoável. Esses subordinados todos sabiam que seus respectivos capitães estavam negando, descontando ou ignorantes aos perigos letais. Infelizmente, nenhum deles foi capaz de fazer qualquer coisa para mudar a performance, ações ou estratégias do Capitão; a maioria não conseguiu sequer fazer o Capitão se tocar do problema.

Talvez isso não faça sentido de imediato, então vamos por partes. No mundo da aviação a hierarquia é rígida: o Piloto/Capitão é a autoridade máxima, e o co-piloto e o resto da tripulação jamais devem discordar dele. Esse é o “Catch-22” dos co-pilotos, o dilema:

• Você está ferrado se ignorar os erros do Capitão!
• Você está ferrado se fizer ou disser qualquer coisa sobre isso!

O corolário disso, é uma regra não escrita que todos sabem:

1. O Capitão está sempre certo.
2. SE, o Capitão algum dia for observado cometendo um erro, veja a Regra 1

Como em qualquer organização, esse tipo de hierarquia sempre leva a um código de ética que não está escrito em nenhum lugar, mas todo co-piloto sabe muito bem. No caso, como o Código de Ética da Águia Verde:

• Não durma enquanto seu Capitão estiver dormindo
• Encoraje seu Capitão a fumar
• É um inferno voar com um Capitão nervoso, especialmente se for você que o estiver deixando nervoso!
• Não interfira se seu Capitão absolutamente insiste em fazer papel de idiota.

Regras de Sobrevivência:

• Não voe com um Capitão apelidado de “Sortudo”;
• Não voe à noite;
• Não voe sob tempo ruim;
• Não se meta com os botões vermelhos;
• Nunca, jamais coma comida de avião no escuro;
• Mantenha sua péssima atitude em segredo;
• Fale muito, muito levemente quando falar com seu Capitão;
• Não faça aterrissagens melhor do que seu Capitão até a última viagem do mês.

Não estou brincando. A análise das caixas-pretas de aviões acidentados nas últimas décadas mostrou que os capitães, sob stress, cansados ou irritados, às vezes acabam ignorando situações de perigo. Os co-pilotos percebiam o risco e não faziam ideia de como abordar o assunto, com medo de retaliação caso estivessem errados. Por alguma razão, nem o pior dos cenários, cair para a morte, conseguia quebrar a barreira da hierarquia.

Por causa disso, pesquisadores como o Dr. Robert O. Besco criaram modelos de procedimento para o Cockpit Resource Management (CRM), a gestão das pessoas dentro da aeronave. Um deles foi o P.A.C.E.:

• (P)robing
• (A)lerting
• (C)hallenging
• (E)mergency Warning

PROBING

“Capitão, preciso entender porque estamos voando desta maneira.”

É a fase em que o co-piloto, ao perceber um perigo em potencial, precisa confirmar se o piloto sabe o que está fazendo. Às vezes é uma manobra calculada, sob total controle, e não custa checar. A tradução mais direta seria:

“Capitão, você por acaso não está se colocando num canto e mirando para atirar no próprio pé?”

ALERTING

“Capitão, parece para mim que estamos num curso que está drasticamente reduzindo nossas margens de segurança.”

Se o capitão não deu uma resposta satisfatória no PROBING, é hora de alertá-lo sobre os perigos iminentes. Mais diretamente:

“Capitão, é minha função e responsabilidade proteger seus pontos cegos. Eu vejo que você está quase caindo no abismo.”

CHALLENGING

“Capitão, você está colocando os passageiros e a aeronave em perigo imediato e irreversível. Você deve escolher imediatamente um curso de ação que irá reduzir nossos níveis inaceitáveis de alto risco.”

Você já tentou entender, já tentou avisar, agora é hora de desafiá-lo e confrontá-lo com a realidade. Nesta penúltima etapa, o co-piloto ainda dá ao capitão a chance de cair em si e fazer a coisa certa.

“Capitão você está prestes a se auto-destruir. Você tem literalmente uma arma apontada nas suas 6 horas. Estamos para receber o equivalente em aviação civil de um enema de 20 milímetros.”

EMERGENCY WARNING

“Capitão, se você não aumentar nossas margens de segurança imediatamente, é meu dever e responsabilidade e tomar o controle da aeronave imediatamente.”

Chegamos ao ponto em que o capitão ignora a realidade por completo, ou está incapacitado de tomar qualquer decisão. São os últimos 30 segundos antes do ponto de não retorno. Em bom português:

“Capitão, estamos prestes a virar presuntos. Eu escolho não me juntar a você. Se você não soltar o controle agora, eu vou tomar esta aeronave de você.”

Passo de Sobrevivência do PACE: INTERVENÇÃO E TOMADA DO CONTROLE

Co-Piloto: “Capitão, eu devo tomar o controle da aeronave!!”

Se no próximo segundo nada acontecer, é hora de sair das formalidades, e chamá-lo pelo primeiro nome ou apelido.

Co-Piloto: “Jerry, tire as mãos do controle, AGORA!!” (grito, lento, com autoridade firme!)

Um terceiro membro da tripulação, se presente, pode usar terminologia como:

Co-Piloto 2: “Capitão, você deve dar o controle da aeronave ao Barry imediatamente!”

Quando o co-piloto já está pilotando a aeronave, os passos de intervenção do PACE devem ser usados pelo co-piloto para anunciar a intenção de implementar uma estratégia não iniciada pelo Capitão. Embora o co-piloto tenha o controle da aeronave, o Capitão ainda tem a responsabilidade de comando para o plano de voo básico e controle da missão. Esses mesmos quatro passos de progressão para estratégia de intervenção devem ser seguidos pelo co-piloto em voo para formalizar a mudança em comando e retornar a aeronave às margens de segurança planejadas anteriormente.

Conclusão

Substitua “Capitão” por “Gerente” e “Co-Piloto” por “membro de uma equipe de projeto” e você entende na hora onde quero chegar.

Os sistemas hierárquicos arcaicos que usamos até hoje partem do princípio de que os tais “gerentes” são onipotentes, onipresentes e têm poder absoluto. A diretoria e o RH vivem a ilusão de que o gerente conhece cada membro da equipe, sabe como cada um se desenvolve, como se comporta e o que deseja.

A equipe, do outro lado, vive a ilusão de que o gerente sabe o que precisa ser feito e quais são as prioridades. E o gerente acaba acreditando mesmo que dá conta de liderar o time, entregar os resultados que a diretoria cobra e que todos confiam nele.

Ou pior: o gerente é do tipo coercivo, que usa medo, intimidação e “carteirada” para mandar e desmandar. “Você trabalha para mim, cale a boca e faça o que estou mandando!” Ninguém costuma dizer com essas palavras, mas é o que acontece, principalmente a portas fechadas. Seu gerente é assim? Prepare-se, seu avião está prestes a cair.

Diria que 99% dos gerentes de hoje são os capitães que vão levar o avião ao fundo do Triângulo das Bermudas. As primeiras pessoas que precisam evitar isso são a própria Equipe.

Sim, você, membro acomodado e conformado de uma equipe de produtos ou projetos. Você é o co-piloto nessa história. Quando o projeto falha, não jogue a culpa só no gerente: a culpa é sua também. Se isso fosse um avião, você estaria igualmente morto, virado presunto. Faça a sua parte.

Os quatro passos do PACE servem para qualquer equipe adotar. Não se trata de caos ou insubordinação. Você precisa prestar atenção cedo para ter tempo de aplicar os quatro passos:

• (P) Quando nota algo estranho se desenrolando, peça esclarecimentos
• (A) Se a explicação não for convincente, tente avisar dos riscos que você já viu
• (C) Se nenhuma ação for tomada, exija que algo seja feito
• (E) Se nada for feito, é hora de avisar que vai tomar o controle!

A sorte é que em projetos e produtos, principalmente na nossa área de software, não existe risco de morte, literalmente falando. Mas pense em cada projeto fracassado como um pedaço de você que morre. Um profissional que só acumula fracassos na carreira é, por definição, um fracassado.

Última coisa: você trabalha no RH? Pense em tudo isso como um treinamento para os novos contratados, um protocolo que dá ao subordinado um caminho “oficial” para agir e evitar a morte prematura da própria carreira. Hoje o único caminho que existe é o da autoridade de cima para baixo. A maioria dos subordinados tem medo de retaliação do gerente. Já passou da hora de criar uma válvula de escape de baixo para cima, que o gerente saiba que existe.

Obs: alguns dias atrás eu escrevi um desabafo sobre o comportamento ruim de um gerente de projetos. Nesta tradução, o foco são as soluções e os cenários corretos. Vamos a ela:

Em 2004, a revista ‘Software Development Magazine’ entrevistou Gerald Weinberg. Aqui vão algumas de suas respostas (a entrevista completa está no site dele):

Qual foi o conselho de gestão mais importante que já lhe deram?

Se você culpa seus funcionários, você é um péssimo gerente. Você os contratou, os aceitou, os supervisionou, e dirigiu seu treinamento. Você é responsável. Se você não gosta do que está acontecendo, veja seu próprio comportamento. Mas, se há crédito a ser dado, é deles.

E sobre gerentes que foram contratados em um grupo onde alguns ou todos os funcionários já foram contratados por outra pessoa?

Você não assume um trabalho de gerência de forma passiva. Antes de aceitar a posição, você entrevista todos em seu grupo, e você consegue o apoio deles, ou se livra deles – ou não aceita a posição. Eu não sei porque gerentes não entendem isso. Eles assumem novas responsabilidades como colegiais em seu primeiro encontro às cegas.

E se um funcionário começa a demonstrar mal comportamento depois que ele ou ela o contratou – comportamento que não era aparente na fase de entrevista?

Bem, isso acontece, e é para isso que gerentes são pagos. Pode ser um retrocesso, mas é seu trabalho cuidar disso e terminar o serviço. Infelizmente, poucos gerentes técnicos têm qualquer preparação para isso, é uma coisa que venho tentando remediar por anos – então, por um lado, eu sou culpado, porque fui bem sucedido apenas em alguns casos. Ei, se tudo desse certo o tempo todo, você não precisaria de gerentes.

O que é atribuir a Culpa?

Obs: Leia o artigo completo Beyond Blaming no site oficial do Jerry.

Em uma organização congruente, seu gerente pergunta, “Como anda seu projeto?” e sua resposta, “Estou um pouco receoso que vou atrasar no cronograma.” Isso inicia uma discussão para resolver o problema, de onde vocês dois fazem novos planos para colocar o projeto de volta em dia. Em uma organização de culpa, entretanto, seu gerente pode lhe dizer que somente pessoas inferiores tem pouca confiança. Nesse caso, resolução de problema será substituída por evitar-a-culpa.

Do ponto de vista de um escritor, interações congruentes não são muito dramáticas; as pessoas apenas agem sensivelmente, tem consideração uns pelos outros, terminam seus trabalhos, e se divertem com o que fazem. Esse tipo de comportamento pode não dar uma boa cena de novela, do que seu gerente gritando em ira e você se encolhendo num canto, mas definitivamente resulta em projetos melhores.

Não que uma cultura de atribuir a culpa conduza toda interação de forma culposa, dramática. Sob circunstâncias ordinárias, resoluções congruentes são a regra, mas se as circunstâncias fossem sempre ordinárias, não precisaríamos de gerentes. Quando sentimentos de auto-estima estão em baixa, elas se manifestam de maneira mais dramática em resoluções incongruentes características: atribuir culpa, apaziguamento, ser super-razoável, amável ou odioso e agir de forma irrelevante. Não podemos lidar com tudo isso num artigo curto, então vamos discutir ‘atribuir a culpa’, talvez a forma mais comum e mais diretamente destrutível de estilo de resolução.

Sob estresse as pessoas tendem a perder o equilíbrio, e um ou mais de três componentes essenciais podem ser ignorados, levando ao característico estilo de resolução incongruente. Por exemplo, quando as pessoas falham em levar outras pessoas em consideração, eles caem em uma postura de jogar a culpa nos outros. Aqui vai uma típica ação de atribuir culpa que você vê em organizações de software (palavras em itálico são enfatizadas nesse estilo de falar – porque múltiplas palavras enfatizadas em uma sentença linguística são sinais de jogar a culpa):

Gerente, quando o programador chega atrasado para uma reunião: “Você está sempre atrasado. Você nunca demonstra qualquer consideração pelas outras pessoas.”

Por que isso é incongruente? Se o gerente realmente está sentindo e pensando que o programador está sempre atrasado e não tem consideração, ele não está sendo congruente ao dizer isso? Sim, mas não é isso que esse gerente disse. Ele não disse, “é minha impressão que você está sempre atrasado para minhas reuniões.” Em vez disso, ele pronunciou sua impressão de atraso como se fosse um fato científico, nunca oferecendo a possibilidade do programador poder ter uma impressão diferente. Ele generalizou a experiência da sua reunião como se isso necessariamente se aplicasse a todas as reuniões, nunca permitindo a possibilidade de sua experiência não ser a única que conta.

Se o gerente realmente está sentindo e pensando que o programador está sempre atrasado e não tem consideração, ele deveria dizer, “eu acho que você está sempre atrasado, e eu acho que você não está tendo consideração comigo e com os outros. Essa é sua percepção também?” (e deixando de lado as palavras estressadas). Estilo de gerenciamento ainda melhor seria dar ao programador a chance de dar uma percepção diferente antes de lançar qualquer interpretação. No mínimo, isso evita embaraços em situações como a seguinte:

Gerente, quando o programador chega atrasado para uma reunião: “Parece para mim que você está sempre atrasado. Essa é sua percepção também?” Programador: “Sim, e eu me sinto mal sobre isso. A razão de eu estar sempre atrasado é que eu tenho que doar sangue para meu filho de 9 anos, que está morrendo de leucemia, e a única hora para doações é bem antes desta reunião.” Gerente: “sinto muito sobre seu filho. Não sabia disso. Vamos marcar a reunião para outro horário para que você não precise se atrasar.”

De forma geral, isso permite a possibilidade de que possa existir outras considerações que contem além daquelas desse único gerente. Por exemplo, talvez o programador está chegando de uma reunião com clientes – uma reunião que por acaso cruza horários com a reunião do gerente.

Mas e se o programador realmente está sempre atrasado, sem uma explicação razoável? O gerente não está no seu direito de culpar o programador? Na realidade não , porque essa situação não é sobre “se tem direito”, mas sim sobre ter o projeto finalizado. Para esse propósito, o problema é resolvido de forma mais efetiva confrontando sem jogar a culpa; com fatos sobre o comportamento inaceitável. Pulando a atribuição de culpa, o gerente mantém a comunicação clara e aberta, maximizando a chance do programador receber a mensagem intencionada. E, claro, receber a mensagem intencionada maximiza a chance (embora não garanta) que o problema irá se resolver.

Quando se atribui culpa, a resolução do problema tem menor chance de acontecer porque os fatos do caso se tornaram um fator minoritário – o maior fator na atribuição de culpa é “quem é importante e quem é insignificante.” Quando se atribui culpa, a pessoa está dizendo, “Eu sou tudo, você não é nada.” Claro, isso não vem de realmente pensar “Eu sou tudo,” mas do oposto. Dirigir a atenção para outra pessoa – e jogar a culpa é normalmente acompanhado de apontamento de dedo – é um dispositivo de auto-proteção para distrair os outros do desconforto que o inquisidor sente.

Como toda resolução incongruente, atribuir culpa é reforçado por sentimentos de baixa auto-estima. Quando você culpa, você tenta se colocar no alto através de puxar o tapete dos outros, porque você não tem a segurança de que pode aguentar muito – ou mesmo sobreviver – de qualquer outra forma.

Jogar a culpa nos outros engana as pessoas pouco sofisticadas, ou cuja própria auto-estima seja bem baixa. O observador inteligente, entretanto, enxerga a quantidade de atribuições de culpa como uma medida segura de quão inadequado o inquisidor se sente. Mais do que isso, se jogar a culpa nos outros é o estilo de comunicação de projeto preferido, então se torna uma medida de quanto um ambiente se degradou – quão pouca comunicação é dirigida a assuntos de projeto, comparado à quantidade que é dirigida diretamente a estufar a baixa auto-estima do comunicador.

Em uma organização onde se joga culpas, não é somente o gerente que faz isso, como ilustrado por estes exemplos:

Programador, quando o gerente pede para falar com um candidato ao trabalho: “Por que você não faz isso você mesmo? Não vou fazer seu trabalho por você. Se fosse mais organizado, não precisaria me pedir essas coisas.”
Cliente, quando o gerente de projeto pergunta sobre a possibilidade de rever os requerimentos: “Você nunca acerta nos requerimentos da primeira vez. Se eu digo uma vez, já disse mil vezes. Faça o trabalho certo da primeira vez, daí não vai precisar me perturbar com revisões.”

Como Jogar a Culpa Machuca um Projeto

Claro, pessoas não são perfeitas, então é impossível conduzir um projeto grande sem ocasiões onde as pessoas são incongruentes. Gerenciamento normal de projetos pode lidar com essas situações – quando elas são excepcionais. Mas quando todo o ambiente encoraja jogar a culpa, cada nova situação complica ainda mais a incongruência. Fred Brooks uma vez perguntou, “Como um projeto de um ano acaba ficando dois anos atrasado?” Sua resposta foi “um dia de cada vez.” Nossa resposta é “uma comunicaçao incongruente de cada vez,” como o exemplo seguinte ilustra:

Um dos programadores estava desenvolvendo um módulo que produzia relatórios impressos quando era testado. O gerente colocou muita pressão no programador para que ficasse pronto no prazo, sem desculpas permitidas. O programador produziu um relatório e o gerente estava contente (embora ele tivesse demonstrado isso, claro – era “somente uma parte esperada do trabalho” na cultura de jogar a culpa). Um mês depois, outra pessoa tentou usar esse módulo e descobriu que ele não havia sido finalizado de jeito nenhum. O programador usou um Word para produzir um relatório falso que se parecia exatamente como um relatório de teste deveria se parecer. Ele pensou que isso lhe daria mais tempo (levou um mês, afinal de contas, até alguém descobrir) para finalizar o módulo. Infelizmente, como era muito trabalho, um mês não fora o suficiente.

O gerente culpou o programador. O programador não disse nada, porque nessa cultura de jogar a culpa, dizer alguma coisa só trás mais acusações na cabeça. A pessoa que reportou o incidente disse que nessa organização, falha não é permitida sob nenhuma circunstância. Pessoas que tem problemas em um projeto e conseguem prever atrasos não conseguem gritar por AJUDA! e receber assistência apropriada. De acordo com os gerentes, cada programador é responsável por atingir os prazos que concordaram. Estimativas inexatas “não eram permitidas” e perfeição deve ser atingida no primeiro dia – caso contrário você é colocado no pilar da culpa. Nessa situação, relatórios falsos são a regra, não a exceção ( nota do Akita: para ser mais claro, substitua ‘relatório falso’ por qualquer dessas ‘gambiarras’ que vemos comumente em código.)

Jogar a culpa é o segredo negro do fracasso de muitos projetos. Uma cultura de jogar a culpa machuca um projeto de pelo menos seis grandes maneiras:

1. As pessoas se comprometem com planos que sabem que não conseguem atingir, pelo menos para atrasar o recebimento da culpa. ( nota do Akita: já ouviu aquele programador que parece sempre “tenho muita coisa pra fazer, por isso não posso nem fazer direito, nem ajudar os outros” – o paradoxo: como pode “ter muita coisa” se foi ele mesmo quem concordou, em todas as vezes, com o que fazer?)
2. As pessoas escondem fatos que os gerentes precisam para controlar o projeto, como no exemplo acima. ( nota do Akita: lembrem-se, “não ter problemas, é um problema” – significa que estão sob o tapete.)
3. Quando os problemas são finalmente revelados, as pessoas evitam sair com idéias de soluções criativas, por medo de levarem a culpa caso não funcione, ou simplesmente se fazem de joão-sem-braço.
4. Em operações de rotina, uma grande parcela dos esforços de cada um é devotado em se posicionar para não levar a culpa quando a hora chegar. ( nota do Akita: exemplo, “a culpa é da outra equipe, a responsabilidade não é minha, ou só minha.”)
5. As pessoas que porventura se sentem seguras o suficiente para se focar no trabalho, se vêem gastando bastante tempo checando a confiabilidade na comunicação com os outros.
6. As pessoas se sentem mal a maior parte do tempo, e gastam muito tempo em tarefas improdutivas ou simplesmente olhando para as paredes.

A Aparência e Sentimento da Incongruência

Organizações podem mudar de uma cultura de jogar a culpa para uma cultura de congruência. Para fazer essa mudança, o primeiro passo é medir, ou pelo menos detectar – mas como medir atribuição de culpa? Na realidade, um consultor experiente consegue detectar uma organização de atribuição de culpa com poucos minutos de contato, porque os sintomas estão por todos os lados. De fato, as pessoas da organização já sabem que é uma cultura de jogar a culpa – mas, claro, numa cultura dessas, jogar a culpa é indiscutível e, mais ainda, a indiscutibilidade também é indiscutível. Paradoxalmente, a existência da indiscutibilidade torna mais fácil detectar a atribuição de culpa. O gerente de um projeto manda um e-mail dizendo que não haveria mais discussão sobre a moral do projeto, e que ele não prestaria mais atenção a questões do assunto porque todos deveriam estar gratos por estar trabalhando num projeto tão legal. Esse tipo de coisa só poderia acontecer numa organização onde se joga a culpa.

Executivos

Uma cultura de jogar a culpa começa no topo. Membros do nível superior de gerenciamento têm costume de enxergar as outras pessoas da organização como fontes de problemas. Os funcionários são vistos como “ingratos” por seus trabalhos, salários, benefícios e oportunidades dadas a eles. São vistos como tendo “falta de ética apropriada de trabalho”, “não saber dar valor”, “ter problemas de autoridade” e “resistir a mudanças”. Essas percepções deixam a alta gerência num dilema: “será que eu as demito, ou demito quem as contratou?”

Esse tipo de gerente sente que está tentando realizar uma visão sem ter o suporte necessário, o que os deixa no limbo. A experiência interna de inércia desses executivos é normalmente uma dor de cabeça contínua e crônica – a menos que as margens de lucro estejam muito baixas. Nesse caso, eles têm sentimentos mais apurados, como dor no peito e queimação no estômago. Suas baixas auto-estimas se refletem adiante na forma de frequentes downsizings, re-engenharias ( nota do Akita: aqueles que em vez de encarar os problemas, ficam achando mais uma “metodologia” da moda para implementar, achando que isso resolve alguma coisa), evitar problemas mais sérios, e-mails fúteis e, claro, humilhar subordinados ( nota do Akita: aqueles que largaram seu sub-gerente trabalhando, achando que estavam fazendo direito, e só recebem feedback negativo meses depois, quando é conveniente – que é um tipo de humilhação). A si mesmos, eles normalmente praticam comportamentos viciados e auto-destrutivos (que não podem ser discutidos, mas costumam ser assunto de fofocas.)

Gerência do Meio

Enquanto a alta liderança é incongruente, os gerentes do meio constantemente recebem mensagens misturadas. Cantarolam aos gerentes de projetos de sua importância e, então descobrem que seus sêniores os “bypassaram” (passaram sobre eles) para intervir diretamente em projetos ou mudaram as regras sem os consultar. Eles se sentem como se estivessem vivendo numa montanha-russa – sem conseguir prever se um determinado dia ou semana será bom ou ruim. Depois de serem publicamente humilhados algumas vezes, eles decidem que sua melhor estratégia é tentar ficar longe de problemas, sem chamar a atenção ( nota do Akita: aqui começa a rotina do batedor-de-cartão conformado).

Em uma organização de atribuição de culpa, a alta gerência tenta (talvez de forma inconsciente) ensinar os gerentes do meio suas próprias atitudes de jogar a culpa. Quando um gerente de projetos reclamou da sua inabilidade de fazer os programadores trabalharem mais rápido, o Vice-Presidente de Desenvolvimento disse, “se seus cachorros não vão pular mais alto, encontre uma vara mais longa para bater neles.” Vivendo num inferno de incongruência vindo de cima, aparecem os problemas de sobrevivência da gerência do meio. Como faziam quando eram crianças, eles descobrem como acalmar, agradar ou evitar os donos do poder. Ao fazer isso eles asseguram sua sobrevivência – e passam a culpa para níveis mais baixos.

Funcionários

Na parte de baixo de uma organização de atribuição de culpa, os funcionários normalmente estão procurando por outro lugar para trabalhar a menos que a empresa esteja em uma condição estável e com pouca competição – ou se suas aposentadorias estão próximas. A maneira para sobreviver é se esconder e aparecer somente para pegar o contra-cheque ( nota do Akita: e em épocas de depósitos automáticos, nem isso.)

Funcionários são desencorajados de pensar criativamente – novas idéias são interpretadas como jogar a culpa na gerência ou tentar usurpar seus poderes e prerrogativas. Funcionários não são recompensados por competência – mas são frequentemente punidos por “descuido” percebido. Funcionários não procuram seus gerentes – exceto quando há problemas. Então, a maior parte do esforço é gasto em tentar dar nome aos bois em vez de resolver o problema.

O estilo de jogar a culpa varia de organização para organização. Pode ser de forma dura, vingativa, direta ou indireta – mas é sempre contagiosa. Algumas organizações refinaram sua maneira de jogar a culpa a um alto grau de sutileza – sem gritos, meramente lançando um olhar, ou um e-mail, ou um telefonema, ou uma visitinha se as coisas são realmente ruins. Em outras organizações, a atribuição de culpa é na gritaria, raivosa e frequentemente feita na frente de uma platéia – para assegurar que todos entenderam a mensagem de quem está certo, quem é o “bonzão”, quem está no comando, e quem deve ficar invisível.

Nesse tipo de ambiente, se defender se torna comum. Para aqueles sem poder formal ou autoridade, parece que aqueles com poder não se importam com eles – e os baniriam sem nenhum remorso. Então eles se sentem no direito de retaliar (adiantado, e em segredo), e em evitar seus gerentes e seus problemas.

Independente do estilo, jogar a culpa do topo sempre gera medo, desconforto, erros, acidentes e respostas passivo-agressivas de baixo. Aqueles embaixo se sentem pequenos e agem de um lugar sem poder. A falta de segurança emocional efetivamente corrói os níveis de confiança e torna qualquer tentativa de congruência extremamente arriscada. O ambiente deles soa assustador e é – tanto para a pessoa que regrediu para imaturidade emocional e, tristemente, para a pessoa no topo que está jogando a culpa.

Aqueles na camada de baixo de qualquer grande organização podem facilmente vir a sentir um senso de dependência àqueles acima deles na hierarquia. Quando jogar a culpa é o modo primário de lidar com pessoas, essa dependência é exacerbada ( nota do Akita: quase uma síndrome de Estocolmo). Então, de um sentimento de dependência, as pessoas facilmente geram um sentimento de hostilidade. À medida que essa hostilidade aumenta também aumenta a experiência debilitante de vergonha – aquele juiz excessivamente crítico que existe latente em todos nós, humanos.

A Aparência e Sentimento de Congruência

A maioria das pessoas que experimentaram uma organização congruente não vão tolerar a miséria de trabalhar em uma organização de atribuição de culpa. Mas muitas pessoas sequer tiveram essa experiência, e tem dificuldade em acreditar em congruência. Vamos ver o que aconteceria se uma dose saudável de congruência pudesse ser magicamente aplicada em larga escala a uma organização incongruente de projetos.

Executivos

Se pudéssemos magicamente instalar congruência nos programas internos desses executivos que jogam culpa, o estilo deles mudaria dramaticamente. Por exemplo, se eles verdadeiramente considerassem os outros envolvidos em sua comunicação, possivelmente acreditariam nas intenções das pessoas de contribuir, de serem produtivos, de pertencer e de aprender – e interpretariam desvios desse ideal como evidência de gerenciamento não efetivo. Sua crença no valor inerente de todas as pessoas com respeito saudável pelas limitações do contexto do trabalho traria energia, esperança, agradecimento, compreensão e gratidão entre seus funcionários.

Um executivo que realmente não acredita nas boas intenções dos funcionários provavelmente diria: ‘Sem desculpas! Você vai entregar isso até primeiro de Outubro.’ Mas, com funcionários cujas intenções são ruins, esse estilo (ou qualquer outro) não vai funcionar mesmo.

Já um executivo congruente que realmente acredita nas boas intenções dos funcionários provavelmente diria: ‘Precisamos muito disso até primeiro de Outubro. O que vocês precisam da gente para conseguir?’ Esse tipo de reciprocidade e apoio desperta um genuíno senso de ‘nós conseguimos’, que aumenta a chance do projeto atingir suas metas e de ninguém precisar fazer promessas falsas para escapar da cultura de culpa.

Quando a alta gerência mantém seu compromisso com congruência, eles vêem que a maioria dos trabalhadores aprecia a oportunidade que o negócio lhes proporciona para desenvolver suas capacidades, sentido, relacionamentos e recompensas monetárias. Eles também sabem como agir quando o trabalhador ocasional não parece apreciar ou ser produtivo. Gerentes que sabem como usar seu poder de forma congruente geralmente conseguem os resultados que procuram – não perfeição, que eles sabem que não devem esperar.

Esses líderes sabem que possuem um tipo especial de poder – poder que usam com consciência e sensibilidade. Eles não deixam de cobrar daqueles que lideram, mas demonstram o mesmo nível de integridade que procuram nos outros. E se não conseguem encontrar os níveis de comprometimentos que requisitam dos outros, eles são abertos quanto a isso. Eles sabem que de vez em quando serão fracos e vulneráveis e precisam de apoio – talvez até para ver o valor de suas próprias visões. Eles usam sua consciência dessa realidade humana para cultivar sua capacidade de empatizar e de ter compaixão por si mesmos e pelos outros.

Executivos congruentes sabem que seu trabalho principal é desenvolver as capacidades de sua organização, não apenas empurrar os mesmos velhos produtos e serviços porta afora. Eles se envolvem de maneira séria nos esforços de melhoria da organização e simultaneamente envolvem outros da organização para conseguir os esforços na vida real, prática operacional e tomada de decisão. Eles sabem que sinergia é necessária para o desenvolvimento da organização e sabem que sinergia vem com conexões de alta qualidade entre as pessoas – independente de nível.

Gerência do Meio

Quando o pessoal do topo começa a operar com congruência, os gerentes do meio recebem mensagens claras e diretas – não mensagens misturadas com duplos sentidos. As comunicações são mais abertas, tornando mais fácil saber mais sobre o que está acontecendo. Dada informação de alta qualidade, eles sabem mais como podem ser úteis, conseguindo mais facilmente se unir a seus líderes em suas visões. Saber mais claramente as direções estratégicas desejadas, e sentir que eles contam nesse processo, os libera para contribuir de forma mais generosa e consciente – em vez de meramente jogar com segurança. Sucesso se torna um objetivo que todos podem compartilhar.

Dada sua posição única de vantagem, as pessoas do meio tem dados mais úteis para ajudá-los a prever problemas, projetar linhas do tempo realistas e predizer tendências. O que eles vêem, ouvem, pensam e sentem é valorizado e eles estão numa posição de iniciar comportamentos que evitam que fraquezas dos projetos cresçam até o fracasso. Eles conhecem a necessidade de interdependência, então se problemas maiores acontecem, eles podem ser considerados para oferecer – e também procurar – por informações importantes. Eles não estão envergonhados nem com medo daqueles que os contrataram. De fato, têm orgulho de seus compromissos com a organização – e sabem que não se trata apenas de compromissos como prazos e orçamentos, mas sobre a verdade sobre esses prazos e orçamentos.

E como congruência que vem do topo também vai para baixo, gerentes do meio notam a diferença entre seus líderes. Eles respondem ao modelo passando isso a seus constituintes. Todos na organização sabem o que está em jogo em cada trabalho bem feito, então todos se sentem seguros em dizer o que está errado, o que está atrapalhando e o que precisa ser consertado. Relatórios honestos de fatos e sentimentos são genuinamente apreciados e não colocam as pessoas em risco de serem humilhadas ou perderem seus empregos. É por isso que organizações congruentes entregam seus projetos como prometido.

Gerentes do meio congruentes encorajam comunicação de alta qualidade. Sua crença na habilidade das pessoas de aprender e mudar em direção a mais congruência tornam aqueles ao seu redor mais responsivos. Com radiação de congruência a partir do centro da organização, todos podem ter um lugar, posição e função de importância e valor – então as coisas acontecem da maneira correta.

Funcionários

Trabalhar na linha de frente de um negócio onde a liderança de cima é congruente, é uma experiência inteiramente diferente de trabalhar numa organização de atribuição de culpa. Compromisso e energia são a norma, não a exceção praticada por novos funcionários até eles “aprenderem como as coisas funcionam por aqui.”

Organizações congruentes suportam uma ideologia que fazer direito no mercado está ligado a lidar direito com os funcionários assim como com os clientes. A perspectiva da liderança inclui consciência global sobre a existência de múltiplos fatores não-lineares, a importância das conexões entre as várias partes do todo e a necessidade de todas as partes saberem seu valor. Os funcionários sentem que esta é uma empresa indo para algum lugar, onde crescimento é um estado natural e o esforço de todos conta. ( nota do Akita: essa é a semente para equipes auto-gerenciadas.)

Trabalhadores numa organização congruente tendem a ter uma visão ampla e podem normalmente manobrar como necessário para atingir as mudanças demandadas pelos clientes. Os funcionários confiam que o que vêem e ouvem é real. Eles compartilham do entusiasmo de criar o futuro. Eles podem não gostar de tudo que acontece – por exemplo, nem sempre acham que estão sendo recompensados adequadamente pelo o que estão dando – mas não se sentem num padrão crônico de diminuição, descrédito e desvalorização do que fazem. Eles podem arriscar a congruência sabendo que isso vai agir como um catalisador para otimizar resultados de sucesso que beneficiam a todos.

Congruência é o grande segredo por trás dos sucessos de muitos projetos. Uma cultura de congruência ajuda um projeto de pelo menos seis grandes maneiras:

1. As pessoas se comprometem com planos somente depois de negociações abertas, então os planos tem mais chances de serem realistas logo no começo. ( nota do Akita: a equipe se compromete apenas com aquilo que realmente acredita que vai entregar – não existe “tenho coisas demais para fazer”)
2. As pessoas vêm rapidamente com fatos, que os gerentes precisam para controlar o projeto, tão logo se tornarem conhecidos, então os gerentes podem agir mais rapidamente com movimentos pequenos para corrigir os problemas. ( nota do Akita: cultura ágil que aceita a mudança.)
3. Quando problemas são revelados, as pessoas vêm rapidamente com idéias de soluções criativas, aumentando as chances de soluções rápidas e efetivas.
4. Uma boa parte dos esforços de todos é devotado a terminar o trabalho e ajudar os outros a terminar o trabalho deles.
5. Porque a falibilidade humana é considerada normal, uma quantidade apropriada – mas pequena – de tempo é gasto garantindo a confiabilidade da comunicação.
6. As pessoas se sentem bem a maior parte do tempo, e por isso são produtivas a maior parte do tempo.

Congruências em Grandes Esforços de Desenvolvimento de Sistemas

No percurso de desenvolvimento de sistemas, as pessoas engajam em numerosos atos de comunicação – sobre requerimentos, prazos, problemas interpessoais, designs, progresso e mais. É por isso que comunicação individual efetiva é importante em todos os projetos, grandes e pequenos. Isso dito, isso se torna ainda mais importante à medida que crescem os esforços de desenvolvimento. A quantidade de comunicação necessária sobe de forma não-linear com o tamanho do projeto, então o efeito de estilo de comunicação imperfeita é aumentada. Portanto, se a qualidade individual de comunicação se mantém constante à medida que o projeto cresce, a qualidade geral da comunicação decai. ( nota do Akita: quantidade de conexões entre pares cresce segundo uma Lei de Potência.)

Por exemplo, um certo nível de congruência de comunicação pode ser adequado para produzir um produto com 25 mil linhas de código, mas totalmente inaceitável para um produto com 2,5 milhões de linhas de código. Para desenvolver sistemas grandes ou complexos, então, não é suficiente prestar atenção aos problemas técnicos – aceitando que o estilo existente de comunicação será adequado. Gerentes também devem melhorar a cultura de comunicação do projeto e, portanto, precisam prestar atenção à congruência.

Para tornar as coisas piores, se não for gerenciado direito, projetos difíceis tendem a diminuir a congruência – porque o estresse tende a subir quando a expectativa de qualidade decai. Não somos criaturas altamente lógicas o tempo todo, mas temos sentimentos, assim como pensamentos em resposta a responsabilidades difíceis. Quando esses sentimentos internos são fortes o suficiente, eles se traduzem em estilos característicos de resolução sob estresse. Se nosso estilo característico é incongruente, as comunicações se tornam menos efetivas e o trabalho se torna ainda mais difícil, criando um ciclo vicioso.

Congruência, claro, é apenas um dos fatores em comunicação efetiva – outros fatores incluem coisas como tempo, memória, platéia adequada e dados precisos. Mas sem congruência, seus esforços de melhorar esses fatores “lógicos” serão sempre seriamente sabotados, junto com sua habilidade de construir sistemas maiores, mais complexos ou mais confiáveis.

Atingindo Congruência

Quando Deming disse, “Coloque o medo fora do ambiente de trabalho,” nós achamos que ele estava falando sobre mudar a organização que atribui culpa a uma organização congruente. Esse tipo de mudança é apresentada a uma pessoa de cada vez – de preferência começando do topo – um passo de cada vez. Os passos podem ser quebrados em seis partes: Conscientização, Aceitação, Autoria, Articulação, Aplicação, Ativismo. Vamos olhar como cada um deles aparece no contexto de um indivíduo tentando mudar a organização que atribui culpa.

Conscientização

Conscientização diz, “Isto está acontecendo. Isto é real.” Conscientização vem da experiência, quando eu me permito experimentar o mundo ao meu redor como ele é – não como deveria ser, ou como eu acho que deveria ser, ou como alguém me diz que deveria ser.

Conscientização é sempre o primeiro passo e provavelmente o mais difícil, porque geralmente não estamos conscientes que não estamos conscientes. Aqui vai um exemplo pessoal de como falta de conscientização pára o processo de mudança antes mesmo de começar:

Jerry estava participando de uma reunião de projeto em uma empresa de software – uma reunião chamada pelo presidente da empresa para descobrir o que estava acontecendo em um projeto atrasado. Depois de alguma persuasão, um dos programadores disse que estava com medo de ir até o Nat, o Gerente de Desenvolvimento, com problemas, por causa da recepção que teve. Nat ficou com a cara vermelha, se levantou e gritou nervoso “Como pode dizer isso? Minha porta estava sempre aberta para ouvir seus problemas! A única coisa que não vou tolerar é se você fica todo tenso quando chega, ou se não tem uma solução para propor!”
Na voz mais calma que conseguia (é difícil ficar calmo quando alguém está tão nervoso, mesmo se não diretamente a você), Jerry se virou ao Presidente e perguntou se Nat alguma vez foi até ele com problemas. Quando o Presidente disse que sim, Jerry perguntou se o Nat estava sempre calmo e carregando uma solução proposta. Antes do Presidente poder responder, Nat interrompeu: “Por que eu iria com um problema se não era importante o suficiente para se excitar a respeito? E, se eu tivesse uma solução, por que eu iria até ele?”
Embora estivesse claro para todo mundo na sala que o Nat estava demandando que os outros “façam como eu digo, não como eu faço”, ele era incapaz de ver a incongruência. Faltando conscientização, não havia jeito do Nat mudar – e de fato ele nunca mudou, até o dia que o Presidente o demitiu para que pudesse procurar por pastos mais verdes.

O caso do Nat é bem típico. Já que incongruência é uma defesa, pessoas incongruentes sobem todos os tipos de escudos que fecham a informação sobre congruência. Sua própria incongruência e a dos outros é invisível – isso é aceito, especialmente se é o normal na organização. Essa invisibilidade torna muito difícil alcancá-los com qualquer tipo de informação sobre o assunto.

Em outras palavras, quando você está sendo incongruente, você está perdendo sua habilidade de ver o que está acontecendo no mundo (dentro e fora). Então, não sabe que precisa mudar. E, mesmo se souber, não tem nenhuma idéia do que mudar para. Não admira que é tão difícil transformar uma cultura incongruente, quando o primeiro passo – conscientização – já é tão difícil de conseguir.

Conscientização vem da experiência, quando você se permite experimentar o mundo ao seu redor – não como ele deveria ser, ou você gostaria que fosse, ou como alguém lhe diz que gostaria que fosse. Mas numa organização que atribui culpa, onde as pessoas se protegem dessa experiência, se tornar consciente normalmente requer ajuda. Ajudar os outros a se conscientizar demanda habilidades para desenvolver ambientes seguros e construir relacionamentos. Demanda paciência e carinho para observar por sinais de conscientização e ajudar a construí-lo. Também demanda fé e um comprometimento de que “parte do meu trabalho é ajudar as pessoas da minha equipe a se desenvolver – a parte mais importante.” Se não acredita nisso, então certamente não tente ajudar. Caso contrário, vai se encontrar dizendo “Você não está consciente de quão ruim você é, mas eu vou torná-lo consciente!”

Mas conscientização da situação geral não é suficiente – você também precisa de auto-conscientização. “Este sou eu. Isso é meu.” Você pode estar consciente da jogatina de culpa, mas enquanto meramente apenas disser “Esta é uma organização de atribuição de culpa,” você não está fazendo coisa alguma para mudar isso. Quando você diz, “Eu sou parte desta organização de atribuição de culpa,” você está dando um passo. Você deve ver a jogatina de culpa como uma parte de si mesmo e de seu comportamento – não apenas alguma coisa que “eles” fazem (a você).

Auto-conscientização é normalmente seguida ou de vergonha ou de culpa. Algumas pessoas reagem com raiva, a si mesmos ou a algum alvo conveniente. Ainda assim, auto-conscientização dá sensação de poder – o pensamento de que já que me pertence, é meu para eu fazer alguma coisa a respeito.

Aceitação

Aceitação move o processo de mudança além de auto-culpa e diz, “Eu não sou uma pessoa má porque faço isso. Minhas intenções são boas, embora minhas ações possam não ser efetivas.”

Aceitação significa que você entende que tomar a responsabilidade não é a mesma coisa que se culpar. Portanto, você tem clemência de si mesmo e de suas imperfeições humanas. Você pára de ser raivoso. Perdoa a si mesmo por não ter feito melhor no passado, baseado no seu entendimento presente e padrões. E, enquanto perdoa e aceita a si mesmo, você ganha compaixão pelos outros envolvidos – aumentando as chances de conseguir se comunicar com eles e efetuar mudanças.

No ponto quando você está tentando alcançar aceitação, é crítico que não seja punido ou humilhado por alguém. Você precisa de ajuda em suportar suas costas, do contrário você pensa tão pouco sobre si mesmo que não poderia fazer qualquer coisa sobre a situação. Claro, em uma organização que atribui culpa, pode ser difícil, por um tempo, evitar esse tipo de punição, que é o motivo pelo qual autoria e aceitação normalmente acontecem internamente, e se mantém internos por algum tempo.

Autoria

Autoria é o primeiro ponto de decisão, quando você diz, “Eu tenho escolhas. Eu posso fazer alguma coisa a respeito.” Com algum encorajamento, você aceita que é responsável por escolhas na sua vida. Você entende que não precisa reagir, mas que pode escolher suas respostas – que você consegue criar, em grande parte, seu próprio contexto interpessoal. Você sabe que existem algumas partes do contexto que pode controlar e algumas que não pode; e sabe precisamente qual é qual.

Articulação

Articulação é o compromisso público de mudar e dizer “Eu vou a público com isso (para assumir responsabilidade e conseguir suporte.)” Articulação não é efetiva se tentada antes dos pré-requisitos estarem nos lugares. Se não consegue aceitar a si mesmo ou como você se refletia para o mundo, ou se não sabe que tem escolhas ou sente que pode ganhar suporte com essas escolhas, então falar para fora é meramente uma bravata não efetiva.

Mas quando os pré-requisitos estão nos lugares, você não consegue ser efetivo mantendo silêncio – você precisa decidir falar. No processo de falar você transforma sua conscientização interior para outro tipo de experiência. Você se ouve e nota a resposta que recebe dos outros. Você torna público, se quiser, a si mesmo – sua posição mental e emocional.

Inicialmente, claro, você precisa procurar lugares para abrir suas expressões verdadeiras e honestas de seus pensamentos e sentimentos. Quando se acostuma mais com o poder de seu verdadeiro você, então consegue procurar o tipo de suporte que o desafia e o confronta, em vez do tipo de suporte que o protege ou consola.

Passos iniciais da articulação congruente normalmente são desajeitados. É por isso que um ouvinte responsivo e receptivo satisfaz um dos requerimentos para promover desenvolvimento e congruência.

Aplicação

Aplicação diz, “Estas são minhas escolhas (minhas novas maneiras de resolução).” Você consegue aprender a ser congruente, primeiro no contexto mais imediato, seguro e encorajador. Então expande os contextos nos quais consegue responder congruentemente. Não tente “não ser incongruente”. Esse comando paradoxal somente envolve incongruência e perfeccionismo. (“Se não consigo ser perfeitamente congruente o tempo todo, eu não valho nada.”) Foque na congruência, pratique congruência e os “músculos” da incongruência vão simplesmente atrofiar.

Com suporte e prática você consegue começar a usar e testar congruência nos seus relacionamentos imediatos. Sugerimos que continue a desenhar para o sucesso, de tal forma que esses testes iniciais de sua nova habilidade sejam feitos dentro de ambientes onde seja mais factível que lhe dêem o benefício da dúvida. À medida que experimenta sucesso, então você consegue se centrar até mesmo em arenas mais turbulentas e de conflito. Em outras palavras, uma vez que você “entende o recado”, não marche à sala do presidente e anuncie que, a partir de agora, todas as partes culpadas devem parar de jogar a culpa, ou caso contrário.

Ativismo

Ativismo diz, “Agora que eu consigo fazer diferença em mim e em meu mundo mais familiar, vou ajudar a espalhar isso pela organização.” Ativismo é liderança aplicada, começando pelo ponto onde você tem competência suficiente em ser congruente para alcançar e ser pró-ativo – antecipando, iniciando, instigando – mas não infligindo. Você não consegue operar de uma posição de incongruência e forçar outras pessoas a serem congruentes. (“Eu preciso culpá-los, porque eles também jogam tanto a culpa ( nota do Akita: “sabonetam”). Quando eles mudarem, então eu serei capaz de mudar.”)

De qualquer forma, você não deve infligir congruência a qualquer um. Congruência é contagiosa – quando dirigida de forma consciente para criar um ambiente seguro, de cultivo, produtivo. Pode se espalhar mais devagar do que você gostaria, mas uma vez que começa a se mover, é difícil parar.

Por que você não deve codificar em Espanhol

Na realidade eu promovo a tradução de software para Espanhol e outras linguagens. Quando digo que você não deveria codificar em Espanhol quero dizer que não deve usar Espanhol ou qualquer outra língua que não seja Inglês como nomes de variáveis, nomes de arquivos, nomes de funções, etc. Linguagens de Programação, linguagens de script, comandos de sistema operacional, etc, são todos baseados na língua Inglesa. Então, por que você faria diferente no seu código?

Pegue por exemplo este código em PHP do post Construindo um forum em PHP e MySQL

require('funciones.php');  
$id = $_GET["id"];  
$citar = $GET["citar"];  
$row = array("id" =\> $id);  
if($citar==1)  
{  
 require('configuracion.php');  
 $sql = "SELECT titulo, mensaje, identificador AS id ";  
 $sql.= "FROM foro WHERE id='$id'";  
 $rs = mysql_query($sql, $con);  
 if(mysql_num_rows($rs)==1) $row = mysqlfetch_ assoc($rs);  
 $row["titulo"] = "Re: ".$row["titulo"];  
 $row["mensaje"] = "[citar]".$row["mensaje"]."[/citar]";  
 if($row["id"]==0) $row["id"]=$id;  
}  
$template = implode("", file('formulario.html'));  
include('header.html');  
mostrarTemplate($template, $row);  
include('footer.html');  

Algumas palavras podem ser familiares para pessoas que entendem inglês já que têm pronúncias similares em inglês, por exemplo: configuracion é configuration, mas e mostrarTemplate? Mesmo formulario dará dores de cabeça a mais de um programador que não saiba Espanhol.

Você também tem que considerar que muitos programadores nem mesmo falam Inglês. Eles podem falar línguas que sequer tem raízes em Latin, para eles já é difícil o suficiente interpretar funções em Inglês como require, echo, etc. Você consegue imaginar um desenvolvedor Chinês tentando entender seu código em Espanhol? Escrever seu código em Inglês é crítico quando se quer trabalhar em um projeto Open Source.

Minha visão é que código deve ser escrito em Inglês: nomes de variáveis, nomes de funções, nomes de classe, campos de dados, etc. Quando digo código, também estou falando de bancos de dados. Existem exceções, objetos nomeados em inglês poderiam ser um problema se o usuário final tiver acesso livre para gerar relatórios, exportar dados, etc.

Não é difícil escrever seu código em Inglês. Use dicionários Espanhol/Ingles (Sua Língua/Inglês – eu recomendo Word Reference). Não entre em pânico, não é para escrever como Shakespeare, gramática não é necessária. Por exemplo, no código acima, mostrarTemplate poderia ser facilmente modificado para showTemplate.

Mesmo que você não tenha intenções de fazer outsourcing, compartilhar ou vender seu código, ter funções em Espanhol misturado com funções nativas de uma linguagem de programação em particular é uma má prática que pode levar a confusões e duplicação de código. Por exemplo, alguém poderia escrever uma função obtenerVariable (obtener significa ‘obter’, em Espanhol), quando já existe uma função chamada getVariable incluso na biblioteca padrão. Se tivesse escrito seu código em inglês e duplicado a função getVariable por engano, é bem possível que o compilador ou interpretador o avisasse. Isso não aconteceria se misturar línguas humanas no seu código.

E sobre comentários dentro de seu código? Embora seja desafiador para muitos que não falam inglês, a realidade é que a maioria dos comentários normalmente tem uma ou duas sentenças. Como disse antes, não é sobre escrever Inglês perfeito. Existem diversas ferramentas que podem ajudá-lo a traduzir sentenças simples. Free Translation é um dos meus favoritos. Mas saiba que essas ferramentas não são 100% perfeitas, traduções de línguas humanas ainda não foram vencidas. Se precisar traduzir um manual, o conteúdo de um website ou as mensagens mostradas ao usuários, por favor, contrate um tradutor profissional.

Não me entenda mal, sou um forte defensor da minha língua materna, Espanhol, mas não sou um idiota. No mundo de hoje, uma empresa estrangeira poderia chegar em você para comprar os direitos do seu produto a qualquer momento. Por exemplo, ano passado o Google comprou o Panoramio, uma empresa fundada pelo Espanhol Eduardo Manchón. Se seu código for ruim para quem não fala Espanhol, será mais difícil de terceirizar sua manutenção (você estará limitado a programadores que falam espanhóis). Esse último ponto poderia ser tópico de discussão com investidores internacionais.

Goste ou não, Inglês é o Esperanto da tecnologia e dos negócios dos tempos modernos. Você deveria escrever seu código em Inglês.

Nota do Akita: novamente, sou um antigo defensor da melhoria da educação pessoal de cada profissional. Cada um é responsável por sua própria capacitação, e ninguém mais. Como disse o autor, aprender – e realmente usar – inglês diariamente não é uma opção, é uma obrigação.

Anos atrás, muitos desenvolvedores reclamaram do código fonte do Ruby porque muita coisa estava documentada em Japonês (!) Imagino que isso deva ter sido um dos motivos que dificulta revoluções maiores no interpretador e a busca por novas alternativas.

Outro caso notório é da SAP, com sua linguagem ABAP/4. Provavelmente, 30 anos atrás, os alemães não imaginavam que seu software seria usado no mundo todo. Veja este pequeno trecho de código ABAP:

IF SUDATE = 'X'.  
SORT ITAB BY UDATE EKKEY-EBELN CHANGENR EKKEY-EBELP  
EKKEY-ETENR.  
ELSEIF SNAME = 'X'.  
SORT ITAB BY USERNAME EKKEY-EBELN CHANGENR EKKEY-EBELP  
EKKEY-ETENR.  
ELSE.  
SORT ITAB BY EKKEY-EBELN CHANGENR EKKEY-EBELP EKKEY-ETENR.  
ENDIF.  

EKKEY, EBELN, EBELP … consultores SAP se acostumam depois de algum tempo, mas tudo isso são acrônimos – que já é ruim – de palavras em alemão! Não é pouco: estamos falando de centenas de milhares de acrônimos como esses, para cada tipo de campo, objeto, tabela em cada módulo empresarial de um pacote que atende Fortune 500. Boa sorte lendo um código desses. ABAP por definição não é a linguagem mais visualmente agradável de se trabalhar, junte a isso diversos nomes de variáveis, tabelas, funções, APIs, tudo em Alemão. Pior: com comentários de código em alemão! Você não precisa compilar nem nada: o código já é naturalmente obfuscado.

Portanto, façam um favor a todos: escrevam nomes em inglês. Não se trata de nacionalismo, idealismo, ou qualquer coisa assim. Isso é puro pragmatismo.

Hoje estava lendo a BusinessWeek e me deparei com este artigo do treinador de comunicação Carmine Gallo. Achei interessante e como muitos de nós na comunidade de tecnologia fazemos palestras ou apresentações, grandes ou pequenas, acho que essas dicas valem muito a pena.

Eu não perco uma apresentação do Steve desde 1997 – a clássica, do seu retorno à Apple – e desde então, cada uma vem sendo melhor que a outra. Vocês podem achar algumas delas via YouTube ou YouTorrent+. A mais recente está disponível para download via iTunes ou para streaming, inclusive em qualidade HD.

Uma coisa que o autor não fala, mas tem que ser óbvio: seus produtos e serviços precisam ser BONS. Nem mesmo Steve Jobs consegue vender certos produtos e serviços que estamos acostumados a ver por aí …

Segue a tradução do artigo:

Faça uma Apresentação como Steve Jobs

Nosso treinador de comunicação explica os slides do ás da apresentação na última Macworld. O resultado? Um framework de 10 passos que você pode usar para surpreender sua própria platéia.

Quando o CEO da Apple (APPL) Steve Jobs começou a Macworld Conference & Expo deste ano, mais uma vez ele subiu o nível em termos de habilidade de apresentação. Enquanto a maioria dos apresentadores simplesmente passam informação, Jobs também inspira. Ele vende a carne e o espeto ao mesmo tempo, como um leitor comentou alguns anos atrás.

Eu analisei sua última apresentação e extraí 10 elementos que você pode combinar para maravilhar sua própria platéia. Tenha em mente que Jobs tem refinado suas capacidades pelos anos. Eu expliquei sua apresentação de 2007 e uma coluna anterior (BusinessWeek.com, 7/6/07) e em um capítulo em meu último livro. De qualquer forma, ele realmente chega ao que parece ser apresentações sem esforço, expandindo e explicando novamente.

1. Defina o tema. “Há alguma coisa no ar hoje”. Com estas palavras, Jobs abriu a Macworld. Fazendo isso, ele definiu o tema da sua apresentação (BusinessWeek.com, 1/15/08) e deu dicas sobre o anúncio do produto principal – o ultra-fino Macbook Air. Toda apresentação precisa de um tema, mas você não precisa entregar no começo. Ano passado, Jobs entregou o tema depois de 20 minutos de apresentação: “Hoje a Apple reinventa o telefone.” Uma vez que você identifica o tema, garanta essa entrega muitas vezes durante a apresentação.

2. Demonstre entusiasmo. Jobs mostra sua paixão por design de computadores. Durante sua apresentação ele usa palavras como “extraordinário”, “incrível” e “legal.” Quando demonstra uma nova funcionalidade de localização para o iPhone, Jobs diz “isso funciona animalmente bem.” A maioria dos apresentadores tem espaço para adicionar alguma originalidade em suas apresentações. Lembre-se, sua platéia quer ser surpreendida, não cair em tédio. Da próxima vez que estiver preparando ou entregando uma apresentação, pense sobre injetar sua própria personalidade nele. Se acha que alguma funcionalidade em particular é “incrível”, diga isso. A maioria dos apresentadores entre em “modo de apresentação” e sentem-se como se tivessem que tirar todo divertimento da fala. Se você não é entusiástico sobre seus próprios produtos ou serviços, como espera que sua platéia seja?

3. Dê um resumo. Jobs resume sua apresentação dizendo, “Existem quatro coisa que eu quero falar hoje. Então vamos começar …” Jobs seguiu seu resumo verbalmente abrindo e fechando cada uma das quatro seções e deixando claro a transição entre elas. Por exemplo, depois de revelar diversas novas funcionalidades do novo iPhone, ele disse, “O iPhone não está parado. Nós nos mantemos fazendo mais e mais melhorias. Esta foi a segunda coisa que eu queria falar hoje. Número 3 é sobre iTunes.” Faça listas e dê direção à sua platéia.

4. Torne os números significativos. Quando Jobs anunciou que a Apple havia vendido 4 milhões de iPhones até então, ele não disse simplesmente deixando o número sem contexto. Em vez disso, ele pôs perspectiva adicionando, “Isso são 20 mil iPhones todos os dias, na média.” Jobs seguiu dizendo, “O que isso significa para o mercado em geral?” Jobs detalhou a divisão do mercado americano de smartphones e a parcela da Apple para demonstrar quão impressionante esse número realmente é. Jobs também apontou que a parcela de mercado da Apple é igual à parcela dos 3 maiores concorrentes combinados. Números não significam muito a menos que sejam colocados em contexto. Conecte os pontos para seus ouvintes.

5. Tem criar um momento inesquecível. Este é o momento na sua apresentação que todos irão falar depois. Toda apresentação do Steve Jobs evolui para uma grande cena. Neste ano, foi o anúncio do Macbook Air. Para demonstrar quão fino ele é, Jobs disse que ele cabe em um envelope.

Jobs extraiu aplausos abrindo um envelope de manilha e segurando o laptop para todos verem. Qual é aquele momento memorável de sua apresentação? Identifique antes e evolua até ela.

6. Crie slides visuais. Enquanto a maioria dos apresentadores enchem seus slides com dados, textos e gráficos, Jobs faz o oposto. Existe muito pouco texto em um slide de Steve Jobs. A maioria dos slides simplesmente mostram uma imagem. Por exemplo, sua frase “A primeira coisa que quero falar para vocês hoje …” foi acompanhada de um slide com o número 1. Só isso. Apenas o número. Quando Jobs discutiu um produto específico como o iPhone, a platéia viu um slide com uma imagem do produto. Quando texto é apresentado, normalmente é revelado como sentenças curtas (três ou quatro palavras) à direita da imagem. Algumas vezes, não havia nenhuma imagem no slide, apenas uma sentença que Jobs entregava como “Existe alguma coisa no ar.” Existe uma tendência em palestras públicas de pintar uma imagem para a platéia criando mais efeitos visuais. Apresentadores que inspiram fazem listas curtas de texto e grandes gráficos.

7. Lhes dê um show. Uma apresentação Jobs ondas e fluidos, temas e transições. Já que ele está dando à sua platéia um show em vez de simplesmente entregar informação, Jobs inclui clipes de vídeo, demonstrações e convidados que dividem o palco. Em sua última apresentação, a platéia ouviu Jim Gianopulos, CEO da Fox Filmed Entertainment e Paul Otellini, CEO da Intel (INTC). Melhore suas apresentações incorporando multimídia, demonstrações de produtos ou dando a outros a chance de dizer algumas palavras.

8. Não se aflija com algum pequeno problema. Apesar de sua melhor preparação, alguma coisa vai errado como aconteceu nesta apresentação. Jobs estava para mostrar algumas fotos ao vivo de um web site, e a tela ficou preta enquanto Jobs esperava a imagem aparecer. Mas não apareceu. Jobs sorriu e disse, “Bem, eu acho que o Flickr não está servindo fotos hoje.” Então ele recapitulou as novas funcionalidades que havia apresentado. Só isso. Nada demais. Eu já vi apresentadores ficarem envergonhados com o menor dos defeitos. Não se aflija. Divirta-se. Poucos vão se lembrar de um defeito pequeno a menos que você chame a atenção deles a isso.

9. Venda o benefício. Enquanto a maioria dos apresentadores promovem funcionalidades dos produtos, Jobs vende os benefícios. Quando apresentou o aluguel de filmes pelo iTunes, Jobs disse “Achamos que existe uma maneira melhor de entregar filmes a nossos clientes.” Jobs explicou o benefício dizendo “nunca oferecemos um modelo de aluguel de músicas porque as pessoas querem propriedade de suas músicas. Você ouve suas músicas favoritas milhares de vezes em sua vida. Mas a maioria de nós assiste a filmes apenas uma vez, talvez algumas poucas vezes. E aluguel é uma grande maneira de fazer isso. É menos caro, não toma espaço no seu disco rígido …” Seus ouvintes estão sempre perguntando a si mesmos, “O que há nisso para mim?” Ouça a pergunta. Não os faça adivinhar. Claramente afirme os benefícios de cada serviço, funcionalidade ou produto.

10. Ensaie, ensaie, ensaie. Steve Jobs não pode dar uma apresentação intrincada com clipes de vídeo, demonstrações e palestrantes de fora sem horas de ensaio. Eu falei com pessoas de dentro da Apple que me disseram que Jobs ensaia a apresentação inteira em voz alta por muitas horas. Nada vem de graça. Você pode ver a apresentação ensaiada da Macworld porque suas palavras normalmente foram perfeitamente sincronizadas com as imagens e textos nos slides. Quando Jobs estava mostrando exemplos de filmes que estão disponíveis no novo serviço de aluguel do iTunes, um pôster de um filme em particular apareceu no exato momento em que ele começou a falar sobre isso. A apresentação inteira estava coordenada. Uma apresentação Steve Jobs parece sem esforço porque é muito bem ensaiada.

Tente usar todas as técnicas que descrevi acima na sua próxima apresentação. Então me diga como foi. Você pode enviar e-mail para mim em carmine@gallocommunications.com com suas opiniões ou postar comentários no artigo.

Carmine Gallo, treinador de comunicação de negócios e ganhador do Emmy-Award para ex-jornalistas de TV, é o autor de “Fire Them Up!” e “10 Simple Secrets of the World’s Greatest Business Communicators”. Ele escreve sua coluna de comunicação semanalmente.

Eu sei que ando meio ausente da comunidade e até mesmo do meu blog (!) Mas realmente o trabalho anda consumindo todo meu tempo (até o livre!). Espero poder voltar às atividades logo. O Ronie também parece estar no mesmo ritmo, ele publicou minha coluna do mês passado um pouco atrasado, mas é totalmente compreensível, dado que eu também estou atrasado com a finalização da revisão da tradução do Getting Real.

Aliás, é exatamente esse o assunto desta coluna. Achei interessante documentar o inside story sobre essa tradução. Dêem uma olhada aqui.

De qualquer forma, o post no blog Signal vs Noise mostra o status das traduções de outros países. Tenho o orgulho de dizer que estamos MUITO na frente: a maioria ainda está no primeiro capítulo. Já terminamos a tradução dos 16 capítulos e estamos na metade da revisão.

Aliás, é por isso que chamei de “Release Candidate 2”. O RC1 foi um lançamento restrito, o RC2 está público e em alguns dias vamos tentar liberar a versão final!

Agradecimentos aos tradutores: Herval Freire, Juraci Krohling Costa, Marcello Rocha, Diogo Bispo, Adriano Mitre, Ricardo Augusto, Rodrigo K.

E também aos revisores: Mateus Del Bianco, Diogo Bispo, Davis Zanetti Cabral, Gustavo Cardoso, Ricardo Augusto.

(Espero não ter esquecido de ninguém :-)