En la investigación no todo es generar ideas o redactar manuscritos. También hay un momento inevitable en el que otras personas evalúan aquello en lo que hemos invertido mucho tiempo y esfuerzo. En el caso de los artículos científicos, este proceso suele permitir réplica y nuevas oportunidades. Sin embargo, en las convocatorias de financiación la situación es distinta, ya que muchas veces no existe la posibilidad de volver a presentarse.

Cuando una convocatoria es única o no se repite, un rechazo puede tener un impacto mucho mayor. Este episodio no se centra en el rechazo en sí, sino en las opciones reales que existen para afrontarlo de forma crítica. Una de ellas es la alegación, un mecanismo que, aunque suene legal o ajeno al ámbito investigador, puede ser legítimo y necesario en determinadas circunstancias.

La alegación solo tiene sentido cuando existe un informe de evaluación detallado y unas bases de convocatoria claras. Antes de iniciar este proceso, es imprescindible un ejercicio de honestidad personal. No todas las evaluaciones negativas son injustas, y alegar solo es recomendable cuando existen errores objetivos, omisiones claras o contradicciones con las propias normas de la convocatoria.

Entre los errores más habituales que pueden justificar una alegación se encuentran la supuesta falta de documentación que sí fue entregada o críticas a aspectos que no eran exigidos. En estos casos, el proceso pasa por analizar el informe con calma, identificar los puntos problemáticos y redactar un documento formal, respetuoso y constructivo, dirigido a la entidad financiadora.

La alegación debe centrarse exclusivamente en hechos verificables y argumentos sólidos, evitando opiniones personales o valoraciones subjetivas. Herramientas de inteligencia artificial pueden ayudar a mejorar el lenguaje o el tono final del documento, pero el contenido y el razonamiento deben partir siempre de la persona solicitante.

Más allá del resultado, el proceso de alegación tiene un valor formativo importante. Obliga a comprender mejor cómo funcionan los sistemas de evaluación y ayuda a desarrollar una mirada crítica que será útil tanto para futuras solicitudes como para el día en que uno mismo esté al otro lado, evaluando propuestas de otras personas.

Si este episodio te ha resultado útil, te agradecería que en la plataforma donde lo estés escuchando le des a like, dejes un comentario o te suscribas al podcast. Estos pequeños gestos ayudan a que Investigando la Investigación tenga más alcance y pueda llegar a más personas interesadas en entender y vivir la investigación desde dentro.

En este episodio de Investigando la Investigación quería reflexionar, desde una perspectiva muy personal, sobre cómo ha ido cambiando la programación a lo largo del tiempo y sobre el punto en el que creo que nos encontramos ahora. Todo parte de una historia que escuché sobre cómo uno de mis directores de tesis programaba alrededor de 1975, cuando el código se escribía en papel, se pasaba a tarjetas perforadas y se enviaba a un ordenador central para su compilación. Un proceso lento, extremadamente frágil y lleno de fricción, en el que cualquier error implicaba rehacer gran parte del trabajo.

Con la llegada de los ordenadores personales en los años ochenta, este modelo desapareció y programar pasó a ser algo que podía hacerse de manera local. Aun así, durante muchos años siguió siendo un proceso muy laborioso, especialmente por la falta de acceso a documentación y manuales. En mi caso, aprendí a programar con lo que encontraba en revistas y mucha prueba y error, hasta que Internet cambió por completo el panorama. Empezaron a surgir comunidades, foros y, más tarde, plataformas como Stack Overflow, que aceleraron enormemente el aprendizaje y la resolución de problemas, aunque el paradigma seguía siendo escribir y depurar código línea a línea.

El siguiente gran salto llegó en torno a 2023 con la aparición de herramientas como ChatGPT, que empezaron a actuar como asistentes de programación capaces de generar código y ayudar a depurarlo. Pero el verdadero cambio de paradigma, en mi opinión, está ocurriendo ahora, entre finales de 2024 y 2025, con las herramientas basadas en agentes. Ya no se trata solo de generar fragmentos de código, sino de sistemas capaces de descomponer proyectos complejos, ejecutar tareas en paralelo y acelerar enormemente el desarrollo, tanto para personas con pocos conocimientos técnicos como para programadores con experiencia.

