12 coisas que todo mundo deveria fazer
0 — Primeira coisa, ler esse texto :)
Esse texto é uma coleção de coisas que eu fiz, mesmo sem querer, que mudaram minha vida de alguma forma. Minha carreira é no desenvolvimento de software voltado para Internet. Mas acredito que muitos (todas as pessoas do mundo) podem se beneficiar de alguma forma. Somente 3 das 12 coisas são técnicas.
Existem coisas na vida que são marcos, como o primeiro beijo, o primeiro dia de aula, passar no vestibular, tirar carta, etc.
E existem coisas que a gente faz e muda nossas vidas de uma forma que temos vontade de obrigar as outras pessoas a fazerem também. Como ouvir aquela música, ver aquele filme, visitar aquele lugar, agir daquela forma, ou passar por uma situação.
Nesses momentos parece que liga uma chavinha na nossa cabeça e passamos a entender de fato uma coisa que estávamos observando ou estudando há tempos, e acreditamos que as outras pessoas, passando pelas mesmas coisas, terão o mesmo lampejo.
Dá vontade de obrigar todo mundo, mas, tirando o título agressivo que reflete essa minha vontade, vamos nos respeitar e respeitar o momento de cada um para não dar uma John Wayne ensinando o filho a nadar:
E foi por isso que decidi escrever e colocar aqui e cada um achar o que mais faz sentido para si :)
1 — Aprender inglês
Sou do final da década de 70, e no meu círculo de convivência dessa época, que é de antes da globalização, ele era tudo o que eu conhecia de mundo. Nesse contexto eu achava que as pessoas aprendiam inglês por status e eu não enxergava um real valor nisso. Então aprendi inglês pela necessidade, na marra. Depois de ter aprendido me arrependi muito de não ter me dedicado a isso antes. A razão disso é que a maioria das referências da computação, inclusive as européias, são escritas em inglês. É como beber da fonte. O computador é uma máquina de precisão e interpretar mal uma frase em manual é desastroso, e isso acontece muito, diariamente. Quando conhecemos um sistema novo, a nossa primeira impressão é que ele vai resolver todos os problemas que temos, que enfim alguém achou a resposta que queríamos. Mas lendo com mais calma percebemos que não é bem assim, e entendemos suas limitações. Se empolgar sem realmente entender nos leva a decisões desastrosas, algumas milionárias.
2 — Ler o livro Operating Systems Design and Implementation
“Leia o livro
Universo em desencanto
Leia o livro
Universo em desencanto
Leia e vai saber o que é encanto
Leia e vai salvar o desencanto”
(repete infinitamente)
Tim Maia — Leia o Livro
Sempre quis saber como o computador funcionava. Por mais que eu entendesse sobre sistemas, nunca não era suficiente. Uma vez comprei um livro ilustrado que ensinava os detalhes de como o hardware funciona, mas ainda assim faltava coisas como: o que acontece exatamente quando o computador liga, e depois disso.
Quando li o Operating Systems Design and Implementation do Andrew S Tanembaum minha vida mudou. Passei a entender tudo. Diversos textos que eu lia ficaram muito mais simples e prazerosos.
Também virei o chato do livro. Enchia, e encho até hoje, o saco das pessoas para lê-lo.
Ler esse livro fez com que outras coisas fossem menos marcantes para mim, como brincar com sistemas distribuídos, entender atomicidade, o teorema CAP, a lei de Amdahl, os “Números que todo programador deveria saber”.
O livro é relativamente simples de ler, e não importa o ramo de informática que você trabalha, ele vai te ajudar.
Programadores irão entender porque um processo não migra de CPU, porque não existe um agendamento (scheduling) de processamento ou de I/O ideal, porque as vezes um sistema não melhora colocando mais CPUs, porque NUNCA devemos contar com a sorte, etc. E o que mais me incomoda: a diferença entre cache e buffer, causada atualmente pelo Redis. :)
Esse livro é famoso por ter sido o livro que Linus Torvalds leu para começar o Linux.
A propósito, meu grande amigo Gabriel Kaffka me deu a dica do Nand2Tetris, um curso onde você cria um computador desde o processador, virtual é claro, até conseguir rodar um jogo de Tetris. Ainda vou fazer um dia.
Se quiser passar um final de semana estudando sistemas distribuídos, leia a série originalmente chamada "call me maybe", que teve que trocar de nome por causa de direitos autorais: https://aphyr.com/tags/jepsen
Nessa série tem uma "briga" excelente do autor do blog com o criador do Redis.
3 — Apresentar em público
Antes disso não temos a dimensão do que realmente é. Algumas pessoas menosprezam a importância, mas para mim é sempre um momento de muita reflexão, antes e depois. É quando aprendemos a receber feedback, olhar para nós mesmos, administrar ansiedade, administrar críticas e o mais importante: dar um passo para a coletividade, para as interações. Em vários aspectos da nossa vida a maturidade vem com mais interações, com mais coletividade. Nossa importância e responsabilidade aumenta com ela. Treinar isso é muito importante, ignorar é fugir.
Se você é um cara técnico, seu sonho pode ser levar o seu trabalho a ser reconhecido e necessário para muitas pessoas. Treinar essas interações o quanto antes pode te poupar muitos problemas futuros.
Se você não quer continuar técnico e virar um líder, se imagine um presidente de uma empresa sem ter que falar com ninguém e não receber críticas.
4 — EWD196 e EWD1303
Também, se fosse presidente do Brasil, obrigaria as crianças a lerem esses dois textos antes de lanchar :p
Para quem não conhece EWD, ele é Edsger W. Dijkstra, o cara que inventou os semáforos, não esses das ruas, mas um pedaço simples de software que possibilita que nossos computadores nos dê a impressão que estão fazendo milhões de coisas ao mesmo tempo sem bagunçar tudo.
O manuscrito 196 descreve como ele e sua equipe implementaram a idéia de multi-programação criando o sistema operacional chamado “THE”. Para quem não sabe, o computador pessoal até muito pouco tempo atrás só fazia uma coisa ao mesmo tempo, o “core 2 duo” faz duas. Importante mencionar que a última grande revolução foi utilizar computadores pessoais para tudo, distribuindo os sistemas. A multi-programação, através da multi-tarefa, nos dá a impressão de que o computador faz muitas coisas ao mesmo tempo simplesmente executando um programa por vez por uma fração de tempo repetidamente.
Esse manuscrito é sem dúvida o texto mais legal que já li, é uma arte, escrito à máquina, mostra como idéias maravilhosas nascem de maneira simples, motivadas por necessidades simples. Parece o Gênesis da computação como conhecemos hoje. Ele descreve porque decidiu criar os níveis de acesso, simplesmente porque na equipe tinham pessoas menos experientes. Como isso trouxe um medo exagerado e descabido de ter BUGs, e como ele permitiu que sistemas funcionassem mesmo com erros. Sem a possibilidade de erros a informática não teria evoluído gigantescamente como a vemos hoje.
Ainda nessa parte de bugs, o texto mostra como é importante testar idéias, como o teste nos leva a conclusões muito mais efetivas.
“Nosso primeiro grande erro foi ter por muito tempo confinado nossa atenção à “instalação perfeita””
O texto ainda descreve a invenção da paginação de memória, que é aquela coisa que faz com que você abra dezenas de programas ao mesmo tempo mesmo sem ter memória RAM pra isso.
Já o manuscrito 1303 é escrito à mão, e a letra dele é incrível, existe até um conjunto de fontes baseado nela. Ele descreve uma década trabalhando com sistemas operacionais, e não se esqueçam, ele é desenvolvedor, programador.
“Naquele tempo eu era acostumado a programar (em código de máquina) para máquinas que nem existiam ainda…”
Além do texto ser uma aula sobre computação é também quando você descobre a importância do software livre, mais especificamente de compartilhar idéias. Apesar de ter inventado os semáforos, que é essencial para sistemas multi-tarefa, uma década se passou sem que a maior empresa de informática do mundo, A IBM na época, soubesse a necessidade deles, dando muita dor de cabeça para muita gente. E nas palavras de EWD:
“Nessa hora fiquei chocado pelo fato de o mais importante produto da maior e mais poderosa fabricante de computadores do mundo pudesse ter tamanho erro. Depois percebi que de uma certa forma, eu era o culpado, por ter inventado os semáforos e as primitivas de sincronização, não publiquei minha invenção. Não guardamos segredo, ensinávamos livremente o tópico, mas não o publicamos até o final da década. Isso foi uma censura auto-imposta… Em retrospecto eu sinto muito por ter postergado a publicação generalizada até 1967 e acho que eu teria melhor servido a humanidade se permitisse “A Maligna” a melhorar o seu produto.”
Todos os manuscritos: http://www.cs.utexas.edu/~EWD/
5 — Não ter chefe
Apesar dessa situação ter sido um acaso na minha carreira, acho que viver como se não tivesse chefe é simples de fazer e vale como dica.
Na verdade eu tinha chefe, mas ele ficava em outro país.
Muito se fala dos benefícios da “auto-gestão”, e sugiro que quem não saiba procure sobre isso na internet, mas o que mais importante aprendi além disso foi o excelente exercício de auto-estima: não ter uma pessoa para você se mostrar ou buscar elogios sobre o seu trabalho a todo momento. Ninguém melhor no mundo para te elogiar do que você mesmo. Em muitos casos o seu chefe não tem a mesma noção que você sobre o trabalho que você está fazendo. Conseguir reconhecer sozinho algo bem feito e se orgulhar disso, e conseguir sozinho suprir a necessidade de realização, é muito bom. Isso vale pra vida né ? Se ame :)
6 — Não ter equipe
Essa situação também foi um acaso, mas acredito que as coisas que eu aprendi me ajudam até hoje e são fáceis de praticar.
Nessa mesma época eu e mais um éramos responsáveis pela operação de dezenas de sistemas. Esse mais um se mudou para outro país. Aí ficou só eu. Eu fazia o backup, e também o restore. Eu fazia monitoração, e eu mesmo monitorava. Eu fazia os deploys, e também respondia os alertas e administrava os incidentes. Era responsável pelo Disaster Recovery dos sistemas: implementar, testar de tempos e tempos, e operá-lo. Também era o “bedel” dos processos.
Isso me ensinou coisas importantes sobre organização e priorização. Qualquer coisa que eu fizesse mais ou menos, sem carinho, eu era diretamente afetado, e não tinha em quem colocar a culpa, porque eu mesmo tinha feito tudo.
Dica número um: faça tudo como se você fosse o próximo da cadeia de trabalho.
Quando dava problema, mesmo se não fosse eu que tivesse feito o trabalho, era eu mesmo que ia arrumar, não adiantava muito pensar em culpados, tinha que pensar como aquilo não me afetaria mais.
As pessoas falam muito sobre “feedback loop”, acredito que o meu era o mais curto possível :)
Uma forma de entender isso é pensar no famoso caso da empresa que quando criou uma equipe de QA a consequência foi ter softwares piores, simplesmente porque é tirada da equipe de desenvolvimento a responsabilidade pelo software funcionar bem. Não achei o link original, mas aí vão dois exemplos para ilustrar a dica número dois:
Yahoo’s Engineers Move to Coding Without a QA Team
Want Better Quality? Fire Your QA Team.
Dica número dois: cuidado ao definir responsabilidades.
7 — Participar de uma reunião com a alta gerência
Algumas vezes caí de paraquedas em algumas reuniões da alta-gerência.
Todas vezes saí delas diferente.
É difícil explicar a experiência, mas é legal e importante.
Peça para um dia você participar, mesmo que como ouvinte, em um assunto que sua presença não atrapalhe, e se tiver a oportunidade, não evite.
Updated: Dica de Fabrício Leotti, nas palavras dele: "você poderia recomendar ler Project Phoenix e Managing Humans como exemplos de como entender o que você quis dizer."
8 — Fazer o que você pede para os outros fazerem
Na mesma época como “bedel” de processos, e mais tarde como “Engenheiro de Sistemas”, um dos meus papéis era garantir que as melhores práticas e os padrões da empresa eram seguidos, mas chegava uma hora que as coisas pareciam fazer menos sentido.
Então, de tempo em tempo, eu me forçava a seguir as regras que eu obrigava as pessoas a seguirem. Por exemplo, eu construía um sistema pequeno, assim aprendia uma linguagem nova, fazia testes de QA, criava todos os ambientes antes de produção, monitorava tudo da forma que eu pedia pros outros. Participava dos processos para levar aquilo para produção, etc.
Dessa forma aprendi a parar de falar muita besteira, e ao mesmo tempo reforçar ainda mais as coisas que eu já acreditava e atestava que eram realmente simples de fazer.
Nesses momentos que comecei a entender a importância de coisas que para mim antes disso não fazia sentido, como por exemplo uso de frameworks, de ter uma forma simples de debugar coisas sem ter que pedir a bênção de zilhões de pessoas, de ter acesso a repositórios públicos para facilitar a manipulação de dependências, de conseguir fazer deploys de forma rápida, etc.
Coincidentemente, aqui no VivaReal, o João Reis teve a brilhante idéia de pegar os gerentes e criar um time, e fazer com que esse time crie processos de trabalho do zero, como se fosse um time como qualquer outro. Está sendo muito interessante :)
9 — Participar de um processo de seleção
Se um dia tiver a oportunidade, participe de uma contratação de alguém, principalmente se for para um trabalho similar ao seu. Peça para participar mesmo que for só como ouvinte.
É muito interessante descobrir como as pessoas são procuradas, o que é importante, o que o RH olha nos currículos, como eles acham os melhores profissionais.
Depois disso você provavelmente ficará surpreso em diversos momentos. As vezes você tem certeza que uma pessoa foi bem e aí descobre que ela foi vaga, não deu evidências de coisas que ela fez, pareceu desviar de perguntas difíceis, etc.
É um excelente aprendizado, senão essencial, de como administrar sua carreira.
10 — Contribuir com código público
Esse é muito parecido com apresentar em público.
E nesse mundo “inner-source, open-source, gitflow, etc…” é essencial.
Fazer um código que fica lá escondido na sua firma é uma coisa. Mexer no programa dos outros, aos olhos do mundo inteiro, com todas aquelas pessoas dando opinião, criticando, exigindo testes, documentação, exigindo qualidade, exigindo paciência, comunicação boa e educação, e te forçando a se virar, é demais :)
Abrir o seu código ou da sua empresa publicamente também é demais. Parece com o primeiro dia que você sai com a pessoa que ama, não pode esquecer de nada, fio-dental, cotonete, cortar as unhas, tomar um banho bem longo, escolher a melhor roupa, etc.
Ninguém quer mostrar um código que pareça preguiçoso, que não funcione para todo mundo, em vários sistemas, tem que ter um belo manual e excelentes testes automatizados para atrair contribuidores, não pode ter nada “hardcoded”. É quando a gente faz tudo o que dentro da firma deixamos para depois.
11 — SCI
Agora sou líder e virar líder me trouxe diversas situações interessantes e muito aprendizado. Mas ser líder depende de escolhas e oportunidades, então não vou falar muito disso. Tenho um outro texto aqui no blog do VivaReal sobre esse tema para quem se interessar.
Mas tem uma coisa muito legal e prática que aprendi sendo líder e que vale para todo mundo, em diversas situações da vida. O tal do SCI — Situação, Comportamento e Impacto.
É uma forma de você dizer algo a alguém sem julgá-la, sem presumir nada, seguindo a sequência: Falar da situação, do comportamento que a pessoa teve, e o impacto que isso gerou em você e pode gerar nos outros. Isso mesmo, o impacto em você, você posso afirmar, mas o que gerou nos outros não, é uma suposição. Lembre-se, não julgue.
A primeira vez que ouvi falar achei meio mais ou menos, parecia bobo, pouco efetivo e às vezes até desonesto, porque parecia o inverso de falar o que a gente realmente pensa.
O que a gente pensa não é necessariamente verdade, e a gente fala para ajudar, ou deveria né. Tem como falar o que a gente pensa de uma forma melhor para ter um resultado mais eficaz, sem viés, sem julgar, sem presumir.
Foi assim que alguém iluminado chegou ao tal do SCI.
Veja um exemplo:
Situação: Ontem durante o daily meeting…
Comportamento: você ficou no celular o tempo todo
Impacto: Achei que você não estava preocupado em ajudar o time e o time pode não querer contar com você por achar você desinteressado.
Essa conversa pode terminar de milhões de maneiras, desde um “me desculpe”, até com um acordo de convivência do tipo: “Então vamos combinar que quando você eu tiver algo muito sério para resolver, aviso e não vou ao daily meeting”.
SCI é muito simples, mas é mais do que está escrito aqui, sugiro que você procure mais sobre isso.
12 — Fazer o básico
Essa não foi a última coisa que eu aprendi, mas gostaria de fechar com ela pela importância que ela tem para mim.
Quando comecei a trabalhar em empresas grandes comecei a reparar nas pessoas que se destacavam, buscava exemplos bons, queria ter sucesso também.
Na minha cabeça imatura não conseguia entender porque essas pessoas eram tão queridas e tinham tanto destaque. Não conseguia achar nada de especial, não via nada que me brilhasse os olhos.
Isso porque eu não estava olhando para o lugar certo. Achava que uma pessoa para ser reconhecida precisava ter feito algo grande e complexo, mas descobri que o que essas pessoas faziam de especial era o básico, o arroz com feijão, as coisas do dia-a-dia, e faziam isso com extremo esmero, seriedade, e eram pessoas que a gente podia contar, que podíamos confiar.
Foi quando percebi que não adianta fazer coisas grandes e complexas se as coisas simples que sustentam tudo isso estão sendo ignoradas.
E acho que essa é a principal dica que fica: cuide do seu dia-a-dia, do básico.
