Omitsis

Guia GAIRABé definitiva per solucionar errors en programar

Client
  • Omitsis
Tecnologies
Serveis
Data
  • 12/05/2026

Si et dediques a programar segur que t’has trobat moltes vegades en una situació en què alguna cosa no va i no saps què passa. Però el problema real ve quan no saps com esbrinar per què passa.

Per experiència sé que és molt frustrant, però hi ha solucions: pegar a un coixí per alliberar la frustració, canviar de feina o esperar a poder dir “ho va fer un mag”. Però acostumen a ser mètodes poc efectius.

En aquesta guia et presento una metodologia sistemàtica per abordar i resoldre el 99% dels errors que trobaràs en la teva carrera com a programador. Tot i que està enfocada a la programació, aquests principis són aplicables a la resolució de problemes en general.

Què és un error?

La primera accepció del diccionari diu: “Concepte equivocat o judici fals.”

En programació podríem dir que hi ha com dos tipus principals d’error:

No fa el que hauria de fer

La nostra intenció era crear una nova funcionalitat i el que hem programat no compleix els requisits. Sigui per poquet o sigui perquè no fa absolutament res.

Peta! Pataplaf!

Hem fet alguna cosa que fa saltar una excepció, un error de sintaxi, etc., que fa que no funcioni res. I ho hem pujat a prod, sense provar-ho abans, sense tests. Pantalla en blanc, alarma a l’oficina i el client ja està trucant preguntant què passa, i recordant el seu SLA. Arriben les suors fredes i els nervis.

També pot ser alguna cosa a mitges, una nova funcionalitat que provoca que peti, l’error el veiem en local i/o no provoca la catàstrofe abans dita, etc.

Un error és el mateix que un bug? Doncs en un concepte ampli, és clar, per què no? Si volem ser més concrets doncs no ho sé, no tinc totes les respostes, però aquesta guia s’aplica per a tots dos.

Objectiu diagnosticar

Hem de tenir molt clar quin objectiu busquem perquè això ens ajudarà a centrar-nos-hi. I el nostre objectiu, almenys el principal i més immediat, no és solucionar l’error: el nostre objectiu és diagnosticar.

I necessitem un bon diagnòstic; no ens serveix si sembla una cosa però després no és així. Hem d’assegurar-nos que la malaltia que té el pacient és la que creiem.

En el nostre cas, si li donem el medicament incorrecte segurament no acabarem amb el pacient, però sí que podem perdre molt de temps, nostre o del negoci.

Un cop tenim un bon diagnòstic segurament la solució serà trivial, o almenys podrem donar una estimació del temps necessari. Però sense diagnòstic no podem saber ni quant de temps trigarem a arreglar-ho. Podria ser 1h, podrien ser 100h.

Dit tot això, vegem una sèrie de metodologies per trobar els bugs i errors:

Verificació d’Axiomes

Què és un axioma en programació?

En matemàtiques, un axioma és un principi indemostrable sobre el qual es construeix una teoria. En programació, els nostres “axiomes” són les suposicions bàsiques sobre les quals construïm el nostre codi:

  • La configuració de l’entorn és correcta
  • Les dependències estan instal·lades
  • Els permisos són adequats
  • Les versions són compatibles
  • Les dades d’entrada són vàlides

Per què verificar axiomes:

  • Els errors més comuns acostumen a ser en les nostres suposicions bàsiques
  • Estalvia temps en identificar problemes fonamentals
  • Evita buscar solucions complexes quan el problema és simple

Un exemple pràctic

Posem que en un web volem tenir un bloc de notícies en què fem short polling per reemplaçar-lo cada x segons si hi ha contingut nou. Ens hi posem i ens queda un codi del més top: mantenible, net i fins i tot bonic. El petit problema és que no funciona.

Respirem fons i comencem a revisar de manera sistemàtica:

El JavaScript que hem escrit s’està executant?

La crida a la ruta del nostre controlador / endpoint que retorna el contingut s’està realitzant?

Si s’hi crida, què retorna aquesta ruta? És correcte el que es retorna?

I així, un a un, anem comprovant i resolent els problemes. Tingues en compte que normalment no és només un error el que fa que alguna cosa no vagi, sinó diversos o molts. Els errors són legió.

