Sendo desenvolvedor depois dos 40

Essa é a tradução de um post sensacional de Adrian Kosmaczewski chamado Being A Developer After 40. Quero que mais desenvolvedores e aspirantes a desenvolvedor, mesmo os que não dominam inglês, consigam aproveitar esses ótimos conselhos.

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:

Original: http://www.smbc-comics.com/index.php?db=comics&id=2436

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.

Excite em 1997, cortesia -do Internet Archive

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.

O pônei diz “nada é tão simples como parece no começo, sem solução como parece no meio ou acabado como parece no fim”

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.

Um cruzamento britânico com 6 rotatórias e 38 setas

"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.