Há 10 anos, eu me sentava no closet do meu apartamento em São Francisco e programava as primeiras centenas de linhas do freeCodeCamp.

Eu não sabia na época, mas o fCC rapidamente se tornaria uma comunidade global de adultos ocupados aprendendo programação juntos.

Muitos desses campers – como nos chamamos agora – conseguiram empregos como engenheiros de software. Muitos deles também contribuíram com código para a base de código aberto do fCC.

Nos últimos 10 anos, construímos:

1. Um currículo interativo de 3 mil horas que ensina Matemática, Programação e Ciência da Computação.
2. Uma biblioteca com mais de 12 mil tutoriais de programação – e dezenas de livros completos – em nossa publicação em inglês.
3. Um canal no YouTube com mais de mil cursos completos gratuitos. Acabamos de atingir 10 milhões de inscritos há poucos dias.
4. O fórum de programação mais gentil e solidário do planeta. Temos também um servidor no Discord igualmente gentil.

A equipe cresceu de apenas eu para um grupo de 35 professores e engenheiros. Essa é apenas a ponta do iceberg. Uma grande parte do trabalho é feita pela própria comunidade open source. Todos os dias, voluntários surgem para melhorar nossa base de código, criar recursos de aprendizado abertos e ajudar uns aos outros no fórum.

Estamos apenas começando. Então, em vez de um texto sentimental sobre os primeiros 10 anos do freeCodeCamp, vamos focar em nossos planos para os próximos 10 anos à nossa frente.

Afinal, a missão da nossa instituição beneficente é criar recursos de aprendizado gratuitos que ajudem as pessoas a aprender matemática, programação e ciência da computação. Ainda há muito trabalho a ser feito.

Neste artigo, detalharei nossas principais iniciativas para a próxima década. Vou mostrar algumas grandes melhorias – algumas das quais estão chegando a tempo para o Natal.

Uma certificação para governar todas elas

A maior melhoria é que estamos combinando a maior parte do nosso currículo atual em uma única certificação abrangente de Desenvolvedor Full-Stack Certificado (CFSD). Estamos desenvolvendo várias novas certificações igualmente abrangentes do zero.

Buscamos inspiração em organizações sem fins lucrativos de certificação de desenvolvedores estabelecidas, como a CompTIA e a (ISC)². Estamos reformulando nossas certificações para se assemelharem mais de perto às certificações estabelecidas no setor.

Nossas novas certificações:

• Serão ainda mais abrangentes
• Envolverão um exame final
• Envolverão um projeto final
• Serão válidas por 3 anos, com um caminho para renovação

Como tudo o que o freeCodeCamp cria, essas certificações continuarão sendo completamente gratuitas.

O currículo de preparação para a certificação de Desenvolvedor Full-Stack Certificado cobrirá:

• HTML semântico
• Acessibilidade
• Fundamentos de CSS
• CSS Flexbox
• Design para desenvolvedores
• Tipografia
• Editores de código
• Fundamentos de JavaScript
• Programação funcional
• Funções de ordem superior e callbacks
• Manipulação do DOM e eventos
• Padrões da web
• Fundamentos de React
• Fundamentos de TypeScript
• Conceitos de testes
• Criação de scripts no Bash
• SQL e bancos de dados relacionais
• Git e GitHub
• Segurança e privacidade
• Node.js
• Express.js
• Fundamentos de Python
• Pensamento algorítmico
• Estruturas de dados
• Programação orientada a objetos
• Programação dinâmica
• Segurança para desenvolvedores para a Web
• Ferramentas e implantação
• Trabalho com APIs
• Fundamentos de engenharia de IA
• Como conseguir um emprego de desenvolvedor
• e mais

A pedido popular, vamos cobrir muito mais teoria – diretamente no currículo principal.

Anteriormente, nossas certificações eram 100% focadas na construção de projetos. Recebemos muitos feedbacks dos campers de que fomos longe demais na direção de "aprender fazendo" – e que muitos campers desejam mais explicação da teoria também.

Isso mesmo – você não precisará mais complementar o currículo principal do freeCodeCamp com vídeos teóricos do nosso YouTube ou livros da nossa publicação. De agora em diante, vamos cobrir toda a teoria essencial ao longo do caminho.

Estamos fazendo isso adicionando breves palestras em vídeo ministradas pela equipe de design instrucional do freeCodeCamp, incluindo Beau Carnes e Ania Kubów. Cada uma delas também terá uma transcrição completa, para os campers que preferem ler a assistir.

Vamos inserir você nos laboratórios de programação ao estilo "tela em branco" muito mais cedo no currículo, para minimizar a necessidade de ajuda.

Aqui está o conteúdo completo do novo caminho para Desenvolvedor Full-Stack Certificado. É bastante extenso:

• 64 workshops – cursos interativos passo-a-passo sobre ferramentas que vão de HTML a SQL e Python
• 513 palestras – vídeos curtos cobrindo conceitos de ciência da computação, com perguntas de múltipla escolha para verificar sua compreensão
• 83 laboratórios – projetos onde você começa com um editor em branco e um conjunto de testes e precisa desenvolver seu projeto para que todos os testes sejam aprovados
• 62 páginas de revisão – listas abrangentes de tópicos de cada módulo que você pode revisar para se preparar para questionários e exames
• 66 questionários e 6 exames de preparação – para afirmar sua compreensão dos conceitos e ferramentas de desenvolvimento full-stack
• 1 projeto final – um grande projeto único que você construirá para seu portfólio, revisado por professores dentro da comunidade do freeCodeCamp
• 1 exame final – um exame abrangente com 90 questões, supervisionado, realizado dentro do ambiente de exame do freeCodeCamp

Após concluir todo o trabalho deste curso, você estará qualificado para fazer o exame final. Criamos nosso próprio ambiente de exame de código aberto, onde você pode fazer um exame aprofundado sobre tudo o que aprendeu ao longo de todo o nosso trabalho preparatório.

Se você não passar no exame, poderá refazê-lo uma vez a cada 24 horas até conseguir passar. A cada vez, o exame será gerado aleatoriamente de um grande corpus de perguntas de exame.

Você pode ter ouvido histórias horríveis sobre pessoas que fazem exames on-line e são acusadas falsamente de trapaça. Pensamos bastante em como vamos aplicar nosso código de conduta acadêmico. Sempre haverá um humano no loop para essas decisões.

Não haverá desqualificações automáticas por "você se levantou da cadeira porque seu bebê começou a chorar". Consideraremos todas essas coisas ao administrar esses exames.

Uma vez que você consiga passar, receberá uma certificação gratuita, verificada e serializada que poderá adicionar ao seu currículo ou CV, além de inserir em sua conta do LinkedIn. A certificação permanecerá válida por 3 anos – momento em que você poderá realizar um processo gratuito de educação continuada para re-certificar.

Aqui está um vídeo de 5 minutos que vai guiá-lo por algumas das grandes atualizações do currículo do freeCodeCamp.

Estamos desenvolvendo três outras certificações

Uma vez que a nova certificação de Desenvolvedor Full-Stack Certificado esteja ativa, nossa equipe de design instrucional voltará sua atenção para a construção de três certificações adicionais:

A certificação de engenheiro de aprendizado de máquina certificado (fCC-CMLE)

Esta certificação envolverá o aprendizado de Python e suas muitas bibliotecas. Você também aprenderá uma quantidade enorme de matemática e teoria. Muitos dos projetos envolverão a criação de seus próprios modelos. Kylie Ying já está trabalhando com engenheiros de aprendizado de máquina para ajudar a projetar isso. Estamos planejando lançar parte dessa certificação em 2025.

A certificação de engenheiro de sistemas de software certificado (fCC-CSSE)

Esta certificação envolverá programação de baixo nível e computação de alto desempenho. Você aprenderá a programar em C e C++ e desenvolverá vários projetos – como seu próprio compilador e seu próprio mecanismo de busca. Estamos planejando lançar parte disso para 2026.

A certificação de cientista de dados certificado (fCC-CDS)

Estamos trabalhando em um currículo abrangente de Ciência de Dados há vários anos. Como você deve saber, o freeCodeCamp já possui muitos cursos populares sobre ferramentas de Ciência de Dados como Python, R e pacotes estatísticos no canal do YouTube da comunidade do freeCodeCamp.

O desafio de ensinar Ciência de Dados é ensinar a grande quantidade de matemática envolvida na área. Também precisamos montar um aprendizado orientado a projetos que possamos avaliar de maneira programada.

Nosso objetivo é oferecer a melhor educação em Ciência de Dados disponível fora de um programa de doutorado. Este será o maior desafio de todos, mas estamos preparados para isso.

Estamos planejando lançar parte dessa certificação em 2027.

Quando teremos mais informações sobre essas certificações e seus cursos?

Estamos trabalhando em esboços abrangentes de currículo para essas certificações e planejamos tornar algumas delas públicas em 2025.

O que acontecerá com as certificações atuais do freeCodeCamp?

O freeCodeCamp tem uma longa tradição de preservar materiais antigos dos certificados legados. Desta vez, não será diferente.

Recomendamos que você migre para o novo currículo do certificado de Desenvolvedor Full-Stack Certificado assim que ele estiver ativo neste Natal. Você já pode ter concluído alguns dos projetos, já que muitos deles vêm de nossos certificados antigos.

Dito isso, se você estiver na metade de um certificado antigo e quiser continuar seu progresso nele, pode fazê-lo.

As certificações legadas vão expirar?

Queríamos dar a todos bastante tempo para usar seus certificados atuais antes que precisassem conquistar a nova certificação de Desenvolvedor Full-Stack Certificado. Achamos que 3 anos é suficiente.

Adicionamos essa data de validade a todas as certificações do freeCodeCamp.

Daqui em diante, sempre que você obtiver a certificação de Desenvolvedor Full-Stack Certificado ou dos outros 3 certificados que estão por vir, ela permanecerá válida por 3 anos a partir da data em que você a conquistou.

Novamente, estamos desenvolvendo um programa de educação continuada que você poderá usar três anos depois para renovar sua certificação. Tudo isso será completamente grátis.

Por que o freeCodeCamp está exigindo exames e adicionando datas de validade às certificações?

Estamos fazendo isso para alinhar essas certificações com outras certificações do setor de tecnologia. Todas essas certificações principais exigem passar em um exame de certificação e expiram após 3 anos.

Nosso objetivo é que as certificações do freeCodeCamp sejam o mais convencionais possível, para facilitar a compreensão delas por parte dos empregadores.

O freeCodeCamp se expandirá para recrutamento ou emprego?

Não temos planos de fazer isso. A missão da nossa instituição beneficente é simples: criar recursos de aprendizagem gratuitos. Planejamos manter nossa equipe de professores pequena e focada, em vez de trazer diversos pessoas que não são professores.

Quanto do conteúdo se sobreporá de uma certificação para outra?

Algumas das certificações compartilharão alguns projetos e aulas comuns. Por exemplo, se você já completou o curso introdutório de Python durante a certificação de Desenvolvedor Full-Stack Certificado, não precisará completá-lo novamente para a certificação de engenheiro de aprendizagem de máquina certificado.

Meus certificados antigos permanecerão on-line? Os links de verificação continuarão funcionando?

Certificados expirados ainda aparecerão no seu perfil. Links diretos para eles ainda continuarão funcionando. Eles serão claramente marcados como "Expirado em [data]" até que você os renove. Novamente, isso não acontecerá com nenhum certificado do fCC até 31 de dezembro de 2027, no mínimo.

O que acontecerá com as 11 certificações atualmente listadas em freecodecamp.org/learn?

Elas continuarão disponíveis lá por pelo menos mais alguns anos – listadas como certificações legadas. A maior parte do conteúdo dentro delas será reaproveitada e melhorada para fazer parte dessas novas certificações.

Terei que refazer projetos que já fiz?

Alguns dos conteúdos das certificações antigas permanecerão nessas novas certificações. Na maioria dos casos, você não deverá ter que refazer os projetos que já fez. Se você já construiu alguns projetos, há uma boa chance de que algumas seções das novas certificações já sejam marcadas como completas para você quando as visualizar.

Fale mais sobre o ensino de linguagens de programação como Rust e Java, ou ferramentas de banco de dados NoSQL.

Estamos mantendo nosso currículo focado nas ferramentas mais populares para ajudar a colocar os alunos no melhor lugar para trabalhar como desenvolvedores. Isso significa Python, JavaScript, SQL e ferramentas como Git e Linux.

Temos muitos cursos em vídeo sobre outras ferramentas populares no canal da comunidade do freeCodeCamp no YouTube, bem como tutoriais na publicação do freeCodeCamp. Continuaremos a ensinar esses tópicos como extracurriculares para quem quiser aprendê-los.

Como está o progresso do currículo de inglês?

Estamos trabalhando arduamente para criar um currículo interativo de inglês para ajudar os alunos a melhorar seu inglês.

Ensinamos por meio de uma combinação de vídeos e exercícios interativos, seguidos por um exame formal de certificação.

Estamos atualmente terminando o nível A2 (pré-intermediário) e começando a trabalhar no nível B1 (intermediário).

Como está avançando o programa de graduação universitária gratuito?

Estamos fazendo um progresso constante rumo à oferta de um curso Associado em Matemática e de um Bacharelado em Ciência da Computação. Já desenvolvemos 2 dos cursos de matemática e estamos trabalhando duro nos 38 cursos de nível universitário restantes e suas aulas, laboratórios e exames.

O freeCodeCamp tem uma pequena equipe de designers instrucionais. Agora, estamos focados principalmente no conteúdo da certificação de Desenvolvedor Full-Stack Certificado e no programa de certificação de inglês. Quando terminarmos esses, alocaremos mais recursos para os programas de graduação para acelerar ainda mais seu desenvolvimento.

10 Anos não é nada.

É incrível o quanto conquistamos como comunidade em apenas 10 anos.

• Um currículo gratuito com três mil horas de recursos de aprendizagem interativa
• Milhares de cursos em vídeo extracurriculares, livros e tutoriais
• Dezenas de milhares de alunos que conseguiram empregos como desenvolvedores
• Dezenas de milhares de colaboradores que estão adquirindo experiência ao voluntariar seu tempo e talentos por meio de código aberto e ao ajudar outros alunos

Eu encorajo você a se envolver na comunidade global do freeCodeCamp. Você pode navegar por nossos principais colaboradores de código aberto de 2024 (em inglês). Aqui está nosso guia do colaborador (em inglês), se você quiser se aprofundar.

Também encorajo você a se tornar um apoiador. Se você já nos apoia todo mês e quer fazer uma doação de fim de ano para nossa organização, fique à vontade. Aqui estão algumas formas dedutíveis de imposto que você pode apoiar nossa missão (texto em inglês).

Se você tiver qualquer dúvida sobre formas de apoiar a missão da nossa organização, ou simplesmente precisar de um recibo de doação para seus impostos, envie-me um e-mail diretamente

Um brinde aos próximos 10 anos.

– Quincy

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

1. Prefácio: para quem é este livro?
2. Resumo em 500 palavras
3. Capítulo 1: como desenvolver suas habilidades
4. Capítulo 2: como construir sua rede de contatos
5. Capítulo 3: como construir sua reputação
6. Capítulo 4: como ser pago para programar – clientes freelance e a busca por um emprego
7. Capítulo 5: como ter sucesso no seu primeiro emprego de desenvolvedor
8. Epílogo: você consegue

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.

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.

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

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.

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:

1. As ferramentas ainda são primitivas.
2. A maioria das pessoas não é boa em lidar com a ambiguidade – e aprender a programar é ambíguo. As pessoas se perdem.
3. 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

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

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.

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:

1. Experiência de trabalho
2. Educação
3. Portfólio e projetos
4. Eles têm uma recomendação de alguém que já trabalha na empresa? (discutiremos networking em profundidade no capítulo 2)
5. 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.

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.

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:

1. HTML
2. CSS
3. JavaScript
4. Linux
5. Git
6. SQL
7. Node.js
8. 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.

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:

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:

1. Eu te conheço
2. Gosto de você
3. 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.

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.

É 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:

1. Hackathons
2. Contribuições para o código aberto
3. Criação de conteúdo focado em desenvolvedores
4. Subir na hierarquia trabalhando em empresas com um "nome conhecido"
5. Construir um portfólio de clientes freelance
6. 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.

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.

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.

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:

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

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:

1. Fazer uma avaliação de programação on-line de suas habilidades ou uma "triagem por telefone".
2. Se você passar, uma segunda entrevista técnica por telefone ou videochamada.
3. 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.

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:

1. 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.
2. 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.
3. 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:

1. É muito mais fácil conseguir um cliente freelance do que um emprego em tempo integral.
2. O trabalho freelance é menos arriscado, pois você pode fazê-lo sem deixar seu emprego atual.
3. 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."

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

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!!!

Escrito por: Adham El Banhawy

Desenvolvedores de back-end enfrentam desafios o tempo todo ao criar aplicações ou testar código. Por ser um desenvolvedor relativamente novo e que está recém se familiarizando com esses desafios, nunca me deparei com um desafio ou inconveniência com mais frequência — ou mais memorável — do que quando usei funções de callback.

Não vou me aprofundar muito nos detalhes das callbacks e seus prós e contras nem nas alternativas a elas, como promises e async/await. Para uma explicação mais detalhada, você pode conferir este artigo (em inglês) que as explica detalhadamente.

O inferno das callbacks

As callbacks são uma funcionalidade útil do JavaScript que permite realizar chamadas assíncronas. Elas são funções que geralmente são passadas como um segundo parâmetro para outra função que está buscando dados ou realizando uma operação de E/S que leva tempo para completar.

Um exemplo disso é ao tentar fazer uma chamada de API usando o módulo request ou ao se conectar a um banco de dados do MongoDB. Se ambas as chamadas dependerem uma da outra ou se a informação que você está buscando for o URL do MongoDB ao qual você precisa se conectar, o que você pode fazer?

Nesse caso, é preciso aninhar essas chamadas uma dentro da outra:

