Incluye Code Reviews

La IA NO reemplazará a los programadores.
Sino que los (buenos) programadores reemplazarán a todos los demás.

Testing SostenibleTesting Sostenible con TypeScriptUn curso de Testing, TDD y Diseño de Software
creado por y para Developers
COMPRAR HOYpaymentsSecured by Stripe with AES-256 Encryption

Últimamente no paro de leer titulares:

“Ya no hay que escribir ni una sola línea de código más.”
“La IA te va a dejar sin trabajo.”
“RIP developers.”

Incluso Barack Obama se ha sumado a la fiesta diciendo que:

“La IA ya es mejor que el 70% de los programadores.”

Curioso, viniendo del mismo Obama que en su día se hizo famoso por ser el primer presidente en escribir código en público.

Y no solo eso. Entonces recomendaba a todo el mundo aprender a programar porque “te enseña a pensar”.

¿Y ahora?

Ahora no.

Ahora todo lo contrario.

Lo que de verdad asusta no es la IA, es la falta de criterio al hablar de ella.

Pero bueno… son sus costumbres y hay que respetarlas.

Naval Ravikant, que sí sabe de lo que habla, lo resumió mucho mejor en un tweet:

“La IA NO reemplazará a los programadores. Sino que los programadores reemplazaremos a todos los demás.”

99% de acuerdo.

Solo le falta un matiz. Un matiz del que te das cuenta cuando llevas años sufriendo las calamidades del paso del tiempo en el código de los proyectos.

Por eso añadí “buenos” entre paréntesis.

Y es que no creo que lo que dice Naval aplique a todos los developers, sino a los buenos de verdad.

A los que de verdad marcan la diferencia.

Porque picar código que más o menos funcione lo sabe hacer cualquiera.

Y ya casi ni hay que picar, solo tienes que copiar y pegar de ChatGPT o directamente lo generas con Cursor…

Pero que el código funcione no significa que esté terminado.

Porque muchas veces los developers olvidamos la otra mitad del trabajo: la de hacer el Código Sostenible

Y cuando digo sostenible, me refiero a fácil de mantener.

Y cuando digo fácil de mantener, me refiero a sencillo de cambiar

Si, cambiar. Porque hay una verdad absoluta en el software: si un proyecto tiene cierto éxito cambiará.

Ojalá alguien me hubiera dicho cuando empecé a programar que aprender a escribir buenos tests era fundamental para diseñar software de calidad...

Podría contarte algunas historias parecidas que me tocó vivir en mis primeros años programando. Pero ninguna ilustra mejor el problema que la que le ocurrió a Carlos Blé —mi socio en esta formación— hace ya unos 20 años.

“En 2004 monté mi primera empresa junto a tres amigos.

Uno de los mejores clientes que conseguimos fue una pequeña empresa de telefonía y canales de televisión que representaba más de la mitad de nuestra facturación.

Recuerdo que una mañana, mientras estaba desarrollando la parte de su web de registro de clientes, me llamaron porque ciertos usuarios no podían darse de alta en el sistema.

Resulta que eran extranjeros con apellidos que contenían símbolos como el apóstrofe o la diéresis y el código de validación fallaba y no les permitía registrarse.

No teníamos ni un test, no sabíamos ni cómo se hacían.

Tampoco teníamos un entorno de pruebas.

Sino que hacíamos los cambios a cualquier hora, directamente en el entorno de producción.

Aquella mañana hice como diez cambios en el código, cada uno correspondiente a una llamada de teléfono de mi cliente, quejándose por un caso diferente.

Mientras arreglaba un caso estropeaba otros, estaba cada vez más tenso y mi cliente más molesto.

Con cada cambio en producción teníamos que reiniciar el servicio y los usuarios conectados perdían su sesión.

Al final del día el cliente se había dado cuenta de que no éramos solventes, había agotado su paciencia.

Paró el proyecto y nos lo quitó.

Para mí fue una gran lección y la terminé de comprender cuando aprendí a hacer tests”.

