Em programação, foque em atravessar o “Deserto do Desespero”

Ao aprender a programar, há um território em que não se vê linha de chegada. É o que Erik Trautman chamou de “Desert of Despair” (“Deserto do Desespero”). Não há jeito senão atravessá-lo

Esta é uma edição especial da Awari Insights - Dados e Tecnologia, dedicada ao Desenvolvimento de Software, à comunidade dev e aos iniciantes na área. Bons leitura e bons insights!


“Aprender a codificar raramente é tão fácil quanto as pessoas fazem parecer, mas também raramente é tão difícil quanto parece no fundo do seu desespero.” — Erik Trautman.

A quase totalidade dos que aprenderam a programar provavelmente já passou por isso. Quem está aprendendo irá passar. Talvez apenas a quem o fez por longas horas, na infância e adolescência, a jornada tenha sido mais suave, embora possa acarretar outras consequências.

É um momento crucial que separa quem persiste no caminho daqueles que andam em círculos, perdem tempo procrastinando ou, então, desistem achando que só seres humanos com um dom ou aptidão inata podem se tornar programadores ou, mais profissionalmente, desenvolvedores de softwares.

Isso ou esse momento (está mais para um território) leva o apelido de “Desert of Despair” (“Deserto do Desespero”, em tradução livre). Faz parte de uma jornada maior que o aprendizado gradativo do desenvolvimento de software demanda.

A expressão foi cunhada em 2018 por Erik Trautman, programador e empreendedor, fundador de iniciativas como The Odin Project e Viking Code School (hoje, parte da Thinkful), direcionados à educação em desenvolvimento web e engenharia de software, e, atualmente, em NEAR Protocol, plataforma de código aberto para aplicativos descentralizados baseados em blockchain.

Para entender o conceito, que aprisiona muitos autodidatas ou mesmo aqueles que estudam programação por meio de cursos — o que envolve desde aspirantes a desenvolvedores front-end e back-end até devops e, em alguma medida, cientistas e engenheiros de dados —, vamos mergulhar em analogias criadas por Trautman, enriquecê-las com interpretações e falar um pouco sobre realização.

Se você está aprendendo a programar, ótimo se o artigo for um sopro de inspiração para perseverar. Se você já passou pela jornada que iremos relatar, talvez relembre, com bom humor, de suas frustrações e alegrias na lida com códigos (talvez esteja nesses altos e baixos cotidianamente, até hoje, não?). 

Em maior ou menor grau, todos que entram no mundo do desenvolvimento, estiveram ou estarão cruzando essa planície árida e monótona um dia. O segredo para encará-la: compreendê-la não como um aspecto totalmente negativo, como somos levados a interpretar, mas usá-lo como uma etapa necessária para desenvolvermos resiliência e carapaça rumo à proficiência.

Um exemplo hipotético. Por vontade, paixão, por gostar de computadores e games ou porque ouviu dizer que dá dinheiro, um interessado resolve se aventurar no mundo do desenvolvimento de software. Começa a pesquisar a respeito. Talvez converse com outras pessoas. Talvez se interesse por cursos. Talvez tente traçar um caminho autodidata.

Estamos considerando o caso de alguém que tem uma “noção” da área e não alguém que já tem uma longa trajetória de mão na massa nela (por exemplo, o garoto ou a garota que brincam de construir pequenos programas desde a infância e que já na adolescência trabalham arduamente para criar o produto revolucionário, que lhes garantirá uma boa aposentadoria precoce).

O primeiro desafio desse principiante é escolher uma linguagem de programação. Talvez goste mesmo de games e quer saber como são renderizados os cenários 3D e programada a lógica dos jogos. 

