Desde que inicié Boot.dev , me han inundado lo que yo llamo "preguntas de arenas movedizas". Superficialmente, una pregunta sobre arenas movedizas parece una buena pregunta. Si pudieras responderla, te catapultaría desde donde estás (turno de noche en el autocine de Wendy's) hasta donde quieres estar (contarles a tus amigos que trabajas en Netflix por cierto).
Las preguntas sobre arenas movedizas tienen que ver con encontrar atajos.
Necesito un trabajo de desarrollador en 3 meses; ¿Cuál es la mejor manera de hacer eso?
Veo que has establecido 20 cursos en tu ruta de aprendizaje backend, pero *guiño* ¿cuáles puedo omitir?
Ahora quiero ser claro : no hay absolutamente nada de malo en querer tomar un camino más corto hacia su objetivo profesional. Cualquier otra cosa sería una locura. Si hubiera una pastilla que te convirtiera en un desarrollador senior de la noche a la mañana, te animo a que la tomes.
En teoría, el min-maxing educativo parece una estrategia sólida, pero simplemente no funciona en la práctica.
¿Por qué? Porque se desconoce el destino.
El algoritmo de Dijkstra es excelente si sabes adónde vas. Si no lo haces, necesitas algo más.
La escena tecnológica es un caos de complejidad. Aprendí como diez lenguajes de programación diferentes en la universidad, e incluso tres años después de graduarme, todavía no sabía que terminaría trabajando como ingeniero backend escribiendo Go.
Me entrevisté para todo tipo de tonterías, desde sistemas integrados hasta desarrollo front-end. Sí, resulta que mi clase de Prolog no me ayudó mucho en mi primera entrevista, pero ¿sabes qué? No me dolió , y ahora, cuando alguien dice: "Es un sistema declarativo", mi expresión facial no delata ignorancia.
Si supiera exactamente qué conceptos necesitaría dominar para aprobar su primera entrevista, entonces podría encontrar un atajo eficaz. El problema es que no existe un subconjunto preciso de conocimientos que siempre sea suficiente para aprobar todas las primeras entrevistas posibles.
Cada empresa tiene su propia pila tecnológica descabellada
Cada PM tiene su propia versión de "ágil"
Cada gerente de contratación tiene su propio proceso de entrevista de 7 pasos
Cada trabajo requiere diferentes conocimientos arcanos
No tienes idea de lo que harás día a día en tu primer trabajo cuando empieces a aprender a codificar. Escucho a personas decir cosas como: "Ni siquiera uso mis habilidades de DSA en el trabajo" y, tras una inspección más detallada, resulta que son un "desarrollador" de WordPress.
Debería; simplemente no está donde crees que lo encontrarás. El camino más corto hacia un trabajo como programador no implica minimizar la cantidad de cosas que necesitas aprender y construir. Ese tipo de pensamiento resulta en un viaje mucho más largo y mentalmente más agotador. Algo como esto:
n
veces, donde n
es d4_roll * your_stubbornness
El camino más corto (o al menos un camino más corto) suele tener este aspecto:
Aprenda conceptos básicos de programación/CS en algún idioma.
Decide tentativamente el tipo de programación que quieres hacer (frontend, backend, móvil, etc.)
Aprenda los fundamentos de ese tipo de programación en tecnologías adecuadas para ello.
Nunca dejes de aprender y construir mientras buscas trabajo
No me malinterpretéis, este segundo camino todavía no es corto. La programación no es fácil; Lo siento si te lo dijeron, pero si estás dispuesto a esforzarte, puedes evitar un paseo sin rumbo por el noveno círculo del infierno tutorial.
Las personas pasan eones tratando de encontrar el camino de aprendizaje más corto o tratando de evitar aprender cosas que "nunca volverán a usar". Están bien desperdiciando meses o años aprendiendo absolutamente nada para evitar hacer trabajos innecesarios. ¿Por qué no hacer de tripas corazón y ¿Te arriesgas a pasar unos días aprendiendo algo que no es directamente aplicable al trabajo que eventualmente conseguirás?
Seamos 100000000% honestos. Algunas personas están buscando un buen plan tradicional para hacerse rico rápidamente. Después de algunas semanas de luchar con los bucles, se darán por vencidos y comprarán un robot de comercio de cifrado impulsado por IA en Fiverr. No seas como esa gente.
Convertirse en ingeniero de software NO es un plan para "hacerse rico rápidamente". Es un plan de "consecución lenta de la clase media alta"
¿El truco para "lograrlo"? Tienes que volverte realmente bueno.
Entonces, en lugar de copiar y pegar al azar desde StackOverflow para "corregir" el siguiente error que encuentre, tómese unos minutos adicionales para descubrir qué significa . No puedo comenzar a decirles cuántos RP he revisado que "solucionan" algo, pero son solo un parche de un parche porque el desarrollador nunca asimiló el problema subyacente.
Por ejemplo, un ex desarrollador de Java (siempre es un desarrollador de Java) descubre que a veces esta función (en Go) entra en pánico:
// sendEmail sends emails, but sometimes panics func sendEmail(e *email) error { // ... }
Van directamente a Google y descubren que el pánico en Go se puede "resolver" con una recover
. Entonces, abren una solicitud de extracción:
func sendEmail(e *email) error { defer func() { if r := recover(); r != nil { log.Println("recovered from panic in sendEmail") } }() // ... }
¿Esto funciona? Sin embargo, un mejor desarrollador intentaría comprender y solucionar el problema subyacente en el código. Agregarían controles nil
o simplemente dejarían de usar punteros para esta función...
// now sendEmail never panics func sendEmail(e email) error { // ... }
Quieres tener una tendencia a mejorar, no a llegar al final. No hay un "fin". Simplemente hay demasiado por aprender. El alcance de toda la ingeniería de software es mayor que el alcance del espacio de nombres global de su último programa.
Ponerse en forma, abandonar la adicción, construir un negocio y, sí, conseguir su primer trabajo de desarrollo son cosas difíciles . No te lo pongas más difícil perdiendo el tiempo buscando atajos.
Aprenda temas fundamentales de hoja perenne, cree proyectos que le interesen y se sorprenderá de lo lejos que puede llegar en solo uno o dos años de esfuerzo constante.
También publicado aquí .