Aprovecha esos 15 minutos: ¡programa!
Permalink | Archivado en: Alma Geek, Programación
Cuando tienes delante de ti un proyecto más o menos grande, normalmente estimas que el tiempo para realizarlo ha de se largo. Esto es cierto, pero es que, además, inconscientemente también quizás piensas que hacen falta ratos largos para completarlos. Y el tiempo es como la memoria: cuanto más grande sea el chunk a reservar, más difícil es hacer el malloc.
Un ejemplo cotidiano
Una de las cosas que hacemos mi señora madre y yo es pintar ejércitos de Warhammer ajenos. Imagina más de 3500 puntos de bretonianos sobre la mesa.
Normalmente no podemos dedicar más de una o dos horas seguidas al asunto, lo cual es claramente insuficiente si queremos pintar el ejército entero en un tiempo razonable. Pero nos dimos cuenta de que, a lo largo del día, teníamos pequeños ratitos: mientras se hacen los macarrones, el descanso del partido de fútbol, mientras esperamos que llegue alguien que se retrasa, etc.
Si sumamos todo el tiempo de esos pequeños ratos, podemos conseguir fácilmente el doble de tiempo (o incluso más) para pintar el ejército. Entonces la cuestión se reduce a cómo aprovechar esos ratitos.
Lo que hacemos es tenerlo siempre todo listo para que, si tenemos cinco minutos libres, poder hacer algo, lo que sea, en esos cinco minutos. Aunque sea sólo pintarle el filo de la espada a un caballero andante. Para ello, dejamos todo el material en la mesa de la cocina, con los pinceles listos, botes con agua limpia, las miniaturas en las que estamos trabajando encima de la mesa, etc.
Así, además de aprovechar esos pequeños ratos, tenemos como ventaja extra que no da nada de pereza ponerse a la tarea y, a menudo, dedicas más de esos cinco minutos (y se te queman las tostadas).
Time to code!
Sí, vale, todo eso es muy bonito, ¿pero cómo se puede aplicar esto a programar? Pues siguiendo el mismo principio: dejando todo listo para poder aprovechar ratos de 10 ó 15 minutos. En mi caso, funciono muy bien simplemente haciendo dos cosas:
- Tener siempre lista una versión que compile y funcione. Si tienes 10 minutos libres y te los tienes que pasar arreglando errores de compilación antes de poder hacer nada, no los aprovecharás.
- Tener siempre una TODO list. A priori, parece ser que no hay muchas cosas que se puedan hacer en un cuarto de hora, pero eso no es cierto. En 15 minutos se puede programar un constructor, lanzar una pequeña batería de pruebas, programar el esqueleto de una clase, arreglar un pequeño bug, etc. Si todo esto está apuntado, no se pierde tiempo pensando en qué hay que hacer.
Esto me está ayudando bastante a programar el Demongrave, así que espero poder implementarlo también este curso a la hora de hacer las prácticas. Como siempre, cualquier otro consejo es bienvenido en los comentarios.
13 comentarios »
Si quieres hacer un trackback, usa esta TrackBack URI
Escribe un comentario
Los párrafos y saltos de línea se ponen de forma automática. La dirección de e-mail no se mostrará nunca. Se permiten las siguientes etiquetas XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
La verdad es que mola la idea.
Comentario de spidi — 29-08-07 12:54 pm
Pues si, parece interesante, yo voy a mirar también de probarlo. Oye, ¿y no podrías subir una foto de esos 3500 puntos de bretonianos?:P
Comentario de Gilithunic — 29-08-07 1:06 pm
No es por ser tocapelotas, pero este método para programar es posiblemente el más improductivo que se puede idear. Pintar figuras o acciones que no requieran de, digamos, un calentamiento previo o gran capacidad cognitiva son perfectamente válidas para este método. Pero programar en tramos de 15min es totalmente contradictorio, justamente lo que se aconseja es lo contrario, estar horas y horas en jornada continua sin interrupciones.
Comentario de Blaxter — 29-08-07 1:52 pm
#3 No digo programar *sólo* así, sino programar en ratos largos *Y TAMBIÉN* así. Hay muchas cosas que se pueden hacer en espacios de tiempo cortos.
Comentario de BenKo — 29-08-07 1:59 pm
100% de acuerdo. Además, lo mismo es aplicable a otros ámbitos. Yo estoy liado ahora mismo grabando una canción en casa y estoy siguiendo exactamente ese procedimiento. Tengo la guitarra en un pie de guitarra, fuera de la funda, el procesador de efectos enchufado a la tarjeta de sonido y un cable enrollado que sólo hay que conectar a la guitarra.
Al arrancar el proyecto hay una todo cortita de modo que puedo aprovechar trocitos tan pequeños como cinco minutos.
Bueno el análisis, Benko, pero tu explicación es mejor aún.
Comentario de Isilion — 29-08-07 2:10 pm
Me parece interesante, esos 10 minutos pueden ser útiles para meter mano a pequeñas cosas, es decir, cuando ya sabes qué es lo que tienes que modificar y cómo (pequeños ajustes.
Por cierto, lo de:
“el tiempo es como la memoria: cuanto más grande sea el chunk a reservar, más difícil es hacer el malloc.”
Friki!
Comentario de Koki — 29-08-07 3:09 pm
Como bien dicen, si hay algo que puedas hacer en dos minutos o menos, hazlo de una vez.
Comentario de P-los — 29-08-07 4:11 pm
mmmmmmm…. algo que yo aplicaba cuando estaba en la facu (un par de meses atras) es que cuando estaba haciendo otra cosa, por ejemplo limpiando mi cuarto, caminando a la escuela, etc… siempre estaba pensando como resolver algun inconveniente, o buscando algoritmos mas efectivos, probando mis ideas, y ejecutandolas, todo esto mentalmente oviamente, pero cuando llegaba a la compu, era muy sencillo escribirlas, pues ya estaban muy bien maquinadas, esto me funciono por los 5 anios que estube en la facu
Anyways esto de los 15 min, nunca lo intente, pero creo que antes de sentarte a programar hay que tener claro lo que tienes que hacer, de otra manera no podras aprovechar tu tiempo, personalmente preferiria utilizar ese tiempo muerto que mencionas en analizar el problema, claro esta que si ya lo tienes listo pues si pudieses sentarte a programar.
have funnnnnnnn!
Comentario de stock — 29-08-07 4:30 pm
Yo también uso este método y puedo darfe de su valía.
Comentario de Mpc — 29-08-07 4:37 pm
Y que software usais para gestionar el TODO?
Comentario de Nadid — 29-08-07 6:00 pm
#10, Un boli y papel del MundoReal suelen ir bastante bien.
En su defecto los widgets para páginas de inicio, iGoogle/Netbeans, también suelen ir bien.
O software de escritorio, para Linux tienes Tomboy que son notas estilo wiki (con enlaces entre ellas).
Comentario de Blaxter — 29-08-07 9:10 pm
El Visual Studio también tiene integrada una pequeña herramienta de todos que a mi me va estupendamente. Puedes marcar cualquier función o variable con un TODO y poner un texto cortito. También hay otras herramientas excelentes, como ClokingIt, que es independiente de las aplicaciones. Yo tengo allí todos los TODO’s de mis proyectos personales.
Comentario de Isilion — 30-08-07 11:07 am
No hace falta que estés pensando todo el rato algo nuevo, aunque a veces es inevitable… claro, yo lo que hago en esos caso es apuntar ideas en un TODO.
Para mejorar la productividad de un proyecto por corto que sea, en mi experiencia personal constatada con el desarrollo profesional, es tener bien organizado este trabajo con:
- Documento de Concepto.
- Documento de Especificación Técnica.
El documento de concepto nos ayuda a tener claro la finalidad del producto en sí, para que no se alargue interminablemente queriendo meterle nuevas features.
El documento de especificaciones técnica es donde se desglosa el trabajo y sus diferentes partes, si nos paramos a pensar largo y tendido o poco a poco ( en cada punto ) sobre las diferentes necesidades a la hora de implementar el producto, no tendremos que pararnos luego a pensar. Sino que directamente implementas y tienes una idea global y clara de hacia donde vas y como vas. La productividad que se consigue organizando los diferentes bloques de trabajo antes de la implementación repercuten en progesión geométrica cuando empiezas a tirar código.
Supuestamente una vez que tienes la especificación técnica y eres consciente del alcance y la problemática a resolver viene nuestro amigo UML. Hacer un UML conceptual siempre nos ayudará a organizarnos el trabajo por bloques que no son más que punteros a los diferentes puntos del documento de especificación técnica.
Una vez hecho esto, puedes usar tus 5 minutos para pintar espadas de soldados sin ningún problema. Blaxter
Saludos.
Comentario de Prompt — 07-09-07 1:06 pm