request.get(url, function(error, response, mongoUrl) {

  if(error) throw new Error("Erro ao buscar dados");

  MongoClient.connect(mongoUrl, function(error, client) {

    if(error) throw new Error("Erro de conexão com o MongoDB");

    console.log("Conectado com sucesso ao servidor");    
    const db = client.db("dbName");
    // Realizar alguma lógica da aplicação
    client.close();

  });

});

Certo... então, onde está o problema? Bem, por um lado, a legibilidade do código sofre com essa técnica.

Pode parecer aceitável no começo, quando a base de código é pequena, mas a escalabilidade disso não é das melhores, especialmente se você inserir mais camadas profundas nos callbacks aninhados.

Você acabará com muitos colchetes e chaves que confundirão você e outros desenvolvedores, não importando se o código está bem formatado ou não. Existe um site chamado callbackhell (em português, o "inferno das callbacks") que aborda essa questão específica.

Ouço alguns de vocês, incluindo meu eu passado ingênuo, me dizendo para envolver em uma função async e então await (em português, esperar) pela função de callback. Isso simplesmente não funciona.

Se houver qualquer bloco de código após a função que usa callbacks, aquele bloco de código será executado e NÃO esperará pela callback.

Aqui está o erro que cometi antes:

var request = require('request');

// ERRADO

async function(){

  let joke;
  let url = "https://api.chucknorris.io/jokes/random"

  await request.get(url, function(error, response, data) {

    if(error) throw new Error("Erro ao buscar dados");

    let content = JSON.parse(data);
    joke = content.value;

  });

  console.log(joke); // undefined

};

// Errado

async function(){

  let joke;
  let url = "https://api.chucknorris.io/jokes/random"

  request.get(url, await function(error, response, data) {

    if(error) throw new Error("Erro ao buscar dados");

    let content = JSON.parse(data);
    joke = content.value;

  });

  console.log(joke); // undefined

};

Alguns desenvolvedores mais experientes podem dizer "Basta usar uma biblioteca diferente que use promises para fazer a mesma coisa, como o axios, ou simplesmente usar o fetch". Claro, eu poderia fazer isso nesse cenário, mas é apenas fugir do problema.

Além disso, esse é apenas um exemplo. Às vezes, você pode estar preso a usar uma biblioteca que não suporta promises sem alternativas, como ao usar kits de desenvolvimento de software (SDKs) para se comunicar com plataformas como a Amazon Web Services (AWS), o Twitter ou o Facebook.

Às vezes, até mesmo usar um callback para fazer uma chamada muito simples com uma E/S rápida ou uma operação de CRUD está bem, já que nenhuma outra lógica depende de seus resultados. Você, no entanto, pode estar restrito pelo ambiente de execução, como em uma função Lambda (site em inglês) que mataria todos os processos uma vez que a thread principal terminasse, independentemente de qualquer chamada assíncrona que não tenha sido concluída.

Solução 1 (fácil): usar o módulo "util" do Node

A solução é surpreendentemente simples. Mesmo se você estiver um pouco desconfortável com a ideia de promises no JavaScript, você vai adorar como pode resolver esse problema usando-as.

Como apontado por Erop e Robin, as versões a partir da versão 8 do Node suportam transformar funções de callback em promises usando o módulo interno util.

const request = require('request');

const util = require('util');

const url = "https://api.chucknorris.io/jokes/random";

// Use o util para trasnformar em promise o método request

const getChuckNorrisFact = util.promisify(request);

// Use o novo método para chamar a API em um padrão moderno de then/catch

getChuckNorrisFact(url).then(data => {

   let content = JSON.parse(data.body);

   console.log('Piada: ', content.value);

}).catch(err => console.log('erro: ', err))

O código acima resolve o problema de maneira limpa usando o método util.promisify, disponível na biblioteca principal do Node.

Solução 2 (um pouco mais complicada): transformar a callback em uma promise

Às vezes, usar as bibliotecas request e util não é possível, seja por causa de um ambiente/código legado ou por realizar as requisições a partir do navegador do lado do client. Você precisaria encapsular uma promise em torno de sua função de callback.

Vamos pegar o exemplo do Chuck Norris acima e transformá-lo em uma promise.

var request = require('request');
let url = "https://api.chucknorris.io/jokes/random";

// Uma função que retorna uma promise para resolver os dados obtidos da API ou um erro
let getChuckNorrisFact = (url) => {
  return new Promise(
    (resolve, reject) => {
      request.get(url, function(error, response, data){
        if (error) reject(error);

let content = JSON.parse(data);
        let fact = content.value;
        resolve(fact);
      })
   }
 );
};

getChuckNorrisFact(url).then(
   fact => console.log(fact) // realmente exibe uma string
).catch(
   error => console.log(error)
);

