Cómo conseguir un trabajo de desarrollador en menos de un año

Acelere su aprendizaje

¿Cuál es la parte más difícil para alguien que decide aprender a programar por sí mismo? El hecho de que normalmente no saben qué aprender: qué lenguaje de programación elegir, cómo abordar el aprendizaje, qué recursos son los mejores en términos de eficiencia de tiempo.

Todo comienza con las búsquedas de Google sobre esos temas, que inevitablemente llevan a las personas a uno de los muchos recursos que les enseñan a codificar. El formato de esos recursos varía enormemente y el sentido común nos dice que debemos probar un montón de recursos diferentes y elegir los que mejor se adapten a nuestro estilo de aprendizaje. Tutoriales para algunas personas, screencasts para otras, artículos para otro grupo, etc. Parece bastante lógico, ¿no?

Bueno no. Hoy quiero convencerte de que uno de esos formatos de aprendizaje te llevará a donde quieres llegar más rápido que cualquier otro. Sin más demora, déjame decirte qué es y por qué debes concentrar todos tus esfuerzos en él.

Proyectos de construcción

Apuesto a que lo viste venir.

En primer lugar, permítame aclarar algunas de sus objeciones. No estoy diciendo que debas abandonar todos los otros tipos de recursos de aprendizaje por completo.

Todos los tutoriales y screencasts tienen su lugar bajo el sol, y lo explicaré más adelante en el artículo. Por ejemplo, a veces la forma más eficaz de familiarizarse con una nueva tecnología o un marco puede ser leer un artículo o seguir un tutorial.

El problema es que tendemos a ceñirnos (o al menos yo lo hago) a los recursos que nos mantienen en nuestra zona de confort, incluso cuando es el momento de hacer algo por nuestra cuenta. Es demasiado conveniente, listo para el consumo. También siempre nos hace sentir muy bien, porque oye, ¡aquí estamos, aprendiendo! ¿Correcto? ¿Quién puede decir que estamos perdiendo el tiempo? ¿Cómo se atreven? ¡Estamos llenando los vacíos en nuestro conocimiento!

Es peligroso que nos parezca que estos recursos también son la forma más eficaz de aprender. Como seres humanos, podemos justificar prácticamente cualquier cosa que nos mantenga dentro de nuestra zona de confort. He estado viviendo en esa ilusión durante bastante tiempo.

Toc, toc, Neo.

Creando proyectos… ¿qué hay de nuevo en esta idea? Nada, y en el fondo, todos sabemos que sería el mejor uso de nuestro tiempo y energía, y nos llevaría a nuestras metas más rápido. Entonces, ¿por qué no lo hacemos? Resistencia.

He hablado sobre la Resistencia en mi artículo anterior (léelo si estás luchando o si te sientes atascado), así que déjame explicarte por qué soy tan inflexible sobre este tema y déjame convencerte de que cambies tu enfoque (a menos que sea ya allí) al edificio.

Al igual que Neo en Matrix, a quien se le da a elegir entre la pastilla roja y la pastilla azul, podemos volver a nuestras ilusiones de que los recursos que están sosteniendo nuestra mano todo el tiempo son la mejor forma de aprender, o podemos tomar la roja. píldora y aceptar la realidad de que solo avanzamos y crecemos cuando estamos fuera de nuestra zona de confort. (Si no ha visto Matrix, probablemente debería hacerlo).

Estos son algunos de mis pensamientos sobre cómo abordar estos proyectos, que pueden ser intimidantes para comenzar, así como algunos consejos que he aprendido a lo largo del camino.

Puede que te lleve incluso menos de un año (¿Qué?)

El razonamiento detrás de esto es que se basa en mi experiencia personal, en hablar con los miembros de nuestro grupo Free Code Camp Toronto y en leer sobre los viajes de los miembros en todo el mundo.

Encuentro que la mayoría de las veces, las personas pueden encontrar un trabajo incluso antes de terminar la certificación de Desarrollo Front End de Free Code Camp. Construyen los proyectos necesarios y comienzan a aplicar. Muy pronto, reciben una oferta para codificar por dinero.

Si lee el subreddit de Free Code Camp, encontrará que hay muchas historias como esa.

