Si te dedicas a programar te habrás encontrado muchas veces en una situación en la que algo no va y no sabes qué pasa. Pero el problema real viene cuando no sabes cómo averiguar por qué pasa.
Por experiencia sé que es muy frustrante pero hay soluciones: golpear a un cojín para liberar la frustración, cambiar de trabajo o esperar a poder decir «lo hizo un mago». Pero suelen ser métodos poco efectivos.
En esta guía te presento una metodología sistemática para abordar y resolver el 99% de los errores que encontrarás en tu carrera como programador. Aunque está enfocada en la programación, estos principios son aplicables a la resolución de problemas en general.
¿Qué es un error?
La RAE dice en su primera acepción: «Concepto equivocado o juicio falso.»
En programación podríamos decir que hay como dos tipos principales de error:
No hace lo que debería hacer
Nuestra intención era crear una funcionalidad y lo que hemos programado no cumple los requisitos. Sea por poquito o sea porque no hace absolutamente nada.
Peta ¡Kabummm!
Hemos hecho algo que hace saltar una excepción, un error de sintaxis, etc., que hace que no funcione nada. Y lo hemos subido a PRO, sin probarlo antes, sin tests. Pantalla en blanco, alarma en la oficina y el cliente ya está llamando preguntando qué pasa, y recordando su SLA. Llegan los sudores fríos y nervios.
También puede ser algo a medias, una nueva funcionalidad que provoca que pete, el error lo vemos en local y/o no provoca la catástrofe antes dicha, etc.
¿Un error es lo mismo que un bug? Pues en un concepto amplio, claro, ¿por qué no? Si queremos ser más concretos pues no lo sé, no tengo todas las respuestas, pero esta guía se aplica para ambos.
Objetivo diagnosticar
Tenemos que tener muy claro qué objetivo buscamos porque eso nos ayudará a centrarnos en ello. Y nuestro objetivo, al menos el principal y más inmediato, no es solucionar el error: nuestro objetivo es diagnosticar.
Y necesitamos un buen diagnóstico, no nos sirve si parece una cosa pero luego no es así. Hemos de cerciorarnos, asegurarnos de que la enfermedad que tiene el paciente es la que creemos.
En nuestro caso si le damos el medicamento incorrecto seguramente no acabaremos con el paciente, pero sí podemos perder mucho tiempo, nuestro o del negocio.
Una vez con un buen diagnóstico seguramente la solución será trivial, o al menos podremos dar una estimación de tiempo necesario. Pero sin diagnóstico no podemos saber ni cuánto tiempo tardaremos en arreglarlo. Podría ser 1h podrían ser 100h.
Dicho todo esto veamos pues una serie de metodologías para encontrar los bugs y errores:
Verificación de Axiomas
¿Qué es un axioma en programación?
En matemáticas, un axioma es un principio indemostrable sobre el cual se construye una teoría. En programación, nuestros «axiomas» son las suposiciones básicas sobre las que construimos nuestro código:
- La configuración del entorno es correcta
- Las dependencias están instaladas
- Los permisos son adecuados
- Las versiones son compatibles
- Los datos de entrada son válidos
Por qué verificar axiomas:
- Los errores más comunes suelen estar en nuestras suposiciones básicas
- Ahorra tiempo al identificar problemas fundamentales
- Evita buscar soluciones complejas cuando el problema es simple
Un ejemplo práctico
Pongamos que en una web queremos tener un bloque de noticias en el que hagamos short polling para reemplazarlo cada x segundos si hay nuevo contenido. Nos ponemos manos a la obra y nos queda un código fetén: mantenible, limpio e incluso hermoso. El pequeño problema es que no funciona.
Respiramos hondo y empezamos a revisar de manera sistemática:
¿El JavaScript que hemos escrito se está ejecutando?
¿La llamada a la ruta de nuestro controlador / endpoint que devuelve el contenido se está realizando?
Si se llama, ¿qué devuelve esta ruta? ¿Es correcto lo que se devuelve?
Y así uno a uno vamos comprobando y resolviendo los problemas. Ten en cuenta que no suele ser solo un error lo que hace que algo no vaya, sino varios o muchos. Los errores son legión.
Divide y Vencerás (Bisección del problema)
No tengo muy claro cómo llamar a esta solución, pero lo cierto es que esta técnica me ha permitido de forma muy rápida dar con el problema incontables veces.
Metodología de bisección:
- Identificar estados base:
- Estado funcional conocido
- Estado con error conocido
- Proceso de bisección:
- Dividir el código/cambios en dos partes
- Verificar en qué mitad está el error
- Repetir el proceso en la mitad problemática
Ejemplos prácticos:
Bisección de código o funcionalidades:
Vamos quitando funcionalidades/código, idealmente el 50%. Si después de quitar sigue fallando igual es que estaba en la parte que no hemos quitado. Si ya no falla entonces el error estaba en la parte que hemos quitado.
Esta técnica es un concepto y la aplicación ya depende del sistema. Por ejemplo concreto de esto podría ser desactivar módulos/plugins:
- Los desactivamos todos
- Vemos que ya no sucede el error
- Activamos la mitad
- Vemos que ahora sí pasa.
- Desactivamos la mitad de los que habíamos activado.
- Vemos que ya no pasa
- Así hasta que detectemos el causante.
- Luego podemos empezar a hacer lo mismo dentro del código.
Todo esto no siempre es posible, ya que a veces tenemos dependencias, y si desactivamos algo puede hacer fallar otra cosa. Eso no significa que no sea una buena herramienta, pero hemos de tener esto en cuenta.
Bisección temporal:
- Último commit funcional: 15 de marzo
- Error actual: 20 de marzo
- Revisar commit del 17 de marzo
- Si funciona → Error entre 17-20
- Si falla → Error entre 15-17
- Finalmente cuando hemos dado con el commit exacto es más fácil examinar el código cambiado.
Git bisect
Git tiene una herramienta que automatiza esto: git bisect. Le marcas un commit «bueno» y otro «malo» y hace búsqueda binaria por ti, dejándote en cada commit intermedio para que lo pruebes y le digas si funciona o falla.
git bisect start
git bisect bad # el commit actual peta
git bisect good <sha-bueno> # último commit que funcionaba
# git te deja en el commit del medio: pruebas y...
git bisect good # o: git bisect bad
# repite hasta que git señale el commit culpable
git bisect reset # vuelve al estado originalResumen
Desactiva o tira para atrás a lo bestia hasta llegar a un estado en el que no falle. Luego retrocede hasta que vuelva a fallar y tendrás el causante.
Lectura y Comprensión del Error
Muchas veces el sistema se quejará y nos dirá dónde le duele. No hagamos como el Doctor House y escuchemos al paciente, que en este caso suele mentir menos.
¿Podemos leer el error?
Lo primero de todo es tener acceso al error. Si el error lo tenemos en local deberíamos haber configurado el entorno para que podamos ver el error en pantalla directamente. En cambio si está en producción el error seguramente no se verá en pantalla, pero podremos buscar en algún archivo de logs, sistema de monitorización, etc., donde poder verlo.
Si no tenemos nada de eso y el problema no es urgente, deja el problema y ponte a solucionar que puedas ver los errores. Imprescindible. A ciegas todo se complica exponencialmente. Y si el problema es urgente entonces deja el problema y ponte a solucionar que puedas ver los errores. Por si no lo has pillado, haz siempre que puedas ver los errores.
El arte de leer y entender
Una vez tenemos el error nuestra tarea es hacer una pequeña pausa, respirar tranquilamente y leerlo sin prisas.
Repito y concreto: leerlo, procesarlo y entenderlo sin prisas. Leer no es lo mismo que procesar.
Lee el mensaje completo
Lee todo el mensaje, no solo la primera línea excepto cuando el mensaje de error es también el stack trace, que puede ser kilométrico. Igualmente has de aprender a analizar los puntos clave del stack trace y si lo has de leer de arriba a abajo o al revés. Esto depende de tu lenguaje de programación.
El sitio web ha detectado un error inesperado. Inténtalo de nuevo más tarde.
Drupal\Core\Render\Component\Exception\InvalidComponentException: [url] NULL value found, but a string or an object is required. This may be because the property is empty instead of having data present. If possible fix the source data, use the |default() twig filter, or update the schema to allow multiple types./n[style] NULL value found, but an array or an object is required/n[classes] Array value found, but a string or an object is required in Drupal\Core\Theme\Component\ComponentValidator->validateProps() (line 203 of core/lib/Drupal/Core/Theme/Component/ComponentValidator.php).
Drupal\Core\Template\ComponentsTwigExtension->doValidateProps(Array, 'paltana:button') (Line: 110)
Drupal\Core\Template\ComponentsTwigExtension->validateProps(Array, 'paltana:button') (Line: 48)
__TwigTemplate_2d7b20eb5242809b7d6a6a82c8fed412->doDisplay(Array, Array) (Line: 387)
Twig\Template->yield(Array, Array) (Line: 343)
Twig\Template->display(Array) (Line: 358)
Twig\Template->render(Array) (Line: 35)
Twig\TemplateWrapper->render(Array) (Line: 1479)
Twig\Extension\CoreExtension::include(Object, Array, 'paltana:button', Array) (Line: 80)
__TwigTemplate_16612a3174921890aa8c974e16d0d909->block_paragraph(Array, Array) (Line: 431)
Twig\Template->yieldBlock('paragraph', Array, Array) (Line: 67)
__TwigTemplate_16612a3174921890aa8c974e16d0d909->doDisplay(Array, Array) (Line: 387)
Twig\Template->yield(Array, Array) (Line: 343)
Twig\Template->display(Array) (Line: 358)
Twig\Template->render(Array) (Line: 35)
Twig\TemplateWrapper->render(Array) (Line: 33)
twig_render_template('themes/custom/paltana/templates/paragraphs/paragraph--download.html.twig', Array) (Line: 348)
Drupal\Core\Theme\ThemeManager->render('paragraph', Array) (Line: 491)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 504)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 248)
Drupal\Core\Render\Renderer->render(Array) (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 228)
__TwigTemplate_73ced71a766ddc03c60ceb7d403a57c2___1427063222->block_content(Array, Array) (Line: 431)
Twig\Template->yieldBlock('content', Array, Array) (Line: 65)
__TwigTemplate_f07c1e4fdef9baa9d7498bea86a00caa->doDisplay(Array, Array) (Line: 387)
Twig\Template->yield(Array, Array) (Line: 208)
__TwigTemplate_73ced71a766ddc03c60ceb7d403a57c2___1427063222->doDisplay(Array, Array) (Line: 387)
Twig\Template->yield(Array) (Line: 63)
__TwigTemplate_73ced71a766ddc03c60ceb7d403a57c2->doDisplay(Array, Array) (Line: 387)
Twig\Template->yield(Array, Array) (Line: 343)
Twig\Template->display(Array) (Line: 358)
Twig\Template->render(Array) (Line: 35)
Twig\TemplateWrapper->render(Array) (Line: 33)
twig_render_template('modules/custom/omitsis_modular/templates/layout/layout--two-column-50-50.html.twig', Array) (Line: 348)
Drupal\Core\Theme\ThemeManager->render('layout__two_column_50_50', Array) (Line: 491)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 248)
Drupal\Core\Render\Renderer->render(Array) (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 67)
__TwigTemplate_1a7e80336362474b950315ef947431b8->block_paragraph(Array, Array) (Line: 431)
Twig\Template->yieldBlock('paragraph', Array, Array) (Line: 50)
__TwigTemplate_1a7e80336362474b950315ef947431b8->doDisplay(Array, Array) (Line: 387)
Twig\Template->yield(Array, Array) (Line: 343)
Twig\Template->display(Array) (Line: 358)
Twig\Template->render(Array) (Line: 35)
Twig\TemplateWrapper->render(Array) (Line: 33)
twig_render_template('themes/custom/paltana/templates/paragraphs/paragraph--layout.html.twig', Array) (Line: 348)
Drupal\Core\Theme\ThemeManager->render('paragraph', Array) (Line: 491)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 248)
Drupal\Core\Render\Renderer->render(Array) (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 73)
__TwigTemplate_d81c272727a5ab212b165d1f3c47fe86->doDisplay(Array, Array) (Line: 387)
Twig\Template->yield(Array, Array) (Line: 343)
Twig\Template->display(Array) (Line: 358)
Twig\Template->render(Array) (Line: 35)
Twig\TemplateWrapper->render(Array) (Line: 33)
twig_render_template('themes/custom/paltana/templates/field/field.html.twig', Array) (Line: 348)
Drupal\Core\Theme\ThemeManager->render('field', Array) (Line: 491)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 504)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 248)
Drupal\Core\Render\Renderer->render(Array) (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 97)
__TwigTemplate_3b4655940d9b39ac2c180506f10a25a0->doDisplay(Array, Array) (Line: 387)
Twig\Template->yield(Array, Array) (Line: 343)
Twig\Template->display(Array) (Line: 358)
Twig\Template->render(Array) (Line: 35)
Twig\TemplateWrapper->render(Array) (Line: 33)
twig_render_template('themes/custom/paltana/templates/content/page/node--page.html.twig', Array) (Line: 348)
Drupal\Core\Theme\ThemeManager->render('node', Array) (Line: 491)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 248)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 238)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 231)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 128)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 38)
Drupal\mercury_editor\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
Lo primero que hace uno al ver algo así es asustarse. Y luego mirar solo la parte de arriba, pero lo más importante es ver dónde ocurre ese error, línea y archivo. Ten en cuenta que a veces te puede indicar que un objeto instanciado en el fichero x está usando un método que no existe de una clase definida en un fichero y. Así que habrá varios ficheros involucrados.
Una vez identificado el error, has de reflexionar:
¿Sé a qué se está refiriendo? ¿Es código mío? → Manos a la obra y resuelve el error. Este tipo de errores suelen ser tonterías que tenemos claro cómo resolver, lo más complicado es identificar el error.
¿No sé a qué se refiere? ¿No es mi código? → Toca buscar por internet o usar IA. En un apartado posterior hay más info sobre este tema.
En el caso del ejemplo al principio me da una pista de lo que pasa, pero no dónde pasa. Pero si sigo más abajo veo algo más familiar: «paltana:button» y luego algo más abajo «paragraph–download.html.twig». Parece que está pasando algo en el archivo paragraph–download.html.twig al llamar al componente paltana:button.
Debugging Efectivo
Este apartado tal vez requiera un post para él solito, aquí solo algunos apuntes y recordatorios.
Siempre mejor un debugging en tiempo real que ir imprimiendo mensajes por el código. Pero mejor esto último que nada. Si es en local no debería haber excusas para no tener disponible esta opción. Si es en otros entornos entonces habrá que recurrir a otras estrategias. La primera intentar reproducir en lo posible en tu local lo que está ocurriendo en el entorno donde hemos detectado el error: Docker, bajar e instalar la base de datos, etc.
Si esto no lo podemos hacer entonces podemos mirar de tener un sistema para guardar mensajes, pero hay que tener mucho cuidado con el impacto que puede tener esto. Sistemas como New Relic pueden ayudar.
Una vez podemos empezar con el debugging es importante saber dónde poner los breakpoints. Si lo ponemos en la primera línea del código podemos estar horas hasta que lleguemos a la zona que da el error. Esta parte hay que combinarla con que sabemos dónde está dando el error (o no funciona como debería), habiendo usado una estrategia anterior.
Una vez en el sitio, un poco antes de donde da el error, hay que volver a comprobar axiomas.
¿Qué valor contiene esta variable? ¿Es lo que esperaba?
¿Entra en las partes del código que debería?
¿Devuelve lo que debería devolver?
Búsqueda en internet
Es algo evidente y que hacemos todos los días, pero aun así hay gente que encuentra lo que necesita rápidamente y otros que tardan más. Por lo que podemos decir que hay algunos trucos que nos ayudan a ser más efectivos. Aquí pongo algunos:
Pon siempre primero el nombre de la «cosa» en la que desarrollas, la más relevante. Por ejemplo, yo desarrollo en Drupal por lo que siempre pongo Drupal primero. Drupal está en PHP, pero a no ser que busque un error genérico de PHP nunca incluiré eso.
Luego pon siempre la versión, en mi caso sería Drupal 11.
Busca el error exacto, usando las comillas, pero con unos cuantos apuntes:
Longitud máxima del error
Pongamos el error kilométrico de antes, que no voy a copiar de nuevo para no petar internet. No nos interesa copiarlo todo, lo que nos interesa es buscar lo que otras personas hayan comentado de sus errores. Así que hemos de buscar lo que tengamos en común.
Pongamos esta primera parte del error:
Drupal\Core\Render\Component\Exception\InvalidComponentException: [url] NULL value found, but a string or an object is required. This may be because the property is empty instead of having data present. If possible fix the source data, use the |default() twig filter, or update the schema to allow multiple types./n[style] NULL value found, but an array or an object is required/n[classes] Array value found, but a string or an object is required in Drupal\Core\Theme\Component\ComponentValidator->validateProps() (line 203 of core/lib/Drupal/Core/Theme/Component/ComponentValidator.php)Aquí hay mucho trozo que no hace falta buscar, ya que con la primera parte ya será suficiente coincidencia. En el caso de que saliesen muchos resultados coincidentes entonces ya podríamos filtrar más, pero de entrada no es bueno, porque puede que la gente que preguntó por el error en internet no lo pusiera todo. Yo usaría solo esta parte:
Drupal\Core\Render\Component\Exception\InvalidComponentException: [url] NULL value found, but a string or an object is required.Quitar nombres específicos
Si busco esto directamente y con comillas lo más normal es que no encuentre nada, ya que puse [url] que es algo que muy posiblemente sea específico para mi proyecto. También podría ser que NULL tampoco salga, ya que el error no es que sea NULL, sino que no es un string o un objeto. Aunque esto probablemente lo podría dejar. Quedaría así entonces:
Drupal 10 Drupal\Core\Render\Component\Exception\InvalidComponentException: value found, but a string or an object is required.No he puesto comillas porque al quitar parte del texto nunca lo encontrará, pero si se puede mejor usar comillas. Si voy a un buscador usando esto veré unas cuantas coincidencias. Si no lo veo muy claro yo suelo abrir las primeras sin mirarlas en nuevos tabs y luego voy mirando una a una.
Filtrar por fechas
Otra cosa que puedo hacer cuando salen muchos resultados es filtrar por fecha. Esto en Google lo puedes hacer desde aquí:
Filtrar por dominio
Algo que hace mucha gente, en general, para evitar sitios de mala calidad es añadir Reddit al final de la consulta. Eso hace emerger resultados que al menos son más de persona. En nuestro caso podemos hacer lo mismo para Stack Overflow o usar directamente, si es en Google, site:stackoverflow.com para que solo muestre resultados de ese dominio.
¿Pero buscar teniendo a IA?
Pues es un recurso más, no confíes nunca en la IA de manera ciega, ten, usa y controla bien otros recursos. Y dicho esto pasemos a…
Chatbot IA
Esto es muy similar al apartado anterior pero los trucos son un poco diferentes. Además según lo que ponga es posible que en una semana ya no sea válido, así que pondré algo que espero sea poco caducable, como las ganas de procrastinar.
Aquí lo más importante es explicar lo que pasa, tu entorno, lo que quieres hacer, etc. Sí, le puedes decir la típica frase de eres un experto en x con 10 años de experiencia pero no creo que sea lo más importante y ni siquiera sé si hoy en día eso produce alguna diferencia.
Explícale bien todo
Cuando es un problema complicado le has de explicar todo. El contexto, tu entorno, lo que pretendes hacer, relaciones, campos, el error que te da, tu tipo de sangre, etc. Todo. Piensa que el chatbot como si fueras tú y lo que necesitarías que te informaran. Si usas un agente como Claude Code podrá descubrir muchas de estas cosas por sí solo, pero no siempre lo hace. Mientras más información relevante mejor.
Sí, le puedes pasar el error y ya está, e incluso es posible que te ayude, pero no será muy diferente a una búsqueda en internet.
En lenguaje natural
Escríbele en lenguaje natural y podrá entenderlo mucho mejor que si pones palabras sueltas como haces en un buscador. No es lo mismo describir: «node type event entity reference field to taxonomy» que decir: «Tengo un campo en un nodo de tipo evento que es una entity reference a un vocabulario que se llama event type». Lo primero se podría interpretar de muchas maneras, lo segundo de bastantes menos.
Por ejemplo, en el caso anterior yo le diría:
Usando Drupal 10, Mercury Editor, Layout Paragraphs y SDC (Single Directory Components) he añadido un nuevo paragraph llamado download. Pero me da un error que no sé qué puede ser:
[aquí el error que no pienso volver a poner de nuevo]
¿Sabes qué puede ser? Muchas gracias.
PD: Sed siempre amables y agradecidos. Cuando las máquinas se rebelen tal vez se apiaden de aquel humano que era amable.
PD2: No creo.
Itera
Es muy posible que con la primera respuesta no sea suficiente, tendrás que irle diciendo qué funciona y qué no, y dando más detalles.
Aquí es importante darte cuenta si has entrado en un bucle y parar. Aunque no sepa la respuesta el chatbot no te lo va a decir y te puede hacer perder mucho tiempo. Es tu responsabilidad parar a tiempo.
Demostrar hipótesis
Si esto sirve para nosotros lo hemos de aplicar también a la IA. Es muy normal que la IA te diga: «¡Ya he encontrado el problema! Es por esto y aquello, si cambiamos lo de más allá ya funcionará» Y tú muy contento le dices que adelante. Pero las cosas se complican y aún no se resuelve.
«¡Ah, ya he visto qué está pasando! Si hacemos esto seguro que funciona». Y ya un poco menos entusiasta le dejas hacer. Pero, ooohh, tampoco llega a buen puerto.
«Confía en mí, colega, antes no pero ahora seguro que sí»…
Y después de un buen rato, con ganas de asesinar a una cosa sin vida, te preguntas por el sentido de tu vida.
Para evitar esta situación has de pedirle pruebas de sus afirmaciones (o comprobarlas tú mismo).
«Esto no funciona por esto y aquello». «¿Has comprobado tu hipótesis? Dime cómo probarías que esto que dices es cierto, con los mínimos cambios y lo más rápido posible»
No copies y pegues sin leerte el código
Esto es casi lo más importante, internet y los repos de código se están llenando de código basura porque no revisamos lo que las IA nos sugieren.
A mí también me ha pasado, aceptar una sugerencia que no era ideal y subirlo a master. Pero fue mi culpa y mi responsabilidad. No valen excusas.
Es tu responsabilidad el código que subas, así que has de mirar lo que hace y mejorarlo o no aceptarlo directamente si es malo. Puedes usar a la misma IA para que te lo mejore, pero has de entender qué está haciendo, si no lo entiendes no lo subas.
Técnica del Pato de Goma
¿Qué es?
Método de debugging donde explicas tu código a un objeto inanimado/persona. Recomiendo que sea una persona porque te podrá ayudar también con su experiencia y es más fácil hablarle a una persona que a un patito. Bueno, depende de la persona. Yo practicaba esta técnica pero no conocía el nombre hasta que, ahora un excompañero, me contó cómo se llamaba. Si este post llega a mucha gente y alguien lo conoce, pasádselo. ¡Un saludo, Marçal!
¿Por qué funciona?
Lo más importante es que te obliga a estructurar bien tu pensamiento. Cuando pensamos eso puede ser un caos en tu cabeza, que le ves sentido pero que muy posiblemente no esté todo conectado.
Cuando nos obligamos a explicar algo para que alguien lo entienda hemos de estructurar ese pensamiento, pasa a ser algo concreto. Mientras haces ese proceso tú mismo te puedes dar cuenta de suposiciones incorrectas, pasos que te faltan o fallos en la lógica.
¿Cómo aplicarlo?
Si puedes busca a una persona que entienda algo del tema. No es necesario, pero si entiende mejor, te podrá preguntar y ayudar directamente. No es imprescindible para esta técnica.
Por supuesto, explica en voz alta, aunque se lo estés diciendo a un patito.
Ve paso a paso, contando qué esperas en cada caso. Por ejemplo:
«Estoy programando una calculadora de tu peso ideal pero no acabo de entender por qué no me funciona. Tengo un formulario con el peso y la altura y cuando se hace submit tengo una función que espera el peso, la altura y la edad. Ui, claro, no le estoy pasando la edad. Tengo que añadir eso al formulario y pasársela.»
Apagar y encender
Esto es algo más metafórico, pero sí apagar y encender muchas veces ayuda a resolver un problema.
Si el problema lo tienes en tu local y antes no pasaba y no se te ocurre nada: apaga y enciende.
Si has instalado un plugin/módulo, etc. y no funciona y no sabes por qué: apaga y enciende, es decir, desinstala el módulo y vuelve a instalarlo.
Si has creado una tabla, un nuevo registro, etc.: apaga y enciende, es decir, bórralo y vuélvelo a crear de nuevo.
Si ya no sabes qué hacer y te has quedado sin ideas: apaga y enciende, es decir, levántate, date una vuelta o cambia de tarea. Mañana tal vez se te ocurra la solución. A mí esto me pasa mucho, me atasco en algo, y lo dejo para el día siguiente. Y mientras voy caminando, en la ducha, cocinando, etc., se me ocurre una solución.
Pidiendo ayuda
Cuando pides ayuda lo más importante es que has de valorar el tiempo de la persona que te pueda ayudar. Se lo has de poner fácil, has de ser amable y agradecido.
Cuándo pedir ayuda
Como todo, depende, pero hay que intentar pedir ayuda en el momento óptimo. ¿Cuándo sería eso? Si hemos agotado todo el tiempo que teníamos asignado tiene pinta que es muy tarde. ¿Pero cuánto antes?
Hay gente que nunca pide ayuda, le sabe mal molestar, le da vergüenza, cree que no le podrán ayudar, etc. Por lo que sea le cuesta mucho hacerlo. ¡A esta gente os diría que tenéis que pedir ayuda antes!
Hay otra gente que pide ayuda a la primera de cambio, sin haberse mirado antes el problema, sin haber aplicado ninguna de estas técnicas. A vosotros os diría RTFM, pero como soy una persona amable y cordial os solicito muy efusivamente que antes de preguntar os lo miréis un poco.
Como regla de oro si llevas el 15% del tiempo asignado y no has avanzado nada, has intentado aplicar las técnicas anteriores y sigues atascado es un buen momento para preguntar.
El coste de ser preguntado
Como persona en mi empresa que suele ser el preguntado siempre animo a que no se corten y me pregunten lo que se necesite. He visto más casos del primer tipo que del segundo.
Pero como todo en la vida tiene un coste y es bueno conocerlo. Se calcula que cuando alguien está concentrado una pequeña interrupción hace que necesite 15 minutos para volver al estado anterior. Así, una pregunta de 1 segundo puede suponer realmente 15 minutos de tiempo.
Esto es cierto con niveles altos de necesidad de concentración, hay tareas que al ser simples se pueden interrumpir con poco coste. Otras que es mejor directamente no interrumpir.
Pero como persona que pregunta no vas a saber en qué momento está tu mentor, así que si es por Slack o similares nunca te cortes. «Oye, cuando tengas un momento, ¿me podrías echar una mano con [pequeña descripción del problema]?»
Cómo pedir ayuda efectivamente: ponlo fácil.
Recuerda que has de valorar el tiempo de las personas que te podrían responder. Si es en directo ten preparado todo lo posible. Si lo vas a dejar escrito detalla el problema claramente, crea ejemplos reproducibles y lista lo que ya hayas intentado.
Dónde pedir ayuda
- Canales de Slack/Discord del proyecto
- Páginas de preguntas/respuestas como Stack Overflow.
- Foros específicos
- Comunidades locales
- Mentores/compañeros de trabajo
Dónde puedas, poner una pregunta también ayudará a otras personas y sitios como Stack Overflow se nutren de tus preguntas, así que no te cortes. Pero comprueba siempre antes si esa pregunta ya ha sido respondida. Si crees que hay cosas similares pero no iguales, enlázalo y coméntalo en tu pregunta.
Y si lo resolviste en otro lado, añade una respuesta indicando cómo lo hiciste. Igual que tú tuviste la duda, habrá más gente que podrá encontrar tu pregunta y tu respuesta.
¿Y si no se soluciona? Plan B
Todo esfuerzo debe merecer la pena y las circunstancias pueden variar mucho, así que cada uno ha de valorar su caso.
Imagina que estás en un avión y el motor se rompe. Si sabes de motores tal vez puedas arreglarlo a tiempo antes de que sea demasiado tarde. Pero lo primero que has de tener muy claro es el tiempo de no retorno: ¿hasta cuándo estoy a tiempo de tirarme en paracaídas y no morir intentando reparar el motor? Porque si el avión llega al suelo seguro que ya no estoy a tiempo, y siempre habrá una altura necesaria para que se pueda abrir el paracaídas.
Pues ese momento lo tengo que tener 100% claro y tener un plan B.
Esto en el mundo del desarrollo web se traduce en fechas de entrega, límites de presupuesto del cliente, etc. Por ejemplo, el cliente ha reportado un error pero tenemos que tener claro:
- ¿Cuánto le importa este error?
- ¿Cuántas horas como máximo desea dedicarle a este error si no se resuelve?
- Si no se resuelve, ¿podríamos mitigarlo de otra manera?
- ¿Hay una fecha de entrega máxima para solucionar esto?
Conclusión
Es muy frustrante y estresante ir contrarreloj para resolver un error, algo que a priori puedes desconocer totalmente el origen y causa. Pero hay esperanza.
No tendrás que aplicar todos estos recursos, y en algunos momentos algunos serán mejores que otros o será una combinación de ellos.
Tendrás que irlo aprendiendo con el tiempo, incluso tendrás tus propios recursos que yo no he puesto. Lo importante es nunca quedarse parado y no saber qué hacer, siempre seguir intentándolo.
Para mí lo más importante es si te he podido ayudar, pero si además compartes este post con todo el mundo, pues oye, mucho mejor.