No código acima, coloquei a função request baseada em callback dentro de uma promise que a envolve Promise((resolve, reject) => { //função de callback}). Isso nos permite chamar a função getChuckNorrisFact como uma promise com os métodos **.then()** e .catch(). Quando _getChuckNorrisFact_ é chamada, ela executa a requisição para a API e espera por uma declaração resolve() ou reject() para executar. Na função de callback, você simplesmente passa os dados recuperados para os métodos resolve ou reject.

Uma vez que os dados (nesse caso, um fato incrível sobre Chuck Norris) são obtidos e passados para o resolve, getChuckNorrisFact executa o método then(). Isso retornará o resultado que você pode utilizar dentro de uma função dentro do then() para realizar a lógica desejada — que, nesse caso, é exibir o fato no console.

Você pode ler mais sobre isso na documentação da web da MDN.

A compilação Just-in-Time é um método para melhorar o desempenho de programas interpretados. Durante a execução, o programa pode ser compilado em código nativo para melhorar seu desempenho. Ela também é conhecida como compilação dinâmica.

A compilação dinâmica tem algumas vantagens sobre a compilação estática. Ao executar aplicações em Java ou C#, o ambiente de execução pode analisar a aplicação enquanto ela está sendo executada. Isso permite que um código mais otimizado seja gerado. Se o comportamento da aplicação mudar enquanto ela está sendo executada, o ambiente de execução pode recompilar o código.

Algumas das desvantagens incluem atrasos na inicialização e a sobrecarga da compilação durante a execução. Para limitar a sobrecarga, muitos compiladores JIT (abreviação de Just-in-Time) apenas compilam os caminhos de código que são frequentemente usados.

Visão geral

Tradicionalmente, existem dois métodos para converter o código-fonte em uma forma que pode ser executada em uma plataforma. A compilação estática converte o código em uma linguagem para uma plataforma específica. Um interpretador executa diretamente o código-fonte.

A compilação JIT tenta usar os benefícios dos dois métodos. Enquanto o programa interpretado está sendo executado, o compilador JIT determina o código mais frequentemente usado e o compila para código de máquina. Dependendo do compilador, isso pode ser feito em um método ou em uma seção menor de código.

A compilação dinâmica foi descrita pela primeira vez em um artigo por J. McCarthy sobre LISP, em 1960.

Compilação Just-in-Time, JIT, ou Tradução Dinâmica, é a compilação que é feita durante a execução de um programa – ou seja, em tempo de execução, em vez de antes da execução. O que acontece é a tradução para código de máquina. As vantagens de uma JIT são devidas ao fato de que, como a compilação ocorre em tempo de execução, um compilador JIT tem acesso a informações de tempo de execução dinâmicas, possibilitando melhores otimizações (como a incorporação de funções).

É importante entender sobre a compilação JIT que ela compilará o bytecode em instruções de código de máquina da máquina em execução. Em outras palavras, o código de máquina resultante é otimizado para a arquitetura da CPU da máquina em execução.

Alguns exemplos de compiladores JIT são a JVM (Java Virtual Machine) no Java e o CLR (Common Language Runtime), em C#.

História

No começo, um compilador era responsável por converter uma linguagem de alto nível (definida como mais elevada que assembly) em código objeto (instruções de máquina), que então seria ligado (por um linker) a um executável.

Em determinado ponto da evolução das linguagens, os compiladores compilavam uma linguagem de alto nível em pseudocódigo, que seria então interpretado (por um interpretador) para executar seu programa. Isso eliminou o código objeto e executáveis, permitindo que essas linguagens fossem portáveis para diversos sistemas operacionais e plataformas de hardware. Pascal (que compilava para P-Code) foi uma das primeiras. Java e C# são exemplos mais recentes. Eventualmente, o termo P-Code foi substituído por bytecode, já que a maioria das pseudo-operações são de um byte de comprimento.

Um compilador Just-in-Time (JIT) é um recurso do interpretador de tempo de execução que, em vez de interpretar bytecode toda vez que um método é invocado, compilará o bytecode em instruções de código de máquina da máquina em execução e, em seguida, invocará esse código objeto. Idealmente, a eficiência de executar o código objeto superará a ineficiência de recompilar o programa toda vez que ele for executado.

Cenário típico

O código-fonte é completamente convertido em código de máquina.

Cenário do JIT

O código-fonte será convertido em uma estrutura semelhante a uma linguagem assembly – por exemplo, IL (linguagem intermediária) para C#, ou bytecode para Java].

O código intermediário é convertido em linguagem de máquina somente quando a aplicação precisa, ou seja, apenas os códigos necessários são convertidos em código de máquina.

Comparação JIT x não JIT

No JIT, nem todo o código é convertido em código de máquina; primeiro, uma parte do código que é necessária será convertida em código de máquina. Então, se um método ou funcionalidade chamado não estiver em máquina, será convertido em código de máquina, o que reduz o peso na CPU. Como o código de máquina será gerado em tempo de execução, o compilador JIT produzirá código de máquina otimizado para a arquitetura de CPU da máquina em execução.

Alguns exemplos de JIT são:

• Java: JVM (Java Virtual Machine)
• C#: CLR (Common Language Runtime)
• Android: DVM (Dalvik Virtual Machine) ou ART (Android RunTime) em versões mais recentes

A máquina virtual do Java (JVM) executa bytecode e mantém uma contagem de quantas vezes uma função é executada. Se essa contagem exceder um limite predefinido, o JIT compila o código em linguagem de máquina, que pode ser diretamente executada pelo processador (ao contrário do caso normal em que o javac compila o código em bytecode e então o Java, o interpretador, interpreta esse bytecode linha por linha, converte-o em código de máquina e executa).

Além disso, na próxima vez que essa função for calculada, o mesmo código compilado é executado novamente, ao contrário da interpretação normal, em que o código é interpretado novamente linha por linha. Isso torna a execução mais rápida.

Escrito por: Jackson Bates

O problema

Tudo o que você quer fazer é buscar algum JSON de um endpoint de API para o clima, algumas resenhas de livros ou algo similarmente simples.

A consulta fetch no seu front-end é suficientemente fácil, mas você tem que colar sua chave de API secreta bem ali no código do front-end para qualquer um encontrar com um mínimo de esforço!

Além disso, enviar suas chaves de API para o seu repositório do GitHub é um grande problema: um desenvolvedor colocou suas chaves da AWS no Github e COISAS RUINS aconteceram (texto em inglês).

"Por que isso é tão difícil?!" – Você, provavelmente há 15 minutos

A solução

Você deve usar um servidor de back-end para buscar os resultados da API para você e depois passá-los para o seu front-end.

O novo problema

Você está apenas tentando fazer uma demonstração de front-end para seu portfólio! Você ainda não aprendeu nada sobre tecnologias de back-end! Por que isso é tão difícil?

Demonstração

Encontrei esse problema com frequência suficiente para decidir parar de inventar truques bobos e implementar uma solução que funciona com código back-end mínimo.

Nessa demonstração, eu configuro um back-end que escuta por requisições POST e as envia para a API do GoodReads. Para usar isso, você precisa implementar seu próprio front-end que possa enviar a requisição POST apropriada para esse back-end. Seu front-end não se comunicará diretamente com o GoodReads. Portanto, nenhuma chave de API é exposta.

Você precisará

• Node (o teste foi feito com a versão v10.16.0 – versões posteriores não terão problemas, versões anteriores podem encontrar alguns)
• git
• Este repositório: https://github.com/JacksonBates/example-goodreads-api-relay

Comece

git clone https://github.com/JacksonBates/example-goodreads-api-relay.git

O README.md (em inglês) contém tudo o que você precisa saber, incluindo instalação e configuração.

Incluí os pontos principais aqui (traduzidos) para sua conveniência:

README.md

Instale as dependências:

npm i

Você precisa criar seu próprio arquivo .env para sua chave:

cp .env.example .env

Então, abra o novo arquivo .env e cole suas chaves no local correto.

Exemplo:

GOODREADS_API_KEY=AABBCCDDEEFF00112233445566778899

Agora execute o servidor:

node app.js

No navegador, navegue até localhost:3000 para confirmar que o servidor está funcionando. Você deve ver um simples Hello World!

O que vem a seguir?

Agora, leia o arquivo app.js cuidadosamente.

Comentei o código extensivamente para ajudá-lo a entender o que está acontecendo se você não viu muito sobre o node e o express antes.

// app.js

// Aqui, importamos os módulos necessários e definimos algumas variáveis iniciais
require("dotenv").config();
const express = require("express");
const fetch = require("node-fetch");
const convert = require("xml-js");
const rateLimit = require("express-rate-limit");
const app = express();
const port = 3000;

// Limitação de taxa – o Goodreads limita para 1/seg, então devemos fazer 
// isso também
// Ative se você estiver atrás de um proxy reverso (Heroku, Bluemix, AWS ELB, // Nginx etc)
// veja https://expressjs.com/en/guide/behind-proxies.html
// app.set('trust proxy', 1);

const limiter = rateLimit({
    windowMs: 1000, // 1 segundo
    max: 1, // limita cada IP a 1 requisição por windowMs
})

// Aplicar a todas as requisições
app.use(limiter)

// Rotas

// Rota de teste, visite localhost:3000 para confirmar se está funcionando
// deve mostrar 'Hello World!' no navegador
app.get("/", (req, res) => res.send("Hello World!"));

// Nossa rota do Goodreads!
app.get("/api/search", async (req, res) => {
    try {
        // Isso usa interpolação de strings para fazer nossa string de
        // consulta de busca
        // tira o parâmetro de consulta postado e o reformata para o
        // goodreads
        const searchString = `q=${req.query.q}`;

        // Usa o node-fetch para chamar a API do goodreads e lê a chave do
        // .env
        const response = await fetch(`https://www.goodreads.com/search/index.xml?key=${process.env.GOODREADS_API_KEY}&${searchString}`);
        //mais informações aqui https://www.goodreads.com/api/index#search.books
        const xml = await response.text();

        // A API do Goodreads retorna XML, então para usá-la facilmente no front-end, podemos
        // converter isso para JSON:
        const json = convert.xml2json(xml, { compact: true, spaces: 2 });

        // A API retorna coisas que não nos interessam, então podemos muito bem eliminar
        // tudo exceto os resultados:
        const results = JSON.parse(json).GoodreadsResponse.search.results;

        return res.json({
            success: true,
            results
        })
    } catch (err) {
        return res.status(500).json({
            success: false,
            message: err.message,
        })
    }
})

// Isso ativa nosso servidor e gera logs para usarmos.
// As declarações console.log que você usar no node para depuração 
// aparecerão no seu terminal, não no console do navegador!
app.listen(port, () => console.log(`Exemplo de aplicação escutando na porta ${port}!`));

Atualização: um grande agradecimento a Gouri Shankar Kumawat por contribuir com um PR que melhorou este código! Você pode segui-lo no Twitter ou no GitHub.

Use o Postman para testar a API.

Configure o Postman para GET e cole isso no URL: localhost:3000/api/search?q=hobbit

O Postman mostrará a resposta JSON abaixo.

Como usar isso no seu front-end?

Esta aplicação simples está escutando requisições POST em /api/search, então interaja com ela em sua aplicação de front-end da mesma forma que você fazia anteriormente com a API original.

Ela está configurada apenas para lidar com consultas de pesquisa – se você quiser usar outros endpoints/métodos da API do Goodreads, precisará pensar em como implementá-los por conta própria!

Hospedagem

Você não pode implantar seu front-end e ainda ter isso no localhost – obviamente você precisa implantar isso também.

Recomendo o Heroku (site em inglês).

Nota da tradução: no momento da tradução deste artigo, o Heroku não está mais disponibilizando um tier gratuito para uso. Aos que procuram uma alternativa gratuita, recomendamos a busca por outras fontes.

Bônus

Se você quiser expandir essa solução, pode considerar como torná-la acessível apenas a partir de um intervalo restrito de endereços IP para aumentar a segurança – o que estava fora do escopo deste tutorial/demonstração.

A solução foi montada rapidamente em resposta a uma discussão no fórum. Se você encontrar algum problema neste artigo ou no código de exemplo, não hesite em responder ao tópico do fórum (em inglês) que deu início a tudo. Manterei o artigo e o repositório atualizados com melhorias.

Sinta-se à vontade para enviar PRs se tiver contribuições valiosas a fazer. 😀

Você também pode entrar em contato com o autor via Twitter.

Escrito por: David Gilbertson

Pelos próximos minutos, quero que você esqueça o CSS, esqueça o desenvolvimento para a web e esqueça as interfaces digitais de usuário.

À medida que você esquece essas coisas, quero que permita sua mente vagar. Voltar no tempo. De volta à sua juventude. De volta ao seu primeiro dia de escola.

Era um tempo mais simples, quando tudo com o que você precisava se preocupar era com desenhar formas e manter sua incontinência sob controle.

Dê uma olhada nos pontos acima. Percebe como alguns deles estão agrupados e outros estão espalhados? O que eu quero que você faça é dividi-los em cinco grupos para mim, da maneira que achar melhor.

Vá em frente. Após verificar que ninguém está olhando, desenhe um círculo ao redor de cada um dos cinco grupos com seu dedinho infantil.

Você, provavelmente, chegou a algo semelhante ao que está abaixo, certo? Seja o que for que você fizer, não me diga que rolou a página sem fazer o exercício. 😒

Claro, aqueles dois pontos à direita poderiam ir para qualquer um dos lados. Se você os agrupou juntos, tudo bem, eu acho. Dizem que não há resposta errada, mas eu nunca estive errado, então nunca estive do lado receptor desse ditado específico.

Antes de continuar, você desenhou algo assim?

Provavelmente, não, certo?

É basicamente isso que você estaria fazendo se definisse seus breakpoints em posições correspondentes à largura exata dos dispositivos populares (320px, 768px, 1024px).

Já ouviu ou disse algo do tipo?

"O breakpoint médio vai até 768px, ou inclui 768? Entendi... e isso é o modo paisagem do iPad, ou 'grande'? Ah, grande é de 768px e acima. Entendi. E pequeno é 320px? O que é essa faixa de 0 a 319px? Um breakpoint para formigas?"

Eu poderia seguir em frente e mostrar os breakpoints corretos e deixar por isso mesmo, mas acho muito curioso que o método acima ("agrupamento bobo") seja tão disseminado.

Por que isso acontece?

Acho que a resposta para esse problema, como tantos outros problemas, se resume a terminologia desalinhada.

Acho que confundimos "limites" e "faixas" em nossas discussões e implementações de breakpoints.

Me diga, se você faz breakpoints no Sass, você tem uma variável chamada $large que é, digamos, 768px?

É o limite inferior da faixa que você chama de grande, ou o limite superior? Se for o inferior, então você não deve ter $small porque o valor deste deveria ser 0, certo?

Se for o limite superior, então como você definiria um breakpoint $extra-large? Deve ser uma consulta de mídia com um min-width de $medium, certo?

Se você estiver se referindo apenas a um limite quando diz grande, então teremos confusão mais tarde porque uma consulta de mídia é sempre uma faixa.

Essa situação é uma bagunça e estamos perdendo tempo pensando nisso. Então, tenho três sugestões:

1. Obtenha seus breakpoints corretamente
2. Nomeie suas faixas de maneira sensata
3. Seja declarativo

Dica nº 1: obtenha seus breakpoints corretamente

Então, quais são os breakpoints corretos?

Seu "eu" de jardim de infância já desenhou os círculos. Eu apenas os transformarei em retângulos para você.

Aqueles pontos com os quais seu "eu" jovem se divertiu representam na verdade os 14 tamanhos de tela mais comuns:

Então, podemos fazer uma imagem bonita que permita o fácil fluxo de palavras entre as pessoas vestidas como empresários, designers, desenvolvedores e testadores.

Dica nº 2: nomeie suas faixas de maneira sensata

Claro, você poderia nomear seus breakpoints de papai urso e bebê urso, se quiser. Se eu for me sentar com um designer, porém, e discutir como o site deve parecer em dispositivos diferentes, quero que seja o mais rápido possível. Se nomear um tamanho de tablet em retrato facilita isso, então ótimo. Aliás, até perdoaria você por chamar de "iPad em retrato".

O CSS do seu site, porém, tem uma vida útil de cerca de três anos (a menos que seja o Gmail). O iPad está conosco há o dobro desse tempo e ainda não foi destronado. Sabemos que a Apple não faz mais novos produtos, eles apenas removem coisas dos existentes (botões, buracos etc).

Então, o 1024 x 768 veio para ficar, pessoal. Vamos não enterrar nossas cabeças na areia. Fato curioso: avestruzes não vivem em cidades porque não há areia e, portanto, nenhum lugar para se esconder dos predadores.

Conclusão: a comunicação é importante. Não se desligue propositalmente de vocabulário útil.

Dica nº 3: seja declarativo

Eu sei, eu sei, essa palavra "declarativo" de novo. Vou colocar de outra maneira: seu CSS deve definir o que ele quer que aconteça, não como deve acontecer. O "como" deve ficar escondido em algum tipo de mixin.

Como discutido anteriormente, parte da confusão em torno dos breakpoints é que as variáveis que definem um limite de um intervalo são usadas como o nome do intervalo. $large: 600px simplesmente não faz sentido se large é um intervalo. É o mesmo que dizer var coordenadas = 4;.

Podemos esconder esses detalhes dentro de um mixin em vez de expô-los para serem usados no código. Podemos fazer melhor e não usar variáveis de todo.

No início, eu fiz o trecho abaixo como um exemplo simplificado. Eu realmente acho que cobre todos os aspectos. Para vê-lo em ação, veja este pen. Estou usando Sass porque não consigo imaginar construir um site sem ele. A lógica se aplica ao CSS ou Less da mesma maneira.

@mixin for-phone-only {
  @media (max-width: 599px) { @content; }
}
@mixin for-tablet-portrait-up {
  @media (min-width: 600px) { @content; }
}
@mixin for-tablet-landscape-up {
  @media (min-width: 900px) { @content; }
}
@mixin for-desktop-up {
  @media (min-width: 1200px) { @content; }
}
@mixin for-big-desktop-up {
  @media (min-width: 1800px) { @content; }
}

// uso
.my-box {
  padding: 10px;

  @include for-desktop-up {
    padding: 20px;
  }
}

A ambiguidade gera confusão.

Uma crítica óbvia pode ser que isso não lida com media queries personalizadas. Bem, boas notícias, pessoal. Se você quiser uma media query personalizada, escreva uma media query personalizada. Na prática, se eu precisasse de mais complexidade do que o acima, cortaria minhas perdas e correria para o abraço amoroso do kit de ferramentas Susy.

Outra crítica pode ser que eu tenho oito mixins aqui. Com certeza um único mixin seria a decisão mais sensata, para então passar o tamanho necessário, assim:

@mixin for-size($size) {
  @if $size == phone-only {
    @media (max-width: 599px) { @content; }
  } @else if $size == tablet-portrait-up {
    @media (min-width: 600px) { @content; }
  } @else if $size == tablet-landscape-up {
    @media (min-width: 900px) { @content; }
  } @else if $size == desktop-up {
    @media (min-width: 1200px) { @content; }
  } @else if $size == big-desktop-up {
    @media (min-width: 1800px) { @content; }
  }
}

// uso
.my-box {
  padding: 10px;

  @include for-size(desktop-up) {
    padding: 20px;
  }
}

Claro, funciona. Porém, você não terá erros em tempo de compilação se passar um nome não suportado. Passar uma variável sass significa expor 8 variáveis só para passar para um switch em um mixin.

Sem mencionar que a sintaxe @include for-desktop-up {...} é muito mais bonita do que @include for-size(desktop-up) {...}.

Uma crítica de ambos esses trechos de código pode ser que estou digitando 900px duas vezes, e também 899px. Certamente eu deveria apenas usar variáveis e subtrair 1 quando necessário.

Se você quiser fazer isso, sinta-se à vontade, mas há duas razões pelas quais eu não o faria:

1. Estas não são coisas que mudam frequentemente. Também não são números que são usados em outro lugar na base de código. Nenhum problema é causado pelo fato de que eles não são variáveis — a menos que você queira expor seus pontos de interrupção Sass para um script que injeta um objeto JS com essas variáveis na sua página.
2. A sintaxe é horrível quando você quer transformar números em strings com Sass. Abaixo está o preço que você paga por acreditar que repetir um número duas vezes é o pior de todos os males:

@mixin for-size($range) {
  $phone-upper-boundary: 600px;
  $tablet-portrait-upper-boundary: 900px;
  $tablet-landscape-upper-boundary: 1200px;
  $desktop-upper-boundary: 1800px;

  @if $range == phone-only {
    @media (max-width: #{$phone-upper-boundary - 1}) { @content; }
  } @else if $range == tablet-portrait-up {
    @media (min-width: $phone-upper-boundary) { @content; }
  } @else if $range == tablet-landscape-up {
    @media (min-width: $tablet-portrait-upper-boundary) { @content; }
  } @else if $range == desktop-up {
    @media (min-width: $tablet-landscape-upper-boundary) { @content; }
  } @else if $range == big-desktop-up {
    @media (min-width: $desktop-upper-boundary) { @content; }
  }
}

// uso
.my-box {
  padding: 10px;

  @include for-size(desktop-up) {
    padding: 20px;
  }
}

Ah, e já que adotei um tom de desabafo nos últimos parágrafos... eu sinto pena do tolo que faz algo mágico como armazenar breakpoints em uma lista do Sass e iterar sobre eles para gerar consultas de mídia, ou algo igualmente ridículo que futuros desenvolvedores terão dificuldade em decifrar.

Finalmente, você pode estar pensando "eu não deveria estar baseando meus pontos de interrupção no conteúdo, e não nos dispositivos?". Bem, estou maravilhado que você tenha chegado até aqui e a resposta é sim... para sites com um layout único. Ou se você tiver múltiplos layouts e estiver feliz em ter um conjunto diferente de breakpoints para cada layout. Ah, e também se o design do seu site não mudar com frequência, ou se você estiver feliz em atualizar seus breakpoints quando seus designs forem atualizados, já que você vai querer mantê-los baseados no conteúdo, certo?

Para sites complexos, a vida é muito mais fácil se você escolher alguns pontos de interrupção para usar em todo o site.

Terminamos! Este artigo não foi tão cheio de bichinhos quanto eu gostaria que fosse – deixe-me ver se consigo pensar em uma desculpa para incluir alguns...

Ah, já sei!

Dicas bônus para o desenvolvimento de breakpoints

1. Se você precisar experimentar com breakpoints de CSS para tamanhos de tela maiores do que o monitor que você está usando, utilize o modo 'responsivo' nas ferramentas de desenvolvedor do Chrome e digite qualquer tamanho gigante que você quiser.
2. A barra azul mostra media queries com "largura máxima" (max-width), a barra laranja mostra media queries com "largura mínima" (min-width), e a barra verde mostra media queries com tanto uma largura mínima quanto uma máxima.
3. Clicar em uma media query ajusta a largura da tela para aquela largura. Se você clicar em uma media query verde mais de uma vez, ela alterna entre as larguras máxima e mínima.
4. Clique com o botão direito em uma media query na barra de media queries para ir à definição dessa regra no CSS.

Ei, agradeço a leitura! Compartilhe o artigo, se acha que eu mereço, ou deixe ele no esquecimento, como ficará minha autoestima se você não o compartilhar. 😳

Escrito por: Reza Lavarian

É um pouco complicado explicar exatamente o que é um sistema de arquivos em apenas uma frase.

É por isso que decidi escrever um artigo sobre isso. Este artigo pretende ser uma visão geral de alto nível sobre sistemas de arquivos. Também examinarei alguns conceitos de mais baixo nível, desde que não fique entediante. 🙂

O que é um sistema de arquivos?

Vamos começar com uma definição simples:

Um sistema de arquivos define como os arquivos são nomeados, armazenados e recuperados em um dispositivo de armazenamento.

Toda vez que você abre um arquivo em seu computador ou dispositivo inteligente, seu sistema operacional usa seu sistema de arquivos internamente para carregá-lo do dispositivo de armazenamento.

Quando você copia, edita ou exclui um arquivo, é o sistema de arquivos que lida com isso nos bastidores.

Sempre que você faz o download de um arquivo ou acessa uma página da web na Internet, um sistema de arquivos está envolvido também.

Por exemplo, se você acessar uma página no freeCodeCamp, seu navegador envia uma solicitação HTTP (texto em inglês) ao servidor do freeCodeCamp para buscar a página. Se o recurso solicitado for um arquivo, ele é buscado de um sistema de arquivos.

Quando as pessoas falam em sistemas de arquivos, elas podem estar se referindo a diferentes aspectos de um sistema de arquivos dependendo do contexto – é aí que as coisas começam a parecer complicadas.

Você pode acabar se perguntando: O QUE É UM SISTEMA DE ARQUIVOS AFINAL? 🤯

Este guia ajudará você a entender sistemas de arquivos em muitos contextos. Também abordarei particionamento e inicialização!

Para manter este guia gerenciável, vou me concentrar em ambientes semelhantes ao Unix ao explicar os conceitos de baixo nível ou comandos de console.

No entanto, esses conceitos permanecem relevantes para outros ambientes e sistemas de arquivos.

Por que precisamos de um sistema de arquivos, afinal de contas?

Bem, sem um sistema de arquivos, o dispositivo de armazenamento conteria um grande bloco de dados armazenados consecutivamente. O sistema operacional não seria capaz de distingui-los.

O termo sistema de arquivos vem dos antigos sistemas de gerenciamento de dados baseados em papel, onde mantínhamos documentos como arquivos e os colocávamos em diretórios.

Imagine uma sala com pilhas de papéis espalhados por todo o lugar.

Um dispositivo de armazenamento sem um sistema de arquivos estaria na mesma situação – e seria um dispositivo eletrônico inútil.

No entanto, um sistema de arquivos muda tudo:

Um sistema de arquivos não é apenas uma função de contagem, no entanto.

Gerenciamento de espaço, metadados, criptografia de dados, controle de acesso a arquivos e integridade dos dados também são responsabilidades do sistema de arquivos.

Tudo começa com o particionamento

Os dispositivos de armazenamento devem ser particionados e formatados antes de serem usados pela primeira vez.

O que é particionamento?

Particionamento é a divisão de um dispositivo de armazenamento em várias regiões lógicas para que possam ser gerenciadas separadamente como se fossem dispositivos de armazenamento separados.

Geralmente, fazemos o particionamento com uma ferramenta de gerenciamento de disco fornecida pelos sistemas operacionais ou com uma ferramenta de linha de comando fornecida pelo firmware do sistema (explicarei o que é firmware mais tarde).

Um dispositivo de armazenamento deve ter, pelo menos, uma partição – ou mais de uma, se necessário.

Por que devemos dividir os dispositivos de armazenamento em várias partições, afinal?

A razão é que não queremos gerenciar todo o espaço de armazenamento como uma única unidade e para um único propósito.

É semelhante ao modo como particionamos nosso espaço de trabalho, para separar (e isolar) salas de reunião, salas de conferência e várias equipes.

Por exemplo, uma instalação básica do Linux tem três partições: uma partição dedicada ao sistema operacional, uma para os arquivos dos usuários e uma partição de swap opcional.

Uma partição de swap funciona como uma extensão da RAM quando a RAM fica sem espaço.

Por exemplo, o sistema operacional pode mover um trecho de dados (temporariamente) da RAM para a partição de swap para liberar algum espaço na RAM.

Os sistemas operacionais continuamente utilizam várias técnicas de gerenciamento de memória (texto em inglês) para garantir que cada processo tenha espaço de memória suficiente para funcionar.

Os sistemas de arquivos no Windows e do Mac têm um layout semelhante, mas não usam uma partição de swap dedicada; Em vez disso, eles gerenciam a troca dentro da partição onde você instalou seu sistema operacional.

Em um computador com várias partições, você pode instalar vários sistemas operacionais e, quando quiser, escolher um sistema operacional diferente para inicializar seu sistema.

As utilidades de recuperação e diagnóstico residem em partições dedicadas também.

Por exemplo, para inicializar um MacBook no modo de recuperação, você precisa segurar Command + R assim que reiniciar (ou ligar) seu MacBook. Fazendo isso, você instrui o firmware do sistema a inicializar com uma partição que contém o programa de recuperação.

O particionamento não é apenas uma maneira de instalar diversos sistemas operacionais e ferramentas, no entanto. Ele também nos ajuda a manter os arquivos críticos do sistema separados dos arquivos comuns.

De volta ao exemplo do escritório, ter um call center e uma equipe técnica em uma área comum prejudicaria a produtividade das duas equipes, pois cada equipe tem suas próprias necessidades para ser eficiente.

Por exemplo, a equipe técnica apreciaria um ambiente mais silencioso.

Alguns sistemas operacionais, como o Windows, atribuem uma letra de unidade (A, B, C ou D) às partições. Por exemplo, a partição primária no Windows (na qual o Windows está instalado) é conhecida como C:, ou unidade C.

Em sistemas operacionais semelhantes ao Unix, no entanto, as partições aparecem como diretórios comuns sob o diretório raiz – abordaremos isso mais tarde.

Na próxima seção, vamos nos aprofundar no particionamento e conhecer dois conceitos que mudarão sua perspectiva sobre sistemas de arquivos: firmware do sistema e boot.

Está pronto?

Vamos lá! 🏊‍♂️

Esquemas de particionamento, firmware de sistema e boot

Ao particionar um dispositivo de armazenamento, temos dois métodos de particionamento (ou esquemas 🙄) para escolher:

• Esquema Master Boot Record (MBR)
• Esquema GUID Partition Table (GPT)

Independentemente do esquema de particionamento que você escolher, os primeiros blocos no dispositivo de armazenamento sempre conterão dados críticos sobre suas partições.

O firmware do sistema usa essas estruturas de dados para inicializar o sistema operacional em uma partição.

Espere, mas o que é firmware do sistema, você pode perguntar.

Aqui está uma explicação:

Um firmware é um software de baixo nível embutido em dispositivos eletrônicos para operar o dispositivo ou iniciar outro programa para fazer isso.

O firmware existe em computadores, periféricos (teclados, mouses e impressoras) ou até mesmo em eletrodomésticos e eletrônicos.

Nos computadores, o firmware fornece uma interface padrão para um software complexo como o sistema operacional fazer a inicialização e trabalhar com os componentes de hardware.

No entanto, em sistemas mais simples como uma impressora, o firmware é o sistema operacional. O menu que você usa na sua impressora é a interface do firmware dela.

Os fabricantes de hardware fazem firmware com base em duas especificações:

• Basic Input/Output (BIOS)
• Unified Extensible Firmware Interface (UEFI)

Firmwares – baseados em BIOS ou UEFI – residem em uma memória não volátil, como uma ROM flash anexada à placa-mãe.

Quando você pressiona o botão de energia do seu computador, o firmware é o primeiro programa a ser executado.

A missão do firmware (entre outras coisas) é inicializar o computador, executar o sistema operacional e passar o controle do sistema inteiro para ele.

Um firmware também executa ambientes anteriores ao sistema operacional (com suporte de rede), como ferramentas de recuperação ou diagnósticas, ou até mesmo um shell para executar comandos baseados em texto.

As primeiras telas que você vê antes de o logotipo do Windows aparecer são a saída do firmware do seu computador, verificando a integridade dos componentes de hardware e da memória.

A verificação inicial é confirmada com um bip (geralmente, em PCs), indicando que está tudo certo para prosseguir.

Particionamento MBR e firmware baseado em BIOS

O esquema de particionamento MBR faz parte das especificações do BIOS e é usado por firmware baseado em BIOS.

Em discos particionados com MBR, o primeiro setor no dispositivo de armazenamento contém dados essenciais para inicializar o sistema.

Esse setor é chamado de MBR.

O MBR contém as seguintes informações:

• O carregador de boot (em português, inicialização), que é um programa simples (em código de máquina) para iniciar a primeira etapa do processo de boot
• Uma tabela de partição, que contém informações sobre suas partições.

O firmware baseado em BIOS inicializa o sistema de maneira diferente do firmware baseado em UEFI.

Veja como funciona:

Uma vez que o sistema é ligado, o firmware do BIOS começa e carrega o programa de carregamento de boot (contido no MBR) na memória. Uma vez que o programa está na memória, a CPU começa a executá-lo.

Ter o carregador de boot e a tabela de partição em um local predefinido como o MBR permite que o BIOS inicialize o sistema sem precisar lidar com qualquer arquivo.

Se você está curioso sobre como a CPU executa as instruções que residem na memória, você pode ler este guia amigável para iniciantes e divertido sobre como a CPU funciona (texto em inglês).

O código do carregador de boot no MBR ocupa entre 434 bytes a 446 bytes do espaço do MBR (de um total de 512b). Além disso, 64 bytes são alocados para a tabela de partição, que pode conter informações de até quatro partições.

446 bytes não é suficiente para acomodar muito código, no entanto. Dito isso, carregadores de boot sofisticados como o GRUB 2 no Linux dividem sua funcionalidade em partes ou etapas.

A menor parte do código, conhecida como carregador de boot de primeira etapa, é armazenada no MBR. É geralmente um programa simples, que não requer muito espaço.

A responsabilidade do carregador de boot de primeira etapa é iniciar as próximas etapas (mais complicadas) do processo de boot.

Imediatamente após o MBR e antes da primeira partição começar, há um pequeno espaço, cerca de 1MB, chamado de gap do MBR.

O gap do MBR pode ser usado para colocar outra parte do programa de carregamento de boot, se necessário.

O stage 1.5 permite que os próximos estágios do GRUB compreendam o conceito de arquivos, em vez de carregar instruções brutas do dispositivo de armazenamento (como o carregador de boot de primeiro estágio).

O carregador de boot de segundo estágio, que agora é capaz de trabalhar com arquivos, pode carregar o arquivo do carregador de boot do sistema operacional para inicializar o respectivo sistema operacional.

É quando o logotipo do sistema operacional aparece...

Aqui está o layout de um dispositivo de armazenamento com partição MBR:

VIsto por dentro, o conteúdo do MBR teria esta aparência:

Embora o MBR seja simples e amplamente suportado, ele tem algumas limitações 😑.

A estrutura de dados do MBR limita o número de partições a apenas quatro partições primárias.

Uma solução comum é fazer uma partição estendida ao lado das partições primárias, desde que o número total de partições não exceda quatro.

Uma partição estendida pode ser dividida em várias partições lógicas. Fazer partições estendidas é diferente em cada sistema operacional. Neste guia rápido, a Microsoft explica como deve ser feito no Windows (texto em inglês).

Ao fazer uma partição, você pode escolher entre primária e estendida.

Depois que isso é resolvido, encontramos a segunda limitação.

Cada partição pode ter no máximo 2TB 🙄.

Espere, tem mais!

O conteúdo do setor MBR não tem back-up 😱, o que significa que, se o MBR for corrompido por alguma razão inesperada, teremos que encontrar uma maneira de reciclar aquele pedaço inútil de hardware.

É aqui que o particionamento GPT se destaca 😎.

Particionamento GPT e firmware baseado em UEFI

O esquema de particionamento GPT é mais sofisticado que o MBR e não possui as limitações do MBR.

Por exemplo, você pode ter tantas partições quantas seu sistema operacional permitir.

Cada partição pode ter o tamanho do maior dispositivo de armazenamento disponível no mercado – na verdade, muito mais.

O GPT está gradualmente substituindo o MBR, embora o MBR ainda seja amplamente suportado em PCs antigos e novos.

Como mencionado anteriormente, o GPT é uma parte da especificação UEFI, que está substituindo o bom e velho BIOS.

Isso significa que o firmware baseado em UEFI usa um dispositivo de armazenamento particionado com GPT para manejar o processo de boot.

Muitos hardwares e sistemas operacionais agora suportam UEFI e usam o esquema GPT para particionar dispositivos de armazenamento.

No esquema de particionamento GPT, o primeiro setor do dispositivo de armazenamento é reservado por razões de compatibilidade com sistemas baseados em BIOS. O motivo é que alguns sistemas ainda podem usar um firmware baseado em BIOS, mas têm um dispositivo de armazenamento particionado com GPT.

Este setor é chamado de MBR protetivo (é aqui que o carregador de boot de primeiro estágio residiria em um disco particionado com MBR).

Depois desse primeiro setor, são armazenadas as estruturas de dados GPT, incluindo o cabeçalho GPT e as entradas de partição.

É feito o back-up das entradas GPT e o cabeçalho GPT no final do dispositivo de armazenamento, para que possam ser recuperados se a cópia principal for corrompida.

Esse back-up é chamado de GPT Secundário.

O layout de um dispositivo de armazenamento particionado com GPT se parece com isso:

No GPT, todos os serviços de boot (carregadores de boot, gerenciadores de boot, ambientes anteriores ao sistema operacional e shells) vivem em uma partição dedicada chamada partição de sistema EFI (ESP), que o firmware UEFI pode usar.

A ESP até tem seu próprio sistema de arquivos, que é uma versão específica do FAT. No Linux, a ESP reside no caminho /sys/firmware/efi.

Se esse caminho não puder ser encontrado em seu sistema, então seu firmware é provavelmente baseado em BIOS.

Para verificar, você pode tentar mudar o diretório para o ponto de montagem do ESP, assim:

cd /sys/firmware/efi

O firmware baseado em UEFI assume que o dispositivo de armazenamento está particionado com GPT e procura o ESP na tabela de partições GPT.

Uma vez encontrada a partição EFI, ele procura o carregador de boot configurado – geralmente, um arquivo com a terminação .efi.

O firmware baseado em UEFI obtém a configuração de boot de NVRAM (uma RAM não volátil).

A NVRAM contém as configurações de boot e os caminhos para os arquivos do carregador de boot do sistema operacional.

O firmware UEFI também pode fazer um boot no estilo BIOS (para inicializar o sistema a partir de um disco MBR) se configurado adequadamente.

Você pode usar o comando parted no Linux para ver qual esquema de particionamento é usado para um dispositivo de armazenamento.

sudo parted -l

A saída seria algo assim:

Model: Virtio Block Device (virtblk)
Disk /dev/vda: 172GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
14      1049kB  5243kB  4194kB                     bios_grub
15      5243kB  116MB   111MB   fat32              msftdata
 1      116MB   172GB   172GB   ext4

Com base na saída acima, o ID do dispositivo de armazenamento é /dev/vda com uma capacidade de 172GB. O dispositivo de armazenamento está particionado com base no GPT e possui três partições; a segunda e a terceira partições estão formatadas com base nos sistemas de arquivos FAT32 e EXT4, respectivamente.

Vamos confirmar isso com o comando dmidecode da seguinte maneira:

sudo dmidecode -t 0

A saída seria:

# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.4 present.

...

✅ Confirmado!

Formatando partições

Quando o particionamento é concluído, as partições devem ser formatadas.

A maioria dos sistemas operacionais permite que você formate uma partição com base em um conjunto de sistemas de arquivos.

Por exemplo, se você estiver formatando uma partição no Windows, você pode escolher entre os sistemas de arquivos FAT32, NTFS e exFAT.

A formatação envolve a criação de várias estruturas de dados e metadados usados para gerenciar arquivos dentro de uma partição.

Essas estruturas de dados são um aspecto de um sistema de arquivos.

Vamos usar o sistema de arquivos NTFS como exemplo.

Quando você formata uma partição para NTFS, o processo de formatação coloca as principais estruturas de dados do NTFS e a Tabela Mestra de Arquivos (MFT) na partição.

Certo, vamos voltar aos sistemas de arquivos com nosso novo entendimento sobre particionamento, formatação e boot.

Como começou, como está indo

Um sistema de arquivos é um conjunto de estruturas de dados, interfaces, abstrações e APIs que trabalham juntos para gerenciar qualquer tipo de arquivo em qualquer tipo de dispositivo de armazenamento, de maneira consistente.

Cada sistema operacional usa um sistema de arquivos particular para gerenciar os arquivos.

Nos primeiros dias, a Microsoft usava FAT (FAT12, FAT16 e FAT32) na família MS-DOS e Windows 9x.

A partir do Windows NT 3.1, a Microsoft desenvolveu o New Technology File System (NTFS), que possuía muitas vantagens sobre o FAT32, como suporte a arquivos maiores, permissão de nomes de arquivos mais longos, criptografia de dados, gerenciamento de acesso, journaling, e muito mais.

O NTFS tem sido o sistema de arquivos padrão da família Windows NT (2000, XP, Vista, 7, 10, etc.) desde então.

No entanto, NTFS não é adequado para ambientes que não sejam Windows 🤷🏻.

Por exemplo, você pode apenas ler o conteúdo de um dispositivo de armazenamento formatado em NTFS (como memória flash) em um Mac OS, mas você não poderá escrever nada nele – a menos que você instale um driver NTFS com suporte a gravação (texto em inglês).

Você pode simplesmente usar o sistema de arquivos exFat, em vez disso.

Extended File Allocation Table (exFAT) é uma versão mais leve do NTFS criada pela Microsoft em 2006.

O exFAT foi projetado para dispositivos removíveis de alta capacidade, como discos rígidos externos, pen drives e cartões de memória.

O exFAT é o sistema de arquivos padrão usado pelos cartões SDXC.

Diferentemente do NTFS, o exFAT possui suporte para leitura e gravação em ambientes que não sejam Windows também, incluindo Mac OS — tornando-o o melhor sistema de arquivos multiplataforma para dispositivos de armazenamento removíveis de alta capacidade.

Basicamente, se você tem um disco removível que deseja usar no Windows, Mac e Linux, você precisa formatá-lo para exFAT.

A Apple também desenvolveu e usou vários sistemas de arquivos ao longo dos anos, incluindo Hierarchical File System (HFS), HFS+ e, recentemente, Apple File System (APFS).

Assim como o NTFS, o APFS é um sistema de arquivos com journaling e tem sido usado desde o lançamento do OS X High Sierra em 2017.

O que ocorre, porém, com os sistemas de arquivos nas distribuições Linux?

A família de sistemas de arquivos Extended File System (ext) foi criada para o kernel do Linux – o núcleo do sistema operacional Linux.

A primeira versão do ext foi lançada em 1991, mas logo foi substituída pelo segundo sistema de arquivos estendido (ext2) em 1993.

Nos anos 2000, o terceiro sistema de arquivos estendido (ext3) e o quarto sistema de arquivos estendido (ext4) foram desenvolvidos para o Linux com capacidade de journaling.

O ext4 é agora o sistema de arquivos padrão em muitas distribuições Linux, incluindo Debian e Ubuntu.

Você pode usar o comando findmnt no Linux para listar suas partições formatadas em ext4:

findmnt -lo source,target,fstype,used -t ext4

A saída seria algo assim:

SOURCE    TARGET FSTYPE  USED
/dev/vda1 /      ext4    3.6G

Arquitetura de sistemas de arquivos

Um sistema de arquivos instalado em um sistema operacional consiste em três camadas:

• Sistema de arquivos físico
• Sistema de arquivos virtual
• Sistema de arquivos lógico

Essas camadas podem ser implementadas como abstrações independentes ou fortemente acopladas.

Quando as pessoas falam sobre sistemas de arquivos, elas se referem a uma dessas camadas ou a todas as três como uma unidade.

Embora essas camadas sejam diferentes entre os sistemas operacionais, o conceito é o mesmo.

A camada física é a implementação concreta de um sistema de arquivos. Ela é responsável pelo armazenamento e recuperação de dados e gerenciamento de espaço no dispositivo de armazenamento (ou mais precisamente: partições).

O sistema de arquivos físico interage com o hardware de armazenamento por meio de drivers de dispositivos (texto em inglês).

A próxima camada é o sistema de arquivos virtual ou VFS.

O sistema de arquivos virtual fornece uma visão consistente de vários sistemas de arquivos montados no mesmo sistema operacional.

Então, isso significa que um sistema operacional pode usar vários sistemas de arquivos ao mesmo tempo?

A resposta é: sim!

É comum que um meio de armazenamento removível tenha um sistema de arquivos diferente do computador.

Por exemplo, no Windows (que usa NTFS como sistema de arquivos principal), uma memória flash pode ter sido formatada para exFAT ou FAT32.

Dito isso, o sistema operacional deve fornecer uma interface unificada entre programas de computador (exploradores de arquivos e outros aplicativos que trabalham com arquivos) e os diferentes sistemas de arquivos montados (como NTFS, APFS, ext4, FAT32, exFAT e UDF).

Esta camada conveniente entre o usuário (você) e os sistemas de arquivos subjacentes é fornecida pelo VFS.

Um VFS define um contrato que todos os sistemas de arquivos físicos devem implementar para serem suportados por esse sistema operacional.

No entanto, essa conformidade não está embutida no núcleo do sistema de arquivos, o que significa que o código-fonte de um sistema de arquivos não inclui suporte para o VFS de todos os sistemas operacionais.

Em vez disso, ele usa um driver de sistema de arquivos para aderir às regras do VFS de cada sistema de arquivos. Um driver é um programa que permite que um software se comunique com outro software ou hardware.

Embora o VFS seja responsável por fornecer uma interface padrão entre programas e diversos sistemas de arquivos, programas de computador não interagem diretamente com o VFS.

Em vez disso, eles usam uma API unificada entre programas e o VFS.

Consegue adivinhar o que é?

Sim, estamos falando do sistema de arquivos lógico.

O sistema de arquivos lógico é a parte visível ao usuário de um sistema de arquivos, que fornece uma API para permitir que programas de usuários realizem várias operações de arquivos, como OPEN, READ e WRITE, sem precisar lidar com nenhum hardware de armazenamento.

Por outro lado, o VFS fornece uma ponte entre a camada lógica (com a qual os programas interagem) e um conjunto da camada física de vários sistemas de arquivos.

O que significa montar um sistema de arquivos?

Em sistemas do tipo Unix, o VFS atribui um ID do dispositivo (por exemplo, dev/disk1s1) a cada partição ou dispositivo de armazenamento removível.

Depois, ele cria uma árvore de diretórios virtual e coloca o conteúdo de cada dispositivo nessa árvore de diretórios como diretórios separados.

O ato de atribuir um diretório a um dispositivo de armazenamento (sob a árvore de diretórios raiz) é chamado de montagem. O diretório atribuído é chamado de ponto de montagem.

Dito isso, em um sistema operacional semelhante ao Unix, todas as partições e dispositivos de armazenamento removíveis aparecem como se fossem diretórios sob o diretório raiz.

Por exemplo, no Linux, os pontos de montagem para um dispositivo removível (como um cartão de memória), geralmente estão sob o diretório /media.

Uma vez que uma memória flash é conectada ao sistema e, consequentemente, montada automaticamente no ponto de montagem padrão (/media, nesse caso), seu conteúdo estaria disponível sob o diretório /media.

No entanto, há momentos em que você precisa montar um sistema de arquivos manualmente.

No Linux, isso é feito assim:

mount /dev/disk1s1 /media/usb

No comando acima, o primeiro parâmetro é o ID do dispositivo (/dev/disk1s1), e o segundo parâmetro (/media/usb) é o ponto de montagem.

Observe que o ponto de montagem já deve existir como um diretório.

Se não existir, ele deve ser criado primeiro:

mkdir -p /media/usb
mount /dev/disk1s1 /media/usb

Se o diretório do ponto de montagem já contiver arquivos, esses arquivos serão ocultados enquanto o dispositivo estiver montado.

Metadados de arquivos

Metadados de arquivo são uma estrutura de dados que contém dados sobre um arquivo, como:

• Tamanho do arquivo
• Timestamps, como data de criação, última data de acesso e data de modificação
• O proprietário do arquivo
• O modo do arquivo (quem pode fazer o que com o arquivo)
• Que blocos na partição estão alocados ao arquivo
• e muito mais

No entanto, os metadados não são armazenados com o conteúdo do arquivo. Em vez disso, eles são armazenados em um local diferente no disco – mas associados ao arquivo.

Em sistemas do tipo Unix, os metadados estão na forma de estruturas de dados, chamadas de inode.

Inodes são identificados por um número único chamado número de inode.

Inodes estão associados a arquivos em uma tabela chamada tabelas de inodes.

Cada arquivo no dispositivo de armazenamento tem um inode, que contém informações sobre ele, como a hora em que foi criado, modificado etc.

O inode também inclui o endereço dos blocos alocados ao arquivo; por outro lado, onde exatamente ele está localizado no dispositivo de armazenamento.

Em um inode ext4, o endereço dos blocos alocados é armazenado como um conjunto de estruturas de dados chamadas extents (dentro do inode).

Cada extent contém o endereço do primeiro bloco de dados alocado ao arquivo e o número de blocos contínuos que o arquivo ocupou.

Sempre que você abre um arquivo no Linux, seu nome é primeiro resolvido para um número de inode.

Com o número de inode, o sistema de arquivos busca o respectivo inode na tabela de inodes.

Uma vez que o inode é buscado, o sistema de arquivos começa a compor o arquivo dos blocos de dados registrados no inode.

Você pode usar o comando df com o parâmetro -i no Linux para ver os inodes (total, usados e livres) em suas partições:

df -i

A saída seria assim:

udev           4116100    378 4115722    1% /dev
tmpfs          4118422    528 4117894    1% /run
/dev/vda1      6451200 175101 6276099    3% /

Como você pode ver, a partição /dev/vda1 tem um número total de 6.451.200 inodes, dos quais 3% foram usados (175.101 inodes).

Para ver os inodes associados aos arquivos em um diretório, você pode usar o comando ls com os parâmetros -il.

ls -li

A saída seria:

1303834 -rw-r--r--  1 root www-data  2502 Jul  8  2019 wp-links-opml.php
1303835 -rw-r--r--  1 root www-data  3306 Jul  8  2019 wp-load.php
1303836 -rw-r--r--  1 root www-data 39551 Jul  8  2019 wp-login.php
1303837 -rw-r--r--  1 root www-data  8403 Jul  8  2019 wp-mail.php
1303838 -rw-r--r--  1 root www-data 18962 Jul  8  2019 wp-settings.php

O número de inodes em uma partição é decidido quando você formata uma partição. Dito isso, enquanto você tiver espaço livre e inodes não utilizados, você pode armazenar arquivos no seu dispositivo de armazenamento.

É improvável que um sistema operacional Linux pessoal fique sem inodes. No entanto, serviços empresariais que lidam com um grande número de arquivos (como servidores de e-mail) precisam gerenciar sua cota de inodes de maneira inteligente.

No NTFS, os metadados são armazenados de maneira diferente.

O NTFS mantém informações de arquivos em uma estrutura de dados chamada Tabela Mestra de Arquivos (MFT) (texto em inglês).

Cada arquivo tem, pelo menos, uma entrada na MFT, que contém tudo sobre ele, incluindo sua localização no dispositivo de armazenamento – semelhante à tabela de inodes.

Na maioria dos sistemas operacionais, você pode obter metadados através da interface gráfica do usuário.

Por exemplo, ao clicar com o botão direito do mouse em um arquivo no Mac OS e selecionar Obter Informações (Propriedades, no Windows), uma janela aparece com informações sobre o arquivo. Essas informações são obtidas dos metadados respectivos do arquivo.

Gerenciamento de espaço

Dispositivos de armazenamento são divididos em blocos de tamanho fixo chamados setores.

Um setor é a unidade mínima de armazenamento em um dispositivo de armazenamento e varia entre 512 bytes e 4096 bytes (formatação avançada).

No entanto, sistemas de arquivos usam um conceito de alto nível como unidade de armazenamento, chamados blocos.

Blocos são uma abstração sobre setores físicos; cada bloco geralmente consiste em diversos setores.

Dependendo do tamanho do arquivo, o sistema de arquivos aloca um ou mais blocos para cada arquivo.

Falando sobre gerenciamento de espaço, o sistema de arquivos está ciente de todos os blocos usados e não usados nas partições, para que ele possa alocar espaço para novos arquivos ou buscar os existentes quando solicitado.

A unidade de armazenamento mais básica em partições formatadas em ext4 é o bloco. No entanto, os blocos contíguos são agrupados em grupos de blocos para facilitar a gestão.

Cada grupo de blocos tem suas próprias estruturas de dados e blocos de dados.

Aqui estão as estruturas de dados que um grupo de blocos pode conter:

• Superbloco: um repositório de metadados, que contém metadados sobre todo o sistema de arquivos, como o número total de blocos no sistema de arquivos, total de blocos em grupos de blocos, inodes e mais. Nem todos os grupos de blocos contêm o superbloco, no entanto. Um certo número de grupos de blocos armazena uma cópia do superbloco como back-up.
• Descritores de grupo: os descritores de grupo também contêm informações contábeis para cada grupo de blocos.
• Bitmap de inodes: cada grupo de blocos tem sua própria cota de inodes para armazenar arquivos. Um bitmap de blocos é uma estrutura de dados usada para identificar inodes usados e não usados dentro do grupo de blocos. 1 denota objetos de inode usados e 0 denota objetos de inode não usados.
• Bitmap de blocos: uma estrutura de dados usada para identificar blocos de dados usados e não usados dentro do grupo de blocos. 1 denota blocos de dados usados e 0 denota blocos de dados não usados.
• Tabela de inodes: uma estrutura de dados que define a relação de arquivos e seus inodes. O número de inodes armazenados nesta área está relacionado ao tamanho do bloco usado pelo sistema de arquivos.
• Blocos de dados: esta é a zona dentro do grupo de blocos onde os conteúdos dos arquivos são armazenados.

O sistema de arquivos ext4 dá um passo adiante (comparado ao ext3) e organiza grupos de blocos em um grupo maior chamado grupos de blocos flex.

As estruturas de dados de cada grupo de blocos, incluindo o bitmap de blocos, bitmap de inodes e tabela de inodes, são concatenadas e armazenadas no primeiro grupo de blocos dentro de cada grupo de blocos flex.

Ter todas as estruturas de dados concatenadas em um grupo de blocos (o primeiro) libera mais blocos de dados contíguos nos outros grupos de blocos dentro de cada grupo de blocos flex.

Esses conceitos podem ser confusos, mas você não precisa dominar cada detalhe. Isso é só para ilustrar a profundidade dos sistemas de arquivos.

A disposição do primeiro grupo de blocos é assim:

Quando um arquivo está sendo escrito em um disco, ele é escrito em um ou mais blocos dentro de um grupo de blocos.

Gerenciar arquivos no nível do grupo de blocos melhora significativamente o desempenho do sistema de arquivos, em oposição a organizar arquivos como uma única unidade.

Tamanho x tamanho no disco

Você já notou que seu explorador de arquivos exibe dois tamanhos diferentes para cada arquivo: tamanho e tamanho no disco?

Por que tamanho e tamanho no disco são ligeiramente diferentes, você pode perguntar?

Aqui está uma explicação:

Já sabemos que, dependendo do tamanho do arquivo, um ou mais blocos são alocados para um arquivo.

Um bloco é o espaço mínimo que pode ser alocado para um arquivo. Isso significa que o espaço restante de um bloco parcialmente preenchido não pode ser usado por outro arquivo. Esta é a regra!

Como o tamanho do arquivo não é um múltiplo inteiro de blocos, o último bloco pode estar parcialmente usado, e o espaço restante permaneceria não utilizado – ou seria preenchido com zeros.

Assim, "tamanho" é basicamente o tamanho real do arquivo, enquanto "tamanho no disco" é o espaço que ele ocupa, mesmo que não esteja usando tudo.

du -b "some-file.txt"

A saída seria algo assim:

623 icon-link.svg

Para verificar o tamanho no disco, use:

du -B 1 "icon-link.svg"

Isso resultará em:

4096    icon-link.svg

Com base na saída, o bloco alocado é de cerca de 4kb, enquanto o tamanho real do arquivo é de 623 bytes. Isso significa que cada bloco de tamanho neste sistema operacional é de 4kb.

O que é fragmentação de disco?

Com o tempo, novos arquivos são gravados no disco, arquivos existentes aumentam, diminuem ou são deletados.

Essas mudanças frequentes no meio de armazenamento deixam muitos pequenos espaços vazios (lacunas) entre os arquivos. Essas lacunas ocorrem pelo mesmo motivo pelo qual o tamanho do arquivo e o tamanho do arquivo no disco são diferentes. Alguns arquivos não preencherão o bloco inteiro, e muito espaço será desperdiçado. Com o tempo, não haverá blocos consequentes suficientes para armazenar novos arquivos.

É então que novos arquivos precisam ser armazenados como fragmentos.

A fragmentação de arquivos ocorre quando um arquivo é armazenado como fragmentos no dispositivo de armazenamento porque o sistema de arquivos não consegue encontrar blocos contíguos suficientes para armazenar o arquivo inteiro em uma sequência.

Vamos deixar mais claro com um exemplo.

Imagine que você tem um documento do Word chamado meuarquivo.docx.

meuarquivo.docx é inicialmente armazenado em alguns blocos contíguos no disco. Vamos dizer que é assim que os blocos são nomeados: LBA250, LBA251 e LBA252.

Agora, se você adicionar mais conteúdo a meuarquivo.docx e salvá-lo, ele precisará ocupar mais blocos no meio de armazenamento.

Como meuarquivo.docx está atualmente armazenado em LBA250, LBA251 e LBA252, o novo conteúdo deveria, de preferência, ficar dentro de LBA253 e assim por diante - dependendo de quantos mais blocos são necessários para acomodar as novas mudanças.

Agora, imagine que LBA253 já esteja ocupado por outro arquivo (talvez seja o primeiro bloco de outro arquivo). Nesse caso, o novo conteúdo de meuarquivo.docx precisa ser armazenado em blocos diferentes em outro lugar no disco, por exemplo, LBA312 e LBA313.

meuarquivo.docx ficou fragmentado 💔.

A fragmentação de arquivo coloca uma sobrecarga no sistema de arquivos, pois, toda vez que um arquivo fragmentado é solicitado por um programa de usuário, o sistema de arquivos precisa coletar cada pedaço do arquivo de várias localizações no disco.

Essa sobrecarga também se aplica ao salvar o arquivo de volta no disco.

A fragmentação também pode ocorrer quando um arquivo é gravado no disco pela primeira vez, provavelmente porque o arquivo é grande e não há muitos blocos contínuos deixados na partição.

A fragmentação é uma das razões pelas quais alguns sistemas operacionais ficam lentos à medida que o sistema de arquivos envelhece.

Devemos nos preocupar com a fragmentação atualmente?

A resposta curta é: não mais!

Os sistemas de arquivos modernos usam algoritmos inteligentes para evitar (ou detectar precocemente) a fragmentação tanto quanto possível.

O Ext4 também faz uma espécie de pré-alocação, que envolve reservar blocos para um arquivo antes que eles sejam realmente necessários – garantindo que o arquivo não seja fragmentado se crescer ao longo do tempo.

O número de blocos pré-alocados é definido no campo de comprimento da extensão do arquivo de seu objeto inode.

Além disso, o Ext4 usa uma técnica de alocação chamada alocação atrasada.

A ideia é que, ao invés de gravar nos blocos de dados um de cada vez durante uma gravação, as solicitações de alocação são acumuladas em um buffer e são gravadas no disco de uma vez só.

Não precisar chamar o alocador de blocos do sistema de arquivos em cada solicitação de gravação ajuda o sistema de arquivos a fazer melhores escolhas ao distribuir o espaço disponível. Por exemplo, ao colocar arquivos grandes afastados dos arquivos menores.

Imagine que um arquivo pequeno esteja localizado entre dois arquivos grandes. Agora, se o arquivo pequeno for excluído, ele deixa um pequeno espaço entre os dois arquivos.

Distribuir os arquivos dessa maneira deixa lacunas suficientes entre os blocos de dados, o que ajuda o sistema de arquivos a gerenciar (e evitar) a fragmentação mais facilmente.

A alocação atrasada reduz ativamente a fragmentação e aumenta o desempenho.

Diretórios

Um diretório (ou pasta, no Windows) é um arquivo especial usado como um contêiner lógico para agrupar arquivos e diretórios dentro de um sistema de arquivos.

No NTFS e no Ext4, diretórios e arquivos são tratados da mesma maneira. Dito isso, diretórios são apenas arquivos que têm seu próprio inode (no Ext4) ou entrada MFT (no NTFS).

O inode ou entrada MFT de um diretório contém informações sobre esse diretório, bem como uma coleção de entradas apontando para os arquivos "sob" esse diretório.

Os arquivos não estão literalmente contidos dentro do diretório, mas estão associados ao diretório de tal maneira que aparecem como filhos do diretório em um nível superior, como em um programa de explorador de arquivos.

Essas entradas são chamadas de entradas de diretório. As entradas de diretório contêm nomes de arquivos mapeados para suas entradas inode/MFT.

Além das entradas de diretório, há mais duas entradas, a entrada ., que aponta para o próprio diretório, e a entrada .., que aponta para o diretório pai deste diretório.

No Linux, você pode usar o comando ls em um diretório para ver as entradas do diretório com seus números de inode associados:

ls -lai

63756 drwxr-xr-x 14 root root   4096 Dec  1 17:24 .
     2 drwxr-xr-x 19 root root   4096 Dec  1 17:06 ..
 81132 drwxr-xr-x  2 root root   4096 Feb 18 06:25 backups
 81020 drwxr-xr-x 14 root root   4096 Dec  2 07:01 cache
 81146 drwxrwxrwt  2 root root   4096 Oct 16 21:43 crash
 80913 drwxr-xr-x 46 root root   4096 Dec  1 22:14 lib

 ...

Regras para nomeação de arquivos

Alguns sistemas de arquivos impõem limitações sobre nomes de arquivos.

A limitação pode estar no comprimento do nome do arquivo ou na sensibilidade de maiúsculas e minúsculas no nome do arquivo.

Por exemplo, em sistemas de arquivos NTFS (Windows) e APFS (Mac), MeuArquivo e meuarquivo referem-se ao mesmo arquivo, enquanto no ext4 (Linux), eles apontam para arquivos diferentes.

Por que isso importa, você pode perguntar.

Imagine que você está criando uma página da web em seu computador com Windows. A página da web contém o logotipo da sua empresa, que é um arquivo PNG, assim:

<!DOCTYPE html>
<html>
    <head>
        <title>Produtos - Seu Site</title>
    </head>
    <body>
        <!--ALGUM CONTEÚDO-->
        <img src="img/logo.png">
        <!--MAIS CONTEÚDO-->
    </body>
</html>

Se o nome real do arquivo for Logo.png (note o L maiúsculo), você ainda pode ver a imagem quando abre sua página da web no navegador (em seu computador com Windows).

No entanto, uma vez que você o implante em um servidor Linux e visualize-o ao vivo, verá uma imagem quebrada.

Por quê?

Porque no Linux (sistema de arquivos ext4) logo.png e Logo.png apontam para dois arquivos diferentes.

Portanto, lembre-se disso ao desenvolver no Windows e implantar em um servidor Linux.

Regras para tamanho de arquivo

Um aspecto importante dos sistemas de arquivos é o tamanho máximo de arquivo que eles suportam.

Um sistema de arquivos antigo como o FAT32 (usado pelo MS-DOS +7.1, família Windows 9x e memórias flash) não pode armazenar arquivos maiores que 4 GB, enquanto seu sucessor, o NTFS permite tamanhos de arquivo de até 16 EB (1000 TB).

Como o NTFS, o exFAT também permite um tamanho de arquivo de 16 EB. Isso torna o exFAT uma opção ideal para armazenar objetos de dados massivos, como arquivos de vídeo.

Praticamente, não há limitação no tamanho do arquivo nos sistemas de arquivos exFAT e NTFS.

O ext4 do Linux e o APFS da Apple suportam arquivos de até 16 TiB e 8 EiB respectivamente.

Programas gerenciadores de arquivos

Como você sabe, a camada lógica do sistema de arquivos fornece uma API para permitir que aplicações do usuário realizem operações de arquivo, como operações de leitura, escrita, exclusão e execução.

A API do sistema de arquivos é um mecanismo de baixo nível, projetado para programas de computador, ambientes de tempo de execução e shells – ela não é projetada para uso diário.

Dito isso, os sistemas operacionais fornecem utilitários convenientes de gerenciamento de arquivos prontos para o uso diário de gerenciamento de arquivos.

Por exemplo, o Explorador de Arquivos no Windows, o Finder no Mac OS e o Nautilus no Ubuntu são exemplos de programas gerenciadores de arquivos.

Esses utilitários usam a API do sistema de arquivos lógico por trás dos panos.

Além dessas ferramentas GUI, os sistemas operacionais também expõem as APIs do sistema de arquivos através das interfaces de linha de comando, como Prompt de Comando no Windows e Terminal no Mac e Linux.

Essas interfaces baseadas em texto ajudam os usuários a realizar todos os tipos de operações de arquivo como comandos de texto – como fizemos nos exemplos anteriores.

Gerenciamento de acesso a arquivos

Nem todos devem ser capazes de remover ou modificar um arquivo que não possuem ou não estão autorizados a fazê-lo.

Sistemas de arquivos modernos fornecem mecanismos para controlar o acesso e as capacidades dos usuários em relação aos arquivos.

Os dados relativos às permissões do usuário e à propriedade dos arquivos são armazenados em uma estrutura de dados chamada Lista de Controle de Acesso (ACL) no Windows ou Entradas de Controle de Acesso (ACE) em sistemas operacionais do tipo Unix (Linux e Mac OS).

Esse recurso também está disponível na CLI (Prompt de comando ou Terminal), onde um usuário pode alterar a propriedade dos arquivos ou limitar as permissões de cada arquivo diretamente na interface de linha de comando.

Por exemplo, um proprietário de arquivo (no Linux ou Mac) pode configurar um arquivo para estar disponível ao público, assim:

chmod 777 meuarquivo.txt

777 significa que todos podem realizar todas as operações (leitura, escrita, execução) em meuarquivo.txt. Note que este é apenas um exemplo. Você não deve definir a permissão de um arquivo para 777.

Mantendo a integridade dos dados

Digamos que você esteja trabalhando em sua tese há um mês. Um dia, você abre o arquivo, faz algumas alterações e o salva.

Depois de salvar o arquivo, seu programa de processador de texto envia uma solicitação de "escrita" para a API do sistema de arquivos (o sistema de arquivos lógico).

A solicitação acaba sendo passada para a camada física para armazenar o arquivo em vários blocos.

O que acontece, porém, se o sistema travar enquanto a versão anterior do arquivo está sendo substituída pela nova versão?

Em sistemas de arquivos mais antigos (como FAT32 ou ext2), os dados seriam corrompidos porque foram parcialmente escritos no disco.

Isso é menos provável de acontecer com sistemas de arquivos modernos, pois eles usam uma técnica chamada journaling.

Os sistemas de arquivos com journaling registram cada operação que está prestes a acontecer na camada física, mas que ainda não aconteceu.

O objetivo principal é manter o controle das alterações que ainda não foram comprometidas fisicamente com o sistema de arquivos.

O journal é uma alocação especial no disco onde cada tentativa de escrita é primeiro armazenada como uma transação.

Em caso de falha do sistema, o sistema de arquivos detectará a transação incompleta e a cancelará como se nunca tivesse acontecido.

Dito isso, o novo conteúdo (que estava sendo escrito) ainda pode ser perdido, mas os dados existentes permaneceriam intactos.

Sistemas de arquivos modernos, como NTFS, APFS e ext4 (até mesmo o ext3), usam journaling para evitar dados corrompidos em caso de falha do sistema.

Sistemas de arquivos de banco de dados

Sistemas de arquivos típicos organizam arquivos como árvores de diretórios.

Para acessar um arquivo, você navega até o respectivo diretório e pronto.

cd /music/country/highwayman

No entanto, em um sistema de arquivos de banco de dados, não há conceito de caminhos e diretórios.

O sistema de arquivos de banco de dados é um sistema facetado que agrupa arquivos com base em vários atributos e dimensões.

Por exemplo, arquivos MP3 podem ser listados por artista, gênero, ano de lançamento e álbum – ao mesmo tempo!

Um sistema de arquivos de banco de dados é mais como uma aplicação de alto nível para ajudá-lo a organizar e acessar seus arquivos de maneira mais fácil e eficiente. No entanto, você não poderá acessar os arquivos brutos fora dessa aplicação.

Um sistema de arquivos de banco de dados não pode substituir um sistema de arquivos típico, no entanto. É apenas uma abstração de alto nível para facilitar a gestão de arquivos em alguns sistemas.

O aplicativo iTunes no Mac OS é um bom exemplo de um sistema de arquivos de banco de dados.

Concluindo

Uau! Você chegou até o fim do artigo – o que significa que agora sabe muito mais sobre sistemas de arquivos. Tenho certeza, porém, de que este não será o fim de seus estudos sobre sistemas de arquivos.

Então, mais uma vez – podemos descrever o que é um sistema de arquivos e como ele funciona em uma frase?

Não podemos! 😁

Vamos terminar este artigo, contudo, com a descrição breve que usei no começo:

Um sistema de arquivos define como arquivos são nomeados, armazenados e recuperados do dispositivo de armazenamento.

Certo, acho que isso encerra este artigo.

Se você gosta de guias mais abrangentes como este, visite o site do autor, decodingweb. dev e siga o autor no Twitter porque, além do freeCodeCamp, esses são os canais que o autor usa para compartilhar suas descobertas diárias.

Agradecemos a leitura! Aproveite o aprendizado! 😃

Escrito por: Joel Olawanle

Usamos props para passar informações/dados de um componente pai para componentes filhos. Neste artigo, vou explicar tudo o que você precisa saber sobre props e por que você deve usar props no Vue.js.

Aqui está um breve resumo do que vamos cobrir neste guia:

• O que são props no Vue.js?
• Como registrar props dentro de um componente
• Como trabalhar com várias props
• Tipos de props no Vue.js
• Como passar dados para props
• Como passar funções para props
• Como validar props
• Como definir valores padrão para props

O que são as props no Vue.js?

"Props" é uma palavra-chave especial que significa propriedades. Elas podem ser registradas em um componente para passar dados de um componente pai para um de seus componentes filhos.

É muito mais fácil de usar em comparação com as bibliotecas de gerenciamento de estado, como o vuex, para aplicações do Vue.js.

Os dados em props só podem fluir em um sentido – de cima, ou do componente pai, para baixo, ou para os componentes filhos. Isso simplesmente significa que você não pode passar dados de um filho para um pai.

Outra coisa a se ter em mente é que props são apenas para leitura e não podem ser modificadas pelo componente filho porque é o componente pai quem "possui" esse valor.

Vamos equilibrar as coisas agora – os componentes pais passam props para os componentes filhos enquanto os componentes filhos emitem eventos para os componentes pais.

Como registrar props em um componente

Vamos agora dar uma olhada em como podemos registrar props dentro de um componente.

Vue.component('user-detail', {
  props: ['name'],
  template: '<p>Hi {{ name }}</p>'
})
.js

ou, em um componente de arquivo único do Vue:

<template>
  <p>{{ name }}</p>
</template>

<script>
export default {
  props: ['name']
}
</script>

No código acima, registramos uma prop chamada name que podemos chamar na seção de template da nossa aplicação.

Observação: este é o componente filho e essa prop vai receber dados do componente pai. Vou explicar isso mais adiante.

Como trabalhar com várias props

Você pode ter mais de uma prop adicionando-as ao array de props, assim:

Vue.component('user-detail', {
  props: ['firstName', 'lastName'],
  template: '<p>Hi {{ firstName }} {{ lastName }}</p>'
})

ou, em um componente de arquivo único do Vue:

<template>
  <p>Hi {{ firstName }} {{ lastName }}</p>
</template>

<script>
export default {
  props: [
    'firstName', 
    'lastName'
  ],
}
</script>

Tipos de props no Vue.js

Para especificar o tipo de prop que você deseja usar no Vue, você usará um objeto em vez de um array. Você usará o nome da propriedade como a chave de cada propriedade e o tipo como o valor.

Se o tipo de dado passado não corresponder ao tipo da prop, o Vue envia um alerta (em modo de desenvolvimento) no console com um aviso. Os tipos válidos que você pode usar são:

• String
• Number
• Boolean
• Array
• Object
• Date
• Function
• Symbol

Vue.component('user-detail', {
  props: {
    firstName: String,
    lastName: String
  },
  template: '<p>Hi {{ firstName }} {{ lastName }}</p>'
})

ou, em um componente de arquivo único do Vue:

<template>
  <p>Hi {{ firstName }} {{ lastName }}</p>
</template>

<script>
export default {
  props: {
    firstName: String,
    lastName: String
  },
}
</script>

Como passar dados para props no Vue

O principal objetivo de usar props é passar dados/informações para baixo. Você pode passar seu valor como uma propriedade de dados usando v-bind, como neste código:

<template>
  <ComponentName :title=title />
</template>

<script>
export default {
  //...
  data() {
    return {
      title: 'Entendendo props no Vue.js'
    }
  },
  //...
}
</script>

ou como um valor estático, assim:

<ComponentName title="Entendendo props no Vue.js" />

Suponha que estamos criando uma aplicação que tem vários botões com diferentes cores de texto/fundo. Em vez de repetir a sintaxe do botão em todos os nossos arquivos, é melhor criar um componente de botão e então passar as cores de texto/fundo como props.

Aqui está o componente pai:

<template>
  <div id="app">
    <Button :name='btnName' bgColor='red' />
    <Button :name='btnName' bgColor='green' />
    <Button :name='btnName' bgColor='blue' />
  </div>
</template>

<script>
import Button from './components/Button'

export default {
  name: 'App',
  data(){
    return{
      btnName:"Joel",
    }
  },
  components: {
    Button
  }
}
</script>

Aqui está o componente filho:

<template>
  <button class="btn" :style="{backgroundColor:bgColor}">{{name}}</button>
</template>
<script>
export default {
  name: 'Button',
  props:{
    name:String,
    bgColor:String
  }
}
</script>

O código acima mostra como usar tanto a propriedade de dados quanto valores estáticos quando você está recebendo dados de um componente pai e usando esses dados em um componente filho.

Observação: você também pode usar um operador ternário dentro do valor da prop para verificar uma condição verdadeira e passar um valor que dependa dela.

<template>
  <div id="app">
    <Button :tagUser="signedUp ? 'Logout' : 'Login'" bgColor='red' />
  </div>
</template>
<script>
import Button from './components/Button'
export default {
  name: 'App',
  data(){
    return{
      signedUp: true,
    }
  },
  components: {
    Button
  }
}
</script>

Como passar funções para props

Passar uma função ou um método para um componente filho como prop é relativamente simples. Basicamente, é o mesmo processo que passar qualquer outra variável.

Há razões, porém, pelas quais você não deve usar props como funções – em vez disso, você deve usar emit. Este artigo (texto em inglês) explica corretamente o porquê.

<template>
  <ChildComponent :function="newFunction" />
</template>

<script>
export default {
  methods: {
    newFunction() {
      // ...
    }
  }
};
</script>

Como validar props no Vue

O Vue torna a validação de props muito fácil. Tudo o que você precisa fazer é adicionar a chave required e seu valor à prop. Podemos validar tanto pelo tipo da prop quanto pelo uso de required:

props: {
  name: {
    type: String,
    required: true
  }
}

Como definir valores padrão para props

Antes de concluir este artigo, vamos agora ver como definir valores padrão para nossas props. Valores padrão são renderizados se o componente filho não conseguir obter dados do componente pai.

O Vue permite que você especifique um valor padrão, assim como especificamos required anteriormente.

props: {
  name: {
    type: String,
    required: true,
    default: 'John Doe'
  },
  img: {
    type: String,
    default: '../image-path/image-name.jpg',
   },
}

Você também pode definir o valor padrão como um objeto. Esse pode ser uma função que retorna um valor apropriado, em vez de ser o valor real.

Conclusão

Neste artigo, aprendemos o que as props fazem e como elas funcionam no Vue.js.

Em resumo, usamos props para passar dados dos componentes pais para os componentes filhos. O componente filho também emite eventos para os componentes pais caso você precise enviar dados/eventos do filho para o componente pai.

Obrigado pela leitura!

Links úteis (em inglês)

• Vue.js Component Props - flaviocopes
• Props - documentação do Vue

Escrito por: Thanoshan MV

O que é o VirtualBox?

A máquina virtual (VM) VirtualBox da Oracle é uma aplicação de virtualização multiplataforma desenvolvida pela Oracle Corporation. Ela permite aos usuários instalar sistemas operacionais, como Windows, macOS, Solaris e Linux, em discos rígidos virtuais.

Como exemplo, você pode rodar Windows e Linux em seu Mac, rodar um servidor Windows em seu servidor Linux ou rodar o Linux em seu PC com Windows enquanto executa suas outras aplicações existentes.

Espaço em disco e memória são os únicos problemas que você enfrentará ao instalar várias máquinas virtuais.

Por que você vai precisar dele

• O VirtualBox da Oracle é fácil de instalar e usar
• É grátis
• Você pode rodar e experimentar qualquer sistema operacional de maneira segura
• Se você é um desenvolvedor, o VirtualBox pode ser usado como uma ferramenta para testar seus próprios projetos de desenvolvimento em diversos ambientes de SO de maneira segura
• Ele pode rodar desde pequenos sistemas embarcados até laptops
• É bom para testes e recuperação de desastres, pois pode ser facilmente copiado, e transportado entre hosts, além de ser fácil de fazer o back-up dele

Instalação do VirtualBox

O VirtualBox pode ser baixado aqui: downloads do VirtualBox

Por que o Ubuntu?

• É grátis
• Personalização fácil: o ambiente de desktop GNOME ajuda você a personalizar facilmente
• É seguro
• O Ubuntu é open-source
• Tem uma comunidade amigável e que dá muito suporte
• Requisitos de sistema baixos
• De acordo com a FOSSBYTES (edição de 2019), o Ubuntu é a segunda melhor distro do Linux para programação e desenvolvedores
• É amigável para iniciantes

Configuração do Ubuntu

Primeiro, abra o VirtualBox, depois clique em "New" (Novo, em português) para criar uma máquina virtual.

Digite "Ubuntu" como nome, selecione "Linux" como tipo e selecione Ubuntu (64-bit) como versão.

Observação: selecione a quantidade de memória que desejar, mas não adicione mais que 50% da sua RAM total.

Marque a opção "Create a virtual hard disk now" (Criar um disco rígido virtual agora, em português) para que possamos definir mais tarde o tamanho do disco rígido virtual do Ubuntu OS.

Agora, selecionamos "VHD (Virtual Hard Disk)" (Disco rígido virtual, em português).

Em seguida, vamos alocar dinamicamente o armazenamento em nosso disco rígido físico.

Queremos especificar o tamanho do Ubuntu OS. O tamanho recomendado é, pelo menos, 10 GB, mas você pode aumentar se desejar.

Depois de criar um disco rígido virtual, você verá o Ubuntu no seu painel.

Agora, precisamos configurar o arquivo de imagem de disco do Ubuntu (.iso).

O arquivo de imagem de disco do Ubuntu pode ser baixado aqui: download do Ubuntu

Para configurar o arquivo de imagem de disco do Ubuntu, vá em Settings e siga estes passos:

1. Clique em "Storage" (Armazenamento, em português)
2. Em Storage Devices (Dispositivos de armazenamento, em português), clique em "Empty" (Vazio, em português)
3. Em Attributes (Atributos, em português), clique na figura do disco e "Select Virtual Optical Drive File" (Selecionar arquivo de disco óptico virtual, em português)
4. Selecione o arquivo de imagem de disco do Ubuntu e abra-o

Clique em OK.

Seu Ubuntu está pronto para ser instalado no VirtualBox. Vamos começar!

Observação: a instalação do Ubuntu no VirtualBox e a instalação real do sistema operacional podem variar. Este guia ajuda você a instalar o Ubuntu no VirtualBox apenas.

Vamos instalar o Ubuntu!

Clique em Install Ubuntu (Instalar o Ubuntu, em português).

Selecione seu layout de teclado.

Na seção "Updates and other software" (Atualizações e software de terceiros, em português), marque "Normal installation" (Instalação normal, em português) e clique em Continue.

Em "Installation type" (Tipo de instalação, em português), marque "Erase disk and install Ubuntu" (Apagar o disco e instalar o Ubuntu, em português).

Clique em "Continue".

Escolha sua localização atual.

Agora, configure seu perfil.

Você verá o Ubuntu sendo instalado.

Após a instalação, reinicie.

Após fazer login, você verá a área de trabalho do Ubuntu.

Instalamos com sucesso o Ubuntu no VirtualBox. Ele está pronto para uso em seus futuros projetos de desenvolvimento.

Vamos verificar a instalação

Abra o seu terminal (Pressione Ctrl+Alt+T) e digite os comandos abaixo para verificar se funcionam.

1. pwd: este comando imprimirá o diretório de trabalho atual
2. ls: este comando listará todos os itens no seu diretório atual

Depois de verificar esses comandos, desligue a sua máquina usando o seguinte comando.

poweroff

Conclusão

O VirtualBox é gratuito e uma ótima ferramenta para executar vários sistemas operacionais em um único sistema operacional. O Ubuntu tem muitos benefícios. Se você é um iniciante em Linux, eu recomendaria usar o Ubuntu, pois é amigável para iniciantes.

Sinta-se à vontade para entrar em contato com o autor se tiver alguma pergunta. Você pode contatar o autor e se conectar com ele pelo X e pelo Medium.

Agradecemos pela leitura.

Boa programação para você!

Escrito por: Tarique Ejaz

O armazenamento de arquivos é um recurso importante e necessário em vários processos e em diversos tipos de aplicações. A existência de processos como as Content Delivery Networks (CDNs – ou, em português, redes de entrega de conteúdo), configuradas através de opções de nuvem de terceiros como a Amazon Web Services, e de opções de armazenamento de arquivos locais sempre tornaram mais fácil a criação desse tipo de recurso.

No entanto, o conceito de armazenar arquivos diretamente em um banco de dados através de uma única chamada de API me intriga há muito tempo. Foi aí que o GridFS entrou em cena para mim.

O que é o GridFS – explicação simplificada

O MongoDB possui uma especificação de driver para upload e recuperação de arquivos chamada GridFS. O GridFS permite que você armazene e recupere arquivos, incluindo aqueles que excedem o limite de tamanho do documento BSON de 16 MB.

Basicamente, o GridFS pega um arquivo e o divide em vários pedaços, que são armazenados como documentos individuais em duas coleções:

• a coleção chunk (que armazena as partes do documento) e
• a coleção file (que armazena os metadados adicionais resultantes).

Cada pedaço (em inglês, chunk) é limitado a 255 KB de tamanho. Isso significa que o último pedaço é normalmente igual ou menor que 255 KB. Parece bom, não?

Quando você lê a partir do GridFS, o driver recompõe todos os pedaços conforme necessário. Isso significa que você pode ler seções de um arquivo de acordo com o intervalo de sua consulta. Um exemplo disso é quando você escuta um trecho de um arquivo de áudio ou busca uma seção de um arquivo de vídeo.

Observação: é preferível usar o GridFS para armazenar arquivos normalmente excedendo o limite de tamanho de 16 MB. Para arquivos menores, é recomendado usar o formato BinData para armazenar os arquivos em documentos únicos.

Isso resume como o GridFS funciona em geral. Hora de examinar um código funcionando e de ver como implementar um sistema assim.

Chega de papo, quero ver o código

Estamos usando o Node.js com acesso a uma instância de nuvem do MongoDB para nossa configuração. Você pode encontrar o repositório de código para a aplicação de exemplo aqui.

Vamos nos concentrar inteiramente em segmentos do código que se relacionam com as funcionalidades do GridFS. Vamos aprender como configurá-lo e usá-lo para armazenar arquivos, recuperar arquivos ou um arquivo específico e excluir um arquivo específico. Vamos começar.

Inicializando a engine de armazenamento

Os pacotes necessários para inicializar a engine são o multer-gridfs-storage e o multer. Também usamos o middleware method-override para habilitar a operação de exclusão de arquivos. O módulo crypto do npm é usado para criptografar os nomes dos arquivos ao serem armazenados e lidos do banco de dados.

Quando a engine de armazenamento usando GridFS é inicializada, você só precisa chamá-la usando o middleware multer. Ela é então passada para a rota respectiva que executa as várias operações de armazenamento de arquivos.

Inicializando o stream do GridFS

Inicializamos um stream do GridFS conforme visto no código abaixo. O stream é necessário para ler os arquivos do banco de dados e também para ajudar a renderizar uma imagem em um navegador quando necessário.

Fazendo o upload de um único arquivo ou imagem

Reutilizamos o middleware de upload que criamos anteriormente.

Observação: o nome file é usado como parâmetro em upload.single(), pois temos a chave com um nome similar carregando o arquivo que está sendo enviado pelo client.

Fazendo o upload de vários arquivos ou imagens

Também podemos fazer upload de vários arquivos de uma vez. Em vez de upload.single(), temos que simplesmente usar upload.multiple(<número de arquivos>).

Observação: o número de arquivos carregados pode ser menor que o número definido de arquivos.

Buscando todos os arquivos do banco de dados

Usando o stream inicializado, podemos buscar todos os arquivos no banco de dados específico usando gfs.find().toArray(...). Quando os arquivos são obtidos, mapeamos para um array e enviamos a resposta.

Buscando um único arquivo pelo nome do arquivo

É muito simples consultar o GridFS para um único arquivo baseado em um atributo específico, como filename (o nome do arquivo). Usando o stream do GridFS, você pode consultar o banco de dados através da função gfs.find({<adicione sua consulta aqui>}).

Renderizando no navegador uma imagem buscada

Essa é uma parte um pouco mais complicada, pois você precisa não apenas buscar um arquivo do banco de dados, mas também renderizá-lo como uma imagem no respectivo navegador. Buscamos o arquivo normalmente. Não há nada de novo nesse processo.

Então, com a ajuda do método openDownloadStreamByName() no stream do gfs, podemos facilmente renderizar uma imagem, pois ele retorna um stream legível. Tendo feito isso, podemos usar o método pipe() do JavaScript para transmitir a resposta.

Excluindo um arquivo específico por Id

Excluir um arquivo também é simples. Usamos o método delete() com o parâmetro _id para consultar e excluir o arquivo em questão.

Essas são as principais funcionalidades oferecidas pela engine de armazenamento. Eu utilizei os recursos do GridFS discutidos para criar uma aplicação simples de upload de imagens. Você pode ver o código em mais detalhes no repositório.

Conclusão

Demorei um pouco e tive uma quantidade razoável de dificuldade para entender como usar o GridFS para um projeto pessoal. Por causa disso, queria garantir que ao menos outra pessoa não precisasse ter de gastar a mesma quantidade de tempo que eu nisso.

Dito isso, eu recomendo usar o GridFS com cautela. Não é uma solução universal para todos os seus problemas de armazenamento de arquivos. Ainda assim, é interessante conhecer essa especificação e saber de sua existência.

Se você tiver alguma dúvida ou questão que deseje apontar, fique à vontade para entrar em contato com o autor pelo LinkedIn.

Boa programação para você! 🙂

Escrito por: Aditya Sridhar

Este artigo está dividido em duas partes

1. A primeira parte demonstra como criar uma aplicação simples em React usando o comando 'create-react-app' da interface de linha de comando e explica a estrutura do projeto.
2. A segunda parte explica um código existente que publiquei no Github. Este código demonstra o uso de componentes, a comunicação entre componentes, como realizar chamadas de HTTP e usar o React Bootstrap (bootstrap escrito para React).

Parte 1

Instale o NodeJS, se ainda não o tiver

O NodeJS é necessário, pois as bibliotecas requeridas para o React são baixadas usando o gerenciador de pacotes node (npm). Consulte este site para instalar o NodeJS.

Instale o pacote create-react-app do Node

O pacote create-react-app do Node ajuda a configurar um projeto de React. Instale o pacote globalmente usando o seguinte comando:

npm install -g create-react-app

Crie o projeto

O projeto pode ser criado usando o create-react-app. Use o comando abaixo para criar o projeto:

npx create-react-app first-react-app

first-react-app é o nome da aplicação. O comando acima cria uma pasta chamada first-react-app, que é a pasta do projeto. Para testar se tudo foi configurado corretamente, entre na pasta do projeto e inicie a aplicação com o seguinte comando:

cd first-react-app
npm start

Vá ao seu navegador e acesse o URL localhost:3000.
Você deverá ver que a aplicação em execução. Ela deve ter a aparência semelhante a esta no seu navegador:

Estrutura básica de pastas explicada

Quando você criou o projeto, deve ter notado que ele criou vários arquivos. Aqui listarei alguns dos arquivos e pastas importantes que você deve conhecer:

1. package.json: este arquivo contém a lista de dependências do node necessárias.
2. public/index.html: quando a aplicação é iniciada, esta é a primeira página que é carregada. Será o único arquivo html em todo a aplicação, já que o React é geralmente escrito usando JSX, sobre o qual falarei mais adiante. Além disso, este arquivo tem uma linha de código. Essa linha é muito significativa, pois todos os componentes da aplicação são carregados nesta div.
3. src/index.js: este é o arquivo do JavaScript correspondente ao index.html. Ele contém a seguinte linha de código, que é muito significativa. ReactDOM.render(, document.getElementById('root'));
4. A linha de código acima está informando que o componente App (tratarei do componente App em instantes) deve ser carregado em um elemento do html com o id root. Esse elemento nada mais é do que o elemento div presente no index.html.
5. src/index.css: o arquivo CSS correspondente ao index.js.
6. src/App.js : este é o arquivo do componente App. O componente App é o componente principal no React, que atua como um contêiner para todos os outros componentes.
7. src/App.css : este é o arquivo do CSS correspondente ao Componente App.
8. build: esta é a pasta onde os arquivos compilados são armazenados. Aplicações do React podem ser desenvolvidas usando tanto JSX quanto JavaScript normal em si, mas usar JSX definitivamente facilita as coisas para o desenvolvedor. 😀 No entanto, os navegadores não entendem JSX. Por isso, o JSX precisa ser convertido em JavaScript antes de ser implantado. Esses arquivos convertidos são armazenados na pasta build após serem agrupação e minificados. Para ver a pasta build, execute o seguinte comando

npm run build

Criando componentes

Um componente em React realiza uma funcionalidade específica. Uma aplicação nada mais é do que uma coleção de componentes. Cada componente pode ter vários componentes filhos e os componentes podem se comunicar entre si.

Vamos criar um componente do React agora.

Dentro da pasta src, crie um arquivo chamado FirstComponent.js e copie o seguinte código para FirstComponent.js.

import React, {Component} from 'react';

export default class FirstComponent extends Component {

constructor(props) {
    super(props)
    }

render() {
    const element = (<div>Texto do elemento</div>)
    return (<div className="comptext">
    <h3>Primeiro componente</h3>
        {this.props.displaytext}
        {element}
    </div>)
    }
}

1. O nome do componente é FirstComponent, que é denotado pelo nome do arquivo assim como pela declaração export default class FirstComponent extends Component
2. O atributo props no construtor conterá todos os parâmetros que são passados como entrada para esse componente.
3. render(): o valor de retorno dessa função é renderizado (exibido) na tela. Sempre que a função render() é chamada, a tela é rerenderizada. Isso é geralmente feito automaticamente pela aplicação. O código que se parece muito com html nessa função nada mais é do que o JSX.

O JSX parece muito com o HTML, mas possui todo o poder do JavaScript. Aqui, eu explicarei o código em JSX e o que ele está tentando fazer.

render() {
    const element = (<div>Texto do elemento</div>)
    return (<div className="comptext">
    <h3>Primeiro componente</h3>
        {this.props.displaytext}
        {element}
    </div>)
    }

A primeira linha const element = (<div>Texto do elemento</div>) cria um elemento div e o atribui a uma constante chamada element. Essa sintaxe peculiar que você vê é apenas JSX.

Dentro da declaração de retorno, você vê a seguinte sintaxe:

<div className="comptext">
    <h3>Primeiro componente</h3>
        {this.props.displaytext}
        {element}
</div>

Aqui, className é usado para apontar para uma classe CSS. <h3>Primeiro componente</h3> é apenas uma sintaxe de HTML normal. {this.props.displaytext} é usado para acessar um atributo chamado displaytext a partir de props (então displaytext é passado como uma entrada sempre que esse componente é chamado). Aqui, displaytext é apenas um nome personalizado que eu dei. {element} é a constante que foi criada, que, por sua vez, contém o elemento div.

Usando o componente

FirstComponent foi criado, mas ainda não está sendo usado em nenhum lugar. Vamos adicionar FirstComponent ao componente App. Aqui está o código modificado para App.js

import React, { Component } from 'react';
import logo from './logo.svg';
import './App.css';
import FirstComponent from './FirstComponent'
class App extends Component {
  render() {
    return (
      <div className="App">
        <header className="App-header">
          <img src={logo} className="App-logo" alt="logo" />
          <h1 className="App-title">Bem-vindo ao React</h1>
        </header>
        <p className="App-intro">
          Para começar, edite <code>src/App.js</code> e salve para recarregar.
        </p>
        <FirstComponent displaytext="Dados do primeiro componente"/>
      </div>
);
  }
}
export default App;

FirstComponent precisa ser importado para o componente App primeiro, o que é feito na linha import FirstComponent from ‘./FirstComponent’

Então FirstComponent é adicionado ao componente App usando a linha <FirstComponent displaytext="Dados do primeiro componente"/>

Aqui displaytext é passado como um atributo para FirstComponent.

Agora, você pode executar a aplicação usando o comando npm start

Você deve ver o seguinte resultado no navegador.

Parabéns!

Agora você sabe como criar uma aplicação do React e como criar e usar componentes do React. Você também sabe um pouco sobre JSX. 🙂

A próxima parte explicará um código em React existente do GitHub. O código da parte 2 é diferente do código que escrevemos na parte 1.

Parte 2

Código

O código a seguir está sendo explicado aqui, então clone o repositório em seu computador. O repositório tem instruções sobre como clonar e configurar o código em seu computador.

URL da Aplicação

Para ver a aparência da aplicação final, você pode clicar neste URL. Isso dará uma boa ideia do que a aplicação está tentando fazer.

A aplicação se parecerá com isto em uma tela de celular:

O que a aplicação faz

A aplicação exibe uma lista de clientes. Quando um cliente é selecionado, são exibidos os detalhes do cliente selecionado. Essa é uma aplicação de página única (em inglês, SPA ou single-page application). O React é mais adequado a aplicações de página única. Elas exibem tudo dentro de uma única página.

Estrutura da aplicação explicada

Componente Customers (clientes)

Este componente exibe a lista de clientes. Ele corresponde ao arquivo src/Customers.js. Esse componente tem o seguinte construtor:

constructor(props) {
    super(props)
    this.state = {
        selectedCustomer: 1
    }
}

As props já foram explicadas, mas aqui você também vê this.state. Sempre que o estado muda, o componente é renderizado novamente. Aqui, state tem um parâmetro chamado selectedCustomer para manter o controle de qual cliente foi selecionado. Se selectedCustomer muda, então o componente e seus componentes filhos serão renderizados novamente. O construtor é usado apenas para definir props e state. Além disso, as props nunca devem ser editadas dentro de um componente.

A próxima coisa que você nota é o código a seguir:

componentDidMount() {
    this.getCustomerData();
}

componentDidMount() é uma função que é chamada assim que o componente é renderizado. Portanto, ela pode ser usada para definir alguns valores iniciais, bem como carregar dados. Aqui, ela está chamando uma função de nome getCustomerData()

O próximo trecho de código que você vê é:

getCustomerData() {
    axios.get('assets/samplejson/customerlist.json').then(response => {
        this.setState({customerList: response})
    })
};

A função getCustomerData() faz uma chamada HTTP para ler o JSON de exemplo contendo a lista de clientes de assets/samplejson/customerlist.json. Ao obter uma resposta com sucesso, o estado do sistema é alterado, atribuindo a response à customerList. Você pode se perguntar por que nunca adicionamos customerList no construtor. A razão é que você pode adicionar parâmetros dinamicamente no state em qualquer ponto do código. O único requisito é que, no construtor, pelo menos um state vazio deve ser definido.

A próxima função é a função render(), que retorna quais elementos devem ser renderizados na tela. Os principais pontos de foco na função render são:

<Button bsStyle="info" onClick={() => this.setState({selectedCustomer: customer.id})}>

Clique para ver detalhes

</Button>

Todo cliente na lista possui um botão chamado Clique para ver detalhes. O trecho de código acima indica que, sempre que o botão for clicado, o state de selectedCustomer será alterado para o id do cliente selecionado. Como o state muda aqui, o componente e seu componente filho serão renderizados novamente.

O outro trecho de código importante é:

<CustomerDetails val={this.state.selectedCustomer}/>

Esse trecho indica que CustomerDetails é um componente filho do componente Customers, além de passar o id selectedCustomer como entrada para o componente CustomerDetails

Componente CustomerDetails

Esse componente exibe os detalhes do cliente selecionado. Alguns trechos de código importantes desse componente serão explicados aqui:

componentDidUpdate(prevProps) {

// obter detalhes do cliente apenas se as props mudarem
// (as props são a entrada) 
    if (this.props.val !== prevProps.val) {
        this.getCustomerDetails(this.props.val)
    }
}

A função componentDidUpdate() é chamada sempre que o componente é renderizado novamente. Aqui, estamos chamando a função getCustomerDetails() se a entrada do componente tiver mudado quando o componente for renderizado de novo. A entrada passada para a função getCustomerDetails() é this.props.val. this.props.val, por sua vez, obtém seu valor do componente Customers (selectedCustomer foi passado como entrada para ele). Para saber se a entrada mudou, o trecho de código usado é this.props.val !== prevProps.val

getCustomerDetails(id) {
    axios.get('assets/samplejson/customer' + id + '.json').then(response => {
        this.setState({customerDetails: response})
    })
};

A função getCustomerDetails() faz uma chamada de HTTP para obter o json de exemplo que contém os detalhes do cliente. O parâmetro id é usado para saber quais detalhes do cliente são necessários. O id nada mais é do que this.props.val. Quando a resposta é recebida com sucesso, o state desse componente é alterado atribuindo response a customerDetails.

A função render() para esse componente é bastante direta e simples, então não será coberta aqui.

Referências

create-react-app: consulte este site para aprender tudo que pode ser feito usando create-react-app

ReactJS: consulte o site do React para entender os conceitos do ReactJS. A documentação é muito boa.

React Bootstrap: consulte este site para entender como usar o React Bootstrap

axios: consulte este site para saber mais sobre como usar a biblioteca axios para fazer requisições HTTP

Parabéns novamente!

Agora, você sabe como usar componentes, como comunicar algo de um componente pai para um componente filho e um pouco sobre renderização.

Os conceitos básicos foram abordados neste artigo e espero que ele tenha sido útil para você.

Sobre o autor

O autor é um apaixonado por tecnologia que busca seguir os avanços tecnológicos. Ele também gosta de ajudar os outros com o conhecimento que tem na área.

Sinta-se à vontade para se conectar com ele pelo LinkedIn.

Você também pode segui-lo no Twitter.

Visite o site do autor.

Outros artigos relevantes do autor (em inglês)

A Quick Guide to Help you Understand and Create Angular 6 Apps

A Quick Introduction to Vue.js

Em HTML, a fonte que você escolhe desempenhará um papel importante na aparência de suas páginas da web.

Você pode escolher a cor, o peso, o tamanho da fonte e assim por diante. Todas essas características fazem com que seus sites e aplicações para a web fiquem melhores e mais apresentáveis para o usuário.

Com a propriedade font-size no CSS, você pode mudar o tamanho do texto que está na página da web. Você pode usar essa propriedade em qualquer tipo de CSS que estiver escrevendo – externo, interno ou em linha.

Neste artigo, eu vou mostrar como mudar o tamanho do texto com a propriedade font-size no CSS em linha.

O que é CSS em linha?

CSS em linha (em inglês, inline) é uma das três maneiras diferentes que você pode usar para estilizar qualquer elemento do HTML.

Em vez de direcionar o elemento com um atributo de classe ou id, ou o próprio elemento como o seletor e estilizá-lo dessa maneira, você coloca todos os estilos do CSS na tag de abertura do elemento.

Além disso, você precisa garantir que todas as propriedades e valores dos estilos estejam dentro do atributo style. Esse atributo style é um dos inúmeros atributos aceitos por todas as tags do HTML.

No exemplo abaixo, eu mudo a cor do fundo do texto para crimson, a cor do texto para #f1f1f1 (cinza-claro) e o peso da fonte para bold com CSS em linha.

<p style="background-color: crimson; color: #f1f1f1; font-weight: bold">
      Hello Campers...
</p>

A propósito, meu navegador está com zoom de 400%, por isso tudo aparece tão grande. Eu não apliquei nenhum estilo adicional para conseguir isso. 🙂

Como mudar o tamanho do texto usando CSS em linha

Para mudar o tamanho do seu texto com CSS em linha, você precisa fazer isso com o atributo style. Você digita a propriedade font-size e, então, atribui a ela um valor.

Existem valores embutidos como large, larger, medium, small, x-large e assim por diante:

No trecho de código abaixo, eu mudo o tamanho do texto "Hello Campers…" para x-large, um dos valores embutidos da propriedade font-size.

<p style="font-size: x-large">Hello Campers...</p>

Você também pode definir o valor da propriedade font-size usando um número com qualquer unidade, como pixels (px), rem ou em.

É melhor usar valores numerados porque eles dão mais liberdade para escolher qualquer tamanho de fonte que você quiser.

No trecho de código abaixo, eu mudei o tamanho do texto para 30px com CSS em linha:

<p style="font-size: 30px">Hello Campers...</p>

Conclusão

Neste artigo, você aprendeu como mudar o tamanho do texto com CSS em linha e a propriedade font-size. Você também viu como pode atribuir valores à propriedade font-size.

Apenas um aviso: o CSS em linha é ótimo para estilizar, mas você não deve depender muito dele, pois dificulta a leitura do seu HTML, especialmente se você estiver trabalhando em equipe. Você não quer ser o único capaz de ler seu próprio código.

Esteja ciente de que o CSS em linha também sobrescreve qualquer estilização definida com estilo interno ou externo. Você deve usar estilo externo ou estilo interno, pois eles separam seus códigos HTML e CSS, o que é melhor para a legibilidade.

Ao atribuir valores à propriedade font-size, é melhor atribuir os valores em unidades rem ou em em vez de px, por exemplo. Isso porque, quando você usa rem, o navegador será capaz de fazer ajustes no tamanho da fonte conforme o usuário aproxima ou afasta o texto usando o zoom, o que não acontece quando você usa px.

Agradecemos pela leitura! Siga programando! 😀

Escrito por: Per Harald Borgen

Clique aqui para conferir o curso gratuito de TypeScript no Scrimba

TypeScript é um superconjunto tipado de JavaScript, que visa tornar a linguagem mais escalável e confiável.

Ele é de código aberto e tem sido mantido pela Microsoft desde que eles o criaram, em 2012. No entanto, o TypeScript teve seu avanço inicial como a linguagem de programação principal no Angular 2. Ele vem crescendo continuamente desde então, também nas comunidades do React e do Vue.

Neste tutorial, você aprenderá o básico do TypeScript com a ajuda de exemplos práticos.

Também estamos lançando um curso gratuito de TypeScript em 22 partes no Scrimba. Deixe seu e-mail aqui se quiser acesso antecipado!

Vamos começar.

Instalando o TypeScript

Antes de começarmos a programar, precisamos instalar o TypeScript no nosso computador. Usaremos o npm para isso, então abra o terminal e digite o seguinte comando:

npm install -g typescript

Uma vez instalado, podemos verificar executando o comando tsc -v que exibirá a versão do TypeScript instalada.

Escrevendo algum código

Vamos criar nosso primeiro arquivo TypeScript e escrever algum código nele. Abra seu IDE ou editor de texto favorito e crie um arquivo com o nome de first.ts — Para arquivos TypeScript, usamos a extensão .ts.

Por enquanto, vamos apenas escrever algumas linhas de JavaScript puro, pois todo código JavaScript também é válido no TypeScript:

let a = 5;  
let b = 5;  
let c = a + b;

console.log(c);

O próximo passo é compilar nosso TypeScript em JavaScript puro, já que os navegadores querem arquivos .js para ler.

Compilando o TypeScript

Para compilar, executaremos o comando tsc filename.ts, que cria um arquivo JavaScript com o mesmo nome, mas com uma extensão diferente, e que eventualmente podemos passar para nossos navegadores.

Então, abra o terminal na localização do arquivo e execute o seguinte comando:

tsc first.ts

Dica: se você quiser compilar todos os arquivos TypeScript dentro de qualquer pasta, use o comando: tsc *.ts

Tipos de dados

TypeScript — como o nome sugere — é a versão tipada do JavaScript. Isso significa que podemos especificar tipos para diferentes variáveis no momento da declaração. Elas sempre manterão o mesmo tipo de dados dentro daquele escopo.

A tipagem é um recurso muito útil para garantir confiabilidade e escalabilidade. A verificação de tipos ajuda a garantir que nosso código funcione conforme o esperado. Além disso, ajuda a encontrar bugs e erros e documentar adequadamente nosso código.

A sintaxe para atribuir um tipo a qualquer variável é escrever o nome da variável seguido por um sinal :, o nome do tipo seguido por um sinal = e o valor da variável.

Existem três tipos diferentes em TypeScript: o tipo any, os tipos Built-in (incorporados), e os tipos User-defined (definidos pelo usuário). Vamos dar uma olhada em cada um deles.

Tipo any

O tipo de dado any é o superconjunto de todos os tipos de dados em TypeScript. Dar a qualquer variável o tipo any é equivalente a optar por não verificar o tipo dessa variável.

let myVariable: any = 'This is a string'

Tipos incorporados

Estes são os tipos que são nativos do TypeScript. Eles incluem number, string, boolean, void, null e undefined.

let num: number = 5;  
let name: string = 'Alex';  
let isPresent: boolean = true;

Tipos definidos pelo usuário

Os tipos definidos pelo usuário incluem enum, class, interface, array e tuple. Discutiremos alguns desses mais adiante neste artigo.

Programação orientada a objetos

O TypeScript suporta todos os recursos da programação orientada a objetos, como classes e interfaces. Essa capacidade é um grande impulso para o JavaScript — que sempre teve dificuldades com sua funcionalidade de OOP, especialmente desde que os desenvolvedores começaram a usá-lo para aplicações de grande escala.

Classe

Na programação orientada a objetos, uma classe é o modelo de objetos. Uma classe define como um objeto seria em termos de características e funcionalidades desse objeto. Uma classe também encapsula dados para o objeto.

TypeScript tem suporte embutido para classes, que não eram suportadas pelo ES5 e versões anteriores. Isso significa que podemos usar a palavra-chave class para declarar uma classe facilmente.

class Car {

// campos  
  model: String;  
  doors: Number;  
  isElectric: Boolean;

constructor(model: String, doors: Number, isElectric: Boolean) {  
    this.model = model;  
    this.doors = doors;  
    this.isElectric = isElectric;  
  }

displayMake(): void {  
    console.log(`This car is ${this.model}`);  
  }

}

No exemplo acima, declaramos uma classe Car, junto com algumas de suas propriedades, que estamos inicializando no construtor. Também temos um método que exibiria alguma mensagem usando sua propriedade.

Vamos ver como podemos criar uma instância dessa classe:

Para criar um objeto de uma classe, usamos a palavra-chave new, chamamos o construtor da classe e passamos suas propriedades. Agora, esse objeto Prius possui suas próprias propriedades de model, doors e isElectric. O objeto também pode chamar o método displayMake, que terá acesso às propriedades do Prius.

Interface

O conceito de interfaces é outro recurso poderoso do TypeScript, que permite definir a estrutura das variáveis. Uma interface é como um contrato sintático ao qual um objeto deve obedecer.

Interfaces são melhor descritas através de um exemplo real. Suponha que tenhamos um objeto Car:

const Car = {  
  model: 'Prius',  
  make: 'Toyota',  
  display() => { console.log('oi'); }  
}

Se olharmos para o objeto acima e se tentarmos extrair sua assinatura, ela seria:

{  
  model: String,  
  make: String,  
  display(): void  
}

Se quisermos reutilizar essa assinatura, podemos declará-la na forma de uma interface. Para criar uma interface, usamos a palavra-chave interface.

interface ICar {  
  model: String,  
  make: String,  
  display(): void  
}

const Car: ICar = {  
  model: 'Prius',  
  make: 'Toyota',  
  display() => { console.log('oi'); }  
}

Aqui, declaramos uma interface chamada ICar e criamos um objeto Car. Car está agora vinculado à interface ICar, garantindo que o objeto Car defina todas as propriedades que estão na interface.

Conclusão

Espero que isso tenha dado a você uma visão rápida sobre como o TypeScript pode tornar seu JavaScript mais estável e menos propenso a erros.

O TypeScript está ganhando muito impulso no mundo do desenvolvimento para a web. Há também um número crescente de desenvolvedores do React que o estão adotando. O TypeScript é definitivamente algo que qualquer desenvolvedor de front-end deve conhecer.

Boa programação para você! 🙂

Agradecemos pela leitura! O autor deste artigo é Per Borgen, co-fundador do Scrimba – a maneira mais fácil de aprender a programar. Confira o bootcamp de design responsivo para a web do Scrimba se quiser aprender a construir sites modernos em um nível profissional.

Clique aqui para acessar o bootcamp avançado

Escrito por: Thanoshan MV

O que é Git?

O Git é um software de controle de versão gratuito e de código aberto. Foi criado por Linus Torvalds em 2005. Essa ferramenta é um sistema de controle de versão que foi inicialmente desenvolvido para trabalhar com vários desenvolvedores no kernel do Linux.

Basicamente, isso significa que o Git é um rastreador de conteúdo. Então, o Git pode ser usado para armazenar conteúdo — e é principalmente usado para armazenar código por causa das outras funcionalidades que ele fornece.

Projetos da vida real geralmente têm diversos desenvolvedores trabalhando em paralelo. Assim, eles precisam de um sistema de controle de versão como o Git para garantir que não ocorram conflitos de código entre eles.

Além disso, os requisitos de tais projetos mudam frequentemente. Por isso, um sistema de controle de versão permite que os desenvolvedores revertam e voltem a uma versão anterior do seu código.

O sistema de branches no Git permite que os desenvolvedores trabalhem individualmente em uma tarefa (por exemplo: uma branch -> uma tarefa OU uma branch -> um desenvolvedor). Basicamente, pense no Git como uma pequena aplicação de software que controla sua base de código, se você for um desenvolvedor.

Repositórios do Git

Se quisermos começar a usar o Git, precisamos saber onde hospedar nossos repositórios.

Um repositório (ou "repo", para abreviar) é um projeto que contém diversos arquivos. No nosso caso, um repositório conterá arquivos baseados em código.

Existem duas maneiras de hospedar seus repositórios. Uma é on-line (na nuvem) e a outra é off-line (instalado no seu servidor).

Existem três serviços populares de hospedagem do Git: GitHub (pertencente à Microsoft), GitLab (pertencente ao GitLab) e BitBucket. Usaremos o GitHub como nosso serviço de hospedagem.

Antes de usar o Git, devemos saber por que precisamos dele

O Git facilita a contribuição para projetos de código aberto

Quase todos os projetos de código aberto usam o GitHub para gerenciar seus projetos. Usar o GitHub é gratuito se o seu projeto for de código aberto, e inclui uma wiki e um rastreador de problemas que facilita a inclusão de documentação mais detalhada e o recebimento de feedback sobre seu projeto.

Se você quiser contribuir, você apenas faz o fork (uma cópia) de um projeto, faz suas alterações e, em seguida, envia ao projeto um pull request usando a interface da web do GitHub. Esse pull request é sua maneira de dizer ao projeto que você está pronto para que revisem suas alterações.

Documentação

Ao usar o GitHub, você facilita a obtenção de excelente documentação. A seção de ajuda e os guias deles têm artigos sobre praticamente qualquer tópico relacionado ao Git que você possa imaginar.

Opções de integração

O GitHub pode se integrar com plataformas comuns como Amazon e Google Cloud, com serviços como Code Climate para acompanhar seu feedback, e pode realçar a sintaxe em mais de 200 linguagens de programação diferentes.

Acompanhe as alterações no seu código entre versões

Quando várias pessoas colaboram em um projeto, é difícil acompanhar as revisões — quem mudou o que, quando e onde esses arquivos estão armazenados.

O GitHub cuida desse problema ao acompanhar todas as alterações que foram enviadas ao repositório.

Muito parecido com o uso do Microsoft Word ou do Google Drive, você pode ter um histórico de versões do seu código para que versões anteriores não sejam perdidas a cada iteração. É fácil voltar à versão anterior e contribuir com seu trabalho.

Exibir seu trabalho

Você é um desenvolvedor que deseja atrair recrutadores? O GitHub é a melhor ferramenta em que você pode confiar para isso.

Hoje, ao procurarem por novos recrutas para seus projetos, a maioria das empresas olha para perfis do GitHub. Se o seu perfil estiver disponível, você terá uma maior chance de ser recrutado, mesmo se não for de uma universidade ou faculdade renomada.

Aprendendo a usar o Git e o GitHub

Criação de conta no GitHub

Para criar sua conta, você precisa ir ao site do GitHub e preencher o formulário de registro.

Instalação do Git

Agora, precisamos instalar as ferramentas do Git em nosso computador. Usaremos a CLI (interface de linha de comando) para nos comunicarmos com o GitHub.

Para o Linux:

1. Primeiro, atualize seus pacotes.

sudo apt update

1. Em seguida, instale o Git e o GitHub com apt-get

sudo apt-get install git

1. Finalmente, verifique se o Git está instalado corretamente

git --version

1. Execute os seguintes comandos com suas informações para definir um nome de usuário e e-mail padrão quando você for salvar seu trabalho.

git config --global user.name "seu_nome_de_usuario_aqui"
git config --global user.email "exemplo@e-mail.com"

Trabalhando com projetos no GitHub

Trabalharemos com projetos no GitHub de dois modos.

Modo 1: crie o repositório, clone-o para o seu PC e trabalhe nele. (recomendado)

O modo 1 envolve criar um repositório do zero no GitHub, cloná-lo para o nosso computador, trabalhar em nosso projeto e enviá-lo de volta.

Crie um repositório clicando no botão "New repository" na página da web do GitHub.

Perfeito! Seu primeiro repositório no GitHub foi criado.

Sua primeira missão é obter uma cópia do repositório no seu computador. Para fazer isso, você precisa "clonar" o repositório no seu computador.

Clonar um repositório significa que você está pegando um repositório que está no servidor e clonando-o para o seu computador - assim como baixá-lo. Na página do repositório, você precisa obter o endereço "HTTPS".

Depois de obter o endereço do repositório, você precisa usar seu terminal. Utilize o seguinte comando no terminal. Quando estiver pronto, você pode inserir isto:

git clone [ENDEREÇO HTTPS]

Esse comando fará uma cópia local do repositório hospedado no endereço fornecido.

Agora, o repositório está no seu computador. Você precisa entrar nele com o seguinte comando.

cd [NOME DO REPOSITÓRIO]

Como você pode ver na imagem acima, o nome do meu repositório é "My-GitHub-Project" e esse comando me fez ir para esse diretório específico.

OBSERVAÇÃO: quando você clona, o Git criará um repositório no seu computador. Se quiser, você pode acessar seu projeto com a interface do usuário do computador em vez de usar o comando 'cd' no terminal.

Agora, naquela pasta, podemos criar arquivos, trabalhar neles e salvá-los localmente. Para salvá-los remotamente — como no GitHub — temos que fazer um processo chamado "commit". Para fazer isso, volte ao seu terminal. Se o tiver fechado, como mencionei anteriormente, use o comando 'cd'.

cd [NOME DO REPOSITÓRIO]

Agora, no terminal, você está no diretório do seu repositório. Existem 4 etapas em um commit: 'status', 'add', 'commit' e 'push'. Todos os passos seguintes devem ser realizados dentro do seu projeto. Vamos passar por eles um por um.

"status": a primeira coisa que você precisa fazer é verificar os arquivos que você modificou. Para fazer isso, você pode digitar o seguinte comando para exibir uma lista de mudanças.

git status

"add": com a ajuda da lista de mudanças, você pode adicionar todos os arquivos que deseja enviar com o seguinte comando,

git add [NOME DO ARQUIVO] [NOME DO ARQUIVO] [...]

No nosso caso, vamos adicionar um arquivo HTML simples.

git add sample.html

"commit": agora que adicionamos os arquivos da nossa escolha, precisamos escrever uma mensagem para explicar o que fizemos. Essa mensagem pode ser útil mais tarde se quisermos verificar o histórico de alterações. Aqui está um exemplo do que podemos colocar no nosso caso.

git commit -m "Adicionado arquivo HTML de amostra que contém sintaxe básica"

1. "push": agora podemos colocar nosso trabalho no GitHub. Para fazer isso, temos que fazer o 'push' de nossos arquivos para remote. remote é uma instância duplicada do nosso repositório que vive em algum lugar em um servidor remoto. Para fazer isso, devemos saber o nome do remote (na maioria das vezes o remote é chamado de origin). Para descobrir esse nome, digite o seguinte comando.

git remote

Como você pode ver na imagem acima, é dito que o nome do nosso remote é origin. Agora, podemos fazer o 'push' do nosso trabalho com segurança pelo seguinte comando.

git push origin master

Agora, se formos ao nosso repositório na página web do GitHub, podemos ver o arquivo sample.html que enviamos para o remoto — que é o GitHub!

OBSERVAÇÃO: às vezes, quando você está usando comandos Git no terminal, isso pode levar você ao editor de texto VIM (um editor de texto baseado em CLI). Para se livrar dele, você tem que digitar

:q

e ENTER.

Fazer o 'pull' é o ato de receber do GitHub.

Fazer o 'push' é o ato de enviar para o GitHub.

Modo 2: trabalhe no seu projeto localmente e depois crie o repositório no GitHub e envie-o para o remoto.

O modo 2 permite que você crie um repositório a partir de uma pasta existente no seu computador e o envie para o GitHub. Em muitos casos, você pode já ter criado algo no seu computador que deseja, de repente, transformar em um repositório no GitHub.

Vou explicar isso para você com um projeto de formulário de pesquisa que fiz anteriormente que não foi adicionado ao GitHub.

Como já mencionei, ao executar quaisquer comandos do Git, temos que garantir que estamos no diretório correto no terminal.

Por padrão, qualquer diretório no nosso computador não é um repositório do Git – mas podemos transformá-lo em um repositório do Git executando o seguinte comando no terminal.

Após converter nosso diretório para um repositório do Git, a primeira coisa que precisamos fazer é verificar os arquivos que temos usando o seguinte comando.

git status

Então, há dois arquivos nesse diretório que precisamos "adicionar" ao nosso repositório.

git add [NOME_DO_ARQUIVO] [NOME_DO_ARQUIVO] [...]

OBSERVAÇÃO: para "adicionar" todos os arquivos no nosso repositório, podemos usar o seguinte comando:

git add .

Após a área de stage (o processo de adição) estar completa, podemos verificar se os arquivos foram adicionados com sucesso executando o git status.

Se esses arquivos específicos estiverem em verde, como na imagem abaixo, você fez seu trabalho!

Então, temos que fazer o "commit" com uma descrição.

git commit -m "Adicionando formulário de pesquisa web"

Se meu repositório começou no GitHub e se eu o clonar para meu computador, um remote já estará anexado a ele (modo 1). Se, no entanto, eu estiver começando o repositório no meu computador, ele não tem um remote associado a ele, então eu preciso adicionar esse remote (modo 2).

Para adicionar esse remote, precisamos ir ao GitHub primeiro. Crie um repositório e nomeie-o como quiser para armazená-lo no GitHub. Em seguida, clique no botão "Create repository".

OBSERVAÇÃO: no modo 2, não inicialize o repositório com um arquivo README ao criar um repositório na página web do GitHub.

Depois de clicar no botão "Create repository", você verá a imagem abaixo como uma página da web.

Copie o endereço HTTPS. Agora, vamos criar o remote para nosso repositório.

git remote add origin [ENDEREÇO HTTPS]

Após executar esse comando, podemos verificar se adicionamos o remote com sucesso usando o seguinte comando:

git remote

Se ele exibir "origin", você adicionou o remote ao seu projeto.

OBSERVAÇÃO: lembre-se de que podemos indicar qualquer nome para o remote alterando o nome "origin". Por exemplo:

git remote add [NOME_DO_REMOTO] [ENDEREÇO HTTPS]

Agora, podemos enviar nosso projeto para o GitHub sem problemas!

git push origin master

Após completar essas etapas uma por uma, se você for ao GitHub, encontrará seu repositório com os arquivos!

Conclusão

Obrigado a todos por lerem. Expliquei apenas o básico de Git e GitHub. Recomendo fortemente que todos leiam mais artigos relacionados a Git e GitHub. Espero que este artigo tenha ajudado.

Confira o artigo original (em inglês) no Medium.

Boa programação para você!