Tenga en cuenta que los mercados laborales varían de una ciudad a otra. En Toronto, por ejemplo, hay un montón de puestos vacantes para desarrolladores front-end.

La posición oficial de Free Code Camp es que debe completar las 2080 horas del plan de estudios. Probablemente será un candidato mucho más fuerte (y obtendrá salarios más altos en puestos más desafiantes) si lo hace.

Hagamos algunas matemáticas:

El certificado de desarrollo web front-end con Free Code Camp tarda alrededor de 478 horas. Hay personas que lo completan más rápido, pero varía según el nivel de preparación de la persona, así que mantengamos 478 como nuestra base.

¿Qué es menos de un año? Por el bien del argumento, trabajaremos con 9 meses. 9 meses * 30 días nos da 270 días.

478 horas / 270 días es aproximadamente 1,8 horas por día. Eso significa que podemos codificar menos de 2 horas al día y en 9 meses podemos estar listos para trabajar.

Sé que para algunas personas el horario no permite dos horas libres al día, pero para la mayoría es posible encontrarlas. Para otros, puede llevar un poco más de tiempo, pero siempre hay fines de semana y otras formas de encontrar (o aprovechar) el tiempo.

Si está buscando un consejo sobre cómo encontrar tiempo para codificar, no dude en comunicarse conmigo en Twitter y estaré encantado de ayudarlo.

Tardé un poco más que eso, alrededor de un año y dos meses. Este artículo es el análisis de las razones por las que tardé más de lo debido. He cometido todos los errores de los que hablo en el artículo. Cuando le doy un consejo, recuerde que yo también me lo doy a mí mismo. Estamos en el mismo bote.

Me contrataron antes de que pudiera terminar el plan de estudios de Free Code Camp Front End, pero sé con certeza que me ayudará a crecer como desarrollador para volver y terminar esos proyectos. Aquí, en el artículo, he colocado enlaces a mi perfil de Codepen (¡estoy un poco avergonzado de él!) Y cuando lo mires, verás que todavía me queda un largo camino por recorrer. Así que digo: ¡hagámoslo juntos! Mi objetivo es terminar todos los proyectos de Front End y convertirlos en mi prioridad sobre cualquier otra cosa relacionada con el código que aprenda en un futuro próximo.

Este artículo es para mí y para ti, para hacernos superar la incomodidad y optimizar nuestro aprendizaje para que podamos llegar a donde queremos llegar más rápido.

Asegúrese de haber cubierto sus conceptos básicos

Creo firmemente que al comienzo de su aprendizaje, definitivamente debe usar tutoriales y recursos interactivos en línea para familiarizarse con la sintaxis de HTML, CSS, JavaScript, para aprender a pensar de manera programática y sentirse cómodo con las cosas básicas y esenciales.

Un intento de construir proyectos de inmediato sin ese conocimiento sería demasiado frustrante. Asegúrese de no pasar demasiado tiempo en esta etapa, ya que es muy fácil de hacer.

Cuando estaba aprendiendo HTML / CSS / JS, iba y aprendía temas similares de diferentes recursos, pensando que de alguna manera eso llenaría todos los vacíos en mi conocimiento. Sí llenó algunos vacíos, pero en algún momento me di cuenta de que estaba usando estos recursos como una muleta para evitar que me cambiara a cosas nuevas, más emocionantes, pero un poco más aterradoras. No se quede atascado en bucles interminables (¿probablemente un bucle while?;) De revisar y volver a visitar la información que ya conoce.

No cedas a la racionalización

Cuando comience a crear proyectos, inevitablemente se quedará atascado. Si te mantienes firme, después de un tiempo superarás la barrera, pero poco después chocarás con otra. No es una opción y les pasa a todos.

En esos momentos, cada parte de nuestro cuerpo está gritando: hagamos otra cosa, salgamos corriendo de aquí, esto me hace sentir incómodo, puedo abordar esto más tarde cuando sepa más, volveré a eso, y así sucesivamente. Así que hacemos una pausa.

Sin embargo, tememos que nuestra pausa se estire y simplemente continuaremos codificando cada vez menos y soltándolo. Para no dejar que eso suceda, pero manteniendo nuestra “decisión” de no trabajar en el proyecto, decidimos que por ahora trabajaremos a través de algún tutorial o un curso online.