Hoy en día hay tantas alternativas que los usuarios ni siquiera se molestan en llamarte para quejarse.

Simplemente cierran tu aplicación, dejan tu servicio y se van a la competencia sin que te des cuenta.

El coste de un bug en producción es más alto que nunca.

Porque la tolerancia de la gente es mínima.

Y las alternativas, infinitas.

Hay que reducir al mínimo el número de bugs que llegan a producción. Y sobre todo, impedir que reaparezcan problemas que ya estaban reportados y corregidos.

Juniors con 10 años de experiencia

El significado de la palabra senior no ha cambiado demasiado en los últimos 20 años.

Aún hoy en día en muchas empresas a los developers se les llama seniors (o se consideran ellos mismos) por el simple hecho de llevar “n años” programando, sin importar si han aprendido algo durante ese tiempo.

Y no me refiero solo a habilidades técnicas. También están las soft skills se esperan de un programador experimentado, especialmente las relacionadas con la comunicación.

Porque sí: el código también comunica.

Para esto es fundamental entender cómo funciona el negocio, cómo hace dinero, dónde se aporta valor y dónde no.

No estoy diciendo que los años programando no sean importantes.

Sin duda lo son. No hay mejor aprendizaje que sufrir las calamidades del paso del tiempo en los proyectos para entender la importancia de saber escribir código de calidad.

Como diría Nassim Taleb: con Skin in the game.

Sufrir las consecuencias de tus decisiones en el código, en tu propia piel.

No hay otra.

Ahora bien, hay una enorme diferencia entre 10 años de experiencia…

… y un año de experiencia repetido 10 veces.

No es lo mismo 10 años de aprendizaje real, trabajando en varios proyectos, con diferentes lenguajes, tecnologías, paradigmas, y rodeado de developers de alto nivel, que además dan importancia a escribir buenos tests.

Que pasar 10 años en la misma empresa, con un equipo mediocre, resolviendo siempre el mismo tipo de problemas, en un proyecto que hace aguas, sin tests y plagado de malas prácticas.

Ahí es donde el aprendizaje se detiene.

O peor: donde los malos hábitos se consolidan.

Las formaciones que hay en el mercado tampoco ayudan...

La mayoría de las formaciones para developers tienen dos problemas.

El primero: están creadas por personas que nunca han convivido lo suficiente con su propio código. Pasa en cursos online, bootcamps y, sobre todo, en la universidad y ciclos formativos.

No son conscientes de los problemas de mantenimiento que puede acarrear la forma en la que enseñan a programar.

De hecho, me atrevo a decir que en el 90% de esos cursos no se escribe ni un test.

Y sin buenos tests no puede haber calidad en el software.

¿Por qué?

Porque una buena batería de pruebas es lo único que te permite refactorizar con garantías.

Los tests son nuestra red de seguridad.

Sin tests (o con tests de mala calidad), intentarás mejorar una cosa y romperás otra. Garantizado.

Tenemos que cambiar esa mentalidad de que programar y hacer tests son tareas distintas.

El segundo problema es cómo enseñan.

¿Te imaginas un curso de cocina donde solo hagas recetas con la Thermomix?

Pues eso es lo que hacen la mayoría de cursos para developers: enseñar a programar centrados en el último framework o librería de turno.

No centran en los principios.
Ni en los fundamentos.
Sino en diseñar soluciones totalmente acopladas a la última herramienta de moda.

Y justo por eso nació esta formación.

Llevábamos años —Carlos Blé y yo— viendo los mismos errores repetirse. En proyectos reales. Con equipos reales. Y consecuencias que no salen en los tutoriales.

Carlos Blé y Miguel Gómez tomando un café

Así que decidimos crear el curso que nos habría ahorrado años de frustración:
Testing Sostenible con TypeScript

Un curso de Testing, TDD y Diseño de Software creado por y para Developers

Una formación donde no solo aprendes crear tests de calidad.

Aprendes a diseñar mejor software (o a escribir mejor código, que en realidad es lo mismo).

