We have a little can of paprika in our kitchen. It’s now empty, but we still keep it as a beautiful souvenir of our days in Budapest in 2025. It’s also a remarkable example of what Chico Buarque says in “Budapeste”, one of his best-known books: Hungarian is the only language that the devil respects. I understand. The long words, full of accents and hard to pronounce, can be a bit scary indeed.

A few days ago, I was “reading” some of those long words on the back of the can when one of them, printed in red capitals, caught my attention: CSÍPŐSSÉGMENTES. I noticed that the last part of the word, ségmentes, was quite similar to the Portuguese word for seeds, sementes, so the naive me quickly assumed that the word had something to do with seeds. Since I don’t know Hungarian, I asked ChatGPT whether my assumption was correct. It wasn’t, of course.

It turns out that long word is actually sorta three different words. Combined. It goes like this:

• Csípős is an adjective that means spicy
• ség is a magical suffix that turns that adjective into a noun, i.e., csípősség means spiciness
• mentes is another magical suffix that prepends “free of” or “without” to whatever comes before. It turns spiciness into “free of spiciness”

So, in short, csípősségmentes is a complicated way of saying, “This is sweet paprika. Don’t expect it to burn your tongue”. As you can see, it has nothing to do with seeds.

Later that day, I was talking to my wife about my wrong guess when I remembered the word helplessness, which I happen to know (and like) because of “Helplessness Blues”, a record by Fleet Foxes. That word is also sorta three different words combined: help + less + ness. In fact, English has plenty of similar words, all of them following the some word + ful or less + ness formula, such as “hopelessness”, “mindfulness”, “usefulness”, and so on.

Let’s dissect “helplessness”:

• Help (as “hope”, “mind”, “use”, and all other examples that come to mind) is a noun and a verb. I don’t know English well enough to know what class it belongs in this context
• What I know for sure is that less turns that first part into an adjective meaning “without hope”, exactly the function played by mentes in csípősségmentes
• Finally, ness turns what comes before into a noun that means “the feeling or state of being unable to do anything to help yourself or anyone else”, according to the Cambridge English Dictionary. Once again, we can map this function to a counterpart in csípősségmentes: that’s what ség does

So, in short, both words behave the same way, just in a different order. That got me thinking about why one of the languages feels “natural” while the other carries the bad reputation of being “the only language that the devil respects”. I believe that happens for at least three reasons:

1. Familiarity: we (Westerners) are more exposed to the widely spoken language, English, than to Hungarian, which is only spoken in Hungary and a few other places in Central Europe. As such, the chance that you know words like “help”, “hope”, “mind” and “use” is way higher than the chance that you know “csípős”
2. Word components are longer. While “hopelessness” has 12 letters, “csípősségmentes” has 15
3. A lot of accents. We have them in Portuguese too, but they are limited to one per word. “Csípősségmentes” has three!

Combined, the three aspects above surely make Hungarian seem scary. In English, if you happen to know at least one of the some word + ful or less + ness words, you can get away with any other word that uses the same formula as long as you know the some word part. In Hungarian, on the other hand, we’re left clueless: we don’t know that the word can be split into three different parts because we don’t recognize any of them.

Don’t expect a big takeaway here. At the end of the day, it all comes down to familiarity, and familiarity requires exposure, time and a lot of patience. After some time, it pays off and the words don’t scare you anymore. Even the long, full of accents, hard-to-pronounce ones.

Aprendi a programar em 2004. Durante 9 desses 13 anos, trabalhei em duas agências digitais como desenvolvedor backend, analista de sistemas, head de desenvolvimento e, ultimamente, head de operações. A AG2 (hoje Sapient AG2) foi comprada pelo segundo maior grupo de comunicação do mundo e a DZ Estúdio atende grandes marcas do Rio Grande do Sul como Grupo RBS, Nutrella, Paquetá, Sicredi e Yara.

Essas são minhas credenciais para mostrar um outro ponto de vista sobre um comentário recorrente que ouço tanto de antigos colegas programadores quanto, mais recentemente, de candidatos que entrevisto para vagas abertas: o de que agências digitais são ambientes insalubres e desorganizados, ou seja, uma escolha de carreira questionável.

Ao invés de dar respostas definitivas, quero garantir que você não desconsidere uma opção de carreira por desinformação. Para isso, quero pontuar com bom humor o que é verdade, o que é mito e o que são questões de escolha, isto é, decisões que dependem muito mais das preferências pessoais de cada profissional do que qualquer fator externo.

O que uma agência digital faz

Imagine o lançamento de um produto revolucionário: uma coleira que traduz os pensamentos dos gatos. Se você já conviveu com um bichano e presenciou algum comportamento estranho, sabe que uma invenção dessa magnitude mereceria um lançamento apropriado, não é mesmo? Para isso, até alguns anos atrás, a marca inventora da coleira só precisaria contratar uma agência de publicidade clássica ou agência off. Essas agências existem desde o século XVIII e, grosso modo, cuidam de toda a publicidade de seus clientes que é veiculada fora da Internet. No nosso lançamento fictício, ela poderia criar propagandas para a TV, jornal, spots no rádio etc.

Acontece que estamos em 2017. Você consegue imaginar o lançamento de uma coleira que traduz os pensamentos dos gatos fora da Internet? A Internet é o paraíso dos gatos! Por isso, precisaríamos também de alguém que conheça as dezenas de opções de comunicação online e saiba quais são as mais eficientes para atingir os objetivos da campanha, geralmente tornar o produto conhecido e vendê-lo. É aí que entra a agência digital ou agência on.

Como as pessoas consomem cada vez mais pela Internet, as agências digitais estão tomando rapidamente o protagonismo das agências off. Boa parte das marcas já conta com uma agência on dedicada cuja função é cuidar da presença digital do cliente, ou seja, tudo que ele tem online. Isso inclui sites, hotsites, blogs, contas em redes sociais, sistemas próprios, serviços contratados, plataformas e produtos, contas de mídia (Google AdWords, Facebook etc) e assim por diante.

Uma das maiores vantagens dessa migração para o digital é a medição de resultados com uma precisão impossível para mídias offline. Afinal de contas, nossa marca de coleiras nunca saberá quantas unidades vendeu graças aquele outdoor na Avenida Paulista.

Verdade: programadores de agência devem ser ágeis

Agora imagine que a marca decidiu que o lançamento da nossa coleira futurista acontecerá no intervalo do Fantástico. É um dos horários mais nobres da televisão, comprado a peso de ouro e com bastante antecedência. Como esse comercial certamente incluirá alguma URL para que os telespectadores saibam mais sobre nosso incrível lançamento, o mercado da publicidade acaba de ditar o deadline do projeto.

Aqui é preciso ser honesto: alguns projetos têm prazos apertados. Isso vale principalmente para campanhas que possuem alguma data preestabelecida como o nosso exemplo do Fantástico. Assim, saber gerir o próprio tempo e conduzir o trabalho com um olho no prazo são duas características importantes para se dar bem em uma agência digital.

A máxima de Mark Zuckerberg cai como uma luva: feito é melhor do que perfeito. No nosso exemplo imaginário do lançamento da coleira tradutora, precisamos ter alguma coisa publicada quando a propaganda for ao ar. Na prática, isso pode significar uma versão mais básica, porém completamente funcional, da ideia original. Nos dias seguintes, você pode incluir conteúdos adicionais, refinar as animações do frontend, refatorar trechos de código etc.

Quanto mais próximo o contato com a marca, no entanto, maior é a liberdade da agência digital para sugerir seus próprios projetos, com maior liberdade criativa e prazos mais factíveis. Desse modo, se você estiver considerando uma oportunidade de trabalho, tente descobrir como é a relação da agência com seus clientes — costuma ser um indicador bastante confiável.

Questão de escolha: agências não fazem produtos

Programadores de startup geralmente desenvolvem um único produto, afinal a empresa só existe por causa daquele produto. Se você trabalha em uma fábrica de software, alocado ou não em um cliente, deve trabalhar meses a fio em um mesmo projeto, provavelmente um dos produtos daquele cliente.

Nesse ponto, há uma diferença fundamental: agências digitais não vivem de produtos e mais, não vivem em função de software. Salvo raras exceções, o desenvolvimento de software em uma agência existe apenas para dar suporte a campanhas de… comunicação.

Isso não significa de forma alguma que o desenvolvimento seja visto como algo inferior ou meramente operacional, até porque o software em si é a principal estratégia de muitas campanhas. No entanto, isso faz com que o ciclo de vida dos projetos sejam bem mais curtos comparados a startups e fábricas de software. É o cenário perfeito para “programadores de tiro curto”, que gostam de trabalhar intensamente em projetos menores e ver resultados rápidos. Se você é do tipo maratonista, que gosta de projetos maiores, talvez agências não sejam uma boa ideia.

Verdade: é bom saber um pouco de tudo

Já que agências digitais não vivem de software, é natural que seus times de desenvolvimento sejam enxutos. Raramente há um núcleo dedicado de TI ou infraestrutura, por exemplo, o que tem no mínimo dois efeitos imediatos:

1. Muita gente acha que consertar a impressora é função dos programadores
2. Você se envolve em mais fases de um projeto do que faria em uma fábrica de software, por exemplo

Sabe quem faz a publicação dos projetos? Você. Ou seja, além de um conhecimento mínimo de administração de servidores, você precisa se virar com várias formas de deploy, desde práticas mais modernas como integração contínua até o famigerado FTP.

Trabalhar em muitos projetos de muitos clientes diferentes leva inevitavelmente a vários ambientes de desenvolvimento, com sistemas operacionais, linguagens de programação, frameworks, bancos de dados, restrições de segurança (ou obsolescência) e acessos completamente diferentes. Dessa forma, é mais útil saber um pouquinho de cada coisa do que ser especialista em uma única combinação dessas variáveis. Tomando emprestada uma expressão divertida que vi em um currículo, é preciso ter um altíssimo nível de sivirômetro.

Mito: todas as agências são exploradoras

A carga de trabalho é um dos pontos mais polêmicos relacionado a agências, on e off. Sim, todos nós sabemos de empresas exploradoras que obrigam os times a virar noites trabalhando e pagam (somente) com pizza e refrigerante. Sempre que um conhecido está interessado em alguma oportunidade nesses lugares, inclusive, faço questão de compartilhar o que eu sei sobre aquele ambiente de trabalho e tento dissuadi-lo, deliberadamente.

O fato é que isso é um vício de uma parte do mercado. Vício, aliás, que vem sendo questionado por um número cada vez maior de profissionais, uma nova geração que não glorifica cargas de trabalho excessivas e nada contra a glamorização do workaholic. Muitas dessas pessoas criaram empresas como a DZ em torno desses novos valores. Procure por agências que respeitam as pessoas e você ficará bem.

Mito: criativos não sabem nada de tecnologia

Em algumas empresas, há uma rixa infantil entre designers e programadores. É comum ouvir que os criativos não sabem nada de tecnologia e que os programadores estragam a experiência pensada pela criação. Bobagem, puro preconceito.

Em uma agência digital, a troca de experiências entre esses dois universos é positiva para todo mundo: programadores desenvolvem um bom senso estético e aprendem a ver o design como função e criativos ganham respaldo técnico para propor soluções inovadoras.

E como você verá, essa combinação de habilidades gera cases muito legais.

Mito: projetos de agência não têm graça

Uma das coisas mais legais de se trabalhar em uma agência digital são os projetos diferentes e inusitados baseados nessa mistura de criatividade e tecnologia. Abaixo estão três cases dos últimos 12 meses da DZ Estúdio, bons exemplos dos desafios cotidianos dos programadores de agência.