Es muy fácil racionalizar la creación. Nadie te dirá que no estás aprendiendo a codificar o te criticará de ninguna manera por hacer eso. Usted es el único que puede identificar lo que realmente está pasando (miedo, aversión al riesgo, resistencia) y tomar la decisión de seguir trabajando en el proyecto.

Créame, todas las paredes se derrumbarán si las golpea el tiempo suficiente. Piense en las personas que, en el pasado, estaban aprendiendo idiomas extranjeros al tener dos copias del mismo libro en sus idiomas nativos y de destino. ¿Cómo lo hicieron? Simplemente se quedaron con eso el tiempo suficiente.

No empieces con tu GRAN IDEA

Es sorprendente que ya lo tenga, pero hay algunas otras consideraciones en juego aquí que pueden hacerle cambiar de opinión. La razón por la que menciono este punto es que sigo escuchando esto de la gente: “Quiero crear una aplicación en línea que permita a las personas crear cuentas para sus mascotas, cargar fotos, rastrear ubicaciones y muchas otras cosas. Recientemente comencé a aprender a codificar y ya estoy en el proceso de desarrollar mi idea ". Esto me hace decir "Whoa whoa whoa".

Lo que puedo ver fácilmente que sucede en esta situación es que una persona se compromete demasiado con la idea, comienza con mucho entusiasmo y la desarrolla lentamente, pero a medida que pasa el tiempo, su aprendizaje no puede seguir el ritmo de las demandas del proyecto, y se siente arrastrando, siempre en el fondo de su mente, sin terminar.

Lo peor que puede pasar en esta situación es que la persona se dé por vencida en el proyecto y con él también en la codificación.

Recomiendo comenzar con proyectos simples y, a medida que termine cada uno de ellos, obtendrá una sensación de logro y una mejor comprensión de cómo estructurar un proyecto más grande.

Imagina que eres escritor y tienes una idea para un libro importante de tu vida y has comenzado a escribirlo de inmediato. Probablemente tendría que reescribirlo todo de 3 a 4 veces para conseguir un nivel de calidad decente, mientras que podría comenzar escribiendo pequeñas historias, obtener comentarios, mejorar su escritura y acercarse a Moby Dick cuando esté realmente listo.

Dónde obtener ideas para proyectos

El mejor lugar que conozco es Free Code Camp. Eso es lo que usé después de estar completamente atascado. Al comienzo de mi viaje de codificación, preguntaba a todos los desarrolladores que conocía (tanto en línea como fuera de línea) cuál debería ser mi primer proyecto. No bromeo cuando digo (sorpresa sorpresa) todos dijeron que debería ser una aplicación de lista de tareas pendientes. Honestamente, creo que si seguimos creando estas aplicaciones de listas de tareas pendientes, pronto saturarán todo Internet.

Free Code Camp me ayudó en el sentido de que me proporcionó una lista de proyectos emocionantes, alineados en una secuencia de dificultad creciente. Otra gran cosa es que cada uno de ellos está diseñado específicamente para enseñarle un tema específico, por ejemplo: una página de tributo pondrá a prueba sus habilidades HTML / CSS, Show the Local Weather le enseñará a trabajar con API, construir un JavaScript La calculadora, obviamente, mejorará tus habilidades de JS, etc.

Es el punto de partida más fuerte que conozco para que empieces a construir. Para todos los proyectos que termines, puedes obtener comentarios de la comunidad, así como ver cómo otros se han acercado a ellos (después de que hayas creado el tuyo, ¡no hagas trampas!) Para inspiración adicional, siempre puedes buscar en Google una "lista de ideas geniales para proyectos de código". ”O algo por el estilo.

Primero estructura tu proyecto

Antes de comenzar a construir, escriba lo que quiere que haga. Haga que se escriban historias de usuarios específicas, por ejemplo: "Los usuarios pueden reproducir audio cuando hacen clic en el botón del reproductor de audio", "Los usuarios pueden iniciar sesión con su correo electrónico y contraseña, así como simplemente usando Facebook".

Su código también debe tener una estructura básica antes de comenzar a escribirlo. Escriba en pseudocódigo: básicamente, explique en palabras lo que hará cada parte de la aplicación o el código del proyecto.