Descobre que games realistas e multijogador são criados em linguagens como Python, Java, Javascript ou vários “Cs” (C++, C#, apenas C). Então, começa a pesquisar sobre as linguagens. (Spoiler: é fácil prever o roteiro adiante a quem já passou pela experiência).

Ou nosso interessado goste da web e queira saber como as páginas são construídas. Lê sobre um tal de HTML, depois CSS. Talvez comece a brincar e ficar animado por conseguir colorir elementos na tela de forma rápida, como mágica. Até se deparar com Javascript e todo seu ecossistema: Node.js, React, Angular (e suas versões). Pode acabar até enrolado em ECMAScript! Isso sem falar que vai descobrir siglas como PHP, SQL, JSON e várias outras pelo caminho.

Troque a programação para os games ou páginas web para a criação de aplicativos para smartphones. História parecida. Tem Java, mas também tem algumas coisas diferentes, como Kotlin e Objective-C (mais um C!). Javascript também serve. Diz um tutorial que outros nomes, como React Native ou Cordova, são mãos na roda.

Quantas siglas e nomes esquisitos passamos em alguns poucos parágrafos? E isto que estamos falando de linguagens populares e seus principais frameworks. Pode piorar muito: em sua exploração, nosso interessado corre o risco de cair no TIOBE Index, por exemplo.

Fiquemos com o aspirante a web developer, com a pilha básica HTML + CSS + Javascript. Ele resolve que tem de aprender HTML da forma “correta”. Nisso, cai nas profundezas sem fim da arquitetura da própria web, no HTTP e seus verbos (PUT, GET etc.), na árvore do DOM, websockets, talvez acredite que tudo ficará melhor com web assembly.

CSS gera a mesma sobrecarga. Grids, Flexbox, Less, Sass. Bootstrap, Material UI, bibliotecas CSS para React. Quando nosso iniciante chegar em Javascript, estará se metendo em mata ainda mais fechada. Na tentativa de decifrar trechos de códigos e descobrir como as coisas funcionam, quererá conhecer os princípios. Pedirá ajuda em fóruns ou consultará threads existentes.

Irão lhe dizer (ou descobrirá) que antes de saber Javascript deve ter uma noção, de preferência profunda, de lógica e algoritmos. Recursão é conhecimento inicial obrigatório, além de piada velha de mau gosto. 

Trolls, mesmo que de anos ou décadas atrás, continuarão em cantos esquecidos da web dizendo que Javascript não é linguagem de verdade. Aprenda C. Linus Torvalds criou o Linux, sistema sobre o qual o mundo roda, hoje, em C. Não: aprenda Java. Ela vai ensinar o que é Programação Orientada a Objetos (OOP, no inglês), herança, encapsulamento, abstração. É o que separa adultos de crianças.

Java é o atraso e OPP é a pior coisa que aconteceu ao desenvolvimento de software, bradarão outros. Todos deveriam aprender linguagens funcionais por padrão. Recursão é mamão com açúcar nelas. Tem Clojure, um dialeto de Lisp, por exemplo, sobre o qual boa parte do Nubank é construída (o Nubank comprou a empresa criadora da linguagem, para se ter ideia).

Melhor, esqueça Clojure e essas modas atuais. Se quer aprender programação funcional de verdade, vá para Haskell. É mais rápido do que C (eterna disputa) e permite abstrações de mais alto nível que Java! 

Lá você entenderá a beleza sublime que é isolar efeitos colaterais do mundo das funções puras. Vasculhando mais a fundo, você descobrirá que entender o conceito de prova de teoremas matemáticos (Idris e Coq podem ajudar nisso) ou a Teoria das Categorias fará de você um mestre Yoda do código.

Share

Deu para captar onde nosso interessado se meteu. Ele está pulando de um galho a outro no infinito mundo de conhecimento em programação, o que é uma enrascada. Qualquer tópico é como uma árvore cheia de raízes, que, se puxadas, desenterram mais e mais raízes. 

“Programação é muito difícil, não é para mim. Nunca vou dominar todos esses conceitos. Mesmo que aprenda Javascript, nunca vou saber de fato como a lógica por trás dele se comporta. Deveria fazer Ciências da Computação para entender? Ou não tenho dom para programar”, pode, perigosamente, concluir nosso aprendiz. 

O consumo de trilhas de cursos, tutoriais, livros e leituras pode causar mais confusão do que indicar saídas.

Esse contexto ajuda a transmitir o que Trautman quis dizer com “Deserto do Desespero”. Se ficássemos só em minúcias do próprio React ou do vanilla JS (“Javascript baunilha”, um apelido para o javascript puro), muito mais populares e foco de interesse na atualidade, daria no mesmo.

Não há informações sobre se Trautman retirou a expressão de algum lugar. Há referências a um “Desert of Despair”, como um local cheio de armadilhas e areia movediça, nos Power Rangers, um seriado japonês antigo e popular; mas talvez seja pura coincidência. Mesmo assim, o conceito dele remete às mesmas desgraças.

O deserto do desespero é a travessia, talvez a mais longa para quem inicia no aprendizado em programação, em que o interessado se depara com a vastidão e a aridez de conceitos e não sabe em qual direção deve caminhar para sair daquele território movediço. A impressão é que nunca sairá de lá.

Para melhor compreensão, Trautman situa a metáfora em um gráfico de linha. A figura tem “competência” no eixo x e “confiança” no eixo y. Essa relação é dividida em cinco períodos ao longo da jornada: 

  1. hand holding honeymoon (de mãos dadas na lua de mel);

  2. cliff of confusion (penhasco da confusão);

  3. desert of despair (deserto do desespero);

  4. upswing of awesome (escalada do incrível);

  5. job ready (trabalho feito).

Para uma explicação rápida das fases:

  1. Lua de mel: é o período em que o interessado tem os primeiros contatos com a sintaxe de uma linguagem de programação, constrói as primeiras condicionais if-else e os primeiros laços for. Muda códigos de tutoriais, consegue printar algo a mais que “Hello World” na tela, provavelmente de forma mais “mágica”, e tem a impressão de que avança rápido, o que aumenta sua confiança.

  2. Penhasco da confusão: a confiança atinge um pico. O interessado quer se aventurar em algo mais exigente do que printar frases na tela ou ficar no playground da sintaxe básica. Acredita que logo poderá voar, construir seu aplicativo revolucionário e colocar a descrição de “desenvolvedor de software” no Linkedin.

  3. Deserto do desespero: na verdade, ao acreditar que pode voar, ele se atira penhasco abaixo. Algo quebra já nas primeiras linhas no aplicativo revolucionário. Ele passa horas tentando corrigir uma dependência. Tenta alterar linhas do código. Copia, sem entender, sugestões que encontrou no Google. É mais difícil do que parece. A sensação é de estar cada vez mais perdido e desamparado. Talvez seja o caso de ler outro tutorial, quem sabe comprar mais um curso rápido. Melhor: seguir, passo a passo, todo um livro sério. Na ânsia de encontrar aquele prazer que sentiu na lua de mel, arrisca várias tentativas. Vem a ansiedade, a sensação de estar perdido piora e o aprendiz começa a se questionar se tem “dom” para aquilo.

  4. Escalada do incrível: depois de um tempo de idas e vindas e, principalmente, meditar, centrar-se em seus objetivos, limpar a poeira dos olhos, alguma coisa acontece. O interessado já descobriu que não tem outro jeito a não ser consultar a documentação, em vez de querer fórmulas prontas. Começa a fazer analogias com o que já viu para encarar problemas novos. Pede feedback e troca conhecimento. Está subindo o aclive que irá torná-lo apto para o trabalho duro e sério de fato.

  5. Trabalho feito: o interessado perseverou colina acima, ficou mais forte e chegou em um ponto em que basta seguir em frente. Talvez o correto não seja dizer que ele está “pronto” para o trabalho, mas que reuniu aquele autoconhecimento necessário para encarar os novos desafios que continuarão surgindo pelo caminho. Até porque programar é isso: resolver problemas, um após o outro, durante toda a carreira.

Dois fatores-chave estão em jogo, segundo Trautman, para que o deserto do desespero seja tão enfadonho: densidade de recursos e escopo do conhecimento. Ele usa mais gráficos para explicar tais conceitos.

Densidade de recursos é o que o aprendiz tem à disposição. Há muito conteúdo, milhões ou bilhões de páginas, vídeos, MOOCs, tutoriais, respostas em fóruns e todo tipo de referências e ajuda à medida em que se depara com mais complexidade. 

Há, também, muito mais desafios de conhecimento, como aprender sobre frameworks específicos, bibliotecas, paradigmas e detalhes especializados de uma determinada linguagem, ambiente ou software em que se está trabalhando.

Trautman dá exemplos. Se na lua de mel você muitas vezes está aprendendo por meio de ambientes gamificados, tutoriais passo a passo muito fáceis e experimentando diretamente em um editor de código simples, à medida que escala o penhasco da confusão tem de recorrer ao Stack Overflow, a tutoriais mais avançados e imergir instruções mais robustas.

No deserto do desespero, a coisa piora, porque a oferta é vasta e interminável e você se depara com a documentação dos frameworks, precisa decidir onde delimitar sua atuação para seguir em frente, o que implica em escolher um caminho e abandonar vários outros. 

Essa oferta de recursos não diminui com o passar da jornada. O que muda é a forma de consumi-la. O aprendiz, já situado em sua trajetória, começa a se referenciar pelo feedback de outros profissionais, aprende a consultar documentação à medida em que é necessário (descobre que nunca vai ter conhecimento prévio da maioria das coisas), envolve-se em uma comunidade e torna o aprendizado mais suave e diluído ao longo da rotina. 

Ele agora reconhece que nunca saberá tudo, mas aprende a aprender continuamente (o tão em voga lifelong learning).

O escopo do conhecimento diz respeito, principalmente, a fundamentos que o aprendiz precisa. Se a sintaxe básica lhe basta na lua de mel, ao subir o penhasco da confusão ele se deparará com a necessidade de ler código de terceiros e debugar programas — práticas consideradas entediantes, mas ótima escola para a vida real. 

O deserto do desespero é quando ele está tentando usar as habilidades básicas para criar um produto no mundo real, mesmo que seja um programa simples, uma página web que registra e consome informações em um banco de dados ou API ou um aplicativo que exibe conteúdos.

O aprendiz se depara com dificuldades que vão além do código em si, como sua organização, modularização e padronização, a integração de bibliotecas e frameworks, os paradigmas de programação (OOP e funcional, principalmente), as pilhas (stacks) muito mais complexas do que o código de principiante em um único arquivo-texto.

Na analogia de Trautman, esse escopo se alarga consideravelmente na fase mais longa. Já não é só questão de pegar alguns snippets (trechos prontos) de código e colar em sequência para a aplicação rodar. 

Há todo um trabalho criativo, que requer o avanço por partes, para que a solução seja construída. Em uma comparação com a matemática, você deixou de apenas fazer cálculos dentro de fórmulas que outros inventaram e consolidaram para ter de criar suas próprias fórmulas e prová-las.

Um fator de frustração é que programação não é como muitas atividades do mundo real, em que, se faltar uma pequena peça, a construção ainda se sustenta. Em código, todas as partes são interdependentes e necessárias à estrutura. Não pode haver ambiguidades e incompletudes.

Para um exemplo, pense em vários palitos. Muitas construções na engenharia, nos negócios e outros ramos, são como colocar esses palitos lado a lado para que suportem alguma coisa. Retire um palito e a carga ainda se acomoda sobre os demais. 

Em programação, é como se você construísse uma corrente circular, fechada, similar a uma correia dentada de uma bicicleta. Retire um único elo e o todo se desfaz. Não há como tracionar a bicicleta.

O artigo em que Trautman destila toda sua tese, Why Learning to Code is So Damn Hard (“Por que aprender a codificar é tão difícil”, em tradução livre), fornece mais insights, principalmente sobre todas essas frustrações e dificuldades inerentes ao aprendizado de programação.

Trautman diz que encontrou eco de sua analogia ao entrevistar centenas de aspirantes a desenvolvedores. A quantidade de relatos que surgiu, de jornadas pessoais baseados na mesma ideia, não deixa dúvida. Uma demonstração é este artigo. 

A abordagem levou, também, a outras interpretações sobre o aprendizado em código, como a comparação da jornada descrita com o efeito Dunning-Kruger — listado, aliás, como uma espécie de viés cognitivo, como vimos no artigo passado

Na prática, o efeito é a sensação vivida por quem acha que sabe mais do que realmente sabe ou do que outros sabem, o que acomete muitos iniciantes em diversas áreas. É algo comum quando alguém se aproxima do penhasco da confusão.

Por outro lado, a persistência da baixa confiança mesmo no decorrer do aumento da experiência leva outra sensação para lá de comum no desenvolvimento de software, o oposto do efeito Dunning-Kruger: a Síndrome do Impostor, o comportamento de acharmos, constantemente, que sabemos menos ou somos menos competentes do que de fato somos.

Share Awari Insights - Dados e Tecnologia

O mais comum é encararmos essas frustrações e dificuldades descritas por Trautman como impedimentos, fatores de atraso ou de aprendizado “errado”. 

Como se existisse um lindo caminho oculto e mágico que, se seguido desde o início, proporcionasse avanço rápido e perfeitamente linear até estarmos prontos para o trabalho — obviamente, uma ilusão.

Aqui, vamos arriscar uma mudança de considerações. Dificuldades, sofrimento e erros são incômodos, nos atrasam e nos deixam em apuros. Mas, se estivermos ao menos conscientes deles e encontrarmos formas de persistirmos, eles sempre serão grandes professores em qualquer jornada de longo prazo.

Não vamos nos enganar: apesar das ofertas tentadoras que dizem ser possível aprender a programar em um mês, dez dias ou 24 horas, não é assim que funciona, como disse Peter Norvig, diretor de pesquisa no Google e uma referência em Inteligência Artificial, em Teach Yourself Programming in Ten Years (“Aprenda a programar em dez anos”).

“Pesquisadores [...] mostraram que leva cerca de dez anos para desenvolver experiência em qualquer uma de uma ampla variedade de áreas [...]. A chave é prática deliberada: não apenas fazer isso de novo e de novo, mas desafiar-se com uma tarefa que está um pouco além de sua capacidade atual, experimentá-la, analisando seu desempenho enquanto e depois de fazê-la e corrigindo quaisquer erros. Então repetir. E repetir novamente. Parece não haver atalhos reais [...]” Peter Norvig.

É claro que não é necessário passar dez anos aprendendo para depois aplicar o conhecimento. Em qualquer contexto (e no atual, mais ainda), seria perda de tempo e estupidez. 

É possível (hoje necessário, diríamos) aprender à medida em que se avança gradualmente, a fim de otimizar a jornada. Quanto mais cedo botarmos a mão na massa do mundo real, mais aprendemos, mesmo que nos custe um bocado de desconforto emocional, principalmente no início.

O deserto do desespero parece inerente a qualquer aprendizado ou aquisição de habilidades. Ele será mais tenebroso quanto mais urgente queiramos que esse aprendizado seja. 

Da mesma forma, será mais suave se pudermos atravessá-lo (ou melhor, dissolvê-lo) em nossos anos de estudo, principalmente na infância, adolescência e juventude. Nem todos têm essa sorte, é claro. Temos de compreender nossas circunstâncias. 

E mesmo que tem essa certa “vantagem” inicial pode se revelar confiante demais, até “selvagem” demais, alguém mais apegado em hackear e brincar do que em construir grandes projetos de forma disciplinada ou de fazer o trabalho sujo e chato de refatorar código legado, por exemplo — no que, quem aprende com orientação e alguma maturidade, pode ter vantagens.

O fato é que as condições áridas e duras do deserto são, também, uma escola à resiliência e a entender que a vida profissional não é uma linha ascendente de felicidade ou de uma prazerosa dopamina.

A trajetória é, na verdade, uma adaptação às condições adversas, até o ponto em que pareçam bem menos difíceis ou se transformem em desafios motivadores, os quais trazem satisfação à medida em que são realizados.

Felicidade e realização, aliás, são temas pouco estudados cientificamente. Talvez por não serem considerados assuntos “sérios”, necessários à “racionalidade”, durante a maior parte da Modernidade.

Se consultarmos estudos mais atuais a respeito, descobriremos que, se pudéssemos reduzir a felicidade a um indicador, ela permaneceria mais ou menos estável (tendência à média) ao longo da vida de um indivíduo.

Em uma escala de 0 a 10, por exemplo, há são indivíduos que teriam esse índice mais próximos de um 8 ou 9, digamos, e se sentem otimistas a maior parte do tempo, enquanto há outros que ficam em uma média de 6 ou 7 a maior parte da vida, sem que isso seja prejudicial (o mais pessimista pode ser mais cauteloso, se arriscar menos e se sair melhor no longo prazo, por exemplo). São características.

A jornada de aprendizado ou a trilha profissional não será como uma escada, em que, superada determinada tarefa ou obstáculo, o nível de felicidade aumentará, sempre em um crescente. Não: haverá satisfação momentânea, um pico. Logo depois, o indicador tenderá à média novamente. Enquanto isso, o trabalho continuará a existir e precisará ser feito. 

Independentemente de quantos desafios forem superados e de quanto conhecimento for adquirido, não haverá um ponto de felicidade e realização plenos. Isso explica porque alguém que, teoricamente, tem instrução ou condição de vida limitados pode se sentir mais feliz do que alguém que tem todo o conforto do mundo à disposição e nenhuma obrigação.

(Mais sobre essa teoria, em certo sentido biológica, sobre felicidade e realização, é contextualizada no capítulo 19, “E eles viveram felizes para sempre”, do livro Sapiens: Uma breve história da humanidade, para referência.)

O entendimento e a aceitação de que o deserto do desespero chegará a quem aprende programação é uma forma de lidarmos com a travessia. 

Ter consciência de que se trata uma fase, mesmo que incômoda e longa, dependendo do caso, pode ajudar a nos mantermos centrados e persistentes, mesmo que tudo pareça uma tempestade de areia (oferta de conteúdo e necessidade de conhecimento).

Um dos fatores que contribuem é ter objetivos e uma visão de longo prazo: o que chamamos de “propósito”. Pode ser querer construir software para prestar um melhor serviço à sociedade em uma determinada área (saúde, com a Covid, por exemplo), para educar novas gerações, para ajudar a nos livrarmos do trabalho repetitivo e automatizável ou só porque gostamos de conhecimento, de entender como as coisas funcionam e de construí-las. O importante é manter esse norte em vista, como uma bússola, para atravessar o deserto.

(O próprio livro Sapiens, citado acima, também contextualiza isso: humanos sobreviveram a condições muito mais duras na Antiguidade ou na Idade Média, e talvez se sentiram mais realizados mesmo assim, porque acreditavam em religião ou outras crenças, que são outras formas de propósito).

Mais recomendações são inspiradas no próprio Trautman e em Norvig. O primeiro traz dicas para cada uma das fases na jornada de aprendizado:

  • Na lua de mel, experimentar diferentes recursos de aprendizados, mas, em seguida, escolha um deles como um caminho no qual perseverar e não se desvie. Tente cumprir o programa de um curso com disciplina. O mesmo vale para um livro que seja referência na área. A dica é não querer pular de possibilidades em possibilidades.

  • No penhasco da confusão, trabalhar com outra pessoa, talvez outro iniciante (uma forma de compartilhar e enriquecer o conhecimento, além de outros benefícios), ler código de outras pessoas e começar um pequeno projeto (um site básico, um jogo de tetris, um aplicativo para exibir a previsão do tempo), que você possa incrementar constantemente.

  • No deserto do desespero, as recomendações dele são, na verdade, outras palavras para o “propósito” de que falamos: ter um objetivo forte, encontrar um caminho forte, focar na jornada e evitar distrações. A repetição ao longo do tempo fará todo o trabalho.

  • Na subida do incrível, a lição é se familiarizar e seguir as melhores práticas de codificação, preencher lacunas de conhecimento que ficaram das fases anteriores (aqui, você já tem mais maestria para isso) e, principalmente, enfrentar habilidades pouco atraentes, como debugar código “macarrônico” legado ou preocupar-se com testes automatizados de código.

Norvig insiste na prática deliberada. Botar a mão na massa e seguir em frente, bug após bug, tentando decifrar cada aviso de anormalidade que aparecer na tela. 

Repetir isso dará consistência para a carreira. Até porque a carreira será uma sequência desta prática: construir, ver se funciona, investigar o que não funciona (e muita coisa nunca vai funcionar de primeira), corrigir, recomeçar o ciclo. Fazer isso até que a atividade se torne tão automática quanto a do Djokovic batendo na bolinha de tênis. 

Sua receita para o sucesso na programação também contém, entre outros conselhos:

  • Seguir em frente porque é divertido e porque continuará divertido o suficiente pelos próximos 10 anos ou 10 mil horas (o equivalente a dizer: até você poder se considerar sênior naquilo).

  • Aprender botando a mão na massa. Pode ser em um desafio real, quem sabe um site ou app para uma instituição filantrópica. Deixa de ser só sobre código e tem ligação com o que impacta e beneficia outras pessoas.

  • Conversar com outros programadores (para Norvig, mais importante do que qualquer livro ou curso).

  • Trabalhar em projetos colaborativos com outros programadores (colaborar em projetos de código aberto, por exemplo).

  • Trabalhar em projetos já feitos por outros programadores, isto é, debugá-los, analisá-los, corrigi-los e melhorá-los. Isso dará proficiência em compreender código e consertar o que for preciso (útil se você for um devops, estiver sozinho no plantão e alguma coisa quebrar no código da startup ou empresa).

Por fim, nunca é demais repetir: não se cobrar tanto, dar um pouco de tempo ao tempo, cultivar humildade e desenvolver autoconhecimento (técnicas como mindfulness e certas terapias comprovadamente ajudam nisso). 

Também, ter em mente que, no fim das contas, tudo isso é sobre trabalho, uma dimensão importante da vida, mas não a única.

Não observar isso pode nos levar a burnout, que pode ocorrer mesmo nos estudos, e à já comentada Síndrome do Impostor, um bom tema para explorarmos em artigos futuros.

Leave a comment

Artigo escrito por Rogério Kreidlow, jornalista, que gosta de observar a tecnologia em relação a temas amplos, como política, economia, história e filosofia.


Dica extra: se você tem interesse em desenvolvimento de software, mas nunca leu ou se aprofundou a respeito e quer ter uma introdução mais amigável a esse mundo, o artigo “Como aprender a programar: passo a passo”, no blog da Awari, ou a edição “Como começar a programar, com Emanoel Vianna, da Sicredi”, em nosso podcast “Não é magia, é tecnologia”, podem ser úteis.