Pra ser exato, se você assistiu meu vídeo sobre meus primeiros 5 anos, eu fiz um pequeno curso de programação sim, em 1990, quando tinha uns 13 anos, de Basic. Este episódio é um daqueles difíceis de organizar as idéias, porque dá pra explicar de dezenas de jeitos muito diferentes. Se você não assistiu os outros vídeos do meu canal, eu sou programador desde 1991 e de lá pra cá eu aprendi e trabalhei com dezenas de linguagens e frameworks diferentes, de comerciais como Java ou C#, a open source como PHP e Ruby, a mobile como Objective-C e entreguei projetos de todos os tipos. E desde 1990 eu venho aprendendo a maior parte do que eu sei quase sempre sozinho. A intenção do vídeo de hoje é ser meio repetitivo mesmo porque eu quero tentar marretar alguns conceitos na sua cabeça.
Quando eu entrei na faculdade eu já sabia o básico de programação. Eu não tinha a fundação pra explicar o porquê das coisas, mas eu conseguia achar as pistas iniciais pra começar a resolver um problema. Então a faculdade nunca me ensinou a “programar” propriamente dito. Agora, eu sinto que muita gente que ansiosa tá no problema anterior: você se sente devagar. Sente que estuda, estuda, mas não avança. Parece que todo novo problema te joga de volta à estaca zero. Você consegue resolver um problema, mas o próximo não consegue mais.
Parece que existe um consenso num caminho: faça um curso, compre um livro, daí tente fazer um projetinho seu do zero. Já ouvi muito isso. Mas eu acho que isso não é eficiente pro aprendizado. Pra que fique claro: eu não estou dizendo que o conteúdo em si seja ruim. Eu só acho que em alguns casos não se leva em consideração que existem dois tipos distintos de público.
Eu dividiria os iniciantes entre aqueles que naturalmente são autodidatas e os que não são. Os que não são, por diversos motivos, tem dificuldade de desviar do material que é apresentado. Elas se sentem mais confortáveis seguindo uma receita ou um procedimento. E quando algum passo diverge do procedimento eles ficam angustiados e travam e não conseguem saber que passo tomar em seguida.
Autodidatas naturalmente não se importam muito com procedimento. A gente obviamente tenta seguir, mas quando um passo não funciona, em vez de sentir angústia a gente sente uma raiva que nos leva a querer entender porque o passo falhou. Foi culpa do procedimento? Foi minha própria culpa porque errei algum passo anterior? Se for esse o caso, deixa eu voltar passos e tentar de novo. Deixa eu voltar pro começo e tentar tudo de novo. Ainda não funciona? Deixa eu pesquisar. Deixa eu perguntar pra outras pessoas. E assim vamos até uma hora avançar pro próximo passo. Por isso eu digo que autodidatas sempre vão avançar independente da qualidade do material de ensino. Porque a gente naturalmente não se conforma. E quando um autodidata se dá bem, não foi por causa de algum curso ou material, foi só a determinação de avançar mesmo.
Por isso eu enfatizei a idéia de não delegar suas decisões num vídeo inteiro. No aprendizado os autodidatas naturalmente tomam uma decisão: se o procedimento não funciona, vou tentar descobrir porque. O procedimento não decide por mim, eu decido pelo procedimento. Os não-autodidatas quando encontram uma barreira, eles travam, e tem a expectativa que alguém ou alguma coisa vai tirar eles do problema. Como assim o procedimento não funciona? Devia funcionar. Vou cruzar os braços e esperar até alguém consertar o procedimento. E vou reclamar que o procedimento não funciona. E vou querer meu dinheiro de volta. Em qualquer outro contexto isso não está totalmente errado, mas em aprendizado é o exato oposto de aprender.
Eu não sei como chamar um não-autodidata então me perdoem se o termo não soa bem, mas vou chamar de pessoas passivas, que esperam as coisas acontecer em vez de fazer as coisas acontecerem. Em um ambiente de aprendizado, você precisa ser diferente: você não quer que as pessoas digam o que você tem que fazer. Você quer referências e orientações mas não ordens nem procedimentos. Mas a maioria dos tutoriais e cursos introdutórios que eu vejo se preocupam em ensinar o "o que" em vez do "porque" e faz sentido. Explicar “o que” fazer é muito mais fácil do que explicar “por que”. Vejam este canal. O "o que" normalmente tá no título, ou no primeiro minuto do vídeo. É o porque que custa 30 minutos ou 1 hora.
Agora, se alguém quer ensinar, ele quer que os alunos tenham o máximo de satisfação possível no final. Se tentar ensinar de verdade, forçar os princípios, explicar os porquês, criar situações de frustração pros alunos. A maioria vai desistir. Porém, se focar mais em exemplos simples e procedimentos, até o pior dos alunos vai conseguir passar por todos os passos. E a satisfação no final vai ser maior porque fica a falsa sensação que aprendeu alguma coisa, quando na verdade só seguiu um procedimento. E qualquer um consegue seguir procedimentos, não requer talento, tampouco habilidade.
É que nem quando você era criança e tinha aqueles livros de colorir com espaços numerados bonitinho. No número 1 você pinta de vermelho, no 2 você pinta de verde, vai seguindo as instruções e no final você tem um desenho colorido bonito o suficiente. Você aprendeu a pintar? Não. Você aprendeu a teoria das cores e como harmonizar essas cores no desenho? Não. Você pintou um desenho mas não avançou nenhum passo em aprender arte. Isso se chama passatempo.
Eu não sei se vocês já se interessaram em assistir vídeos ou documentários sobre o início dos computadores caseiros no fim dos anos 70 e começo dos 80. Na Europa com os ZX-Spectrum. Nos Estados Unidos com os Commodore. Mesmo no Brasil com os TK que eram clones dos Sinclair. E vários outros modelos similares e simples de 8-bits ou 16-bits. Você podia programar em Basic ou Assembler, linguagem de máquina mesmo. Eram computadores super fracos, com pouquíssima memória e processamento, mesmo pros padrões da época. E eles costumavam vir com um manual de instruções que normalmente ensinava o básico de Basic .. alguns exemplos de códigos pra animações e joguinhos simples nível jogo da velha. E era só isso que você tinha.
Muitas vezes você sequer tinha onde gravar o que programava, porque gravador de fita cassette era opcional, disk drives de 5 e 1/4 ou 3 e 1/2 eram mais caros. HD então era inacessível, muitos desses computadores nem aceitavam. A maioria das pessoas se contentava em comprar joguinhos e programas educacionais e ser só um mero usuário do computador. Uma pequena parcela aprendia a programar nessas máquinas limitadas. Sem cursos. Sem livros. Sem internet pra pesquisar nem nada.
Vocês perceberam que eu já contei muitas dessas histórias em episódios anteriores? Eu posso ter sido sutil, mas eu falei de tudo isso até hoje pra ver se vocês chegavam na pergunta mais óbvia. Como pessoas como eu, quando criança, conseguimos aprender a programar num ambiente muito mais hostil do que hoje em dia?
Eu já dei metade da resposta no vídeo de não delegar suas decisões e também no de como eu aprendi inglês sozinho. E a resposta não é porque eu ou essas outras crianças da época éramos gênios, com QI superior ou qualquer bobagem dessas. A resposta mais simples é porque a gente não deixou de ser criança até hoje. Vou relembrar o que eu disse no vídeo de inglês. Muita gente tentando aprender a falar em inglês não consegue, porque tem vergonha de falar errado. Então fica nervoso, gagueja, dá branco, e isso deixa ainda mais nervoso, gaguejando mais. Até o ponto onde a pessoa conclui: ahhh isso Não é pra mim, eu não sou inteligente o suficiente pra aprender (chora).
Eu não sou um profissional de ensino, nem estudioso do comportamento humano, mas eu tenho uma teoria. Tirando os casos de real deficiência física, doença, ou algo assim, eu realmente não acredito que as pessoas sejam incapazes de aprender qualquer coisa. E eu não digo isso porque eu sou algum tipo de humanista e tenho fé nas pessoas ou qualquer bobagem assim. Na verdade é até o oposto. Mas deixa eu apresentar um fato pra vocês. No exemplo do inglês por exemplo, pra você que acha difícil falar, que acha que o curso é ruim, ou que o material que você tem é ruim, ou que você só é burro mesmo e nunca vai aprender. Você fala português?
Concorda comigo que 100% das pessoas nascidas no Brasil, com ou sem educação formal, todas falam português? Porque existiria uma deficiência pra se aprender inglês mas não existe uma deficiência que te tornou incapaz de aprender português quando você era criança? Minha teoria é que todos nós nascemos sem noção de "sentir vergonha" ou qualquer tipo de "auto-julgamento". Quanto mais nova uma criança, menos vergonha ela tem, mesmo falando errado. E ela fala errado o tempo todo, alguns adultos acham bonitos, outros acham irritante. A gente tenta corrigir e elas não ficam mudas de vergonha, elas atentamente copiam os adultos. Elas vão de poucas sílabas sem sentido, palavras que não formam frases direito, até conseguir argumentar coisas complicadas com os adultos. E tudo isso sem NENHUM treinamento formal.
Nenhuma criança precisou de curso pra aprender a chutar bola na rua. Nenhuma criança precisou de curso pra aprender a se comunicar com as outras no jardim da infância. Elas simplesmente vão e fazem. À medida que se envelhece - e aqui eu não tenho bagagem técnica pra explicar porque - cria-se uma barreira. Em algum momento você tentou fazer alguma coisa que ainda não sabia como, você errou, alguém te criticou ou tirou sarro de você, e você parou de tentar. A partir desse dia, tudo que antes você não julgava difícil começou a ficar angustiante, frustrante, você se sente desajustado, inadequado, burro e até mesmo incapaz.
A grande maioria das pessoas de 40 anos, se eu falar, suba num palco e fale. Ou, grave vídeos e mostre pras pessoas. Elas vão ficar aterrorizadas. Eu também fico. Até hoje quando vou dar uma palestra, não importa se é pra 500 pessoas ou pra 10 pessoas, me dá frio na barriga, começa a vir os pensamentos de "e se me der um branco". Se eu errar será que as pessoas vão achar que eu sou uma fraude? A diferença é que independente disso eu sou kamikaze, então eu ligo o "foda-se" e simplesmente vou. Pessoas como eu não fazem as coisas porque não temos medo. A gente faz as coisas apesar do medo. O medo que você sente eu também sinto e ela continua aqui. Mesmo depois de anos e anos. Você pode se esconder e evitar o medo ou você pode aprender a conviver com o medo. Em qualquer dos dois casos o medo vai continuar, então porque não só ligar o foda-se?
Deixa eu fazer uma tangente. Alguns meses atrás eu decidi comprar um uniciclo. É super difícil se equilibrar nessa porcaria. A dificuldade inicial é mais ou menos a mesma de skate, do básico de skate, quero dizer. Eu passei 2 ou 3 dias caindo no chão. Se você quer aprender coisas novas, você não pode pensar "puts, que coisa feia eu quarentão caindo no chão e me ralando todo como se fosse uma criança de 10 anos". É extremamente vergonhoso você sair na rua pra treinar e cair na frente dos outros. E eu tenho tomado tombo na rua mesmo. E o que eu vou fazer? Desistir e inventar justificativas de porque alguém da minha idade não devia estar fazendo essas coisas? Nem a pau.
E veja que interessante. A loja onde comprei até ofereceu um grupo de suporte pra iniciantes treinarem juntos. Mas eu sou muito mais teimoso e arrogante pra isso. Eu gosto de aprender as coisas sozinho. É uma coisa minha. Eu prefiro tentar usar meu tempo da forma mais eficiente possível e me deslocar pra algum lugar, num horário pré-determinado, nunca me pareceu eficiente pra mim. Eu não gosto de ter outras pessoas do lado pra cair na armadilha de usar a muleta do "puts, isso é difícil mesmo né? Se a gente tivesse 10 anos já tinha conseguido" e aí fica um se sentindo mais confortável porque o outro tá lamentando também. Eu vira e mexe me vejo lamentado mas eu odeio ficar me lamentando, e eu detesto mais ainda ouvir o lamento dos outros.
Então, pra aprender, eu comecei num sábado de manhã cedo e eu treinei sem parar, sem pausas mesmo, tomando tombo e tentando de novo, tombo atrás de tombo, até lá pelas 9 horas da noite que foi quando eu consegui andar em linha reta pela primeira vez sem cair. Eu terminei o dia com as pernas roxas, inchadas e raladas de tanto cair. E quando eu caía eu caía mesmo, deixava meu corpo inteiro ir pro chão. Acordei domingo cedo e fiz a mesma coisa, horas a fio até conseguir dar curvas. Eu tinha colocado na minha cabeça que eu ia aprender a andar naquela porcaria em 2 dias, então eu fui e fiz. E isso pra aprender o básico, não estou pulando rampas nem fazendo malabarismo não.
Como qualquer um faria, eu assisti videos de tutorial na sexta feira. Nenhum me ajudou muito porque nenhum disse a coisa mais óbvia. Você já tentou subir numa bicicleta e ficar parado em cima dela? Não dá, ela despenca pros lados. Como você faz pra não despencar? Você sobe na bicicleta já dando a primeira pedalada e sai pedalando. É a inércia do movimento que impede você de cair. É a mesma coisa no uniciclo, você precisa subir nela já andando. Sem isso você vai cair. Sei lá porque; tanto eu, como todo mundo que pediu pra tentar, o primeiro instinto é ficar de pé parado em cima do negócio. Agora que eu sei, é claramente idiota isso, porque ninguém vai conseguir ficar imóvel em cima disso, é impossível. No máximo você vai fazer a roda ficar girando pra frente e pra trás pra se equilibrar no mesmo lugar. Mas parado, parado é impossível.
E eu aprendi a andar a primeira linha reta quando esse insight me ocorreu. Daí o próximo passo foi brigar com o próprio corpo que instintivamente quer parar quando ele se vê indo pra frente sem as pernas estarem se mexendo. Sério, a memória muscular do corpo é uma droga. O corpo quer frear sozinho, daí são horas até você obrigar o seu corpo a desaprender e aceitar que o novo estado natural dele é andando pra frente em cima do negócio. Aprendizado, no seu núcleo, é uma briga de você contra você mesmo. Por isso eu acho que nós anti-sociais temos uma vantagem, porque a gente tá acostumado a brigar com nós mesmos.
Desculpa fazer essa longa tangente de uniciclo mas esse episódio me lembrou dessa situação, porque é igualzinho com qualquer outra coisa que você tá aprendendo. Primeiro, você precisa perder a vergonha de cair, porque é lógico, você é iniciante, você tem que cair, tem que se ralar todo, tem que ficar roxo e machucado. Segundo, você precisa desaprender o que você acha que sabe, porque senão você freia automaticamente e cai sem saber porque.
Respondendo a pergunta que eu fiz agora a pouco. Como nós aprendemos a programar naqueles computadores dos anos 80? A gente caía. Nossos códigos davam pau. A diferença é que a maioria desiste nas primeiras tentativas. Mas alguns de nós ficam roxos e não se importam de ficar mais roxos. Eu pensei nesse exemplo porque este fim de semana mesmo, lá estava eu andando de uniciclo na rua, não prestei atenção, tropecei e caí com tudo no chão. O que eu fiz no dia seguinte? Tomei um remédio pra dor e resolvi andar 20 quilômetros pela cidade, porque depois da queda eu senti meu corpo arregando e ficando com medo, então eu fui ensinar uma lição pra ele, que quem manda sou eu.
O prazer de um autodidata é provar pra ele mesmo que ele suporta a dor. A gente sente dor, igual todo mundo, mas em vez de evitar a dor, a gente faz esforço pra se acostumar a sentir dor. É bem doloroso quando você faz um curso, lê um livro, e seu código ainda não funciona ou você nem sabe como fazer um código diferente do que foi ensinado. É super frustrante. E sua primeira reação é o que? O curso é que não deve ter sido bom. Ou deve ter outro livro que vai ensinar de verdade o que precisa saber. Desculpe se eu sou o primeiro a dizer isso: a menos que você esteja disposto a encarar a dor, engolir o choro, esquecer a frustração, e começar a cair e ficar roxo na frente dos outros, não adianta nenhum curso, nenhum livro, nada, você nunca vai aprender. Ou você pára de desperdiçar dinheiro indo atrás de fórmula mágica, ou engole a dor, pára de mimimi, se compromete e foca no objetivo.
Vou repetir: programação é uma profissão de prática. Qualquer atividade manual como culinária, artes, esportes, como subir num uniciclo, tudo é prática. Eu aprendi o básico, sei andar num uniciclo, cobrir longas distâncias, e não cair, mas eu ainda não sei o avançado. Eu não sei pular rampas por exemplo, estou treinando agora a andar numa perna só. E porque eu faço isso? Não tenho a mínima idéia, eu simplesmente quero.
Até hoje todo mundo chama os invasores digitais russos ou chineses de hackers. O termo acabou sendo distorcido e hacker passou a significar, ou algo ruim e criminoso, ou algo tecnicamente muito difícil que exige um QI superior, como você vê num Mr. Robot da vida. Mas isso é o que antigamente a gente chamava de Cracker. Só que a definição original de hacker é só uma pessoa curiosa. Na verdade mais que só curioso, alguém que é curioso é alguém que faz a pergunta. Mas um hacker é alguém que também procura a resposta. Todo bom programador é um hacker.
Eu sempre achei que a forma mais eficiente de aprender é primeiro tentando fazer, de qualquer jeito, sem objetivos. Sem instrução nenhuma. Existem algumas etapas que você provavelmente vai passar. A primeira é a do zero. Não estou dizendo pra não fazer curso. Faça. Se você ainda não sabe, use pra aprender o básico do ambiente. Como eu uso o editor de textos que o curso apresentou? Como eu salvo o código? Como eu faço pra esse código rodar. Por que vocês acham que os vídeos técnicos que eu fiz primeiro são de como instalar o sistema operacional e configurar as formas de rodar as primeiras linguagens?
Mas você precisa também passar por um período, alguns dias por exemplo, de copiar código de livro, de tutorial ou de qualquer lugar do GitHub, sem se importar se você tá fazendo certo ou errado. Você tá nos primeiros dias. Sério, não tem importância nenhuma saber se você tá fazendo direito ou não. Vou repetir: não importa. A vantagem de código é que ele não custa nada. Você não gasta nada. Se der erro você não perde nada. Não se machuca. Eu gosto de correr antes de aprender a andar. Se cair do uniciclo não machucasse, a primeira coisa que eu ia fazer era pular de uma rampa, depois aprender a andar em linha reta. Mas eu provavelmente ia quebrar uma perna, então não dá pra fazer isso. Mas com código dá.
Corre e depois anda. Copia um monte de código. Parece idiota isso, mas abre um código do GitHub de um lado, o editor do outro lado e vai copiando, da mesma forma como você copiaria um texto de um livro no Word. A intenção é ganhar memória muscular. Ao fazer isso várias vezes, você vai instintivamente começar a ganhar noção de como os códigos são escritos, como programadores melhores que você dão nome pras coisas, com que estética. A silhueta do que é um código vai começar a se formar na sua cabeça. Nesse ponto não importa se esse código vai servir pra alguma coisa ou não. Só digita muito, por horas, dias. Você precisa se familiarizar com o máximo possível de código num período curto de tempo.
Eu aprendi a datilografar desse jeito. Lembram no episódio de Henry Jones que eu disse que eu copiava enciclopédia? Não era uma vez só não. Tinha verbetes que eu copiava múltiplas vezes, porque eu achava que não tinha ficado bom da primeira vez. Mas pra que fazer isso? Não tem nenhum motivo, só porque eu gostava da sensação de sair do ponto onde eu era devagar até ficar rápido copiando. Foda-se o conteúdo do que eu tava copiando. Eu tô dizendo pra você fazer a mesma coisa, mas não só pra ficar rápido. Copiando muitos textos eu pouco a pouco fui entendendo o que é o tamanho adequado de um parágrafo? Como é a composição das frases? Que palavras são mais ou menos usadas?
Pouco a pouco, treinando desse jeito, você vai percebendo uma coisa interessante: padrões. No sentido de repetições. Diferentes códigos de diferentes pessoas tem certos padrões embutidos nelas. Algumas são estruturais, algumas são estéticas. Pouco a pouco você vai diferenciando quais são obrigatórias, quais são opções estéticas. Nomenclatura das coisas. Tamanho das funções. Complexidade do código. Diferentes formas de resolver o mesmo problema.
Quando a gente é iniciante dificilmente pensa "quero fazer um programa X" e daí vai magicamente conseguir. Você não vai, e mesmo se chegar perto ou conseguir, vai estar uma droga. É o contrário. Você vai copiando muitos códigos, entendendo o que cada trecho faz. Aos poucos você aprende ... ahh é assim que se abre um arquivo. ahh é assim que se grava um arquivo ... ahh é assim que eu posso passar uma URL e baixar o conteúdo. Uma hora você pensa ... peraí, se eu consigo abrir e salvar coisas num arquivo e se eu consigo baixar coisas da internet ... isso é um programa que podia ser útil, vou fazer um programa que baixa os artigos dos sites que eu gosto e guarda em arquivos.
O objetivo aparece sozinho depois que você começa a aprender o que cada trecho diferente de código faz. Inverte sua expectativa. No fundo não importa o que você acha que quer fazer porque na prática você ainda não sabe o que é possível fazer, então suas idéias sempre vão ser medíocres e provavelmente tudo que você consegue imaginar já existe pronto. A menos que você já seja um estudioso de outra área, seja de física, matemática, direito, qualquer outra coisa, suas idéias iniciais sempre vão ser simplórias. Por isso Não importa tanto o objetivo do código, só importa você codar.
Estou sendo bem repetitivo porque parece que não é tão óbvio. Quantas horas você já gastou digitando código? A diferença entre hoje e na minha época é que hoje você tem um troço chamado GitHub onde pode baixar todo tipo de exemplo de código possível e imaginável. Eu nunca mais ia dormir se aos 13 anos eu tivesse um GitHub. Falando em não dormir, o que eu vou dizer agora é o clichê do clichê mas eu vou dizer mesmo assim. Pessoas como eu amam fazer as coisas a noite. Estudar ou qualquer coisa. E existe uma grande razão pra isso: todo mundo tá dormindo de noite. Ninguém te liga. Ninguém te manda mensagem. Ninguém te atrapalha nem te interrompe. Se você mora com outras pessoas na mesma casa, elas provavelmente estão dormindo.
A melhor coisa pra estudar ou produzir coisas criativas é estar completamente focado. É o estado que as pessoas olham pra mim e me chamam de autistas. Porque quando eu quero entrar nesse modo eu literalmente ignoro todo mundo. Meu celular fica permanentemente em “Não perturbe”. Eu literalmente não atendo meu celular. Mesmo mensagens em whats ou direct ou email, eu raramente respondo na hora. Eu respondo quando eu estiver com vontade de responder, nunca antes. E por isso também eu gravo e edito meus vídeos a noite. Não tem barulho, não tem maldito cachorro barulhento do vizinho, não tem barulho de carro, nada pra atrapalhar. Você precisa encontrar seu espaço isolado e usar ele pra estudar e produzir. E não existe mais viciante e mais improdutivo do que redes sociais. Redes sociais é a definição de perda de tempo. Não tem absolutamente nada em nenhuma rede social que exige sua atenção imediata. E se você se acostumar a não querer engajar em alguma coisa na hora que você vê, e espera 5 minutos, quando voltar vai ver que não era assim tão importante que merece seu tempo de comentar. Threads de redes sociais são basicamente coisas inúteis, mas é bom pra quando você vai no banheiro e já tá enjoado de candy crush.
A idéia não é você sair contribuindo em projetos de código aberto também. Se tiver a oportunidade pode fazer, mas não é esse o objetivo principal pra você que é iniciante. O objetivo é você pegar fluência no código. Fluência não é fazer tudo certo em todos os passos. É você dar a cara pra bater e errar sem se intimidar em sentir vergonha. Fluência em uma língua nova, tipo inglês, é a mesma coisa, é a atitude de simplesmente falar, mesmo se estiver errado, e não ter vergonha e se intimidar quando alguém te corrigir.
Você vai notar que a recomendação aqui é igual do vídeo de como aprender inglês. Porque é a mesma coisa. Em vez de tentar decorar gramática, decorar vocabulário e tentar escrever um texto todo certo da primeira vez, e se frustrar, porque obviamente você não vai conseguir. Eu acho mais fácil ler e ouvir o máximo possível de tudo que é lugar. Igual quando você aprendeu português quando era criança. Você aprende a falar igual o que se fala na televisão e igual os adultos ao redor falam. Você não aprendeu nenhuma regra gramatical, você aprendeu via reconhecimento de padrões, ou patterns.
Nós seres humanos somos muito bem equipados pra detectar patterns via nossos sentidos. O que significa isso? Significa que somos bons em detectar coisas que se repetem ao nosso redor. Mas é uma faca de dois gumes. Ilusões de ótica, por exemplo, brincam com os bugs nesse nosso sistema. Muitas vezes esse sentido nos engana, e aí criamos superstições. Por exemplo, associamos muito tempo atrás a correlação de que passar embaixo de uma escada dá azar. Provavelmente porque algumas pessoas que foram vistas passando debaixo de uma escada depois sofreram algum infortúnio. E o pattern de "passar embaixo de escada e sofrer" acabou pegando. A maioria das besteiras que dão trending no Twitter são isso: falácias lógicas por viés de confirmação, uma falha de correlação, vítima do nosso excelente sistema de detecção de patterns. O principal: só porque você nota uma grande repetição de alguma coisa, não a torna boa, pode ser o que chamamos de anti-pattern.
Eu já expliquei no meu vídeo de inglês sobre a diferença entre patterns e padrões. Mas vou repetir aqui de novo pra relembrar. Em inglês existem três palavras diferentes que traduzem pra padrão em português. Temos Standard que é "o" padrão, como um regulamento ou regra a ser seguida. Temos Default que é a escolha padrão, ou seja, dentro de várias opções se você não escolher nenhuma o sistema pode escolher o default. Default pode ser também quando você não paga uma dívida e dá default nela. Finalmente, o que a gente usa em tecnologia que é "um" padrão ou repetição, isso é um Pattern. Patterns não representam uma regra ou regulamento ou o melhor jeito, são simplesmente coisas que se repetem várias vezes.
Isso é importante explicar aqui porque várias vezes muitos iniciantes me falam que estão estudando o livro de Design Patterns do Gang of Four, e me perguntam se isso vai ajudar eles a virarem programadores melhores. Minha resposta é simples: se você é iniciante, isso vai ajudar muito pouco pra quase nada. Patterns é uma coisa que você vai entendendo melhor ao longo do tempo e não adianta só estudar uma vez, você vai revisitando de anos em anos e vai entendendo melhor a cada nova revisitada.
Entendam, a idéia de patterns foi inspirada no livro A Language Pattern do arquiteto Christopher Alexander. Arquiteto de construções de verdade mesmo. Ele compila os patterns vistos em arquitetura que podem ajudar na composição de novos designs usando uma linguagem comum usada a séculos em construções pelo mundo. É um catálogo de organização urbana com mais de 250 patterns que descrevem a visão do Alexander de como uma cidade perfeita poderia ser. Do layout das ruas, até o café da esquina.
O que é um pattern em arquitetura. Vejamos um problema trivial: como entrar e sair de uma casa? Um buraco com uma tábua que abre e fecha. Nome do pattern? Porta. Dá pra implementar de outras formas? Claro, pode ter uma câmera e um computador pra abrir e fechar sozinha. Pode ser redonda em vez de retangular. Pode ser uma porta com outra porta no meio.
Agora, você não precisou ter o livro do Alexander pra saber o conceito da porta. Se você construir uma casinha do zero e esquecer da porta, você não vai conseguir entrar na casa. Mas você sempre pode pegar uma marreta e abrir uma porta na força pela parede. É meio idiota mas funciona. Em código é mais fácil. Se você esquecer da porta, sempre pode refatorar ou reescrever o trecho do código que precisava da porta. O custo do código é proporcionalmente quase zero se comparado a corrigir um erro no mundo físico, de tijolo e madeira.
Meu ponto é que os patterns surgem da observação de centenas de construções. E criam uma linguagem pra descrever os elementos dessas construções. Milhares de pessoas ao longo da história vieram implementando essas construções e agora só ganharam um nome pra podermos falar delas. Eu pensei isso quando o livro do Gang of Four saiu pela primeira vez em 1994. Lembre-se que antes disso a gente já fazia bons softwares e não havia uma formalização de patterns. Ela é útil e importante, mas não é crucial, especialmente no começo.
O livro ganhou notoriedade porque coincidiu com o nascimento do mercado de Java. Então pra uma novo mercado de programadores, orientação a objetos e design patterns pareciam uma coisa nova que andavam juntos e eram a “regra”, o “standard” a ser seguido. Mas na realidade, comece a programar, observar o código de outras pessoas, e você naturalmente chega na maioria dos patterns do livro. De command, a visitor, a observer, a builder. A grande maioria dos patterns, aliás, foi derivado de frameworks de interfaces gráficas como Motif nos Unix. Se você já teve a oportunidade de criar ou usar uma toolkit de elementos gráficos como um tcl/tk ou Qt ou Gtk ou WPF ou Apple UIKit, vai facilmente ver muitos dos patterns do gang of four neles.
E esses não são os únicos patterns. Hoje em dia, por alguma razão, o Domain Driven Design do Eric Evans, que foi lançado em 2003 foi ressuscitado por causa do famigerado pattern Repository. No mundo Ruby on Rails a gente se inspirou no Patterns of Enterprise Application Architecture do Martin Fowler pra pegar emprestado o pattern que ele cunhou como ActiveRecord. Todo guideline visual de interfaces gráficas da Apple, do Gnome, e outros são patterns de como implementar aplicações gráficas coerentes.
Tudo isso e muito mais são patterns. Mas eu acho muito pouco útil estudar os patterns sem ter experiência anterior em programação. Eu acho mais útil estudar patterns depois que você já treinou escrevendo muito código e lendo muito código dos outros. Daí o estudo dos patterns vai ajudar a criar uma linguagem pra descrever patterns de programação que você já estava acostumado a ver mas só não sabia os nomes. Foi o que aconteceu comigo. Ah, isso que eu fazia se chama Visitor, bom saber. Ah, esse outro jeito aqui é um chain of responsability, que fancy, bom saber também.
Se você com pouca experiência começa estudando e decorando os patterns primeiro e depois vai querer tentar aplicar, você vai usar tudo errado. Patterns são ferramentas. Você não deve usar todas ao mesmo tempo. Cada problema tem uma ferramenta pra escolher e nem sempre essa escolha é simples. Até hoje muita gente discute ActiveRecord versus Repository. Eu acho engraçado povo discutindo isso em 2019 sendo que foi ponto de grande discussão em 2003 ao ponto de eu ficar enjoado de ouvir sobre Repository e na época era versus DAO ou Data Access Objects que a Microsoft usava bastante.
Vejam, 16 anos depois e até agora as pessoas ainda não chegaram num consenso sobre acesso e abstração de dados. Além de ActiveRecord, Repository, DAO ainda temos outros patterns como Data Mapper, Table e Row Data Gateway e outros patterns. Patterns não são regras, não são “o” jeito certo de resolver todos os problemas, são apenas repetições, cada qual emergiu pra resolver um problema diferente numa situação diferente.
Por isso eu digo que tanto faz que curso você faça, que livro você leia, no fundo eles são quase todos iguais porque todos vão ensinar mais ou menos do mesmo jeito: do jeito linear, passo a passo, que raramente é o que você vai encontrar no mundo real. No mundo real você tem um problema pra resolver, e sua solução vai depender do quanto você treinou com quantas ferramentas e técnicas diferentes. Pra chutar uma combinação de elementos que pode ou não resolver o problema da forma mais eficiente possível, dentro das limitações e circunstâncias em que você se encontra. Quanto menos você treinou, menos opções você vai ter. Se você só treinou um jeito, você sempre só vai querer resolver de um jeito, e normalmente não é o jeito mais eficiente. E por isso eu falo pra não se apaixonar por uma linguagem ou uma ferramenta. Daí vem o ditado: pra quem só conhece martelo, todos os problemas parecem pregos.
Alguns anos atrás eu comecei a estudar Elixir, Crystal e Rust. Eu li a documentação dos sites deles primeiro. Eu procurei os poucos tutoriais que eles tinham disponíveis 4 anos atrás. E eu simplesmente fui codando, qualquer coisa. Códigos sem nenhum propósito além de exercício. A minha vantagem quando aprendi essas linguagens é que eu já tinha experiência de programação em outras linguagens, então eu não levei mais que 30 dias pra aprender cada uma. A que eu até hoje tenho menos fluência é Rust porque foi o que eu menos treinei. Elixir foi o que tinha melhor material pelo fato que ele pôde aproveitar as décadas de existência e maturidade do Erlang que está por baixo dele, então o framework OTP já era bem compreendido e com inúmeros exemplos, patterns e anti-patterns conhecidos e bem documentados. Crystal foi quase trivial porque ele se valeu de usar quase a mesma sintaxe de Ruby e usar os patterns de Go pra concorrência, então se você já sabe Ruby ou se você já sabe Go, pular pra Crystal é uma questão de poucos dias.
Quanto mais você vai desistindo a cada dificuldade que aparece e desiste de ir até o fim pra resolver, mais difícil as coisas vão ficando. Se você aprender a aprender, que é hackeando seu caminho, resolvendo problemas que o material não previu, ou seja, aprendendo a ser autodidata, a vantagem é que quanto mais você aprender assim e criar seu próprio ritmo, menos difícil vai ficando aprender coisas novas. A maioria das coisas novas é uma melhoria de coisas anteriores. Então as primeiras linguagens que eu aprendi em 1990, que foram Basic e dBase, são hiper simples pros padrões de hoje, mas eu levei meses e meses pra aprender. Porque eu não tinha nem material, nem base de referência. Linguagens ordens de grandeza mais complicados como um Elixir, pra mim, é uma questão de semanas pra me tornar produtivo nelas. Não me tornar um expert, cuidado, me tornar produtivo.
A idéia não é falar mal dos cursos e livros, só apontar que é impossível criar um curso ou livro que consiga te mostrar como é programação na vida real. Eles virariam livros de milhares de páginas e extremamente tediosos de ler. A estrutura de cursos e livros é tentar transmitir um conhecimento no menor tempo e esforço possíveis. É como um livro de artesanato, ele pode te dar passo a passo de como pregar madeira e prego e fazer uma cadeira. Mas se você nunca usou um martelo nem nunca cortou madeira na vida, na realidade você vai quebrar um monte de tábuas, entortar um monte de pregos, provavelmente vai martelar o próprio dedo e se cortar um monte de vezes até conseguir fazer uma cadeira que não vai se parecer nada com a foto do livro. No final a diferença é só isso: quem desiste, o caminho acaba aí. Não tem outro caminho a não ser ir em frente, independente da sua frustração ou da sua vergonha.
Sobre conhecimento de fundação. Eu diria que se tem uma matéria de faculdade que é obrigatório e separa os amadores e hobistas dos que vão fazer uma carreira de verdade em programação é Algoritmos e Estruturas de Dados. Qual é a diferença entre um Tuple ou uma Lista Ligada? Qual a diferença de um String de conteúdo imutável e um String Buffer que você pode adicionar e modificar o conteúdo? Aliás, se é tudo binário, qual é a diferença de um integer e um string? O que de fato é a diferença entre um float e um double? Toda linguagem tem essas coisas, é a base de TODAS as linguagens. Um Java parece difícil porque ela tem umas 20 classes diferentes só pra Listas. Por exemplo, qual a diferença de um ArrayList, um LinkedList, um Stack, um SortedSet, uma Queue?
Daí você precisa aprender: qual a forma mais fácil de estruturar os dados pra ser fácil recuperar o que você precisa depois? Vai passar pelas coisas triviais como Quicksorts ou Mergesorts até chegar em coisas mais legais como Bloom filters e até hash rings e consistent hashing. Quando você entende esses elementos, coisas como computação distribuída, replicação de bancos de dados como NoSQL e tudo mais começam a clicar na sua cabeça mais fácil. Mas pra chegar nisso você precisa sair do básico. Entender as estruturas de dados e algoritmos mais simples primeiro, de um mero struct de C, union types, nomes como markov, levenshtein, huffman e assim por diante.
Algoritmos e Estruturas de Dados eu não vejo como você poderia aprender organicamente, sem um material formal. Vai precisar estudar a teoria e praticar centenas de vezes pra realmente ganhar fluência. Por isso eu acho que linguagens como C ou Pascal eram boas pra começar, porque você era obrigado a entender essas coisas pra fazer qualquer coisa. A maioria das linguagens modernas esconde essas coisas de você, então você não nota que vai precisar até muito tarde.
Esquece estudar Design Patterns ou Arquiteturas de Sistemas antes de aprender Estruturas de Dados e Algoritmos. Estou repetindo isso várias vezes pra vocês colocarem isso na cabeça. Antes de dominar o básico, esquece o avançado, não vai acontecer. É que nem querer aprender culinária e achar que não precisa aprender Mis en place ou descascar batata. Tudo que você constrói precisa de fundações sólidas. Quanto mais porcaria for sua fundação pior vai ser seu puxadinho. Você vai bater num teto muito rápido e não vai conseguir crescer, e seu puxadinho toda hora arrisca desabar. Se preocupe em fundações sólidas, não em hype da moda.
Hype da moda, linguagem ou framework da moda, tudo isso é simples. Sério, se você tem boas fundações, aprender um novo framework “tem” que ser simples. Aprender uma nova linguagem tem que ser simples. Claro, ganhar fluência exige tempo, mas você não vai ficar coçando a cabeça toda hora ficando frustrado porque não consegue começar a aprender. Você tem dificuldade de aprender porque tem preguiça e tá postergando sofrer a fundação, que é chato, teórico, difícil e parece que não tem utilidade. Mesma coisa técnica de usar a faca direito pra cortar as coisas. Você teima em não aprender, e não consegue cortar mais rápido sem cortar os dedos juntos. Porque você é burro, a gente já sabe o jeito certo, isso é o básico, a fundação, o que todo mundo que vai cozinhar já devia saber.
Aliás, caso não seja óbvio, frameworks são implementações de patterns pra resolver um determinado tipo de problema. Por exemplo, frameworks de GUI pra interfaces gráfica como o UIKit da Apple ou frameworks web como Rails e Laravel pra aplicativos web. Ou frameworks como OTP do Erlang pra sistemas distribuídos. Frameworks são manifestações em forma de implementação de patterns reusáveis de programação.
Outra coisa interessante é que muitos design patterns podem ser considerados defeitos nas linguagens. A gente costuma chamar esse tipo de boilerplates, que são trechos de código que todo mundo meio que convencionou a fazer toda vez. É uma sensação de .. “porque eu estou tendo toda hora que fazer esse mesmo código em todo lugar em vez da linguagem ou mesmo do framework fazerem isso por mim?” .. É quando você é obrigado a criar funções ou classes vazias ou arquivos pra lá e pra cá, só pro negócio compilar ou rodar.
Eu vou dizer que ainda não tô totalmente contente com essa minha explicação até agora. Mas os pontos principais pra resumir: Primeiro, estude obrigatoriamente Algoritmos e Estruturas de Dados. Segundo, desligue redes sociais, coloque seu celular em modo de não perturbe o tempo todo. Terceiro, não se preocupe em codar coisas com objetivo no começo, os objetivos do exercício não importam, o único objetivo é codar e codar. Quarto, não importa qual curso e qual livro você vai escolher pra aprender a primeira linguagem, tanto faz mesmo, a diferença entre a maioria dos cursos mais conhecidos é marginal. Quinto, treine, treine, treine e treinar não é fazer projetinho do zero. Nada de bom sai de uma cabeça vazia. Treinar é copiar qualquer código sem nenhum objetivo, quebrar esse código, combinar códigos de pessoas diferentes, mas principalmente, copiar a maior quantidade de código dos outros quanto possível. Só depois de copiar e copiar trechos por centenas de horas você vai começar a identificar sozinho alguns patterns. Quando finalmente você se sentir confortável com os puxadinhos de código que começam a funcionar de forma precária, talvez você possa estudar os diversos design patterns que existem por aí só pra dar nome pros seus puxadinhos. E é assim que você começa.
Eu falei isso no vídeo de Conhecimentos Gerais no começo da série Começando aos 40. Eu acabei de dizer que a coisa mais importante é se expôr à maior quantidade de código dos outros quanto possível, mesmo se não entender nada da primeira vez que ler. É como aprender uma nova língua e desligar as legendas dos filmes. A idéia é você sofrer mesmo, e aprender a lidar com essa angústia de não estar entendendo nada. Pra isso você pode e deve usar o GitHub que está dando sopa com milhões de projetos em todas as linguagens e frameworks que você pode imaginar. É a biblioteca de Alexandria do código. Pra isso, a primeira coisa que você deve aprender é a usar Git, e o Google tá aí pra isso. Hoje em dia tem muito tutorial simples. Se você ainda não sabe, aprende. Qual é a desculpa?
E é isso aí, eu queria deixar uma resposta mais completa pra essa indagação do que eu estava conseguindo dizer nas mensagens diretas. Espero que tenha ajudado a criar um modelo mental do que você devia estar fazendo pra superar essa fase inicial de aprendizado em qualuqer coisa. Se ficou com dúvidas não deixe de mandar nos comentários, se tiver outras dicas também são muito bem vindas. Se curtiram o vídeo mandem um joinha, não deixem de assinar o canal e cliquem no sininho pra não perder os próximos episódios. A gente se vê, até mais.