Divideix i Venceràs (Bisecció del problema)

No tinc gaire clar com anomenar aquesta solució, però la veritat és que aquesta tècnica m’ha permès, de manera molt ràpida, trobar el problema incomptables vegades.

Metodologia de bisecció:

  1. Identificar estats base:
  • Estat funcional conegut
  • Estat amb error conegut
  1. Procés de bisecció:
  • Dividir el codi/canvis en dues parts
  • Verificar en quina meitat hi ha l’error
  • Repetir el procés a la meitat problemàtica

Exemples pràctics:

Bisecció de codi o funcionalitats:

Anem traient funcionalitats/codi, idealment el 50%. Si després de treure’l continua fallant igual és que era a la part que no hem tret. Si ja no falla, llavors l’error era a la part que hem tret.

Aquesta tècnica és un concepte i l’aplicació depèn del sistema. Un exemple concret podria ser desactivar mòduls/plugins:

  1. Els desactivem tots
  2. Veiem que ja no passa l’error
  3. Activem la meitat
  4. Veiem que ara sí que passa.
  5. Desactivem la meitat dels que havíem activat.
  6. Veiem que ja no passa
  7. Així fins que detectem el causant.
  8. Després podem començar a fer el mateix dins del codi.

Tot això no sempre és possible, ja que de vegades tenim dependències, i si desactivem alguna cosa pot fer fallar una altra. Això no significa que no sigui una bona eina, però ho hem de tenir en compte.

Bisecció temporal:

  • Últim commit funcional: 15 de març
  • Error actual: 20 de març
  • Revisar el commit del 17 de març
  • Si funciona → Error entre el 17 i el 20
  • Si falla → Error entre el 15 i el 17
  • Finalment, quan hem trobat el commit exacte, és més fàcil examinar el codi canviat.

Git bisect

Git té una eina que automatitza això: git bisect. Li marques un commit “bo” i un altre de “dolent” i fa cerca binària per tu, deixant-te a cada commit intermedi perquè el provis i li diguis si funciona o falla.

git bisect start
git bisect bad                 # el commit actual peta
git bisect good <sha-bo>       # últim commit que funcionava
# git et deixa al commit del mig: prova'l i...
git bisect good                # o: git bisect bad
# repeteix fins que git assenyali el commit culpable
git bisect reset               # torna a l'estat original

Resum

Desactiva o tira enrere a lo bèstia fins arribar a un estat en què no falli. Després torna endavant fins que torni a fallar i tindràs el causant.

Lectura i Comprensió de l’Error

Moltes vegades el sistema es queixarà i ens dirà on li fa mal. No fem com el Dr. House i escoltem el pacient, que en aquest cas acostuma a mentir menys.

Podem llegir l’error?

El primer de tot és tenir accés a l’error. Si el tenim en local hauríem d’haver configurat l’entorn perquè puguem veure l’error a la pantalla directament. En canvi, si és en producció, l’error segurament no es veurà a la pantalla, però podrem buscar en algun arxiu de logs, sistema de monitoratge, etc., on poder-lo veure.

Si no tenim res d’això i el problema no és urgent, deixa el problema i posa’t a arreglar-ho perquè puguis veure els errors. Imprescindible. A cegues tot es complica exponencialment. I si el problema és urgent, llavors deixa el problema i posa’t a arreglar-ho perquè puguis veure els errors. Per si no ho has pillat: fes sempre que puguis veure els errors.

L’art de llegir i entendre

Un cop tenim l’error la nostra tasca és fer una petita pausa, respirar tranquil·lament i llegir-lo sense presses.

Repeteixo i concreto: llegir-lo, processar-lo i entendre’l sense presses. Llegir no és el mateix que processar.

Llegeix el missatge sencer

Llegeix tot el missatge, no només la primera línia, excepte quan el missatge d’error és també el stack trace, que pot ser quilomètric. Igualment has d’aprendre a analitzar els punts clau del stack trace i si l’has de llegir de dalt a baix o al revés. Això depèn del teu llenguatge de programació.

The website encountered an unexpected error. Please try again later.

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)