Ejemplo básico:

// Cuando el usuario abre una página, toma su ubicación

// Envía una solicitud al sitio de la API meteorológica con la ubicación

// Recibir datos

// Mostrar los grados en la página

// Cambiar la imagen de fondo de la página para reflejar el clima actual

No exagere, no hay necesidad de escribir primero todo lo que su código hará en pseudocódigo, pero tenga las partes principales establecidas.

El mejor ejemplo que puedo darte es: recuerda que cuando estabas escribiendo ensayos en la escuela, primero tenías que estructurarlos, por ejemplo, una introducción con tu opinión sobre el tema, 3 puntos principales que respaldan tu opinión y una conclusión. .

Esto le ayudará a anticipar problemas potenciales y mejorar la calidad de su código.

Está bien quedarse atascado

Como mencioné antes, está bien quedarse atascado. No significa que seamos estúpidos, solo significa que aún no lo sabemos. Siempre experimentarás los momentos de estancarte: no solo cuando estás aprendiendo, sino también en el trabajo.

Cuanto antes te sientas cómodo sintiéndote incómodo, mejor. Hará que tu progreso sea mucho más rápido. La programación en sí misma es la resolución creativa de problemas. Si no hay problemas que le resulten difíciles de resolver, significa que está jugando a lo seguro. ¡Deja de pisar aguas poco profundas y zambúllete!

Sobre todo, y lo repetiré de nuevo, no te consideres estúpido. Sé que es fácil de hacer en estos momentos. A menudo hablo con personas que pasaron por la parte HTML / CSS / JS de Free Code Camp con facilidad, eliminando de 30 a 40 elementos por día, y luego llegan a los algoritmos básicos e intermedios y descubren que solo pueden hacer 1– 5 al día, por lo que llegan a la conclusión de que se estancaron y que son estúpidos, que no son lo suficientemente buenos o que no están destinados a ser desarrolladores.

Yo también estaba de la misma manera, sentí que probablemente hay personas que simplemente pasan volando por esta sección y me sentí mal conmigo mismo y con mi progreso. Ahora lo sé mejor.

Lo que estoy tratando de decir aquí es que debes aprender a:

Estar sobre tu cabeza

Tienes que encontrar ese nivel de dificultad del proyecto que te mantenga justo en el medio entre las "cosas que son fáciles" y las "cosas que todavía son demasiado difíciles".

He hablado mucho sobre las razones por las que es peligroso seguir revisando y volviendo a aprender el mismo material (las cosas fáciles), así que hablemos del lado opuesto de la ecuación: las cosas difíciles.

Su regla general cuando se acerca a algo difícil, algo que cree que no podrá hacer, debe ser intentar hacerlo primero.

Empiece por la estructura básica e intente codificarla. Si está atascado en lo mismo durante más de tres días de concentrarse en él, déjelo por un tiempo y encuentre cosas similares, pero un poco más fáciles, que hacer.

Lo que encuentro es que después de hacer eso, mi mente subconsciente todavía está enfocada en resolver el problema en el que me quedé atrapado. Tengo estas ideas aleatorias sobre cómo podría resolverlo cuando estoy haciendo cosas simples, como tomar una ducha o lavar los platos, ¡de repente me doy cuenta!

A veces funciona exactamente de esa manera. A veces no es así. Pero el consejo principal aquí es: elige siempre algo que te haga sentir un poco incómodo . Cualquier otra cosa no vale la pena.

Resiliencia

Quiero compartir contigo una de mis palabras favoritas absolutas:

Resiliencia : la capacidad de un sistema para tolerar perturbaciones sin colapsar, para resistir golpes, para reconstruirse cuando sea necesario y para mejorarse cuando sea posible.

Esta es una cualidad asombrosa en la que usted, como programador (y como persona que busca triunfar en la vida) debe trabajar en desarrollar en sí mismo. Prepárese para todos los problemas, todos los desafíos, todas las críticas a su trabajo, a sus diseños, a sus soluciones y cualquier otra cosa que pueda hacer incluso antes de que sucedan.

¿Tienes miedo de estar en el escenario? Regístrese para enseñar a las personas de su comunidad local los conceptos básicos del desarrollo web, o regístrese para hablar en una conferencia / evento tecnológico.

