Hasta hace unos 2 años nunca había escrito un test en mi vida, si escuchaste bien, me avergüenza decirlo pero en mis primeros 3 años en la industria nunca nadie me pidió que escribiera un test.

No sabía cómo se hacían, y sin duda no entendía los beneficios que estos podían traer, conocía la teoría y entendía porque podían ser útiles pero ingenuamente los consideraba no tan importantes.
Fue entonces cuando leí "Clean Code" y "The Clean Coder" \[Robert C. Martin] que una culpa se apoderó de mi. Me di cuenta que durante todo este tiempo nunca había presentado una prueba repetible de que mis programas funcionasen, andaban por plena suerte y solo habían sido probados por mi en ciertas situaciones.

Me di cuenta que había sido irresponsable de mi parte entregar un producto de esta manera y que no tomar esto enserio era una falta de respeto hacia el arte que tanto aprecio y que le da de comer a mi familia.
Recordé muchas veces en las que errores aparecen y reaparecen en partes del código que ya están terminadas, como un cambio trae devuelta toneladas de errores que ya habían sido testeados.
Entendí el miedo real que sentía al momento de refactorizar una parte del código temiendo que podía salir de esa bolsa.

***

Fue entonces cuando decidí tomar un cambio de postura, así como Michael Feathers define el código legacy como cualquier código que no tenga tests, decidí que cada pieza de código que saliera de mi computadora, iba a tenerlos. Que un desarrollo no estaba terminado si este no tenía una suite de tests que lo acompañe que demuestre su correcto funcionamiento (o al menos que pruebe que no es incorrecto). Desde entonces luego de que mi código funcionase, procedía a escribir tests, toneladas de ellos cubriendo todos los grandes funcionamientos, si un bug aparecía, lo arreglaba y escribía un test para ello. Si bien puedo decir orgullosamente que mi código y autoestima como desarrollador mejoro, mi miedo no se redujo.

Seguía teniendo un miedo ferviente a la hora de cambiar código, el hecho de tener suites de tests completas por alguna razón no me daban seguridad, lo que es peor, al darme cuenta que encontraba tests unitarios que pasaban por otras razones que las esperadas, cuestione si todo este trabajo valía la pena o solo me estaba engañando.

Fue entonces cuando lei Test Driven Development By Example \[Kent Beck], y mi mente se abrió a una nueva posibilidad. La idea de que el orden en el que realizaba el proceso de desarrollo si importaba, que escribir mis tests primero si podría tener cierto beneficio.

***

Un poco de contexto:

TDD es un método para dejar que tus tests guíen el diseño de tu software, de seguir este proceso tu código se volverá Desacoplado y Testeable. Usualmente cuando queremos desarrollar algo nuevo nos metemos directamente a teclear y tratamos de sacar algo funcionando y luego escribimos un test para "probar" que funciona, en TDD arrancamos al revés.

1. Decimos, ¿que queremos que este código haga?¿en que situación no debería andar? y escribimos nuestro primer escenario de test, el test naturalmente va a fallar ya que no existe todavía una implementación.
2. Luego procedemos a hacer lo mínimo e indispensable para que el test pase y se nos muestre la deseada luz verde.
3. Finalmente refactorizamos el código siempre corriendo nuestro test después de cada cambio.

> Este ciclo básico se conoce como Red Green Refactor o Rojo Verde Reorganizar.

![Red Green Refactor](/red-green-refactor.jpg)

Ahora que entendemos el proceso básico veamos esos momentos en los que me enamoré:

\*\* Amor a primera vista \*\*

Básicamente por seguir este método nosotros comenzamos siempre con un escenario que sabemos que no funciona y logramos hacerlo funcionar, esto presenta el primer beneficio que amo de TDD, \*\* CONFIANZA \*\*

Cuando vos viste fallar tu código y luego al realizar los cambios correspondientes lo ves pasar, esto te da plena confianza de que tu implementation hace lo que vos esperas que haga, es una diferencia sutil pero que notas inmediatamente al momento de hacer un gran Refactor, tu suite de test te genera tal confianza que sabes que si rompes algo, los tests te lo van a informar.

\*\* Segunda cita \*\*

Usualmente al desarrollar una nueva tarea, tienes que modificar código preexistente, cambias numerosas cosas y luego llega a una parte del proceso en que algo que se encontraba funcionando, ya no lo hace mas, lo peor es que nunca sabemos exactamente qué cambio o en qué momento eso dejo de andar, pasas mucho tiempo buscando ese cambio equivocado e incluso a veces terminas volviendo todos tus cambios atrás y comenzando de cero.
Es en esta situación cuando se me presentó otro beneficio de TDD, \*\* ERRORES DE CORTO PLAZO\*\*. Al encontrarse constantemente en un proceso de Red Green Refactor, en el que escribes tests y estos guían la implementación de tu solución, es un proceso rápido en el que los cambios se hacen en pequeños incrementos, hasta hace solo unos cambios, el código daba Verde y ahora da Rojo, entonces se vuelve trivial el encontrar que parte fue la que causó el error, ya que solo tienes que recordar los cambios que hiciste hace unos pocos segundos.