A diseñar software testable y fácil de mantener.

Incluye vídeos teóricos y prácticos, soluciones a diferentes katas, ejercicios tipo test, repositorios de código… y alguna que otra sorpresa que te contaré más adelante.

Es un atajo.

Pero no un atajo para memorizar "lo que hay que hacer".

Es un atajo para entender el por qué.

¿Cómo lo hacemos?

Todo empieza con una masterclass inicial (y además puedes ver parte de ella de forma totalmente gratuita).

Es mucho más que una simple introducción.

Aquí ya empezarás a entender por qué tantos proyectos terminan secuestrados por su propio código.

Además de presentarnos y explicarte cómo está estructurada la formación, en esta masterclass vas a descubrir:

Y esto es solo una pincelada.

El grueso del curso empieza ahora, con tres bloques donde vamos a entrar a fondo en los principios, las técnicas y las prácticas que realmente marcan la diferencia en el día a día.

Bloque 1 — Fundamentos de Testing

"No nos pagan por hacer tests. Nos pagan por hacer software que funcione."
— Kent Beck

Y sin embargo, es imposible construir software que funcione bien y siga siendo fiable a medida que evoluciona, si no hay tests bien diseñados detrás.

De hecho, la primera regla del diseño simple dice que el código tiene que pasar correctamente los tests. Pero para eso, primero tiene que haber tests…

En este primer bloque vamos a sentar las bases.

No vamos a limitarnos a repetir definiciones.

Vas a entender qué es realmente el testing de software. Por qué es crítico para la calidad del código (y más aún en tiempos de la IA generativa).

Y cómo diseñar una batería de tests que no se convierta en una carga con el paso del tiempo.

Además, en este bloque aprenderás:

Bloque 2 — Tests Sostenibles

“Los tests no son solo para encontrar errores, sino para garantizar la estabilidad del diseño.” — Steve McConnell

Y para eso, tienen que ayudarte a avanzar con confianza, no a frenarte cada vez que algo cambia.

Es fácil escribir tests. Más aún con la ayuda de la IA.

Lo difícil es que sigan siendo útiles seis meses después.

El problema es que, en la mayoría de proyectos, el código de los tests se trata como código “de segunda”.

Se improvisa. No se refactoriza.

Y con el tiempo se convierte en un lastre.

En este bloque descubrirás:

Bloque 3 — Diseño de Software Dirigido por Tests

"TDD no es escribir los tests primero, es diseñar software de manera iterativa con feedback constante" — Martin Fowler

Hay mucha gente que piensa que el objetivo de TDD es conseguir una mejor cobertura de tests.

Otros creen que solo por hacer TDD crearán mejores diseños.

Otros que desarrollarán mejor por arte de magia.

Pero no.

Esto no es ni de lejos lo más importante.

Sin duda lo mejor de TDD es que te obliga a pensar antes de programar, siempre y cuando lo sepas aplicar.

Si, a pensar.

El simple hecho de tener que expresarlo con un test, te obliga a clarificar las ideas antes de ponerte a codificar.

El cuello de botella en los proyectos nunca ha sido pensar, sino todo lo contrario.

Y es que la mayoría de los desarrolladores lo que hacen es ponerse a “picar código” como pollo sin cabeza.

Sin pensar en las consecuencias. Sin pensar si esa es la solución más simple que pueden implementar.

En este bloque sin duda es el más importante, está dividido en dos partes, en los que aprenderás:

(Parte 1: Fundamentos y proceso)

(Parte 2: Técnicas, patrones y práctica)

Si aún no lo tienes claro, aquí tienes los contenidos detallados

Se trata de una formación de alto nivel organizada en 28 apartados que incluye más de 150 videos teóricos y prácticos. Las lecciones son concisas, valoramos tu tiempo tanto como el nuestro, así que no te haremos perderlo dando rodeos.

El curso empieza con una masterclass gratuita sin límite de tiempo y sin ningún compromiso (ni siquiera pedimos tarjeta de crédito).

Queremos que esta masterclass sirva como tu primer punto de contacto con nosotros y que te ayude a evaluar la calidad del contenido ¿no te convence? No hay problema, sin rencores.

Y aquí es donde esta formación se diferencia del resto: el soporte y las Code Reviews

En esta formación no hay grupos de Slack. Ni canales de Discord. Ni foros donde preguntas y nadie contesta.

Aquí me tienes a mí.

Si te atascas, si algo no te queda claro o si necesitas revisar un ejercicio, me escribes directamente por email.

Y te respondo personalmente.

Además, durante los primeros 6 meses puedes enviarme tus soluciones a las katas del curso y recibir feedback detallado sobre tu código.

Sin bots.
Sin asistentes.
Sin "tutores certificados".

Solo tú, tu código y yo.

La mejor forma de aprovechar este acompañamiento es esta:

Primero haces el ejercicio por tu cuenta.

Me mandas tu solución. Reviso el código y te doy feedback concreto.

Después ves cómo lo resuelvo en los vídeos del curso. Comparamos enfoques, criterios, decisiones de diseño.

Y una vez lo has visto, vuelves a escribir tu propia solución. Me la envías de nuevo.

Y revisamos juntos qué ha mejorado… y qué detalles aún pueden afinarse.

Ahí es donde de verdad interiorizas lo que has aprendido.

Porque no se trata de ver cómo lo hago. Se trata de que lo pienses tú, lo hagas tú y lo trabajemos juntos.

Este servicio de acompañamiento y Code Reviews te lo podría vender perfectamente por 100 €/mes (o lo que es lo mismo: 600 € los 6 meses).

Tú te lo llevas incluido, sin pagar un euro más.

Muy bien, pero ¿cuál es el precio de una formación tan completa?

Como dice Warren Buffet: “Precio es lo que pagas, valor es lo que recibes.”

O dicho de otra forma: "solo el necio confunde valor con precio".

La pregunta es: ¿cuánto vale para ti algo así?

No solo por la calidad y cantidad del contenido, más el acompañamiento y las Code Reviews.

Yo tengo claro lo que habría pagado:

¿2000€?

¿3000€?

(¿2000 o 3000€, Miguel? No te flipes…)

Te aseguro que he pagado formaciones mucho más caras que esta, y con mucho menos valor.

Pero claro, yo soy yo, y mis circunstancias.

La verdad que he tenido problemas para poner el precio… ¿Por qué? Porque esto no es solo otro curso online, son más de dos años de trabajo y en parte, también estoy vendiendo mi tiempo.

Aun así, había que poner una cifra. Y esta es la de ahora (que no será la definitiva y seguirá subiendo).

500€ impuestos incluidos. Pago único.

Fin de la historia.

Si quieres entrar a Testing Sostenible solo tienes que darle al botón de comprar hoy. En menos de 3 minutos estarás dentro.

Testing SostenibleTesting Sostenible con TypeScriptUn curso de Testing, TDD y Diseño de Software
creado por y para Developers
500COMPRAR HOYpaymentsSecured by Stripe with AES-256 Encryption
Una formación de alto nivel que incluye:
  • Acceso de por vida, nada de suscripciones.
  • Más de 150 videos teóricos y prácticos. Son lecciones concisas, no te haremos perder el tiempo dando rodeos.
  • Katas, ejercicios y repositorios de código para que aprendas haciendo.
  • Acceso a las actualizaciones que hagamos en las futuras ediciones del curso.
  • Soporte y revisiones de código durante 6 meses.

Preguntas raras (y no tanto) que me han hecho más de una vez

- ¿Es buena inversión?

LoL ¿Qué pregunta es esa? xD ¿Qué quieres que te diga?

“No, claro que no es buena inversión. Me pasé dos años junto a Carlos Blé preparando un curso con más de 150 vídeos… pero nah, no merece la pena.”

Anda que… Más preguntas, señoría.

- ¿Hay garantía de devolución?