¿Está decepcionado de cómo fue su entrevista y de que no lo contrataron después? ¿Tiene miedo de que sea demasiado tarde para empezar a aprender a codificar? ¿No estás contento con el proyecto que acabas de terminar?

Replantee todo esto : ¿qué puede aprender de la experiencia para mejorarla la próxima vez? ¿Cómo puedes convertir tus debilidades en fortalezas?

Por ejemplo, es posible que le preocupe llegar a la codificación demasiado tarde después de haber estado en otra carrera durante X años. Replantee eso en su mente, pensando en una perspectiva y madurez diferente que traerá a la industria que necesita desesperadamente personas más maduras (psicológicamente) y con antecedentes más diversos. ¡Estás enriqueciendo a la industria de la tecnología con la sola decisión de entrar en ella!

Si escuchas una voz dentro de ti que dice 'no puedes pintar', entonces pinta, y esa voz será silenciada. - Vincent Van Gogh

Lo que puedo recomendar para aumentar su resiliencia son estos tres libros:

  1. "Cartas de un estoico" de Séneca
  2. "El obstáculo es el camino" de Ryan Holiday
  3. "Turning Pro" de Steven Pressfield

Establezca una meta diaria con un límite de tiempo

Para progresar más rápido, debe trabajar en sus proyectos todos los días. Esa parte es solo sentido común. Sin embargo, hay algunas consideraciones adicionales que debe tener en cuenta.

En lugar de establecer un objetivo de resultado ("Terminaré esta función o esa parte hoy"), establezca un período definido de tiempo que dedicará a codificar todos los días. No lo haga más de 30 minutos o una hora por día.

Sé que desea comprometerse a codificar durante 3 horas al día y tratar de cumplirlo. Esto funciona, pero solo durante un tiempo, hasta que la vida entra en juego. Con un límite de tiempo razonable, como 30 minutos al día, siempre sabrá que se puede hacer y que siempre tendrá media hora al día libre para programar, especialmente si su objetivo principal es aprender a codificar. Incluso te encontrarás codificando más en ciertos días, y eso se sentirá genial, porque ya habrás cumplido con tu cuota para ese día.

Este límite de tiempo es más un truco psicológico que funciona debido a la forma en que nuestros cerebros están conectados. ¿Recuerda aquella vez que tenía un gran proyecto que necesitaba comenzar, pero siguió demorando y demorando hasta que tuvo tiempo suficiente para terminarlo antes de la fecha límite? Lo hizo bien, pero estaba estresado todo el tiempo antes de eso. Luego agregue a esto el hecho de que no hay nadie que le ponga una fecha límite para convertirse en desarrollador. Es decir, nadie más que tú.

Lo que sucede cuando establecemos un objetivo de resultado es que no podemos estimar el tiempo que tomará terminar esa o esta función. Y la mayoría de las veces, terminamos sin lograr lo que nos propusimos hacer durante el día. Eso nos hace sentir muy mal y disminuye el deseo de sentarnos y programar al día siguiente.

Con un objetivo diario de tiempo limitado, progresará todos los días. ¿A quién le importa si no ha terminado esa función específica que quería terminar hoy? ¡Has progresado! Apareciste. Eso es lo que te lleva adelante.

Otra gran ventaja es que una vez que te sientas y comienzas a codificar, las ideas y soluciones comenzarán a fluir, como si salieran de la nada (similar a escribir un artículo, ¿eh? :). Será mucho más fácil sentarse y codificar una vez que haya eliminado las expectativas y los miedos poco realistas.

Copiar código es una pérdida de tiempo

Durante el proceso de construcción de un proyecto, ya sea al principio, cuando no sabe por dónde empezar, o en una etapa posterior cuando se encuentra con un problema que no puede resolver fácilmente, experimentará un fuerte deseo de buscar en el código fuente del proyecto para ver cómo se hace. Racionalizará que le hará comprender instantáneamente el código, y eso significa que lo ha aprendido y asimilado. Lejos de ahi.

No copie proyectos completos y personalícelos. No tome partes del código. Ni siquiera tomes pedazos.

Con proyectos, no mire el código en primer lugar. Con las cosas que buscó en Stack Overflow y demás, mírelas, analícelas, comprenda, pero luego codifíquelas usted mismo desde cero. Verá que es difícil escribirlo usted mismo incluso después de haberlo visto todo.