\*\* Tercera cita \*\*

Cuando pase por esa etapa en la que escribía los tests después, muchas veces se presentaba un error que provocaba que mi confianza en la suite de tests bajase, con el paso del tiempo note que esto sucedía debido a que los tests se encontraban mal planteados desde el comienzo, al escribir los tests después del código inconscientemente estos unicamente pasaban por los "Caminos Fáciles", lugares felices del código donde todo funciona, o lo hace la mayoría del tiempo, esta situación me dio otro beneficio de TDD, \*\* PENSAR EN CASOS EXTREMOS \*\*.

TDD te obliga primero a pensar en los tests, esto hace que puedas concentrarte en cómo debería funcionar tu programa, y también cómo no debería hacerlo, al utilizar el testing como prueba comprobable es mucho más sencillo pensar en estos casos extremos en los que el código tiene que comportarse de maneras específicas, nuestra mente trata de buscar esos lugares y verlos dar Verde.

\*\* Mudándonos juntos \*\*

Por último, y este se encuentra relacionado al anterior. Cuando empecé a realizar los tests luego de la implementation, mi tarea como desarrollador se volvió tediosa y aburrida, por momentos maldije el sentir esa responsabilidad de testear mi código, este aburrimiento provocó que deje de testear caminos complicados o ignore ciertos casos específicos en mi desarrollo. TDD llegó al rescate para solucionar ese problema, hacer los tests primero y verlos fallar género en mi una adicción, la adicción de encontrar errores y luego corregirlos, saber con certeza que esos errores no volverían a aparecer (al menos no de la misma manera) y fue aquí que se me presentó el último beneficio, TDD hizo que \*\* EL TESTING SEA DIVERTIDO \*\*.

***

Desde entonces no imagino mi vida sin escribir tests, hoy en dia a la hora de reproducir un bug muchas veces creo un test que lo pruebe incluso antes de probarlo manualmente,
esta adicción me ha llevado incluso a crear una extension para VSCODE para correr unit tests de Angular con mayor facilidad y poder aplicar el famoso ciclo con rapidez.

Espero que luego de leer este artículo te encuentres interesado en darle una oportunidad a TDD, es un camino difícil y toma tiempo transitarlo, por momentos nuestros impulsos nos llevan a seguir desarrollando más de la cuenta cuando deberías estar escribiendo el test, pero con practica este camino se vuelve más fácil y los beneficios más evidentes.

Que decís, ¿te animas a recorrer este camino conmigo?.


4 razones por las que me enamoré del Test Driven Development

Después de años trabajando como desarrollador, sigo sorprendido de la falta de contenido de calidad específico para nuestra comunidad.
Pasamos días enteros trabajando en Inglés, leyendo documentation, usando tutoriales, hasta nuestro lenguajes de programación están en Inglés.
Se imaginan si un if fuese así?

![FalsoIf](/falsoIf.png)

No fue hasta hace unos meses cuando empecé a realmente valorar la suerte que tengo de saber inglés, no solo porque puedo entender las herramientas, cursos, documentación,
sino porque puedo trabajar perfectamente con gente de muchas nacionalidades, buscar ayuda y aprender. Darme cuenta de esto también me hizo darme cuenta que hay gente que no es tan afortunada,
programadores que no poseen un nivel de inglés suficiente para entender un libro, esto también les dificulta encontrar problemas a errores comunes en portales como Stack Overflow.

Decidí entonces que iba a hacer un esfuerzo para aportar mi parte y que la comunidad de programadores hispanos crezca, desde ahora en más todos los artículos de mi blog van a ser en español, voy a publicar un artículo todos los viernes, últimamente ando enfocado en programación funcional y arquitectura de software, si esto te gusta entonces te doy la bienvenida a mi calabozo.


Devolviendo a la comunidad

He estado trabajando como desarrollador durante los últimos 5 años. No es mucho tiempo, lo sé, pero en este tiempo creo que he mejorado mucho, más que si hubiera tomado un enfoque pasivo con mi carrera. Me he dado cuenta de que las personas siempre acuden a mí y mencionan las tecnologías para obtener mi opinión como si hubiera probado todo lo que está ahí fuera.
Aunque es una exageración, tuve experiencias variadas, entre el trabajo profesional y el hobby, he realizado aplicaciones comerciales, juegos, hacks de juegos, bots, API públicas de alta concurrencia, extensiones de Visual Studio Code e incluso ROMS personalizados de Android. ¿y porque te preguntas? porque no aprender es estar muerto, así de simple.