Te Joga (Sprite e RBS TV)

O próprio objeto da campanha já era inusitado: criar o maior toboágua de rua que Porto Alegre já viu. O maior desafio desse projeto não era o site com o formulário de inscrições em si, mas sim como fazê-lo resistir ao grande número de acessos, motivado pelos ingressos grátis e limitados.

No fim das contas, optou-se por um site simples em PHP puro e MySQL publicado na Heroku, pois essa plataforma permitiria escalar recursos imediatamente caso fosse necessário. Na abertura das inscrições, o time fez um plantão na hora do almoço e os ingressos se esgotaram em apenas seis minutos. Foram mais de 4 mil acessos simultâneos e nenhum downtime.

Juntos Pelo Natal (Sicredi)

Este projeto foi feito com Node.js, Express e Socket.IO.

Ao acessar o site da campanha, os visitantes eram convidados a sincronizar o celular com o computador (ou com outro celular) para ter uma experiência inesquecível.​ ​A partir daí, um vídeo iniciava simultaneamente​ ​nos dois dispositivos, revelando a verdade sobre o fábula natalina: o Papai Noel não faz nada sozinho. Na tela principal, o bom velhinho aparecia sorridente, abrindo as cartinhas, preparando os presentes e enviando para as crianças. Na segunda tela, descobríamos que tudo aquilo só ​era possível com a cooperação dos duendes.
Explorando o comportamento multitela, que é uma realidade no Brasil (90% dos usuários se conectam com 2 ou mais dispositivos), a ação Juntos Pelo Natal virou assunto. O interesse pela marca cresceu imediatamente​ e as buscas por Sicredi aumentaram 20% durante o período da campanha,​ em relação à média do ano.

— DZ Estúdio

ChefBot (Nutrella)

ChefBot é um robozinho simpático que sugere receitas personalizadas de sanduíches, snacks e sobremesas baseado nas preferências que você expressa ao responder algumas perguntas iniciais. Não usamos nenhuma plataforma intermediária como a Gupshup, então tivemos que aprender como programar um bot do zero, o que é sempre mais difícil quando envolve qualquer documentação do Facebook (entendedores entenderão).

Como participei diretamente do desenvolvimento, me sinto à vontade para dizer que a coisa mais legal desse projeto é o conteúdo, ou seja, o que o bot fala e principalmente como ele fala. É um bom exemplo da interdisciplinaridade bacana das agências digitais e me fez valorizar ainda mais o trabalho dos colegas redatores.

Dica de procrastinação: o bot está recheado de easter eggs! Converse com ele e experimente perguntar se no céu tem pão, por exemplo.

Por onde começar

Se você se identificou com o estilo de trabalho de uma agência digital e quer dar uma olhada nas oportunidades, acesse o site da Associação Brasileira dos Agentes Digitais (ABRADi) e conheça os associados. A maioria deles tem uma seção ou página no Facebook dedicada a divulgar vagas abertas.

Ao encontrar uma vaga interessante, consulte salários e veja as opiniões sobre a agência no Love Mondays. Nada é melhor, porém, do que conversar com alguém que trabalha ou já trabalhou por lá. Busque um contato de primeiro ou segundo nível no LinkedIn, envie uma mensagem, se apresente e pergunte sobre a cultura praticada pela agência e principalmente como ela lida com os pontos que discutimos antes, como a proximidade da relação com os clientes.Uma agência digital tem tudo para ser um ótimo ambiente de trabalho. Basta fazer uma boa pesquisa e assegurar que seus valores combinam com a cultura da empresa — uma regra de ouro para qualquer opção de carreira.

Cachoeira do Sul é uma pequena cidade no interior do Rio Grande do Sul. É onde nasceram Adão Iturrusgarai, Alexandre Garcia, Régis Rösing e a Miss Brasil 1972 Rejane Goulart, mas não é particularmente conhecida por formar programadores. Em 2004, quando aprendi a programar, os destinos mais comuns para jovens de 17 anos eram ser cobrador de ônibus, empacotador de supermercado ou trabalhar em uma das indústrias da cidade.

Contra todas as probabilidades, sou cachoeirense e programador.

Por mais estranho que pareça, tudo começou com um concurso de monografias políticas em 2002. Um partido político (não convém nominá-lo) pagaria R$ 1500 ao estudante que escrevesse o melhor trabalho sobre o político cachoeirense João Neves da Fontoura, membro da Academia Brasileira de Letras que chegou a ser embaixador em Portugal e poderia ter sido presidente da república. Para um adolescente pobre do interior, aquele prêmio era uma fortuna.

Mergulhei na história de João Neves assim que minha inscrição foi aprovada. Conversei com historiadores e até com um sobrinho-neto que me emprestou livros raros. Caminhava até a biblioteca pública da cidade quase todos os dias, 11 quilômetros a pé para economizar os R$ 150 de ajuda de custo que recebemos durante três meses: era o pagamento da digitadora.

No fim das contas, meu esforço foi compensado: venci o concurso, fiz uma espécie de discurso na câmara de vereadores e levei o cheque para casa. Tinha certeza absoluta do que faria com ele assim que a segunda-feira chegasse: comprar um computador.

Foi nesse computador, um Celeron 400 de segunda mão, que descobri como funcionavam as páginas que eu acessava na Internet. Criava os arquivos HTML no Notepad e aprendia basicamente por tentativa e erro: alterava uma tag, via o que mudava na página e assim por diante.

Naturalmente, a primeira linguagem de programação que aprendi foi JavaScript. Na época, aliás, ela sequer era classificada como linguagem de programação: para as revistas e sites especializados, era uma “linguagem de scripting”. Classificações à parte, o fato é que esse foi meu primeiro contato com um universo incrível onde tudo (quase sempre) segue um padrão, tem lógica, é previsível.

Talvez eu não soubesse o nome, mas já sabia o que queria ser: programador.

O próximo passo foi o server-side. PHP, mais especificamente. Como o pulso único da internet discada durava apenas da meia-noite às 6:00 da manhã, baixei todo o manual da linguagem em formato Compiled Help File do Windows. Dessa forma, conseguia consultar a documentação de todas as funções durante o dia, o que não deve fazer nenhum sentido para qualquer um que tenha aprendido a programar em tempos de banda larga.

Depois veio um período de drogas mais pesadas: comecei a mexer com Flash e ActionScript e — pasmem — até a fazer layouts de gosto duvidoso no Fireworks. Foi graças a esse perfil “webtudinho”, porém, que fiz meus primeiros freelances para um time de futebol, uma emissora de rádio e um jeep club da cidade. Fazia registro do domínio, “design”, frontend, backend e publicação, tudo com muitas tabelas, contador de visitas e aviso de resolução recomendada. O preço? R$ 400 cada.

Em 2005, veio outro marco importante: consegui uma bolsa de estudos integral para cursar ciência da computação na ULBRA, em Canoas. Era uma ótima notícia que trazia uma preocupação de brinde, pois eu precisaria mudar de cidade e isso só seria possível se eu conseguisse um estágio ou emprego, o que aconteceu de uma forma bem inusitada para a época: uma entrevista por telefone. Como teste prático, combinamos que eu faria a codificação frontend de um projeto criado para uma grande marca de calçados. O resultado agradou os jovens donos da agência e assim consegui meu primeiro estágio em tecnologia antes mesmo do primeiro dia de aula.

Em 18 de fevereiro de 2006, encaixotei meu computador e umas poucas peças de roupa e me mudei para a região metropolitana de Porto Alegre. Estudaria e trabalharia com computação, sem Stack Overflow nem um décimo das ferramentas que existem hoje. O resto é história.

Versão estendida

Sempre contei essa história com muito orgulho. Acho bonito como consegui me formar e trabalhar com o que amo a despeito das adversidades. Tem um quê de jornada do herói e outras pessoas podem até se identificar com algumas partes, mas aqui está a verdade: contada assim, essa história deixa de fora muitas pessoas e fatos importantes.

Para começar, meu interesse por computadores não surgiu do nada. Minha mãe financiou vários cursos de informática, coisas chamadas “ABC do Micro”, “Windows 98”, “Word 97”, “Internet” (sim, havia um curso que ensinava às pessoas como usar a Internet), “Page Maker”, “Access” e “Delphi”. Por mais que eu não lembre bulhufas de Access e Delphi, acabamos de descobrir um contato anterior com banco de dados e programação, certo? Um contato cuidadosamente cortado da primeira versão da história.

Computadores não eram objetos tão inatingíveis. Antes de comprar o Celeron 400, podia usar os micros do pequeno laboratório de informática da escola ou da mesma biblioteca na qual eu pesquisava para a monografia. Eram ótimas oportunidades de descobrir como funcionava aquela máquina maravilhosa.

Falta mencionar ainda que consegui estágio em um dos dois jornais na cidade logo após o concurso de monografias. A bolsa em si era irrisória, mas o trabalho não me deixava completamente exausto e havia banda larga disponível o dia inteiro, ou seja, a história da conexão discada é um exagero romântico. Aproveitava todos os intervalos da minha rotina de repórter mirim para pesquisar sobre as coisas que estava aprendendo.

Foi um colega do jornal chamado Marcelo Faccin, aliás, quem me explicou o que é HTML e como aquele punhado de tags dá vida à web. Mais ou menos na mesma época, um colega de escola chamado Adão Maurício me deu uma cópia pirata do famigerado Dreamweaver e me ensinou a editar o código e usar o modo visual para ver as alterações. Aquilo explodiu minha cabeça!

A partir daí, devo praticamente tudo que aprendi ao fórum do Webmasters Online. “Webmaster”, crianças, era o termo da época para full stack developers, e o WMO era o lugar certo para tirar e responder dúvidas de desenvolvimento, um precursor honrado do Stack Overflow.

Eu era um completo amador fazendo perguntas completamente amadoras, mas sempre havia alguém disposto a responder pacientemente todas essas dúvidas. Essas pessoas, muitas quase tão amadoras quanto eu, saíram do anonimato dos nicknames e tornaram-se nomes conhecidos e até mesmo colegas de trabalho especialíssimos, como a Maria e o Mozart Petter.

Os freelas só aconteceram graças ao estágio no jornal, um ótimo lugar para conhecer pessoas e fazer o bom e velho networking. Todos os trabalhos vieram de contatos que fiz por lá: o gerente financeiro do jornal também era executivo do clube de futebol, uma colega de trabalho era filha de um dos membros do jeep club e a emissora de rádio era uma empresa parceira.

Devo a bolsa de estudos — e só vejo desta forma hoje, com meus 30 e poucos anos — a alguns professores do ensino médio que sempre nos incentivaram a continuar estudando. Não importava se estávamos em uma escola pública: tínhamos que nos preparar para o ensino superior. Muita gente parou de estudar por ali mesmo, é verdade, mas alguns alunos compraram a ideia. Foi graças a esses professores que me formei.

Aliás, o próprio Prouni, o programa do governo que me deu a bolsa, foi uma oportunidade que as gerações anteriores de estudantes não tiveram. E mais: o programa ainda era pouco conhecido e menos concorrido. Além de pessoas e oportunidades, às vezes é preciso um pouquinho de sorte.

Por fim, lembra da entrevista por telefone? Foi indicação da mesma Maria que conheci através do WMO.

O mito do programador autodidata

Pula para 2017.

