Você está na página 1de 12

Sendo desenvolvedor depois dos 40

lfbittencourt.com /sendo-desenvolvedor-depois-dos-40-db274feb9445

14/09/2016

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:

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.

1/12
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
2/12
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.

3/12
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
4/12
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.

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:

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.

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
5/12
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.

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).
6/12
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

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

7/12
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.

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

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.

8/12
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”

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.
9/12
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.

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.

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

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:

11/12
“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.

12/12

Você também pode gostar