Cómo pedir ayuda que te enseñe en lugar de ayuda que te sustituya.
Esta es la lección que más te va a cambiar la forma de trabajar, y no por lo que crees.
La diferencia entre un uso que te enseña y un uso que te atrofia no está en la herramienta. Está en qué le pides.
La regla: pide ayuda con tu proceso, no el producto terminado.
Tú mantienes el control de la tarea. El sistema te ayuda en los tramos donde te atascas.
La mayoría de las peticiones malas lo son porque se lanzan sobre un problema entero que quien pregunta todavía no ha analizado. Antes de abrir el chat:
El paso 2 es el que más cambia el resultado y el que casi todo el mundo se salta. Quien sabe dónde está atascado ya ha aprendido la mitad.
Que te devuelva la pregunta. En vez de la solución, pídele que te haga preguntas para delimitar el problema, o que te diga qué información te falta.
Una pista graduada. “Dame la pista más pequeña que me permita avanzar, sin darme la solución.” Si sigues atascado, pides la siguiente.
Que revise lo tuyo. Escribes tú primero —el esquema, el borrador, el razonamiento, el código— y pides crítica: qué falla, qué no has considerado, qué caso lo rompe. Se invierten los papeles: el sistema revisa, tú produces.
Que te contraste. “Dame un enfoque alternativo al mío y dime en qué se diferencian los supuestos.” Casi nunca hay una única solución válida.
Y en las cuatro: da contexto. Objetivo, restricciones, tu nivel, qué has intentado ya y qué no puedes usar. Una petición sin contexto recibe una respuesta genérica.
| Lo que se suele pedir | Lo que te hace aprender |
|---|---|
| Solucionar un problema de diseño relativo a un componente del procesador: analizador léxico o sintáctico, analizador semántico, intérprete, traductor o compilador. | Explicita las decisiones de diseño relevantes y justifica por qué. |
| Construye la gramática o la gramática atribuida desde las decisiones relevantes. | Argumenta por qué la gramática o la gramática atribuida satisface las decisiones de diseño. |
| Testar la gramática o la gramática atribuida. | Encontrar posibles errores en la solución propuesta, acotar su origen y proponer una reparación. |
| Derivar la implementación ANTLR/Java desde la gramática o la gramática atribuida. | Argumenta por qué el programa resultante satisface la solución. |
| Testar el programa con los mismos ejemplos usados en el test de la gramática o la gramática atribuida. | Encontrar posibles errores de implementación, acotar su origen y proponer una solución. |
Fíjate en lo que tienen en común las versiones de la derecha: la respuesta todavía te obliga a trabajar. Ese es el criterio para saber si has pedido bien.
Hay tramos donde usarla te perjudica aunque esté permitida: justo el punto que la asignatura quiere que domines. En Procesadores de Lenguajes eso significa, sobre todo:
Un vídeo corto de Asociación Programamos que desarrolla lo anterior. Verlos es opcional.