Ignora los mensajes de error
Los compiladores, los sistemas operativos, etc. emiten mensajes de error sólo para que los usen sus creadores, o para justificar sus sueldos.
Leer esos mensajes, además, lleva un tiempo precioso que se podría dedicar a escribir más código, por lo que atentan contra nuestra productividad.
Y por último, para entender esos mensajes hacen falta conocimientos informáticos -cosa que no debemos cultivar, ya que en realidad todos estamos estudiando para jefes-, y encima... ¡la mayoría de las veces esos mensajes están en inglés! No caigas en la trampa. Ignóralos.
Ignora las advertencias, "warnings" o "hints"
Al igual que en el caso de los errores, estos mensajes son difíciles de entender (por lo menos más difíciles que los mensajes cortos de los móviles), y encima suelen estar en inglés.
Es más, ignorar los "warnings" le da a uno una pátina de programador profesional que no tiene miedo de los ordenadores. ¿Qué mejor demostración de madurez como programador que presentar un programa que al compilar da decenas, no, cientos de warnings, sin que su autor se inmute? Se nota que es un programador experimentado, que no se amilana por nada, y que además está demasiado ocupado para perder el tiempo con tonterías.
Escribe el código directamente sin pensar
Al final, no nos engañemos. ¿Qué es lo que estamos construyendo? Un programa. ¿Qué es lo único imprescindible en un programa? El código. ¿Qué es lo que de verdad funciona? El código. No hay que perder ni un minuto en usar medios arcaicos como lápices, bolígrafos o papel. Tú eres un miembro de pleno derecho de la generación WAP. No haces el ridículo escribiendo costosas sílabas, ¿verdad? Pues no hagas el ridículo pensando en nada, cuando hay tanto código por escribir.
Cuanto antes te quites de enmedio este rollo de programar, mejor. Y eso, muñeco, sólo lo puedes acelerar escribiendo más y más líneas.
Aunque el código no compile o no funcione, sigue escribiendo
Es sabido que los mensajes de error son una interrupción inadmisible, una traba estúpida a nuestro trabajo. ¿Qué puedes hacer si tienes un error de compilación? Ya hemos visto que leérselo y comprenderlo no es una opción válida.
Se puede intentar hacer algún cambio aleatorio en el código fuente, a ver si hay forma de engañar a ese estúpido compilador. Pero si eso no funciona, no pierdas más tiempo. NO, no caigas en la tentación de leer el mensaje de error o intentar comprenderlo (tú tienes un prestigio al que te debes). Sigue escribiendo código, que es de lo que se trata para acabar con esta asquerosa asignatura. Más adelante, ya arreglarás el error. Es sabido, además, que los errores tienden a desaparecer solos con el tiempo si no se los mira mucho. Cuando eso pase, ya tendrás el programa casi acabado. Compilarás, ejecutarás, y si probases (que tampoco hace falta) verías que todo funciona perfectamente.
Si el código compila, eso ya es el paraíso; nada nos impide seguir escribiendo código para liquidar de una vez esta odiosa práctica. El que el programa no haga lo que se quería que hiciera no es tan importante, ya lo arreglaremos más tarde, cuando esté acabado. Además, siempre puede pasar que en un golpe de suerte los profesores cambien el enunciado de la práctica y entonces sí que encaje con nuestro programa, así que no hay que arriesgarse a hacer trabajo inútil arreglando un programa que va descarriado.
Si el código tiene un error que no se produce siempre, ignóralo y sigue escribiendo
Mejor aún que en el punto anterior. Si el error no se produce siempre, va a ser difícil de encontrar, y además puede que en la demostración de la práctica no salga, y además puede que desaparezca solo si no lo miras. Así que no te preocupes, seguro que no es nada grave.
Si el código tiene un error que se produce siempre, cambia cosas aleatoriamente hasta que desaparezca
Ya hemos hablado en contra de pararse y pensar. Si hay un error que, por algún capricho, quieres eliminar, simplemente prueba a escribir el mismo código de otras formas diversas. Esto tiene la ventaja de que a lo mejor se soluciona, y además habrás conseguido que se solucione: 1) sin entender cuál era la causa, y 2) sin dejar de escribir código. Claramente, este es el comportamiento más profesional.
Construye enormes porciones de código sin compilar / ejecutar / probar
No compiles con frecuencia; no des pasos pequeñitos. Tú eres un profesional, y tienes que dar pasos de gigante. Escribe miles de líneas de código, y ya después compila. Así será mucho más entretenido buscar los errores de compilación y arreglar el código, lo que constituye un excelente ejercicio.
Respecto a ejecutar el programa que escribes, si intentas tener siempre un programa que funcione parcialmente, descubrirás los errores muy pronto, y además al haber hecho pocas modificaciones desde la última vez, te será demasiado fácil saber dónde has introducido el nuevo error. Esto sólo lo hacen los miedicas. Un verdadero programador hace el programa entero, y luego lo digiere entero, como una boa. Nada sustituye a la maravillosa sensación de buscar un error que se oculta en las últimas 10.000 líneas de código que has escrito; si sólo son 10 ó 20, la cosa no tiene ciencia.
No escribas comentarios, salvo los obligatorios
Ya lo hemos dicho antes. ¿Cuál es el objetivo de todo esto? Hacer un programa. ¿Y de qué consta un programa? De código. Todo código que no sea ejecutable no es realmente necesario. Poner comentarios explicando algo es un insulto a la inteligencia de un programador; cualquiera que vea un programa, si conoce el lenguaje de programación, sabe perfectamente lo que hace ese programa, cómo y por qué.
Si hay comentarios obligatorios (descripciones de funciones y toda esa morralla), esos sí hay que ponerlos, aunque no se tenga nada interesante que decir. A los profesores les gustan esas tonterías y te pondrán más nota.
Ignora los enunciados
Los enunciados y las especificaciones son un rollo. Hablan de problemas que no nos interesan, son largos, prolijos, y en realidad no son más que un simple ejercicio de narcisismo de los profesores para que veamos cuánto creen que saben. Limítate a echar un vistazo, decide más o menos qué te están pidiendo, y es suficiente; seguir leyendo el enunciado, o volver a leerlo más adelante, es un obstáculo en nuestra verdadera misión. Que no es otra, por supuesto, que escribir el código. Por tanto, una vez intuido más o menos lo que se pide, entierra el enunciado en el fondo de la pila de papeles más alta que tengas, o en las profundidades del directorio temporal de tu ordenador.
Ignora las normas de programación y presentación
Las normas que dicen cómo debe escribirse el código, o cómo debe presentarse la práctica, son un ejercicio de prepotencia por parte de los profesores. A ellos les gusta dominarnos, obligarnos a hacer cosas que no tienen ningún sentido, y por eso escriben normas. No te prestes a ese juego. Todas esas normas son totalmente innecesarias, ya que aun sin ellas las prácticas entregadas cumplirán los requisitos de calidad exigibles. Respecto a la facilidad de manejo por su parte, ¿no cobran para corregirlas? No te molestes siquiera en poner tu nombre o tu curso en las prácticas, ya que en realidad no tienen mayor dificultad en recordar tu cara, tu estilo inconfundible de programación, y sabrán que la práctica es tuya de todas formas.
Escribe la documentación al final
¿Cómo vas a escribir un documento describiendo un programa que no existe? Por otra parte, ¿qué sentido tiene escribir documentos para ti mismo sobre lo que vas haciendo? ¡Todo lo que puedas leer en ellos, ya lo sabes, puesto que lo habrás escrito tú! Así que el único motivo para escribir documentación de un programa es que los profesores la piden. Y eso puede solucionarse el día anterior a la entrega. Si, además, haces el programa durante los días previos a la fecha de entrega, no tendrás el problema de que se te olvide algo y necesites mirar documentos; todo estará muy reciente en tu cabeza.
No aprendas a utilizar el depurador ni otras herramientas
Si se produce un error en tu código, al fin y al cabo todo lo que sabes sobre programación te lo han enseñado los profesores. ¿De quién es, pues, la culpa de que tú tengas un error? Es del profesor; por tanto, que sea él quien lo busque y lo solucione. Los errores de programación son algo excepcional, cuando seas profesional no tendrás que enfrentarte a ellos, por lo que en tu etapa de formación es normal que no emplees tiempo ni esfuerzo en aprender a arreglarlos.
No utilices jamás breakpoints al depurar un programa
En primer lugar, ya hemos dicho que no aprendas a utilizar las herramientas. ¿Qué demonios haces con el depurador, entonces?
Si a pesar de todo lo utilizas, no uses breakpoints. De todos es sabido que la mejor forma de depurar un programa es recorriendo paso a paso todo el código hasta llegar a la función que está provocando el error; si hay que recorrer 1000 líneas de código simplemente se le da más rápido a la tecla F7. Los breakpoints son algo esotérico, que permite que pongas a ejecutar un programa y la ejecución se pare justo donde está el breakpoint; pero siempre que podamos ejecutar todo desde el principio estaremos más seguros de que ha llegado a donde queremos.
Los compiladores, los sistemas operativos, etc. emiten mensajes de error sólo para que los usen sus creadores, o para justificar sus sueldos.
Leer esos mensajes, además, lleva un tiempo precioso que se podría dedicar a escribir más código, por lo que atentan contra nuestra productividad.
Y por último, para entender esos mensajes hacen falta conocimientos informáticos -cosa que no debemos cultivar, ya que en realidad todos estamos estudiando para jefes-, y encima... ¡la mayoría de las veces esos mensajes están en inglés! No caigas en la trampa. Ignóralos.
Ignora las advertencias, "warnings" o "hints"
Al igual que en el caso de los errores, estos mensajes son difíciles de entender (por lo menos más difíciles que los mensajes cortos de los móviles), y encima suelen estar en inglés.
Es más, ignorar los "warnings" le da a uno una pátina de programador profesional que no tiene miedo de los ordenadores. ¿Qué mejor demostración de madurez como programador que presentar un programa que al compilar da decenas, no, cientos de warnings, sin que su autor se inmute? Se nota que es un programador experimentado, que no se amilana por nada, y que además está demasiado ocupado para perder el tiempo con tonterías.
Escribe el código directamente sin pensar
Al final, no nos engañemos. ¿Qué es lo que estamos construyendo? Un programa. ¿Qué es lo único imprescindible en un programa? El código. ¿Qué es lo que de verdad funciona? El código. No hay que perder ni un minuto en usar medios arcaicos como lápices, bolígrafos o papel. Tú eres un miembro de pleno derecho de la generación WAP. No haces el ridículo escribiendo costosas sílabas, ¿verdad? Pues no hagas el ridículo pensando en nada, cuando hay tanto código por escribir.
Cuanto antes te quites de enmedio este rollo de programar, mejor. Y eso, muñeco, sólo lo puedes acelerar escribiendo más y más líneas.
Aunque el código no compile o no funcione, sigue escribiendo
Es sabido que los mensajes de error son una interrupción inadmisible, una traba estúpida a nuestro trabajo. ¿Qué puedes hacer si tienes un error de compilación? Ya hemos visto que leérselo y comprenderlo no es una opción válida.
Se puede intentar hacer algún cambio aleatorio en el código fuente, a ver si hay forma de engañar a ese estúpido compilador. Pero si eso no funciona, no pierdas más tiempo. NO, no caigas en la tentación de leer el mensaje de error o intentar comprenderlo (tú tienes un prestigio al que te debes). Sigue escribiendo código, que es de lo que se trata para acabar con esta asquerosa asignatura. Más adelante, ya arreglarás el error. Es sabido, además, que los errores tienden a desaparecer solos con el tiempo si no se los mira mucho. Cuando eso pase, ya tendrás el programa casi acabado. Compilarás, ejecutarás, y si probases (que tampoco hace falta) verías que todo funciona perfectamente.
Si el código compila, eso ya es el paraíso; nada nos impide seguir escribiendo código para liquidar de una vez esta odiosa práctica. El que el programa no haga lo que se quería que hiciera no es tan importante, ya lo arreglaremos más tarde, cuando esté acabado. Además, siempre puede pasar que en un golpe de suerte los profesores cambien el enunciado de la práctica y entonces sí que encaje con nuestro programa, así que no hay que arriesgarse a hacer trabajo inútil arreglando un programa que va descarriado.
Si el código tiene un error que no se produce siempre, ignóralo y sigue escribiendo
Mejor aún que en el punto anterior. Si el error no se produce siempre, va a ser difícil de encontrar, y además puede que en la demostración de la práctica no salga, y además puede que desaparezca solo si no lo miras. Así que no te preocupes, seguro que no es nada grave.
Si el código tiene un error que se produce siempre, cambia cosas aleatoriamente hasta que desaparezca
Ya hemos hablado en contra de pararse y pensar. Si hay un error que, por algún capricho, quieres eliminar, simplemente prueba a escribir el mismo código de otras formas diversas. Esto tiene la ventaja de que a lo mejor se soluciona, y además habrás conseguido que se solucione: 1) sin entender cuál era la causa, y 2) sin dejar de escribir código. Claramente, este es el comportamiento más profesional.
Construye enormes porciones de código sin compilar / ejecutar / probar
No compiles con frecuencia; no des pasos pequeñitos. Tú eres un profesional, y tienes que dar pasos de gigante. Escribe miles de líneas de código, y ya después compila. Así será mucho más entretenido buscar los errores de compilación y arreglar el código, lo que constituye un excelente ejercicio.
Respecto a ejecutar el programa que escribes, si intentas tener siempre un programa que funcione parcialmente, descubrirás los errores muy pronto, y además al haber hecho pocas modificaciones desde la última vez, te será demasiado fácil saber dónde has introducido el nuevo error. Esto sólo lo hacen los miedicas. Un verdadero programador hace el programa entero, y luego lo digiere entero, como una boa. Nada sustituye a la maravillosa sensación de buscar un error que se oculta en las últimas 10.000 líneas de código que has escrito; si sólo son 10 ó 20, la cosa no tiene ciencia.
No escribas comentarios, salvo los obligatorios
Ya lo hemos dicho antes. ¿Cuál es el objetivo de todo esto? Hacer un programa. ¿Y de qué consta un programa? De código. Todo código que no sea ejecutable no es realmente necesario. Poner comentarios explicando algo es un insulto a la inteligencia de un programador; cualquiera que vea un programa, si conoce el lenguaje de programación, sabe perfectamente lo que hace ese programa, cómo y por qué.
Si hay comentarios obligatorios (descripciones de funciones y toda esa morralla), esos sí hay que ponerlos, aunque no se tenga nada interesante que decir. A los profesores les gustan esas tonterías y te pondrán más nota.
Ignora los enunciados
Los enunciados y las especificaciones son un rollo. Hablan de problemas que no nos interesan, son largos, prolijos, y en realidad no son más que un simple ejercicio de narcisismo de los profesores para que veamos cuánto creen que saben. Limítate a echar un vistazo, decide más o menos qué te están pidiendo, y es suficiente; seguir leyendo el enunciado, o volver a leerlo más adelante, es un obstáculo en nuestra verdadera misión. Que no es otra, por supuesto, que escribir el código. Por tanto, una vez intuido más o menos lo que se pide, entierra el enunciado en el fondo de la pila de papeles más alta que tengas, o en las profundidades del directorio temporal de tu ordenador.
Ignora las normas de programación y presentación
Las normas que dicen cómo debe escribirse el código, o cómo debe presentarse la práctica, son un ejercicio de prepotencia por parte de los profesores. A ellos les gusta dominarnos, obligarnos a hacer cosas que no tienen ningún sentido, y por eso escriben normas. No te prestes a ese juego. Todas esas normas son totalmente innecesarias, ya que aun sin ellas las prácticas entregadas cumplirán los requisitos de calidad exigibles. Respecto a la facilidad de manejo por su parte, ¿no cobran para corregirlas? No te molestes siquiera en poner tu nombre o tu curso en las prácticas, ya que en realidad no tienen mayor dificultad en recordar tu cara, tu estilo inconfundible de programación, y sabrán que la práctica es tuya de todas formas.
Escribe la documentación al final
¿Cómo vas a escribir un documento describiendo un programa que no existe? Por otra parte, ¿qué sentido tiene escribir documentos para ti mismo sobre lo que vas haciendo? ¡Todo lo que puedas leer en ellos, ya lo sabes, puesto que lo habrás escrito tú! Así que el único motivo para escribir documentación de un programa es que los profesores la piden. Y eso puede solucionarse el día anterior a la entrega. Si, además, haces el programa durante los días previos a la fecha de entrega, no tendrás el problema de que se te olvide algo y necesites mirar documentos; todo estará muy reciente en tu cabeza.
No aprendas a utilizar el depurador ni otras herramientas
Si se produce un error en tu código, al fin y al cabo todo lo que sabes sobre programación te lo han enseñado los profesores. ¿De quién es, pues, la culpa de que tú tengas un error? Es del profesor; por tanto, que sea él quien lo busque y lo solucione. Los errores de programación son algo excepcional, cuando seas profesional no tendrás que enfrentarte a ellos, por lo que en tu etapa de formación es normal que no emplees tiempo ni esfuerzo en aprender a arreglarlos.
No utilices jamás breakpoints al depurar un programa
En primer lugar, ya hemos dicho que no aprendas a utilizar las herramientas. ¿Qué demonios haces con el depurador, entonces?
Si a pesar de todo lo utilizas, no uses breakpoints. De todos es sabido que la mejor forma de depurar un programa es recorriendo paso a paso todo el código hasta llegar a la función que está provocando el error; si hay que recorrer 1000 líneas de código simplemente se le da más rápido a la tecla F7. Los breakpoints son algo esotérico, que permite que pongas a ejecutar un programa y la ejecución se pare justo donde está el breakpoint; pero siempre que podamos ejecutar todo desde el principio estaremos más seguros de que ha llegado a donde queremos.