Acredito que estamos vivendo um período muito especial na história da computação. A revolução da inteligência artificial está apenas começando, mas já dá para vislumbrar um futuro em que teremos assistentes pessoais para quase tudo e os trabalhos puramente operacionais serão feitos por robôs. Dizem até que nós, programadores, seremos os próximos trabalhadores de colarinho azul — a primeira geração de operários cuja função será exclusivamente intelectual e criativa.

O efeito colateral dessa expansão meteórica da indústria é que não estamos formando novos programadores no ritmo necessário. Longe disso: só nos Estados Unidos, há meio milhão de vagas abertas e menos de 40 mil novos graduados para preenchê-las. Como essas posições são críticas para os negócios, a escassez vira um freio indesejado para a economia.

Tenho a impressão de que mesmo aqui no Brasil há mais oferta do que procura, um sinal claro de que precisamos, como indústria, de mais programadores, pessoas de todos os gêneros, idades e origens — não só aquelas que se encaixam no estereótipo do sujeito com poucas habilidades sociais, introvertido e superinteligente. Só os nerds não bastam.

Nós também acreditamos nisso! ❤️ #19elw #EncontroLocaweb pic.twitter.com/3tye0riWrl

— Locaweb (@locaweb) May 18, 2017

A solução de como atrair e acolher esses novos perfis passa inevitavelmente por nós, os mentores naturais da próxima geração de programadores. Estou recontando minha própria história de uma forma menos heroica e mais realista porque acredito que assim sou um modelo mais útil e acessível aos futuros profissionais. Minha esperança é a de que pessoas com histórias de vida parecidas com a minha percebam que podem contar com a mesma ajuda e ter até mais oportunidades do que eu tive.

Minha carreira sempre foi uma escada, não uma plataforma mágica. Houve pessoas dispostas a ajudar em cada degrau, e foi graças a essas pessoas que consegui aproveitar as oportunidades que apareceram. Por isso, não faz o menor sentido me intitular “autodidata”, porque autodidata é quem aprende sozinho, sem professores ou mentores, e eu sempre tive muitos professores e mentores. Não é só um preciosismo linguístico, mas uma forma de reconhecer esse suporte social e mostrar que a computação pode ser receptiva e amigável.

Os programadores de amanhã são como crianças com ouvido absoluto ou uma habilidade natural para os esportes: precisam apenas de incentivo e oportunidades para se desenvolver. Sem isso, nem os talentos mais raros conseguem ir em frente. Pessoalmente, quero que cada vez mais pessoas conheçam esse mundo fascinante pelo qual somos todos apaixonados, onde criamos coisas incríveis e inventamos o futuro.

E que nesse futuro eu possa escrever um novo artigo, contando que Cachoeira do Sul já não exporta apenas jornalistas, cartunistas e misses, mas também programadores e programadoras.

Esse post foi inspirado pelo ótimo I am going to stop saying I taught myself programming when I was 10 and maybe you should too, de Felienne Hermans.

Em setembro de 2016, dei uma vida nova a meu velho domínio e comecei a escrever um blog. Na época, estava relendo Being a Developer After 40 e percebi que o autor Adrian Kosmaczewski tinha adicionado um prólogo agradecendo a repercussão do artigo e colocando links para todas as versões traduzidas do post. Como não havia tradução para o português, decidi que essa era uma ótima forma de começar um blog.

De lá para cá, escrevi um artigo sobre a primeira linguagem que todo programador deve aprender, contei a história das programadoras do ENIAC e até dei dicas de como se comunicar com clareza usando conceitos de marketing digital. O que une todos esses artigos é a relação direta com o desenvolvimento de software, mas passando longe de trechos de código ou tutoriais sobre a tecnologia do momento.

Essa linha editorial não foi um acaso. Sempre acreditei que bons desenvolvedores de software são aqueles que fazem muito mais do que apenas programar bem. Afinal de contas, há uma infinidade de coisas além do código que precisam da nossa atenção se realmente queremos melhorar essa indústria de paradoxos, onde empresas de ponta humilham seus colaboradores e mulheres são marginalizadas.

Por isso, resolvi criar a Além do Código, uma newsletter semanal com links e comentários sobre os melhores artigos que eu encontrar sobre diversidade, ética, privacidade e outros assuntos não-técnicos ligados à tecnologia. Entre várias ótimas newsletters de tecnologia com enfoque mais técnico, espero que seja um lembrete de que podemos — e devemos — fazer mais.

Pense, por exemplo, na linha do tempo de qualquer emprego. Você se comunica desde quando escreve seu perfil no LinkedIn e faz a primeira entrevista até quando dá bom dia aos colegas ou documenta um projeto. Goste você ou não, comunicação é fundamental.

Fundamental e irônica, pois você pode se comunicar perfeitamente sem dizer ou escrever nada (pense em emojis, libras e turistas se comunicando por gestos) e falar ou escrever até cansar e, ainda assim, não ser compreendido. Ou pior: ser mal interpretado.

Ao contrário do que muita gente pensa, se comunicar com clareza não é falar bastante, mas sim dizer as coisas certas, de forma simples e compreensível. Esse detalhe deixa as coisas mais justas entre pessoas mais introspectivas e colegas mais comunicativos: pelo menos nesse sentido, todos têm as mesmas chances no mercado de trabalho.

O que não significa que seja uma tarefa fácil — graças ao nosso cérebro.

Como funciona nossa atenção

Quando falamos ou escrevemos, nossa tendência natural é acreditar que quem está nos ouvindo ou lendo prestará atenção em todas as palavras, nos mínimos detalhes de cada frase. Na prática, porém, não é bem isso que acontece. Nosso cérebro evoluiu para usar todo e qualquer atalho para poupar energia e faz isso até nas coisas mais simples, como prestar atenção ao que você diz ou escreve.

Resumidamente, nossa massa cinzenta vive tentando adivinhar as informações focando nas partes mais importantes e chutando o resto. Sabe quando você “lê” uma notícia apenas rolando a página e passando os olhos pelos subtítulos? É seu cérebro preguiçoso em ação.

O efeito colateral disso é que não temos paciência para pessoas prolixas. Explicações mais longas que o necessário soam como desculpas (mesmo quando não são), divagações nos fazem “perder o fio da meada” e livros densos como Cem Anos de Solidão são campeões de desistência.

Por isso, um grande truque para se comunicar com clareza é garantir que o cérebro seja bem alimentado com pistas sobre o que é importante. E a melhor forma de aprender a fazer isso é prestar atenção em landing pages.

Anatomia de uma landing page

Landing pages são páginas web simples extremamente focadas em algum tipo de conversão. Por conversão, entenda qualquer coisa que você deseje que o visitante da sua landing page faça, como baixar um app, preencher um cadastro em troca de um ebook ou deixar um depoimento.

Comecei a ler mais sobre landing pages no início de 2016, quando minha sócia e eu redefinimos nossas funções na Gongo e passei a cuidar também do nosso marketing digital. Como não tenho nenhuma formação na área, li muito sobre o assunto e descobri uma coisa interessante: landing pages são estruturadas cuidadosamente para prender a atenção dos visitantes.

Por isso, preste atenção nos conceitos abaixo. Mais adiante, eles vão fazer sentido e você verá porque landing pages são ótimos exemplos de como se comunicar com clareza.Cada elemento de uma landing page é pensado para “converter” o maior número possível de visitantes. O design extremamente funcional e o texto trabalhado minuciosamente seguem uma lógica progressiva pensada especialmente para o nosso cérebro preguiçoso: cada pedaço do conteúdo acrescenta um detalhe interessante para manter o visitante na página.

Tudo começa com uma headline matadora, ou seja, uma frase de poucas palavras que sintetiza o valor do que você está oferecendo. A headline é o primeiro item visto pelo visitante e deve ser suficiente para que ele entenda completamente o produto ou serviço. Sabe por quê? Porque em boa parte das vezes, é só isso mesmo que ele verá.

Se a headline chamar a atenção, é hora de despertar interesse. Essa é a função da subheadline, um texto de apoio que detalha um pouco mais o produto ou serviço. Pelas razões que você já sabe, a subheadline também é curta, pensada para ser mais persuasiva do que falastrona.

Se tudo der certo e você conseguir chamar a atenção do visitante, ele topa ler um pouco mais e você tem alguns segundos extras de atenção para vender seu peixe. Nesse texto com os benefícios também não há espaço para enrolação. As frases e parágrafos são curtos e objetivos.

Por fim, temos também uma call to action ou CTA. Essa “chamada para a ação” é o elemento mais importante da landing page, pois é onde o visitante finalmente faz o que você quer que ele faça, ou seja, converte. Se a landing foi feita para ele baixar um app, por exemplo, o CTA é o botão de download.

Pronto. Agora que você já sabe criar ótimas landing pages, vamos ver como usar as mesmas ideias para se comunicar com clareza.

Antes de mais nada, diga o que você quer dizer

Se você quiser guardar apenas uma coisa desse artigo, guarde isto: a forma mais clara de se comunicar é simplesmente dizer o que você quer dizer, sem rodeios. É por isso que toda landing page começa com uma headline escancarada, para garantir que até o visitante mais distraído entenda a mensagem que ela quer passar.

Isso é especialmente difícil para nós, brasileiros, principalmente quando precisamos dizer “não”. Antes de negar, nós justificamos, pedimos desculpas, damos voltas e mais voltas. Se você já trabalhou com americanos (neste artigo eu digo porque isso é uma ótima ideia, caso você não tenha trabalhado), sabe melhor do que ninguém que eles não têm nenhuma dificuldade com isso. Pode parecer grosseria, mas eles apenas vão direto ao ponto.

Um exemplo fácil e um bom ponto para praticar são perguntas que podem, ou melhor, devem ser respondidas com “sim” ou “não”. Por exemplo:

Você conseguiu acabar o trabalho?

Você pode fazer uma dúzia de considerações, mencionar todos os colegas que ajudaram (ou não) a concluir a tarefa ou até mesmo reclamar que o computador lento diminuiu sua produtividade, mas faça isso depois de dizer “sim” ou “não”.

Encare essa resposta objetiva como uma demonstração de respeito ao tempo do seu interlocutor e não tenha medo de parecer ríspido, pois você pode complementar sua resposta depois usando a mesma lógica progressiva das landing pages.

O “sim” ou “não” é a sua headline. Quem fez a pergunta já tem a resposta que queria e pode encerrar a conversa sem nenhum problema depois dessa única palavra. Se ele ou ela demonstrar interesse e quiser saber mais, escolha sua consideração mais importante e faça dela sua subheadline. E assim por diante, tomando o cuidando de ser suscinto e priorizando o essencial a ser dito.

Clareza = simplicidade

Ao falar e escrever, preze pela simplicidade. Você verá que simplificar as coisas é surpreendentemente difícil, mas aqui vão algumas dicas práticas que vão ajudar a deixar as coisas mais simples:

• Não deixe nada subentendido. Pessoas diferentes podem entender a mesma coisa de formas diferentes, principalmente se essa coisa não estiver suficientemente clara, então seja explícito.
• Evite regionalismos e gírias.
• Não use termos técnicos desnecessários. Tente substituí-los por palavras mais simples, mesmo que elas não representem exatamente a mesma coisa que o termo original. É melhor garantir uma comunicação clara do que se prender a preciosismos técnicos.

Se estiver escrevendo:

