senior

El otro día estaba haciendo una entrevista para un puesto de desarrollador senior de JavaScript. Un colega mío, que también estuvo presente en la entrevista, le pidió al solicitante que escribiera una función que ejecutara una llamada HTTP y la repitiera varias veces si fallaba.

Dado que estaba escribiendo código en una pizarra, el pseudocódigo habría sido suficiente. Nos habría gustado que simplemente hubiera demostrado una buena comprensión de la cuestión. Pero desafortunadamente, no pudo encontrar una buena solución.

Pensando que solo estaba nervioso, decidimos facilitar la tarea y le pedimos que convirtiera una función basada en devolución de llamada en una función basada en promesas.

Pobremente.

Sí, puedo decir que ha visto un código similar antes. Sabía, en mayor o menor medida, cómo funcionaba. Bastaría con una solución en pseudocódigo que demuestre su comprensión del concepto.

Pero el código que escribió en la pizarra no tenía ningún sentido. Solo tenía una vaga idea del concepto de promesas en JavaScript y no podía explicarlo bien.

Puedes salirte con la tuya si eres un desarrollador junior, pero si estás solicitando un puesto de desarrollador senior, no es suficiente. ¿Cómo sería capaz de depurar una cadena de promesas y luego explicar sus acciones a los demás?

Los desarrolladores dan por sentadas las abstracciones

Trabajamos con abstracciones. Estamos abstrayendo código que, de otro modo, tendría que repetirse. Entonces, cuando nos concentramos en las áreas más importantes, damos por sentadas las abstracciones y simplemente asumimos que funcionan.

Este suele ser el caso, pero cuando las cosas se complican, es necesario saber realmente cómo funcionan estas abstracciones.

Un candidato para el puesto de desarrollador senior daba por sentada la abstracción de las promesas. Es posible que supiera cómo trabajar con él si lo hubiera visto en algún lugar de un fragmento de código, pero realmente no entendió el concepto y no pudo replicarlo en una entrevista.

Podía memorizar el código. De hecho, no es tan difícil:

return new Promise((resolve, reject) => {
    functionWithCallback((err, result) => {
        return err ? reject(err) : resolve(result);
    });
});

Memoricé como muchos otros. Simplemente memorizas un fragmento de código y puedes lidiar con él entendiendo más o menos cómo funciona.

Pero si realmente entendiera el concepto, no necesitaría memorizar el código. Simplemente lo sabría y no tendría problemas para jugarlo.

Conozca su fuente

En 2012, antes de que los frameworks front-end llegaran a dominar, el mundo estaba dirigido por jQuery, y yo estaba leyendo el libro "Ninja JavaScript Secrets" de John Rezig, el creador de jQuery.

Este libro te enseña cómo crear tu propio jQuery desde cero y proporciona una visión única de los procesos de pensamiento detrás de la creación de esta biblioteca. Aunque jQuery ha pasado a un segundo plano en los últimos años, te recomiendo encarecidamente que leas este libro.

Lo que más me impresionó de ella fue la sensación constante de que podría haberlo descubierto yo mismo. Los pasos descritos eran tan lógicos y simples que realmente sentí que podía crear jQuery yo mismo si lo hacía.

Por supuesto, en realidad, nunca habría sido capaz de hacer eso, me habría resultado demasiado difícil. Habría creído que mis soluciones eran demasiado simples e ingenuas para que funcionaran, y simplemente me habría dado por vencido. Daría jQuery por sentado y creería que funciona. Después de eso, probablemente no me tomé el tiempo para descubrir cómo funcionaba, solo lo usaría como una caja negra.

Pero este libro me ha cambiado. Comencé a leer el código fuente y descubrí que muchas de las implementaciones de las soluciones eran muy simples, incluso obvias.

Por supuesto, encontrar estas soluciones por su cuenta es un asunto completamente diferente. Pero leer el código fuente e implementar las soluciones existentes usted mismo es exactamente lo que ayuda a que surjan sus propias soluciones.

La inspiración que obtendrás y las plantillas que descubrirás te cambiarán como desarrollador. Verás que esta magnífica biblioteca mágica que estás utilizando no es mágica en absoluto, sino muy sencilla, pero bien pensada.

Se necesita tiempo para entender el código. Paso a paso, poco a poco, seguirás el mismo camino que tomaron los autores para crear esta biblioteca. Obtendrá una comprensión más profunda del proceso de codificación y más confianza en sus propias decisiones.

Cuando empecé a usar promesas en JavaScript, pensé que eran algún tipo de magia. Luego descubrí que solo se basaban en devoluciones de llamada, y mi visión de la programación cambió para siempre.

Este patrón, que se suponía que estaba libre de devoluciones de llamada, se implementó con... ¿Devoluciones de llamada?

Me cambió y me hizo darme cuenta de que estos fragmentos de código no son tan complicados. Son solo patrones que son fáciles de entender con curiosidad y paciencia.

Así es como realmente aprendí a programar. Así es como te conviertes en un mejor desarrollador.

Reinventar la rueda

Así que adelante y reinventa la rueda. Escriba su propia facturación de datos, su propia promesa o incluso su propia solución de gestión estatal.

No importa si alguien los usa. Aprenderás. Y si puedes aplicar este código en uno de tus proyectos, sería genial. Lo desarrollarás aún más y aprenderás aún más.

El punto es no usar su solución en producción. Escribir código con sus propias implementaciones de soluciones existentes es una excelente manera de aprender de los mejores.

Compartir: