Como aprender a programar e conseguir um emprego como desenvolvedor [livro completo]

Artigo original: How to Learn to Code and Get a Developer Job [Full Book]

Se você quer aprender a programar e conseguir um emprego como desenvolvedor, você está no lugar certo. Este livro vai mostrar a você como fazer isso.

Sim, este é o livro completo – de graça – bem aqui, nesta página do freeCodeCamp.

Além disso, gravei uma versão completa em audiolivro GRATUITA deste livro (em inglês), que publiquei como o episódio de número 100 do podcast do freeCodeCamp. Você pode procurá-lo no seu player de podcast favorito. Não se esqueça de se inscrever. Também adicionei o episódio logo abaixo para sua conveniência.

Há alguns anos, uma das cinco maiores editoras de livros de Nova York entrou em contato comigo sugerindo um contrato para que eu escrevesse um livro. Eu me encontrei com eles, mas não tinha tempo para escrever um livro.

Bem, agora eu finalmente tive tempo e decidi simplesmente publicar este livro de graça, bem aqui no freeCodeCamp.

A informação merece ser livre, certo? 🙂

Você levará algumas horas para ler todo ele. São minhas percepções sobre como aprender a programar e sobre conseguir um emprego como desenvolvedor.

Eu aprendi tudo isso enquanto:

aprendia a programar aos 30 anos de idade
trabalhava como engenheiro de software
e, por fim, dirigia o freeCodeCamp.org, o que venho fazendo nos últimos oito anos. Hoje, mais de um milhão de pessoas visitam este site todos os dias para aprender sobre matemática, programação e ciência da computação.

Eu era um professor de inglês que nunca havia programado antes. Consegui aprender o suficiente sobre programação para arranjar meu primeiro emprego como desenvolvedor de software em apenas um ano.

Tudo isso sem gastar dinheiro em livros ou cursos (eu gastei dinheiro, sim, para viajar para cidades próximas e participar de eventos de tecnologia. Como você verá mais adiante no livro, esse foi um dinheiro bem gasto).

Depois de trabalhar como engenheiro de software por alguns anos, eu me senti pronto. Queria ensinar outras pessoas a fazer essa transição de carreira também.

Criei várias ferramentas de educação tecnológica as quais ninguém estava interessado em usar. Foi então que, em um fim de semana, criei o freeCodeCamp.org. Uma comunidade ativa rapidamente se formou em torno dele.

Ao longo do caminho, todos nós ajudamos uns aos outros. Hoje, pessoas em todo o mundo usam o freeCodeCamp para se preparar para seu primeiro emprego em tecnologia.

Você pode estar pensando: não sei se tenho tempo para ler todo este livro.

Sem problemas. Você pode marcá-lo como favorito. Pode voltar a ele e lê-lo em quantas sessões precisar.

Você também pode compartilhá-lo nas redes sociais. Diga aos outros: "dê uma olhada neste livro que estou lendo". Compartilhe o link dele. É uma maneira surpreendentemente eficaz de convencer a si mesmo a terminar de ler um livro.

Digo isso porque não estou tentando vender a você este livro. Você já "comprou" este livro quando abriu esta página da web. Agora, meu objetivo é tranquilizá-lo de que será um bom investimento de seu tempo terminar de lê-lo. 😉

Prometo respeitar o seu tempo. Não há exagero ou enfeite aqui – apenas dicas diretas e práticas.

Vou incluir o máximo de percepção possível em cada capítulo deste livro.

O que me lembra: onde está o índice?

Ah, está aqui:

Índice

Prefácio: para quem é este livro?

Este livro é para qualquer pessoa que esteja considerando uma carreira em desenvolvimento de software.

Se você está procurando uma carreira que seja flexível, bem remunerada e que envolva muita resolução criativa de problemas, o desenvolvimento de software pode ser para você.

Claro, cada um de nós aborda sua própria jornada em programação com certos recursos: tempo, dinheiro e oportunidade.

Você pode ser mais velho e ter filhos ou pais idosos de quem cuida. Então, você pode ter menos tempo.

Você pode ser mais jovem e não ter tido tempo suficiente para economizar ou adquirir habilidades que aumentem sua renda. Então, você pode ter menos dinheiro.

Você também pode morar longe das principais cidades da tecnologia, como São Francisco, Berlim, Tóquio ou Bengaluru.

Você pode ter de viver com empecilhos, físicos ou mentais. O preconceito com a idade, o racismo e o sexismo são reais. O status de imigração pode complicar a busca por emprego, assim como antecedentes criminais.

Em resumo: você pode ter menos oportunidades.

Aprender a programar e conseguir um emprego como desenvolvedor será mais difícil para algumas pessoas do que para outras. Todos abordam esse desafio a partir de seu próprio ponto de partida, com os recursos que tiverem à mão.

Independentemente de onde você esteja começando, no entanto – em termos de tempo, dinheiro e oportunidade – farei o meu melhor para dar a você conselhos práticos.

Uma nota rápida sobre terminologia

Sempre que eu usar termos novos, farei o máximo para defini-los.

Há alguns termos, porém, que direi o tempo todo.

Usarei a palavra "programação" tanto no sentido amplo ("programming", em inglês), como no sentido estrito ("coding", em inglês) de modo intercambiável.

Usarei a palavra "app" como se planejou usá-la originalmente – como uma abreviação para qualquer tipo de aplicação, independentemente de rodar em um telefone, laptop, console de jogos ou geladeira (perdão, Steve Jobs, mas o iPhone não tem monopólio sobre a palavra app).

Também usarei as palavras "engenheiro de software" e "desenvolvedor de software" de modo intercambiável.

Você pode encontrar pessoas na tecnologia que não concordam com isso. Como se engenharia de software fosse algum campo chique com um legado multicentenário, como são a engenharia mecânica ou a engenharia civil. Quem sabe – talvez isso seja verdade para seus netos. Agora, porém, ainda estamos nos primeiros dias do desenvolvimento de software como um campo.

Vou deixar esta citação aqui para você, caso se sinta desconfortável em se chamar de engenheiro de software:

"Se os construtores construíssem edifícios como os programadores escrevem programas, o primeiro pica-pau que aparecesse destruiria a civilização." – Gerald Weinberg, programador, autor e professor universitário

Qualquer pessoa pode aprender a programar?

Sim. Eu acredito que qualquer pessoa suficientemente motivada pode aprender a programar. No final das contas, aprender a programar é um desafio motivacional – não é uma questão de aptidão.

Nas savanas da África – onde os primeiros humanos viveram por milhares de anos antes de se espalharem pela Europa, Ásia e América – havia computadores?

Habilidades de programação nunca foram algo selecionado ao longo dos milênios. Computadores como os conhecemos (desktops, laptops, smartphones) surgiram nos anos 1980, 1990 e 2000.

Sim – eu acredito que a aptidão desempenha um papel. Porém, no final, qualquer pessoa que queira se tornar um desenvolvedor profissional precisará passar tempo no teclado.

A grande maioria das pessoas que tenta aprender a programar ficará frustrada e desistirá.

Eu, certamente, desisti. Fiquei frustrado e desisti várias vezes.

Como outras pessoas que no fim tiveram sucesso, no entanto, continuei voltando depois de alguns dias e tentava novamente.

Eu digo tudo isso porque quero reconhecer: aprender a programar e conseguir um emprego de desenvolvedor é difícil, ainda mais para algumas pessoas do que para outras, devido às circunstâncias.

Não vou fingir ter enfrentado verdadeiras dificuldades ao aprender a programar. Sim, eu estava na casa dos 30 anos e não tinha formação formal em programação ou ciência da computação, mas considere isto:

Eu cresci na classe média nos Estados Unidos – um americano de 4ª geração de uma casa de língua inglesa. Eu fui para a universidade. Meu pai foi para a universidade. O pai dele foi para a universidade (os pais dos pais dele eram fazendeiros na Suécia),

Eu me beneficiei de uma espécie de privilégio intergeracional. Um impulso que algumas famílias são capazes de captar ao longo do tempo quando não são dilaceradas por guerra, fome ou escravidão.

Então, esse é meu grande aviso para você: eu não sou uma figura motivacional para incentivar a superar as adversidades.

Se você precisa de inspiração, há muitas pessoas na comunidade de desenvolvedores que superaram adversidades reais. Você pode procurá-las.

Não estou tentando elevar o campo do desenvolvimento de software. Não vou pintar quadros de utopias de ficção científica que podem surgir se todos aprenderem a programar.

Em vez disso, vou apenas dar dicas práticas de como você pode adquirir essas habilidades e de como você pode conseguir um bom emprego, para que possa sustentar sua família.

Não há nada de errado em aprender a programar porque você quer um bom e estável emprego.

Não há nada de errado em aprender a programar para que você possa começar um negócio.

Você pode encontrar pessoas que dizem que você deve ser tão apaixonado por programação a ponto de sonhar com isso, que você se desligue do seu trabalho de tempo integral e passe o fim de semana todo contribuindo para projetos de código aberto.

Eu conheço pessoas que são muito apaixonadas por programação. Conheço também muitas pessoas que, após uma semana de trabalho árduo, só querem passar um tempo nos parques ou jogar jogos de tabuleiro com amigos.

As pessoas geralmente gostam de fazer coisas em que são boas. Você pode desenvolver um nível razoável de paixão por programação apenas melhorando nela.

Então, resumindo: para quem é este livro? Para quem quer ficar melhor em programação e conseguir um emprego como desenvolvedor. Pronto.

Você não precisa se autodeclarar um "geek", ser um introvertido ou um ativista ideologicamente motivado. Nenhum desses estereótipos é necessário.

Se você for um desses, está ok, mas você não precisa ser.

Então, se é esse o seu caso – se você está seriamente pensando em aprender a programar o suficiente para ser pago para programar – este livro é para você.

Comece lendo este resumo rápido do livro. Depois, leia o resto.

Resumo em 500 palavras

Aprender a programar é difícil. Conseguir um emprego como desenvolvedor de software é ainda mais difícil. Para muitas pessoas, porém, vale o esforço.

A programação é um campo bem pago, intelectualmente desafiador e criativamente recompensador. Há uma progressão clara de carreira à sua frente: desenvolvedor sênior, líder técnico, gerente de engenharia, CTO e, talvez, até CEO.

Você pode encontrar trabalho em praticamente qualquer setor. Cerca de dois terços dos empregos de desenvolvedores estão fora do que tradicionalmente chamamos de área da "tecnologia" – em agricultura, manufatura, no governo e nos setores de serviços, como bancos e saúde.

A automação vai impactar a programação. Já impacta há décadas.

Ferramentas de IA generativa, como o GPT-4 e o Copilot, podem nos ajudar a passar da Programação Imperativa – onde você diz exatamente o que os computadores devem fazer – para a Programação Declarativa – onde você dá aos computadores objetivos de nível superior. Em outras palavras: programação ao estilo de Jornada nas Estrelas.

Você ainda deve aprender matemática, embora agora tenhamos calculadoras. Você ainda deve aprender a programar, embora agora tenhamos ferramentas de IA que possam escrever código.

Convenci você a considerar a programação como uma carreira?

Ótimo. Aqui está como se inserir no campo.

Desenvolva suas habilidades

Você precisa aprender:

Desenvolvimento de front-end: HTML, CSS e JavaScript
Desenvolvimento de back-end: SQL, Git, Linux e servidores da Web
Computação científica: Python e suas muitas bibliotecas

Essas são todas tecnologias maduras, com mais de 20 anos de existência. Qualquer que seja a empresa em que você trabalhe, você quase certamente usará a maioria dessas ferramentas.

A melhor maneira de aprender essas ferramentas é criando projetos. Tente programar pelo menos um pouco todos os dias. Se você seguir o currículo do freeCodeCamp de cima a baixo, aprenderá tudo isso e criará dezenas de projetos.

*Algumas das certificações no currículo principal do freeCodeCamp.*

Construa sua rede de contatos

Muito de se conseguir um emprego depende de quem você conhece.

Está tudo bem ser introvertido, mas você precisa expandir seus limites.

Crie contas no GitHub, X, LinkedIn e Discord.

Vá a encontros e conferências de tecnologia. Viaje, se precisar (a maior parte do seu orçamento dedicado a "aprender a programar" deve estar alocado para viagens e ingressos para eventos – não para livros e cursos).

Cumprimente pessoas que estão sozinhas. Deixe que os outros façam a maior parte da conversa e realmente ouça. Lembre-se dos nomes das pessoas.

Adicione pessoas no LinkedIn, siga-as no X e vá a festas pós-eventos.

Construa sua reputação

Compartilhe demonstrações de vídeo curtas de seus projetos.

Continue se inscrevendo para falar em conferências cada vez maiores.

Frequente hackerspaces e ajude pessoas que são ainda mais novas na programação do que você.

Contribua para o código aberto. O trabalho é semelhante ao desenvolvimento de software profissional.

Desenvolva suas habilidades, rede de contatos e reputação ao mesmo tempo. Não deixe que você mesmo evite e deixe para mais tarde as partes mais assustadoras.

Em vez de se candidatar a empregos pela "porta da frente", use sua rede de contatos para conseguir entrevistas de emprego pela "porta lateral". Recrutadores podem ajudar também.

Continue fazendo entrevistas até começar a receber ofertas de emprego. Você não precisa, porém, aceitar a primeira oferta que receber. Seja paciente.

Seu primeiro trabalho como desenvolvedor será o mais difícil. Tente ficar lá por pelo menos 2 anos e, essencialmente, ser pago para aprender.

O verdadeiro aprendizado começa assim que você está no emprego, trabalhando ao lado de uma equipe e com grandes bases de código legadas.

Mais importante ainda, durma e se exercite.

Qualquer pessoa suficientemente motivada pode aprender a programar bem o suficiente para conseguir um emprego como desenvolvedor.

É apenas uma questão da intensidade com a qual você deseja isso e do seu nível de persistência na busca por emprego.

Lembre-se: você consegue.

Este livro é dedicado à comunidade global do freeCodeCamp.

Obrigado a todos vocês que apoiaram nossa instituição beneficente e nossa missão nos últimos anos.

Foi através do seu voluntariado e da sua filantropia que pudemos ajudar tantas pessoas a aprender a programar e a conseguir seu primeiro emprego como desenvolvedor.

A comunidade cresceu tanto a partir do humilde projeto de código aberto que implantei pela primeira vez em 2014. Agora, sou apenas uma pequena parte desta comunidade global.

É um privilégio ainda estar aqui, trabalhando ao lado de todos vocês. Juntos, enfrentamos os problemas fundamentais do nosso tempo: acesso à informação, acesso à educação e acesso às ferramentas que estão moldando o futuro.

Estes ainda são os primeiros dias. Não tenho a ilusão de que todos saberão programar durante a minha vida, mas, assim como a Bíblia de Gutenberg acelerou a alfabetização em 1455, podemos continuar acelerando a alfabetização tecnológica por meio de recursos de aprendizado gratuitos e abertos.

Mais uma vez, obrigado a todos.

Um agradecimento especial a Abbey Rennemeyer, por seu feedback editorial, e a Estefania Cassingena Navone, por desenhar a capa do livro.

Agora, vamos ao livro.

Capítulo 1: como desenvolver suas habilidades

"Todo artista foi primeiro um amador." ― Ralph Waldo Emerson

O caminho para saber programar é longo.

Para mim, foi um caminho ambíguo, mas não precisa ser assim para você.

Neste capítulo, vou compartilhar algumas estratégias para aprender a programar da maneira mais tranquila possível.

Primeiro, permita-me falar sobre como aprendi a programar em 2011.

Depois, compartilharei o que aprendi com esse processo.

Vou mostrar a você como aprender de modo muito mais eficiente do que eu.

Hora da história: como um professor de inglês nos seus 30 anos de idade aprendeu a programar sozinho?

Eu era um professor administrando uma escola de inglês. Tínhamos cerca de 100 alunos adultos que haviam viajado para a Califórnia vindos de todo o mundo. Eles estavam aprendendo inglês avançado para poderem ingressar na pós-graduação.

A maioria dos professores da nossa escola adorava ensinar. Eles adoravam passar o tempo com os alunos pela cidade e ajudá-los a melhorar seu inglês conversacional.

Eu queria que nossos professores pudessem passar mais tempo com os alunos e menos tempo presos à mesa fazendo papelada.

Eu, no entanto, não sabia nada sobre computadores.

Programação? Não era preciso ser inteligente para programar? Eu mal conseguia configurar um roteador Wi-Fi e era péssimo em matemática.

Bem, um dia coloquei tudo isso de lado e pensei "Quer saber? Vou tentar. O que eu tenho a perder?"

Comecei a pesquisar no Google "como clicar automaticamente em sites" e "como importar dados de sites para o Excel".

Não percebi na época, mas estava aprendendo a automatizar fluxos de trabalho.

A aprendizagem, então, começou. Primeiro, com macros do Excel. Depois, com uma ferramenta chamada AutoHotKey, onde você pode programar o mouse para se mover para determinadas coordenadas da tela, clicar, copiar texto, depois se mover para coordenadas diferentes e colar.

Depois de algumas semanas tateando no escuro, descobri como automatizar algumas tarefas. Eu podia abrir uma planilha do Excel e um site, executar meu script, retornar 10 minutos depois e a planilha estaria totalmente preenchida.

Era o trabalho de um amador, o que os desenvolvedores podem chamar de "gambiarra", mas o trabalho era feito.

Usei minhas habilidades recém adquiridas de automação para continuar agilizando a escola.

Logo, os professores mal precisavam tocar em um computador. Eu estava fazendo o trabalho de vários professores, apenas com minhas habilidades rudimentares.

Isso teve um impacto visível na escola. Muito do nosso tempo estava preso em trabalho rotineiro no computador. Agora, estávamos livres.

Os professores estavam mais felizes. Eles passavam mais tempo com os alunos.

Os alunos estavam mais felizes. Eles diziam a todos os seus amigos em seus países de origem: "vocês precisam conhecer essa escola."

Logo, éramos uma das escolas mais bem-sucedidas de todo o sistema escolar.

Isso me encorajou ainda mais. Lembro-me de pensar comigo mesmo: "Talvez eu possa aprender a programar."

Eu conhecia alguns engenheiros de software do meu grupo de jogos de tabuleiro. Eles tinham formações tradicionais, com diplomas da Cal Tech, da Harvey Mudd e de outros programas famosos em Ciência da Computação.

Na época, era muito menos comum que pessoas na casa dos 30 anos aprendessem a programar.

Criei coragem para compartilhar meus sonhos com alguns desses amigos.

Eu queria aprender a programar corretamente. Eu queria poder escrever código para viver como eles faziam. Queria até escrever software que pudesse alimentar escolas.

Eu compartilhava esses sonhos com meus amigos desenvolvedores. "Eu quero fazer o que vocês fazem."

Eles meio que davam de ombros. Então, diziam algo como:

"Claro, você pode tentar, mas terá que aprender muita coisa."

Ou "É um campo bastante competitivo. Como você vai competir com pessoas que cresceram programando desde cedo?"

Ou ainda "Você já está indo bem como professor. Por que não continua naquilo em que é bom?"

Isso me tirava do rumo por algumas semanas. Eu fazia longas caminhadas introspectivas à noite. Eu pensava sobre meu futuro sob as estrelas. Será que essas pessoas estavam certas? Digo – elas conhecem o caminho, certo?

Todas as manhãs, porém, eu voltava à minha mesa. Ficava vendo meus scripts rodarem e vendo meus relatórios se compilarem a velocidades sobre-humanas. Via tudo isso enquanto meu computador fazia minhas vontades.

Um pensamento me ocorria: talvez esses amigos estivessem apenas tentando me poupar de um desgosto. Talvez eles simplesmente não conheçam ninguém que tenha aprendido a programar na casa dos 30 anos. Então, eles não acham que é possível.

É como... por anos, os médicos acharam que seria impossível para alguém correr um quilômetro e meio em 4 minutos. Eles achavam que seu coração explodiria de correr tão rápido.

Foi aí que alguém conseguiu fazer isso – e seu coração não explodiu.

Depois que Roger Bannister – um estudante de Oxford de 25 anos – rompeu essa barreira psicológica, várias outras pessoas também conseguiram. Até hoje, mais de mil pessoas correram uma milha em menos de 4 minutos.

Roger-Bannister-1951_jpg__1269-1600_ — *Roger Bannister correndo como um campeão. (Imagem: Britannica)*

Não é como se eu estivesse fazendo algo tão ousado e sem precedentes como correr um quilômetro e meio em 4 minutos aqui. Muitos desenvolvedores famosos conseguiram ensinar a si mesmos a programar ao longo dos anos.

Caramba, Ada Lovelace ensinou a si mesma a programar na década de 1840. Ela nem tinha um computador funcionando. Ela apenas tinha um entendimento de como o computador de seu amigo, Charles Babbage, funcionaria na teoria.

Ela escreveu vários dos primeiros algoritmos de computador. Ela é considerada por muitos a primeira programadora de computadores do mundo. Ninguém a ensinou porque não havia ninguém para ensiná-la. As dúvidas que ela poderia ter tido, ela claramente superou.

Óbvio, eu não era a Ada Lovelace. Eu era apenas um professor que já tinha um computador funcionando, uma conexão decente com a internet e a habilidade de pesquisar bilhões de páginas da web com o Google.

Estalei os dedos e estabeleci minha meta. Eu conseguiria aprender.

Preso no inferno dos tutoriais

"Se você trabalha há 10 anos, você ganha 10 anos de experiência ou ganha 1 ano de experiência 10 vezes? Você tem que refletir sobre suas atividades para obter experiência verdadeira. Se você fizer do aprendizado um compromisso contínuo, obterá experiência. Se não fizer, não importa quantos anos você tenha de carreira." – Steve McConnell, engenheiro de software

"Olha só, um tutorial de Ruby."

"Xiii, está começando a ficar difícil. Estou recebendo mensagens de erro que não foram mencionadas no tutorial. Hmm... o que está acontecendo aqui..."

"Olha só, um tutorial de Python."

A psicologia humana é uma coisa engraçada. No momento em que algo começa a ficar difícil, perguntamos: estou fazendo isso certo?

Talvez o tutorial esteja desatualizado. Talvez o autor não soubesse do que estava falando. Alguém ainda usa essa linguagem de programação?

Quando você está enfrentando mensagens de erro ambíguas horas após iniciar uma sessão de programação, a grama do outro lado parece sempre muito mais verde.

Era fácil fingir que eu havia feito progresso. Hora de almoçar.

Eu encontrava um amigo no café. "Como está indo na programação?", ele perguntava.

"Estou indo muito bem. Já programei por 4 horas hoje."

"Incrível. Gostaria muito de ver o que você está criando algum dia."

"Claro," eu dizia, sabendo que eu não tinha criado nada. "Em breve."

Talvez eu fosse à biblioteca e pegasse um novo livro sobre JavaScript.

Há um ditado que diz que comprar livros dá a melhor sensação do mundo porque também parece que você está comprando o tempo para lê-los.

Foi exatamente onde me encontrei algumas semanas após começar a aprender a programar.

Eu havia lido as primeiras 100 páginas de vários livros de programação, mas não terminei nenhum.

Eu havia escrito as primeiras 100 linhas de código de vários tutoriais de programação, mas não terminei nenhum.

Eu não sabia, mas estava preso em um lugar que os desenvolvedores carinhosamente chamam de "inferno dos tutoriais".

O inferno dos tutoriais é onde você pula de um tutorial para outro, aprendendo e depois reaprendendo as mesmas coisas básicas, mas nunca indo além dos fundamentos.

Por que ir além dos fundamentos? Bem, isso requer trabalho de verdade.

É preciso uma comunidade para criar um programador

