Introduccion.


Yo siempre tuve esta fantasía de que los programadores de juegos eran la crema de la cosecha. Cualquiera puede escribir un procesador de texto o una aplicación Visual Basic, y cualquiera puede modificar un archivo save ¡Pero los programadores de juegos tienen que empujar los limites de la maquina! Ellos tienen que capturar cada aspecto del ambiente en la pantalla y de alguna manera que no impacte en el frame rate (N de T: Tasa de cuadros por segundo, también conocido como framerate). Yo siempre pensaba que los programadores de juego eran la crema de la cosecha, hasta que realmente me uní a la industria. La cruel realidad me golpeo casi instantáneamente y comencé a pensar – hasta decir en voz alta. Estoy asombrado de que nuestro juego aun funcione.

Tradicionalmente, los programadores de juego trabajaban en sus sótanos o garages, rejuntando piezas de código asembler para poner pixels en la pantalla. De vuelta a cuando los programadores eran los artistas debido a que la resolución era tan mala que realmente pagar un artista era absurdo. Sin embargo mucho ha cambiado desde entonces, los juegos ya no son hechos por dos compañeros en un garage, estos son hechos por equipos de gente a lo largo de muchos meses de desarrollo.

En estos días y en estos tiempos no somos individuos quienes trabajan en un proyecto entero. Somos una pieza de una compañía viva y que respira y que debe trabajar junta para lograr éxitos. Ahora hay “Game Developer Conference” ( http://www.gdconf.com/ ), Tutoriales Online ( http://www.flipcode.com/ , http://www.gamedev.net/ ), Artículos ( http://www.gamasutra.com/ ), Tablones de anuncios ( http://www.thedc.com/ ), Revistas ( http://www.gdmag.com/ ), y Libros ( http://www.satori.org/gamegems/ ) que nos permiten compartir nuevas ideas y técnicas. Y todavía de alguna forma, con todo este trabajo en equipo y todos estos maravillosos recursos a nuestra disposición, seguimos arreglándonos para codificarnos en los rincones.

Si hubiera algún enfoque de programación que esquive todos los obstáculos y bugs mientras de alguna forma evite las vueltas hacia atrás o la reescritura de código, entonces estoy seguro de que todos estaríamos usando esa técnica. Dado que no hay una forma perfecta de programar, todo lo que podemos hacer es mantener nuestros ojos y oídos abiertos, observar los programadores alrededor nuestro y ver que están haciendo bien y mal.

Aquí hay algunas técnicas que eh observado de primera mano las cuales han mejorado notablemente mis propios hábitos de programación. Lo más importante a recordar cuando las leas es que a pesar de que algunas de ellas puedan sonar simples y elementales, conocer una técnica no vale la pena a menos que la practiques. Muchos programadores sin ningún esfuerzo niegan la importancia de cosas como “chequeo de errores” y convenciones de comentado tomándolas como una perdida de tiempo. Por lo tanto me gustaría apuntar algunas sugerencias que pretenden mejorar la cantidad de tiempo y esfuerzo necesario para completar trabajos. Después de practicar solamente algunas de estas técnicas de programación, eh notado que mi propio código se escribe mucho mas rápido y mas eficientemente de lo que nunca lo ah hecho antes.

Prepárate Para lo Peor.


Okay, vamos a asumir que eres un programador súper humano, y que tu código nunca es bugoso y nunca se rompe. Déjame ser el primero en felicitarte por escribir el código perfecto. Sin embargo, que pasara cuando tu código perfecto no le es dado el dato perfecto. ¿Asumirá el código un puntero valido? ¿Intentara usar un archivo de sonido como un mapa de textura?

Por más básico que pueda sonar, el código no debe asumir nada. El lenguaje C tiene una brillante función estándar llamada “assert”, la cual fue diseñada para atrapar errores. Cada vez que a tu código se le de datos del exterior, ten el habito de asegurarte de que el dato es lo que tu esperabas que sea. Si no lo es, assert AND imprimí un mensaje que explique exactamente que esta mal y por que el programa asserteo (N. del T. assert en ingles significa afirmar).

Es importante dar un mensaje, de esta forma cualquiera que lo lea instantáneamente se dirá a si mismo “oops, Ya veo el error”. El noventa por ciento de las veces la causa de un bug es un simple error. Entonces en vez de dejar que paralice tu juego, y desperdicie el tiempo de todos, como el de la gente que intentara rastrear el bug hacia atrás en un esfuerzo de precisar la causa, por que no decirle en el momento que salio mal. Nueve de cada diez veces puede ser arreglado sin dolor. El otro diez por ciento de las veces el equipo se dará cuenta de un problema mayor de codificación mucho antes de que este se vuelva un problema incorregible sobre el que todos tendrán que trabajar a su alrededor.

Sin importar en que lenguaje estas trabajando. La primera subrutina que siempre deberías escribir debe ser una simple función de impresión de error. Hazla funcionar como la función básica de impresión del lenguaje, así es simple e indolora de usar y recordar para otros programadores. Entonces cuando el programa "assertee" en un caso que no es obvio desde el mensaje de error, puedes poner un break point dentro de tu función de impresión y el programa se detendrá exactamente cuando el problema ocurra. Esto ahorrara tiempo en localizar la primera ocurrencia del problema mientras hagamos un simple debug.

Espera Olvidar.


No esperes recordar lo que tu código esta haciendo. Los proyectos en estos días duran meses incluso años. No recordaras lo que programaste al comienzo del proyecto. De hecho probablemente sea la única garantía que tengas. El cielo es azul (si no esta lloviendo, y si no es el crepúsculo, o de noche), el pasto es verde (si se lo riega regularmente y si no es invierno), y tu siempre olvidaras los detalles de un manojo de texto que escribiste meses atrás (siempre).

Por lo tanto comenta todo como si se lo estuvieras enseñando a alguien que no lo conoce todo --alguien como tú dentro de seis meses. Piensa en un miembro de tu equipo que te diga que hay un bug en tu viejo código, y tú tienes que revisitarlo y arreglarlo. Si tu puedes abrir el archivo y entender lo que estabas haciendo, sin tener que preocuparte sobre las variables o parámetros. Encontrar y arreglar el bug será rápido e indoloro.

La técnica es simple, cuando sea que uses un paréntesis, pon un comentario que diga que esta haciendo la línea. Solo escríbelo como si estuvieras leyendo la línea en voz alta. Si alguien mas la lee le dirá que hace sin tener que saber lo que estaban haciendo las variables y cálculos locos. Si tu lo lees, le dirás después a tu mente convierte todos esos cálculos a lo que realmente significan. Por ejemplo si una línea de código que debería ser solamente ejecutada si "(frmp>10)", "(plisti.bdown & x03)", y "(plisti.y > pond.y)". Por que no tener un comentario que diga "si (pasaron diez frames Y el botón 3 sigue apretado Y el jugador no esta bajo el agua)".

Cuando comentas de esta manera, te beneficiaras dos veces. Primero, cualquiera podrá leer exactamente lo que la función se supone que esta haciendo sin ni siquiera saber como programar en un lenguaje en particular. Esto hace que el chequeo de lógica sea mucho más fácil. Segundo, si la lógica esta bien, es fácil ubicar errores debido a que la línea de código no estará haciendo lo que se dice que debería estar haciendo. En el ejemplo anterior, si el código actual estuviese corriendo cuando el jugador esta bajo el agua, seria fácil de ubicar en que parte del código esta el bug debido a que el comentario nos diría " Y el jugador no esta bajo el agua." Si la sentencia no estuviera comentada, podrías mirar la sentencia cientos de veces pensando que esta bien antes de que un "Espera un minuto, ¿es mayor, o menor que pond.y? " te golpee.

El comentario tiene que ser una de las más poderosas herramientas que tiene el programador. Estos son universales debido a que todos los lenguajes de programación tienen un modo de escribir comentarios. Es una pena que siendo algo simple y común también se los hace el objetivo primario a ser tomados por garantías.
Esto en realidad nos lleva a nuestro siguiente punto.

Documentación


Una vez yo escribí documentación. Recuerdo haber escrito unas pocas docenas de páginas sobre varios sistemas y módulos. La documentación en si misma estaba bien, pero a fin de cuentas contra producente. Nadie, incluido yo mismo, la uso nunca. Mucha gente hasta olvido que existía, y si ellos venían a mi y me preguntaban sobre el sistema yo podía explicarles exactamente lo que necesitaban saber en una fracción del tiempo que les hubiera tomado leer la documentación. Sin mencionar que estaba la posibilidad de que alguien leyera la susodicha "documentación" de principio a fin y no tener absolutamente ningún avistamiento de lo que quería saber. El tiempo que me tomo escribir esas páginas de texto fue completamente desperdiciado. Peor aun, cada vez que uno de estos varios sistemas o módulos, teníamos que cambiar el documento también. Por lo tanto yo tenía duplicada la carga de trabajo.

Sin embargo, la solución definitivamente NO es saltearse la documentación completamente. En su lugar, la solución es hacer de tus archivos de código la documentación. Antes de cada función, haz un bloque de comentario que explique que hace, como usarla, y a que prestar atención. Si esta es una compleja pieza de código, explica el enfoque que estas por tomar al lector (quizás hasta a ti mismo dentro de seis meses) entonces ellos entenderán lo que están por ver antes de saltar dentro del código actual. Si hay cosas que necesitan ser usadas en un orden especifico, dilo. Si una función solamente funciona en un oscuro caso díselo a la gente allí mismo. - tan claro como el día.

Ahora, en vez de abrir un documento separado y buscar lo que necesitas saber, la documentación estará justo allí en el código. Las cosas que normalmente tienes que hacer un esfuerzo por aprender estarán exactamente donde las necesitan, cuando las necesitan, y todos se ahorraran el tiempo de buscarlas. Será más probable que otros programadores usen tu código correctamente si ellos encuentran todas las cuestiones que dispusiste para que ellos las vean.

Además, a diferencia de tener un documento separado, otros programadores probaran leer tu código auto documentado. Cuando alguien se acerque a ti por que ellos no entienden un pedazo de código, tú seguramente puedes concluir que los comentarios documentantes en esa área son escasos. Esto es algo que probablemente nunca te des cuenta si no te lo dijeran inintencionalmente. Así que mientras clarificas lo que necesiten saber, comenta ese pedazo de código un poco más. Ahora la próxima persona no tendrá que preguntarte.

Error humano y el Monkey Business


Leí un articulo en Gamasutra intitulado "Postmortem: Angel Studios' Smuggler's Run" (de Charles Eubacks) y este me introdujo a un concepto que era demasiado simple y aun increíblemente efectivo - quizás hasta brillante. En este postmortem, ellos daban un punto entero en "Que Estuvo Bien" a algo llamado "buildmonkey". El buildmonkey era una herramienta que automáticamente compilaba el juego entero cada mañana a las 03:00 AM y logueaba el proceso. De este modo, al comienzo de cada día, los programadores podían tener a una versión compilada de su proyecto ciento por ciento fresca. Si por alguna razón el proyecto no compilo, ellos podían tener un registro con errores que les diga que anduvo mal. Hasta enviaba emails a las personas claves para informarles si la compilación fue satisfactoria o si esta tuvo problemas.

Si bien no estoy proponiendo a todos que salgan y programen un buildmonkey, estoy apuntando al tiempo el tiempo que se ahorro al escribir una herramienta cuyo propósito es realizar una tarea repetitiva y mundana y prevenir/atrapar el error humano.

Ya eh tocado el uso de dispositivos chequeo de error en tus llamados a función, y cuanto tiempo se ahorra cuando el error es atrapado y corregido mientras son hechos. Ahora me gustaría remarcar exactamente la misma ventaja en los datos externos al código en si mismo. La mayoría de los juegos de estos días dependen pesadamente de scripts, archivos INI, y otras fuentes de datos que hacen que el juego corra como es deseado. Sin embargo muchas veces, mientras se desarrolla, un escritor de cometerá un error o un programa exportador emitirá un comando incorrectamente.

En vez de esperar hasta que estos datos sean realmente cargados dentro del juego para ver si funcionaran. Por que no tener un simple programa de DOS que chequee la sintaxis de tales archivos al término del diseñador o el artista. Este programa podría señalar un error antes de que los datos sean cargados en el juego y podría ser un enorme ahorrador de tiempo.

Ahora estoy seguro de que muchos de ustedes probablemente piensen para si mismos " eso seria genial, pero realmente nadie lo usaría." Bueno, es simple. La próxima vez que alguien venga a tu escritorio preguntándote por que el juego se esta estrellando. Tu primera respuesta puede ser "¿Ejecutaste el monkey de sintaxis?"

Otro gran ejemplo de un monkey podría ser una función que imprima el último comando de script conocido cada vez que el juego es ejecutado (en una flag de compilación por supuesto). Esto también podría eliminar la necesidad de constantemente actualizar la documentación y de responder preguntas como "¿podrías decirme de nuevo cual era la sintaxis para un AIPoint?".

Los humanos cometen errores, algunos más que otros. Sin embargo hay unas nuevas cosas chulas llamadas "computadoras" que están hechas para hacer tareas mundanas una y otra vez. Es tiempo de que comencemos a darle un buen uso y nos ahorremos algo de tiempo y esfuerzo.

Un motor tiene correas y vielas.


La mejor metáfora para un game engine que siempre escuche vino de uno de mis compañeros de trabajo, Jerry, alguien quien ni siquiera es programador. El en realidad me planteo unas preguntas, "¿Que es un engine (N del T: motor)? ¿Porque hacer uno? ¿Cual es el problema? “Hice lo mejor para explicárselo, y cuando termine el me dijo que un Game Engine es muy parecido al motor de un auto. Sin este, el auto nunca se mueve, pero al mismo tiempo, un motor funcionando sin un chasis (llantas, etc...) es inútil.

Pensé que era un buen ejemplo y lo escuche mientras el continuaba clarificándolo. Jerry explico que cuando una pieza del motor de su auto se rompe, la puedes reemplazar. Si una correa se rompe, le pones una nueva y acomodas la tensión para una optima performance. Al mismo tiempo, sin embargo, este motor tiene una transmisión, un block y vielas. Estas son vitales para la funcionalidad del motor, pero si tú tiras una viela no podes simplemente cambiarla por una nueva sin desarmar la mitad del motor.

Entonces el concluyo que si tu fueras a construir un motor desde cero, querrás construirlo con un montón de correas y no vielas, así tu podrías intercambiar las partes constantemente y setear la performance sin llevar el motor a un parate.

Brillante. Sin saber nada sobre programacion, el dio al clavo justo en la cabeza. Una de las grandes cosas que separa los buenos programadores de los grandes programadores es la escritura de codigo que encaje como correa en el motor en vez de como una viela. El concepto de escribir codigo flexible, reusable, y remplazable puede ser realmente bastante simple.

La clave para escribir código de casos generales es no dejar que tus subrutinas se vuelvan de más de una pantalla de largo. La forma de hacer esto NO es escribir basura encriptada tanto como puedas meter a presión en una sola línea y NO usar variables globales. La solución es partir todo lo que puedas en funciones ajustadas y reutilizables que puedan tanto realizar una tarea, o llamar la función necesaria para completarla.

Por ejemplo: VectorAdd() podría contener una pequeña pieza de código que sume dos vectores juntos, mientras que SceneDisplay() podría contener llamados a PrepRender(), Render3dObjects(), RenderHud(), RenderDebugText(), y SwapBuffers(). Sin embargo todas las funciones podrían solamente ser de algunas líneas de largo.

Mientras partes el codigo en piezas mas pequeñas, comenzaras a observar funciones que pueden ser reutilizadas en otros lugares sin hacer ningun esfuerzo en absoluto. En el ejemplo anterior RenderHud() y RenderDebugText() probablemente compratiran algunos llamados a funciones del nucleo dado que ambos dibujan objetos encima de todo lo demas en pantalla.

Muchos creen que debe haber un gran diseño antes de que puedas hacer código para casos generales. Cuando escribes módulos y sistemas, el diseño es un paso importante pero no es el punto aquí. Estoy diciendo que te hagas el hábito de escribir todo tu programa lo más general y reusable posible. Entonces cuando comiences a diseñar un nuevo sistema y modulo, tendrás mucho de la funcionalidad ya disponible, y solo tendrás que llamar a esas funciones de una forma organizada, en lugar de reinventar la rueda un par de cientos de veces más.

Un Nuevo Martillo Flamante


Como dije al comienzo de este articulo, no hay un simple enfoque de programación que manejara los tantos obstáculos con los que te encuentres. Muchos consideran la programación una especie de arte oscura de su propiedad. A mi me gusta pensar de nosotros como si fuéramos mas carpinteros que hechiceros.

Carpinteros construyen estructuras desde la materia prima utilizando el conocimiento que han ganado a través de experiencia de primera y segunda mano. Anteriormente en sus carreras, quizás construyeron en sus propios patios traseros, un escritorio usando un martillo, clavos, una sierra y madera. A medida que ganaron experiencia, hacer cosas más avanzadas, como agregar un cuarto extra a la casa, se vuelven más feasibles.
Mucho después de que tareas como preparar cemento, construir un marco interno, disponer aislante, poner sheetrocks, y fijar un techo se vuelvan una segunda naturaleza para ellos. Cuando un carpintero alcanza ese punto, quizás tendrán la posibilidad de realmente construir una casa entera con un equipo de gente tales como plomeros, electricistas, y así.

Estos carpinteros son valiosos no por que tienen un montón de herramientas, sino por que saben como usarlas –y mas importante, cuando usarlas. Dale a un carpintero un martillo y pidele que cuelgue una puerta en sus bisagras y el te pedirá un taladro y un destornillador. Dale a cualquier hombre un martillo y este podría asumir que la puerta fue hecha para ser colgada con clavos. Dale a un niño un nuevo y flamante martillo y probablemente todo se convertirá en un clavo rogando ser golpeado.

Es importante aprender paciencia y buen juicio cuando se encara un problema en vez de cargartelo, e incondicionalmente usar nuestra ultima técnica. Solo por que últimamente leíste un tutorial de quaterniones, no significa que sea útil en todos los casos. Usa tus herramientas y técnicas responsablemente y si no tienes el conocimiento adecuado haz el llamado de atención sobre cual podría ser el mejor enfoque. Admitelo.

Admite tus propios límites.


Nosotros somos solamente humanos, y por mas que seria lindo saberlo todo, no lo sabemos. El peligro en situaciones donde tenemos que terminar una tarea que nos es poco familiar no es nuestra limitada experiencia o conocimiento, es como tratamos con ella. Es muy tentador intentar aceptar tareas de las que tú no sabes nada y no decirle a nadie que podría ser problemático por que no quieres perder valor ante los ojos de la dirección . En casos como estos, algunas personas podrían hacer el siguiente razonamiento, que podría ser mejor no decir nada que le de a pensar a alguien que no tenes idea de lo que estas haciendo. A veces este enfoque puede funcionar. Tú podrías mantener la boca cerrada, trabajar horas extra, leer un libro y algunos artículos on-line y completar el trabajo a tiempo.

Mas veces de las que no, tu mantienes la boca cerrada, trabajas horas extra, lees cualquier cosa que puedas encontrar, la tarea se completa de una semana a un mes mas tarde. Lo hiciste, ¿pero a que precio?

Si no tienes el conocimiento adecuado para la tarea en mano, supérate a ti mismo y admítelo. No lo ocultes o mientas. Si expresas que la tarea te es poco familiar o simplemente un no se como resolver el problema, entonces se puede hacer algo al respecto. Una frase simple como “Lo haré, pero esto es bastante nuevo para mi.¿Que dirección imaginas que debería tomar la escritura del código? ¿Hay algo mas en el proyecto que esta codificado con el mismo enfoque, algo a lo que pueda referenciarme como ejemplo?” No estas diciendo “No puedo hacer esto, No valgo la pena – despídame ahora!” Estas diciendo "Puede que no sepa esto, pero quiero hacerlo. Haré lo que pueda para hacer este trabajo bien la primera vez ." En muchos casos muchos otros programadores estarán felices de compartir algún conocimiento y experiencia contigo. En cierta forma es halagador tener a alguien que te pide consejo. Solo recuerda que solamente es halagador una o dos veces así que presta atención a lo que tienen para decirte y todo estará bien. Siéntate con un block y una lapicera así puedes escribirlo todo si tienes que hacerlo. Mientras no vuelvas repetidamente y digas “¿ que era eso, de nuevo?” Ahí es donde los empujas a través de la línea entre sentirse halagados y sentirse molestados.

A pesar de todo, no temas decir las cosas. Cuando lo haces, alguien puede enseñarte; estarás reservando tiempo para aprender la técnica correcta; o alguien mas puede hacerlo. Lo importante es no dejar que el proyecto sufra, y no admitir tus propios límites es la mejor manera de hacerlo. Nadie sabrá que no puedes manejarlo si tu no se los dices, y es mejor hacerlo de ante mano que cuando ya estas sobre la marcha.

Arreglalo, no lo hackees.


Con mucha frecuencia el código prototipo es escrito y termina convirtiéndose en el código del juego. Muchas veces la gente (Directores) al pasar verán algo en la pantalla y asumirán que ya esta hecho cuando no lo esta. Entonces ese programador es empujado a otra tarea dado que ya esta “hecho” y el hack se queda detrás para plagar el proyecto algún día bajo la línea. No dejes que esto te pase. El código prototipo esta bien mientras siga siendo código prototipo. Una vez que entiendes el proceso, tomate el tiempo para escribir el código que funcionara correctamente, en lugar de solo trabajar para “el ahora”

Además, si hay código que esta causando problemas, no lo “hackees”. Arreglalo. Si puedes agregar una línea de código que lo hackeara a un estado que funciona, por que no gastar otros cinco minutos en entender por que funciona. Después de eso podrás hacerlo funcionar en todos los casos. Hazlo bien y no tendrás que tratar de nuevo con este. Luego habrá una cosa menos que causara problemas en el futuro.

Pisa suavemente y no acarrees nada


Muchos de nosotros caen en la trampa "comprender las cosas por nosotros mismos."Algunas veces veremos un lindo código que nos gustaría aplicarlo a otro aspecto de nuestros programas, sin embargo necesitamos entender que exactamente esta haciendo para usarlo apropiadamente. Primer ejemplo de esto son los tutoriales online.

Cuando yo tropecé con los tutoriales de OpenGL de Jeff Molofee, creí que habían sido enviados del cielo. Con esta ayuda, podía dar el salto inicial mi uso de OpenGL, dado que ese primer par de pasos son los mas duros. Excitado por la API, me puse a escribir mi “engine 3D” (como estoy seguro que muchos antes de mi estuvieron) Mucho después, me encontré dependiendo del código de Jeff como de una muleta en vez de para lo que se pretendía que seria usado. Gaste incontables horas jugando con valores enums y comandos que realmente no conocía, entonces buscaba de vuelta en el tutorial para ver como el lo estaba haciendo. Finalmente me di cuenta de cuanto tiempo estaba desperdiciando a causa de que tenia que adivinar que cosa estaba haciendo, en lugar de solo saberlo. Los tutoriales de Jeff eran geniales, pero intentar imitar lo que el hizo no debería ser nuestro objetivo. Ahora tengo un libro de OpenGL, y en vez de adivinar los detalles de la API comencé a entenderlos, y en consecuencia comencé a apreciar el código de Jeff bajo una nueva luz.

Elige las pasaderas (N del T: En ingles “stepping stones” son las piedras, baldosas, o lajas que forman un camino o escalinata sobre la tierra) en las cuales pisar sabiamente, pero recuerda que existen solamente para llevarte donde estas yendo y solamente te retrasaran si intentas recogerlas y cargarlas contigo a lo largo del camino. También ayuda dejar algunas pasaderas detrás para aquellos que vienen. Otros se beneficiaran como tú lo hiciste, pero sobre todo, te asombraras cuanto se aprende en el proceso de intentar enseñarle a otros.

No lo tomes Personal.


Esto es lejos, la cosa más difícil de hacer. Mucho de nosotros podemos ser muy protectivos de nuestro código a un nivel inconsciente. Programar no es una cosa fácil de hacer, y es lindo poder tomar el orgullo de nuestro trabajo y nuestros logros. Se siente bien tener a alguien apuntando la pantalla diciendo "wow that's really cool" (N de T: Decidí dejar esa expresión en ingles ya que creo que a todos nos es familiar) y saber que tu hiciste eso.

Sin embargo siempre hay más que aprender. Si algunos tienen un enfoque diferente a algo que tú has escrito, no lo tomes como algo personal y no lo descartes o te enojes con ellos. Habla con ellos y una o dos cosas resultaran. Tú aprenderás como programar mejor o tú les explicaras a ellos lo que has concluido y esperanzadamente ellos se volverán mejores programadores. Siendo bueno en programar es lindo y todo, pero trabajar con otros quienes son buenos en programación es un honor que se con mucha frecuencia se toma por garantía. Se profesional y aprende de otros.

Resumiendo.


Eh tocado un montón de temas en este articulo. Por lo tanto antes de que me vaya aquí va una breve recapitulación.

Preparate para lo peor.
No importa en que lenguaje estas trabajando . La primera subrutina que siempre debes escribir es una simple función de impresión de errores.

Espera olvidar.
Comenta todo como si se lo estuvieras enseñando a alguien que no conoce nada en absoluto –alguien como tú dentro de seis meses.

Documentacion
Haz tus archivos de programa contener la documentación, ponlos justo allí en el código, exactamente donde lo necesitaras y finalmente ahorraras el tiempo de todos.

Error humano y Monkey Business
Los humanos cometemos errores, algunos más que otros. Sin embargo las computadoras fueron hechas para hacer tareas descerebradas y mundanas una y otra vez. Es tiempo que empecemos a darle un buen uso y nos ahorremos algo de tiempo y esfuerzo

Un motor tiene correas y vielas.
Escribe código que encaje en el motor como una correa, en lugar de una viela usando el concepto de flexible, reusable y reemplazable código de caso general.

Un nuevo y flamante martillo
Dale a un niño un martillo y probablemente todo se convertirá en un clavo, rogando ser golpeado. Es importante aprender paciencia y buen juicio cuando enfocamos un problema en vez de cargárnoslo incondicionalmente con la última técnica.

Admite tus propios limites.
Nadie sabrá que tu no puedes manejar una tarea si tu no se los dices, y es mejor decírselos de antemano, que sobre la marcha.

Arreglalo, no lo Hackees.
Hazlo bien y no tendrás que tratar con este de nuevo. Luego habrá una cosa menos que causara problemas en el futuro.

Pisa suavemente y no acarrees nada.
Elige tu pasadera sabiamente, pero recuerda que existen solamente para llevarte donde estas yendo y que solo te retrasaran si tratas de recogerlas y cargarlas contigo a lo largo del camino.

No lo tomes personal.
Siendo bueno programando es lindo y todo, pero trabajar con otros que son buenos programando es un honor y muy frecuentemente es tomado por una garantía. Se profesional y aprende de otros.