No, en ningún caso. Si no tienes claro que te compense, mejor no la compres.

- ¿Qué conocimientos previos?

Saber programar, aunque sea lo mínimo. Vale tanto para juniors como para seniors, pero si partes desde cero, no es el momento.

- Programo en otro lenguaje, ¿me sirve?

Sí. El 90% del contenido es transversal y aplicable en cualquier lenguaje.

He elegido TypeScript como vehículo porque está creciendo rápido y es muy versátil. Pero el foco está en el diseño, no en el stack.

- ¿Podemos comprar una sola licencia para varios miembros del equipo?

No. La licencia es individual.

Aunque el formato sea digital, incluye soporte personalizado, revisiones de código y corrección del ejercicio.

Cada persona que accede necesita su propia inscripción. Si son varios en el equipo, cada desarrollador debe realizar su propia compra.

- ¿Para qué quiero aprender a hacer tests si ya me los hace Cursor o ChatGPT?

Porque si no sabes lo que estás haciendo, da igual quién escriba el test.

Siguiente pregunta señoría.

- ¿Tiene fechas o plazos?

No, tú decides cuándo la empiezas y cuándo la acabas. Una vez terminada podrás consultarlo las veces que quieras.

Esta no es la típica suscripción que tienes que pagar cada mes o cada año, pagas una vez y tendrás acceso para siempre.

- ¿Desde cuándo tengo acceso?

Desde el momento en que haces la compra.

- ¿Hay grupo de soporte?

Esto es importante que lo tengas claro: No hay grupo de Facebook, ni Slack, ni Discord.

Hay algo mejor.

Si tienes dudas (que las tendrás) me escribes directamente a mí por email. Te responderé personalmente.

Además, podrás enviarme tu solución sobre los ejercicios y katas propuestas para recibir feedback durante los 6 primeros meses tras la compra.

- Quiero aprovechar la oferta pero no voy a poder empezar el curso, ¿puedo posponer el soporte?

Sí. Escríbeme en cuanto hagas la compra y lo tengo en cuenta. Eso sí: si pasa un año y no has empezado, caduca.

- ¿Me revisas cualquier código?

No. El soporte no es una mentoría personalizada. Reviso los ejercicios y katas propuestas en el curso, no proyectos externos.

- ¿Es caro 500€?

El soporte por sí solo ya vale más que eso.

Si te parece caro, o no puedes permitírtelo, no la compres.

- ¿Se puede pagar a plazos?

Sí, con Klarna puedes dividir el pago en 3 cuotas sin intereses (disponible en varios países).

- ¿Puedo pagar por transferencia o criptomonedas?

Sí. Escríbeme a miguel.gomez@softwarecrafters.io y te explico cómo.

- ¿Haces factura?

Sí. Solo tienes que rellenar tus datos de facturación al comprar y la recibirás en 48h.

- ¿Es bonificable por FUNDAE?

No. Superamos el límite de alumnos permitido para estas ayudas.

Tampoco la diseñé pensando en ayudas públicas sino en contenido que realmente sirva.

- ¿Haces descuentos?

Nunca. Por simple respeto a los alumnos que ya están dentro. Ni por Black Friday, ni por Navidades, ni por el día del programador.

Hoy es el mejor precio al que puedes entrar. Mañana será igual o más alto. Nunca más bajo.

Testing SostenibleTesting Sostenible con TypeScriptUn curso de Testing, TDD y Diseño de Software
creado por y para Developers
500COMPRAR HOYpaymentsSecured by Stripe with AES-256 Encryption
Una formación de alto nivel que incluye:
  • Acceso de por vida, nada de suscripciones.
  • Más de 150 videos teóricos y prácticos. Son lecciones concisas, no te haremos perder el tiempo dando rodeos.
  • Katas, ejercicios y repositorios de código para que aprendas haciendo.
  • Acceso a las actualizaciones que hagamos en las futuras ediciones del curso.
  • Soporte y revisiones de código durante 6 meses.

Una colaboración de:

Colaboración