Así es como la práctica deliberada se diferencia de la práctica regular (repetición). El principal problema de la regla de los 10,000 es que la práctica debe ser deliberada. Las siguientes plantillas y soluciones listas para usar no lo llevarán a ninguna parte. Alguien probablemente podría escribir un script de Python que lo reemplazará en lo que sea que esté haciendo, si va por ese camino. Presta atención a lo que te parezca difícil.

Otra idea fuera del tema es que si tiene dificultades con un tema en particular, intente enseñárselo a los demás o simplemente explicárselo de la manera que lo entiende. Los resultados seguirán tanto para usted como para los alumnos.

Copiar código le robará la oportunidad de aprender a hacerlo usted mismo, y de ninguna manera es mejor que seguir un tutorial. Sí, la solución está ahí. Sí, puede tomarlo si lo desea. Pero cual es el punto? ¿Estás intentando impresionar a alguien con la velocidad con la que has construido el proyecto? ¿O está tratando de evitar los problemas difíciles que llevará algún tiempo resolver?

Cualquiera que sea su razón, es solo otro camino de regreso al cálido confort del que estamos tratando de escapar. Haz lo contrario. Corre hacia la incomodidad.

La única vez que está bien echar un vistazo al código de otras personas es después de haber terminado el proyecto. Luego, mire todo lo que quiera, analícelo y aprenda de él.

Cada problema difícil que resuelves te hace crecer a pasos agigantados.

No extiendas tus esfuerzos

Soy muy culpable de esto, y en realidad es un consejo que escribo más para mí que para cualquier otra persona (¡lo siento!). Cuando empiece a trabajar en un proyecto y golpee las paredes que mencioné, tendrá la tentación de poner ese proyecto en espera y comenzar uno nuevo.

Siempre se siente genial al principio, hasta que chocas contra una pared con el segundo proyecto. Entonces tendrás dos proyectos sin terminar en tus manos. Esto se repetirá una y otra vez, si lo dejas.

La solución aquí es limitarse a 2 proyectos a la vez. Una vez que se quede atascado en uno, dedique un tiempo a averiguarlo. Pero si parece imposible de romper en este momento, simplemente pase al otro proyecto que tiene. La clave es no iniciar una tercera, porque desde allí hay una pendiente resbaladiza.

Siempre debe intentar hacer todo lo posible para mantenerse en el camino del aprendizaje. Si se siente harto, o simplemente está aburrido de lo que está haciendo actualmente, tómese un pequeño descanso, ajústese y vuelva a hacerlo. No renuncies a la codificación por completo.

Es por eso que siempre recomiendo tener un poco de margen de maniobra, ya sea una distracción temporal en forma de un recurso de aprendizaje diferente (limitado a una semana), o, en este caso, dos proyectos en lugar de uno.

Tu cartera es lo que te contratará

Es muy difícil para un gerente de contratación o para un ingeniero evaluar sus habilidades basándose únicamente en lo que ha escrito en su currículum. “¡Sé JavaScript! (y tener 4 años de experiencia) ". "¡Muéstrame!" (Realmente tengo que detenerme con las referencias de Matrix).

Todos los proyectos que crea y pone en línea constituyen su mejor currículum en vivo. Cualquiera puede mirarlo y estar convencido de que realmente sabe lo que está haciendo.

Sin embargo, no se asuste, no significa que su código deba ser ideal para que ellos siquiera lo consideren. Estos proyectos ayudarán a quien tenga la tarea de entrevistarlo a evaluar adecuadamente su nivel de habilidad.

No tendrá que experimentar entrevistas muy por encima de su nivel porque alguna persona de recursos humanos ha encontrado un conjunto particular de palabras clave en su currículum. Las expectativas de su empleador estarán más a la par con sus habilidades reales.

Los beneficios positivos de tener su trabajo en línea incluyen:

  • los empleadores ven que sabes lo que estás haciendo
  • ven que trabajas constantemente para mejorar tus habilidades
  • ven que usted es, de hecho, un desarrollador y que es lo suficientemente valiente como para poner su trabajo en línea para que todos lo vean.