• Escreva do jeito que você fala, naturalmente. Um bom teste para saber se você está no caminho certo é ler tudo em voz alta e perguntar a si mesmo se você falaria dessa forma, com essas mesmas palavras, com a sua tia, por exemplo. Se a resposta for não, delete e comece de novo.
• Seja breve: use palavras, frases e parágrafos curtos.
• Use tópicos para facilitar a leitura de itens que você queira destacar (o perfil do público-alvo do site, as opções de tecnologias para o próximo projeto, os prós e contras do novo banco de horas e assim por diante).
• Use negrito ou cores diferentes em trechos importantes que não podem passar despercebidos.
• Cole endereços de links na próxima linha ao invés de escondê-los no meio do texto. Dessa forma, fica mais fácil encontrá-los e clicá-los.
• Deixe espaço entre os parágrafos para deixá-los mais legíveis e para não assustar ninguém com blocos gigantes de texto.

E como diria George Orwell, um dos meus autores preferidos, quebre qualquer uma dessas regras antes de escrever alguma barbaridade.

Deixe claro o que você quer

Assim como nas landing pages, o call to action é uma parte muito importante da comunicação quando você quer que a outra pessoa faça alguma coisa. Você precisa deixar isso extremamente claro, pois todo o esforço de comunicação irá por água abaixo se ele ou ela não der esse próximo passo.

Os CTAs do cotidiano são mais sutis que os botões das landing pages e por isso são um pouco mais difíceis de notar. Como exemplo, imagine que você precise receber um relatório até o fim do dia. Nesse caso, a ação desejada é exatamente essa, que alguém envie o relatório até o fim do dia. Já a chamada para a ação é como você deixará isso o mais claro possível para essa pessoa.

Aqui, a regra de ouro também vem das landing pages: foque em uma única ação. Como você viu, nossa atenção segue suas próprias regras e, sendo honesto, fazer com que alguém faça uma única coisa já é uma tarefa suficientemente complicada. Várias ações? Esqueça.

Por isso, evite enviar aqueles emails pedindo mil coisas. Se pedir tudo isso for realmente necessário, priorize a coisa mais importante e a peça primeiro. Se a comunicação fluir, você terá oportunidade de pedir as outras na sequência. Não se afobe: se você insistir em pedir tudo de uma vez, as chances de você ser atendido vão cair drasticamente.

Por fim, lembre-se que seu CTA é como um botão em uma landing page. Ele é a parte mais importante da comunicação e precisa ser visto e entendido. Deixe claro o que você quer que a outra pessoa faça e evite fazer suposições sobre o que ela sabe ou não. Na dúvida, é sempre melhor pecar pelo excesso.

Conclusão

Se comunicar com clareza é difícil e depende de uma séries de fatores, como resumiu de forma irretocável o escritor francês Bernard Werber:

Entre o que eu penso, o que eu quero dizer, o que eu acredito que eu digo, o que eu digo, o que você quer ouvir, o que você acredita ouvir, o que você ouve, o que você quer entender, o que você acha que entende, o que você entende… São dez possibilidades de termos algum problema de comunicação. Mas vamos tentar mesmo assim…

Porém, com alguma dedicação, todo mundo pode se comunicar de forma mais clara e simples. Ser mais articulado fará você expressar suas ideias com mais facilidade e ser entendido, uma belíssima habilidade para sua carreira e quaisquer outros relacionamentos interpessoais.

Como disse Werber, não custa tentar.

Em sua pesquisa, Kathy encontrou uma foto famosa do ENIAC, o primeiro computador totalmente eletrônico de uso geral. Publicada nos principais jornais dos Estados Unidos na época de seu lançamento em 1946, a imagem mostrava quatro homens e duas mulheres operando o computador, mas o que realmente chamou a atenção de Kathy foi um detalhe incômodo: apenas os homens da foto estavam identificados na legenda.

Kathy mostrou a foto a muitas pessoas, mas nem mesmo historiadores da computação sabiam quem eram aquelas mulheres. O mais provável, lhe disseram, era que as mulheres fossem “refrigerator ladies”, ou seja, modelos que posavam junto de eletrodomésticos para torná-los mais atrativos, um truque de marketing bastante comum na época da foto.

Mas esse palpite estava terrivelmente errado.

O nascimento do primeiro computador

No final da Segunda Guerra Mundial, o exército dos Estados Unidos tinha uma missão insólita longe dos campos de batalha: calcular a trajetória de mísseis desde o momento em que saíam dos canhões até atingirem seus alvos. E no auge da guerra, com um poder de fogo cada vez maior, esses cálculos eram cada vez mais necessários.

Por isso, o exército começou a recrutar pessoas formadas em matemática de todo o país para realizar as complexas equações diferenciais que traçavam a rota dos mísseis. E com a maioria dos homens lutando ou trabalhando em outras funções de guerra, essas pessoas eram todas mulheres. Seu título oficial era computer, “computadora”.

Em alguns meses, havia uma centena de computadoras preenchendo tabelas balísticas manualmente, resolvendo folhas e mais folhas de equações contando apenas com a ajuda de calculadoras de mesa. Só tinha um problema: cada cálculo levava 30 horas.

Logo, ficou claro que contratar mais matemáticas não seria suficiente para suprir toda a demanda de cálculos que a guerra estava produzindo. Foi então que o exército resolveu bancar um experimento altamente arriscado: uma máquina que pudesse realizar as equações em uma fração do tempo que as computadoras levavam. Assim nascia o Electronic Numerical Integrator and Computer, mais conhecido por sua sigla, ENIAC.

O projeto foi tocado como segredo de guerra e liderado pelos engenheiros John Presper Eckert e John W. Mauchly. Na primavera de 1945, pouco tempo antes do ENIAC ficar pronto, seis computadoras foram escolhidas para o que era considerado um trabalho inferior comparado ao prodígio de engenharia que Eckert e Mauchly haviam criado: descobrir como a máquina funcionava e como ela deveria ser programada para executar os cálculos balísticos. As matemáticas selecionadas foram Frances Bilas, Jean Jennings, Ruth Lichterman, Kathleen McNulty, Betty Snyder e Marlyn Wescoff.

Programando um monstro

O ENIAC era um monstro de 18.000 válvulas e um emaranhado de cabos e interruptores que ocupava um andar inteiro da Universidade da Pensilvânia. Tudo que as seis mulheres receberam para descobrir como programá-lo foram os diagramas lógicos dos 40 painéis que compunham o computador.

Não havia livros, sistema operacional, linguagem de programação ou ferramentas para ajudá-las. Programar o primeiro computador da história significava escrever toda a lógica no papel, reproduzí-la fisicamente com extrema precisão plugando e desplugando cabos e alternando interruptores e documentá-la nos mínimos detalhes para que pudesse ser reutilizada no futuro. Configurar um único programa levava várias semanas.

Havia diagramas lógicos do ENIAC e nós supostamente tínhamos que estudá-los e descobrir como programá-lo. O ENIAC era uma merda de programar!

— Jean Jennings em The Computers

Depois de algum tempo, as programadoras se familiarizaram com o ENIAC. Como ele era basicamente uma calculadora gigante, elas perceberam que a melhor forma de usá-lo para determinar a trajetória dos mísseis era quebrar o cálculo em partes menores que podiam ser executadas uma de cada vez. Cada módulo calculava sua parte da equação, passava esse resultado parcial para o próximo módulo e assim por diante até o resultado final ser impresso.

E como todo programador, as mulheres do ENIAC também corrigiam bugs. E por corrigir bug, em uma máquina que ocupava 270 m², entenda literalmente entrar de cabeça em um mar de cabos e interruptores para encontrar qual das 18.000 válvulas queimou ou qual das milhões de soldas estava com algum problema. Era algo tão comum que elas desenvolveram métodos para descobrir rapidamente qual componente estava danificado.

Depois de alguns meses, o trabalho foi recompensado: os cálculos balísticos que levavam 30 horas passaram a ser resolvidos em 15 segundos pelo ENIAC.

O começo do esquecimento

Um dia, Jean Jennings e Betty Snyder foram chamadas por Herman Goldstine, responsável pela comunicação entre o exército e o time do ENIAC. O projeto seria lançado oficialmente em duas semanas em uma cerimônia luxuosa e ele queria saber se as mulheres eram capazes de programar um cálculo balístico a tempo de ser demonstrado ao vivo no lançamento. Elas aceitaram o desafio e começaram a trabalhar dia e noite na tarefa.

Na véspera do lançamento, em pleno dia dos namorados, ainda havia um detalhe que as duas não conseguiam resolver: o ENIAC estava calculando a trajetória do projétil indefinidamente, ou seja, continuava a projeção mesmo depois que o projétil já havia atingido o chão. Era um bug embaraçoso que arruinaria a festa de lançamento — um míssil que continua sua trajetória dentro da terra era uma imagem tragicômica que colocaria em cheque a capacidade do ENIAC.

À meia-noite, elas desistiram e pegaram o último trem para suas casas, mas Betty não conseguiu dormir. Repassando mentalmente a trama de cabos e interruptores, descobriu onde estava o problema. No dia seguinte, tomou o primeiro trem, ajustou o cabo defeituoso e rodou o programa. O computador calculou a trajetória perfeitamente e o ENIAC estava pronto para ser apresentado ao mundo.

Além de cientistas, Eckert e Mauchly eram ótimos vendedores. Eles sabiam que uma calculadora gigante executando uma equação diferencial durante alguns poucos segundos não era exatamente empolgante, então cortaram bolinhas de pingue-pongue, as numeraram e as colocaram sobre as válvulas. Com a luzes apagadas, as bolinhas se iluminariam quando as válvulas fossem ligadas e os jornalistas poderiam literalmente acompanhar o cálculo enquanto ele acontecia.

O cálculo perfeito, a apresentação digna de filmes de ficção científica e o discurso futurista dos engenheiros garantiram o sucesso da festa de lançamento. Mauchly chegou a dizer à imprensa que, no futuro, máquinas como o ENIAC baixariam o preço do pão. Os jornalistas ficaram radiantes com a novidade, o ENIAC virou uma lenda e Eckert e Mauchly gravaram seus nomes permanentemente na história da computação.

Nenhuma das seis programadoras do ENIAC foi convidada para a festa.

Legado

Quando a Segunda Guerra Mundial terminou, as mulheres que estavam ocupando postos de trabalho normalmente destinados aos homens foram aconselhadas a voltar a suas casas e deixar as vagas abertas aos homens que estavam voltando da guerra. As programadoras do ENIAC jamais ouviram essa sugestão, pois eram formadas em uma época em que a maioria dos homens sequer ia à faculdade e o exército sabia que eram fundamentais para levar o projeto além dos cálculos balísticos.

Nós éramos como pilotos de caça. Quero dizer, aqui está essa grande, grande máquina, mas você não pode pegar qualquer piloto de avião, colocá-lo em um caça e dizer “vai lá, cara”. Não podia ser desse jeito.

— Kathleen McNulty em The Computers

O ENIAC funcionou durante 10 anos e Frances, Jean, Ruth, Kathleen, Betty e Marlyn tornaram-se as primeiras programadoras profissionais, as primeiras professoras da programação moderna e as inventoras de ferramentas que abriram caminho para o software como conhecemos hoje.

Frances Bilas (depois Spence, 1922–2013) continuou programando equações com o ENIAC após a guerra e colaborou com os principais matemáticos do mundo.

Jean Jennings (depois Bartik, 1924–2011) trabalhou no time que transformou o ENIAC em uma máquina de programa armazenado, tornando mais rápido e fácil programar problemas mais complexos. Participou também dos projetos dos dois primeiros computadores comerciais, programando o BINAC e criando a lógica e um sistema de backup de memória eletrostática para o UNIVAC I. Mais tarde, criou relatórios para ajudar negócios a entenderem o potencial dos microcomputadores.

Ruth Lichterman (depois Teitelbaum, 1924–1986) foi realocada juntamente com o ENIAC para Aberdeen, Maryland, para ser a professora da próxima geração de programadores do projeto.

