¿Cómo trato el problema de "30 minutos restantes"?
Como desarrollador, a menudo llego a este punto en el que al final del día termino una gran tarea y todavía me quedan aproximadamente 30 minutos.
El problema es que 30 minutos no son tiempo suficiente para codificar nada, y si empiezo a codificar desde el comienzo de una tarea, sé que me costará continuar al día siguiente mientras pierdo el contexto y tendré que volver a leer el código, lo que me hará perder tiempo.
Pero para centrarme en el problema profesional, no quiero holgazanear tanto tiempo en el trabajo y quedarme 30 minutos sin hacer nada me parece absurdo.
¿Cómo trato el problema de "30 minutos restantes"?
EDITAR: Para explicar por qué no es un duplicado, el problema no es "¿qué hacer cuando los sistemas no funcionan? " o " ¿qué hacer cuando no tengo nada que hacer? " sino "¿qué hacer cuando llegue cerca hasta el final del día y no tienes tiempo para comenzar una nueva tarea?"
Hay un montón de opciones:
Además de planificar su día, ordenar las cosas y simplemente irse temprano (para compensar quedarse tarde otras veces), permítame sugerir algo que probablemente parezca muy contradictorio:
Trate de evitar detenerse en un "punto de parada natural"
Le preocupa que si dedica media hora a una tarea de codificación, le resultará difícil cargar el contexto cuando regrese al día siguiente. Pero mi experiencia es precisamente la contraria. Digamos que vas a escribir una función simple. Sabes que habrá algo de inicialización, un ciclo para procesar todo el X en el Y, y algo de limpieza. Literalmente agregaré el archivo a mi proyecto, declararé la función, agregaré tres comentarios (tal vez escribiendo la construcción for o while alrededor de uno de ellos) y luego, iré a casa.
Por la mañana, cuando llegue, no necesita recordar lo que estaba haciendo ni consultar sus notas: todo está ahí para usted. ¿Por qué ir a casa con un archivo vacío o una hoja de papel en blanco esperándote por la mañana? En su lugar, al menos escribe un título o una línea de asunto. Al menos escribe el nombre de la función. Si se supone que debe escribir un documento, cree la carpeta, cree un documento vacío con el nombre correcto y coloque el título del documento en la parte superior de la primera página. Aplicar una hoja de estilo.
Empezar. Entonces vete. Es posible que te sorprendas MUY gratamente: es mucho más fácil comenzar si no te detuviste en un punto de parada natural. Despegar desde estos puntos es muy fácil.
De hecho, es tan fácil que a veces uso una variante de esto para engañarme a mí mismo y trabajar en algo en lo que no quiero trabajar. Solo hago la parte de "comenzar": hacer el nuevo proyecto o la carpeta vacía o lo que sea. Crear un archivo llamado esquema y pegar el esquema del correo electrónico. Descargar las especificaciones o las notas de la versión. Encontrar el enlace a ese video que necesito ver. Nada de esto realmente cuenta como trabajar en algo en lo que no quiero trabajar, son solo las cosas iniciales que me permitirían trabajar en eso, así que hago estas tareas sin resistencia. Y luego descubro, cuando los he hecho, que mi resistencia desaparece y soy capaz de hacer la tarea en sí.
Intentalo.
Estaría más que feliz de verte ir a casa y recuperar los 30 minutos algún otro día. Como dices, serás mucho más productivo haciendo esto que tratando de hacer 30 minutos de trabajo, perdiendo el contexto de la noche a la mañana e intentando reiniciar por la mañana.
Pero nunca soy un fanático del trabajo de "9 a 5" de todos modos. Su empleador puede ser más regresivo y más estricto en esto.
Practique la planificación y la escritura. No puede codificar otra cosa, pero generalmente hay algo de planificación para codificar que continúa y si lo escribe en esos 30 minutos, puede leerlo a primera hora del día siguiente y comenzar a codificar. Si pasa por un plan, solo haga otro para estar preparado para sumergirse en un par de elementos en lugar de solo uno.
El nivel de las notas sobre esto dependerá de usted como persona y de lo que le ayude a recordar mejor, pero el objetivo es planificar y articular de tal manera que refresque la memoria de la planificación y lo devuelva a donde estaba ayer sin demasiada pérdida de pensamiento. He visto esto hecho en comentarios de código de marco de alambre, en papel, notas post-it, editores de texto, imágenes de pizarra, etc. Encuentre lo que funciona mejor para usted.
¿Cómo lidiar con el problema de "30 minutos restantes"?
Esto me pasa de vez en cuando, te sugiero que uses el tiempo a tu favor.
Utilizo estos obsequios de tiempo inesperados para investigar nuevas tecnologías, analizar mi próxima tarea o responder/revisar preguntas en Stack Overflow. Aprendo mucho simplemente revisando nuevas preguntas y respuestas.
No se limite a sentarse y pretender estar ocupado. ¡Aprovecha bien el tiempo!
Mantengo una "lista de barrido" de tareas que se me ocurren mientras trabajo en otra cosa, tareas que son lo suficientemente largas como para no querer desviarme y trabajar en ellas de inmediato (o que no quiero para abordar de inmediato por alguna otra razón, como "Quiero que este compromiso contenga solo un cambio lógico"), pero lo suficientemente corto como para que no merezca todos los gastos generales asociados con los proyectos normales. Cada vez que me encuentro con una tarea como esta, la escribo en la lista con una gran cantidad de detalles: adónde ir, qué hacer, quién podría beneficiarse y cuánto tiempo espero que tome.. La mayoría de las cosas en él son casos de esquina demasiado pequeños para obtener recursos "oficiales", refactorizaciones que deberían hacerse, pruebas unitarias que deberían escribirse, etc., pero las cosas que mis colegas me piden mientras estoy en medio de algo más también va en esta misma lista (de ahí el "quién podría beneficiarse").
Cuando tengo fragmentos de tiempo sobrantes, voy a la lista y empiezo a sacar cosas al azar. Cada elemento es independiente y altamente predecible en términos de la cantidad de tiempo que lleva, lo que los hace perfectos para incluirlos cuando tengo 15 minutos antes de una reunión, 5 minutos después de configurar una llamada de conferencia, etc. Además, cuando alguien llega tarde a una reunión, nada los hace más felices que "Oye, estaba pensando en ti, así que incluí esa característica que me pediste hace seis meses, ¿no es encantador?" (Y nada me hace más feliz que no sentarme allí, pensando, "*&@$ reuniones, nunca empiezan a tiempo...")
Como desarrollador, nunca terminas.
Incluso si no puede agregar una nueva funcionalidad a su código en el tiempo restante, puede (y debe) refactorizarlo :
y otras cosas por el estilo.
Cualquiera de estas tareas lleva unos segundos usando las capacidades de refactorización automatizadas de su IDE. Y su prueba de unidad garantizará que no cambió el comportamiento de las aplicaciones tal como está implementado actualmente.
Y en el caso improbable de que rompieras algo: verifica el último estado de funcionamiento de tu SCM...
¿Cómo lidiar con el problema de "30 minutos restantes"?
Siempre dediqué los últimos 30 minutos de cada día a:
Estas son cosas que podrías considerar hacer si a menudo te sobran 30 minutos no programados al final del día.
Y si en realidad no me quedaran actividades que valieran la pena, simplemente me iría.
Si trabaja por hora, use el tiempo para hacer un trabajo ocupado como agregar comentarios y limpieza general. Por lo general, también uso estos últimos 30 minutos para enviar correos electrónicos, escribir informes y completar registros de trabajo.
Por lo menos, navegue por Stack Overflow y luzca ocupado.
Hay muchas tareas para las que una organización podría creer que "no hay tiempo", pero que pueden crear una deuda técnica si se dejan; las pruebas a veces entran en esta categoría.
Convencer a la gerencia de que necesitan gastar dinero en tareas que ahorran dinero en un futuro indeterminado suele ser difícil. Esta vez, si se quejan, puede señalar que tenía 30 minutos libres al final del día y señalar que encontró una cantidad X de errores.
Con demasiada frecuencia, los desarrolladores se ven presionados para terminar las cosas más rápido y no hay suficiente supervisión de la calidad.
Verifique que algo que escribió recientemente esté hecho según las especificaciones: esto me sucedió ayer. Volví a leer parte de la especificación de algo y me di cuenta de que no estaba del todo bien. Pasé unos 20 minutos arreglándolo.
Personalmente, esto me sucede durante los últimos 15-20 minutos del día.
Lo que me ayuda es planificar el día (o la semana) siguiente al proponer algunos elementos de acción, etc.
Debería considerar dividir su tiempo en el trabajo en bloques que sean lo suficientemente grandes como para permitirle trabajar libremente dentro de cada bloque pero que no sean excesivamente grandes. Puede pensar que los bloques arbitrariamente grandes que duran tanto como sea necesario para realizar alguna tarea funcionan bien para usted, pero la concentración se ve afectada después de unas pocas horas de trabajo ininterrumpido. Si impone un descanso después de, digamos, 2,5 horas, entonces puede escupir un día laboral de 9 horas (8 horas de trabajo más 1 hora de descanso) en 3 bloques de este tipo con descansos de 20 minutos para café/almuerzo entre bloques y un descanso adicional de ejercicio de 50 minutos.
Luego eliminará este "problema de la última media hora", solo habrá un último bloque de 2.5 horas que se sentirá totalmente diferente a sus últimas horas actuales en el trabajo. Si termina una tarea dentro del último bloque, tendrá mucha más energía para continuar con otras tareas o planificar para el día siguiente. Habrás comenzado ese bloque con más energía y al comienzo del bloque probablemente sabrás que vas a terminar antes de tiempo, lo que te hace más propenso a pensar positivamente en hacer otro trabajo después de terminar el proyecto. .
El hecho de que ahora no estés inclinado a hacer eso es un artefacto de "trabajar hasta el final de una tarea" que drena energía mental; Si organizas tu trabajo en maratones largos, no es de extrañar que al final de una tarea te sientas como un corredor de maratón al final.
Cualquier software de una complejidad (no muy alta) se puede hacer siempre un poco mejor.
Haz tu código un poco mejor.
Mi trabajo tiene diferentes tipos de trabajo. Trabajo que hay que hacer hoy. Trabajo que hay que hacer esta semana. Trabajo que debe realizarse en el próximo medio año.
El trabajo que debe realizarse en el próximo medio año consiste principalmente en pequeñas tareas serviles con poco "pensamiento-trabajo". Estas son las cosas que hago en el tiempo libre entre tareas más grandes. Son buenos rellenos para dejar que tu cerebro se relaje al final de la jornada laboral.
Pensar en el futuro. A menos que realmente esté al final de un paquete de trabajo y "solo le quede una cosa por hacer", cambie a otra tarea que lo llevará hasta el final del día antes de llegar a los "solo quedan 30 minutos". situación.
En realidad, no entiendo muy bien por qué "30 minutos no son tiempo suficiente para que codifique nada". Si no divide (o no puede) su trabajo en partes más pequeñas, no suena muy forma eficiente de progresar. De hecho, si usara una técnica de gestión del tiempo como Pomodoro , estaría dividiendo todo su trabajo en partes de 30 minutos.
Según tengo entendido, estos 30 minutos quedan después de todas las tareas administrativas/oficinas.
En mi experiencia, uso este tiempo para tomar nota de mis pensamientos y la funcionalidad futura que planeo. de la forma más descriptiva posible
Lilienthal
usuario
pavel
Pablo D. Waite
usuario8036
codificador de barcos
usuario207421
Emond
Marte
marxin
andrea lazarotto
Tvde1