Por mi experiencia personal y por lo que sigo escuchando de la gente de nuestro grupo de Toronto Free Code Camp es que el factor más importante para encontrar un trabajo de codificación ha sido su cartera de proyectos.

Te irá mejor en las entrevistas

En las entrevistas, es probable que obtenga una pequeña aplicación web de la vida real o una página para construir, o que le den un problema para resolver.

A menudo, con estos problemas, la persona que realiza la contratación busca ver cómo piensa usted para resolver un problema. No siempre quieren que produzca la solución ideal. A veces dan problemas que no se pueden resolver solo para ver lo que haces. Obtendrás mucha práctica de ese tipo con proyectos: cada uno de ellos estará lleno de estos mini-problemas.

En cuanto a las cosas de la vida real que se te pueden dar para construir, pueden variar y variarán. Aquí hay algo que tuve que construir durante la entrevista para mi puesto actual. Sé que el código no es tan bueno, pero esto debería darte una idea de qué esperar. La única razón por la que pude terminarlo el día de mi entrevista fue porque tenía experiencia previa en la creación de cosas como una aplicación meteorológica y una calculadora a través de Free Code Camp.

Identificarás las lagunas reales en tu conocimiento

Aquí es donde los tutoriales y similares te juegan una mala pasada. Te hacen sentir que cuando los terminas, has cubierto todo lo que necesitas saber sobre el tema. Pero en el momento en que intente construir algo por su cuenta, instantáneamente se quedará atascado, a menudo en cosas muy simples.

¿Porqué es eso? Porque los fragmentos de información que se le proporcionaron en un tutorial fueron elegidos por alguien que lo creó utilizando su propio conocimiento de lo que las personas podrían estar buscando. Y porque es simplemente imposible abarcar todo en un tutorial.

La única forma de ver realmente qué conocimiento le falta es seguir descubriendo las lagunas a medida que avanza. No sabes lo que no sabes. Entonces, el proceso es: ir, chocar contra una pared, resolver el problema, seguir adelante, etc.

Cada nuevo proyecto te asusta. ¿Qué hacer?

No sé ustedes, pero conmigo pasa todo el tiempo. Termino un proyecto y me siento muy bien conmigo mismo y con mis habilidades. Luego, en el momento en que leo las historias de los usuarios para mi próximo proyecto, el miedo me paraliza.

Me encuentro pensando: ¿cómo puedo empezar? ¿Qué debo hacer primero? ¿Cómo pude terminar el anterior? ¡No se nada! * Alternar modo de pánico completo *

Hay un par de técnicas que utilizo cuando me meto en esa situación:

En primer lugar, eche un vistazo a todos los proyectos anteriores que ha creado. También fueron enormemente intimidantes. De alguna manera, encontró una manera de resolver los problemas y construir estos proyectos.

Mirar hacia atrás en sus éxitos pasados ​​cuando se encuentra en un momento de poca confianza en sí mismo es un método poderoso para recuperarse y prepararse para un nuevo desafío.

La clave es ver el proyecto como un conjunto de pequeños problemas que resolver. Solo nos asustamos porque vemos todo el iceberg en su totalidad, y viene hacia nosotros. Sin embargo, si usa una técnica de la que hablamos antes, dividir el proyecto en una estructura básica, será muy fácil comenzar.

Olvida el perfeccionismo

No está haciendo esto para crear una especie de proyecto increíble e ideal con un código tan hermoso que hará llorar a los desarrolladores experimentados.

El objetivo es hacer lo que sea necesario: cumplir con las historias de usuario que se le han dado (o que ha creado para usted) para que pueda aprender la mecánica de cómo funciona una determinada técnica de codificación / característica del lenguaje / marco, ya sean API, funciones, promesas etc.

Luego, haga todo lo que pueda para mejorar el proyecto, tanto el diseño como la funcionalidad y la calidad del código.

Pero en algún momento, permítase detenerse. No es un concurso de arte internacional. Eres tú y el tema que quieres aprender. No dejes que el tema te asuste tanto que ni siquiera puedas empezar.

Las personas que tienen una necesidad extrema de hacer todo a la perfección suelen ser las personas que no consiguen absolutamente nada.