Kathleen McNulty (depois Mauchly Antonelli, 1921–2006) foi quem teve a ideia de criar subrotinas para conseguir calcular trajetórias que extrapolavam os limites computacionais do ENIAC. Essas subrotinas foram as precursoras das funções e tinham a nobre intenção de reaproveitar partes do programa que se repetiam. Se você pensou em DRY, acertou na mosca.

Frances Elizabeth “Betty” Snyder (depois Holberton, 1917–2001) trabalhou com Jean no UNIVAC I desenhando seu console de controle, teclado e teclado numérico. Também foi para esse projeto que ela escreveu o primeiro algoritmo de ordenação em 1952. Betty ainda escreveu padrões para o FORTRAN e participou de vários comitês nacionais e internacionais de computação como o que foi responsável pela criação do COBOL.

Marlyn Wescoff (depois Meltzer, 1922–2008) se desligou do projeto para se casar em 1947, antes do ENIAC ser deslocado para Aberdeen.

O trabalho delas alterou dramaticamente a computação nos anos 40 e 50, mas elas foram consideradas meras operadoras e não ganharam nenhum crédito até serem descobertas por uma estudante de Harvard 30 anos depois.

Reconhecimento

As mulheres daquela foto famosa não são modelos. Elas são dois dos nomes mais importantes da história da computação e se chamam Jean Jennings e Ruth Lichterman. Quando Kathy Kleiman descobriu isso e foi atrás delas, as programadoras do ENIAC ficaram surpresas de serem reconhecidas.

Perto do aniversário de 50 anos do lançamento do ENIAC, em 1996, Kathy ligou para a Women in Technology International perguntando o que eles fariam para honrar as seis programadoras e o que ela ouviu foi mais uma triste ironia na história daquelas mulheres. A WITI, criada justamente para promover o valor das mulheres na indústria da tecnologia, não fazia a menor ideia de quem Kathy estava falando.

Na festa oficial do 50º aniversário, apenas duas programadoras do ENIAC foram reconhecidas. Assim como no lançamento, as outras três mulheres que ainda estavam vivas não foram sequer convidadas.

Ao saber disso, Kathy decidiu gravar suas histórias e lutar por seu reconhecimento público. Graças a ela, as seis programadoras do ENIAC foram induzidas ao hall da fama da WITI durante a conferência Women in Technology de 1997. Nos anos seguintes, elas também receberam prêmios da IEEE Computer Society e do Computing History Museum.

Kathy criou o ENIAC Programmers Project e suas gravações resultaram no documentário The Computers, lançado em 2014 com as entrevistas e filmagens originais que mostram como o ENIAC era operado. Apesar do ressentimento óbvio, as programadoras mantinham um bom humor surpreendente para quem só teve seu trabalho reconhecido 50 anos depois.

O futuro das mulheres na computação

Falar sobre o ENIAC sem citar o nome dessas seis mulheres é compactuar com uma injustiça histórica. Tirar o crédito de suas contribuições inestimáveis perpetua os estereótipos que mantêm as mulheres afastadas da programação.

Em 1946, a computação foi ingrata com as programadoras do ENIAC.

Em 1986, a computação era hostil às colegas de Kathy Kleiman.

Em 2016, a computação ainda é uma terra inóspita para mulheres.

Devemos contar essa história incrível com o mesmo entusiasmo com que falamos de Alan Turing, Bill Gates, Steve Jobs e outros expoentes masculinos.

De todos os problemas que afastam as mulheres da computação, eliminemos pelo menos este: o mito de que todos os grandes inovadores da história da computação são homens. As seis programadoras do ENIAC são a maior prova de que isso está muito longe da verdade.

Tive uma vida fantástica. Tudo que eu fiz foi o começo de algo novo.

— Betty Snyder em The Computers

São muitas opções e é normal ficar em dúvida, mas uma coisa é certa: você não irá muito longe se não dominar outra “linguagem” antes: inglês.

Inglês é a língua franca da tecnologia. Tudo, desde os comandos mais básicos da programação como if, while e for loop, está escrito ou é falado em inglês. Por isso, vou mostrar neste artigo como saber inglês pode facilitar sua carreira, aumentar suas chances no mercado de trabalho e contribuir para o seu crescimento pessoal.

Para começar, vamos ver um único número que deixa bastante claro o abismo que separa os profissionais que sabem inglês dos que não dominam o idioma.

Uma goleada de 75x1

Se inglês é a língua franca da tecnologia, é meio óbvio que a quantidade de informação disponível em inglês seja muito maior do que em português, certo? Mas será que conseguimos estimar de alguma forma o tamanho dessa diferença? Os números do Stack Overflow dão uma boa ideia.

O Stack Overflow é uma espécie de terra santa dos programadores. É o 48º site mais acessado do mundo e tem 40 milhões de visitas todos os meses. Fundado em 2008, ele tem nada mais, nada menos do que 12 milhões de perguntas, 20 milhões de respostas e 52 milhões de comentários. Jogue uma dúvida de programação no Google e é praticamente certo que os primeiros resultados da busca venham de lá.

Em 2014, o Stack Overflow lançou sua versão em português, que tem até agora 52 mil perguntas e 67 mil respostas. Entre todos os sites de perguntas e respostas lançados a partir do sucesso do SO, a versão brasileira fica atrás até de fóruns de tecnologias específicas como Drupal e SharePoint e assuntos de nicho como games e cartografia.

Ou seja, fazendo uma comparação justa levando em conta a quantidade de informação produzida em relação ao tempo de vida de cada projeto, a versão gringa do Stack Overflow gera 75 vezes mais conteúdo do que a versão Herbert Richers.

Dada a importância do Stack Overflow, não é nenhum exagero dizer que um profissional que domina inglês dispõe de uma base de conhecimento 75 vezes maior do que um colega que conta apenas com o português para tornar-se e manter-se um bom programador. Não é impossível, mas é (cada vez) mais difícil.

Tudo está em inglês

Documentações

Vamos começar pelo básico: documentações, os manuais de instruções das linguagens de programação. Como são a referência básica dos programadores, muitas linguagens já estão documentadas em português, mas outras não estão. E não estou falando apenas de linguagens mais underground como Lua, R ou Go. Node.js e Python, por exemplo, não têm documentação em português.

Se linguagens com milhões de adeptos têm apenas documentação em inglês, o que esperar de todas as milhares de outras tecnologias como frameworks, bibliotecas, plugins e componentes? Isso mesmo: tá tudo em inglês.

Como a maior parte das traduções é fruto de trabalho voluntário, você dependerá da boa vontade de outros brasileiros para ter acesso a documentações em português. Por outro lado, se dominar inglês, não precisa esperar nada nem ninguém para saber tudo sobre a tecnologia que deseja aprender.

Blogs

Outra fonte de consulta muito comum são os blogs. Muitas vezes, eles têm a solução perfeita para o problema que você está tentando resolver, principalmente porque o autor é um programador como você e está postando a solução para poupar horas e fios de cabelo de seus colegas. É um recurso e tanto para tópicos avançados e funcionalidades mal documentadas.

No entanto, mesmo blogueiros que não nasceram em países falantes de língua inglesa costumam escrever seus blogs (muitas vezes apenas) em inglês. O motivo é simples: como há muito mais conteúdo em inglês, há muito mais procura por conteúdo em inglês. Logo, escrever em inglês garante mais visibilidade, mais SEO etc.

O argentino Nicolás Bevacqua e o norueguês Sindre Sorhus são dois exemplos de caras que só escrevem em inglês. E acredite em mim: seria muito mais difícil se esses caras escrevessem em castelhano e norueguês.

Vídeos

Não podemos esquecer do formato mais amado agora que temos uma banda verdadeiramente larga: vídeos. O YouTube, por exemplo, está repleto de ótimos conteúdos que vão desde aulas básicas de programação a screencasts onde você pode ver a tela do programador enquanto ele programa desde hello worlds até soluções super complexas.

Há também TED e TEDx talks, eventos nos quais palestrantes convidados falam de tecnologia, entretenimento e design (a sigla “TED” vem daí) em apresentações extremamente inspiradoras.

Isso não significa que não há conteúdos em vídeo em português. No entanto, só quem domina inglês pode assistir a essas aulas completas de introdução à ciência da computação e programação do MIT, uma das melhores universidades do mundo.

Livros e ebooks

Livros de programação são um pequeno pesadelo para quem só lê em português. Como a tecnologia evolui rápido, os livros de papel e ebooks logo ficam obsoletos. E como as edições em português levam alguns meses para sair, o conteúdo fica desatualizado ainda mais rápido. De quebra, podem surgir algumas pérolas como na tradução do The Lean Startup, que chama framework de “arcabouço”.

Como os brasileiros não gostam de ler, a maioria dos livros de programação nunca ganha uma versão tupiniquim. Isso significa que muitos livros fantásticos como Build APIs You Won’t Hate só estão disponíveis se você dominar inglês.

Quem sabe inglês tem mais opções de mercado

Saber inglês também é uma grande alavanca para o crescimento profissional. Em uma entrevista de emprego, por exemplo, o fato de você saber outro idioma mostra no mínimo que você gosta de aprender, uma habilidade fundamental para quem quer ser um ótimo profissional. Mesmo que a empresa não precise diretamente do seu inglês, você será visto com outros olhos e sairá na frente dos outros candidatos. Ela saberá que você tem uma mentalidade diferente.

E o contrário também acontece: se você disser que não sabe inglês, o recrutador pode pensar que você não gosta de aprender coisas novas e tem um perfil mais acomodado, resistente, que não aceita desafios. E nem pense em mentir que sabe, pois ele pode decidir continuar a entrevista em inglês e aí mesmo é que você não terá chances.

Projetos internacionais

Com inglês, você também pode trabalhar em projetos internacionais sem sair do Brasil. Como a mão de obra brasileira é barata comparada à mão de obra de fora, cada vez mais empresas estrangeiras têm contratado fábricas de software e produtoras para desenvolver seus projetos por aqui. É um nicho de mercado bastante aquecido e sempre há vagas, mas dominar inglês é fundamental para conversar tanto com o cliente quanto com seus colegas de projeto gringos.

A grande vantagem desse tipo de emprego é que a empresa que contrata você recebe em dólar ou euro, ou seja, recebe muito bem. Com isso, ela consegue pagar salários mais generosos e todo mundo sai feliz.

Freela em dólar

Outra opção incrível são as redes de programadores freelancers. A mais famosa é a Toptal, que aprova somente 3% dos engenheiros de software que se candidatam. Porém, antes de qualquer teste técnico, você precisa passar por uma entrevista que avalia se você sabe “ler, escrever e falar inglês extremamente bem”.

Se você passar pelo processo, você escolhe seus freelas e recebe em dólar, uma moeda estável que não é afetada pela economia brasileira e vai lhe garantir certa segurança financeira. No momento em que estou escrevendo, por exemplo, 1 dólar vale R$ 3,24, mas já chegou a valer R$ 4,24 em 2015.

Viver e trabalhar fora

Por último, mas não menos importante, inglês é requisito básico para quem quer viver e trabalhar em outro país. Você precisará dele desde o pedido de um visto de trabalho até sair para comprar pão. Dá um trabalho danado, mas também é muito promissor. Muitos países como o Canadá estão com um déficit muito grande de profissionais qualificados e essa pode ser uma ótima oportunidade para você.

Crescimento pessoal