El primer que fa un en veure una cosa així és espantar-se. I després mirar només la part de dalt, però el més important és veure on passa aquest error, línia i arxiu. Tingues en compte que de vegades et pot indicar que un objecte instanciat al fitxer x està utilitzant un mètode que no existeix d’una classe definida al fitxer y. Així que hi haurà diversos fitxers involucrats.

Un cop identificat l’error, has de reflexionar:

Sé a què s’està referint? És codi meu? → Mans a l’obra i resol l’error. Aquest tipus d’errors acostumen a ser ximpleries que tenim clar com resoldre, el més complicat és identificar l’error.

No saps a què es refereix? No és el teu codi? → Toca buscar per internet o usar IA. En un apartat posterior hi ha més info sobre aquest tema.

En el cas de l’exemple del principi em dona una pista del que passa, però no on passa. Però si segueixo més avall veig alguna cosa més familiar: “paltana:button” i després una mica més avall “paragraph–download.html.twig”. Sembla que està passant alguna cosa al fitxer paragraph–download.html.twig en cridar el component paltana:button.

Debugging Efectiu

Aquest apartat potser requereix un post per a ell sol; aquí només alguns apunts i recordatoris.

Sempre és millor un debugging en temps real que anar imprimint missatges pel codi. Però millor això últim que res. Si és en local no hauria d’haver-hi excuses per no tenir disponible aquesta opció. Si és en altres entorns, llavors hauràs de recórrer a altres estratègies. La primera, intentar reproduir tant com es pugui en el teu local el que està passant en l’entorn on hem detectat l’error: Docker, baixar i instal·lar la base de dades, etc.

Si això no ho podem fer, llavors podem mirar de tenir un sistema per desar missatges, però hem de tenir molt de compte amb l’impacte que pot tenir això. Sistemes com New Relic poden ajudar.

Un cop podem començar amb el debugging és important saber on posar els breakpoints. Si el posem a la primera línia del codi podem passar hores fins arribar a la zona que dona l’error. Aquesta part s’ha de combinar amb saber on està donant l’error (o no funciona com hauria), havent fet servir una estratègia anterior.

Un cop al lloc, una mica abans d’on dona l’error, cal tornar a comprovar axiomes.

Quin valor conté aquesta variable? És el que esperava?

Entra a les parts del codi que hauria d’entrar?

Retorna el que hauria de retornar?

Cerca a internet

És una cosa evident i que fem tots els dies, però tot i així hi ha gent que troba el que necessita ràpidament i d’altres que triguen més. Per la qual cosa podem dir que hi ha alguns trucs que ens ajuden a ser més efectius. Aquí en poso alguns:

Posa sempre primer el nom de la “cosa” en què desenvolupes, la més rellevant. Per exemple, jo desenvolupo en Drupal, per la qual cosa sempre poso Drupal primer. Drupal funciona sobre PHP, però a no ser que busqui un error genèric de PHP mai inclouré això.

Després posa sempre la versió, en el meu cas seria Drupal 11.

Busca l’error exacte, fent servir les cometes, però amb uns quants apunts:

Longitud màxima de l’error

Posem l’error quilomètric d’abans, que no copiaré de nou per no petar internet. No ens interessa copiar-lo tot, el que ens interessa és buscar el que altres persones hagin comentat dels seus errors. Així que hem de buscar el que tinguem en comú.

Posem aquesta primera part de l’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í hi ha molt tros que no cal buscar, ja que amb la primera part ja n’hi haurà prou amb la coincidència. En el cas que sortissin molts resultats coincidents, llavors ja podríem filtrar més, però d’entrada no és bo, perquè pot ser que la gent que va preguntar per l’error a internet no ho posés tot. Jo faria servir només aquesta part:

Drupal\Core\Render\Component\Exception\InvalidComponentException: [url] NULL value found, but a string or an object is required.

Treure noms específics

Si busco això directament i amb cometes el més normal és que no trobi res, ja que vaig posar [url] que és una cosa que molt possiblement sigui específica per al meu projecte. També podria ser que NULL tampoc surti, ja que l’error no és que sigui NULL, sinó que no és un string o un objecte. Tot i que això probablement ho podria deixar. Quedaria així llavors:

Drupal 10 Drupal\Core\Render\Component\Exception\InvalidComponentException: value found, but a string or an object is required.

No he posat cometes perquè en treure part del text mai ho trobarà, però si es pot, millor fer servir cometes. Si vaig a un cercador usant això veuré unes quantes coincidències. Si no ho veig gaire clar, jo acostumo a obrir les primeres sense mirar-les en pestanyes noves i després les vaig mirant una a una.

Filtrar per dates

Una altra cosa que puc fer quan surten molts resultats és filtrar per data. Això a Google ho pots fer des d’aquí:

Per exemple, per a coses que necessito que siguin recents va molt bé, perquè de vegades hi ha molta documentació però és antiga.

Filtrar per domini

Una cosa que fa molta gent, en general, per evitar llocs de mala qualitat és afegir Reddit al final de la consulta. Això fa emergir resultats que almenys són més de persona. En el nostre cas podem fer el mateix per a Stack Overflow o fer servir directament, si és a Google, site:stackoverflow.com perquè només mostri resultats d’aquest domini.

Però buscar tenint la IA?

Doncs és un recurs més, no confiïs mai en la IA de manera cega, tingues, fes servir i controla bé altres recursos. I dit això passem a…

Chatbot IA

Això és molt semblant a l’apartat anterior però els trucs són una mica diferents. A més, segons el que posi és possible que en una setmana ja no sigui vàlid, així que posaré alguna cosa que espero que sigui poc caducable, com les ganes de procrastinar.

Aquí el més important és explicar el que passa, el teu entorn, el que vols fer, etc. Sí, li pots dir la típica frase d’ets un expert en x amb 10 anys d’experiència però no crec que sigui el més important i ni tan sols sé si avui dia això produeix cap diferència.

Explica-li bé tot

Quan és un problema complicat li has d’explicar tot. El context, el teu entorn, el que pretens fer, relacions, camps, l’error que et dona, el teu tipus de sang, etc. Tot. Pensa que el chatbot és com si fossis tu i el que necessitaries que t’informessin. Si fas servir un agent com Claude Code podrà descobrir moltes d’aquestes coses per ell mateix, però no sempre ho fa. Mentre més informació rellevant, millor.

Sí, li pots passar l’error i ja està, i fins i tot és possible que t’ajudi, però no serà gaire diferent d’una cerca a internet.

En llenguatge natural

Escriu-li en llenguatge natural i ho podrà entendre molt millor que si poses paraules soltes com fas en un cercador. No és el mateix descriure: “node type event entity reference field to taxonomy” que dir: “Tinc un camp en un node de tipus esdeveniment que és una entity reference a un vocabulari que es diu event type”. El primer es podria interpretar de moltes maneres, el segon de força menys.

Per exemple, en el cas anterior jo li diria:

Fent servir Drupal 10, Mercury Editor, Layout Paragraphs i SDC (Single Directory Components) he afegit un nou paragraph anomenat download. Però em dona un error que no sé què pot ser:

[aquí l’error que no penso tornar a posar]

Saps què pot ser? Moltes gràcies.

PD: Sigueu sempre amables i agraïts. Quan les màquines es rebel·lin potser s’apiadaran d’aquell humà que era amable.

PD2: No m’ho crec.

Itera

És molt possible que amb la primera resposta no n’hi hagi prou, hauràs d’anar-li dient què funciona i què no, i donant més detalls.

Aquí és important adonar-te si has entrat en un bucle i parar. Encara que no sàpiga la resposta, el chatbot no t’ho dirà i et pot fer perdre molt de temps. És la teva responsabilitat parar a temps.

Demostrar hipòtesis

Si això ens serveix a nosaltres ho hem d’aplicar també a la IA. És molt normal que la IA et digui: “Ja he trobat el problema! És per això i allò, si canviem allò altre ja funcionarà.” I tu molt content li dius que endavant. Però les coses es compliquen i encara no es resol.

“Ah, ja he vist què està passant! Si fem això segur que funciona.” I ja una mica menys entusiasta el deixes fer. Però, ooohh, tampoc arriba a bon port.

“Confia en mi, col·lega, abans no però ara segur que sí”…

I després d’una bona estona, amb ganes d’assassinar una cosa sense vida, et preguntes pel sentit de la teva vida.

Per evitar aquesta situació li has de demanar proves de les seves afirmacions (o comprovar-les tu mateix).

“Això no funciona per això i allò.” “Has comprovat la teva hipòtesi? Digues-me com provaries que això que dius és cert, amb els mínims canvis i el més ràpid possible.”

No copiïs i enganxis sense llegir-te el codi

Això és gairebé el més important; internet i els repos de codi s’estan omplint de codi escombraria perquè no revisem el que les IA ens suggereixen.

A mi també m’ha passat, acceptar un suggeriment que no era ideal i pujar-ho a master. Però va ser culpa meva i responsabilitat meva. No valen excuses.

És responsabilitat teva el codi que pugis, així que has de mirar el que fa i millorar-ho o no acceptar-ho directament si és dolent. Pots fer servir la mateixa IA perquè t’ho millori, però has d’entendre què està fent; si no ho entens, no ho pugis.

Tècnica de l’Ànec de Goma

Què és?

Mètode de debugging on expliques el teu codi a un objecte inanimat/persona. Recomano que sigui una persona perquè et podrà ajudar també amb la seva experiència i és més fàcil parlar a una persona que a un aneguet. Bé, depèn de la persona. Jo practicava aquesta tècnica però no en sabia el nom fins que, ara excompany, em va explicar com es deia. Si aquest post arriba a molta gent i algú el coneix, passeu-li. Una salutació, Marçal!

Per què funciona?

El més important és que t’obliga a estructurar bé el teu pensament. Quan pensem això pot ser un caos al cap, que li veus sentit però que molt possiblement no estigui tot connectat.

Quan ens obliguem a explicar alguna cosa perquè algú l’entengui hem d’estructurar aquest pensament, passa a ser una cosa concreta. Mentre fas aquest procés tu mateix et pots adonar de suposicions incorrectes, passos que et falten o errors en la lògica.

Com aplicar-ho?

Si pots busca una persona que entengui alguna cosa del tema. No és necessari, però si ho entén millor, et podrà preguntar i ajudar directament. No és imprescindible per a aquesta tècnica.

Per descomptat, explica en veu alta, encara que l’hi estiguis dient a un aneguet.

Ves pas a pas, explicant què esperes en cada cas. Per exemple:

“Estic programant una calculadora del teu pes ideal però no acabo d’entendre per què no em funciona. Tinc un formulari amb el pes i l’alçada i quan es fa submit tinc una funció que espera el pes, l’alçada i l’edat. Ui, clar, no li estic passant l’edat. Haig d’afegir això al formulari i passar-la-hi.”

Apagar i encendre

Això és una mica més metafòric, però sí, apagar i encendre moltes vegades ajuda a resoldre un problema.

Si el problema el tens al teu local i abans no passava i no se t’acut res: apaga i encén.

Si has instal·lat un plugin/mòdul, etc. i no funciona i no saps per què: apaga i encén, és a dir, desinstal·la el mòdul i torna-l’hi a instal·lar.

Si has creat una taula, un nou registre, etc.: apaga i encén, és a dir, esborra’l i torna’l a crear de nou.

Si ja no saps què fer i t’has quedat sense idees: apaga i encén, és a dir, aixeca’t, fes una volta o canvia de tasca. Demà potser se t’acudeixi la solució. A mi això em passa molt, m’encallo en alguna cosa i ho deixo per l’endemà. I mentre vaig caminant, a la dutxa, cuinant, etc., se m’acut una solució.

Demanant ajuda

Quan demanes ajuda el més important és que has de valorar el temps de la persona que et pugui ajudar. L’hi has de posar fàcil, has de ser amable i agraït.

Quan demanar ajuda

Com tot, depèn, però cal intentar demanar ajuda en el moment òptim. Quan seria això? Si hem esgotat tot el temps que teníem assignat té pinta que és molt tard. Però quant abans?

Hi ha gent que no demana mai ajuda, li sap greu molestar, li fa vergonya, creu que no la podran ajudar, etc. Per la raó que sigui li costa molt fer-ho. A aquesta gent us diria que heu de demanar ajuda abans!

Hi ha una altra gent que demana ajuda a la primera de canvi, sense haver-se mirat abans el problema, sense haver aplicat cap d’aquestes tècniques. A vosaltres us diria RTFM, però com que sóc una persona amable i cordial us sol·licito molt efusivament que abans de preguntar us ho mireu una mica.

Com a regla d’or, si portes el 15% del temps assignat i no has avançat res, has intentat aplicar les tècniques anteriors i continues encallat, és un bon moment per preguntar.

El cost de ser preguntat

Com a persona a la meva empresa que acostumo a ser el preguntat sempre animo que no es tallin i em preguntin el que es necessiti. He vist més casos del primer tipus que del segon.

Però com tot a la vida té un cost i és bo conèixer-lo. Es calcula que quan algú està concentrat una petita interrupció fa que necessiti 15 minuts per tornar a l’estat anterior. Així, una pregunta d’1 segon pot suposar realment 15 minuts de temps.

Això és cert amb nivells alts de necessitat de concentració, hi ha tasques que en ser simples es poden interrompre amb poc cost. D’altres que és millor directament no interrompre.

Però com a persona que pregunta no sabràs en quin moment està el teu mentor, així que si és per Slack o similars mai et tallis. “Ei, quan tinguis un moment, em podries fer un cop de mà amb [petita descripció del problema]?”

Com demanar ajuda efectivament: posa-ho fàcil.

Recorda que has de valorar el temps de les persones que et podrien respondre. Si és en directe tingues preparat tot el possible. Si ho deixaràs escrit detalla el problema clarament, crea exemples reproduïbles i llista el que ja hagis intentat.

On demanar ajuda

  • Canals de Slack/Discord del projecte
  • Pàgines de preguntes/respostes com Stack Overflow.
  • Fòrums específics
  • Comunitats locals
  • Mentors/companys de feina

On puguis, posar una pregunta també ajudarà altres persones i llocs com Stack Overflow es nodreixen de les teves preguntes, així que no et tallis. Però comprova sempre abans si aquesta pregunta ja ha estat resposta. Si creus que hi ha coses similars però no iguals, enllaça-ho i comenta-ho a la teva pregunta.

I si ho vas resoldre en un altre lloc, afegeix una resposta indicant com ho vas fer. Igual que tu vas tenir el dubte, hi haurà més gent que podrà trobar la teva pregunta i la teva resposta.

I si no es soluciona? Pla B

Tot esforç ha de valer la pena i les circumstàncies poden variar molt, així que cadascú ha de valorar el seu cas.

Imagina’t que estàs en un avió i el motor es trenca. Si en saps de motors potser pots arreglar-ho a temps abans que sigui massa tard. Però el primer que has de tenir molt clar és el temps de no retorn: fins quan sóc a temps de tirar-me en paracaigudes i no morir intentant reparar el motor? Perquè si l’avió arriba a terra segur que ja no hi sóc a temps, i sempre hi haurà una altura necessària perquè es pugui obrir el paracaigudes.

Doncs aquest moment l’haig de tenir 100% clar i tenir un pla B.

Això en el món del desenvolupament web es tradueix en dates d’entrega, límits de pressupost del client, etc. Per exemple, el client ha reportat un error però hem de tenir clar:

  • Quant li importa aquest error?
  • Quantes hores com a màxim vol dedicar-li a aquest error si no es resol?
  • Si no es resol, podríem mitigar-ho d’una altra manera?
  • Hi ha una data d’entrega màxima per solucionar això?

Conclusió

És molt frustrant i estressant anar contrarellotge per resoldre un error, una cosa que a priori pots desconèixer totalment l’origen i causa. Però hi ha esperança.

No hauràs d’aplicar tots aquests recursos, i en alguns moments alguns seran millors que d’altres o serà una combinació d’ells.

Hauràs d’anar-ho aprenent amb el temps, fins i tot tindràs els teus propis recursos que jo no he posat. L’important és no quedar-se mai parat sense saber què fer, sempre seguir intentant-ho.

Per a mi el més important és si t’he pogut ajudar, però si a més comparteixes aquest post amb tothom, doncs escolta, molt millor.

Carlos Rincón

Carlos Rincón

developer

Publicacions relacionades