No podría comenzar con este artículo, por ejemplo, si pasara demasiado tiempo preocupándome de si sería bueno o malo, y mucho menos perfecto. Sabía que este era un tema importante en el que mucha gente está interesada y que necesitaba escribir sobre lo que había descubierto hasta ahora, con la esperanza de que pudiera ayudar a alguien y facilitar su viaje de codificación.

Si todo tuviera que ser perfecto, ¿habría lugar para los bocetos en el arte? Las imperfecciones son lo que los hace únicos, después de todo.

¡Deja fluir tu creatividad!

No sienta que tiene que hacer que su proyecto sea exactamente el mismo que ve en la página, si está trabajando a partir de una descripción y un ejemplo que encontró en línea. La programación es tanto un arte como una ciencia.

Tómese este punto aún más en serio si está haciendo front end.

Si está creando una máquina de cotizaciones aleatorias, deje que las citas sean de su personaje favorito. Si estás creando un juego, ¡deja que los sonidos y el diseño sean lo que quieras que sean!

Ser raro. Deja salir todas las peculiaridades y diferencias únicas de tu personalidad. Dé rienda suelta a su verdadero yo.

Concéntrese en cumplir con todas las historias de usuario, pero todo lo demás depende completamente de usted.

Aquí está la Calculadora Zen que he construido, como ejemplo de lo que estoy hablando. Por supuesto, puedes ser mucho más creativo. El original está aquí, aunque ya se actualizó. La versión desde la que he trabajado recordaba más a una aplicación de calculadora de iPhone.

La web - y la programación en general - nos permiten esa libertad. Nunca te reprimas. Sea quien quiera ser, haga lo que quiera hacer y deje que eso se extienda a todos los aspectos de su vida, incluida la codificación.

Aquí hay algo de inspiración y para ilustrar lo que quiero decir:

¡Las cosas solo adquieren su sabor cuando les agregas personalidad! Compare pintores hiperrealistas y Picasso. ¿Podrías distinguir a los pintores hiperrealistas con solo mirar su trabajo? Lo dudo mucho. Sin embargo, conocería una pintura de Picasso de inmediato. Te hace pensar.

Cede a una distracción, de vez en cuando

A veces está bien tomarse un pequeño descanso de los proyectos, pero para eso debes tener algunas reglas.

Idealmente, su distracción debe tomar menos de una semana , ya sea un curso o un tutorial, o cualquier otra cosa. Debe ser un tema específico que quieras aprender, preferiblemente relacionado con algo que necesites saber para seguir perfeccionando tu proyecto.

De lo contrario, está completamente bien para mí si está leyendo libros de programación o viendo videos de codificación durante su viaje, o mientras espera en algún lugar sin acceso a Internet.

Solo asegúrese de que cuando esté de regreso en su escritorio (o en cualquier lugar desde el que codifique, podría ser una cama o un sofá, ¿verdad?), Esté de vuelta a lo real. Es tu práctica .

Reciba comentarios sobre sus proyectos

Además de ayudarlo a llenar los vacíos en su conocimiento, los proyectos también le brindan un artefacto que puede compartir con el mundo, solicitando comentarios constructivos.

Tenga cuidado con quién comparte sus proyectos. No dejes entrar a personas demasiado críticas. Intenta encontrar desarrolladores reales o personas que también estén aprendiendo, pero que ya sean un poco más avanzadas que tú. Pídales que revisen su código y brinden sus comentarios. ¿Qué puedes mejorar? ¿Que funciona? ¿Qué no?

Esto acelerará aún más su aprendizaje, porque estas amables personas lo ayudarán a descubrir conocimientos que de otro modo no habría encontrado usted mismo.

Espero haberte convencido a estas alturas de que crear proyectos en vivo es la forma más eficaz de aprender a codificar.

Personalmente, he notado que los períodos en los que construyo, en lugar de mirar, leer o realizar cursos en línea, son los períodos en los que más aprendo. Espero que tu experiencia sea la misma que la mía.

¡Buena suerte! No dude en agregar sus consejos en los comentarios de este artículo y compartir sus proyectos aquí también.

Nota aleatoria: escribí este artículo mientras escuchaba Tron: Legacy Soundtrack.

Si le gustó este artículo, haga clic en ❤ para recomendarlo aquí en Medium. ¡Significaría mucho para mí! :)