Quando você aprende inglês, outra pessoa além dos entrevistadores vê que você tem um perfil diferente: você mesmo. Você se sente mais capaz, mais confiante, e com certeza tem uma vida melhor em vários aspectos. Quem consegue aprender uma nova língua consegue aprender qualquer coisa.

Se você ainda não está certo se vale a pena, pense em todo o crescimento pessoal que o inglês vai lhe proporcionar. Imagine como será legal assistir suas séries favoritas sem legenda, entendendo aqueles detalhes que perdem todo o sentido quando são traduzidos para o português. Pense em como será legal ir ao cinema e não ficar tão preocupado em ler as legendas, porque você entende tudo que os atores falam.

Você poderá receber gringos na sua cidade e falar sobre as coisas bacanas que só você conhece, aproveitando a oportunidade para saber mais sobre culturas totalmente diferentes da sua. E você se sentirá seguro para ser esse gringo em qualquer lugar do mundo, pois em todo lugar existe alguém que fala pelo menos um pouco de inglês e pode lhe ajudar com o que for necessário.

E acima de tudo, lembre dos 75x1. Você terá acesso a um mundo de informação e ficará mais claro o quanto você é parte de algo maior, seja a comunidade de tecnologia ou o mundo em si. Ou melhor: o mundo será a sua nova comunidade, e você poderá colaborar tanto com linhas de código em um projeto open source quanto contando para seu novo amigo gringo a dor e a delícia do jeitinho brasileiro.

Conclusão

Vá além do “inglês técnico”. Você pode passar a vida toda praticando o que o inglês instrumental chama de skimming e scanning, ou seja, “pegar a ideia” sem necessariamente entender (ou mesmo ler) todo o conteúdo. Mas só se comprometendo a aprender inglês de verdade é que você perceberá os detalhes que podem mudar completamente o entendimento do que você está lendo.

Não use a evolução dos tradutores automáticos como desculpa para não estudar. Por mais que o Google Translator seja aperfeiçoado, ele sempre saberá apenas o que você escreve e diz, não necessariamente o que você quer dizer.

Treine seu ouvido

Quando ainda somos bebês, nosso cérebro escolhe quais sons devemos reconhecer e reproduzir e ignora todo o resto. E você sabe quais sons ele escolhe? Os sons que ouvimos quando somos bebês: a língua dos nossos pais, muito provavelmente português.

É por isso que muita gente pronuncia “word” quando quer falar “world”, porque o som é estranho demais para os nossos ouvidos. E aqui não existe atalho: só com muito treino conseguimos reeducar nosso cérebro preguiçoso.

E como eu sei disso? Porque vi em um TED talk.

Invista em inglês

Tecnologias nascem e morrem do dia para a noite, mas essa é uma “linguagem” que você usará pelo resto da vida, seja para escrever um código mais coeso, aprender novas linguagens de programação ou conquistar o mundo. Você escolhe.

E olha que legal: você será melhor que muito gringo, porque muitos deles só sabem falar inglês.

PS: o post original é a transcrição de uma palestra dada por Adrian no App Builders Switzerland, em 25 de abril de 2016.

Olá a todos. Eu sou um desenvolvedor autodidata de 42 anos e esta é a minha história.

Algumas semanas atrás eu vi o tweet abaixo e ele me fez pensar sobre minha carreira, e esses pensamentos me levaram de volta aonde tudo começou para mim:

Comecei minha carreira como desenvolvedor de software precisamente às 10:00 do dia 6 de outubro de 1997, uma segunda-feira, em algum lugar na cidade de Olivos, ao norte de Buenos Aires, Argentina. O momento exato era 876142800 Era Unix. Eu recém tinha celebrado meus 24 anos.

O mundo em 1997

O mundo era um lugar ligeiramente diferente naquela época.

Sites não tinham alertas de cookie. O futuro da web eram portais como o Excite.com. Meu buscador preferido era o AltaVista. Meu email era kosmacze@sc2a.unige.ch, o que significava que meu primeiro site pessoal ficava em http://sc2a.unige.ch/~kosmacze. Nós ainda estávamos chorando pela Princesa Diana. Steve Jobs tinha pego o cargo de CEO e convencido a Microsoft a injetar 150 milhões de dólares na Apple Computer. A Digital Equipment Corporation estava processando a Dell. Os restos mortais de Che Guevara recém tinham sido levados de volta a Cuba. A quarta temporada de Friends recém tinha começado. Gianni Versace recém tinha sido assassinado em frente a sua casa. Madre Teresa, Roy Lichtenstein e Jeanne Calment (a pessoa mais velha do mundo) recém tinham falecido. As pessoas estavam jogando Final Fantasy 7 como loucas em seus PlayStation. A BBC 2 começou a passar os Telletubbies. James Cameron estava prestes a lançar Titanic. O The Verve recém tinha lançado seu sucesso “Bitter Sweet Symphony” e então teve que pagar a maior parte dos royalties para os Rolling Stones.

Os smartphones pareciam o Nokia 9000 Communicator. Tinham 8 MB de memória e um CPU i386 de 24 MHz e rodavam o sistema operacional GEOS.

Os smartwatches pareciam o CASIO G-SHOCK DW-9100BJ. Não tinham tantos apps, mas a bateria durava muito mais.

O Deep Blue da IBM tinha derrotado Garry Kasparov pela primeira vez em um jogo de xadrez.

Um hacker conhecido como “_eci” publicou o código C para um exploit de Windows 3.1, 95 e NT chamado “WinNuke”, um ataque de negação de serviço sobre a porta TCP 139 (NetBIOS) que causava a Tela Azul da Morte.

A propósito, 1997 também foi o ano em que Malala Yousafzai, Chloë Moretz e Kylie Jenner nasceram.

Muitos enredos de filmes se passam em 1997. Para citar alguns: Fuga de Nova York, O Predador 2, O Curioso Caso de Benjamin Button, Harry Potter e o Enigma do Príncipe, O Poderoso Chefão III e, de acordo com O Exterminador do Futuro 2: O Julgamento Final, a Skynet se tornou autoconsciente às 2:14 do dia 29 de agosto de 1997. Isso não aconteceu; no entanto, em uma reviravolta interessante de eventos, o domínio google.com foi registrado em 15 de setembro daquele ano.

Nós estávamos a dois anos do Bug do Milênio e a mídia estava começando a deixar as pessoas nervosas com isso.

Meu primeiro trabalho como desenvolvedor

Meu primeiro trabalho consistia em escrever páginas ASP em vários editores, variando do Microsoft FrontPage, para o HotMeTaL Pro, para o EditPlus, cuidando a compatibilidade cross-browser entre o Netscape Navigator e o Internet Explorer 4 e escrevendo stored procedures em SQL Server 6.5 para um site comercial publicado em japonês, russo, inglês e espanhol — sem nenhum suporte consistente a UTF-8 na arquitetura de software.

O produto desses esforços rodava em um servidor Pentium II hospedado em algum lugar dos EUA, com um impressionante HD de 2 GB e colossais 256 MB de RAM. Era um single server rodando Windows NT 4, SQL Server 6.5 e IIS 2.0, servindo cerca de 10 mil visitantes por dia.

Minha primeira linguagem de programação oficial era esse mutante chamado VBScript, e um pouquinho de JavaScript no lado do cliente, é claro, recheado de “se isso for Netscape, então faça aquilo, senão faça aquele outro”, porque naquele tempo eu não tinha a menor ideia de como usar JavaScript apropriadamente.

O interessante é que estamos em 2016 e mal começamos a entender como fazer qualquer coisa em JavaScript.

Ninguém tinha ouvido falar de testes unitários. O Manifesto Ágil ainda não tinha sido escrito. Integração contínua era um sonho. XML não era nem uma palavra da moda. Nossa estratégia de QA consistia em reiniciar o servidor uma vez por semana, porque senão ele dava pau aleatoriamente. Nós desenvolvemos nosso próprio componente COM+ em Visual J++ para interpretar arquivos JPG enviados para o servidor. Assim que começaram a aparecer arquivos codificados com JPEG-2000, nosso componente falhou miseravelmente.

Nós não usávamos controle de versão, nem mesmo CVS, RCS ou, Deus me livre, SourceSafe. Subversion ainda não existia. Nossa pontuação no Joel Test era -25.

6776 dias

Nos últimos 6776 dias eu tenho tomado uma xícara de café pela manhã e escrito código com coisas chamadas VBScript, JavaScript, Linux, SQL, HTML, Makefiles, Node.js, CSS, XML, .NET, YAML, Podfiles, JSON, Markdown, PHP, Windows, Doxygen, C#, Visual Basic, Visual Basic.NET, Java, Socket.io, Ruby, testes unitários, Python, scripts shell, C++, Objective-C, arquivos batch e, recentemente, Swift.

Nesses 6776 dias muitas coisas aconteceram; mais importante, minha esposa e eu nos casamos. Pedi demissão de 6 empregos e fui demitido duas vezes. Comecei e fechei meu próprio negócio. Concluí meu mestrado. Publiquei alguns projetos open source, e um deles me rendeu um artigo no Ars Technica escrito pela própria Erica Sadun. Apareci em programas de TV suíços e bolivianos. Vi palestras de Bill Gates e Steve Jobs em Seattle e São Francisco. Palestrei e coorganizei conferências em quatro continentes. Escrevi e publiquei dois livros. Tive dois burnouts e muitas outras coisas aconteceram, tanto maravilhosas quanto horríveis.

Já pensei várias vezes em abandonar completamente a profissão. Mas de alguma forma, o código sempre me chama de volta depois de algum tempo. Eu gosto de escrever apps, sistemas, software. Tive que desenvolver estratégias para evitar burnouts.

Nessa palestra eu vou contar meus segredos para que vocês também possam chegar à gloriosa idade de 40 anos como um desenvolvedor experiente, com vontade de continuar nessa profissão.

Conselhos de um jovem de espírito

Algumas dicas simples para chegar à gloriosa idade de 40 anos como um feliz desenvolvedor de software.

1. Esqueçam as modinhas

O primeiro conselho que eu posso dar a vocês todos é: não prestem atenção às modinhas. Todo ano há uma nova linguagem de programação, framework, biblioteca, padrão, arquitetura de componentes ou paradigma que conquista a blogosfera. Pessoas enlouquecem com isso. Conferências são dadas. Livros são escritos. Ciclos do Gartner sobem e descem. Consultores cobram quantidades insanas de dinheiro para ensinar, implantar ou quando não para foder com as vidas das pessoas nessa indústria. A imprensa irá apoiar esses horrores e vai fazer vocês se sentirem culpados se não prestarem atenção a eles.

Em 1997 era CORBA & RUP.

Em 2000 era SOAP & XML.

Em 2003 era Model Driven Architecture e Software Factories.

Em 2006 era Web Semântica e OLPC.

Em 2009 era Realidade Aumentada.

Em 2012 era Big Data.

Em 2015… Realidade Virtual? Bots?

Não se preocupem com o hype. Continuem fazendo suas coisas, continuem aprendendo o que vocês estavam aprendendo e sigam em frente. Prestem atenção só se tiverem um interesse genuíno ou sentirem que isso pode lhes trazer algum benefício a médio ou longo prazo.

De fato, a razão para essas mentiras, como os romanos diziam no passado, é que nihil sub sole novum. A maior parte do que vocês veem e aprendem em Ciência da Computação está por aí há décadas, e esse fato é escondido de propósito debaixo de pilhas de marketing, livros, posts em blogs e perguntas no Stack Overflow. Toda nova arquitetura é apenas uma reimaginação e uma readaptação de uma ideia que estava por aí há décadas.

2. Escolham sua galáxia com sabedoria

