Il n'y a pas de raccourci pour obtenir un emploi de développeur : apprenez à coder lentement

Depuis le démarrage de Boot.dev , j'ai été inondé de ce que j'appelle des « questions de sable mouvant ». En apparence, une question de sable mouvant semble être une bonne question. Si vous pouviez y répondre, cela vous catapulterait d'où vous êtes (équipe de nuit au ciné-parc Wendy's) à là où vous voulez être (dire à vos amis que vous travaillez chez Netflix d'ailleurs).

Les questions Quicksand consistent uniquement à trouver des raccourcis.

J'ai besoin d'un emploi de développeur dans 3 mois ; quelle est la meilleure façon de procéder ?

Je vois que vous avez prévu 20 cours dans votre parcours d'apprentissage back-end, mais *clin d'œil*, lesquels puis-je ignorer ?

Quel est le problème avec les raccourcis ?

Maintenant, je veux être clair : il n’y a absolument rien de mal à vouloir emprunter un chemin plus court vers votre objectif de carrière. Tout le reste serait de la folie. S'il existait une pilule pour faire de vous un développeur senior du jour au lendemain, je vous encouragerais à l'utiliser.

En théorie, le min-maxing éducatif semble être une stratégie solide, mais cela ne fonctionne tout simplement pas dans la pratique.

Pourquoi? Parce que la destination est inconnue .

L'algorithme de Dijkstra est génial si vous savez où vous allez. Si ce n'est pas le cas, vous avez besoin d'autre chose.

Personne ne sait où ils vont

La scène technologique est un véritable concentré de complexité. J'ai appris dix langages de programmation différents à l'université, et même après trois ans d'études, je ne savais toujours pas que je finirais par travailler comme ingénieur back-end pour écrire Go.

J'ai passé des entretiens pour toutes sortes d'absurdités, des systèmes embarqués au développement front-end. Ouais, il s'avère que mon cours Prolog n'a pas beaucoup aidé lors de mon premier entretien, mais vous savez quoi ? Cela ne m'a pas fait de mal , et maintenant, quand quelqu'un dit : « C'est un système déclaratif », mon expression faciale ne trahit pas l'ignorance.

Si vous saviez exactement quels concepts vous deviez maîtriser pour réussir votre premier entretien, vous pourriez alors trouver un raccourci efficace. Le problème est qu’il n’existe pas de sous-ensemble précis de connaissances qui suffiront toujours à réussir chaque premier entretien possible.

• Chaque entreprise a sa propre pile technologique déjantée

• Chaque PM a sa propre version de "agile"

• Chaque responsable du recrutement a son propre processus d'entretien en 7 étapes

• Chaque travail nécessite différents éléments de connaissances obscures

  
  

Vous n'avez aucune idée de ce que vous ferez au quotidien lors de votre premier emploi lorsque vous commencerez à apprendre à coder. J'entends des gens dire des choses comme : « Je n'utilise même jamais mes compétences DSA au travail », et après une inspection plus approfondie, il s'avère qu'ils sont un « développeur » WordPress.

Alors, je ne devrais pas m'intéresser au chemin le plus court ?

Tu devrais; ce n'est tout simplement pas là où vous pensez le trouver. Le chemin le plus court vers un emploi de programmeur n’implique pas de minimiser la quantité de choses que vous devez apprendre et construire. Ce genre de réflexion se traduit par un voyage beaucoup plus long et mentalement plus épuisant. Quelque chose comme ça:

1. Accédez directement à un framework Web (probablement Next.js puisque vous êtes basique).
2. Découvrez que vous avez un talent pour créer des applications TODO
3. Réalisez que vous ne pouvez pas créer un « hello world » sans un didacticiel
4. Essayez de remédier à cela en faisant plus de tutoriels
5. Lisez sur Twitter que Rust est sans aucun doute le meilleur langage
6. Admettre la défaite face au vérificateur d'emprunt
7. Répétez les étapes 1 à 4 n fois, où n est un d4_roll * your_stubbornness

Le chemin le plus court (ou du moins un chemin plus court) ressemble généralement à ceci :

1. Apprendre les concepts de programmation/CS de base dans certains langages

2. Décidez provisoirement du type de programmation que vous souhaitez effectuer (frontend, backend, mobile, etc.)

3. Apprenez les fondamentaux de ce type de programmation dans des technologies bien adaptées

4. N'arrêtez jamais d'apprendre et de construire pendant que vous recherchez un emploi

   
   

Ne vous méprenez pas, ce deuxième chemin n’est toujours pas court. La programmation n'est pas facile ; désolé si on vous l'a dit, mais si vous êtes prêt à faire l'effort, vous pouvez éviter une promenade sans but dans le 9ème cercle de l'enfer des tutoriels.

N'ayez pas peur du travail

Les gens passent des éternités à essayer de trouver le chemin d'apprentissage le plus court ou à éviter d'apprendre des choses qu '«ils n'utiliseront plus jamais». Ils perdent des mois ou des années sans rien apprendre pour éviter de faire un travail inutile. Pourquoi ne pas serrer les dents et risquer de passer quelques jours à apprendre quelque chose qui n'est pas directement applicable à l'emploi que vous décrocherez éventuellement ?

Dogecoin vers la lune ?

Soyons honnêtes à 100000000%. Certaines personnes recherchent un bon vieux plan pour devenir riche rapidement. Après quelques semaines de lutte contre les boucles, ils abandonneront et achèteront un robot de trading crypto alimenté par l'IA sur Fiverr. Ne soyez pas comme ces gens-là.

Devenir ingénieur logiciel n’est PAS un programme pour « devenir riche rapidement ». C'est un plan pour "obtenir lentement la classe moyenne supérieure".

L’astuce pour « réussir » ? Il faut vraiment devenir bon.

Ainsi, au lieu de copier/coller au hasard depuis StackOverflow pour « corriger » la prochaine erreur que vous rencontrez, prenez les minutes supplémentaires pour comprendre ce que cela signifie . Je ne peux pas commencer à vous dire combien de PR j'ai examinés qui "corrigent" quelque chose, mais ne sont qu'un patch d'un patch car le développeur n'a jamais détecté le problème sous-jacent.

Par exemple, un ancien développeur Java (c'est toujours un développeur Java) constate que parfois cette fonction (dans Go) panique :

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

Ils vont directement sur Google et découvrent que la panique dans Go peut être « résolue » avec un recover . Alors, ils ouvrent une pull request :

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

Ça marche un peu ? Cependant, un meilleur développeur essaierait de comprendre et de résoudre le problème sous-jacent dans le code. Ils ajouteraient des vérifications nil , ou cesseraient simplement d'utiliser des pointeurs pour cette fonction...

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

Vous voulez avoir un penchant pour devenir meilleur, et non pour atteindre la fin. Il n’y a pas de « fin ». Il y a tout simplement trop de choses à apprendre. La portée de l'ensemble de l'ingénierie logicielle est plus grande que la portée de l'espace de noms global de votre dernier programme.

Ce n'est pas le conseil que tu voulais

Se mettre en forme, abandonner sa dépendance, créer une entreprise et, oui, obtenir son premier emploi de développeur sont tous des tâches difficiles . Ne vous compliquez pas la tâche en perdant votre temps à chercher des raccourcis.

Apprenez des éléments de base permanents, construisez des projets qui vous intéressent et vous serez étonné de voir jusqu'où vous pouvez aller en seulement un an ou deux d'efforts constants.

Également publié ici .