Todo esto está transformando el rol del programador, que cada vez se parece más al de un ingeniero o gestor de proyectos: alguien que sabe estructurar problemas, guiar herramientas complejas, detectar errores y validar resultados, más que escribir código de forma manual todo el tiempo. En este contexto, también creo que es clave mantenerse informado a través de redes técnicas como Twitter o LinkedIn, donde el ritmo de innovación es mucho más visible que en otros formatos.

A partir de estas ideas, comento también algunos proyectos en los que estoy trabajando, tanto herramientas personales como una plataforma pública llamada Explore Labs, orientada a ofrecer utilidades prácticas para procesos de investigación, como el análisis y la pre-revisión de artículos científicos.

Puedes acceder a la plataforma en: https://explore-labs.com

El problema no es generar muchas ideas; de hecho, generar muchas ideas suele ser una ventaja. El problema aparece cuando esas ideas se acumulan sin un criterio claro y terminan diluyendo el foco original. Generar cantidad no implica generar calidad, ni mucho menos avanzar. Cuando las ideas se multiplican sin control, se vuelve difícil identificar qué es realmente importante y qué simplemente añade ruido.

Desde hace varios años utilizo Obsidian como sistema de gestión de notas, algo que he comentado en detalle en episodios anteriores del podcast. En particular, uso mucho las notas diarias: cada día aparece una nota en blanco en la que vuelco cualquier idea que se me ocurre, sobre cualquier tema, en el momento en que aparece. Más adelante reviso ese material y, si una idea lo merece, la convierto en una nota independiente donde empiezo a desarrollarla con más calma.

El problema surge cuando, a partir de una idea inicial —el tronco—, empiezo a añadir demasiadas subideas. Llega un punto en el que el documento crece tanto que pierdo la visión global. Me cuesta distinguir qué partes son esenciales y cuáles son accesorias y, cuando vuelvo tiempo después a esa nota, me encuentro con un desorden que genera fricción. Esa fricción acaba provocando procrastinación y hace que no vuelva a ideas que, en el fondo, pueden ser muy valiosas.

Aquí es donde entra el concepto de poda. Igual que en jardinería se cortan ramas para fortalecer el tronco, con las ideas ocurre algo muy parecido. Sin poda aparece la parálisis por análisis o la sobrecarga creativa: confundimos tener muchas ideas con avanzar, cuando en realidad estamos bloqueándonos.

La clave, al menos en mi experiencia, es tener una estrategia de poda definida. No basta con pensar que ya se revisará más adelante; si no hay criterios claros, la poda no se hace. Algunos de los criterios que utilizo son si una subidea refuerza o no la idea principal, si es práctica o simplemente interesante pero poco accionable, o si se aleja demasiado del objetivo inicial. Estos criterios no son universales: dependen mucho del tipo de proyecto y de cómo trabaja cada persona.

No es lo mismo, por ejemplo, un proyecto científico, donde todo debe girar alrededor de un eje muy concreto, que un proyecto creativo o artístico, donde la dispersión puede ser parte del proceso. En cualquier caso, lo importante es que esos filtros existan y estén definidos, mejor aún si están por escrito para poder revisarlos de vez en cuando.

Esta lógica de poda no solo aplica a las ideas, sino también al ruido informativo al que estamos expuestos constantemente. Vivimos rodeados de estímulos digitales y, sin filtros propios, es fácil perder dirección. En este contexto, recomiendo el libro Digital Minimalism, de Cal Newport, que aborda precisamente cómo proteger la atención y reducir el ruido en entornos tecnológicos saturados.

Para cerrar el episodio, comento una novedad: estoy desarrollando una aplicación web orientada a apoyar distintos procesos de investigación mediante herramientas de inteligencia artificial. La aplicación está en fase de pruebas, pero ya permite, por ejemplo, convertir un artículo científico en PDF en un episodio de podcast o simular un proceso de revisión por pares a partir de un borrador. Se puede acceder en explore-labs.com y, por ahora, es gratuita. Iré comentando su evolución en futuros episodios del podcast.