VIII Jornadas de Enseñanza Universitaria de la Informática Cáceres ...

y no te da la gana buscarlo. Entonces, sí estájustificado que acudas al profesor para que sea élel que haga tu trabajo. Si se niega, critícale en lospasillos.La segunda es que se puede acudir a tutoríasen la semana previa a la entrega del programa.Estará lleno de gente, el profesor se dedicará enexclusiva a atender alumnos obviando otras tareas,y además si no te atiende podrás criticarlo en lospasillos. Cada vez que vayas, tendrás que esperardurante horas, y eso te permitirá relacionarte concompañeros en la cola. Todo son ventajas.3.2 Nunca describas un problema en detalleSi a pesar de todo decides saltarte el puntoanterior, y pides ayuda, ten en cuenta una regla deoro que te será también muy útil en tu vidaprofesional (no en vano la siguen multitud deprofesionales y usuarios de la informática).NUNCA describas un problema en detalle.Ejemplo. Si durante el desarrollo de unprograma se produce algún suceso que te resultadesagradable, acude al profesor y dile: "Ayer mepasó algo que no me agrada". El pondrá cara deesperar más datos; aguanta, no digas nada más.No se te ocurra entrar en detalles como estos:• Si el suceso desagradable se produjo durantela compilación del programa o durante laejecución.• Si el suceso desagradable hizo que elprograma terminase súbitamente su ejecucióno bien hizo que la ejecución continuaseindefinidamente, o simplemente el programano hizo lo que esperabas que hicera desde unpunto de vista funcional.Otro ejemplo. Si el suceso desagradable seprodujo durante la compilación, no le digas alprofesor el mensaje de error y la línea en la que seprodujo dicho error. Dile sólo algo como "Medaba no sé qué error, o algo".Otro ejemplo. Si el suceso desagradable seprodujo durante la ejecución, y provocó la súbitaterminación del programa, nunca anotes elmensaje producido, ni le digas al profesor el textodel mismo. Di simplemente "Me daba no sé quéerror, o algo".Evidentemente, si el suceso desagradableconsistía en que el programa no hacía lo queesperabas, no se te ocurra decirle al profesor enqué situación exacta lo producía (si era al leer unfichero vacío, o antes o después de que pasasealguna otra cosa). Evita una descripción como "Elerror se produce siempre que cargo un segundofichero y el primero estaba vacío". Tú di sólo lafrase mágica: "Me daba no sé qué error, o algo".¿Lo vas pillando?3.3 Lleva siempre los fuentes equivocadosSupongamos que, contra todos nuestros consejosanteriores, acudes al profesor, y además vas apreguntarle por un problema concreto. Si elprofesor se niega a examinar tus fuentes, podráscriticarle en los pasillos y advertir a futurosalumnos contra él, pero puede darse el caso de queel tío te reciba y tú acabes entrando ypreguntando. Haces mal, pero la situación aúntiene arreglo: procura llevar los fuentesequivocados. Por ejemplo, si tienes un problema,y haces diversas modificaciones que no danresultado, o incluso generan problemas nuevos,acude con los últimos fuentes, pero pregunta porel problema original. Así, el profesor buscaráinútilmente un error cuando se le producirá otro.Entonces di algo como "Ah, bueno es que despuésprobé una cosa. Quita esa línea de ahí..."Si manejas este proceso con habilidad, puedesrealizar toda una sesión de codificación allímismo, en las tutorías. Esto es particularmenteaconsejable si hay otros compañeros esperandofuera. El profesor cogerá mala fama, trabajará mástiempo, harás que el resto de los alumnos tenganmás trabas para avanzar, con lo que el nivel de laclase se mantendrá en cierto equilibrio y así nopensarán en ampliar el temario en futuros años...Tómatelo como un servicio a la comunidad.3.4 No aísles el problemaVolvamos a suponer que eres un irresponsable yacudes a una tutoría. No se te ocurra aislar elproblema antes de ir. Si se produce un error en unfichero de entrada de 1 MB, no intentes irprobando con ficheros más pequeños hasta acotarqué produce el error, ni intentes crear un mini-