Não há atalhos para conseguir um trabalho de desenvolvedor: aprenda a codificar de maneira lenta

Desde que comecei o Boot.dev , fui inundado com o que chamo de “perguntas areia movediça”. Superficialmente, uma pergunta de areia movediça parece uma boa pergunta. Se você pudesse respondê-la, ela o catapultaria de onde você está (turno noturno no Wendy's drive-in) para onde você quer estar (contar aos amigos que você trabalha em Netflix, aliás).

As perguntas areia movediça tratam de encontrar atalhos.

Preciso de um emprego de desenvolvedor em 3 meses; qual é a melhor maneira de fazer isso?

Vejo que você definiu 20 cursos em seu caminho de aprendizagem de back-end, mas, *piscadela*, quais posso pular?

O que há de errado com os atalhos?

Agora, quero ser claro : não há absolutamente nada de errado em querer seguir um caminho mais curto em direção ao seu objetivo profissional. Qualquer outra coisa seria loucura. Se houvesse uma pílula para transformá-lo em um desenvolvedor sênior da noite para o dia, eu o encorajaria a estourar esse idiota.

Em teoria, o min-maxing educacional parece uma estratégia sólida, mas simplesmente não funciona na prática.

Por que? Porque o destino é desconhecido .

O algoritmo de Dijkstra é ótimo se você sabe para onde está indo. Se não, você precisa de outra coisa.

Ninguém sabe para onde estão indo

O cenário tecnológico é um aglomerado de complexidade. Aprendi cerca de dez linguagens de programação diferentes na faculdade e, mesmo após três anos de graduação, ainda não sabia que acabaria trabalhando como engenheiro de back-end escrevendo Go.

Entrevistei todo tipo de bobagem, desde sistemas embarcados até desenvolvimento front-end. Sim, acontece que minha aula de Prolog não ajudou muito na minha primeira entrevista, mas quer saber? Não doeu , e agora, quando alguém diz: “É um sistema declarativo”, minha expressão facial não revela ignorância.

Se você soubesse exatamente quais conceitos precisa dominar para passar na primeira entrevista, poderá encontrar um atalho eficaz. O problema é que não existe um subconjunto preciso de conhecimento que sempre será suficiente para passar em todas as primeiras entrevistas possíveis.

• Cada empresa tem sua própria pilha de tecnologia desajeitada

• Cada PM tem sua própria versão de “ágil”

• Cada gerente de contratação tem seu próprio processo de entrevista em 7 etapas

• Cada trabalho requer diferentes pedaços de conhecimento misterioso

  
  

Você não tem ideia do que fará no dia a dia em seu primeiro emprego quando começar a aprender a programar. Ouço pessoas dizerem coisas como: “Nunca uso minhas habilidades de DSA no trabalho” e, após uma inspeção mais aprofundada, descobri que são “desenvolvedores” de WordPress.

Então, eu não deveria estar interessado no caminho mais curto?

Você deve; simplesmente não está onde você acha que o encontrará. O caminho mais curto para um trabalho como programador não envolve minimizar a quantidade de coisas que você precisa aprender e construir. Esse tipo de pensamento resulta em uma jornada muito mais longa e mentalmente exaustiva. Algo assim:

1. Vá diretamente para uma estrutura da web (provavelmente Next.js, já que você é básico).
2. Descubra que você tem talento para criar aplicativos TODO
3. Perceba que você não pode construir um “olá mundo” sem um tutorial
4. Tente remediar isso fazendo mais tutoriais
5. Leia no Twitter que ackshaully Rust é a melhor linguagem
6. Admita a derrota nas mãos do verificador de empréstimo
7. Repita as etapas 1 a 4 n vezes, onde n é d4_roll * your_stubbornness

O caminho mais curto (ou pelo menos um caminho mais curto) geralmente se parece com isto:

1. Aprenda conceitos básicos de programação/CS em alguma linguagem

2. Decida provisoriamente o tipo de programação que você deseja fazer (frontend, backend, mobile, etc.)

3. Aprenda os fundamentos desse tipo de programação em tecnologias adequadas para isso

4. Nunca pare de aprender e construir enquanto procura um emprego

   
   

Não me entenda mal, esse segundo caminho ainda não é curto. Programar não é fácil; desculpe se lhe disseram que sim, mas se você estiver disposto a se esforçar, poderá evitar um passeio sem rumo pelo 9º círculo do inferno tutorial.

Não tenha medo do trabalho

As pessoas passam eras tentando encontrar o caminho de aprendizagem mais curto ou tentando evitar aprender coisas que “nunca mais usarão”. Elas ficam bem em perder meses ou anos aprendendo absolutamente nada para evitar qualquer trabalho desnecessário. arriscar passar alguns dias aprendendo algo que não é diretamente aplicável ao trabalho que você eventualmente conseguirá?

Dogecoin para a lua?

Sejamos 100000000% honestos. Algumas pessoas estão procurando um bom e velho esquema para enriquecimento rápido. Depois de algumas semanas lutando com loops, eles desistirão e comprarão um bot de negociação de criptografia com tecnologia de IA no Fiverr. Não seja como essas pessoas.

Tornar-se um engenheiro de software NÃO é um esquema de “enriquecimento rápido”. É um esquema de "obter a classe média alta lenta"

O truque para "conseguir"? Você tem que realmente ficar bom.

Portanto, em vez de copiar/colar aleatoriamente do StackOverflow para "consertar" o próximo erro que encontrar, reserve alguns minutos extras para descobrir o que isso significa . Não consigo dizer quantos PRs revisei que "consertam" algo, mas são apenas um patch de patch porque o desenvolvedor nunca grocou o problema subjacente.

Por exemplo, um ex-desenvolvedor Java (é sempre um desenvolvedor Java) descobre que às vezes esta função (em Go) entra em pânico:

 // sendEmail sends emails, but sometimes panics func sendEmail(e *email) error { // ... }

Eles vão direto ao Google e descobrem que o pânico no Go pode ser “resolvido” com um recover . Então, eles abrem uma solicitação pull:

 func sendEmail(e *email) error { defer func() { if r := recover(); r != nil { log.Println("recovered from panic in sendEmail") } }() // ... }

Isso meio que funciona? No entanto, um desenvolvedor melhor tentaria compreender e corrigir o problema subjacente no código. Eles adicionariam verificações nil ou simplesmente parariam de usar ponteiros para esta função ...

 // now sendEmail never panics func sendEmail(e email) error { // ... }

Você quer ter uma tendência para se tornar melhor, não para chegar ao fim. Não existe um “fim”. Há muito para aprender. O escopo de toda a engenharia de software é maior que o escopo do namespace global do seu último programa.

Não é o conselho que você queria

Ficar em forma, abandonar o vício, construir um negócio e, sim, conseguir seu primeiro emprego como desenvolvedor são coisas difíceis . Não torne as coisas mais difíceis para você mesmo, desperdiçando seu tempo procurando atalhos.

Aprenda coisas fundamentais perenes, construa projetos que lhe interessem e você ficará surpreso com o quão longe você pode chegar em apenas um ou dois anos de esforço consistente.

Também publicado aqui .