> Déjame decir eso otra vez! No aprender es estar muerto.

Siempre hay un nuevo libro, algo interesante que no has probado antes y algo de lo que puedes aprender y es tu trabajo tomar medidas y hacerlo, nadie más puede hacerlo por ti, si solo esperas "aprender en el trabajo" puede que te despiertes un día en ese trabajo viejo y horrible haciendo exactamente lo mismo que has estado haciendo durante los últimos 10 años y te veas obligado a mejorar, dejame decirte, ese cuento no va a terminar bien.

***

Para ser justos, no todo mi aprendizaje ha sido 100% planeado, planeé investigar tecnologías o leer cierto libro o mejorar en cierta habilidad, pero no siempre he sido tan organizado como me estoy volviendo ahora, así que intentaré compartir mi sistema de trabajo contigo.

Necesitaba una manera de mantener toda la complejidad mental de avanzar en mi carrera en un solo lugar, para eso elegí [Notion](https://www.notion.so/), es una gran herramienta con toneladas de plantillas para básicamente todo que puedas necesitar, no solo lo uso para mi desarrollo personal, sino también para mi presupuesto, solicitudes de empleo, trackear mis comidas y documentación de trabajos independientes.

Entonces, ¿cómo empezamos? Primero establecemos nuestros objetivos, para llevar esto acabo podemos hacer una lista.

1. Aprender programación funcional
2. Aprender a utilizar patrones de arquitectura como *Clean Architecture*
3. Conviértete en un verdadero desarrollador full stack, mejorar mis capacidades en el frontend
4. Crear mi propio sitio web / blog
5. Obtener un trabajo de desarrollador remoto de backend / full stack

Tengo otros objetivos como perder peso, ahorrar dinero extra, invertir, mejorar mis relaciones personales, etc. Solo nombre los relacionados con el software 😀

Después de eso, traducimos esos objetivos en tareas más pequeñas y concretas, por lo que, de modo que cuando se complete una, nos llevará un paso más allá hacia nuestros objetivos, esto lo logró usando una tabla Kanban en *Notion* como se puede ver en la imagen a continuación.

![Notion Kanban Board](https://thepracticaldev.s3.amazonaws.com/i/6njh1bf4p42dx4l223mz.png)

Aquí verás cosas como:

* "Leer *Design Patterns*"
* "Leer *Mostly Adequate Guide to Functional Programming*"
* "Leer *Structure and Interpretation of computer programs*"
* "Implementar diseño de la landing page de mi sitio"
* "Implementar diseño de blog y los artículos"
* "Finalizar características pendientes en Angular Test Explorer (esa es la extensión VSCODE que mencioné antes)"

Esto esta perfecto, pero luego debes asegurarte de realmente hacer lo que decis que vas a hacer. Bueno, noté por prueba y error que si no los planificó, nunca se hacen. Entonces, ¿cómo hago eso? el confiable [Google Calendar](https://calendar.google.com/) al rescate.

![Calendario de Google](https://thepracticaldev.s3.amazonaws.com/i/4gaxvshbcu8f4w7fyphr.png)

El domingo por la noche antes de que termine el fin de semana, planeo lo que voy a hacer la próxima semana (y sí, la planificación también está en el calendario), no soy muy específico aquí, solo pongo "Código" o "Leer", o en algunos casos especiales "Hacer Code Katas".
Estoy intentando, aunque no soy perfecto en ello, seguir la técnica "2 sombreros" aquí, básicamente lo que esto significa es que cuando planifico mi semana tengo el "sombrero de jefe", durante la semana, por otro lado tengo "sombrero de empleado", si mi calendario dice ejercicio, entonces el jefe dijo ejercicio, así que es tiempo de ejercicio, sin preguntas, simplemente lo hago, por supuesto, es más fácil decirlo que hacerlo, pero lo intento.

Finalmente, escribo mi progreso en un cuaderno, si, no hay aplicaciones aquí, un cuaderno real, también leo lo que he logrado la semana anterior, así que siempre lo tengo en mi cabeza.

![Cuaderno](https://thepracticaldev.s3.amazonaws.com/i/8ygelofb7d5h22ts5tyj.jpg)

***

Hasta ahora, mi progreso se ha disparado desde que comencé a ser más disciplinado y organizado sobre mi carrera, ahora está muy claro lo que quiero lograr y si estoy tomando los pasos correctos.
Mi flujo de trabajo no es perfecto, todavía estoy tratando de mejorar, pero realmente espero que mi proceso te inspire a tomar tu camino en tus propias manos, reflexionar profundamente y planificar tu arduo trabajo. Hará un mundo de diferencia.


Estudio deliberado, tomando el control de nuestra carrera

De vez en cuando, con el objetivo de mantener mi ojo en el mercado, miro las ofertas de trabajo para ver qué encuentro. Para determinar si mis habilidades siguen siendo relevantes y verificar qué tecnología está en auge en el mercado laboral. A menudo me siento decepcionado de que todo siga igual, los mismos "REQUISITOS" estúpidos:

1. Master en informática y 7 años de experiencia.
2. Solo ingenieros de software con diez años de experiencia trabajando en aplicaciones comerciales.
3. Siete años de experiencia en React (fue lanzado en 2013).
4. Experiencia en JavaScript, Python, Ruby y Go.
5. Conocimiento de sistemas web, móvile, embbeded.
6. Desarrollador experto en .NET con conocimiento de Java 7, Spring.
7. Habla inglés, holandés, francés, alemán es una ventaja (vivo en Bélgica, así que supongo que consideran hablar estos 4 idiomas como algo "Normal").
8. Menores de 30 años, más de 10 años de experiencia.

Se podría pensar que estoy inventando esto, pero no, todos estos son requisitos reales que encontré en Linkedin la semana pasada. ¿Alguien de ustedes consideraría que estos requisitos son realistas? ¿Son incluso REQUISITOS? La realidad es que no lo son.

***

En la fábrica de salchichas de ofertas de trabajo pueden suceder muchas cosas. Podrían ser construidos por alguien que no tenga información real o comentarios del equipo técnico, solo recopilan algunas de las tecnologías utilizadas, solicitan un número aleatorio de años de experiencia, y eso es todo. En algunos casos, el equipo de tecnología en realidad revisa las publicaciones, pero quieren lo que me gusta llamar "El candidato perfecto", seguro que todos querríamos a un tipo con 10 años de experiencia que conozca nuestro stack perfectamente y quiera trabajar por 10 dólares la hora, no es realista esperar que alguien así llegue a nuestra puerta (o que incluso exista).

La realidad es que la mayoría de las veces no se necesita todos esos requisitos para ser contratado, solo se necesita tener algunos conocimientos para asumir las tareas que le asignan y hacer que la empresa gane dinero, al final eso es todo lo que la empresa está buscando. También debe tener en cuenta que, incluso si esos son los requisitos, existen grandes posibilidades de que nadie así responda a la búsqueda, tendrán que elegir a alguien del grupo de solicitantes que recibieron y contratarlo. Es en ese momento cuando los reclutadores y la empresa se dan cuenta de que las expectativas no son realistas, una vez que comienzan a llegar esos CV, solo haces lo mejor que puedes con lo que tienes a tu disposición.

No estoy diciendo que deberías solicitar un puesto de alto nivel si acabas de comenzar (aunque lo peor que puede pasar es que no le devuelvan la llamada, ¿no es tan malo, verdad?), pero deberías aplicar a todos los trabajos que crees que puedes hacer, incluso si no cumples con todos los requisitos. Tal vez tengas menos experiencia de lo que están buscando, o solamente hables algunos de los idiomas, o hayas trabajado con un stack diferente durante muchos años y quieras hacer un cambio. Simplemente aplica, nada puede salir mal, una vez más, lo peor que puede pasar es que no respondan, por otro lado, podrías terminar siendo contratado para un hermoso trabajo que no soñabas obtener en un millón de años..

***

Digamos que te llaman, obtienes la entrevista, todo está en tus manos ahora, sé sincero. Habla sobre las cosas que te gustaron de la compañía y su producto, qué se es lo que no tienes en relación a la publicación del trabajo, pero por qué crees que todavía puedes hacer el trabajo, no olvides enfatizar que puedes traer a la mesa que es beneficioso para ellos. Siempre hablo sobre el conocimiento agnóstico de la tecnología, cosas que no son específicas de la stack en la que está trabajando, como la arquitectura de software, ahora es el momento de mencionar todo lo que te permitirá empezar ese nuevo trabajo y ser productivo en el menor tiempo posible.


Aplica a todos los trabajos, los avisos no son realistas de todas maneras

La semana pasada escribí un artículo analizando mis primeros 5 años en desarrollo y dando algunas recomendaciones, una de mis sugerencias fue **¡Siempre lea libros técnicos!**. Mucha gente mostró interés en el tema, así que decidí escribir el siguiente artículo sobre los libros que creo que son los más útiles para los desarrolladores.

Si estas interesado en el primer artículo, puedes leerlo [aquí!](https://www.patferraggi.dev/blog/2019/oct/how-to-become-amazing-developer/).

***

Siempre preferí los tutoriales y los cursos en línea, pero desafortunadamente no cubrirán el conocimiento fundamental que llevará sus habilidades de desarrollo a un nivel completamente nuevo. Durante los últimos 2 años he estado comiendo libros técnicos, uno tras otro, tratando de implementar lo que leo en mi trabajo diario. He visto que la calidad de mi código mejoró mucho, y también noté muchos errores que estaba cometiendo, lo que me hizo crear mejores estándares para mí y perseguir el dominio de mi oficio. Ahora pienso en cuánto tiempo 'perdí' antes de comenzar a leer este tipo de libros y deseó haber empezado antes, espero que este artículo te dé una ventaja en el camino para ser el mejor desarrollador que puedas ser.

#### 1. [Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)](https://www.amazon.com/gp/product/0132350882?ie=UTF8\&tag=patferraggi-20\&camp=1789\&linkCode=xm2\&creativeASIN=0132350882)

![clean code](https://m.media-amazon.com/images/S/aplus-media/mg/38127463-e531-4823-b46e-d79d174575cc._SR150,300_.jpg "Clean Code")

Este libro es un comienzo increíble, definitivamente lo consideraría el primero. Abarca varios temas como dependencias, nombres de métodos y clases, comentarios, pruebas. En mi caso, cuando leí este libro, inmediatamente me sentí como un idiota, sentí que estaba haciendo todo mal, básicamente sacudió todo lo que creía saber sobre la creación de software.
Creo que después de leer esto, mi código es más fácil de mantener, verificable y se explica por sí mismo.

El libro también está muy bien escrito, lo que hace que sea increíblemente fácil de leer varias veces.

#### 2. [The Pragmatic Programmer, your journey to mastery (Dave Thomas and Andrew Hunt)](https://pragprog.com/book/tpp20/the-pragmatic-programmer-20th-anniversary-edition)

![prag prog](https://imagery.pragprog.com/products/595/tpp20_xlargecover.jpg?15571739633,200_.jpg "The Pragmatic Programmer")

Ya salió la edición 20 aniversario de este clásico, leí la versión original hace 2 años. Fue mi primer libro técnico y fue uno bueno, a la altura de Clean Code.

Este libro está lleno de sorprendentes consejos muy simples que podes hacer para mejorar su software, desde cómo manejar las pruebas y refactorizaciones, hasta la creación de herramientas automatizadas, para evitar la duplicación. Tiene un buen consejo tras otro. El libro también está escrito usando estudios e historias como ejemplos que hacen que estos consejos sean fáciles de entender e interiorizar.

#### 3. [The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin)](https://www.amazon.com/gp/product/0137081073?ie=UTF8\&tag=patferraggi-20\&camp=1789\&linkCode=xm2\&creativeASIN=0137081073)

![The clean coder](https://m.media-amazon.com/images/S/aplus-media/mg/a1e81e9e-d24a-462f-8364-552ae1f840c8._SR150,300_.jpg "The clean coder")

Sí, otro de Robert C. Martin o "Uncle Bob" como le suelen llamar. Es un tipo con opiniones fuertes y una pasión contagiosa por el software. Este libro trata sobre esa pasión, trata sobre cómo debemos manejar todos los pasos para crear y mantener software e intenta crear un conjunto de principios que todos los desarrolladores deberían aplicar. Realmente creo que esto también es una necesidad para todos los desarrolladores, en mi caso me hizo cuestionar mi propia profesionalismo y me inspiró a llevar mis acciones diarias en el trabajo de manera diferente.

#### 4. [Working Effectively With Legacy Code (Michael Feathers)](https://www.amazon.com/gp/product/0131177052?ie=UTF8\&tag=patferraggi-20\&camp=1789\&linkCode=xm2\&creativeASIN=0131177052)

![Working effectively with legacy code](https://m.media-amazon.com/images/S/aplus-media/vc/d4da85d4-70d2-4fce-ad49-8731719c77b7._SR150,300_.jpg "Legacy Code")

El título del libro parece ser todo lo que puedas necesitar, ¿verdad? Al menos eso es lo que pensé cuando lo vi. ¿No siempre trabajamos con código legacy? ¿Estás en un proyecto nuevo sin pruebas, así que esto no te concierne?

Después de leer este libro, verás el código legacy de una manera muy diferente y este libro agregará toneladas de herramientas a su cinturón sobre cómo llevar ese código legacy a una era de gloria. También es uno de esos libros que te hace pensar que estabas haciendo todo mal, hasta el punto de sentir vergüenza por el software que estás creando. Es en ese punto que sucederán grandes mejoras.

#### 5. [Test Driven Development By Example (Kent Beck)](https://www.amazon.com/gp/product/0321146530?ie=UTF8\&tag=patferraggi-20\&camp=1789\&linkCode=xm2\&creativeASIN=0321146530)

![TDD by example](https://images-na.ssl-images-amazon.com/images/I/51kDbV%2BN65L._AC_AA180_.jpg "Test driven development")

Esto podría ser un poco controvertido, habrá dos tipos de argumentos aquí. El primero: "¿Realmente necesito pruebas?" Te sorprendería saber cuántos desarrolladores no prueban su código en 2019. No se dan cuenta de que parte del desarrollo es proporcionar una forma repetible de mostrar la correcta ejecución (o la NO falla) de sus programas.

El segundo argumento es si realmente se necesita Test Driven Development. Es posible que esté haciendo pruebas después de compilar el software y pensar que es lo mismo, pero no lo es. TDD te ofrece algunas características que no obtendrás si realizas las pruebas después del código, particularmente una confianza total en su conjunto de pruebas que te permite realizar refactorizaciones con facilidad, ayudando automáticamente a que tu código mejore.
Después de leer este libro, comprenderás las diferencias. Lo que no entenderás es cómo estabas produciendo software sin él.

***

Ese es mi top 5, tengo más, mucho más, pero creo que estos son imprescindibles. Por lo general, no leo libros tecnicos sobre una tecnología específica, la tecnología se mueve tan rápido que ese tipo de libros están desactualizados la mayoría de las veces en el momento en que salen, descubrí que es mejor obtener conocimiento que pueda ser agnóstico a la tecnología utilizada para implementarlo.

En caso de que ya leas esos, voy a dejar aquí algunos enlaces rápidos a otros que leí y realmente disfruté.

[Refactoring: Improving the Design of Existing Code (Martin Fowler)](https://www.amazon.com/gp/product/0134757599?ie=UTF8\&tag=patferraggi-20\&camp=1789\&linkCode=xm2\&creativeASIN=0134757599)

[Adaptive Code: Agile coding with design patterns and SOLID principles (Gary McLean Hall)](https://www.amazon.com/gp/product/1509302581?ie=UTF8\&tag=patferraggi-20\&camp=1789\&linkCode=xm2\&creativeASIN=1509302581)

[Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin)](https://www.amazon.com/gp/product/0134494164?ie=UTF8\&tag=patferraggi-20\&camp=1789\&linkCode=xm2\&creativeASIN=0134494164)

[Structure and Interpretation of Computer Programs (Harold Abelson and Gerald Jay Sussman with Julie Sussman)](https://web.mit.edu/alexmv/6.037/sicp.pdf)

[Design Patterns: Elements of Reusable Object-Oriented Software (Gang of Four)](https://www.amazon.com/gp/product/0201633612?ie=UTF8\&tag=patferraggi-20\&camp=1789\&linkCode=xm2\&creativeASIN=0201633612)

[Head First Design Patterns: A Brain-Friendly Guide (Eric Freeman and Elisabeth Robson)](https://www.amazon.com/gp/product/0596007124?ie=UTF8\&tag=patferraggi-20\&camp=1789\&linkCode=xm2\&creativeASIN=0596007124)

Si necesitas una recomendación de libro, hácemelo saber, siempre hay algo nuevo en mi biblioteca 😀.

Muchas gracias por tomarte el tiempo de leer este artículo, ¿ya has leído alguno de estos libros? Me encantaría leer tu opinión en los comentarios.
¿Tienes una recomendación de libro para mí? No dudes en hacérmelo saber.


5 libros que todo programador deberia leer y algunos extras

Hace unas semanas sucedió algo especial: el 8 de octubre. Para todos los demás eso no significa nada, otro día normal. Para mí, por otro lado, fue mi cumpleaños de desarrollo de software.

A principios de 2014, mi mejor amigo me recomendó que comenzara a aprender programación porque vio que estaba triste y cansado de seguir una carrera que realmente no me gustaba. Comencé a aprender C por mi cuenta, experimente un poco con C++ y finalmente comencé a leer "C# In Depth" según la recomendación de mi amigo.

***

El 8 de octubre de 2014 me uní a un programa de capacitación en C# impartido por *Accenture* (lo llamaron su campo de entrenamiento), 1 mes después estaba trabajando como desarrollador de C# Junior y comenzó mi carrera en software.
Mucho ha cambiado en los últimos 5 años, *Microsoft* se volvió de código abierto, *JavaScript* se convirtió en un lenguaje serio y no solo un juguete para sitios web, la programación funcional comenzó su regreso, toneladas de tecnologías han nacido y murieron ante nuestros ojos.

Muchas cosas también cambiaron en mi carrera: pasé de ser autodidacta a bootcamp, a cambiar de universidad para dedicarme a la ingeniería de software, abandonar y finalmente continuar la ruta autodidacta. Desde trabajar en contabilidad hasta convertirme en desarrollador de software, trabajar durante 3 años en mi país natal, Argentina, para buscar una vida mejor en un lugar del que no sabía nada, y mucho menos hablar el mismo idioma, la encantadora y lluviosa Bélgica.

Después de reflexionar sobre el camino que me trajo hasta aquí, no puedo evitar pensar en las buenas y malas decisiones que he tomado. Aquí hay algunas cosas que desearía haber sabido cuando comencé:

### 1. ¡Ve a meetups, conoce gente nueva, haz amigos!

Las personas subestiman la importancia de las relaciones personales y la comunicación en el desarrollo de software. Algunos creen en esta idea de un desarrollador genio 10X que codeara 24 horas sin dormir y creará magia. Este es un sueño imposible. Somos excelentes en lo que hacemos cuando colaboramos entre nosotros, cuando desarrollamos relaciones humanas que nos permiten crear grandes piezas de software. Estas relaciones nos ayudan a crecer, aprender cosas nuevas (no siempre relacionadas con el software, pero igual de valiosas) e incluso progresar en nuestras carreras. Si no fuera por un amigo mío, probablemente sería un contador muy triste.

### 2. Leer libros técnicos.

Siempre preferí los tutoriales y los cursos en línea, pero desafortunadamente no cubrirán el conocimiento fundamental que llevará sus habilidades de desarrollo a un nivel completamente nuevo. Durante los últimos 2 años he estado comiendo libros técnicos, "El programador pragmático", "Código completo", "Código limpio", "Refactorización", lo que sea, sólo desearía haber comenzado antes. Hay tanto conocimiento escrito por profesionales en la industria y es una pena no mirar un poco sus cerebros.

### 3. Centra tu aprendizaje en el conocimiento agnóstico del lenguaje o framework.

Este está relacionado con el anterior. Claro, hay un nuevo framework de *JavaScript* todos los días y la gente está luchando por ponerse al día. Bueno, no lo intentes. No es posible ni vale la pena. En lugar de enfocarse en los framework, enfócate en la arquitectura, el diseño de sistemas, incluso los paradigmas de software. Los lenguajes y los framework son solo herramientas que utilizamos para crear productos, cambian todo el tiempo, las técnicas que utilizamos para crear software evolucionan a un ritmo mucho más lento y pueden ayudarte a cambiar de un stack a otro con facilidad.

### 4. Siempre tenga un proyecto personal al lado.

No puedo enfatizar lo suficiente lo importante que es esto. Claro, codeas 8 horas al día en su trabajo diario y podrías estar pensando, "¿por qué necesito codear en mi tiempo libre?", Bueno, hay una serie de razones.

* No siempre estará claro qué quieres hacer con tu carrera. Cuando comencé, pensé que quería ser un desarrollador móvile. Me llevó un proyecto personal creando una aplicación de reembolso de gastos en Xamarin se darme cuenta de que esto no era lo que más me interesaba.
* Las habilidades técnicas se vuelven obsoletas rápidamente en esta industria, por lo que debes probar otras cosas y tener una buena idea de lo que hay fuera de tu zona de confort.
* Puede ser una muy buena manera de crear un portfolio personal, mostrarle a un empleador potencial que eres un apasionado, un solucionador de problemas y tienes un buen conjunto de habilidades.
* Si la comunidad nota los proyectos, puede ser una excelente manera de conocer a otros desarrolladores, hacer conexiones y amigos.

### 5. Aprende algo de Ciencias de la Computación.

Si eres un desarrollador autodidacta como yo, probablemente no quieras tener nada que ver con esto. Bueno, tendré que reventarte la burbuja. Aprender algunos conceptos clave hará que tu vida sea mucho más fácil para el aprendizaje futuro. No digo que los necesites para ser un desarrollador, pero después de conocerlos, se convertirán en los componentes básicos que utilizarás para aprender nuevas tecnologías y patrones.
Pasé 2 años estudiando ciencias de la computación mientras trabajaba como desarrollador, no mucho, pero fue suficiente para ponerme en contacto con conceptos como álgebra booleana, grupos, grafos, árboles, algoritmos de clasificación, memoria dinámica y estática, punteros, teoría de autómatas; incluso diferentes paradigmas de programación, como orientado a objetos, lógico, funcional, y puedo recordar toneladas de momentos en los que pude asociar esos conceptos a cómo una nueva pieza de tecnología que estaba aprendiendo se encontraba implementada detrás de escena.

Si eres un desarrollador autodidacta, te recomendaría que leyeras [The Imposter ‘s Handbook 1 & 2](https://bigmachine.io/products/imposter2-combo/), cubren todo lo que puedas necesitar 😀

***

Después de escribir este artículo, me siento mucho mejor acerca de mi progreso, cometí algunos errores aquí y allá, tal vez no utilicé mi tiempo correctamente. Pero aprendí y continuaré aprendiendo sin importar qué, porque eso es lo más importante que quiero que recuerdes de esto, sigue aprendiendo y te prometo que todo estará bien.


Cómo volverse un excelente programador, cosas me hubiera gustado saber cuando empecé

Hola, me llamo Patricio y, como tú, soy desarrollador de software. Hace aproximadamente un año comencé a trabajar con *Angular* en mi trabajo actual, ya que quería volver a ser desarrollador full stack. Trabajé profesionalmente con Angular.js antes e hice algunos proyectos de prueba con Angular pero nada serio.

Con conocimientos en *C#/JavaScript* hacer *TypeScript* no fue un problema en absoluto. Me sentí como en casa y desarrollé las habilidades necesarias rápidamente. Tenía mi entorno de desarrollo en Visual Studio Code listo, así que seguí adelante y comencé a desarrollar utilizando TDD, como estaba acostumbrado a hacer en C#.

***

Creé mis primeras pruebas usando Jasmine y Karma, ya que viene por defecto con *Angular* cuando noté un problema por primera vez. Tuve que ejecutar "ng test" para ejecutar pruebas en el proyecto, ver el resultado en la consola o abrir un navegador y ver los resultados en Karma. Si quería ejecutar una sola prueba por defecto, tenía que modificar el código para que solo ejecutara esa prueba.

Estaba completamente asombrado, no podía creer que así es como trabajaban los desarrolladores en *Angular*. El flujo de testing entero se sintió extraño, contraproducente y realmente me retrasó. Viniendo de Visual Studio, estaba tan acostumbrado a tener una interfaz de usuario interactiva agradable donde ves todas las pruebas: ejecutas la "Suite" entera o ejecutas tests individualmente y obtienes resultados inmediatos. Necesitaba algo similar para que *Angular* funcionara tan eficientemente como lo hago en *C#*, pero no pude encontrarlo (WebStorm de Jetbrains tenía algo similar, pero yo soy fanático de VS Code y tampoco quería comprar una licencia de producto) .

Entonces, ¿qué decidí hacer? Construir mi propia solución.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/tmfv22164xb8ngg8i2gh.png)

Así es como mi extensión "Angular/Karma Test Explorer" se hizo realidad.

Con la extensión, puedes abrir un proyecto *Angular* en Visual Studio Code e inmediatamente ver todas sus pruebas dentro del explorador.
También puedes ejecutar todo el conjunto de pruebas o pruebas individuales y ver los resultados de inmediato, incluso ver decoraciones en el archivo o ejecutar las pruebas directamente desde el archivo.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/7nsmr183g6szwk2ervrp.png)

Todo comenzó como un problema personal que tuve y no pude encontrar una solución, pero finalmente la gente comenzó a responder a la extensión. Comenzó a usarse en mi lugar de trabajo y en otras compañías, y la gente mostró su aprecio por el proyecto. Los usuarios comenzaron a solicitar funciones e incluso enviaron "pull requests" para cosas que jamas hubiese considerado yo.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/fwg87ttoqs0zgiipo81f.png)

No era competente en *Angular* o *TypeScript* (la extensión esta hecha en *TypeScript*, así que ahora me siento mucho más confiado con el lenguaje), ni siquiera me consideraba un desarrollador senior, pero vi un problema y tomé el desafío personal de construir algo que yo y otras personas podrían disfrutar.

***

Y esta es la conclusión de este artículo. Como desarrolladores, creamos soluciones, y no importa las habilidades que tengas, probablemente ya hayas visto una característica faltante o un problema que no se está resolviendo. No esperes a que alguien lo arregle por vos, hacelo vos mismo. Ayuda a alguien más y aumenta tus propias habilidades en el proceso, te prometo que será muy divertido.

Si deseas contribuir al proyecto, puedes encontrarlo directamente en VSCode o en el Marketplace, antes de contribuir, echa un vistazo al repositorio de Github o si solo quieres conversar conmigo, no dudes en ponerte en contacto conmigo en Twitter. Gracias por tomarte el tiempo de leer esto y, con suerte, te aliente a comenzar a construir nuevos productos 😀.


4 razones por las que me enamoré del Test Driven Development

Devolviendo a la comunidad

Estudio deliberado, tomando el control de nuestra carrera

Aplica a todos los trabajos, los avisos no son realistas de todas maneras

5 libros que todo programador deberia leer y algunos extras

Cómo volverse un excelente programador, cosas me hubiera gustado saber cuando empecé

Como encontré un problema con el Testing en Angular y decidí solucionarlo yo mismo