Na nossa indústria, toda tecnologia gera o que eu chamo de “galáxia”. Essas galáxias têm estrelas e também buracos negros; mudanças meteóricas que desaparecem na noite, muitos planetas, dos quais apenas uma pequena fração abriga alguma forma de vida, e um monte de poeira cósmica e matéria escura.

Exemplos de galáxias são .NET, Cocoa, Node.js, PHP, Emacs, SAP etc. Cada uma dessas tem seus evangelistas, desenvolvedores, blogueiros, podcasts, conferências, livros, cursos, serviços de consultoria e problemas de inclusão. Galáxias são construídas sobre a suposição de que sua tecnologia é a resposta para todos os problemas. Cada galáxia, portanto, é baseada numa suposição errada.

Os desenvolvedores dessas diferentes galáxias incorporam as atitudes arquetípicas que trouxeram aquela tecnologia à vida. Eles aderem às ideias e vão vestir as camisetas com entusiasmo e evangelizar outros sobre os méritos da sua escolha.

Na verdade, eu uso o termo “galáxia” para evitar o levemente mais apropriado, se não menos controverso, termo “religião”, que deve descrever melhor esse fenômeno.

No meu caso, gastei os primeiros 10 anos da minha carreira na galáxia Microsoft, e os nove seguintes na galáxia Apple.

Me arrisco a dizer que uma das maiores razões por que eu troquei de galáxia foi Steve Ballmer. Eu cansei da atitude geral das pessoas da galáxia Microsoft contra o software open source.

Por outro lado, eu também tenho que dizer que a galáxia Apple é um lugar fantástico, cheio de artistas e músicos e escritores que, por sorte ou azar, também escrevem código.

Eu fui a conferências na galáxia Microsoft, como o Barcelona TechEd 2003, ou vários Tech Talks em Buenos Aires, Genebra ou Londres. Eu até palestrei no Microsoft DevDays 2006, em Genebra. A atitude geral dos desenvolvedores na galáxia Microsoft é antipática, “corporativa” e presa a sigilos, NDAs e processos bizarros de TI.

A galáxia Apple foi para mim, lá em 2006, exatamente o contrário; estava cheia de pessoas que eram musicistas, artistas, pintores; escreviam software para ajudar sua paixão e escreviam software com paixão. Isso fez toda a diferença e até hoje curto tremendamente essa galáxia, a que estamos, exatamente agora, e que nos juntou.

E então o iPhone surgiu, e o resto é história.

Então minha recomendação para vocês é: escolham sua galáxia com sabedoria, curtam o quanto quiserem, mas mantenham seu telescópio apontado na direção de outras galáxias, e se preparem para se transportar a outros lugares se for necessário.

3. Estudem a história do software

Isso me leva ao próximo ponto: estudem como sua tecnologia favorita surgiu. Vocês gostam de C#? Vocês sabem quem o criou? Como surgiu o projeto .NET? Quem era o arquiteto líder? Quais eram as limitações do projeto e como a linguagem se tornou o que é hoje?

Apliquem a mesma receita a qualquer linguagem ou arquitetura de CPU que vocês curtam ou amem: Python, Ruby, Java, qualquer que seja a linguagem de programação; estudem suas origens, como elas surgiram. O mesmo para sistemas operacionais, tecnologias de rede, hardware, qualquer coisa. Vão e estudem como as pessoas apareceram com essas ideias, e quanto demorou para elas crescerem e amadurecem. Porque bom software leva dez anos, vocês sabem.

The mobile phone evolution @ValaAfshar pic.twitter.com/ShP206GiYL

— JM Alvarez-Pallete (@jmalvpal) November 26, 2015

As histórias que cercam a gênese da nossa indústria são fascinantes e lhes mostrarão duas coisas: primeiro, que tudo é um remix. Segundo, que poderiam ser vocês remixando a próxima tendência. Não, melhor: serão vocês os criadores da próxima tendência.

E para ajudar vocês a chegarem lá, aqui está minha (altamente tendenciosa) seleção de livros de história que eu gosto e recomendo:

• Dealers of Lightning, de Michael A. Hiltzik
• Revolution in the Valley, de Andy Hertzfeld
• A Catedral e o Bazar, de Eric S. Raymond
• The Success of Open Source, de Steven Weber
• The Old New Thing, de Raymond Chen
• The Mythical Man Month, de Frederick P. Brooks Jr.

Vocês também aprenderão a valorizar aquelas coisas que passaram pelo teste do tempo: Lisp, TeX, Unix, bash, C, Cocoa, Emacs, Vim, Python, ARM, GNU make, man pages. Esses são exemplos de coisas úteis que duram muito e são algo para celebrar, proteger e aprender.

I felt like saying this. pic.twitter.com/mHJ1rENoX1

— Hisham (@hisham_hm) December 13, 2015

4. Continuem aprendendo

Aprendam. Vale qualquer coisa. Querem aprender Fortran? Vão em frente. Acham Erlang interessante? Excelente. Pensam que COBOL pode ser a próxima tendência nas suas carreiras? Fantástico. Precisam saber mais sobre Programação Funcional Reativa? Fiquem à vontade. Design? É claro. UX? Vocês devem. Poesia? Vocês deveriam.

Muitos conceitos comuns na Ciência da Computação estão por aí há décadas, o que faz valer a pena estudar velhas linguagens de programação e frameworks, mesmo que tenham caído em desuso. Primeiro, vai fazer vocês valorizarem o estado atual da indústria (ou odiar, depende), e segundo, vocês aprenderão como usar as ferramentas atuais com mais efetividade — no mínimo, porque vocês entenderão seu legado e suas origens.

Dica 1: aprendam pelo menos uma nova linguagem de programação todo ano. Eu não tive essa ideia; ela é do livro The Pragmatic Programmer. E funciona.

Uma nova linguagem de programação todo ano. Simples, não? Vão além do típico estágio do “Hello, World” e construam algo útil com ela. Eu geralmente construo uma calculadora simples com qualquer nova tecnologia que eu aprenda. Me ajuda a entender a sintaxe, ficar familiarizado com as APIs ou a IDE etc.

Dica 2: leiam pelo menos 6 livros por ano. Eu mostrei acima uma lista de seis livros que vocês devem ler; isso deve manter vocês ocupados por um ano. Aqui está a lista para o segundo ano:

• Peopleware, de Tom DeMarco e Tim Lister
• The Psychology of Software Programming, de Gerald M. Weinberg
• Facts and Fallacies of Software Engineering, de Robert L. Glass
• O Design do Dia-a-dia, de Don Norman
• Agile!: The Good, the Hype and the Ugly de Bertrand Meyer
• Rework, de Jason Fried e David Heinemeier Hansson
• Geekonomics, de David Rice

(OK, são sete livros.)

Seis livros por ano parece muito, mas significa apenas um a cada 2 meses. E a maioria dos livros que eu mencionei nessa apresentação não são tão longos, e melhor, são extraordinariamente bem escritos, divertidos de ler e cheios de sabedoria.

Veja desta forma: se vocês têm 20 anos agora, com 30 vocês terão lido mais de 60 livros, e mais de 120 quando vocês tiverem a minha idade. E vocês terão brincado com pelo menos 20 linguagens de programação diferentes. Pensem nisso por um segundo.

Alguns dos doze livros que eu selecionei foram escritos nos anos setenta, outros nos oitenta, alguns nos noventa e, por fim, a maioria deles são da última década. Eles representam o que de melhor foi escrito sobre a nossa indústria.

Mas não apenas os leiam; tomem notas. Marquem as páginas. Escrevam nas páginas dos livros. Então os releiam de vez em quando. Borges costumava dizer que um prazer maior que ler um livro é relê-lo. E também, por favor, comprem aqueles livros que vocês realmente gostam em papel. Ebooks são superestimados. Nada supera um livro de papel.

É claro, por favor entendam que quando vocês envelhecerem, o número de coisas classificadas como novas e/ou importantes vai cair dramaticamente. Se preparem para isso. E está tudo bem se vocês derramarem uma lágrima quando se derem conta disso.

If I could go back in time and tell the younger me exactly one and only one thing, it would be "learn UNIX"

— Jeff Atwood (@codinghorror) February 4, 2016

5. Ensinem

Quando vocês tiverem aprendido, ensinem. Isso é muito importante.

Isso não significa que vocês devam organizar uma sala de aula e convidar pessoas para ouvir suas divagações (apesar de que seria incrível se vocês organizassem!). Isso pode significar simplesmente vocês darem respostas relevantes no Stack Overflow, escreverem um livro, publicarem um podcast sobre a sua tecnologia favorita, manterem um blog, escreverem no Medium, irem a outro continente e organizarem escolas de programação usando Raspberry Pis ajudarem um desenvolvedor mais jovem virando seu mentor (mas não façam isso antes dos 30).

Ensinar vai fazer vocês serem mais humildes, porque vai mostrar dolorosamente o quão limitado seu conhecimento é. Ensinar é a melhor forma de aprender. Apenas testando seu conhecimento com outros vocês aprenderão direito. Isso também vai fazer vocês serem mais respeitosos em relação a outros desenvolvedores e outras tecnologias; toda tecnologia, não importa quão modesta ou obsoleta, tem seu lugar no Tao da Programação, e somente através do ensino vocês serão capazes de sentí-la.

E através do ensino vocês realmente, realmente podem fazer a diferença nesse mundo. Em 2012 eu recebi um email de uma pessoa que tinha ido a um dos meus treinamentos. Ela costumava trabalhar como desenvolvedora Flash. Lembra do ActionScript e tudo aquilo? Bem, como era esperado, ela se viu desempregada após 12 anos trabalhando como desenvolvedora Flash freelancer. Sozinha. Com um bebê para alimentar. Ela me disse em sua mensagem que tinha ido ao meu treinamento, que tinha curtido e também aprendido algo útil, e que depois daquilo tinha achado um emprego como mobile web developer. Ela me escreveu para dizer obrigado.

Não posso dizer que eu mudei o mundo, mas talvez eu o tenha empurrado um pouquinho para uma direção (espero) melhor. Esse pensamento tem feito cada aula que eu dou desde então mais valiosa e significativa.

6. Escritórios são um saco

Every day, with every action and choice, you're either a teacher and an inspiration, or a lesson and a reminder.

— Cat Swart (@Jexx) May 25, 2015

Não esperem que empresas de software ofereçam qualquer tipo de plano de carreira. Eles podem fazer isso nos EUA, mas nunca vi nada disso na Europa. Isso significa que vocês são os únicos responsáveis pelo sucesso das suas carreiras. Ninguém vai dizer “ah, bem, ano que vem vocês podem crescer para ser líderes de time, então gerentes, então CTOs…”.

Nem. A. Pau. Muito pelo contrário, na verdade: vocês são, sempre foram e sempre serão desenvolvedores de software, ou seja, trabalhadores de fábrica relativamente caros, cujas tarefas seus gerentes ficariam felizes em terceirizar, não importa o que eles digam.

Não aceitem um emprego somente pelo dinheiro. Empresas de software se tornaram fábricas exploradoras onde vocês supostamente têm que justificar seu salário absurdamente alto com uma carga horária insana e expectativas irreais. E, pelo menos no caso da Suíça, não há sindicato para ajudá-los se a coisa ficar feia. Na verdade até há sindicatos na Suíça, mas eles não se importam muito com situações que não levarão a nenhum tipo de exposição na mídia.

Pior ainda; na maioria dos ambientes de trabalho vocês serão assediados, especialmente se forem mulheres, membros da comunidade LGBT ou não forem brancos. Eu vi desenvolvedores serem ameaçados de não terem seus vistos de trabalho renovados se não trabalhassem mais rápido. Eu testemunhei colegas mulheres e gays serem assediados.

Algumas partes da nossa indústria são completamente nojentas, e vocês não precisam estar no Vale do Silício para viver isso. Vocês não precisam do Medium para ler sobre. Vocês podem experimentar isso aqui mesmo na Suíça. Muitos bancos têm ambientes de trabalho atrozes. Instituições financeiras querem que vocês vomitem código 15 horas por dia, mesmo que as leis trabalhistas da Suíça proíbam explicitamente tais tratamentos. Companhias farmacêuticas querem que vocês escrevam códigos para fraudar resultados de testes e ajudá-las a escapar de regulamentações. Startups querem a sua pele, trabalhando 18 horas sem nenhuma compensação, lhes dizendo bobagens como “porque lhe damos stock options” ou “porque todos nós somos membros de um time”.

Não importa se vocês são Zach Holman e podem dizer no seu CV que literalmente escreveram o Github do zero: vocês serão demitidos pela mais estúpida das razões.

Não importa que o app traga mais da metade do tráfego e receita do seu empregador; o time de API vai tratar vocês e suas ideias com desprezo e desleixo.

Pessoas muito conhecidas na indústria, inclusive com página na Wikipedia, têm pedido que eu trabalhe de graça, e isso é simplesmente apavorante. Eu não vou dar seus nomes, mas vou prevenir qualquer júnior de chegar perto delas, porque pessoas que trabalham sem ética não merecem o cérebro de ninguém.

Sempre que um gerente de RH diz que “vocês devem fazer isso (qualquer coisa errada no seu entendimento) porque nós pagamos seu salário”, lembrem de responder o seguinte: “você paga o meu salário, mas eu dou meu cérebro em troca, e eu me recuso a obedecer essa ordem”.

E acima de tudo, eles colocarão vocês em um espaço aberto, e por alguma razão terão orgulho disso. Espaços abertos são um câncer. Eles são sem dúvida o pior layout de escritório possível já inventado, e o menos apropriado para desenvolvimento de software — ou qualquer tipo de trabalho intelectual que importe.

Lembre-se disso: o fato de vocês entenderem alguma coisa não significa que vocês devam concordar com ela.

Desobedeçam autoridades. Digam “foda-se, eu não vou fazer o que você me diz” e mudem de emprego. Há ambientes de trabalho fantásticos lá fora; não muitos, mas existem. Eu tive a sorte de trabalhar em alguns deles. Não deixem que um emprego ruim mate seu entusiasmo. Não vale a pena. Desobedeçam e vão em frente.

Ou, melhor ainda, tornem-se independentes.

Myth: Open offices result in massive collaboration.

Reality: 2 people loudly collaborate; 30 must wear headphones to get any work done.

— Jochen Wolters (@jochenWolters) April 7, 2016

7. Saibam seu valor

Vocês provavelmente ouviram sobre o mito do “Engenheiro de Software 10x”, certo? Bem, aqui está: não é um mito, mas ele não funciona como vocês pensam.

Ele funciona do ponto de vista do empregador: um “Engenheiro de Software 10x” gera um valor 10 vezes maior do que o que o empregador paga. Isso significa que se ela ou ele ganha 100 KCHF por ano, ela ou ele está na verdade gerando um valor acima de um milhão de francos. E é claro que eles ganham os bônus no final do ano fiscal, porque, vocês sabem, capitalismo. Saibam seu valor. Leiam Karl Marx e Thomas Piketty. Tenho dito.

Sigam andando; sejam como o tubarão que continua nadando, porque suas habilidades são extremamente valiosas. Falem seus salários, falem alto, postem sobre isso, para que seus colegas saibam o quanto o trabalho deles vale. As empresas querem que vocês se calem sobre isso para que mulheres recebam 70% do que é pago aos homens. Então falem! Postem sobre isso! Tuítem! Eu estou ganhando 135 KCHF por ano. Esse é meu salário atual. Que tal vocês? E vocês? Quanto mais falarmos, menor será a desigualdade. Qualquer pessoa fazendo meu trabalho com a minha experiência deve ganhar o mesmo dinheiro, independentemente de raça, sexo, idade ou time do coração. Fim de papo. Mas não é assim. Não é.

A customer walks into a bar. He asks for a beer made out of wine. The project manager agrees. Both question the bartender's competence.

— Daniel Méndez (@mendezfe) March 22, 2015

8. Ajudem os outros

Se vocês são homens brancos, lembrem de todos os privilégios que vocês desfrutaram desde o nascimento simplesmente porque vocês nasceram assim. É sua responsabilidade mudar a indústria e seus preconceitos para gerar mais inclusão social.

É seu dever ajudar os outros.

Tomem decisões conscientes na sua vida. Estejam cientes das suas ações e das suas consequências. Não fiquem vermelhos ou envergonhados por mudar suas opiniões. Digam “me desculpe” quando for preciso. Ouçam. Não sejam espertalhões. Tenham integridade e amor-próprio.

Não critiquem ou tirem sarro das escolhas tecnológicas dos seus colegas, porque outras pessoas terão suas razões para escolhê-las e devem ser respeitadas. Estejam preparados para mudar de ideia a qualquer momento através do aprendizado. Um dia vocês podem gostar de Windows. Um dia vocês podem gostar de Android. Eu mesmo estou gostando de algumas coisas do Android ultimamente. E isso é OK.

Desirable developer skills:

1 Ability to ignore new tools and technologies
2 Taste for simplicity
3 Good code deletion skills
4 Humility

— David Winterbottom (@codeinthehole) December 3, 2014

9. LLVM

Todo mundo está falando sobre Swift, mas na realidade o que eu mais presto atenção nesses dias é o LLVM em si.

Eu acho que o LLVM é o projeto de software mais importante hoje, considerando seu impacto de longo prazo. Objective-C blocks, Rust & Swift (as duas linguagem de programação fortemente tipadas e compiladas mais amadas na pesquisa de desenvolvimento do Stack Overflow em 2016), Dropbox Pyston, o Clang Static Analyser, ARC, Google Souper, Emscripten, LLVMSharp, Microsoft LLILC, Rubymotion, cheerp, apps watchOS, o Android NDK, Metal, todas essas coisas surgiram ou só foram possíveis pelo LLVM. Há compiladores usando LLVM como backend para praticamente todas as linguagens mais importantes da atualidade. O .NET CLR eventualmente vai interoperar com ele; o Mono já usa. O Facebook tentou integrar o LLVM com a HHVM e o WebKit migrou recentemente seu compilador JavaScript do LLVM para o novo JIT B3.

LLVM é multiplataforma, multiarquitetura de CPU, multilinguagem, multicompilador, multitestado, grátis como a cerveja e livre como os pássaros.

Aprendam tudo que puderem sobre LLVM. Essa é a galáxia onde a verdadeira inovação está acontecendo agora. Esse é o alicerce dos próximos 20 anos.

@owensd Java is 20 years old, C# is 15 - I think it is better to see Swift as a response to that sort of managed language (the next step?)

— Chris Lattner (@clattner_llvm) February 18, 2015

10. Siga sua intuição

Tive a sensação de que o .NET seria grande quando vi sua apresentação em junho de 2000. Tive a sensação de que o iPhone seria grande quando vi sua apresentação em 2007.

Em ambos os casos as pessoas riram de mim, literalmente. Em ambos os casos eu segui minha intuição e acho que não fui tão mal.

Sigam sua intuição. Vocês também podem se dar bem.

Follow your heart
Follw yur heart
Fllw yr hart
Fw y art
Fart

— Daniel Kibblesmith ☃️ (@kibblesmith) November 17, 2014

11. APIs são rei

Grandes APIs possibilitam grandes apps. Se a API é um desastre, o app será um desastre também, não importa o quão bonito seja o design.

Lembrem que “chunky” é melhor que “chatty” (ou seja, é melhor enviar muita informação com pouca frequência que pouca informação com muita frequência) e que clientes devem ser burros; coloquem o máximo de lógica que vocês puderem na API.

Não inventem seus próprios protocolos de segurança.

Aprendam algumas tecnologias server-side, e se certifiquem de que Node seja uma delas.

Deixem o REST de lado e abracem Socket.io, ZeroMQ, RabbitMQ, Erlang, XMPP; encarem realtime como o próximo passo no desenvolvimento de apps. Realtime não é apenas para apps de chat. Tirem o polling da equação para sempre.

Ah, e comecem a construir bots sobre essas APIs. Conselho de amigo.

12. Combatam a complexidade

Mais simples é melhor. Lembrem do princípio KISS. E eu não quero dizer apenas na camada de UI, mas em tudo, até as camadas mais profundas do seu código.

Refactoring, testes unitários, revisões de código, pull requests, todas essas ferramentas estão à sua disposição para garantir que o código que vocês publiquem seja a arquitetura funcional mais simples possível. É assim que se constrói sistemas resilientes de longo prazo.

"Ok, let's make a rails app"
"Oh, I need rails first"
"Oh, I need rbenv first"
"Oh I need brew"
"Oh I need xcode tools"
... rage.

— Matthew Jewell (@mattisfrommars) January 22, 2015

Conclusão

A coisa mais importante para lembrar é que sua idade não importa.

Um dos meus filhos disse para mim “Impossível, papai. Matemáticos fazem todos os seus melhores trabalhos até os 40 anos. E você tem mais de 80. É impossível para você ter uma boa ideia agora.”
Se você ainda estiver mentalmente desperto e alerta quando você tiver mais de 80, você tem a vantagem de ter vivido um longo tempo e ter visto muitas coisas, e você ganha perspectiva. Eu tenho 86 anos agora, e foi nos últimos anos que tive essas ideias. Novas ideias surgem e você pega partes daqui e dali, e agora é a hora propícia de colher, enquanto poderiam não estar maduras cinco ou 10 anos atrás.

— Michael Atiyah, matemático ganhador da Medalha Fields e do Prêmio Abel, citado em um artigo da Wired.

Enquanto seus corações lhe disserem para continuar codificando e construindo novas coisas, vocês serão jovens, para sempre.

Em 2035, exatamente daqui a 19 anos, alguém vai dar uma palestra em uma conferência de software parecida com essa, começando assim:

“Olá, eu tenho 42 anos, e esta é a minha história.”

Tomara que seja um de vocês dando essa palestra; caso contrário, será um bot com inteligência artificial. Vocês darão alguns fatos curiosos sobre 2016, como, por exemplo, que esse foi o ano em que morreram David Bowie, Umberto Eco, Gato Barbieri e Johan Cruyff, ou que o SQL Server foi disponibilizado para Linux, ou que o Google AlphaGo bateu um campeão de Go, ou que os Papéis do Panamá e o Turkish Citizenship Database foram vazados no mesmo dia, ou que o Google considerou usar Swift para o Android pela primeira vez, ou que foi o último ano no qual as pessoas aproveitaram essa coisa inútil chamada privacidade.

Nós estaremos a três anos do Problema do Ano 2038 e pessoas ficarão bem nervosas com isso.

É claro que eu não sei o que acontecerá daqui a 19 anos, mas eu posso dizer a vocês três coisas que acontecerão com certeza:

1. Alguém vai perguntar no Stack Overflow como filtrar endereços de email usando expressões regulares.
2. Alguém vai lançar um novo framework JavaScript.
3. Alguém vai construir alguma coisa legal usando LLVM.

E talvez vocês lembrem dessa palestra com um sorriso.

Muito obrigado pela atenção.