Aprender a programar estava absorvendo todo o meu tempo livre, mas eu não estava fazendo muito progresso. Agora, eu podia digitar os caracteres { e * sem olhar para o teclado, mas era só isso.

Eu sabia que precisava de ajuda. Talvez algum mentor do tipo o mestre Yoda, que pudesse me ensinar os caminhos. Sim – se tal pessoa existisse, certamente faria toda a diferença.

Descobri um lugar nas proximidades chamado "hackerspace". Quando ouvi o nome pela primeira vez, fiquei um pouco apreensivo. Os hackers não são aqueles caras que fazem coisas ilegais? Eu era um professor de inglês que gostava de jogos de tabuleiro. Não estava procurando encrenca.

Bem, liguei para o número listado e falei com um cara chamado Steve. Perguntei nervosamente: "Vocês não fazem nada ilegal, fazem?". Steve riu.

Acontece que a palavra "hack" é o que ele chamava de um termo sobrecarregado. Sim – "hackear" pode significar invadir maliciosamente um sistema de software, mas "hackear" também pode significar algo mais simples: escrever código de computador.

Algo pode ser "hacky" significando que não é uma solução elegante, nossa famosa "gambiarra". Ainda assim, você pode ter "um hack engenhoso" – um truque engenhoso para fazer seu código funcionar de modo mais eficiente.

Em resumo: não tenha medo do termo "hack".

1200x-1_jpg__1200-797_ — *O campus corporativo do Facebook tem a palavra "hack" escrita em letras gigantes no concreto. (Imagem: Bloomberg)*

Eu, por exemplo, dificilmente uso o termo porque é muito confuso. Acho que recentemente muitos hackerspaces perceberam a ambiguidade. Muitos deles, agora, se chamam "makerspaces" em vez disso.

É disso que se trata um hackerspace – fazer coisas.

Steve me convidou para visitar o hackerspace no sábado à tarde. Ele disse que vários desenvolvedores da área estariam lá.

A primeira vez que passei pelas portas do Hackerspace de Santa Barbara, fiquei impressionado.

O lugar cheirava a fogo elétrico. Suas mesas improvisadas estavam repletas de ferros de solda, tiras de luzes de LED, placas de circuito de Arduino para hobbistas e pilhas de robôs aspiradores Roomba.

O mesmo Steve com quem eu havia falado ao telefone estava lá e me cumprimentou. Ele usava óculos, cabelo penteado para trás e uma barba com cavanhaque. Ele estava sempre sorrindo. Quando você fazia uma pergunta a ele, em vez de responder rapidamente, ele balançava a cabeça e pensava por alguns segundos primeiro.

Steve era um programador apaixonado, que estudou matemática e filosofia na Universidade da Califórnia – Santa Barbara. Ele ainda era apaixonado por esses assuntos, mas sua verdadeira paixão era o Python.

Steve ligou o projetor e deu uma "palestra relâmpago" informal. Ele estava demonstrando uma aplicação que havia escrito, que reconheceria códigos QR em um vídeo e os substituiria por imagens.

Alguém na plateia puxou um código QR em seu laptop e o segurou na frente da câmera. A aplicação de Steve, então, substituiu o código QR por uma foto de uma pizza.

Alguém na plateia gritou: "Você pode fazer a pizza girar?"

Steve abriu seu código em um editor de código, chamado Emacs, e começou a fazer alterações em tempo real. Ele alternava sem esforço entre seu editor de código, sua linha de comando e o navegador em que a aplicação estava sendo executada, "carregando diretamente" as atualizações do código.

Para mim, aquilo era feitiçaria. Eu não conseguia acreditar que Steve havia acabado de criar aquela aplicação em questão de algumas horas. Agora, ele estava adicionando novos recursos na hora, conforme o público pedia.

Eu pensei: "Esse cara é um gênio."

Naquela noite, depois que o evento terminou, ele e eu ficamos conversando depois e eu disse isso a ele.

Comemos sanduíches juntos. Então, eu disse a ele: "Eu poderia programar por toda minha carreira e não seria tão bom como você. Eu adoraria se, daqui a uns 10 anos, eu programasse com a metade da sua capacidade."

Steve resistiu. Ele disse: "Eu não sou nada especial. Não se limite. Se você continuar programando, poderá me superar facilmente."

Naquele momento, eu não acreditei nem por um segundo nas palavras que ele me disse, mas só o fato de ele ter dito isso me deixou emocionado.

Lá estava ele: um desenvolvedor que acreditava em mim. Ele me enxergava – um professor qualquer – a própria definição de "novato dos scripts" – e achava que eu poderia conseguir.

Steve e eu conversamos até tarde da noite. Ele me mostrou seu netbook de 200 dólares, que, mesmo para os padrões de 2011, era extremamente defasado.

"Você não precisa de um computador poderoso para desenvolver software," Steve me disse. "O hardware de hoje é incrivelmente poderoso. Os computadores são lentos porque o software inchado que eles rodam os torna lentos. Compre um laptop comum, limpe o disco rígido, instale o Linux e comece a programar."

Anotei o modelo do laptop que ele tinha e encomendei exatamente o mesmo quando cheguei em casa naquela noite.

Depois de alguns dias depurando meu novo computador com o Stack Overflow, consegui instalar o Ubuntu com sucesso. Comecei a aprender a usar o editor de código Emacs. No sábado seguinte, já conhecia alguns comandos e estava ansioso para mostrá-los.

Steve acenou com a cabeça em aprovação. Ele disse, "Incrível, mas o que você está criando?"

Eu não entendi o que ele quis dizer. "Estou aprendendo a usar o Emacs. Veja, eu memorizei..."

Steve parecia pensativo. "Isso é legal, mas você precisa de um projeto. Sempre tenha um projeto. Então, aprenda o que você precisa aprender no caminho para terminar esse projeto."

Além de alguns scripts que eu tinha escrito para ajudar os professores da minha escola, eu nunca tinha terminado nada, mas comecei a entender o que ele estava dizendo.

Foi aí que começou a me ocorrer: esse tempo todo eu estava preso no inferno dos tutoriais, andando em círculos, sem terminar nada.

Steve disse, "Quero que você crie um projeto usando HTML5. No próximo sábado, quero que você o apresente no hackerspace."

Fiquei apavorado com suas palavras, mas me levantei e disse: "Combinado. Estou dentro."

Ninguém pode fazer de você um desenvolvedor, além de você mesmo

"Estou tentando libertar sua mente, Neo, mas só posso mostrar a porta. É você quem tem que atravessá-la." – Morpheus, no filme Matrix (1999)

Na manhã seguinte, acordei mais cedo do que de costume e procurei algo como "tutorial de HTML5" no Google. Eu já sabia muita coisa disso do meu tempo anterior no inferno dos tutoriais, mas ao invés de pular partes, desacelerei e segui exatamente como estava, digitando cada comando.

Geralmente, depois de terminar um tutorial, eu simplesmente procurava outro. Dessa vez, comecei a brincar com o código do tutorial. Tive uma ideia simples para um projeto. Eu faria uma página de documentação de HTML5, depois faria a página puramente em HTML5.

Deixe-me explicar rapidamente o HTML5. É apenas uma versão mais nova do HTML, que existe desde as primeiras páginas da web nos anos 90.

Se um site fosse um corpo, o HTML seria os ossos. Tudo o mais repousa sobre esses ossos (você pode pensar no JavaScript como os músculos e no CSS como a pele, mas vamos voltar à história.)

Eu sabia que, no HTML, você podia linkar para diferentes partes da mesma página web usando propriedades de ID. Então, pensei: e se eu colocasse um índice no lado esquerdo? Depois, clicando nos diferentes itens à esquerda, a página rolaria até mostrar esses itens.

Dentro de meia hora, eu tinha criado o protótipo bruto.

Era hora de ir para o trabalho na escola. O dia todo, só conseguia pensar no meu projeto e em como deveria terminá-lo.

Corri para casa, abri meu laptop e passei a noite inteira programando.

Copiei a documentação oficial (e licenciada sob o creative commons) do HTML diretamente para a minha página, colocando no HTML a documentação por "hard coding" (quando você coloca os valores de variáveis diretamente no código).

Então, passei cerca de uma hora no CSS, ajustando tudo para ficar certo e usando posicionamento absoluto para manter a barra lateral no lugar.

Fiz questão de usar o máximo das novas tags "semânticas" do HTML5 que pude.

Logo, o projeto estava terminado.

Uma onda de realização me preencheu. Corri até um campo de futebol próximo e dei voltas ao redor do campo, comemorando. Eu consegui. Terminei um projeto.

Foi naquele momento que decidi: de agora em diante, tudo que eu fizer será um projeto. A partir de agora, vou trabalhar para finalizar os produtos.

Na noite seguinte, caminhei até o centro da sala, pluguei meu laptop e apresentei minha página em HTML5. Respondi às perguntas dos desenvolvedores presentes sobre o HTML5.

Às vezes, cometia um erro e alguém na plateia dizia, "isso não parece estar certo – vamos conferir a documentação."

As pessoas não tinham medo de me corrigir, mas eram educadas e prestativas. Nem parecia que estavam me corrigindo – parecia que estavam corrigindo o registro público – para que ninguém saísse com informações incorretas.

Eu não senti a ansiedade que talvez sentisse ao dar uma palestra em uma reunião de serviço para professores.

Na verdade, quase me senti parte dos espectadores, aprendendo junto com eles.

Afinal, essas ferramentas eram novas e emergentes. Todos nós estávamos tentando entender como usá-las juntos.

Depois da minha apresentação, Steve veio até mim e me disse: "Nada mal."

Eu sorri para ele de um modo meio estranho por bastante tempo, sem dizer nada. Estava apenas feliz comigo mesmo.

Então, Steve apertou os olhos e franziu os lábios. Ele disse: "Comece seu próximo projeto hoje a noite."

Lições da minha jornada de programação

Vamos acompanhar a jornada de programação do jovem Quincy em cada um dos capítulos seguintes, mas agora eu quero detalhar algumas das lições aqui. Quero responder a algumas das perguntas que você possa ter.

Por que aprender a programar é tão difícil?

Aprender qualquer nova habilidade é difícil, seja driblar com uma bola de futebol, trocar o óleo de um carro ou falar um novo idioma.

Aprender a programar é difícil por algumas razões específicas. Algumas delas são exclusivas da programação.

A primeira é que a maioria das pessoas não entende exatamente o que é programação. Bem, aí vai.

O que é programação?

Programação é dizer a um computador o que fazer, de um modo que o computador possa entender.

É isso. Isso é tudo que a programação realmente é.

Agora, não se engane. Comunicar-se com computadores é difícil. Eles são "burros" pelos padrões humanos. Eles farão exatamente o que você disser a eles que façam. A menos que você seja bom em programação, porém, eles provavelmente não farão o que você quer que eles façam.

Você pode estar pensando: e os servidores, os bancos de dados e as redes?

No final, tudo isso é controlado por camadas de software. Código. É código o tempo todo. Eventualmente, você chega ao hardware físico, que está movendo elétrons pelas placas de circuito.

Nas primeiras décadas da computação, os desenvolvedores escreviam código que estava "próximo ao metal" – muitas vezes operando no hardware diretamente, alterando bits de 0 para 1 e vice-versa.

O desenvolvimento de software contemporâneo, contudo, envolve tantas "camadas de abstração" – programas rodando em cima de programas – que apenas algumas linhas de código em JavaScript já podem fazer coisas realmente poderosas.

Nos anos de 1960, um "bug" poderia ser um inseto rastejando dentro de um computador do tamanho de uma sala e sendo frito em um dos circuitos.

First_Computer_Bug-_1945 — *O primeiro bug de computador, descoberto em 1945, era uma mariposa que ficou presa nos painéis de um computador de calculadora do tamanho de uma sala em Harvard. (Imagem: domínio público)*

Hoje, estamos escrevendo código com muitas camadas de abstração acima do hardware físico.

Essa é a programação. É muito mais fácil do que era no passado e está ficando mais fácil a cada ano.

Eu não estou exagerando quando digo que, em algumas décadas, programar será tão fácil e tão comum que a maioria das pessoas mais jovens saberá fazer isso.

Por que aprender a programar ainda é tão difícil após todos esses anos?

Existem três grandes razões pelas quais aprender a programar é tão difícil, mesmo hoje:

As ferramentas ainda são primitivas.
A maioria das pessoas não é boa em lidar com a ambiguidade – e aprender a programar é ambíguo. As pessoas se perdem.
A maioria das pessoas não é boa em lidar com feedback negativo constante. Aprender a programar é uma mensagem de erro fatal após a outra. As pessoas ficam frustradas.

Vamos discutir cada uma dessas dificuldades em mais detalhes. Vou ensinar a você algumas estratégias práticas para superar cada uma delas.

As ferramentas ainda são primitivas

TNG-S4E19-171 — *Um Barclay Possuído de Star Trek: A Nova Geração, programando no Holodeck.*

"Computador. Começar novo programa. Criar conforme o seguinte. Cadeira de estação de trabalho. Agora criar um console alfanumérico padrão posicionado à esquerda. Agora um console de display icônico para a mão direita. Ligar ambos os consoles ao núcleo do computador principal da Enterprise, utilizando a interface de neuralscan." - Barclay de Star Trek: A Nova Geração, temporada 4, episódio 19: "O enésimo grau"

É assim que as pessoas podem programar no futuro. Esse é um exemplo da minha série de TV de ficção científica favorita, Star Trek: A Nova Geração.

Todo personagem em Star Trek pode programar. Médicos, oficiais de segurança, pilotos. Até o pequeno Wesley Crusher (interpretado pelo ator mirim Wil Wheaton) consegue fazer o computador da nave obedecer suas ordens.

Claro, uma das razões pelas quais todos podem programar é que eles vivem em uma sociedade pós-escassez do século 24, com acesso à educação gratuita e de alta qualidade.

Outra razão é que, no futuro, programar será muito, muito mais fácil. Você só diz a um computador exatamente o que fazer e – se for suficientemente preciso – o computador fará o que você quer.

Que tal seria se programar fosse tão fácil quanto dar instruções para um computador em linguagem simples?

Bem, já fizemos progressos significativos em direção a esse objetivo. Pense em nossas avós, correndo entre computadores mainframe do tamanho de uma sala com pilhas de cartões perfurados.

naca-computer-operates-an-ibm-telereader-5b6f9f-1024 — *Trabalhando com um computador baseado em cartões perfurados nos anos 1950 (Imagem: NASA)*

Antigamente, programar até mesmo uma aplicação simples exigia instruções meticulosas.

Aqui estão dois exemplos de uma "Cifra de César", o clássico projeto de tema de casa da ciência da computação.

Ele também é conhecido como "ROT-13" porque você ROTaciona as letras em 13 posições. Por exemplo, A se torna N (13 letras após A) e B se torna O (13 letras após B).

Vou mostrar dois exemplos deste programa.

Primeiro, aqui está o programa em Assembly x86:

format     ELF     executable 3
entry     start

segment    readable writeable
buf    rb    1

segment    readable executable
start:    mov    eax, 3        ; syscall "read"
    mov    ebx, 0        ; stdin
    mov    ecx, buf    ; buffer for read byte
    mov    edx, 1        ; len (read one byte)
    int    80h

    cmp    eax, 0        ; EOF?
    jz    exit

    xor     eax, eax    ; load read char to eax
    mov    al, [buf]
    cmp    eax, "A"    ; see if it is in ascii a-z or A-Z
    jl    print
    cmp    eax, "z"
    jg    print
    cmp    eax, "Z"
    jle    rotup
    cmp    eax, "a"
    jge    rotlow
    jmp    print

rotup:    sub    eax, "A"-13    ; do rot 13 for A-Z
    cdq
    mov    ebx, 26
    div    ebx
    add    edx, "A"
    jmp    rotend

rotlow:    sub    eax, "a"-13    ; do rot 13 for a-z
    cdq
    mov    ebx, 26
    div    ebx
    add    edx, "a"

rotend:    mov    [buf], dl

print:     mov    eax, 4        ; syscall write
    mov    ebx, 1        ; stdout
    mov    ecx, buf    ; *char
    mov    edx, 1        ; string length
    int    80h

    jmp    start

Esse exemplo de Assembly x86 vem do projeto Rosetta Code, licenciado sob a Creative Commons.

Aqui temos o mesmo programa, mas escrito em Python:

def rot13(text):
    result = []

    for char in text:
        ascii_value = ord(char)

        if 'A' <= char <= 'Z':
            result.append(chr((ascii_value - ord('A') + 13) % 26 + ord('A')))
        elif 'a' <= char <= 'z':
            result.append(chr((ascii_value - ord('a') + 13) % 26 + ord('a')))
        else:
            result.append(char)

    return ''.join(result)

if __name__ == "__main__":
    input_text = input("Digite o texto a ser codificado/decodificado com ROT-13: ")
    print("Texto Codificado/Decodificado:", rot13(input_text))

Parece mais simples e fácil de ler?

Esse exemplo em Python vem diretamente do GPT-4. Eu pedi da mesma maneira que o Capitão Picard pediria ao computador da nave em Jornada nas Estrelas.

Aqui está exatamente o que eu disse: "Computador. Novo programa. Pegue cada letra da palavra que eu disser e substitua pela letra que aparece 13 posições depois no alfabeto inglês. Então, leia o resultado para mim. A palavra é Banana."

O GPT-4 produziu este código em Python, e então leu o resultado para mim: "Onanan."

O que estamos fazendo aqui é chamado de Programação Declarativa. Estamos declarando "computador, você deve fazer isto". O computador é inteligente o suficiente para entender nossas instruções e executá-las.

O estilo de programação que a maioria dos desenvolvedores usa hoje, contudo, é a Programação Imperativa. Estamos dizendo ao computador exatamente o que fazer, passo a passo. Historicamente, os computadores têm sido bem burrinhos. Então, tivemos que ajudá-los a dar um passo de cada vez.

A área de desenvolvimento de software ainda não está madura.

Porém, assim como as ferramentas humanas antigas avançaram – da pedra ao bronze e depois ao ferro – o mesmo está acontecendo com as ferramentas de software, só que muito mais rápido.

Provavelmente, ainda estejamos no equivalente da Idade do Bronze da programação agora, mas podemos chegar à Idade do Ferro ainda nesta época em que vivemos. Ferramentas de IA generativa como o GPT estão rapidamente se tornando mais poderosas e mais confiáveis.

A comunidade de desenvolvedores ainda está dividida sobre a utilidade de ferramentas como o GPT para o desenvolvimento de software.

De um lado, você tem os influenciadores empreendedores ("torne-se seu próprio chefe"), que dizem coisas como: "Você não precisa mais aprender a programar. O ChatGPT pode escrever todo o seu código para você. Você só precisa de uma ideia de aplicação."

Do outro lado do espectro, você tem desenvolvedores da "velha guarda" com décadas de experiência em programação – muitos dos quais são céticos de que ferramentas como o GPT são realmente tão úteis para produzir código de qualidade em produção.

Como na maioria das coisas, a resposta real provavelmente está em algum lugar no meio.

Não é difícil encontrar vídeos no YouTube de pessoas que começam com uma ideia de aplicação, depois pedem ao ChatGPT o código de que precisam. Algumas pessoas podem até pegar esse código e transformá-lo em uma aplicação que funciona.

Grandes Modelos de Linguagem (em inglês, LLMs, ou Large Language Models), como o GPT-4, são impressionantes. A velocidade com que estão melhorando é ainda mais impressionante.

Ainda assim, muitos desenvolvedores são céticos sobre a utilidade dessas ferramentas. Eles questionam se seremos capazes de fazer com que as IAs parem de "alucinar" informações falsas.

Este é o problema fundamental da "interpretabilidade". Pode levar décadas antes que entendamos realmente o que está acontecendo dentro de uma IA como o GPT-4. Até que consigamos, devemos verificar tudo o que ele diz e assumir que haverá bugs e falhas de segurança no código que ele nos dá.

Há uma grande diferença entre conseguir fazer um computador fazer algo para você e realmente entender como o computador está fazendo isso.

Muitas pessoas sabem conduzir um carro, mas muito menos pessoas podem consertar um carro – quanto mais desenhar um novo carro do zero.

Se você quer ser capaz de desenvolver sistemas de software poderosos que resolvam novos problemas – e quer que esses sistemas sejam rápidos e seguros – ainda vai precisar aprender a programar corretamente.

Isso significa sentir qual é o seu caminho e lidar com muita ambiguidade.

Aprender a programar é um processo ambíguo

Quando você está aprendendo a programar, você constantemente se pergunta: "Estou usando meu tempo com sabedoria? Estou aprendendo as ferramentas certas? Esses autores de livros/criadores de cursos sabem do que estão falando?"

A ambiguidade embaça todas as suas sessões de estudo. "Meu caso de teste falhou porque o tutorial está desatualizado e porque houve mudanças no framework que estou usando? Ou será que eu estou fazendo algo de errado?"

Como mencionei anteriormente com o inferno dos tutoriais, você também precisa lidar com a doença do "a grama é mais verde do outro lado".

Isso é agravado pelo fato de que alguns desenvolvedores se acham muito espertos ao responderem perguntas com um "RTFM" (que significa, em português, algo como "Leia a droga do manual". Nada super útil. Que manual? Que seção?

Outro problema é que você não sabe o que não sabe. Muitas vezes você não consegue nem articular a pergunta que está tentando fazer.

Se você não consegue nem mesmo fazer a pergunta certa, vai se debater.

Isso é ainda mais difícil com a programação porque é possível que ninguém tenha tentado construir exatamente a mesma aplicação que você está construindo.

Assim, alguns dos problemas que você encontra podem não ter precedentes. Pode não haver ninguém a quem recorrer.

15% das consultas que as pessoas digitam no Google todos os dias jamais foram pesquisadas antes. Essa é uma má notícia se você é a pessoa que está fazendo essas pesquisas.

Minha teoria é de que a maioria dos desenvolvedores descobrirá como resolver um problema e simplesmente seguirá em frente, sem jamais documentá-lo em qualquer lugar. Então, você pode ser parte dos incontáveis desenvolvedores que teve de inventar sua própria solução para o mesmo problema específico.

Claro, há os tópicos de fóruns antigos e as páginas do StackOverflow.

wisdom_of_the_ancients_png__485-270_ — *Quadrinho criado por XKCD*

Como não se perder ao aprender a programar

A boa notícia é: competência e confiança vêm com a prática.

Em breve, você saberá exatamente o que buscar no Google. Você terá uma espécie de sexto sentido para como a documentação é geralmente estruturada e onde procurar por o quê. Também saberá onde perguntar determinadas perguntas.

Eu gostaria que houvesse uma solução mais simples para o problema da ambiguidade, mas você só precisa aceitá-la. Aprender a programar é um processo ambíguo. Mesmo os desenvolvedores mais experientes precisam lidar com a ambiguidade.

Afinal, programar é uma das raras profissões onde você pode reutilizar infinitamente soluções para problemas que já encontrou antes.

Assim, como desenvolvedor, você está sempre fazendo algo que nunca fez antes.

As pessoas pensam que desenvolvimento de software tem a ver com digitar código em um computador. Na verdade, é mais a ver com aprender.

Você vai passar uma grande parte da sua carreira apenas pensando muito intensamente ou inserindo comandos às cegas em um prompt, tentando entender como um sistema funciona.

Você também vai passar muito tempo em reuniões com outras pessoas: gerentes, clientes, colegas desenvolvedores, aprendendo sobre o problema que precisa ser resolvido, para que você possa construir uma solução para ele.

Fique confortável com a ambiguidade e você vai longe.

Aprender a programar é uma mensagem de erro após a outra

Muitas pessoas que estão aprendendo a programar sentem como se batessem em um muro. O progresso não vem tão rapidamente quanto esperam.

Uma grande razão para isso é que, na programação, o ciclo de feedback é muito mais apertado do que em outras áreas.

Na maioria das escolas, seu professor vai dar a você as tarefas, depois avaliará essas tarefas e as devolverá para você. Ao longo de um semestre, você pode ter apenas uma dúzia de situações onde receberá feedback.

"Oh, não, eu realmente fui mal nessa prova," você pode dizer a si mesmo. "Eu preciso estudar mais para a próxima prova".

Talvez seu professor deixe anotações em tinta vermelha no seu trabalho para ajudar você a melhorá-lo.

Receber uma nota ruim em um teste ou trabalho pode realmente arruinar seu dia.

É assim que geralmente pensamos sobre feedback como seres humanos.

Se você passou muito tempo programando, saberá que os computadores são bastante rápidos. Eles podem executar seu código em alguns milissegundos.

Na maioria das vezes, seu código vai falhar.

Se você tiver sorte, receberá uma mensagem de erro.

Se tiver MUITA sorte, receberá um "rastreamento de pilha" – tudo o que o computador estava tentando fazer quando encontrou o erro – junto com um número de linha do trecho de código que causou a falha do programa.

Esse é um feedback negativo direto de um computador. Nem todo mundo consegue lidar com ele, vendo isso repetidamente o dia todo.

Imagine se cada vez que você entregasse seu trabalho ao seu professor, ele o devolvesse com um grande "F" vermelho escrito nele. Imagine se ele fizesse isso antes que você pudesse sequer piscar e repetidamente.

É assim que programar pode parecer às vezes. Você quer agarrar o computador e gritar, "por que você simplesmente não entende o que estou tentando fazer?".

Como não se frustrar

A chave, novamente, é a prática.

Com o tempo, você desenvolverá uma tolerância para as mensagens de erro vagas e rastreamentos de pilha do tamanho de uma tela inteira.

Programar nunca será mais difícil do que é quando você está apenas começando.

Não só você não sabe o que está fazendo, como também não está acostumado a receber um feedback negativo tão impessoal e rápido.

Aqui vão algumas dicas:

Dica nº 1: saiba que você não é o pior dos piores em programação

Todos que aprendem a programar lutam com a frustração de tentar realizar uma fusão mental com um computador e fazer com que ele o entenda (outra referência a Star Trek).

Claro, algumas pessoas começaram a programar quando eram apenas crianças. Elas podem agir como se sempre fossem boas em programação, mas, muito provavelmente, elas lutaram da mesma forma que nós, adultos, lutamos, e com o tempo simplesmente esqueceram as horas de frustração.

Pense no computador como seu amigo, não seu adversário. Ele está apenas pedindo que você esclareça suas instruções.

Dica nº 2: respire

A reação natural de muitas pessoas quando recebem uma mensagem de erro é ranger os dentes. Depois, voltar ao editor de código e começar a alterar o código cegamente, esperando ter sorte e passar pelo erro.

Isso não funciona, e eu vou te dizer o porquê.

O universo é complexo. Software é complexo. Você, provavelmente, não terá a sorte de um Forest Gump de simplesmente esbarrar em algo bom no final.

Você pode ter ouvido falar do Teorema do macaco infinito. É um experimento mental onde você imagina chimpanzés digitando em máquinas de escrever.

Se você tivesse uma sala cheia de chimpanzés digitando em máquinas de escrever, quanto tempo levaria até que um deles digitasse a frase "ser ou não ser" por acaso?

Vamos supor que cada chimpanzé digite um caractere aleatório por segundo. Provavelmente, levaria 1 quintilhão de anos para um deles digitar "ser ou não ser". Isso é 10 elevado à 18ª potência. Um bilhão de bilhões.

Mesmo assumindo que os chimpanzés permaneçam saudáveis e que as máquinas de escrever sejam regularmente mantidas – a galáxia seria um vazio frio e escuro até que um deles conseguisse digitar "ser ou não ser".

Por que estou falando disso? Porque você não quer ser um desses chimpanzés.

Nesse tempo, você certamente descobriria uma maneira de ensinar esses chimpanzés a digitar palavras em inglês. Eles provavelmente conseguiriam digitar todo Hamlet – não apenas sua linha mais famosa.

Mesmo que, de alguma maneira, você dê sorte e passe pelo bug, o que você terá aprendido?

Então, em vez de brigar com o código, você deve dar um tempo. Entenda o código. Entenda o que está acontecendo e, então, corrija o erro.

Sempre dedique um tempo para entender o código que está falhando. Não seja um chimpanzé quintilionário (acho que isso significa alguém com 1 quintilhão de anos, embora, segundo o Google, ninguém jamais tenha digitado essa palavra antes).

Em vez de tentar fazer as coisas cegamente, esperando que a mensagem de erro pare de aparecer, desacelere.

Respire fundo. Alongue-se. Levante-se e pegue uma bebida quente.

Seu futuro eu será grato por ter aproveitado esse momento para aprender algo.

Dica nº 3: use a depuração com o patinho de borracha

Obtenha um patinho de borracha e coloque-o ao lado do seu computador. Toda vez que você encontrar uma mensagem de erro, tente explicar ao patinho o que você acha que está acontecendo.

Claro, isso é bobo. Como isso poderia ser útil?

Por incrível que pareça, é.

A depuração com o patinho de borracha (em inglês, rubber duck debugging) é uma ótima ferramenta para desacelerar e falar sobre o problema em questão.

Você não precisa usar um patinho de borracha, é claro. Você poderia explicar sua aplicação em Python para o seu cacto de estimação e sua consulta SQL ao gato que continua pulando no seu teclado.

O próprio ato de explicar seu raciocínio em voz alta parece ajudá-lo a processar melhor a situação.

Como a maioria das pessoas aprende a programar?

Vamos falar sobre os caminhos tradicionais que levam ao primeiro emprego como desenvolvedor.

Por que você deveria se importar com o que todos os outros fazem? Spoiler: você não precisa fazer isso, na verdade.

Você faz você.

Dito isso, você pode duvidar de si mesmo e das decisões que tomou sobre seu aprendizado. Pode ansiar pelo caminho não trilhado.

Meu objetivo com esta seção é acalmar qualquer ansiedade que você possa ter.

A importância dos diplomas em Ciência da Computação

Os diplomas universitários ainda são o padrão de ouro para se preparar para uma carreira em desenvolvimento de software, especialmente os bacharelados em Ciência da Computação.

Antes de começar a dizer "mas eu não tenho um diploma em Ciência da Computação" – relaxe. Você não precisa de um diploma em Ciência da Computação para se tornar um desenvolvedor.

A utilidade do curso, porém, é inegável – e eu vou explicar o porquê.

Primeiro, você pode se perguntar: por que os desenvolvedores devem estudar Ciência da Computação? Afinal, um dos desenvolvedores mais proeminentes de todos os tempos disse o seguinte sobre o campo:

"A educação em ciência da computação não pode fazer ninguém se tornar um especialista em programação, assim como estudar pincéis e pigmentos não pode fazer alguém se tornar um especialista em pintura." – Eric Raymond, desenvolvedor, cientista da computação e autor

Os departamentos de Ciência da Computação eram tradicionalmente parte do departamento de matemática. Universidades nos anos 1960 e 1970 não sabiam ao certo onde colocar essa coisa toda de computação.

Em outras universidades, a Ciência da Computação era considerada uma extensão da Engenharia Elétrica. Até recentemente, mesmo a Universidade da Califórnia – Berkeley – uma das maiores universidades públicas do mundo – só oferecia diplomas de Ciência da Computação como uma espécie de dupla graduação com Engenharia Elétrica.

A maioria das universidades, agora, compreende a importância da Ciência da Computação como campo de estudo.

No momento em que escrevo, a Ciência da Computação é o diploma mais bem remunerado que você pode obter, com salários mais altos até do que o de áreas focadas em dinheiro, como Finanças e Economia.

De acordo com o Glassdoor, a graduação em Ciência da Computação nos EUA garante mais dinheiro em seu primeiro emprego do que qualquer outra graduação. São 70 mil dólares. Isso é muito dinheiro para alguém que acabou de se formar na faculdade.

Mais do que graduações em Enfermagem (59 mil dólares), Finanças (55 mil dólares) e arquitetura (50 mil dólares).

Certo – então, obter um diploma em Ciência da Computação pode ajudá-lo a conseguir um emprego de nível básico bem remunerado. Isso provavelmente não é novidade para ninguém, mas por que as coisas são assim?

Como os empregadores pensam sobre diplomas de bacharelado

Você pode ter ouvido alguns grandes empregadores em tecnologia dizerem coisas como "não exigimos mais que os candidatos a vagas de emprego tenham um diploma de bacharelado".

O Google disse isso. A Apple disse isso.

Eu acredito neles, que eles não exigem mais diplomas de bacharelado.

Tivemos muitos ex-alunos do freeCodeCamp conseguindo empregos nessas empresas, alguns dos quais não tinham diplomas de bacharelado.

Esses ex-alunos do freeCodeCamp, porém, que conseguiram esses empregos, provavelmente, tiveram de ser candidatos muito fortes para superar o fato de não terem diplomas de bacharelado.

Você pode ver essas vagas de emprego como tendo uma variedade de critérios pelos quais os candidatos são julgados:

Experiência de trabalho
Educação
Portfólio e projetos
Eles têm uma recomendação de alguém que já trabalha na empresa? (discutiremos networking em profundidade no capítulo 2)
Outras considerações relacionadas à reputação (discutiremos construção de uma reputação no capítulo 3)

Para esses empregadores que não exigem um diploma de bacharelado, a educação formal é apenas uma das várias coisas a serem consideradas. Se você for muito forte em outras áreas, eles podem escolher entrevistar você – independentemente de você ter pisado ou não em alguma universidade em algum momento da vida.

Apenas observe que ter um diploma de bacharelado tornará mais fácil conseguir uma entrevista, mesmo nesses empregadores "que não exigem diploma".

Por que tantos empregos de desenvolvedor exigem especificamente um diploma em Ciência da Computação?

Um bacharelado é um bacharelado, eu costumo dizer às pessoas, porque, para a maioria dos casos e propósitos, é isso mesmo.

Quer entrar nas forças armadas dos EUA como oficial, em vez de passar pelo alistamento? Você precisará de um diploma de bacharelado, mas qualquer especialidade serve.

Quer obter um visto de trabalho para trabalhar no exterior? Provavelmente, precisará de um diploma de bacharelado, mas qualquer especialidade serve.

Para tantas vagas de emprego que dizem "necessário diploma de bacharelado" – qualquer especialidade serve.

Por que funciona assim? O assunto que você estuda na universidade não importa?

Bem, aqui está minha teoria sobre isso: o que você aprende na universidade é menos importante do que se você concluiu a universidade.

Os empregadores estão tentando selecionar pessoas que possam encontrar meios de passar por esse "rito de passagem".

É certamente verdade que você pode estar entre os piores da sua turma, repetindo cursos em que não conseguiu passar, e estar fazendo aulas de recuperação a metade do seu tempo, mas um diploma é um diploma.

Sabe como eles chamam o estudante que terminou em último lugar na sua turma na escola de medicina? "Doutor".

Para a maioria dos empregadores, o mesmo se aplica.

Em muitos casos, as pessoas de RH estão apenas marcando uma caixa no software de filtragem de candidaturas a um emprego. Eles estão filtrando candidatos que não têm um diploma. Nesses casos, eles podem sequer olhar para as candidaturas a emprego de pessoas sem diplomas.

Novamente, nem todo empregador é assim. Muitos deles são, no entanto. Aqui nos EUA, com certeza, e talvez ainda mais em outros países.

Isso é ruim, mas é como o mercado de trabalho funciona agora. Pode mudar nas próximas décadas. Pode não mudar.

É por isso que eu sempre encorajo pessoas que estão na adolescência e chegando aos 20 anos de idade a considerarem seriamente obter um diploma de bacharelado.

Não é por causa de nenhuma das coisas que as universidades fazem propaganda a respeito:

A própria educação (você pode fazer cursos de algumas das melhores universidades on-line de graça, então isso por si só não justifica o alto custo da mensalidade).
A "experiência universitária" de morar em um dormitório, fazer novos amigos e autodescoberta (a maioria dos estudantes universitários dos EUA nunca moram no campus, então eles realmente não têm isso de qualquer forma).
Cursos de educação geral que ajudam a deixar um indivíduo "redondinho" (já ouviu falar das "Freshman 15"? É uma piada, é claro, mas muitos calouros universitários realmente ganham peso devido ao estresse da experiência).

Nota da tradução: "Freshman 15" pode ser traduzido livremente como "as 15 do calouro". "As 15", nesse caso, refere-se as 15 libras (cerca de 7 quilos) que o calouro ganha de peso devido ao estresse do primeiro ano da faculdade.

Novamente, o verdadeiro valor de obter um diploma de bacharelado – a verdadeira razão pela qual os americanos pagam 100 mil dólares ou mais por 4 anos de universidade – é porque muitos empregadores exigem diplomas.

Claro, existem outros benefícios de se ter um diploma de bacharelado, como os que mencionei: opções maiores na carreira militar e maior facilidade de se obter vistos de trabalho.

Um desses benefícios é: se você quiser se tornar um médico, dentista, advogado ou professor, você primeiro precisará de um diploma de bacharelado. Você pode, então, usá-lo para entrar na pós-graduação.

OK – isso é muita informação de fundo. Permita-me responder suas perguntas de maneira mais direta.

Você precisa de um diploma universitário para trabalhar como desenvolvedor de software?

Não. Existem muitos empregadores que o contratarão sem um diploma de bacharelado.

Um diploma de bacharelado tornará muito mais fácil conseguir uma entrevista em muitos empregadores. Também pode ajudá-lo a exigir um salário mais alto.

Nos EUA, existem também os Associate Degrees... eles valem alguma coisa?

Nota da tradução: de uma maneira MUITO resumida, quando falamos de Associate Degrees, estamos falando de algo semelhante a um curso técnico no Brasil.

Em teoria, sim. Existem alguns campos em tecnologia onde ter um Associate Degree pode ser necessário. Eu acho que sempre aumenta suas chances de conseguir uma entrevista.

Dito isso, eu não recomendaria ir para a universidade com o objetivo específico de obter um Associate Degree. Eu encorajaria 100% a permanecer na faculdade até obter um diploma de bacharelado, que é infinitamente mais útil.

De acordo com o Departamento de Educação dos EUA, ao longo de sua carreira, ter um diploma de bacharelado fará você ganhar 31% mais do que apenas ter um Associate Degree.

Confio no fato de que essa diferença é muito maior com um bacharelado em Ciência da Computação.

Vale a pena ir para a universidade para obter um diploma de bacharelado mais tarde na vida, se você ainda não tiver um?

Digamos que você está na casa dos 30 anos. Talvez você tenha frequentado alguns cursos de faculdade ou universidade. Talvez você tenha concluído os primeiros dois anos e tenha conseguido um Associate Degree.

Faz sentido voltar "às aulas" no sentido formal?

Sim, pode fazer sentido.

Não acho que faça sentido, porém, largar o emprego para voltar a estudar em tempo integral.

O estilo de vida de estudante em tempo integral é realmente projetado para estudantes "tradicionais" em mente. Ou seja, pessoas entre 18 e 22 anos (ou um pouco mais velhas se serviram nas forças armadas), que ainda não entraram na força de trabalho senão em empregos que exigem apenas o ensino médio ou nos conhecidos empregos de verão.

Universidades tradicionais custam muito dinheiro para frequentar. A suposição é a de que os estudantes pagarão por meio de uma combinação de bolsas de estudo, fundos familiares e empréstimos estudantis.

Como adulto trabalhador, você terá menos acesso a essas fontes de financiamento. Além disso, você terá menos tempo livre do que alguém que recém saiu do ensino médio teria.

Em vez de frequentar uma universidade tradicional, recomendo que pessoas com mais de 30 anos frequentem uma das universidades on-line sem fins lucrativos. Duas que têm boas reputações e cujas taxas são bastante razoáveis são a Western Governor's University e a University of the People.

Você também pode encontrar uma community college local ou um programa de extensão universitária estadual que ofereça diplomas. Muitos desses programas são on-line. Alguns deles são até autoguiados, para que você possa concluir os cursos conforme sua agenda de trabalho permitir.

Faça sua pesquisa. Se uma escola parecer promissora, recomendo encontrar um ex-aluno dela no LinkedIn e entrar em contato. Pergunte a ele sobre suas experiências e se acha que valeu a pena.

Recomendo não contrair nenhuma dívida para financiar seu diploma. É muito melhor frequentar uma escola mais barata. Afinal, um diploma é um diploma. Contanto que seja de uma instituição credenciada, deve ser suficiente para a maioria das finalidades.

Se você já tem um bacharelado, faz sentido voltar e conseguir um segundo bacharelado em Ciência da Computação?

Não. Segundos bacharelados quase nunca valem o tempo e o dinheiro.

Se você tem qualquer bacharelado – mesmo que seja em uma área não relacionada às ciências exatas – você já obteve a maior parte do valor que obteria da universidade.

Que tal um mestrado em Ciência da Computação?

Eles podem ser úteis para o avanço na carreira, mas você deve buscá-los mais tarde, depois de já estar trabalhando como desenvolvedor.

Muitos empregadores pagarão pela educação contínua de seus funcionários.

Um programa que muitos dos meus amigos na área de tecnologia frequentaram é o mestrado em Ciência da Computação da Georgia Tech.

O departamento de Ciência da Computação da Georgia Tech está entre os melhores dos EUA. Esse programa de mestrado não é apenas totalmente on-line, mas também é bastante acessível.

Eu não recomendaria fazer isso agora. Primeiro, concentre-se em conseguir um emprego como desenvolvedor (falaremos sobre isso mais detalhadamente mais adiante neste livro).

Os diplomas continuarão a ser importantes no futuro?

Sim, acredito que os diplomas universitários continuarão a ser importantes por décadas – e possivelmente séculos – no futuro.

Os diplomas universitários existem há mais de mil anos.

Muitas das principais universidades dos EUA são mais antigas do que os próprios EUA (Harvard tem mais de 400 anos).

A morte do diploma universitário é muito exagerada.

Tornou-se popular em alguns círculos criticar as universidades e dizer que os diplomas não importam mais.

Se você observar as estatísticas, no entanto, isso claramente não é verdade. Eles têm um impacto nos ganhos ao longo da vida.

Além disso, eles podem abrir carreiras que são mais seguras, mais estáveis e, no final das contas, mais gratificantes.

Claro, você pode ganhar muito dinheiro trabalhando em plataformas de petróleo em alto mar, por exemplo.

Você, porém, pode ganhar um ótimo dinheiro igualmente trabalhando como desenvolvedor em um escritório com controle de clima, assistindo servidores e corrigindo bases de código.

Um desses trabalhos é perigoso e exaustivo. O outro é um trabalho que você poderia fazer confortavelmente por 40 anos.

Muitos dos "líderes de pensamento" que criticam as universidades tiraram proveito de uma educação universitária.

Uma razão pela qual muitas pessoas acham que os diplomas são "inúteis" é o fato de que é difícil separar o aprendizado do impulso no status que você recebe.

A universidade é apenas uma forma de sinalização de classe – uma maneira para os ricos continuarem a passar vantagem para seus filhos, talvez. Afinal, há três vezes mais chances de se encontrar uma criança rica em Harvard do que uma criança pobre.

O fato é que a vida é fundamentalmente injusta, mas isso não muda o funcionamento do mercado de trabalho.

Você pode escolher o modo fácil e terminar um diploma que dará a você mais opções no futuro.

Ou você pode escolher o modo difícil, potencialmente economizar tempo e dinheiro, e apenas ser mais seletivo sobre os empregadores para os quais você se candidata.

Tenho muitos amigos que usaram as duas abordagens com grande sucesso.

Quais são as alternativas a um diploma universitário?

Trabalho com educação de adultos há quase duas décadas e ainda não vi um substituto convincente para um diploma universitário.

Claro – existem programas de certificação e bootcamps.

Eles, porém, não têm o mesmo peso com os empregadores e raramente são tão rigorosos.

Nota: quando digo "programas de certificação" refiro-me a um programa onde você participa de um curso e depois obtém uma certificação no final. Eles têm valor limitado, mas certificações baseadas em exames de empresas como a Amazon e a Microsoft são bastante valiosas. Discutiremos isso detalhadamente mais adiante.

O que digo às pessoas é: graduar-se ou não graduar-se – essa é a questão.

Conheço muitas pessoas que são mecânicos, eletricistas ou que fazem algum outro tipo de serviço e que não têm um bacharelado. Eles claramente podem aprender um conjunto de habilidades, aplicá-las e manter um emprego.

Conheço muitas pessoas que são contadores, assistentes jurídicos e outros "trabalhadores do conhecimento" que não têm um bacharelado. Eles claramente podem aprender um conjunto de habilidades, aplicá-las e manter um emprego.

Em muitos casos, essas pessoas podem simplesmente aprender a programar sozinhas, usando recursos de aprendizado gratuitos e interagindo com pessoas de mentalidade semelhante.

Algumas dessas pessoas sempre tiveram o objetivo pessoal de voltar e concluir seu bacharelado. Esse é um bom motivo para fazê-lo.

Se você quer uma educação formal, vá para a graduação. Se você não quer uma educação formal, não a faça. Apenas aprenda por conta própria.

A principal coisa que bootcamps e outros programas de certificação vão dar a você é estrutura e um pouco de pressão dos colegas. Isso não é uma coisa ruim, mas vale a pena pagar milhares de dólares por isso?

Como ser um autodidata em programação

A maioria dos desenvolvedores são autodidatas. Mesmo os desenvolvedores que se formaram em Ciência da Computação ainda frequentemente se descrevem como "autodidatas" em pesquisas do setor, como a pesquisa anual do Stack Overflow.

stack-overflow — *A maioria dos desenvolvedores em atividade se considera "autodidata" (Imagem: pesquisa do Stack Overflow, 2016)*

Isso acontece porque aprender a programar é um processo de vida inteira. Há constantemente novas ferramentas para aprender, novos códigos legados para mapear e novos problemas para resolver.

Então, quer você busque uma educação formal ou não, saiba disso: você precisará se tornar um bom autodidata.

O que significa ser um desenvolvedor "autodidata"?

Não querendo ser pedante, mas quando me refiro a autodidatismo, quero dizer aprendizagem autodirigida – aprendizado fora da educação formal.

Muito poucas pessoas são verdadeiramente "autodidatas" em qualquer coisa. Por exemplo, Isaac Newton aprendeu Cálculo sozinho porque não havia livros de Cálculo. Ele teve que descobrir e inventar à medida que avançava.

Da mesma forma, Ada Lovelace aprendeu programação sozinha porque, antes dela, não havia programação. Ela a inventou.

Alguém pode te dizer: "Você não é realmente autodidata porque aprendeu com livros ou cursos on-line. Então, você teve professores". Eles estão corretos, mas apenas no sentido mais estrito.

Se alguém tiver problemas com você se chamando de autodidata, basta dizer: "Pelos seus padrões, ninguém que não foi criado por lobos pode alegar ser autodidata em qualquer coisa".

Indique a eles esta seção do livro e diga: "Quincy antecipou seu esnobismo." Depois, siga em frente com sua vida.

Afinal, a vida é muito curta, certo?

Você é autodidata.

O que é aprendizagem autodirigida?

Como autodidata, você vai selecionar seus próprios recursos de aprendizagem. Você vai escolher o que aprender e de onde. Essa é a essência da "aprendizagem autodirigida."

Como saber, porém, se você está aprendendo as habilidades certas e usando os recursos adequados?

Bem, é aí que entra a comunidade.

Existem muitas comunidades de aprendizes ao redor do mundo, todas ajudando umas às outras a expandir suas habilidades.

Comunidade é uma palavra difícil de definir. A parte do Twitter de tecnologia é uma comunidade? O fórum do freeCodeCamp é? Que tal os muitos grupos do Discord e subreddits dedicados a conjuntos de habilidades específicas em programação?

Considero todas essas comunidades. Se há pessoas que regularmente frequentam e se ajudam mutualmente, acho que estamos falando de uma comunidade.

Os eventos presenciais também são? O encontro mensal de desenvolvedores Ruby em Oakland é? O encontro da comunidade de startups de Nova York? O grupo de usuários de Linux do Texas Central?

Essas comunidades podem ser on-line, presenciais ou uma combinação de ambos.

Falaremos mais sobre comunidades no capítulo sobre como construir sua rede de contatos. O ponto mais importante é: os novos amigos que você encontra nessas comunidades podem ajudar você a restringir suas opções sobre o que aprender e sobre quais recursos utilizar.

Qual linguagem de programação devo aprender primeiro?

A resposta curta é: não importa, na verdade. Uma vez que você aprendeu bem uma linguagem de programação, fica muito mais fácil aprender a sua segunda linguagem.

Existem diferentes tipos de linguagens de programação, mas hoje a maioria do desenvolvimento é feito usando "linguagens de script de alto nível", como JavaScript e Python. Essas linguagens trocam a eficiência bruta que você obtém com "linguagens de programação de baixo nível", como C, pelo que elas ganham em troca: o benefício de serem muito mais fáceis de usar.

Os computadores de hoje são bilhões de vezes mais rápidos do que eram nos anos 1970 e 1980, quando as pessoas escreviam a maioria de seus programas em linguagens como o C. Esse poder mais do que compensa a relativa ineficiência das linguagens de script.

Vale notar que tanto JavaScript quanto Python são escritos em C, e estão ficando mais rápidos a cada ano, graças às suas grandes comunidades de contribuintes de código aberto.

O Python é uma linguagem poderosa para computação científica (Ciência de Dados e Aprendizado de Máquina).

O JavaScript... bem, o JavaScript pode fazer de tudo. É a linguagem de programação canivete suíço definitiva. JavaScript é a fita adesiva que mantém a World Wide Web unida.

"Qualquer aplicação que possa ser escrita em JavaScript, eventualmente será escrita em JavaScript." – Lei de Atwood (Jeff Atwood, fundador do Stack Overflow e Discourse)

Você poderia programar sua carreira inteira em JavaScript e nunca precisaria aprender uma segunda linguagem. (Dito isso, você vai querer aprender Python mais tarde, e talvez algumas outras linguagens também.)

Então, eu recomendo começar com JavaScript. Além de ser muito mais fácil de usar do que linguagens como Java e C++, é mais fácil de aprender, também. Há muito, muito mais vagas de emprego para pessoas que sabem JavaScript.

Find_Javascript_Jobs_with_great_pay_and_benefits_in_United_States___Indeed_com_-- — *Uma captura de tela do site de busca de empregos Indeed. Minha busca por "javascript" para os EUA rendeu 68.838 vagas de emprego.*

Você pode aprender um pouco de HTML e CSS em uma única tarde. Como a maioria das ferramentas que menciono aqui, são fáceis de aprender, mas difíceis de dominar.

Você também vai querer aprender a usar Linux. O Linux alimenta a grande maioria dos servidores do mundo, e você passará grande parte da sua carreira executando comandos na linha de comando do Linux.

Se você tem um Mac, o MacOS tem um terminal que aceita quase todos os mesmos comandos que o Linux (MacOS e Linux têm um ancestral comum no Unix).

Se você está em um PC com Windows, você vai querer instalar o WSL, o Windows Subsystem for Linux. Você poderá então executar comandos do Linux no seu PC. Se você estiver querendo arriscar, pode até usar dual boot nos sistemas operacionais Windows e Linux no mesmo computador.

Se você vai instalar Linux em um computador, eu recomendo começar pelo Ubuntu. É a distribuição Linux mais amplamente usada (e amplamente documentada). Portanto, deve ser a mais indulgente.

Não se engane – o Linux é um pouco mais difícil de usar do que o Windows e o MacOS, mas o que você ganha em troca de seus esforços é um sistema operacional extremamente rápido, seguro e altamente personalizável.

Além disso, você nunca mais precisará pagar por uma licença de sistema operacional. A menos que você queira. A Red Hat é uma empresa de bilhões de dólares, embora seu software seja de código aberto, porque as empresas pagam por sua ajuda na manutenção e suporte dos servidores Linux.

Você também vai querer aprender Git. Esse sistema de controle de versão é como equipes de desenvolvedores coordenam suas mudanças em uma base de código.

Você pode ter ouvido falar do GitHub. É um site que facilita a colaboração de desenvolvedores em projetos de código aberto. Ele também estende algumas das funcionalidades do Git. Você aprenderá mais sobre o GitHub no capítulo sobre "como construir sua reputação" mais adiante.

Você vai querer aprender SQL e como funcionam os bancos de dados relacionais. Eles são os pilares da economia da informação.

Você também ouvirá muito sobre bancos de dados NoSQL (bancos de dados não relacionais, como bancos de dados de grafos, bancos de dados de documentos e armazenamento de pares chave-valor). Você pode aprender mais sobre eles mais tarde, mas foque no SQL primeiro.

Finalmente, você vai querer aprender como servidores web funcionam. Você vai querer começar com Node.js e Express.js.

Quando você ouvir o termo "desenvolvimento full-stack", ele se refere a ligar o front-end (HTML, CSS e JavaScript) com o back-end (Linux, bancos de dados SQL e Node + Express).

Existem muitas outras ferramentas que você vai querer aprender, como React, NGINX, Docker e bibliotecas de testes. Você pode aprender essas conforme avançar.

As habilidades fundamentais em que você deve gastar 90% do seu tempo de aprendizado pré-emprego, no entanto, são:

HTML
CSS
JavaScript
Linux
Git
SQL
Node.js
Express.js

Se você aprender essas ferramentas, pode criar a maioria das principais aplicações web e móveis. Também estará capacitado para a maioria dos empregos de desenvolvedor de nível iniciante (claro, muitas descrições de trabalho incluirão outras ferramentas, mas discutiremos essas mais tarde no livro).

Então, você deve estar pensando: ótimo. Como eu aprendo essas?

Onde eu aprendo a programar?

Engraçado você perguntar. Existe um currículo completo projetado por engenheiros de software e professores experientes. Ele é projetado com adultos ocupados em mente. É completamente gratuito e autopautado.

Isso mesmo. Estou falando do currículo principal do freeCodeCamp. Ele ajudará você a aprender:

Desenvolvimento para front-end
Desenvolvimento para back-end
Matemática de engenharia
e computação científica (com Python para Ciência de Dados e Machine Learning)

Até o momento, milhares de pessoas passaram por esse currículo principal e conseguiram um emprego como desenvolvedor. Eles não precisaram largar seus empregos diários, contrair empréstimos ou realmente arriscar qualquer coisa além de algumas de suas noites e finais de semana.

Na prática, o freeCodeCamp se tornou o caminho padrão para a maioria das pessoas que estão aprendendo a programar sozinhas.

Se nada mais, o currículo principal do freeCodeCamp pode ser sua "base" para aprender – e você pode se ramificar a partir daí. Você pode aprender as habilidades fundamentais que a maioria dos empregos exige, além de se aventurar em tecnologias que interessem a você.

Há décadas de livros e cursos para aprender. Alguns estão disponíveis na sua biblioteca pública, ou através de serviços de assinatura mensal. Você também pode acessar alguns desses serviços de assinatura gratuitamente através da sua biblioteca.

Além disso, o freeCodeCamp agora tem quase mil cursos gratuitos de longa duração sobre tudo, desde preparação para certificação da AWS até desenvolvimento de aplicações móveis e Kali Linux.

Nunca foi tão fácil aprender programação por conta própria.

Construir suas habilidades é um esforço contínuo

Conversamos sobre por que o autodidatismo provavelmente é o melhor caminho, e sobre como seguir por ele.

Conversamos sobre as alternativas ao autodidatismo, como obter um bacharelado em Ciência da Computação ou um mestrado.

Conversamos também sobre quais ferramentas específicas você deve se concentrar em aprender primeiro.

Agora, vamos mudar de assunto e falar sobre como construir a segunda perna do seu tripé: sua rede de contatos.

Capítulo 2: como construir sua rede de contatos

"Se você quer ir rápido, vá sozinho. Se você quer ir longe, vá acompanhado." – provérbio africano

"Networking" – você pode fazer uma careta ao ouvir essa palavra.

Networking pode trazer à mente festas com muito álcool – onde você finge estar interessado em um esporte que você nem segue.

Networking pode trazer à mente desejar "feliz aniversário" para pessoas que você mal conhece no LinkedIn, ou curtir suas atualizações de status esperando que elas percebam você.

O networking, contudo, não precisa ser assim.

Neste capítulo, vou contar tudo o que aprendi sobre conhecer pessoas. Vou mostrar como ganhar sua confiança e estar no topo de suas mentes quando estiverem procurando por ajuda.

Pois, no fim das contas, é disso que se trata: ajudar as pessoas a resolverem seus problemas, ser útil para as pessoas.

Vou mostrar para você como construir uma rede pessoal robusta e que apoiará você por décadas.

Hora da história: como um professor na casa dos 30 anos construiu uma rede de contatos em tecnologia?

No capítulo anterior, em Hora da História: Quincy aprendeu um pouco de programação lendo livros, assistindo a cursos on-line gratuitos e passando tempo com desenvolvedores no Hackerspace local. Ele tinha acabado de construir seu primeiro projeto e dado sua primeira palestra técnica...

OK – então, eu já tinha algumas habilidades rudimentares em programação. Eu podia programar para além da minha zona de conforto.

Qual era o próximo passo? Afinal, eu era totalmente estranho ao mundo da tecnologia.

Bem, embora eu fosse novo em tecnologia, eu não era novo no trabalho. Eu coloquei comida na mesa por quase uma década trabalhando em escolas e ensinando inglês.

Como professor, eu era pago para transmitir conhecimento. Como desenvolvedor, eu seria pago para programar.

Eu já sabia uma verdade muito importante sobre a natureza do trabalho: o que importa é quem você conhece.

Eu conhecia o poder das redes. Eu sabia que o caminho para a oportunidade passava diretamente pelos porteiros.

Tudo o que estava entre mim e um emprego lucrativo de desenvolvedor era um gerente de contratação que pudesse dizer: "Sim. Esse cara, o Quincy, parece alguém digno de se juntar à nossa equipe."

Claro, sendo um estranho na tecnologia, eu não conhecia a cultura.

A cultura acadêmica é muito mais formal.

Você usa um terno.

Você usa uma terminologia acadêmica sofisticada para demonstrar que faz parte do "grupo de elite."

Você acha maneiras de inserir em todas as conversas que você foi para a universidade X, ou que foi assistente do Dr. Y, ou que foi publicado na Revista Científica Z.

Progressões de carreira são diferentes. Conferências são diferentes. Estruturas de poder são diferentes.

Eu não percebi isso imediatamente.

Nos primeiros eventos tecnológicos em que fui, eu usei um terno.

Eu mantinha cópias do meu currículo no meu bolso o tempo todo.

Eu até carregava cartões de visita. Eu tinha encomendado folhas de alumínio anodizado e usado um cortador a laser para gravar meu nome, endereço de e-mail e até uma citação do lendário educador John Dewey:

"Qualquer pessoa que tenha começado a pensar coloca uma parte do mundo em risco." – John Dewey

Ainda é minha citação favorita até hoje – mas um pouco exagerada, não?

"Oi, eu sou o Quincy. Aqui está meu cartão de visita de alumínio vermelho. Desculpe antecipadamente – ele pode disparar o detector de metais no seu voo de volta para casa."

Eu estava forçando muito a barra. Provavelmente, isso era dolorosamente aparente para todos com quem eu falava.

Fui no Meetup.com e confirmei presença em todos os eventos de desenvolvedores que pude encontrar. Santa Bárbara é uma cidade pequena, mas fica perto de Los Angeles. Então, fiz a viagem para eventos lá também.

Rapidamente, me tornei mais esperto e troquei meu terno por jeans e um moletom com capuz. Percebi que ninguém mais distribuía cartões de visita. Então, parei de carregá-los.

Peguei dicas dos desenvolvedores que conheci no hackerspace: Seja apaixonado, mas discreto. Mantenha um pouco do seu entusiasmo guardado.

Li muitos livros para entender melhor a cultura dos desenvolvedores.

The Coders at Work é um bom livro dos anos 1980.

Hackers: Heroes of the Revolution é um bom livro dos anos 1990.

Para um recurso cultural mais contemporâneo, confira a série de TV Mr. Robot. Seus personagens são um pouco extremos, mas fazem um bom trabalho ao capturar a mentalidade e os modos de muitos desenvolvedores.

Logo, eu estava falando menos como um professor e mais como um desenvolvedor. Eu não destoava de maneira tão constrangedora.

Várias vezes por semana eu participava de eventos locais relacionados à tecnologia. Meu evento favorito nem era um evento de desenvolvedores. Era a noite das startups de Santa Bárbara. Uma vez a cada poucas semanas, eles tinham um evento onde desenvolvedores apresentavam seus protótipos. Alguns dos desenvolvedores que demonstravam seu código até conseguiram financiamento de investidores-anjo – pessoas ricas que investem em empresas em estágio inicial.

O cara que organizava o evento se chamava Mike. Ele devia conhecer todos os desenvolvedores e empreendedores de Santa Bárbara.

Quando finalmente criei coragem para me apresentar ao Mike, fiquei deslumbrado. Ele era um ultramaratonista com um batimento cardíaco em repouso na casa dos 40, cabelo e barba perfeitamente cortados. Para mim, ele era o cara mais legal do planeta. Sempre impecável. Sempre respeitoso.

Mike era "não técnico". Ele trabalhava como gerente de produto. Embora soubesse muito sobre tecnologia e design de experiência do usuário, ele não sabia programar.

Às vezes, desenvolvedores desconsideravam pessoas não técnicas. "Ele é apenas um cara de negócios", diziam. Ou ainda: "ela é só uma executiva de terninho". Nunca ouvi ninguém dizer isso sobre Mike. Ele tinha o respeito de todos.

Fiz questão de observar como Mike interagia com desenvolvedores. Afinal de contas, eu não estava tão distante de ser "não técnico" eu mesmo. Eu só estava programando há alguns meses.

Vez que outra, meus velhos hábitos apareciam. Durante conversas, eu tinha a tentação de me exibir com relação ao que já havia aprendido ou criado.

Muitos desenvolvedores são modestos sobre suas habilidades ou conquistas. Eles podem dizer: "Eu brinco um pouco com Python." O pequeno e inseguro eu já abria a grande boca e dizia: "Ah, é. Eu programei muita coisa em Python. Eu escrevo em Python até dormindo."

Depois, eu ia para casa e pesquisava no Google o nome do desenvolvedor com quem havia conversado, e percebia que ele era um colaborador principal de uma grande biblioteca em Python – e me repreenderia pelo resto do dia.

Eu rapidamente aprendi a não me vangloriar das minhas conquistas ou habilidades. Há uma boa chance de que a pessoa com quem você está falando possa programar muito melhor que você, mas a maioria deles nunca fala sobre esse fato.

Não há nada pior do que abrir o laptop com confiança, mostrar seu código e então alguém te fazer uma série de perguntas para as quais você está totalmente despreparado para responder.

Meus primeiros meses participando de eventos foram uma experiência humilhante, mas esses eventos me energizaram para continuar avançando com minhas habilidades.

Logo as pessoas no sul da Califórnia começaram a me reconhecer. Elas diziam: "Eu continuo te encontrando nesses eventos. Qual é o seu nome mesmo?"

Certa noite, uma desenvolvedora me disse: "Vamos nos seguir no Twitter". Eu tinha criado uma conta no Twitter a contragosto alguns dias antes, achando que era um site bobo. Quanto você realmente poderia comunicar com apenas 140 caracteres? Eu mal tinha tuitado alguma coisa, mas eu tinha uma conta no Twitter pronta, e ela de fato me seguiu.

Isso me inspirou a gastar mais tempo refinando minha presença on-line. Tornei meu LinkedIn menos formal e mais amigável. Olhei como outros desenvolvedores na comunidade se apresentavam on-line.

Dentro de alguns meses, eu conhecia pessoas de muitos campos:

desenvolvedores experientes
pessoas não técnicas ou semitécnicas que trabalhavam em empresas de tecnologia
gerentes de contratação e recrutadores
e, mais importante, meus pares que também estavam no meio da carreira e tentando entrar na tecnologia

Por que os pares eram os mais importantes? Certamente, eles seriam os menos capazes de me ajudar a conseguir um emprego, certo?

Bem, deixe-me contar um segredo para você: digamos que um gerente de contratação contrate um novo desenvolvedor, o treine, e ele se mostre realmente bom em seu trabalho. Aquele gerente de contratação vai perguntar: onde posso encontrar mais pessoas como você?

Seus pares são uma das peças mais importantes da sua rede. Muitas das minhas oportunidades de freelancer e oportunidades de entrevistas de emprego vieram de pessoas que começaram a aprender a programar na mesma época que eu.

Avançamos juntos. Éramos irmãos e irmãs de luta. Esses laços são os mais fortes.

De qualquer modo, todo esse networking ao longo dos meses acabaria resultando em uma noite em que eu entrei no bar de um hotel elegante no centro da cidade para um evento de desenvolvedores.

Isso é assunto para o próximo capítulo. Agora, vamos falar mais sobre a arte e a ciência de construir sua rede.

Tem realmente a ver com quem você conhece?

Você pode ter ouvido a expressão de que o sucesso é "menos sobre o que você sabe, e mais sobre quem você conhece."

Na prática, é uma combinação de ambos.

Sim – suas conexões podem te ajudar a conseguir o emprego dos seus sonhos. Mas se você estiver fora do que pode alcançar e se não tiver as habilidades para ter sucesso, não se sairá bem nesse papel.

Vamos assumir, contudo, que você está proativamente construindo suas habilidades. Você seguiu meu conselho do Capítulo 1. Quando é o momento certo para começar a construir sua rede?

O melhor momento para começar a construir sua rede é ontem.

Você não precisa, porém, de uma máquina do tempo para fazer isso, porque você já tem uma rede. É provavelmente muito menor do que você gostaria que fosse, mas você conhece pessoas.

Elas podem ser amigos da sua cidade natal, ou os colegas de seus pais. Qualquer pessoa que você conheça do seu passado – ainda que pouco – pode ser de grande ajuda.

Então, o primeiro passo é fazer um inventário completo das pessoas que você conhece. Não se preocupe – não estou pedindo para você entrar em contato com ninguém ainda, ou explorar seus relacionamentos pessoais.

Pense antes de agir. Formule uma estratégia.

Primeiro, vamos fazer um inventário de todas as pessoas que você conhece.

Como construir um quadro de redes pessoais

Você vai começar criando uma lista de pessoas que você conhece.

Você pode fazer isso com uma planilha ou com uma ferramenta de Gestão de Relacionamento com o Cliente (CRM, do inglês, Client Relationship Manager) como os vendedores usam, mas isso, provavelmente, é um exagero para o que estamos fazendo aqui.

Recomendo usar uma ferramenta de quadro de Kanban como o Trello, que é gratuita.

Você vai criar 5 colunas: "Em avaliação", "Para entrar em contato", "Esperando resposta", "Em contato recente" e "Ainda sem contato".

Depois, crie tags, para que você possa classificar as pessoas pelo modo como você as conhece. Aqui estão algumas ideias de tags para você: "Amigo de infância", "Amigo da família", "Ex-colega", "Colega de classe", "Amigos de eventos de tecnologia".

Agora, você pode começar a criar cartões. Cada cartão pode ser apenas o nome deles e, se você tiver tempo, pode adicionar uma foto ao cartão.

Aqui está o quadro do Trello que eu criei para dar a você uma ideia de como pode ser esse quadro de rede pessoal. Usei personagens do meu filme favorito da infância, o clássico "Tartarugas Ninja", de 1989.

Personal_Network_Board___Trello_-- — *Meu quadro de rede pessoal, com os amigos que conheci no meu trabalho paralelo de lutar contra o crime.*

Você pode percorrer suas contas de mídia social – até mesmo seus antigos anuários escolares se os tiver – e começar a adicionar pessoas.

Esse processo pode levar um ou dois dias, mas saiba que é um investimento. Você poderá usar esse quadro para o resto de sua carreira.

Você pode pensar: "Não preciso fazer isso – já tenho uma conta no LinkedIn". Ter uma conta lá pode funcionar razoavelmente bem, mas lembre-se de que o LinkedIn é um instrumento bruto. Você quer maximizar o sinal e minimizar o ruído aqui. Por isso, estou incentivando você a criar esse quadro de rede pessoal dedicado.

À medida que adicionar pessoas ao seu quadro, você pode associar tags a elas. Reserve um momento para pesquisar sobre cada uma dessas pessoas. O que elas estão fazendo atualmente? Elas têm um trabalho? Gerenciam uma empresa?

Você pode adicionar notas a cada cartão, à medida que descobrir novos fatos sobre elas. Elas recentemente participaram de uma corrida de 5 km para arrecadar fundos? A avó delas recentemente comemorou 90 anos? Esses fatos podem parecer irrelevantes, mas se a pessoa está compartilhando esses fatos nas redes sociais, significa que são importantes para elas.

Esforce-se para se interessar pelas pessoas, suas vidas diárias e aspirações. Compreendendo suas motivações e objetivos, você terá uma visão mais profunda de como pode ajudá-las.

Como disse anteriormente, a melhor forma de forjar alianças é ajudar as pessoas. Falaremos sobre isso detalhadamente em breve.

Para cada uma das pessoas que adicionar ao seu quadro de rede pessoal, considere se vale a pena entrar em contato com elas. Depois, coloque-as na coluna "Para entrar em contato" ou "Ainda sem contato".

Você pode estar se perguntando: por que a coluna se chama "Ainda sem contato"? Porque nunca se sabe quando pode ser útil conhecer alguém. Nunca subestime uma amizade ou pessoa conhecida.

Depois de preencher o quadro, colocando tags em todos e organizando-os em colunas, você está pronto para começar a entrar em contato.

Como se preparar para entrar em contato com a rede

A coisa mais importante a se ter em mente ao entrar em contato e tentar causar uma boa impressão é: mantenha-se simples.

As pessoas estão ocupadas e só conseguem se lembrar de alguns poucos fatos sobre você. Você quer resumir quem você é naquilo que é mais básico a seu respeito. A melhor maneira de se fazer isso é escrever uma biografia pessoal.

Como escrever uma biografia pessoal para as mídias sociais

Você quer que sua presença seja consistente em todas as suas contas de redes social.

Aqui está como eu me apresento:

"Me chamo Quincy e sou professor no freeCodeCamp. Eu moro em Dallas, no Texas. Posso ajudar você a aprender a programar."

É sua vez! Escreva a sua biografia. Veja se consegue reduzir para 100 caracteres ou menos. Tente evitar palavras complicadas ou jargões.

Pode ser difícil reduzir sua identidade a poucas palavras, mas esse é um processo importante.

Lembre-se: as pessoas estão ocupadas. Elas não precisam conhecer toda a sua história de vida. À medida que for conhecendo melhor essas pessoas, você gradualmente preencherá os detalhes de quem você é. À medida que elas fizerem perguntas, poderão conhecê-lo melhor com o tempo.

Falando nisso, você precisa de uma boa foto do seu rosto sorridente.

Como fazer uma foto para as redes sociais

Se você tiver dinheiro, basta encontrar um fotógrafo local e pagar para tirar algumas fotos profissionais.

Você pode até ter um amigo que gosta de fotografia e pode tirar as fotos de graça.

Eu tirei minha foto sozinho, usando o Photobooth, que vem pré-instalado no MacOS. Meu amigo passou cerca de 10 minutos ajustando o fundo e a iluminação no Photoshop. Ele pode ter deixado meus dentes um pouco mais brancos. Aqui está como ficou:

Michael_Headshot_B_W_Full_heic — *Minha foto. Eu uso essa mesma foto em todos os lugares.*

Certifique-se de sorrir com os olhos, para não parecer robótico. Melhor ainda, pense em algo realmente engraçado, como fiz aqui. O sorriso será genuíno.

Tire muitas fotos de diferentes ângulos e use a que parecer melhor em você.

Recomendo usar uma foto que se pareça com você em um dia qualquer. Não use uma foto muito photoshopada que tente maximizar sua atratividade. Você quer que as pessoas em eventos o reconheçam pela foto, não quer intimidar as pessoas com sua beleza. Você quer deixá-las à vontade.

Falando em deixar as pessoas à vontade: não use óculos escuros, nem tente parecer descolado demais. Você quer parecer amigável e acessível. Um bom teste para isso é: olhe para sua foto. Se você estivesse perdido e visse essa pessoa na rua, teria coragem de pedir informações?

Depois de escolher a foto do perfil, use a mesma foto em todos os lugares. Coloque-a em todas as suas contas de redes sociais.

Use-a no seu site pessoal. Adicione a foto de perfil à sua conta de e-mail (texto em inglês).

Recomendo usar essa mesma foto por anos. Toda vez que você a mudar, corre o risco de algumas pessoas não o reconhecerem imediatamente. Mesmo mudanças sutis na iluminação, ângulo ou fundo podem atrapalhar a familiaridade das pessoas.

Certifique-se de manter uma versão em alta definição da foto. Assim, as pessoas podem usá-la para promover sua palestra na conferência delas ou sua aparição como convidado no podcast delas (não se preocupe – com o tempo, você chegará lá).

Como entrar em contato com pessoas de seu passado

Agora que você organizou sua biografia e fotos, está pronto para começar a falar com as pessoas.

Há 15 anos, eu diria que você deve ligar para as pessoas em vez de enviar mensagens, mas a cultura mudou muito com a introdução dos smartphones. A maioria das pessoas não responderá bem a uma ligação.

Você precisa ir direto ao ponto – e fazer isso rapidamente.

Então, qual é esse ponto ao qual você precisa chegar?

Essencialmente:

Eu te conheço
Gosto de você
e respeito o trabalho que você está fazendo.

É isso.

As pessoas gostam de ser conhecidas. Elas gostam de ser apreciadas. Gostam que seu trabalho e que sua vida que vivem sejam notados.

A maioria de nós recebe reconhecimento em nossos aniversários. Pessoas do nosso passado podem enviar mensagens de "feliz aniversário", fazer publicações nas redes sociais ou até nos ligar.

Porém, nos outros 364 dias do ano, as pessoas também gostam de ser reconhecidas.

Bem, aqui está uma maneira simples de você reconhecer as pessoas.

Passo 1: Pesquise a pessoa no Google. Leia suas publicações recentes nas redes sociais. Leia seu LinkedIn. Se eles publicarem fotos de família, realmente dedique um tempo para olhá-las.

Passo 2: Pense em algo que você poderia dizer que possa alegrar o dia deles um pouco mais.

Passo 3: Escolha uma plataforma de rede social na qual eles estiveram recentemente ativos. Envie uma mensagem direta.

Vou compartilhar um modelo, mas nunca use modelos literalmente, pois se o destinatário colocar sua mensagem no Google, ele descobrirá que é um modelo, e toda sua boa vontade será desperdiçada.

Se eu estivesse enviando uma mensagem para alguém com quem não falo há alguns meses ou anos, eu diria algo como:

"Oi [nome], espero que seu(s)/sua(s) [ano novo/férias/semana] esteja começando de uma maneira divertida. Parabéns pelo/pela [novo trabalho/promoção/novo bebê/projeto concluído]. É inspirador ver você fazendo as coisas acontecerem."

Algo curto e direto assim. Saudação + parabéns + elogio. Essa é a fórmula básica.

Não diga apenas por dizer. Queira realmente que essa pessoa se sinta reconhecida. Queira realmente alegrar o dia dela. Queira realmente encorajá-la a continuar progredindo em direção aos seus objetivos.

Os seres humanos são muito bons em detectar falta de sinceridade. Não tente exagerar. Não dê a eles qualquer razão para pensar "essa pessoa quer algo de mim".

É por isso que o mais importante é: seja breve. Respeite o tempo das pessoas. Ninguém quer uma carta longa que se sinta obrigado a responder longamente.

Isso ocorre porque – repita comigo novamente – as pessoas estão ocupadas.

Como construir conexões ainda mais profundas

Como as pessoas estão ocupadas, elas frequentemente são tentadas a ver estranhos mais pelo que esses estranhos podem fazer por elas:

Essa pessoa dirige o ônibus que me leva ao trabalho.
Essa pessoa faz minha bebida exatamente do jeito que eu gosto.
Essa pessoa no RH responde minhas perguntas sobre folgas.
Essa pessoa montou uma playlist incrível de jazz para eu ouvir enquanto programo.
Essa pessoa me envia e-mails úteis todas as semanas com recursos grátis de programação.

Até certo ponto, você é o que você faz pelas pessoas.

Eu sei, eu sei. Isso pode parecer excessivamente simplista. Cínico até. Isso definitivamente não é verdade para as amizades próximas e familiares na sua vida.

Porém, para as pessoas que mal conhecem você – que apenas encontram você e depois seguem com suas vidas – é provável que elas vejam você dessa maneira.

Você precisa dar às pessoas uma razão para se importarem com você. Você precisa inspirá-las a aprender mais sobre você.

Antes que você possa se tornar um amigo próximo de alguém – alguém com quem eles realmente se importam e em quem eles pensam quando você não está por perto – você precisa começar sendo uma pessoa útil para eles.

É isso que vamos fazer aqui. Vamos construir relacionamentos ainda mais profundos oferecendo ajuda às pessoas.

Será um processo longo. Você deve começar bem antes da sua busca por emprego. A última coisa que você quer é que alguém pense "Ah, você só está entrando em contato porque precisa de algo de mim".

Pelo contrário – você está entrando em contato porque tem algo a oferecer para eles.

Afinal de contas, você possui um dos conjuntos de habilidades mais poderosos que uma pessoa pode adquirir. A capacidade de fazer com que as máquinas obedeçam à sua vontade. Você é um programador.

c_BasicProgramming_Picture_front — Essa é a sensação de se sentir bom em programação!

Ou, pelo menos, você está no caminho para se tornar um.

Então, você já tem um bom pretexto para entrar em contato com as pessoas.

Você pode ter ouvido o termo "cold call" (ligação fria). É quando você liga para alguém sabendo quase nada sobre ela e tenta vender algo. Não é fácil. A grande maioria das cold calls termina com a outra parte desligando.

No entanto, quanto mais informações você souber sobre a outra pessoa, mais "quente" a ligação (ou contato) fica e mais chances você tem de ter sucesso.

Você não está vendendo nada nesse caso. Como mencionei antes, você também não está ligando. Você está enviando uma mensagem direta.

Talvez seja pelo Twitter, LinkedIn, Discord, Reddit – onde quer que seja. Você, porém, está entrando em contato com elas com um único parágrafo de texto.

Como eu disse, o movimento inicial mais forte – a abordagem que provavelmente terá mais chance de obter uma resposta – é oferecer ajuda casualmente.

Se eu estivesse fazendo isso, aqui está um modelo simples que eu usaria. Lembre-se de não usar esse modelo literalmente. Reescreva em sua própria voz, como você faria ao falar com um amigo:

"Oi [nome], parabéns pelo/pela [novo trabalho/promoção/novo bebê]. Tenho aprendido um pouco de programação e estou construindo meu portfólio. Você foi uma das primeiras pessoas que veio à minha mente como alguém que realiza muitas coisas. Existe algum tipo de ferramenta ou aplicação que facilitaria sua vida? Talvez eu possa programá-la para você, como prática."

Esse é o motivo pelo qual eu envio todas as minhas mensagens manualmente e não confio em automação. É melhor compor mensagens lentamente, uma a uma, do que tentar economizar tempo com um script ou uma mala direta.

A maneira mais rápida de ser bloqueado é enviar uma mensagem com "Oi, como está indo?" onde claramente falta um nome – evidência de que a mensagem é um modelo.

Às vezes, recebo uma mensagem usando meu sobrenome em vez do meu primeiro nome. "Oi, Larson." Fico pensando se estou em uma escola militar agora.

Muitas pessoas no LinkedIn começaram a colocar um emoji no início do nome. Isso facilita a detecção de mensagens automatizadas, porque ninguém incluiria esse emoji em uma mensagem direta.

Quando uma mensagem começa com: "Oi 🍜Sarah, você está procurando um novo emprego?" Aí, você sabe que é uma mensagem em massa.

Observe também que meu modelo acima não diz "estudamos juntos" ou algo assim. A menos que você tenha conhecido alguém há poucos dias, não deve especificar como vocês se conheceram.

Por quê? Porque o próprio ato de lembrar as pessoas de como vocês se conheceram vai fazer com que algumas delas recuem e pensem: "Caramba, eu mal conheço essa pessoa."

Como manter a conversa

Novamente, seu objetivo é obter uma resposta deles, para que você possa iniciar uma conversa de fato.

Essas plataformas de mensagens têm uma sensação de informalidade. Mantenha essa sensação.

Não envie uma mensagem única e longa de vários parágrafos. Mantenha suas mensagens curtas e rápidas. Você não quer que pareça uma tarefa árdua responder a você.

Uma vez que estejam respondendo, comece a fazer anotações no seu quadro de rede pessoal para se lembrar desses fatos mais tarde.

Talvez eles tenham alguma ideia de aplicação ou ferramenta. Ótimo. Pergunte a eles sobre isso. Veja se consegue criar isso para eles.

Comece esboçando um mock-up simples da interface do usuário. Use papel quadriculado se quiser parecer ainda mais sofisticado. Tire uma foto e envie para eles. "Algo assim?"

Isso estabelecerá que você realmente quer em ajudar. Eu poderia apostar que, para a maioria das pessoas, isso seria uma experiência nova.

"Você está me ajudando? Está criando isso para mim?" Será lisonjeiro, e eles provavelmente se lembrarão disso. Mesmo que a aplicação em si não vá a lugar nenhum.

A partir daí, você pode seguir com o fluxo da conversa. Talvez a conversa esfrie. Tudo bem. Deixe. Você pode encontrar uma razão para retomar a conversa algumas semanas depois.

A grande vantagem dessas mensagens diretas em redes sociais é que todo o histórico da mensagem está ali. Na próxima vez que você enviar uma mensagem, eles podem simplesmente rolar para cima e ver "ah – essa é a pessoa que se ofereceu para criar aquela aplicação para mim". Não há mais aquelas inclinações de cabeça do tipo "quem é você mesmo?" que você pode receber em conversas presenciais.

Novamente, mantenha tudo informal e positivo. Se parecer que a conversa está indo devagar, não há problema. Você terá dezenas de outras conversas em andamento. Vai estar ocupado construindo sua rede.

Como conhecer pessoas novas e ampliar sua rede pessoal

Falamos sobre como entrar em contato com pessoas que você já conhece. Essas conexões ainda estão lá, mesmo que tenham atrofiado um pouco ao longo dos anos.

Você pode se perguntar: como fazer novas conexões?

Essa não é uma tarefa fácil, mas eu tenho algumas dicas que tornarão esse processo um pouco menos assustador.

Antes de tudo, encontrar pessoas pela primeira vez pessoalmente é muito mais poderoso do que conhecê-las on-line.

Quando você conhece alguém pessoalmente, sua memória tem muito mais informações para se apegar:

Como a pessoa se parece, sua postura e como ela se move pelo espaço
O som da voz dela e a maneira como ela fala
As luzes, sons, aromas, temperatura e a sensação geral do local
além de muitos outros pequenos detalhes que ficam gravados na sua memória

Passar 10 minutos conversando pessoalmente com alguém pode criar uma conexão mais profunda do que dezenas de mensagens trocadas durante semanas de correspondência.

Por isso, eu recomendo fortemente: saia e conheça pessoas em eventos locais.

Como conhecer pessoas em eventos locais pela cidade

Quais eventos? Se você vive em uma cidade densamente populada, pode ter várias opções à sua disposição. Talvez você possa ir a eventos de tecnologia várias noites por semana, com deslocamento mínimo.

Se você vive em uma cidade pequena, pode ter que se contentar em conhecer pessoas em encontros locais. Feiras de livros, encontros sociais com sorvete, eventos esportivos.

Se você frequenta uma igreja, mesquita ou templo, conheça pessoas lá também.

Sim, eu percebo que isso pode soar ridículo. "Aquela pessoa em pé ao meu lado nas arquibancadas do jogo de futebol? De alguma forma, ela vai me ajudar a conseguir um emprego de desenvolvedor?"

Talvez. Talvez não. Apenas evite de descartar as pessoas.

Essa pessoa pode ter um pequeno negócio.

Ela pode ter estudado com um amigo que é VP de engenharia em uma empresa da Fortune 500.

Talvez – só talvez – ela também seja um engenheiro de software. Afinal, há milhões de nós, engenheiros de software, por aí – e nem todos nós vivemos no Vale do Silício. 😉

Quando você conhecer uma pessoa nova, não queira imediatamente pegar seu telefone e dizer "Posso adicionar você à minha rede profissional no LinkedIn?"

Lembre-se do nome deles. Os nomes são essenciais para construir um relacionamento. Se você tem dificuldade em lembrar nomes, pratique essa habilidade. Você pode treinar apenas tentando lembrar o nome de cada personagem – não importa se são insignificantes ou não – quando estiver assistindo a programas de TV ou filmes.

Se você esquecer o nome de alguém, não adivinhe. Apenas diga "qual é o seu nome mesmo?" e certifique-se de lembrar na segunda vez.

Aperte a mão deles ou faça aquele cumprimento com os punhos. Converse com eles sobre o que parecer natural. Se a conversa acabar, tudo bem. Deixe acabar.

Você constrói relacionamentos ao longo do tempo. Não é sobre o tempo total gasto com alguém – é sobre o número de vezes que você encontra essa pessoa ao longo de um período maior.

Há uma boa chance de você ver essa pessoa novamente no futuro, talvez no mesmo local, algumas semanas depois. É nessa hora que você age:

"Oi [nome], como vai o [assunto que vocês conversaram na última vez]?"

Continue a conversa de onde parou. Se parecer que essa pessoa poderia ser uma adição útil à sua rede pessoal, pergunte "ei, o que você está fazendo na próxima [dia da semana]? Quer vir comigo a [outro evento local próximo]?"

Sempre tenha a sua semana de eventos em mente, para que você possa convidar pessoas a se juntar a você.

Essa é uma ótima maneira de fazer com que as pessoas passem tempo com você em um espaço seguro e público. Você estará oferecendo algo de valor – dando a eles conhecimento sobre um evento próximo.

Se parecerem interessados, você pode dizer "Ótimo. Qual é a melhor maneira de eu enviar uma mensagem para você e passar os detalhes do evento?"

Aí está – você agora tem o e-mail deles, rede social ou número de telefone. Seu relacionamento pode evoluir a partir daí.

Isso pode soar como uma abordagem lenta. Por que ser tão cauteloso?

Mais uma vez, as pessoas estão ocupadas. Pessoas inteligentes defendem seu tempo e suas informações pessoais.

Existem muitos "vampiros" por aí querendo tirar vantagem das pessoas – tentando vender algo, enganá-las, inseri-las em algum esquema de marketing multinível, ou de alguma outra maneira proselitista.

A melhor maneira de ajudar as pessoas a superar essa defesa reflexiva é já estar no radar delas a partir de encontros anteriores como uma pessoa que vale a pena conversar.

Como aproveitar sua rede

Falaremos mais sobre como aproveitar a sua rede no Capítulo 4. Por enquanto, veja sua rede puramente como um investimento de tempo e energia.

Gosto de pensar na minha rede como um pomar. Estou plantando relacionamentos. Cuidando deles e garantindo que estejam saudáveis.

Quem sabe quando esses relacionamentos crescerão e darão frutos? O objetivo é continuar plantando árvores e, em algum momento no futuro, essas árvores ajudarão a sustentar você.

Continue enviando energia positiva. Continue oferecendo ajuda às pessoas usando suas habilidades e até mesmo sua própria rede. Raramente é uma má ideia fazer uma apresentação educada entre duas pessoas que você conhece.

Seja uma pessoa gentil, atenciosa e prestativa.

Nunca se sinta impaciente com a lentidão na busca por um emprego.

Nunca se sinta desconsiderado ou esnobado.

Nunca se sinta ciumento com o sucesso de outra pessoa.

O que vai, volta. Um dia você colherá o que plantou. Se você está plantando energia positiva, está se preparando para uma colheita abundante.

Capítulo 3: como construir sua reputação

"A maneira de ganhar uma boa reputação é se esforçar para ser o que você deseja parecer." – Sócrates

Agora que você começou a construir suas habilidades e sua rede, está pronto para começar a construir sua reputação.

Você pode estar começando do zero – um total novato em tecnologia – ou pode já ter alguma credibilidade que pode trazer consigo de outro emprego.

Neste capítulo, compartilharei dicas práticas sobre como você pode construir uma reputação impecável entre seus colegas. Isso será a chave para conseguir clientes freelance, um primeiro emprego e avançar na sua carreira.

Primeiro, aqui está como eu construí minha reputação.

Hora da história: como um professor de 30 e poucos anos construiu uma reputação como desenvolvedor?

Na última vez em Hora da história: Quincy começou a construir sua rede de desenvolvedores, empreendedores e gerentes de contratação em tecnologia. Ele frequentava hackerspaces e eventos de tecnologia pela cidade, mas ainda não havia entrado na arena para testar suas habilidades...

Eu já estava há vários meses em minha jornada em programação quando finalmente criei coragem para ir ao meu primeiro hackathon.

Um dia, encontrei um bug particularmente desagradável e não sabia como resolver. Então, fiz o que muita gente faria nessa situação: procrastinei navegando na web. Foi aí que vi o Startup Weekend EDU.

Startup Weekend é uma competição de 54 horas que envolve construir um aplicativo e depois apresentá-lo a um painel de juízes. Esses eventos recompensam seu conhecimento de codificação, design e empreendedorismo também.

Esse evento em particular – realizado no coração do Vale do Silício – tinha um painel de educadores e empreendedores da educação como juízes. Com minha experiência em educação de adultos, parecia ser o hackathon ideal para mim.

Contei a Steve sobre o evento. Então, disse as palavras mágicas: "Eu dirijo". O que foi bom, porque Steve não tinha carteira de motorista.

Passei semanas me preparando para o evento, pesquisando sobre os juízes e as empresas para as quais trabalhavam. Pesquisei sobre os patrocinadores. Claro, pratiquei programação como um monge Shaolin.

Finalmente, depois de um mês de preparação, chegou o grande fim de semana. Entramos no meu Toyota Corolla 2003 com o verniz descascando, colocamos uma música de alta energia e começamos nossa viagem de 5 horas.

No caminho, discutimos o que deveríamos criar. Seria focado em educação, é claro. Preferencialmente voltado para estudantes do ensino médio, já que essas eram as séries em que as empresas dos juízes estavam focadas.

O que, no entanto, a aplicação deveria fazer? Como ela tornaria a vida das pessoas mais fácil?

Pensei na minha própria época no ensino médio. Eu não tinha muito a oferecer, já que tinha abandonado os estudos depois de apenas um ano. (Consegui estudar e passar no GED – Good Enough Degree, como o chamávamos – enquanto trabalhava no Taco Bell, antes de finalmente ir para a faculdade, mas essa é outra história).

Algo que me incomodava e que eu me lembrava no ensino médio ainda ecoava depois de todos esses anos: trabalhos de inglês.

Eu adorava escrever, mas não gostava de escrever no formato MLA, com suas rígidas regras de citação. Eu costumava temer a preparação de uma página de trabalhos com citação. Meu professor sempre me descontava pontos por não formatar corretamente as citações.

Depois de ouvir muitas ideias razoáveis dos outros passageiros no carro, eu disse: "Eu tenho uma ideia. Devíamos programar uma aplicação que cria citações para você."

Alguém riu e disse: "Genial."

Steve disse: "Ei, esse é um bom nome. Poderíamos chamar de Out of Cite com 'C'."

Todos rimos e nos sentimos inteligentes. Então, começamos a discutir os detalhes da implementação.

Quando chegamos ao local, havia cerca de 100 outros desenvolvedores lá. Era um espaço de escritório de plano aberto, com cubículos baixos flanqueados por quadros brancos.

Ouvi sussurros sobre um daqueles desenvolvedores. "Ei, é aquele cara que venceu o evento no ano passado," ouvi as pessoas dizendo. Elas apontavam na direção de um desenvolvedor com uma expressão arrogante cercado de fãs. "Talvez ele me deixe fazer parte da equipe dele".

O evento começou com apresentações. Qualquer um poderia ir à frente da sala, pegar o microfone e fazer uma apresentação de 60 segundos sobre a aplicação que queria construir.

Eu estava tão nervoso que parecia que um alien estava prestes a explodir do meu peito. Então, naturalmente, fui o primeiro da fila. Resolver isso de uma vez, certo?

Eu estava suando e gesticulando freneticamente enquanto corria com minha apresentação. Eu disse algo assim: "Citações são um saco. Digo, elas não são um saco. São necessárias. Você precisa adicioná-las aos seus trabalhos, mas preparar citações é um saco. Vamos criar uma aplicação que preencha sua página de trabalhos com citação para você. Quem está comigo?"

A sala ficou quieta. Então, as pessoas perceberam que eu havia terminado de falar e me deram uma rodada de aplausos obrigatória. O MC tirou o microfone da minha mão e o entregou à próxima pessoa e eu voltei para meu assento saltitando.

Depois das apresentações, era hora de formar equipes. Nosso contingente de Santa Bárbara olhou um para o outro e disse: "Acho que somos uma equipe."

Descobrimos a senha do wi-fi e pegamos o melhor dos espaços de trabalho: um escritório de canto que tinha uma porta que você realmente podia fechar.

Comecei a rabiscar mock-ups de UI no quadro branco. Eu disse: "Queremos algo que esteja sempre a um clique de distância. Bem na barra de menu do seu navegador."

"Como um plug-in de navegador", disse Steve.

"Sim. Vamos criar um plug-in de navegador."

Mostrei a eles exemplos dos três formatos que os ensaios podem exigir: MLA, APA e Chicago.

"Poderíamos gerar todos os três de uma vez, para que possam simplesmente copiar e colar?" eu perguntei.

"Podemos fazer melhor que isso", disse Steve. "Podemos ter um botão para cada um deles que coloca a citação diretamente na área de transferência."

Trabalhamos rápido, criando um MVP (produto mínimo viável, do inglês Minimum Viable Product) simples até o final da sexta-feira à noite. Tudo o que fazia era pegar os metadados do site atual e estruturá-los como uma citação, mas funcionou.

Como era meu primeiro hackathon, eu não queria o estresse de ficar em um albergue. Então, exagerei e reservei um quarto de hotel. Tínhamos duas camas de solteiro, então, a cada noite, fazíamos rodízio para ver quem tinha que dormir no chão.

Na manhã de sábado, nossas ambições cresceram. Caminhei até o quadro branco e disse à equipe: "Citar sites é ótimo e tudo mais, mas muitas das coisas que os estudantes citam estão em livros ou trabalhos acadêmicos. Precisamos ser capazes de gerar citações para esses também."

Encontramos uma API que poderíamos usar para obter informações de citação com base no ISBN (um número de série usado para livros) e remendamos um script que poderia buscar trabalhos acadêmicos com base no DOI (um número de série usado para trabalhos acadêmicos). Em seguida, extraímos o dados da página de resultados.

Na noite de sábado, o código para nosso plug-in de navegador estava realmente ganhando forma. Então, sentei e comecei a preparar os slides de apresentação. Deixei muito da programação final para meus colegas de equipe enquanto eu ensaiava minha apresentação repetidamente por horas.

Mesmo sendo minha vez de dormir em uma cama, eu mal conseguia fechar os olhos devido ao nervosismo. Ali estava eu, bem no coração do ecossistema tecnológico. Vale do Silício.

Como professor, eu rotineiramente dava palestras na frente de meus colegas – às vezes dezenas deles – mas isso era diferente.

Incapaz de dormir, abri meu e-mail. A equipe do Startup Weekend havia enviado um e-mail, que incluía um PDF de um livro. Era uma mistura não oficial dos clássicos de startups de tecnologia 4 Steps to the Epiphany e The Lean Startup.

Eu já tinha lido esses livros, porque eram leituras obrigatórias para quem queria criar software no início dos anos 2010, mas eu também tinha lido dezenas de outros livros sobre startups. Muitas de suas percepções meio que se juntavam em uma mistura de conselhos.

Eram 4 da manhã e eu não conseguia dormir. Então, comecei a ler. Uma coisa que esses livros realmente enfatizam é construir algo pelo qual as pessoas estejam dispostas a pagar. A forma máxima de validação do cliente.

Foi quando percebi: sabe o que realmente levaria minha apresentação até a linha de chegada? Prova de ajuste do produto ao mercado. Prova de que a aplicação que estávamos construindo resolveria um problema real que as pessoas tinham, tão real que elas comprariam um produto assim.

Isso me deu uma ideia. Deveria levar nossa aplicação para a rua e "vendê-la" para as pessoas.

Só que era domingo de manhã. Onde eu encontraria potenciais clientes? Bem, nosso hotel estava localizado perto do campus principal da Universidade de Stanford.

Levei minha equipe até o local do evento, acenei e disse: "Voltarei quando tiver dinheiro de verdade dos clientes."

Meus colegas riram. Não sei se eles acharam que eu estava falando sério. Eles disseram: "Só não se atrase para a apresentação."

Eu estava falando sério. Eu tinha um protótipo da aplicação rodando no meu laptop. Digitei Stanford no meu GPS e embarquei na minha missão.

Eu estudei numa universidade estadual realmente barata em Oklahoma. Então, eu me senti realmente fora do meu elemento quando cheguei a uma das universidades mais prestigiadas do mundo.

Stanford custa 50 mil dólares por ano para frequentar. Eu entrei no estacionamento deles dirigindo um carro que valia 1/10 disso.

O campus estava uma cidade fantasma naquela hora da semana, mas uma cidade fantasma palaciana, ainda assim. Estátuas de bronze. Arcos icônicos por toda parte.

Perguntei a mim mesmo: onde estão os alunos mais dedicados a essa hora do dia, aqueles que não têm tempo a perder criando suas páginas de trabalhos com citação manualmente?

Entrei na biblioteca principal, passei pela mesa de segurança e um sinal que dizia "proibido vender".

Andei pelas estantes, encontrando um pequeno punhado de pessoas estudando. Um garoto estava diligentemente fazendo anotações enquanto lia um livro grosso. Achei!

Sentei-me ao lado dele. "Ei. Você gosta de citações?"

"O quê?"

"Citações. Você sabe, como, páginas de trabalhos com citação."

"Hum..."

"Você sabe, a última página do seu trabalho, onde você tem que listar todos os..."

"Eu sei o que é uma página de trabalhos com citação."

"OK. Bem, veja isso." Abri meu casaco como um traficante, e tirei meu netbook de $200. Ele me deu um momento enquanto eu apresentava meu discurso de vendas desajeitado.

Eu disse: "Aqui. Eu tenho esse plug-in para navegador. Eu vou a qualquer site, clico no botão e pronto. Ele cria uma citação para mim."

O garoto levantou as sobrancelhas. "Ele faz em MLA?"

Contive minha empolgação e disse: "MLA, APA e até mesmo Chicago. Veja." Cliquei no botão e três citações apareceram – cada uma com seu próprio botão de copiar para área de transferência.

O garoto acenou com a cabeça, parecendo um pouco impressionado. Então, tentei fechar a venda.

"E se eu te dissesse que estou prestes a lançar essa aplicação com uma assinatura anual? Se você se inscrever agora, terá acesso ilimitado não por um ano, mas por toda a vida."

O garoto pensou por um momento.

Eu tinha ouvido que o silêncio era o melhor amigo do vendedor. Então, fiquei ali em silêncio absoluto por um tempo desconfortavelmente longo, encarando-o.

Finalmente, ele disse: "Legal, eu topo."

"Ótimo. Serão vinte dólares."

O garoto recuou. "O quê? Isso é caro."

Claro, esta era a era das startups subsidiadas por capital de risco, onde Uber e Lyft estavam perdendo dinheiro em cada corrida numa corrida por participação de mercado. Portanto, a reação do garoto não foi totalmente surpreendente.

Eu pensei rápido: "Bem, quanto dinheiro você tem?"

Ele mexeu na carteira e, então, disse: "cinco dólares."

Olhei para a nota amassada e dei de ombros. "Vendido."

Ele sorriu, e eu enviei a ele um e-mail com instruções sobre como instalá-lo. Então eu disse, "Mais uma coisa. Vamos tirar uma foto juntos."

Coloquei meu telefone no modo selfie. Ele começou a sorrir, e eu disse, "Aqui. Segure a nota de cinco dólares."

Passei mais uma hora apresentando para pessoas na biblioteca e consegui mais um cliente pagante também. Então, corri de volta para o local do evento para finalizar nosso protótipo com a equipe.

Naquela tarde, fiz o que ainda acho que foi a melhor apresentação da minha vida. Demonstramos ao vivo a aplicação funcionando – e ela funcionou perfeitamente.

Terminamos a apresentação com as fotos que tirei, posando com estudantes de Stanford que agora eram nossos clientes pagantes. Quando levantei o dinheiro que ganhamos, a audiência aplaudiu fervorosamente.

No geral, foi uma das experiências mais emocionantes da minha vida. Ficamos em segundo lugar e ganhamos algum crédito de API de uma das empresas que patrocinou o evento.

Na festa pós-evento, comi rapidamente algumas fatias de pizza, para ter mais tempo de fazer networking com todos que pudesse. Conectei-me no LinkedIn. Segui no Twitter. Tirei selfies com pessoas e usei bastante a hashtag do evento.

Correndo o circuito de hackathons

A partir daquele momento, eu fiquei viciado em hackathons. Aquele ano, participei de dezenas deles. Tornei-me um guerreiro das estradas, subindo e descendo a costa, participando de todas as competições que eu conseguia.

A partir daí, seria muito mais difícil. Eu não tinha mais uma equipe. Estava sozinho.

Eu chegava, conhecia o máximo de pessoas que podia, subia ao palco e fazia uma proposta de ideia que achava que poderia conquistar os jurados.

Às vezes, as pessoas entravam na minha equipe. Às vezes, eu me juntava a equipes de outras pessoas.

Eu não queria apenas projetar aplicações – eu queria programá-las também. Meu alcance frequentemente superava minha compreensão.

Houve muitos hackathons onde eu ainda estava tentando corrigir bugs nos minutos finais antes de subir ao palco. Às vezes, minhas aplicações travavam durante as demonstrações ao vivo.

Em um hackathon em Las Vegas, consegui danificar tanto a base de código que tivemos que usar apenas uma apresentação de slides. Sentei na plateia com a cabeça nas mãos, assistindo impotente enquanto meu colega de equipe demonstrava como nossa aplicação funcionaria hipoteticamente – se eu tivesse conseguido fazê-la funcionar. Não nos saímos bem com os jurados.

Eu continuei perseverando. Continuava chegando em novas cidades, fazendo check-in no albergue, indo ao local do evento e comendo o máximo de pizza grátis que conseguia.

Minhas equipes já tinham ficado em segundo ou terceiro lugar tantas vezes que eu mal conseguia contar, mas nunca tínhamos conseguido vencer um hackathon.

A primeira vitória

Fui, então, a um evento em San Diego. Nunca vou esquecer a sensação de criar algo que conquistou o público e os jurados a ponto de nossa vitória parecer uma conclusão inevitável.

Depois que anunciaram nossa vitória, lembro de sair sorrateiramente pela porta dos fundos para o estacionamento e ligar para meus avós. Disse a eles que finalmente tinha conseguido. Eu tinha ajudado a construir uma aplicação e a criar uma apresentação que havia vencido um hackathon.

Não sei o quanto meus avós entendiam sobre desenvolvimento de software ou sobre hackathons, mas eles disseram que estavam orgulhosos de mim.

Com eles não estando mais aqui, muitas vezes penso nessa conversa. Valorizo o incentivo deles. A fé que tiveram em um neto de 30 e poucos anos, professor, que se esforçava ao máximo para se tornar um desenvolvedor.

Continuei indo a hackathons depois disso. Continuei formando novas equipes e aprendendo novas ferramentas ao longo do caminho. Você nunca esquece a primeira vez que consegue fazer uma API funcionar. Nem quando finalmente entende como algum comando do Git funciona. Você também nunca esquece as pessoas que se esforçam ao seu lado, tentando manter a aplicação funcionando durante a demonstração.

TechCrunch Disrupt, DeveloperWeek, ProgrammableWeb, o Prêmio de 1 milhão de dólares da Salesforce: foram vários grandes hackathons e muito aprendizado. Foi aí que minhas habilidades de desenvolvedor foram forjadas.

Não só consegui desenvolver minhas habilidades e minha rede de contatos ao longo do caminho – agora eu tinha a fama de alguém que realmente podia vencer um hackathon.

Eu podia entregar.

Isso me tornou uma figura conhecida.

Essa reputação foi crucial para conseguir meus primeiros clientes freelancers, meu primeiro emprego de desenvolvedor e, o mais importante – confiar nos meus próprios instintos como desenvolvedor.

Por que sua reputação é tão importante

O papel da reputação na sociedade remonta, e muito, aos tempos pré-históricos da humanidade. Na maioria das tribos e assentamentos, havia algum sistema para rastrear quem devia o quê a quem.

Antes de haver dinheiro, havia crédito.

Isso podia ter sido por um registro escrito, ou um ancião que simplesmente mantinha todos esses registros em sua cabeça.

Além da contabilidade bruta, havia também uma vibração menos tangível, mas igualmente importante, que as pessoas carregavam consigo.

"John realmente sabe como ferrar um cavalo."

Ou "Jane é a melhor contadora de histórias do lugar."

Ou "A coragem de Jay na batalha nos salvou dos invasores três invernos atrás."

Você notará que esses exemplos envolvem alguém ser bom em algo. Não apenas ser uma boa pessoa, agradável.

Claro que ajuda ser uma pessoa tranquila e pé no chão, mas não estamos no Grande Lebowski e não vamos sobreviver só com nosso charme.

image__2000-1338_ — *O Grande Lebowski (à esquerda). Ele não tinha emprego, não tinha habilidades, não tinha energia, mas tinha tranquilidade até não poder mais.*

É fácil para um desenvolvedor dizer: "Ah é. Eu conheço JavaScript como a palma da minha mão. Posso criar qualquer tipo de aplicação em JavaScript que você precisar, rodando em qualquer dispositivo que você imaginar."

Ou ainda: "Eu entrego código dentro do orçamento e antes do prazo – o tempo todo."

Como saber, no entanto, se eles não estão exagerando em suas afirmações?

Afinal, um homem ardiloso uma vez disse:

"Se você só pode ser bom em uma coisa, seja bom em mentir. Aí, você é bom em tudo."

(A verdadeira procedência dessa citação é desconhecida, mas gosto de imaginar que foi dita por um vigarista dos anos 1920 usando uma cartola e um monóculo).

Qualquer um pode mentir – e algumas pessoas mentem.

No início da minha carreira, tive a desagradável tarefa de demitir um professor que havia mentido sobre ter um mestrado. Os anos se passaram e ninguém percebeu.

Todo ano, ele mentia em seu formulário anual para obter um aumento maior do que os outros professores. Todo ano, ele conseguia.

Um dia, porém, uma pequena discrepância me alertou. Revisei seu arquivo, liguei para alguns departamentos de registros universitários e descobri que ele nunca tinha terminado seu curso.

Era desanimador saber que essa pessoa estava ensinando na escola há anos e recebia mais do que muitos dos outros professores – apenas porque estava disposta a mentir.

Os frutos da mentira estão sempre lá, brilhando. Algumas pessoas estão dispostas a ceder a essa tentação.

Os empregadores sabem disso. Sabem que não se pode confiar em qualquer pessoa que afirma conhecer desenvolvimento full-stack em JavaScript. É preciso ser cauteloso sobre quem recebe um crachá da empresa, um endereço de e-mail corporativo e as chaves dos bancos de dados de produção.

É por isso que os empregadores usam perguntas de entrevista comportamental – para tentar pegar pessoas que são mais capazes de desonestidade.

Chame-me de ingênuo, mas acredito que a maioria das pessoas é inerentemente boa, que a maioria das pessoas está disposta a jogar pelas regras, desde que essas regras sejam razoavelmente justas.

Porém, se contratar até mesmo uma pessoa ruim em cada dez seria desastroso, isso significa que todos nós estamos sujeitos a uma maior verificação.

O pior cenário não é apenas alguém que mente para ganhar mais dinheiro. É alguém que vende segredos da empresa, destrói relações com clientes ou infringe leis em nome de inflar seus números.

A história está repleta de funcionários que causaram danos catastróficos aos seus empregadores, tudo para ganho pessoal.

Assim, o processo de contratação de desenvolvedores na maioria das grandes empresas é excessivamente paranoico. Talvez deva ser, mas, infelizmente, isso torna mais difícil para todos conseguirem um emprego de desenvolvedor – até mesmo os candidatos mais honestos.

Como desenvolvedores, precisamos de provas de que nossas habilidades são tão fortes quanto dizemos que são. Precisamos de provas de que nossa ética de trabalho é tão firme quanto nossos empregadores precisam que seja.

É aí que entra a reputação. Reduz a ambiguidade. Reduz a parte do risco. Torna mais seguro para os empregadores fazer uma oferta de emprego e assinar um contrato de trabalho com você.

Isso significa que – se você tiver uma reputação forte o suficiente – poderá até entrar na empresa por uma porta lateral – em vez da porta da frente pela qual outros candidatos fazem fila.

Algumas empresas têm até recrutadores internos que podem acelerar seu processo de entrevista. Uma reputação forte também pode ajudá-lo a obter mais poder de negociação durante as negociações salariais.

Então, vamos falar sobre como você pode construir uma reputação forte e se tornar procurado por gerentes.

Como construir sua reputação como desenvolvedor

Existem pelo menos seis maneiras comprovadas para construir sua reputação como desenvolvedor. São elas:

Hackathons
Contribuições para o código aberto
Criação de conteúdo focado em desenvolvedores
Subir na hierarquia trabalhando em empresas com um "nome conhecido"
Construir um portfólio de clientes freelance
Iniciar seu próprio projeto de código aberto, empresa ou instituição de caridade

Como encontrar hackathons e outras competições de desenvolvedores

Hackathons representam a maneira mais imediata de construir sua reputação, sua rede e suas habilidades de programação ao mesmo tempo.

A maioria dos hackathons é gratuita e aberta ao público. Você só precisa ter tempo e orçamento para viajar.

Se você mora em uma cidade com muitos hackathons – como São Francisco, Nova York, Bengaluru ou Pequim – pode ser capaz de ir até o evento, depois voltar para casa e dormir em sua própria cama.

Embora eu morasse em Santa Bárbara, que tinha hackathons apenas uma vez a cada poucos meses, eu tinha um antigo colega de classe em São Francisco que me deixava dormir no sofá dele. Isso me dava acesso a muitos eventos.

Hackathons costumavam ser eventos pesados. As pessoas tomavam bebidas energéticas e dormiam no chão, tudo para terminar seu projeto a tempo da apresentação.

Porém, os organizadores de hackathons estão gradualmente se tornando mais conscientes sobre a saúde e sustentabilidade desses eventos. Afinal, muitos participantes têm filhos ou empregos de tempo integral exigentes e não podem programar o fim de semana inteiro sem parar.

A melhor maneira de encontrar eventos futuros é simplesmente procurar no google "hackathon [nome da sua cidade]" e navegar pelos vários calendários de eventos que surgem nos resultados da busca. Muitos desses serão organizados por universidades, empregadores locais ou até instituições de caridade focadas em educação.

Se você está jogando para ganhar, recomendo fazer sua pesquisa com antecedência.

Quem são os patrocinadores do evento? Normalmente serão empresas do tipo Business-to-Developer (B2D), com APIs, ferramentas de banco de dados ou várias ofertas de Software como Serviço.

Esses patrocinadores provavelmente terão um estande no evento onde você poderá conversar com seus defensores de desenvolvedores. Essas são pessoas pagas para ensinar aos outros como usar as ferramentas da empresa. Às vezes, você ainda encontrará funcionários chave ou fundadores nesses estandes, o que também pode ser uma ótima oportunidade de networking.

Frequentemente, o hackathon oferecerá prêmios específicos dos patrocinadores. "Melhor Uso da API [do patrocinador]." Pode ser mais fácil concentrar seu tempo em incorporar ferramentas específicas dos patrocinadores no seu projeto, em vez de tentar ganhar o grande prêmio. Você ainda pode listar essas vitórias no seu LinkedIn ou no currículo. Uma vitória é uma vitória.

Às vezes, o hackathon é tão de alto perfil – ou o prêmio é tão substancial – que faz sentido tentar ganhar a competição de qualquer forma.

Durante meu tempo participando de hackathons, consegui ganhar prêmios em dinheiro que cobriam o aluguel de vários meses, vários anos de espaço de coworking gratuito e até um tour privado pelo prédio das Nações Unidas em Nova York.

Não fique surpreso se algumas das pessoas que você encontrar frequentemente em hackathons fundarem empresas financiadas por capital de risco ou lançarem projetos de código aberto proeminentes.

O nível de ambição que você verá entre os frequentadores de hackathons é muito, muito mais alto do que o do desenvolvedor médio. Afinal, são pessoas que terminam uma semana de trabalho e vão direto para um fim de semana de trabalho. Essas pessoas não têm medo de pular da frigideira para o fogo.

Como contribuir para o código aberto

Contribuir para o código aberto é uma das maneiras mais imediatas de se construir sua reputação. A maioria dos empregadores vai olhar para o seu perfil no GitHub, que exibirá de maneira destacada seu histórico de commits do Git.

raisedadead__Mrugesh_Mohapatra__-- — O perfil GitHub de Mrugesh Mohapatra, que faz uma grande quantidade de desenvolvimento de plataforma e DevOps para o freeCodeCamp.org. Note como sua barra de atividades está verde. Foram 2.208 contribuições apenas no ano passado.

Muitos mantenedores de projetos de código aberto, como a Linux Foundation, Mozilla (Firefox) e, claro, nós mesmos do freeCodeCamp, têm padrões elevados para a qualidade do código.

Você pode ler as issues abertas no GitHub para encontrar bugs conhecidos ou pedidos de funcionalidades. Depois, você pode fazer as alterações no código e abrir um pull request. Se os mantenedores fizerem merge do seu pull request, será uma grande vantagem para você.

Uma das melhores maneiras de se conseguir um emprego em uma empresa de tecnologia é se tornar um colaborador produtivo de código aberto nos repositórios delas.

Contribuir para o código aberto é uma ótima maneira de se construir sua reputação porque tudo o que você faz está aberto ao público. Você obtém a prova social de ter outros desenvolvedores revisando e aceitando seu trabalho.

Se você está interessado em construir sua reputação através do código aberto, aqui está como começar: leia o guia de Hillary Nyakundi sobre como começar com o código aberto (texto em inglês).

Como criar conteúdo voltado para desenvolvedores

Desenvolvedores são pessoas. Como outras pessoas, eles querem algo para fazer com seu tempo quando não estão trabalhando, dormindo ou saindo com amigos e familiares.

Para muitas pessoas – inclusive eu – isso significa passar um tempo nos pensamentos de outras pessoas. Livros. Ensaios em vídeo. Experiências interativas, como visual novels (texto em inglês).

Você pode se referir a esses como "conteúdo". Eu não sou um grande fã dessa palavra, porque faz esses trabalhos parecerem descartáveis, mas é assim que as pessoas chamam.

O desenvolvimento de software é um campo incrivelmente amplo, com muitos tópicos diferentes que você pode abordar. Existem vlogs sobre estilo de vida de desenvolvedores, tutoriais de preparação para entrevistas de programação, transmissões ao vivo de programação no Twitch e podcasts de entrevistas com desenvolvedores, como o podcast do freeCodeCamp (em inglês).

Provavelmente há categorias inteiras de conteúdo para desenvolvedores que ainda não pensamos – e que surgirão na próxima década.

Se você é interessado em cinema, jornalismo ou escrita criativa, o conteúdo para desenvolvedores pode ser uma boa maneira de construir sua reputação.

Você pode escolher um tópico específico e ser gradualmente visto como um especialista nele.

Existem desenvolvedores que se especializam em tutoriais para stacks de tecnologia específicas, por exemplo.

Meu amigo Andrew Brown é um ex-CTO de Toronto que passou em todos os principais exames de DevOps. Ele cria cursos gratuitos para preparar você para todas as certificações AWS, Azure e Google Cloud (em inglês), e também administra um serviço de preparação para exames.

Existem mais de 30 milhões de desenvolvedores de software ao redor do mundo. Isso é uma quantidade enorme de pessoas que potencialmente consumirão seu conteúdo e conhecerão quem você é.

Como subir na hierarquia trabalhando em grandes empresas

Você pode ter visto um desenvolvedor ser apresentado como um "ex funcionário da Google" ou um "ex-engenheiro da Netflix".

Algumas empresas de tecnologia têm processos de contratação tão rigorosos – e padrões tão altos – que até conseguir um emprego na empresa já é um grande feito.

Há algumas razões práticas pelas quais os empregadores olham onde os candidatos trabalharam anteriormente. Isso reduz o risco de uma contratação ruim.

Você pode construir sua reputação subindo na hierarquia do prestígio. Você pode escalar de um empregador local para uma empresa Fortune 500 e, finalmente, para um dos gigantes da tecnologia.

Claro, trabalhar em uma corporação gigante não é para todos. Falarei mais sobre isso no Capítulo 4., mas saiba que é uma opção que você tem para construir sua reputação.

Como construir sua reputação construindo um portfólio de clientes freelance

Você pode construir sua reputação trabalhando com empresas como freelancer.

Desenvolvedores freelancers geralmente trabalham em projetos menores, de uma pessoa só. Então, essa pode ser uma estratégia melhor para construir sua reputação localmente.

Por exemplo, se você fez um bom trabalho para um banco local, isso pode ser suficiente para convencer um escritório de advocacia local a contratá-lo também.

Há algo a ser dito sobre ser um "herói na sua cidade". Eu conheço muitos desenvolvedores que podem competir efetivamente com a concorrência on-line apenas por estarem fisicamente presentes em reuniões e conhecerem pessoas localmente.

Como construir um portfólio de desenvolvedor com seu trabalho

Depois de construir alguns projetos, você vai querer mostrá-los. A melhor maneira de se fazer isso é com vídeos curtos.

Se você enviar pessoas para um site, elas podem não entender completamente o que estão vendo e por que é tão especial.

É por isso que eu recomendo usar uma ferramenta de captura de tela para gravar vídeos de demonstração de dois minutos.

Dois minutos devem ser suficientes para mostrar como o projeto funciona. E depois de fazer isso, você pode explicar alguns dos detalhes da implementação e decisões de design que tomou.

Sempre, no entanto, comece com a demonstração. As pessoas querem ver algo funcionando. Elas querem ver algo visual.

Depois de atrair as pessoas com sua demonstração atraente da aplicação em funcionamento, você pode explicar todos os detalhes que quiser. Seu público agora terá mais contexto e estará mais interessado.

Dois minutos também é um tempo mágico, porque você pode fazer o upload desse vídeo para um tweet, e ele será reproduzido automaticamente no Twitter enquanto as pessoas rolam a tela. Vídeos de reprodução automática são muito, muito mais propensos a serem assistidos no Twitter. Eles removem o atrito de ter que clicar em um botão de reprodução ou navegar para outro site.

So a freeCodeCamp alum built their own twitter.

Like... so many of the core features and UI elements.

It looks uncanny.🦹

🧑‍💻 Code by Risal
🥁 Music by me pic.twitter.com/cFDjNxthnF
— Quincy Larson (@ossia) December 15, 2022

Você pode colocar esses vídeos de demonstração de projeto em sites como YouTube, Twitter, seu perfil do GitHub e, claro, em seu próprio site de portfólio.

Para gravar esse vídeo, eu recomendo usar o QuickTime, que vem integrado ao MacOS. Se você estiver no Windows, pode usar o Game Recorder, que vem grátis no Windows 10, ou a Game Bar, no Windows 11.

Se você quiser uma ferramenta mais poderosa, o OBS é grátis e de código aberto. É mais difícil de aprender, mas infinitamente personalizável.

Em termos de dicas de gravação: mantenha o tamanho da fonte o maior possível e use um microfone externo. Qualquer microfone que você encontrar – até mesmo de fones de ouvido baratos – será melhor do que falar no microfone embutido do seu laptop.

Invista o tempo que precisar para gravar e regravar até acertar.

Ser capaz de demonstrar seus projetos e apresentar seu código é uma habilidade valiosa que você usará ao longo de sua carreira. O tempo gasto praticando apresentações nunca é desperdiçado.

Como iniciar seu próprio projeto de código aberto, empresa ou instituição beneficente

Ser um fundador é a maneira mais rápida – mas também a mais arriscada – de construir uma reputação como desenvolvedor.

É mais arriscado porque você está apostando seu tempo, seu dinheiro e possivelmente até seus relacionamentos pessoais – tudo por um resultado desconhecido.

Se você contribuir com código aberto por tempo suficiente, você construirá uma reputação como desenvolvedor.

Se você percorrer o circuito de hackathons por tempo suficiente, você construirá uma reputação como desenvolvedor.

Porém, você pode tentar iniciar projetos empreendedores por décadas sem obter tração e desperdiçar seu tempo, dinheiro e contatos ao longo do caminho.

Empreendedorismo está além do escopo deste livro, mas se você estiver interessado nisso, darei este conselho rápido:

A maioria dos empreendedores falha. Alguns falham devido a circunstâncias fora de seu controle, mas muitos falham por não entenderem a natureza dos riscos que estão assumindo.

Não se apresse em fundar um projeto, empresa ou instituição beneficente. Tente trabalhar para outras organizações que já estão fazendo trabalhos no seu campo de interesse.

Ao trabalhar para outra pessoa, você é pago para aprender. Você ganha exposição ao trabalho e aos riscos que o cercam. Além disso, você pode economizar para uma eventual empreitada como empreendedor.

Como não destruir sua reputação

"Leva-se uma vida inteira para construir uma boa reputação, mas você pode perdê-la em um minuto." – Will Rogers, ator, cowboy e um dos meus heróis crescendo em Oklahoma City

Construir sua reputação é uma maratona, não uma corrida de velocidade.

Pode levar anos para construir uma reputação forte o suficiente para abrir as portas certas.

Assim como em uma maratona competitiva, contudo, um tropeço pode custar um tempo valioso. Um tropeço que resulte em lesão pode tirá-lo da corrida completamente.

Não diga coisas estúpidas na internet

As pessoas costumavam dizer coisas estúpidas o tempo todo. As palavras poderiam pairar no ar por alguns minutos enquanto todos faziam caretas, mas as palavras eventualmente se dissipavam.

Agora, quando as pessoas dizem coisas estúpidas, elas frequentemente o fazem on-line. Essa é uma tinta que não sai.

Sempre presuma que, no momento em que você digita algo em um site e pressiona enter, isso será salvo em um banco de dados. Esse banco de dados será copiado para vários centros de dados em todo o mundo.

Você pode provar a existência de dados, mas não há como provar a ausência de dados.

Você deve assumir, para todos os efeitos, que o que falou, ficará para sempre. Não há como colocar voltar atrás. O que quer que você tenha dito, está no seu registro permanente.

Você pode excluir o comentário. Você pode excluir sua conta. Você pode até tentar apagá-lo dos resultados de busca do Google, mas alguém provavelmente já fez um back-up na Wayback Machine. Quando um desses bancos de dados inevitavelmente for hackeado anos depois, esses dados provavelmente ainda estarão lá em algum lugar, prontinhos para serem trazidos à tona.

É uma época assustadora para ser um tagarela. Então, não seja. Pense antes de falar.

Meu conselho, que pode até parecer covardia: não crie o hábito de discutir com pessoas on-line.

Algumas pessoas seguem a regra de que "se você não tem algo legal para dizer, não diga nada".

Eu prefiro "elogiar em público, criticar em particular."

Eu reconheço publicamente o bom trabalho que alguém está fazendo na comunidade de desenvolvedores. Se eu vejo um projeto que me impressiona, eu digo isso.

Em uma briga, todos parecem sujos.

Você não quer parecer raivoso, desmontando o argumento de alguém, ou ser rude com alguém que acabou de dizer algo estúpido.

Claro – o humor cáustico pode render pontos na internet a curto prazo, mas também pode fazer as pessoas gostarem um pouco menos de você e temerem um pouco mais.

Eu também tento evitar reclamações. Sim, eu provavelmente conseguiria um melhor serviço ao cliente se ameaçasse tuitar sobre um voo cancelado.

As pessoas, porém, estão ocupadas. A maioria delas não quer usar seu tempo escasso, rolando pelas redes sociais, apenas para me ver reclamando sobre o que, no esquema geral das coisas, é um leve inconveniente.

Então, esse é meu conselho sobre o uso de redes sociais. Tente manter uma postura positiva.

Se for um assunto sobre o qual você tem fortes convicções, eu não vou impedi-lo de expressar sua opinião. Apenas pense antes de digitar e antes de clicar em enviar.

Não prometa demais e entregue de menos

Uma das maneiras mais comuns de ver desenvolvedores torpedeando suas próprias reputações é prometer demais e entregar de menos. Isso não é necessariamente um erro fatal, mas é ruim.

Lembre-se de quando falei sobre o hackathon em Las Vegas, onde eu falhei totalmente em terminar o projeto a tempo para a apresentação e tivemos que usar slides em vez de uma aplicação funcional?

Sim, esse foi um dos pontos mais baixos na minha jornada de aprender a programar. Meus colegas de equipe foram educados, mas tenho certeza de que ficaram desapontados comigo. Afinal de contas, eu tinha sido excessivamente confiante. Eu tinha prometido mais do que poderia realizar naquele período de tempo, e entreguei de menos.

É muito melhor ser modesto nas suas estimativas sobre suas habilidades.

Lembre-se da parábola de Ícaro, que com suas asas de cera voou muito perto do sol. Se ele tivesse adotado uma abordagem mais comedida, subido um pouco mais devagar, suas asas não teriam derretido. Ele não teria caído no mar, deixando um pai atormentado pela culpa.

1690px-Pieter_Bruegel_de_Oude_-_De_val_van_Icarus — Paisagem com a Queda de Ícaro por Pieter Bruegel, o Velho, cerca de 1560. Ícaro poderia ter sido importante. Ele poderia ter sido alguém, mas, em vez disso, ele é apenas um par de pernas desaparecendo no mar. Os agricultores e pastores não se incomodam em levantar os olhos de seu trabalho para notar sua insignificância.

Controle seus vícios antes que eles danifiquem sua reputação

Se você tem um vício não tratado em drogas, álcool ou jogos de azar, procure ajuda primeiro. A busca por um emprego de desenvolvedor pode ser longa e extenuante. Você quer entrar nela com toda a sua atenção.

Mesmo algo aparentemente inofensivo como o vício em videogames pode distraí-lo e consumir muito do seu tempo. Vale a pena controlá-lo primeiro.

Eu não sou médico. Não vou fazer um discurso de como "drogas são ruins". Isso, ao menos, eu vou dizer: você pode ouvir falar de modas no Vale do Silício, onde desenvolvedores abusam de drogas pensando que podem, de algum modo, melhorar suas habilidades de programação ou resolução de problemas.

Por um tempo, houve uma tendência de "microdosagem de LSD". Houve uma tendência de uso de anfetaminas farmacêuticas.

Minha reação instintiva a isso é: qualquer vantagem que essas drogas possam dar a você provavelmente é insustentável e, a longo prazo, um prejuízo.

Não se sinta pressionado a tomar drogas psicoativas. Não se sinta pressionado a beber em happy hours (eu não bebo nem uma cerveja desde que minha filha nasceu há 8 anos, e não sinto que perdi nada).

Se você está se recuperando de um vício, esteja ciente de que aprender a programar e conseguir um emprego de desenvolvedor será um processo estressante. Vá com calma, para não correr o risco de uma recaída.

Você não quer chegar ao final do processo de transição de carreira – e realizar tanto – apenas para que velhos hábitos ressurjam e desfaçam seu trabalho árduo.

Tente separar sua vida profissional da sua vida pessoal

Você pode ter ouvido a expressão, "Não misture negócios com prazer."

Como desenvolvedor, você se tornará uma pessoa poderosa. Você vai comandar um certo grau de respeito das outras pessoas em sua cidade.

Talvez não tanto quanto um médico ou um astronauta, mas, ainda assim, as pessoas vão olhar para você com admiração.

Você vai conversar com pessoas que adorariam estar no seu lugar.

Não exiba sua riqueza.

Não aja como se fosse mais inteligente do que todo mundo.

Não abuse da dinâmica de poder para conseguir o que quer em relacionamentos.

Isso fará com que as pessoas ao seu redor não gostem de você. Se, de algum modo, isso for percebido e publicado on-line, pode perseguir você pelo resto de sua carreira.

Nunca perca de vista o quanto você tem e o quanto você tem a perder.

Use o truque do narrador

Vou fechar este capítulo com um pequeno truque que eu uso para me animar.

Primeiro, lembre-se de que você é o herói em sua própria jornada em programação. No teatro da sua mente, você é a pessoa que todos estão assistindo – aquela por quem estão torcendo.

O truque do narrador é narrar suas ações mentalmente enquanto você as executa.

Quincy caminha pelo hackerspaces, seu laptop enfiado sob o braço. Ele coloca sua caneca sob o dispensador de água quente e joga um sachê de chá fresco. Ele puxa a alavanca. E enquanto a água fumegante enche sua caneca, ele diz em voz alta com seu melhor sotaque britânico: "Chá. Earl Grey. Quente."

Com sua bebida energizante em mãos, ele desliza para dentro de um cubículo, alinha seu laptop na superfície e encontra o olhar de outro desenvolvedor. Eles se encaram por um segundo. Quincy abaixa a cabeça suavemente, reconhecendo a presença do desenvolvedor. O desenvolvedor retribui com um pequeno movimento de cabeça, quase telepaticamente compartilhando esse sentimento: "Eu vejo você, amigo. Eu vejo você aparecer e realizar coisas."

Narrar até os momentos mais mundanos da sua vida na sua cabeça pode te ajudar a se energizar. Cristalizar o momento que está diante de você e dar a você clareza de propósito.

Isso funciona ainda melhor quando você pensa na sua vida em termos de eras ("os anos do Taco Bell") ou como pontos de inflexão ("passar no exame GED").

O que isso tem a ver com construir sua reputação? Sua reputação é, essencialmente, o resumo de quem você é. O que você significa para as pessoas ao seu redor.

Ao se levar mais a sério, ao pensar na sua vida como um filme, você está gradualmente analisando e entendendo quem você é e quem quer se tornar um dia.

Ao narrar suas ações, você lança uma luz mais brilhante sobre elas na sua própria mente. Por que eu acabei de fazer isso? O que eu estava pensando? Havia uma jogada melhor ali?

Muitas pessoas sabotam suas reputações sem nem mesmo perceber, só porque se acomodaram em maus hábitos.

Por anos, eu achei que precisava ser "engraçado" o tempo todo. Eu encontrava qualquer oportunidade para injetar algum humor autodepreciativo. Muitas pessoas percebiam o que eu estava fazendo e achavam divertido, mas outras não entendiam e só ficavam com a impressão de que eu era um idiota.

Por que eu fazia isso? Acho que remonta ao ensino fundamental, quando eu sempre tentava ser o palhaço da turma e fazer as pessoas rirem.

Décadas depois, esse reflexo de preencher o silêncio com risadas não estava me servindo bem.

"Quando você repete um erro, ele não é mais um erro. É uma decisão." – Paulo Coelho

Eu poderia ter continuado muito mais tempo sem notar esse mau hábito, mas, com o truque do narrador, o constrangimento do meu comportamento ficou evidente.

Tenho certeza de que tenho muitas outras maneiras de pensar e de fazer as coisas que são longe de ser ótimas. Com a ajuda do truque do narrador, espero identificá-las no futuro e refiná-las, antes que deem às pessoas uma impressão errada.

Sua reputação se tornará seu legado

Pense em quem você quer ser no final da sua história. Como você quer que as pessoas pensem no seu tempo na Terra. Então, trabalhe de trás para frente a partir daí.

A pessoa que você quer ser no final do filme. Aquele herói que você quer que as pessoas admirem. Por que não começar a se portar assim agora?

Você consegue imaginar como seria ser um desenvolvedor de sucesso? Ter construído sistemas de software dos quais as pessoas dependem?

Esse futuro você – como ele pensaria? Como ele abordaria situações e resolveria problemas? Como ele falaria sobre suas realizações? Seus contratempos?

Simplesmente pensar no seu futuro eu pode ajudar você a esclarecer seus pensamentos, suas prioridades.

Eu frequentemente penso no "Velho Quincy", com suas costas ruins. Ele tem que se desculpar para correr ao banheiro a cada 30 minutos.

O Velho Quincy, porém, ainda tenta fazer o melhor com o que ele tem. Ele se move apesar das articulações doloridas. Ele pondera apesar de uma mente enevoada.

O Velho Quincy ainda quer fazer as coisas acontecerem. Ele se orgulha do que realizou, mas não passa muito tempo olhando para trás. Ele olha para frente, para o que ele vai fazer naquele dia e para quais objetivos ele vai alcançar.

Eu frequentemente penso no Velho Quincy e trabalho de trás para onde estou hoje.

Quais decisões posso tomar hoje que me prepararão para ser alguém digno de admiração amanhã? Preciso esperar décadas para conquistar essa reputação? Ou posso pegar emprestado um pouco desse respeito do futuro?

Pensando como o meu futuro eu poderia pensar, posso fazer movimentos que me rendam uma reputação positiva no presente?

Eu acredito que você pode aproveitar sua futura reputação – seu legado – agora mesmo. Basta pensar em termos do seu futuro eu e do que você realizará. Use isso como um ponto de referência para guiar você adiante.

Espero que essas ferramentas – o truque do narrador e a visualização do seu futuro eu – ajudem você não apenas a pensar sobre a natureza da reputação. Espero que elas também ajudem você a dar passos concretos para melhorar sua reputação.

Construir uma reputação – fazer um nome para si mesmo – é o caminho mais seguro para um sucesso sustentável como desenvolvedor.

Sucesso pode significar muitas coisas para muitas pessoas, mas a maioria das pessoas – de várias culturas – concordaria: um grande aspecto do sucesso é colocar comida na mesa para você e sua família.

É disso que falaremos a seguir.

Capítulo 4: como ser pago para programar – clientes freelance e a busca por emprego

Se você tem desenvolvido suas habilidades, sua rede de contatos e sua reputação, conseguir um emprego de desenvolvedor não é tão complicado assim.

Observe que eu disse que não é complicado – ainda é muito trabalho e pode ser cansativo.

Primeiro, deixe-me contar como consegui meu primeiro emprego.

Hora da história: como um professor na casa dos 30 conseguiu seu primeiro emprego como desenvolvedor?

Na última vez, na Hora da história: Quincy mergulhou de cabeça no circuito de hackathons, chegando a vencer alguns dos eventos. Ele estava construindo sua reputação como um desenvolvedor que era "perigoso" com JavaScript. Não super habilidoso. Apenas perigoso...

Eu tinha acabado de terminar um longo dia de aprendizado na biblioteca do centro de Santa Barbara, bebendo chá e construindo projetos.

A melhor coisa sobre viver na Califórnia é o clima. Costumávamos brincar que, ao alugar um apartamento exorbitantemente caro de um quarto nos subúrbios, você não estava pagando pelo interior – você estava pagando pelo exterior.

Foi uma linda noite de quarta-feira. Eu ainda tinha mais dois dias para me preparar para o hackathon daquele fim de semana. Meu cérebro estava completamente exausto do dia de programação. Minha esposa estava trabalhando até tarde, então verifiquei meu calendário para encontrar algo para fazer.

Na primeira segunda-feira de cada mês, eu mapeava todos os eventos de tecnologia que aconteceriam naquele mês no sul da Califórnia, para que eu sempre tivesse um evento de tecnologia para participar se tivesse energia.

Ah – esta noite é o encontro do Santa Barbara Ruby on Rails. Eu já tinha confirmado minha presença.

Eu não sabia muito sobre Ruby on Rails, mas tinha concluído alguns pequenos projetos com ele. Eu era muito mais um desenvolvedor JavaScript e Python.

Pensei: por que não? Eu precisava manter meu impulso de construir minha rede de contatos e o local era a apenas alguns quarteirões de distância.

Entrei e eram apenas alguns desenvolvedores sentados ao redor de uma mesa conversando. Rapidamente ficou claro que todos eles trabalhavam juntos em uma startup local, mantendo uma grande base de código em Ruby on Rails. A maioria deles trabalhava lá há vários anos.

Neste ponto, eu tinha passado o último ano construindo minhas habilidades, minha rede de contatos e minha reputação. Então, eu consegui me manter durante a conversa.

Eu também tinha uma noção dos limites das minhas habilidades. Então, permaneci modesto. Discreto. Do jeito que vi tantos outros desenvolvedores bem-sucedidos conduzirem uma conversa em eventos de tecnologia.

Ficou claro que um dos desenvolvedores na mesa era o Diretor de Engenharia. Ele reportava diretamente ao CTO.

Ficou claro também que eles estavam procurando contratar desenvolvedores de Ruby on Rails.

Fui franco sobre minha experiência e minhas habilidades. "Minha experiência é em educação de adultos. Ensinei inglês e administrei escolas. Comecei a aprender a programar há cerca de um ano."

O homem não se mostrou surpreso. "Bem, se você quiser vir para uma entrevista, podemos ver se você seria uma boa adição para a equipe."

Naquela noite, voltei para casa sentindo uma eletricidade. Era muito mais um temor do que uma empolgação.

Eu me sentia muito longe de estar pronto. Nem estava procurando um emprego. Eu estava apenas vivendo das minhas economias, aprendendo a programar em tempo integral, com seguro de saúde por meio do emprego da minha esposa.

Eu era um poupador compulsivo. As pessoas me criticavam por isso. Eu mesmo trocava o óleo do meu carro, cortava meu próprio cabelo e até cozinhava meu próprio arroz em casa quando pedíamos comida de fora – só para economizar alguns trocados.

Ao longo da década em que trabalhei como professor, consegui economizar quase um quarto dos meus rendimentos após impostos. Eu comprava jogos de videogame antigos no Craigslist e os revendia no eBay. Isso pode parecer bobo, mas era uma fonte substancial de renda para mim.

Para que estávamos poupando tudo isso? Não tínhamos certeza. Talvez para comprar uma casa na Califórnia em algum momento no futuro? Isso, porém, significava que eu não tinha que correr para conseguir um emprego. Eu sabia que estava em uma posição privilegiada e tentava aproveitar ao máximo aprendendo mais a cada dia.

Resumindo, eu não achava que estava pronto para meu primeiro emprego como desenvolvedor. Estava preocupado que, se me contratassem, seria um grande erro. Eles perceberiam a minha inexperiência, me despediriam e eu teria que explicar esse fracasso em futuras entrevistas de emprego.

Claro, agora eu sei que estava olhando para essa oportunidade do jeito errado, mas deixe-me terminar a história.

Quando agendei minha entrevista de emprego, eles pediram meu currículo. Eu não sabia o que fazer, então incluí toda a minha experiência profissional lá. Todas as escolas nas quais trabalhei ao longo dos anos (deixei de fora meu tempo administrando o drive-thru do Taco Bell).

Claro, nenhuma das minhas experiências de trabalho tinha qualquer relação com programação, mas o que eu deveria fazer? Entregar uma folha de papel em branco?

Bem, eu tinha um portfólio on-line dos projetos que construí. Mais importante ainda, eu tinha uma lista de todos os hackathons que venci ou nos quais me classifiquei. Então, incluí essas informações.

Passei as últimas horas antes da entrevista revisitando todos os tutoriais de Ruby on Rails que usei ao longo do último ano, para refrescar minha memória. Então vesti meu moletom com capuz, jeans e mochila, e fui até o escritório deles.

A gerente do escritório era uma senhora simpática que me levou até o espaço dos desenvolvedores e me apresentou à pequena equipe deles. Eram talvez uma dúzia, a maioria vestida com jeans e moletons com capuz, com idades que variavam dos 20 e poucos aos 40 e muitos anos. Dois deles eram mulheres.

Fui, um por um, navegando pela confusão de mesas e cabos, apertando as mãos de cada um e me apresentando. Foi aí que toda a minha experiência como professor de sala de aula memorizando nomes de alunos se mostrou útil. Consegui me lembrar de todos os nomes, para que mais tarde, quando fosse embora, pudesse falar novamente com cada um deles: "Foi ótimo te conhecer, [nome]. Eu ficaria empolgado em trabalhar ao seu lado."

Primeiro, encontrei-me com o diretor de engenharia. Fomos para uma pequena sala e fechamos a porta.

Um quadro branco na parede estava coberto de esboços de diagramas de Linguagem de Modelagem Unificada (UML). Um arco-íris de marcadores de apagamento a seco delineava as relações entre vários servidores e serviços.

Continuei olhando de relance para aquele quadro branco, temendo que ele me mandasse até lá para resolver alguns problemas de programação e demonstrar minhas habilidades. Talvez o famoso problema fizzbuzz? Talvez ele quisesse que eu invertesse uma árvore binária?

Eles eram uma empresa com cerca de 50 funcionários, com muito financiamento de capital de risco e milhares de clientes pagantes – principalmente pequenas empresas. Eles se orgulhavam de serem pragmáticos. Em nenhum momento perguntaram sobre o que eu estudei na escola, ou que tipo de trabalho eu fiz no passado. Tudo o que realmente importava era...

"Olha. Eu sei que você sabe programar," ele disse. "Você tem programado esse tempo todo, ganhando hackathons. Eu verifiquei alguns dos seus projetos de portfólio. A qualidade do código estava OK para alguém que é novo em programação. Então, para mim, a verdadeira questão é – você pode aprender como fazemos as coisas aqui? Você pode trabalhar com os outros desenvolvedores da equipe? Mais importante ainda: você consegue fazer o que precisa ser feito?"

Eu engoli em seco, inclinei-me para frente e reuni toda a confiança que pude. "Sim," eu disse. "Acredito que posso."

Ele disse: "Bom. Bom. OK. Vá esperar no restaurante Pho no andar de baixo. [O CTO] deve estar lá em um minuto."

Então, eu conversei com o CTO enquanto comia noodles. Eu principalmente ouvi. Eu aprendi que as pessoas projetam inteligência em pessoas quietas. Ouvir atentamente não apenas ajuda você a ficar mais inteligente – até faz você parecer mais inteligente.

A abordagem funcionou. A reunião durou cerca de uma hora. Os noodles estavam saborosos. Eu aprendi muito sobre a história da empresa e os objetivos de curto prazo. O CTO disse, "OK, volte lá em cima e fale com [o diretor de engenharia]."

Eu fui e ele me ofereceu um emprego.

Agora, eu quero enfatizar: não é assim que a maioria das pessoas consegue seu primeiro emprego de desenvolvedor.

Você provavelmente está pensando, "Puxa, esse é o Quincy, o Forest Gump, conseguindo um emprego de desenvolvedor que ele nem estava procurando. Se ao menos todos nós pudéssemos ser tão sortudos."

Certamente foi assim que eu me senti na época. Na próxima seção, vou explorar a relação entre empregadores e desenvolvedores. A maneira como consegui aquele emprego teve menos a ver com minhas habilidades como entrevistado e mais com o ano de programação, networking e construção de reputação que o precedeu.

Esse não era um emprego confortável em uma grande empresa de tecnologia, com toda a compensação, benefícios e pistas de boliche da empresa. Era um cargo de contratado, que pagava aproximadamente o mesmo que eu ganhava como professor.

Só que era um emprego de desenvolvedor. Uma empresa estava me pagando para escrever código.

Eu agora era um desenvolvedor profissional.

O que os empregadores querem

Vamos avançar uma década. Agora estive dos dois lados da mesa. Fui entrevistado por gerentes de contratação como desenvolvedor. Eu entrevistei desenvolvedores como gerente de contratação.

Passei muitas horas em chamadas com desenvolvedores que estão no meio da busca por emprego. Alguns deles aplicaram para centenas de empregos e receberam apenas alguns retornos para entrevistas.

Também passei muitas horas em chamadas com gerentes e recrutadores, tentando entender melhor como eles contratam e o que procuram.

Acho que grande parte da frustração dos desenvolvedores sobre o processo de contratação se resume a um mal-entendido.

Os empregadores valorizam uma coisa acima de tudo: previsibilidade.

Qual destes candidatos você acha que um empregador preferiria?

X é uma estrela da programação que frequentemente tem lampejos de genialidade. X também tem surtos de produtividade incrível, mas frequentemente está irritado com os colegas e perde prazos ou reuniões.

Y é um bom programador e tem uma produção mais lenta, mas mais consistente. Y se dá bem com os colegas e raramente perde reuniões ou prazos.

Z é semelhante a Y em termos de produção e capaz de se dar bem com os colegas e cumprir prazos, mas mudou de emprego três vezes nos últimos três anos.

OK, você provavelmente pode adivinhar por tudo o que eu disse até agora que Y é o candidato preferido. Isso ocorre porque os empregadores valorizam a previsibilidade acima de tudo.

X é um candidato armadilha que alguns gerentes de primeira viagem podem cometer o erro de contratar. Se você está curioso por que contratar X seria uma ideia tão ruim, leia We fired our top talent. Best decision we ever made (texto em inglês).

Eu só adicionei Z a essa lista para acrescentar um ponto: tente não mudar de emprego com muita frequência.

Você pode aumentar sua renda rapidamente passando de um empregador para outro. Você pode começar a se candidatar a novos empregos no momento em que aceitar uma carta de oferta, mas isso afastará muitos gerentes de contratação.

Afinal, pedra que rola não cria limo. Você estará entrando e saindo de bases de código antes de ter tempo de entender como elas funcionam.

Considere isto: pode levar 6 meses ou mais para um gerente fazer com que um novo desenvolvedor fique a par das coisas, até o ponto em que ele possa ser um ponto positivo para a equipe.

Até esse ponto, a nova contratação é essencialmente um dreno nos recursos da empresa, absorvendo tempo e energia dos seus pares que precisam integrá-los, ajudá-los a encontrar o caminho em uma base de código e corrigir seus erros.

A maioria dos empregadores é avesso ao risco

Vamos dizer que um gerente contrata o desenvolvedor errado. Pense por um momento sobre como isso pode ser ruim para a equipe.

Em média, leva cerca de 3 meses para preencher uma posição de desenvolvedor em uma empresa. Os empregadores precisam primeiro:

obter o orçamento para contratar um desenvolvedor aprovado por seus chefes
criar a descrição do trabalho
postar o trabalho em sites de emprego e se comunicar com recrutadores
vasculhar currículos – muitos dos quais serão de baixo esforço de candidatos que estão se inscrevendo cegamente para o maior número de empregos possível
iniciar o processo de entrevista, que pode envolver levar os candidatos para a cidade e hospedá-los em um hotel
rodadas de entrevistas envolvendo muitos membros da equipe. Para alguns empregadores, isso é uma questão de vários dias
selecionar um candidato final e negociar uma oferta... que muitos candidatos não aceitarão de qualquer maneira
assinar contratos e integrar o funcionário
dar a eles acesso a sistemas internos sensíveis
apresentá-los aos seus colegas de equipe e garantir que todos se deem bem
meses de treinamento informal, quando o funcionário precisa entender um serviço ou uma parte de uma base de código legado
e finalmente, imergi-los na forma da equipe de fazer as coisas

Agora imagine que, depois de todo esse esforço, o novo funcionário diz: "Ei, acabei de receber uma oferta melhor de outra empresa. Fui, valeu!"

Ou imagine que o funcionário é pouco confiável, frequentemente chegando horas depois do início da jornada de trabalho.

Ou imagine que o funcionário luta com problemas não tratados como dependência em drogas, álcool ou jogos, questões de raiva – ou simplesmente se revela uma pessoa passivo-agressiva que mina a equipe.

Agora você precisa recomeçar todo esse processo novamente e procurar um novo candidato para a posição.

Contratar é difícil.

Você pode ver por que os empregadores são avessos ao risco. Muitos deles passam por cima de candidatos aparentemente qualificados até encontrar alguém com quem se sentem 99% seguros.

Como os empregadores são tão avessos ao risco, os candidatos a um emprego sofrem

Se você acha que contratar é difícil, espere até ouvir sobre o processo de candidatura a emprego. Você pode já estar mais do que familiarizado com ele, mas aqui vai...

Você tem que preparar seu currículo ou CV. Ao longo do caminho, você tomará decisões que constantemente questionará durante sua busca de emprego.
Você tem que procurar vagas de emprego on-line, pesquisar os empregadores e avaliar se eles têm probabilidade de serem um bom encaixe para você.
A maioria das vagas levará a formulários na web onde você terá que reescrever seu currículo repetidas vezes, esperando que o formulário não trave devido a erros de servidor ou erros de validação de JavaScript.
Depois de enviar essas candidaturas, você tem que esperar enquanto os empregadores as processam. Alguns empregadores recebem tantas candidaturas que não conseguem revisá-las todas manualmente (a Google sozinha recebe 9 mil candidaturas por dia). Os empregadores usarão software para filtrar as candidaturas. Recrutadores internos gastam em média 6 segundos olhando cada currículo (texto em inglês). Muitas vezes, sua candidatura nunca será sequer revisada por um humano.
Provavelmente, você nunca ouvirá nada de volta da empresa. Eles têm pouco incentivo para dizer por que rejeitaram você (eles não querem que você entre com um processo por discriminação). Se você tiver sorte, receberá um daqueles e-mails "Optamos por seguir com outros candidatos".
E todo o tempo que você gasta se candidatando a essas vagas – potencialmente horas por semana – é mentalmente exaustivo e, claro, não remunerado.

Uau. Agora, você pode ver como o processo de contratação é um pesadelo para os empregadores e especialmente para os candidatos a emprego.

Se você persistir, porém poderá receber ofertas. Quando chove, vira uma tempestade.

Aqui está um dado da busca de emprego de um colaborador do freeCodeCamp ao longo de 12 semanas:

85L921BMzXxKhVySPo9gxWamr5J4QLFJaVEn — *De 291 candidaturas, ele acabou recebendo 8 ofertas.*

À medida que as ofertas chegavam, o salário inicial ficava cada vez maior. Note, é claro, que isso é para um emprego em San Francisco, uma das cidades mais caras do mundo.

bDp3eVv6VQS3Og3ulVpwp6dDylIybdpRczsD — *Na 12ª semana, suas ofertas de salário inicial eram quase o dobro do que eram na 2ª semana.*

O número de vezes que esse desenvolvedor conseguiu entrevistas é bastante grande. Sua capacidade de negociação também era forte. Você pode ler mais sobre o processo dele se estiver curioso (texto em inglês).

Como eu disse antes, porém, é muito mais fácil entrar em uma empresa pela porta lateral.

Essa é uma das razões pelas quais escrevi este livro. Eu não quero que você continue se alinhando na porta da frente desses empregadores.

Se você desenvolver suas habilidades, sua rede e sua reputação, pode ignorar grande parte do processo de candidatura a empregos.

Ao longo deste livro, tenho ensinado técnicas para aumentar sua probabilidade de "dar sorte" e conseguir uma oferta de emprego.

"Sorte é quando a preparação encontra a oportunidade. Se você não estivesse preparado quando a oportunidade surgisse, você não teria tido 'sorte'." – Oprah Winfrey

É por isso que ao longo deste livro tenho incentivado você a desenvolver essas três áreas ao mesmo tempo e a começar a pensar nelas desde o primeiro dia – bem antes da sua busca de emprego.

Minha história de nem mesmo procurar um emprego e conseguir um trabalho pode parecer boba, mas isso acontece mais frequentemente do que você imagina.

A realidade é: aprender a programar é difícil.

Saber programar, porém, é importante.

Em cada setor – em praticamente todas as empresas do mundo – os gerentes estão tentando descobrir maneiras de levar seus processos para a camada de software.

Isso significa desenvolvedores.

Você pode ouvir sobre grandes demissões no setor de tecnologia de vez em quando. Muitas dessas demissões afetam funcionários que não são desenvolvedores. Muitas vezes, contudo, muitos desenvolvedores perdem seus empregos.

Por que as empresas demitiriam desenvolvedores, depois de gastar tanto tempo e dinheiro recrutando e treinando-os? Fora uma situação de falência, eu não sei a resposta para essa pergunta. Não tenho certeza se alguém sabe.

Há evidências crescentes de que as demissões destroem valor a longo prazo dentro de uma empresa. Na prática, porém, muitos CEOs sentem pressão de seus investidores para fazer demissões. Quando várias empresas fazem demissões ao mesmo tempo, outros CEOs podem seguir o exemplo.

Ainda assim, mesmo com as demissões, a maioria dos economistas espera que o número de empregos para desenvolvedores e outros empregos relacionados a software continue crescendo. Por exemplo, o Departamento de Estatísticas do Trabalho dos EUA prevê um aumento de 15% no número de desenvolvedores na próxima década.

Minha esperança é que, com habilidades fortes, uma rede forte e uma reputação forte, você consiga um bom emprego, apesar de um mercado de trabalho desafiador.

Espero que um dia seja mais fácil para empregadores e funcionários qualificados se encontrarem – sem o longo e brutal processo de aplicação e entrevista de emprego.

O que esperar do processo de entrevista de emprego para desenvolvedores

Uma vez que você comece a marcar entrevistas de emprego, você terá um gostinho do temido processo de entrevista de emprego para desenvolvedores e da famigerada entrevista de programação.

Um fluxo de entrevista típico pode envolver:

Fazer uma avaliação de programação on-line de suas habilidades ou uma "triagem por telefone".
Se você passar, uma segunda entrevista técnica por telefone ou videochamada.
Se você passar, uma entrevista "presencial", onde você viaja para o escritório da empresa. Essas geralmente envolvem várias entrevistas com RH, gerentes de contratação e desenvolvedores de linha de frente com os quais você pode trabalhar.

Ao longo do caminho, você enfrentará perguntas que testam seu conhecimento de resolução de problemas, algoritmos e estruturas de dados, depuração e outras habilidades.

Seus entrevistadores podem permitir que você resolva esses problemas de programação em um computador em um editor de código. Muitas vezes, no entanto, você terá que resolvê-los à mão enquanto está em um quadro branco.

A coisa principal a lembrar é que a pessoa que está entrevistando você não está apenas procurando uma resposta correta. Eles também estão tentando entender como você pensa.

Eles querem saber se você entende os fundamentos da programação e da ciência da computação ou se você está apenas regurgitando uma série de soluções que memorizou?

Praticar algoritmos e estruturas de dados ajudará muito, mas você também precisa ser capaz de pensar em voz alta e explicar seu processo de pensamento enquanto escreve suas soluções.

A melhor maneira de praticar isso é falar em voz alta consigo mesmo enquanto programa. Ou – se você estiver se sentindo corajoso – transmitir ao vivo sua programação.

Existem muitos streams de "programação ao vivo" no Twitch, onde as pessoas "aprendem em público" construindo projetos na frente de uma plateia. Como bônus, se você estiver disposto a se expor dessa forma, isso também ajudará a construir sua reputação como desenvolvedor.

Outra coisa a lembrar durante as entrevistas em quadro branco: seu entrevistador. Eles não estão apenas sentados esperando você terminar. Eles estão com você o tempo todo, observando e avaliando você tanto consciente quanto inconscientemente.

Tente tornar o processo de entrevista o mais interativo possível para seu entrevistador. Sorria e faça contato visual ocasionalmente. Tente julgar a linguagem corporal deles. Estão relaxados? Estão acenando com a cabeça enquanto você explica os pontos?

Seu entrevistador provavelmente sabe o que está procurando no seu código. Então, veja se você consegue arrancar algumas dicas deles. Fazendo observações ou fazendo perguntas abertas em voz alta para si mesmo, você pode conseguir que seu entrevistador entre na conversa e se envolva no processo.

Você quer que seu entrevistador goste de você. Você quer que eles torçam por você, para que possam desconsiderar algumas das deficiências nas suas habilidades de programação ou ignorar alguns dos erros que você possa cometer em seu código.

Você está se vendendo como candidato a emprego. Certifique-se de que seu entrevistador sinta que está fazendo um bom negócio.

Isso também vale para qualquer entrevista comportamental que você possa ter que passar. Essas entrevistas são menos sobre sua habilidade em programação e mais sobre seu "encaixe cultural" (eu gostaria de poder dizer o que isso significa, mas cada gerente definirá isso de uma maneira ligeiramente diferente).

Nessas entrevistas comportamentais, você terá que convencer seu entrevistador de que possui fortes habilidades de comunicação.

Definitivamente ajuda ser fluente no idioma em que você está sendo entrevistado e conhecer o jargão certo. Você pode absorver muito disso ouvindo regularmente podcasts de tecnologia, como o Podcast do freeCodeCamp (em inglês).

Uma coisa importante que seus entrevistadores estão tentando descobrir: você é uma pessoa calma que trabalhará bem com os outros? A melhor maneira de mostrar isso é ser educado e evitar usar palavrões ou se desviar muito do assunto em questão.

Você não quer entrar em um debate sobre algo não relacionado, como uma rivalidade esportiva. Também recomendo não tentar corrigir seus entrevistadores, mesmo que eles digam coisas que você acredita serem bobas ou falsas.

Se você sentir vibrações ruins da empresa, você não precisa aceitar a oferta de emprego deles. Empregadores recusam candidatos o tempo todo. Você, como candidato, também tem o direito de recusar um empregador. A entrevista em si provavelmente não é o melhor momento para conflito.

Devo negociar meu salário no meu primeiro emprego como desenvolvedor?

Tentar negociar seu salário para cima geralmente não atrapalha, desde que você o faça educadamente.

Eu escrevi muito sobre como negociar sua oferta salário de emprego como desenvolvedor (texto em inglês).

Essencialmente, negociar um salário inicial mais alto se resume a quanto poder de barganha você tem.

Seu empregador tem trabalho a ser feito. Qual é o nível de desespero de seu empregador de que você trabalhe para eles? Que outras opções eles têm?

Você precisa de renda para sobreviver. Quais outras opções você tem? Qual é seu plano B?

Se você tiver uma oferta de emprego de outro empregador oferecendo para pagar a você uma certa quantia, pode usar isso como poder de barganha na sua negociação salarial.

Pense novamente no processo de contratação que descrevi anteriormente. Os empregadores têm que passar por pelo menos uma dúzia de etapas antes de chegarem à etapa de oferta de emprego com os candidatos. Eles provavelmente já estão planejando que você negocie – e não ficarão surpresos com isso.

Se você estiver em uma situação como a minha, porém, onde uma empresa simplesmente oferece um emprego do nada, você pode se sentir estranho tentando negociar.

92508 — *Smithers dos Simpsons - o que há de errado nesse país? Não é possível sair para caminhar na rua sem que nos ofereçam um emprego?*

Vou admitir – na minha história acima, quando meu gerente me ofereceu o emprego, eu não negociei.

Olhando para trás, eu deveria ter negociado minha compensação? Provavelmente, sim.

Eu tinha alguma vantagem? Provavelmente, não muita. Meu plano B era simplesmente continuar competindo em hackathons e continuar tomando chá e programando na biblioteca pública.

Eu poderia ter conseguido negociar e ganhar alguns dólares a mais por hora, mas, no momento em que me ofereceram o emprego, a compensação era a última coisa em minha mente. Eu estava apenas extasiado por estar prestes a me tornar um desenvolvedor profissional.

A propósito, uma vez que você tenha trabalhado como desenvolvedor em uma empresa por cerca de um ano, você pode querer pedir um aumento. Eu escrevi longamente sobre como pedir um aumento como desenvolvedor (texto em inglês), mas tudo se resume à mesma coisa: ter a vantagem.

Você deve usar um recrutador para sua busca por emprego como desenvolvedor?

Sim. Se você puder encontrar um recrutador que o ajude a conseguir seu primeiro emprego como desenvolvedor, acho que você deve fazer isso.

Eu escrevi longamente sobre por que os recrutadores são uma ferramenta subestimada em sua caixa de ferramentas (texto em inglês).

Muitos empregadores pagarão uma taxa de busca aos recrutadores por enviar candidatos a empregos de alta qualidade.

Os incentivos dos recrutadores estão bem alinhados com seus próprios objetivos como candidato a emprego:

Visto que são pagos com base em seu salário inicial, eles estão inclinados a ajudá-lo a negociar o salário inicial mais alto possível.
Quanto mais candidatos que eles recrutarem forem contratados— e quanto mais rápido eles forem contratados — mais dinheiro os recrutadores ganham. Então, eles vão querer ajudá-lo a conseguir um emprego o mais rápido possível para que possam passar para outros candidatos a emprego.
Visto que são pagos apenas se você for bem-sucedido como funcionário (e permanecer pelo menos 90 dias), eles tentarão garantir que você seja competente e um bom ajuste para a cultura da empresa.

Dito isso, se um recrutador pedir dinheiro para qualquer coisa, isso é um sinal de alerta.

Nem todos os recrutadores são iguais. Faça sua pesquisa antes de trabalhar com um recrutador, mesmo que eles estejam recebendo pagamento do empregador, você ainda está investindo seu tempo em ajudá-los a ter um emprego. Seu tempo é valioso.

Falando em tempo, uma maneira de começar a ser pago para programar mais cedo — mesmo enquanto você se prepara para a busca de emprego — é conseguir alguns clientes freelance.

Como conseguir clientes freelance

Eu encorajo novos desenvolvedores a tentar conseguir alguns clientes freelance antes de começarem a busca de emprego. Existem três boas razões para isso:

É muito mais fácil conseguir um cliente freelance do que um emprego em tempo integral.
O trabalho freelance é menos arriscado, pois você pode fazê-lo sem deixar seu emprego atual.
Você pode começar a ser pago para programar mais cedo e começar a construir seu portfólio de trabalho profissional mais cedo.

Conseguir clientes freelance pode ser muito mais fácil do que conseguir um emprego de desenvolvedor. Por quê?

Pense em pequenas empresas locais. Pode ser apenas uma família que administra um restaurante ou uma loja do bairro, uma empresa de encanamento ou um escritório de advocacia.

Quantas dessas empresas poderiam se beneficiar de ter um site interativo, sistemas de gerenciamento de escritórios e ferramentas para automatizar seus fluxos de trabalho comuns? A maioria delas.

Agora, quantas dessas empresas podem se dar ao luxo de ter um desenvolvedor de software em tempo integral para construir e manter esses sistemas? Não tantas.

É aí que entram os freelancers. Eles podem fazer o trabalho de maneira mais econômica, caso a caso. Uma pequena empresa pode contratar um freelancer para um único projeto ou por um período mais curto.

Se você estiver ativamente construindo sua rede, algumas das pessoas que você conhece podem se tornar seus clientes.

Por exemplo, você pode conhecer um contador local que quer atualizar seu site. Talvez ele queira adicionar a capacidade de agendar uma consulta ou aceitar um pagamento com cartão de crédito por uma conta. Esses são recursos comuns que pequenas empresas podem solicitar – e você pode ficar muito bom em implementá-los.

Você também pode conhecer os gerentes de pequenas empresas que precisam de um sistema ERP, um sistema CRM, um sistema de inventário ou uma das inúmeras outras ferramentas.

Em muitos casos, há uma ferramenta de código aberto que você pode implantar e configurar para eles. Então, você pode apenas ensiná-los como usar esse sistema. E você pode cobrar uma taxa de serviço mensal para estar "de plantão" e pronto para resolver problemas que possam surgir.

Devo usar um contrato para trabalho freelance?

Você vai querer encontrar um modelo de contrato padrão, personalizá-lo e obter a aprovação de um advogado.

Pode parecer estranho fazer a padaria local assinar um contrato com você apenas para ajudar a atualizar seu site ou presença nas redes sociais, mas fazer isso tornará toda a transação mais profissional do que um mero aperto de mão.

É improvável que uma pequena empresa o leve ao tribunal por alguns milhares de dólares, mas, no caso de isso acontecer, você ficará feliz em ter assinado um contrato.

Quanto eu devo cobrar pelo trabalho como freelance?

Eu duplicaria o valor que você ganha no seu trabalho diurno, calcularia sua taxa horária e dobraria. Isso pode parecer muito dinheiro, mas o trabalho freelance é muito mais difícil do que o trabalho regular. Você tem que aprender muito.

Alternativamente, você pode cobrar por projeto. "Vou implantar e configurar este sistema para você por mil reais."

Apenas tenha certeza de especificar um prazo em que você está disposto a manter o projeto. Você não quer que as pessoas liguem para você 3 anos depois, esperando que você volte e conserte um sistema que ninguém manteve.

Como faço para garantir que clientes freelance me paguem?

Muitos outros freelancers – inclusive eu – usam esta abordagem simples: peça metade da sua compensação adiantada, antes de começar o trabalho. Quando você puder demonstrar que está na metade do caminho, peça a outra metade.

Sempre tente receber todo o dinheiro antes de realmente terminar o projeto. Desse modo, o cliente não poderá usar o dinheiro como alavanca para tentar obter trabalho extra de você.

Se você já recebeu o pagamento total, o trabalho que você fizer para ajudar seu cliente depois disso transmitirá: "Estou indo além do esperado para auxiliar você".

É uma vibe totalmente diferente de: "Xiiii – será que você vai mesmo me pagar por todo esse trabalho que estou fazendo?"

Devo usar um website de freelance como Upwork ou Fiverr?

Se você está em uma área rural do mundo e não consegue encontrar nenhum cliente localmente, pode tentar alguns desses sites de freelance. Do contrário, eu não me concentraria neles. Aqui está o porquê:

Quando você tenta conseguir contratos em um site de freelance, você está competindo com todos os freelancers do mundo inteiro. Muitos deles vivem em cidades com um custo de vida muito mais baixo que o seu. Alguns deles nem se importam tanto com suas reputações como você – e podem estar dispostos a entregar um trabalho abaixo do padrão.

Até certo ponto, esses sites promovem um fenômeno de "corrida até o fundo", onde a pessoa que se oferece para fazer o trabalho mais barato geralmente consegue o trabalho.

Se você em vez disso se concentrar em encontrar clientes através da sua própria rede local, não terá que competir com esses freelancers do exterior.

O mesmo vale para pessoas que estão procurando ajuda de desenvolvedores freelance. Se você um dia quiser contratar um freelancer, recomendo fortemente trabalhar com alguém que você possa encontrar pessoalmente, que tenha laços com a sua comunidade.

Alguém que vive na sua cidade há vários anos e frequenta muitos dos mesmos eventos sociais que você terá muito menos chances de tentar se aproveitar de você. Se tanto você quanto ele se importarem com sua reputação, os dois estarão investidos em que essa parceria funcione.

Vocês podem ser uma história de sucesso nos portfólios um do outro.

Fazer freelance é como dirigir uma empresa de uma pessoa só, o que representa muito trabalho oculto

Não subestime a quantidade de "trabalho oculto" envolvida em conduzir sua prática de desenvolvimento freelance.

Para começar, você pode querer criar sua própria entidade legal.

Nos EUA, a abordagem mais comum é criar uma Sociedade de Responsabilidade Limitada (LLC) e conduzir negócios como essa companhia – mesmo se você for a única pessoa trabalhando lá.

Isso pode simplificar seus impostos. No caso de cometer um erro e ser processado por um cliente, sua entidade legal pode ajudar a isolá-lo de responsabilidade pessoal, de modo que é sua LLC que vai à falência – não você, pessoalmente.

Você também pode considerar obter um seguro de responsabilidade para se proteger ainda mais contra isso.

Lembre-se de que, quando você está trabalhando como freelancer, normalmente, terá que pagar impostos no final do ano, então certifique-se de guardar dinheiro para isso.

Para criar sua LLC, você pode certamente encontrar documentos padrão on-line e registrá-los você mesmo. Se você realmente deseja trabalhar como freelancer, recomendo conversar com um advogado de pequenas empresas e/ou contador para se certificar de que tudo está configurado corretamente.

Quando devo parar de ser freelancer e começar a procurar um emprego?

Se você consegue pagar suas contas como freelancer, você pode apenas querer continuar fazendo isso. Com o tempo, você pode até ser capaz de construir sua própria agência de desenvolvimento de software e contratar outros desenvolvedores para ajudá-lo.

Dito isso, se você está ansiando pela estabilidade de um emprego de desenvolvedor, você pode ter sorte. Clientes freelance podem se transformar em empregos de tempo integral se você ficar com eles por tempo suficiente. Em algum momento, pode fazer sentido econômico para um cliente simplesmente oferecer a você um emprego de tempo integral a uma taxa horária mais baixa. Você ganha a estabilidade de uma semana de trabalho de 40 horas, e eles obtêm suas habilidades em tempo integral.

Você também pode ser capaz de manter alguns clientes freelance quando conseguir um emprego. Isso pode ser um bom complemento para sua renda. Tenha em mente, porém, que, como aprenderemos no próximo capítulo, seu primeiro emprego de desenvolvedor pode ser uma responsabilidade que consome quase todo o seu tempo – pelo menos, no início.

Esse primeiro ano de trabalho como desenvolvedor profissional será muito louco? Bem, vamos falar sobre isso.

Capítulo 5: como ter sucesso no seu primeiro emprego de desenvolvedor

"Um navio no porto está seguro, mas não é para isso que os navios são construídos." – Grace Hopper, Matemática, Contralmirante da Marinha dos EUA e Pioneira da Ciência da Computação

Quando conseguir seu primeiro emprego de desenvolvedor, o verdadeiro aprendizado vai começar.

Você aprenderá a trabalhar de maneira produtiva ao lado de outros desenvolvedores.

Você aprenderá Sistemas de Controle de Versão, ferramentas de Integração Contínua e Entrega Contínua (CI/CD), ferramentas de gestão de projetos e mais.

Você aprenderá como trabalhar sob a supervisão de um gerente de engenharia, como entregar antes do prazo e como lidar com uma grande dose de ambiguidades no trabalho.

Mais importante, você aprenderá como gerenciar a si mesmo.

Você aprenderá como superar barreiras psicológicas que afetam todos nós, como a síndrome do impostor. Você aprenderá seus limites e como ir um pouco além deles.

Hora da história: como um professor na casa dos 30 anos conseguiu sucesso em seu primeiro emprego como desenvolvedor?

Da última vez, na Hora da história: Quincy conseguiu seu primeiro emprego como desenvolvedor em uma startup de tecnologia local. Ele trabalharia como um dos doze desenvolvedores mantendo uma base de código grande e sofisticada. Ele não fazia ideia do que estava fazendo...

Acordei às 4 da manhã e não conseguia voltar a dormir. Tentei, mas tinha essa queimação no peito. Essa ansiedade. Pânico.

Eu tinha trabalhado por uma década na educação. Primeiro como tutor. Depois como professor. Mais tarde, como diretor de escola.

Em algumas horas, eu estaria começando do zero, trabalhando como desenvolvedor.

Será que alguma das minhas aprendizagens anteriores – sucessos anteriores – sequer importariam nessa nova carreira?

Fiz o que sempre faço quando sinto ansiedade – fui correr. Desci os morros correndo, com minha lanterna balançando na escuridão. Quando cheguei à praia, corri ao lado do oceano enquanto o sol subia por cima das copas das árvores.

Quando cheguei em casa, minha esposa já estava saindo para o trabalho. Ela me disse para não me preocupar. Ela disse, "Eu ainda vou te amar mesmo se você for demitido por não saber o que está fazendo."

Quando cheguei ao meu novo escritório, ninguém estava lá. Como professor, eu estava acostumado a chegar à escola pontualmente às 7:30. Rapidamente percebi que a maioria dos desenvolvedores de software não começam a trabalhar tão cedo.

Então, sentei de pernas cruzadas no corredor de entrada, programando junto com tutoriais no meu netbook.

Uma funcionária veio até mim com uma expressão nervosa no rosto. Ela provavelmente pensou que eu era um invasor, mas eu a tranquilizei dizendo que realmente trabalhava na empresa dela e a convenci a me deixar entrar.

Foi surreal caminhar pelo escritório vazio em direção ao setor dos desenvolvedores, com apenas a luz da placa de saída para guiar meu caminho.

Montei meu netbook em uma mesa alta vazia e terminei meu tutorial de programação.

Pouco depois, as luzes começaram a piscar ao meu redor. Meu chefe havia chegado. No início, ele não reconheceu minha presença. Ele apenas sentou em sua mesa e começou a digitar freneticamente em seu teclado mecânico.

"Larson," ele finalmente disse. "Você está pronto para seu grande primeiro dia?"

Eu não estava, mas queria sinalizar confiança. Então, disse as palavras que foram ditas pela primeira vez em "Aventureiros do Bairro Proibido", um dos meus filmes favoritos dos anos 80: "Eu nasci pronto."

big-trubs-born-ready — Você provavelmente já ouviu "Eu nasci pronto" um milhão de vezes. A frase foi dita pela primeira vez em 1986, por Jack Burton ao seu amigo Wang Chi, quando eles estavam se preparando para confrontar um mago de mil anos em seu armazém mortal. Não acredito que meus pais me deixaram assistir isso naquela época, mas estou feliz que deixaram.

"Ótimo," meu chefe disse. "Vamos conseguir uma máquina para você."

"Ah, eu já tenho uma," eu disse, batendo no meu netbook de $200. "Este bebê está rodando Linux Mint – e eu já customizei meu arquivo .emacs para poder..."

"Somos uma loja de Macs," ele disse caminhando até um armário de armazenamento. Ele remexeu por um momento e disse: "Aqui. É um modelo de 3 anos, mas deve servir. Nós o limpamos para os padrões de fábrica."

Eu comecei a dizer que já estava familiarizado com minha configuração e que poderia trabalhar muito mais rápido com ela, mas ele não quis saber.

"Todos estamos usando as mesmas ferramentas. Isso torna a colaboração muito mais fácil. Convenção primeiro, configuração depois, você sabe."

Foi a primeira vez que ouvi a frase "convenção primeiro, configuração depois", mas ela apareceria muito nos dias seguintes.

Passei as próximas horas configurando meu novo computador de trabalho enquanto outros desenvolvedores chegavam.

Era quase 10 da manhã quando começamos nossa reunião de equipe. Todos nós ficamos em um círculo perto do quadro branco. Nós nos revezamos relatando no que estávamos trabalhando naquele dia.

Todos deram atualizações rápidas e precisas de status.

Quando chegou minha vez, comecei a me apresentar. Já estava ansioso o suficiente, quando entrou ninguém menos que Mike, aquele cara ultramaratonista que organizava os eventos do Santa Barbara Startup. Ele estava mastigando algumas cenouras baby, tendo já corrido cerca de 30 milhas naquela manhã.

Depois que terminei, Mike falou, dando-me as boas-vindas e dizendo que me tinha visto em alguns de seus eventos. Ele então deu uma atualização de status de 15 segundos sobre algum recurso no qual estava trabalhando.

A reunião inteira levou apenas cerca de 10 minutos e todos se dispersaram de volta para suas mesas.

Eu eventualmente consegui fazer a base de código da empresa rodar no meu novo laptop. Era uma aplicação em Ruby on Rails que havia crescido ao longo de 5 anos. Executei o comando rake stats e vi que eram milhões de linhas de código. Eu estremeci. Como eu poderia compreender tudo aquilo?

Meu vizinho, um desenvolvedor rude e barbudo, disse, "Ah, a maior parte disso são apenas pacotes. A base de código real com a qual você vai trabalhar tem apenas, talvez, umas 100 mil linhas. Não se preocupe. Você vai pegar o jeito."

"Meu nome é Nick, aliás," ele disse, se apresentando. "Se você precisar de ajuda é só me avisar. Eu estou mexendo nessa base de código há alguns anos, então devo ser capaz de te ajudar."

Nos dias seguintes, bombardeei o Nick com perguntas sobre todos os sistemas internos que encontrei.

Eventualmente, Nick começou a definir seu status no chat como "modo de programação" e a colocar seus fones de ouvido com cancelamento de ruído. Ele girou as costas um pouco em minha direção, com a linguagem corporal de: "me deixe em paz para que eu possa fazer meu próprio trabalho também".

Esta foi uma das minhas primeiras lições sobre dinâmica de equipe. Você não quer esgotar sua boa vontade fazendo muitas perguntas. Você precisa melhorar em aprender as coisas por conta própria.

Essa, porém, era uma base de código enorme e estava amplamente sem documentação, exceto por comentários em linha e uma wiki da equipe bem vaga.

Como era uma base de código de código fechado, na qual apenas os desenvolvedores ao meu redor estavam trabalhando, eu não podia usar o Stack Overflow para descobrir onde a lógica específica estava localizada. Eu só tinha que tatear no escuro.

Comecei a rodar entre qual vizinho eu incomodaria com uma pergunta específica, mas parecia que eu estava rapidamente esgotando qualquer entusiasmo que eles poderiam ter por mim como colega de equipe.

Eu corrigi demais. Eu fiquei tímido até mesmo para fazer perguntas simples. Criei uma regra para mim mesmo de que eu tentaria por 2 horas antes de pedir ajuda.

Em algum momento, depois de lutar por várias horas, eu pedi ajuda. Quando meu gerente descobriu que eu estava preso a manhã inteira, ele perguntou: "Por que você não pediu ajuda mais cedo?"

Outra luta foi entender a própria base de código – o "monólito" e seus muitos microsserviços.

A base de código tinha milhares de testes unitários e testes de integração. Sempre que você escrevia uma nova contribuição de código, você também deveria escrever testes. Esses testes ajudavam a garantir que seu código fizesse o que deveria – e não quebrasse nenhuma funcionalidade existente.

Eu frequentemente "quebrava a build" ao submeter código que eu achava que estava suficientemente testado – apenas para que meu código quebrasse alguma outra parte da aplicação que eu não tinha considerado. Isso frustrava toda a equipe, que não podia fazer o merge de seu próprio código até que o problema fosse resolvido.

A build quebrava várias vezes por semana. Eu não era a única pessoa que cometia esses tipos de erros, mas eu sentia que era.

Havia dias em que eu sentia que não estava preparado para ser um desenvolvedor. Eu dizia para mim mesmo: "Quem eu estou enganando? Eu só acordo um dia e decido que vou ser um desenvolvedor?"

Continuava ouvindo os ecos de todas aquelas coisas que meus amigos desenvolvedores tinham me dito um ano antes, quando eu estava começando minha jornada em programação.

"Como você vai competir com pessoas que cresceram programando desde cedo?"

"Você vai ter que beber um oceano inteiro de conhecimento."

"Por que você simplesmente não continua com o que já é bom?"

Eu passava a fazer pausas progressivamente mais longas para sair do computador. O escritório tinha uma cozinha cheia de lanches. Eu encontraria mais desculpas para levantar e pegar um lanche. Qualquer coisa para adiar a sensação esmagadora de que eu não tinha ideia do que estava fazendo.

Os primeiros meses foram difíceis. Durante as reuniões diárias de equipe, parecia que todos estavam avançando rápido, fechando bugs abertos e lançando funcionalidades. Parecia que eu não tinha nada a dizer. Eu ainda estava trabalhando na mesma funcionalidade do dia anterior.

Todos os dias, quando eu acordava e me preparava para o trabalho, sentia medo. "Hoje vai ser o dia em que eles me demitem."

No entanto, eu ia para o trabalho e todos eram bem gentis, bem pacientes. Eu pedia ajuda se realmente estivesse preso. Eu fazia algum progresso, e talvez corrigisse um ou dois bugs.

Eu estava ficando mais rápido em navegar na base de código. Eu estava ficando mais rápido em ler rastros de pilha quando meu código dava erro. Eu estava lançando funcionalidades em um ritmo mais rápido do que antes.

Sempre que meu chefe me chamava para entrar em seu escritório, eu pensava comigo mesmo: "Ah não, eu estava certo. Eu vou ser demitido hoje." Ele, então, apenas me designava mais alguns bugs para corrigir ou funcionalidades para desenvolver. Ufa.

Era a coisa mais surreal – eu morrendo de medo de que seria despedido e ele sem ideia de que algo estava errado.

Claro, eu já tinha ouvido o termo "síndrome do impostor" antes, mas eu não percebi que era isso que eu estava experimentando. Certamente, eu estava apenas sofrendo da síndrome "sou péssimo em programação", certo?

Um dia, eu estava sentado ao lado de Nick e ele parecia muito cansado. Eu me ofereci para pegar um refrigerante para ele na cozinha.

Quando voltei, ele abriu a lata, tomou um gole e se recostou na cadeira, olhando para seu monitor cheio de código. "Esse bug, cara. Três semanas tentando consertar esse único bug. A essa altura, eu estou depurando ele até no meu sono."

"Três semanas tentando consertar o mesmo bug?" Eu perguntei. Eu nunca tinha ouvido falar de algo assim.

"Alguns bugs são mais difíceis de resolver que outros. Este é um daqueles realmente perversos."

Parecia que alguém tinha me dado uma bofetada com um salmão. Eu via meu trabalho como blocos de tarefas, como se devesse levar meio dia para corrigir um bug e, se levasse mais tempo que isso, eu estava fazendo algo errado.

Porém, aqui estava o Nick – com seu diploma de ciência da computação da Universidade da Califórnia e seus anos de experiência trabalhando nessa mesma base de código – e ele estava empacado por três semanas com um único bug.

Depois de tudo, quando orçamos o tempo para as funcionalidades, às vezes tínhamos "funcionalidades de 5 dias" ou até "funcionalidades de 2 semanas". Não fazíamos isso para bugs, mas eles provavelmente variavam de maneira semelhante.

Fui para casa e li mais sobre a Síndrome do Impostor. O que li explicou muito da minha ansiedade.

Nos meses seguintes, continuei desenvolvendo funcionalidades para a base de código. Continuei colaborando com minha equipe. Ainda era um trabalho difícil, extenuante, mas estava começando a ficar um pouco mais fácil.

Eu me aproximei dos meus colegas de trabalho todos os dias no almoço jogando jogos de tabuleiro. Uma semana, tivemos um torneio de xadrez em toda a empresa.

Depois de algumas rodadas, joguei contra o CEO.

O CEO tem um estilo de jogo de xadrez não ortodoxo. Ele usou uma abertura boba que poucos jogadores de xadrez sérios escolheriam. Eu consegui assumir a liderança inicial no jogo.

Ao longo dos próximos movimentos, porém, ele conseguiu lentamente recuperar o controle do jogo. Eventualmente, ele ganhou a vantagem e me venceu.

Quando perguntei a ele como encontrava tempo para manter suas habilidades de xadrez afiadas enquanto dirigia uma empresa, ele disse: "Ah, eu não encontro. Eu jogo apenas uma ou duas vezes por ano."

Então, ele fez uma pausa por um momento, sua mão congelada à sua frente, como se preparando para se lançar em um discurso. Ele disse: "Meu tio era um jogador de xadrez competitivo. Ele me deu apenas um único conselho a seguir: toda vez que seu oponente mover, diminua o ritmo e tente entender o jogo da perspectiva dele – por que ele fez esse movimento?"

Ele se curvou e depois se desculpou dizendo que precisava correr para uma reunião.

Refleti muito ao longo dos anos sobre isso que ele me disse. Percebi que esse conselho não se aplica apenas ao xadrez. Você pode aplicá-lo a qualquer situação adversa.

Se você continua tendo que fazer uma tarefa, deveria automatizá-la

Outra lição que aprendi sobre desenvolvimento de software: como eu era a pessoa mais "júnior" na equipe, muitas vezes me atribuíram o "trabalho braçal" que ninguém mais queria fazer. Uma dessas tarefas era ser a "babá de build".

Sempre que alguém quebrava a build, eu baixava a versão mais recente da nossa branch principal e usava git bisect para tentar identificar o commit que quebrou.

Eu abria aquele commit, executava os testes e descobria o que havia dado errado. Em seguida, enviava uma mensagem para a pessoa que quebrou a build, dizendo o que ela precisava corrigir.

Eu fiquei realmente rápido em fazer isso. Em um dia cheio de relatórios de bugs confusos e solicitações de funcionalidades ambíguas, eu esperava que a build quebrasse. Isso me dava uma chance de me sentir útil rapidamente.

Não demorou muito para que alguém na equipe dissesse: "Com a frequência que a build quebra, deveríamos apenas automatizar isso".

Eu não disse nada, mas me senti na defensiva. Isso era uma má ideia. Como um script poderia fazer tão bem quanto eu – um desenvolvedor de carne e osso?

Levaram alguns dias, mas, certamente, um dos meus colegas de equipe criou um script e eu não precisava mais ser a babá da build.

Foi estranho ver uma mensagem de que a build falhou e, em seguida, um momento depois, ver uma mensagem dizendo qual commit quebrou a build e quem precisava corrigi-lo.

Me senti indignado. Não disse nada, mas na minha mente estava pensando: "Esse deveria ser meu trabalho. Esse script tirou meu emprego."

É claro que, agora, relembro a minha reação e rio. Imagino-me, agora com 40 anos, ainda largando tudo várias vezes por semana para poder ser a babá da build.

Porque, na prática, se uma tarefa pode ser automatizada – se você pode dividi-la em etapas discretas que um computador pode executar de modo confiável para você – então provavelmente você deveria automatizá-la.

Há muito trabalho mais interessante que você pode fazer com seu tempo.

is_it_worth_the_time_2x-1 — *Este gráfico do XKCD pode ajudar você a descobrir se uma tarefa vale o investimento de tempo para ser automatizada.*

Lições dos anciãos do vilarejo

Aprendi muito com outras pessoas na equipe. Aprendi conceitos de design de produto com Mike. Ele me levou para correr na praia e me ensinou como correr com a parte da frente dos pés, onde as bolas dos meus pés tocam o chão antes dos calcanhares. Isso é um pouco mais fácil para suas articulações.

Aprendi sobre conceitos de engenharia de software ágil com Nick. Ele me ajudou a escolher alguns bons livros de desenvolvimento de software na biblioteca da empresa e até me convidou para uma festa de inauguração de casa, onde conheci seus filhos.

Depois de cerca de um ano trabalhando para a empresa, senti que era hora de tentar trilhar meu próprio caminho e construir alguns projetos de aprendizado on-line. Eu me sentei com o CTO para dar a notícia de que estava saindo.

Eu disse: "Sou grato por vocês terem me contratado, mesmo que eu fosse claramente o desenvolvedor mais fraco da empresa."

Ele apenas deu uma risada e disse: "Claro, quando você começou, você era o pior desenvolvedor da equipe. Eu diria que você ainda é o pior desenvolvedor da equipe."

Eu fiquei lá sentado, sorrindo de maneira constrangedora, piscando para ele, sem saber se ele estava apenas bravo por eu estar saindo.

Então, ele disse: "Mas isso é inteligente. Você é inteligente. Você sempre quer ser o pior músico da banda. Você sempre quer estar cercado por pessoas que são melhores do que você. É assim que você cresce."

Duas semanas depois, fiz check-in das minhas alterações no código do dia e entreguei meus tickets abertos. Reiniciei meu Mac para as configurações de fábrica e o entreguei ao meu gerente.

Eu saí correndo, alinhando contratos freelance para manter as luzes acesas. Busquei um apartamento na Bay Area, do outro lado da ponte do coração pulsante da tecnologia em South of Market, San Francisco.

Agora, eu era um desenvolvedor profissional com um ano de experiência já adquirido.

Eu estava pronto para sonhar novos sonhos e fazer novos movimentos.

Eu estava a caminho da terra das startups.

Lições do meu primeiro ano como desenvolvedor

Fiz muitas coisas certas durante meu primeiro ano como desenvolvedor profissional. Eu me dou uma nota B-.

Se eu tivesse a chance de fazer tudo de novo, há algumas coisas que eu faria diferente.

Aqui estão algumas dicas. Que elas maximizem seu aprendizado e minimizem suas dores de cabeça.

Deixe seu ego na porta

Muitas pessoas que entram na área de desenvolvimento de software começam desde o nível mais básico. Um título que você pode ter é o de "Desenvolvedor Júnior."

Pode ser um pouco constrangedor estar na meia-idade e ter a palavra "júnior" no seu título, mas, com um pouco de paciência e muito trabalho duro, você pode superar isso.

Um problema que eu enfrentava todos os dias era – eu tinha 10 anos de experiência profissional. Eu não era um funcionário de nível inicial. Sim, eu era novo no desenvolvimento, mas eu era bastante experiente em ensinar e até gerenciar pessoas (eu havia gerenciado 30 funcionários no meu emprego mais recente como professor).

Ainda assim – apesar de toda a minha experiência de trabalho anterior – eu era um desenvolvedor de nível inicial. Eu ainda era um novato. Um neófito.

Por mais que eu quisesse gritar "Eu costumava ser o chefe – eu não preciso que você me vigie" – a verdade era que eu precisava, sim, de babás.

O que ocorreria se eu acidentalmente quebrasse a produção? Se eu introduzisse uma vulnerabilidade de segurança na aplicação? Se eu apagasse todo o banco de dados? Ou se eu criptografasse algo importante e perdesse a chave?

Esses tipos de desastres acontecem o tempo todo.

A realidade é que, como um novo desenvolvedor, você é como um elefante em uma loja de cristais, tentando andar com cuidado, mas quebrando tudo em seu caminho.

Não deixe que a impaciência com seus colegas de equipe tome conta de você. Resista à tentação de falar sobre seus diplomas avançados, prêmios que ganhou com seu trabalho, ou aquela vez que o prefeito lhe deu a chave da cidade (OK, talvez essa última nunca tenha acontecido comigo).

Não apenas porque isso fará de você uma pessoa difícil de trabalhar, mas porque isso distrairá você de sua tarefa.

Nos primeiros meses da minha carreira como desenvolvedor, eu usava minhas conquistas passadas como uma espécie de chupeta. "Sim, eu sou péssimo em programação, mas sou fenomenal em ensinar gramática inglesa. Já mencionei que eu costumava administrar uma escola?"

Quando seus dedos estão no teclado e seus olhos no editor de código, você precisa deixar esse passado para trás. Você pode se deleitar com as conquistas de ontem à noite, depois que o trabalho de hoje estiver feito.

Por enquanto, você precisa aceitar todas as emoções que vêm com ser um iniciante novamente. Você precisa se concentrar na tarefa à sua frente e concluir o trabalho.

Provavelmente, é só a Síndrome do Impostor falando

Quase todo mundo que eu conheço já experimentou a Síndrome do Impostor. Aquela sensação de que você não pertence. Aquela sensação de que, a qualquer momento, seus colegas de equipe vão ver que você é terrível como programador e vão expor você como não sendo um "desenvolvedor de verdade."

Até certo ponto, essa sensação não desaparece. Ela está sempre ali no fundo da sua mente, pronta para surgir quando você tenta fazer algo novo.

"Você poderia me ajudar a superar essa mensagem de erro?" "Hum... Não tenho certeza se sou a melhor pessoa para perguntar."

"Você poderia programar em par comigo para implementar este recurso?" "Hum... Acho que sim... se você não encontrar alguém mais qualificado."

"Você poderia dar uma palestra na nossa próxima conferência?" "Hum... Eu?"

Conheci engenheiros sêniores que ainda sofrem ocasionalmente de síndrome do impostor, mais de uma década em suas carreiras.

Quando você se sente inadequado ou despreparado, pode ser apenas a síndrome do impostor falando.

Claro – se você me entregasse um bisturi e dissesse: "ajude-me a realizar uma cirurgia cardíaca", eu me sentiria como um impostor. Até certo ponto, sentir-se fora das suas capacidades é totalmente razoável se você realmente estiver fora delas.

O problema é que, se você tem praticado desenvolvimento de software, pode ser capaz de fazer algo e ainda assim inexplicavelmente sofrer de ansiedade.

Eu não sou médico, mas meu instinto é que – para a maioria das pessoas – a síndrome do impostor gradualmente diminuirá com o tempo, à medida que você pratica mais e constrói mais confiança.

No entanto, ela pode aparecer aleatoriamente. Eu não tenho vergonha de admitir que às vezes sinto pontadas de síndrome do impostor ao fazer uma nova tarefa, ou uma que eu não faço há algum tempo.

A chave é simplesmente aceitá-la: "Provavelmente é só a síndrome do impostor falando."

Apenas siga em frente.

Encontre sua tribo, mas não caia na armadilha do tribalismo

Quando você conseguir seu primeiro emprego como desenvolvedor, trabalhará ao lado de outros desenvolvedores. Que bom! Você encontrou sua tribo.

Você passará muito tempo com eles, e todos vocês podem começar a se sentir como uma unidade coesa.

Não ignore, porém, as pessoas não desenvolvedoras ao seu redor.

Na minha história acima, falei sobre Mike, o Gerente de Produto que também organizava eventos de startup. Ele era "não técnico". Seu conhecimento de programação era limitado, no melhor dos casos, mas eu ousaria dizer que aprendi tanto com ele quanto com qualquer outra pessoa na empresa.

Você pode trabalhar com outras pessoas de outros departamentos – designers, gerentes de produto, gerentes de projeto, pessoas de TI, pessoas de QA, profissionais de marketing, até mesmo pessoal de finanças e contabilidade. Você também pode aprender muito com essas pessoas.

Não fique muito confortável e não se especialize muito cedo

Eu frequentemente dou este conselho para quem está começando sua jornada na programação: "aprenda habilidades gerais de programação (JavaScript, SQL, Linux etc.) e depois se especialize no trabalho."

A ideia é: uma vez que você entende como funcionam as ferramentas mais comuns, você pode então aprender os equivalentes dessas ferramentas menos comuns.

Por exemplo, uma vez que você aprende PostgreSQL, você pode facilmente aprender MySQL. Uma vez que você aprende Node.js, você pode facilmente aprender Ruby on Rails ou Java Spring Boot.

Algumas pessoas, no entanto, se especializam muito cedo no trabalho. O chefe delas pode pedir a elas para "controlar" uma certa API ou funcionalidade. Se elas fizerem um bom trabalho com isso, o chefe pode continuar dando projetos semelhantes.

Você está gerenciando apenas a si mesmo, mas seu chefe está gerenciando muitas pessoas. Ele pode estar muito ocupado para desenvolver um entendimento detalhado de suas habilidades e interesses. Ele pode passar a ver você como "a pessoa de XYZ" e apenas passar tarefas relacionadas a isso.

Você, no entanto, sabe no que você é bom e no que está interessado. Você pode tentar se voluntariar para projetos fora da sua zona de conforto. Se você conseguir que seu chefe atribua você a esses projetos, poderá continuar expandindo suas habilidades e, potencialmente, trabalhar com novas equipes.

Lembre-se: seu chefe pode ser responsável pelo seu desempenho no trabalho, mas você é responsável pelo seu desempenho em toda a sua carreira.

Assuma projetos que cumpram sua obrigação com seu empregador e, ao mesmo tempo, posicionem você bem para seus objetivos de carreira a longo prazo.

Epílogo: você consegue

Se há uma mensagem que eu quero deixar com você aqui, é esta: você consegue!

Você pode aprender esses conceitos.

Você pode aprender essas ferramentas.

Você pode se tornar um desenvolvedor.

Então, no momento em que alguém lhe der dinheiro para você ajudar a programar algo, você se formará como um desenvolvedor profissional.

Aprender a programar e conseguir o primeiro emprego como desenvolvedor é um processo assustador, mas não se assuste.

Se você persistir, eventualmente conseguirá. É apenas uma questão de prática.

Construa seus projetos. Mostre-os aos seus amigos. Construa projetos para seus amigos.

Crie sua rede de contatos. Ajude as pessoas que você encontrar pelo caminho. O que vai, volta. Você colhe o que planta.

Não é tarde demais. A vida é longa.

Você vai olhar para este momento daqui a alguns anos e ficará feliz por ter tomado uma atitude.

Planeje para que demore muito tempo. Planeje para a incerteza.

Acima de tudo, continue voltando ao teclado. Continue participando de eventos. Continue compartilhando suas conquistas com os amigos.

Como Lao Tsu, o Velho Mestre, certa vez disse:

"Uma jornada de mil milhas começa com um único passo."

Ao terminar este livro, você já deu um passo. Digo, você pode já ter dado muitos passos em direção a seus objetivos.

O momento é tudo. Então, mantenha o momento que você já criou durante as últimas horas com este livro.

Comece a programar seu próximo projeto hoje.

Lembre-se sempre: você consegue!!!