Procrastinar. Cuando Dejas Para Mañana Lo Que Puedes Hacer Hoy

Todos hemos pospuesto en algún momento aquellas tareas que no nos apetecía nada hacer, pese a que sepamos que no podemos olvidarnos eternamente, y que después nos estresaremos más para poder realizarlas.

Una de las causas de la ansiedad que generan síntomas más intensos a nivel emocional y fisiológico es la procrastinación.  Dejar para mañana lo que se puede hacer hoy, es en esencia una actitud que mantiene al cerebro activo buscando no pensar, pero haciendo que en realidad no pueda acabar nunca de hacerlo.

 

¿Por qué Procrastinamos?

Antes de analizar más en detalle qué es procrastinar, hagámonos unas preguntillas ¿Pospones con demasiada frecuencia?, ¿Te dices a menudo que has de hacer cosas pero no las acabas? ¿Te propones tareas, te enfadas contigo mismo y te sientes culpable porque frecuentemente las retrasas? ¿Cuándo pospones una tarea sueles tener buenas razones pero se convierte en una constante?, entonces es posible que procrastines.

Hay estudios que revelan que la procrastinación puede estar ligada a problemas en la gestión emocional. Explica el psicólogo Cristian Mantilla. “Estamos divididos entre el aspecto emocional, el del deseo inmediato, y el racional, que tiene objetivos a largo plazo”.

Para Mantilla, existen tres factores clave que explican este comportamiento: el valor, la impulsividad y la expectativa. Es decir, si para nosotros la tarea tiene poco valor, o la recompensa esperada es mínima, es más fácil que abandonemos. De la misma manera, alguien impulsivo es más probable que se rinda ante lo que le apetece hacer realmente. Pero sobre todo, influye lo que esperamos de nuestro trabajo.

Otra de las razones por las que pudiéramos estar posponiendo un trabajo es porque no sabemos cómo gestionarlo, porque creemos que no va a salir bien o que no estaremos a la altura de la misma. Si una tarea nos parece demasiado complicada, grande o indefinida, es mucho más probable que nos agobiemos porque es más difícil afrontar cosas abstractas y terminamos dejándolas para después.

 

Si se puede dejar de Procrastinar

Para empezar, debemos identificar porque nosotros procrastinamos. Cuanto más útil haya sido a una persona el presionarse para conseguir resultados, con más probabilidad intentará volver a conseguirlos por medio de la presión y la exigencia. Sin embargo no siempre presionarse más garantiza conseguir lo que uno necesita o lo que uno se dice que es importante conseguir.

 

Dejar de procrastinar se consigue haciendo la tarea pendiente, pero también decidiendo no hacerla. Aquí detallamos algunos consejos que te ayudarán a favorecer el hacer cosas y la toma de decisiones sobre lo que debes y quieres y hacer y lo que conscientemente puede esperar.

 

  1. Utiliza la Regla de los Dos Minutos. La Regla de los Dos Minutos tiene su origen en GTD y dice que si estás planificando una acción que se puede hacer en menos de dos minutos, no la planifiques; hazla. Puedes extender ese tiempo a 5 ó 10 minutos. Si haces de esta regla un hábito, habrá una multitud de tareas que no vas a tener la oportunidad de posponer.
  2. Evita las distracciones. Cuantas más tentaciones tengas para hacer otra cosa en vez de lo que tienes que hacer, más fácil será procrastinar. Mantén el móvil, las notificaciones y el acceso a internet desconectados cuando te dispongas a afrontar tareas complicadas.
  3. Divide el trabajo en tareas pequeñas y concretas. Un proyecto grande y complejo puede resultar abrumador. Al dividirlo en pequeñas tareas consigues ver claro el camino y la resistencia a enfrentarte a él disminuye.
  4. Gestiona tu energía, no tu tiempo. Es importante que trabajes en tus mejores momentos. Si estás agotado o de mal humor, tus probabilidades de procrastinar aumentan considerablemente. Para tener una mejor actitud, descansa lo suficiente, controla tu nutrición y haz ejercicio.
  5. Establece una recompensa para cuando termines esa tarea que se resiste. Motívate pensando en lo que harás después de hacerla—algo que realmente te apetezca, te relaje y no suponga ningún esfuerzo. Define tus propios incentivos.

No todo es Malo

Como todo siempre presenta un balance, se ha determinado que también procrastinar en muchas oportunidades estimula la creatividad. Es así como El profesor Adam Grant de la Universidad de Pensilvania dice que nuestras primeras ideas generalmente son las más convencionales, pero si esperamos y le damos tiempo a nuestras ideas para que evolucionen, se nos ocurrirá algo realmente original.

Por su parte Jihae Shin, ahora investigadora en la Universidad de Wisconsin, encuestó empleados en dos compañías diferentes sobre las tareas en el trabajo, nivel de rendimiento y nivel de procrastinación. Luego les pidió a los supervisores que calificaran el rendimiento de sus empleados. Los resultados arrojaron que los empleados que procrastinaban eran, a menudo, los más creativos.

 

Es fácil buscarse una causa que justifique no tener que afrontar lo que no deseamos, lo principal en esto es ser honestos con nosotros mismos para así poder tomar las mejores decisiones orientadas siempre a nuestros bienestar, físico, mental y emocional.

10 hábitos de un Desarrollador de Software Senior

Con el crecimiento de la tecnología, tenemos que esforzarnos más para mantenernos al día con los frameworks y herramientas más nuevas. Sin embargo, muchos desarrolladores ignoran algunos pasos simples que podrían ayudarlos a llevar su carrera al siguiente nivel. Por lo tanto, si bien este artículo está escrito para ayudarlo a mejorar sus habilidades de programación, no cubrirá las mejores prácticas de codificación ni otros enfoques para mejorar su código. En cambio, esta es una lista de diez formas sencillas de sobresalir entre otros desarrolladores.

Automatice tanto como sea posible

Están sucediendo muchas cosas con respecto a CI / CD y DevOps. Puede que todo parezca un mundo loco que aún no estás listo para explorar. Sin embargo, aún puede ahorrar algo de tiempo de desarrollo al automatizar pequeñas actividades ejecutadas con frecuencia, como:

Secuencias de comandos que ejecuta todos los días y que podrían programarse.

Comandos de rutina. En lugar de 4 comandos para iniciar la aplicación, envuélvalos en solo 1 script / comando, por ejemplo: “npm run prepareSeedBuildStart” o simplemente “npm start” o “prepareSeedBuildStart.sh”.

Consultas de datos mensuales que se pueden ejecutar mediante un script.

Además de eso, hay varias herramientas que permiten la integración con otros, compartiendo estados y actualizaciones en todo el equipo automáticamente. En lugar de escribir a su grupo en espera el estado de una implementación, puede simplemente agregarlo en su secuencia de comandos de implementación. El tiempo es dinero.

 

Prueba tu propio código

Esto puede parecer obvio, pero también es un error muy común. Si se le ha solicitado que cree un nuevo CRUD, asegúrese de probar no solo el camino feliz sino también los inválidos. Esto incluye intentar guardar sin datos, leer datos que el solicitante no posee, actualizar sin un campo obligatorio, etc. Sin embargo, si está pensando que este debería ser el trabajo de un ingeniero de calidad o de otra persona, quiero que se pregunte usted mismo:

Si se detecta un error, ¿quién será responsable de ello?

Cuando hay un error en la función que creó, ¿quién es muy probable que lo solucione?

¿Es mejor que encuentre un error y lo arregle o permitir que otra persona lo haga?

¿Cómo se reflejará eso en sus habilidades de programación?

Supongo que no tengo que dar las respuestas a estas preguntas, pero espero que le hagan comprender el valor de las pruebas de desarrollo. Con respecto al tiempo de desarrollo adicional, si esto le preocupa, consideremos que dedicará un 15% adicional de su tiempo a probar la función. Hay dos cosas que podemos obtener de eso: 1. El tiempo en que alguien más encuentra el error, lo informa y lo devuelve para que se resuelva y 2. El tiempo que dedicará a volver a la función y corregir el error. Ambos son mayores que el tiempo de mi enfoque sugerido.

 

Haz siempre lo que prometiste.

¿Sabes ese archivo que alguien te pidió y que dijiste que enviarías en un par de minutos? ¿Qué pasa con la tarea rápida / favor que le pidieron verbalmente? ¿También el mensaje que dijo que respondería con el mejor momento para reunirse? No estoy aquí para discutir si estas solicitudes deben llegar a través de un ticket, porque sabemos que siempre habrá algunas que no lo harán, sino para reforzar que debes hacer lo que prometiste.

Como siempre estamos demasiado ocupados (o simplemente desorganizados) haciendo otras cosas, estas tareas se ignoran muy fácilmente. Sin embargo, todavía existe la expectativa de que se cumplan. Cuando reciba este tipo de solicitudes, considere escribirlas (tal vez publicarlas) en un lugar muy visible o agregarlas a su lista de recordatorios / tareas pendientes. Una vez que haya terminado la tarea, asegúrese de informar a la persona que el trabajo se ha realizado. Esta actitud no solo muestra responsabilidad, sino también respeto por sus colegas.

 

Nunca digas «funcionó en mi computadora»

Aunque lo entendería completamente si alguien me dijera eso, todavía no es suficiente. Vuelve a la propiedad de su código y esta declaración implica que está tratando de encontrar algo (o alguien) más a quien culpar. La mejor solución para este problema sería un CI, que utilizará un contenedor dedicado para construir y probar la aplicación. Sin embargo, si su equipo no tiene eso, hay dos cosas que debe hacer:

Solicite un proceso de CI. Implacablemente.

Asegúrese de probar su aplicación no solo localmente, sino también después de la implementación en el entorno de prueba / ensayo. También puede probarlo apuntando a la base de datos de prueba.

Los problemas suelen ser uno de los siguientes: 1. Dependencias o complementos que instaló localmente pero olvidó agregar al proyecto, 2. Nuevos datos de configuración que agregó en su base de datos local pero olvidó agregar al script de implementación , 3. Su versión local de herramientas y complementos no es la misma que en el otro entorno, 4. El caché no se ha invalidado (tanto para el Front End en los navegadores como para el Back End). Sin embargo, tener un enfoque proactivo, y decir «Mi función no funciona en el entorno de ensayo, pero no sé por qué» es mejor que decir «Funcionó en mi computadora».

 

Sigue aprendiendo constantemente

Inicialmente fui ambivalente acerca de agregar este tema, ya que es un paso obvio. Pero luego me di cuenta de cuántas personas no lo hacen. Si su excusa para no aprender más es la falta de tiempo o motivación, solo tengo una cosa que decir: «No aprenda para el negocio en el que trabaja, aprenda por sí mismo». El aprendizaje no tiene por qué estar relacionado necesariamente con las tareas del día a día, sino con cualquier cosa que pueda ayudarlo a ser un mejor profesional.

No hace falta decir que sería fantástico si buscara conocimientos en su campo profesional. Pero también es seguro decir que: Es mejor saber que alguien ha estado estudiando música (aunque no esté relacionado con el trabajo) que saber que no está aprendiendo nada en absoluto. La gente puede quitarte todo, excepto tu conocimiento.

 

Comprender el problema antes de resolverlo

Lo sé, esto suena muy obvio, pero créame, no sucede tan a menudo como creemos. Aunque hay muchas cosas que contribuyen a este problema, las principales son: “una cultura de hacer las cosas lo antes posible” y “tareas centradas en la ejecución, más que en el problema”.

En una cultura ASAP, la gente se siente atraída a centrarse en las presiones del tiempo mientras se olvida lo más importante, la solución. Le da al inconsciente la idea de que es mejor entregar algo rápido que algo que resolverá el problema.

Con respecto al enfoque incorrecto, imaginemos dos descripciones de tareas: «Actualizar la base de datos a la versión más reciente» o «Permitir a los usuarios utilizar las sintaxis de consulta más recientes a través de la base de datos». Este último realmente informa cuál es el problema y, como resultado, capacita a la persona responsable para pensar en la mejor solución. En lugar de comprar una nueva versión de base de datos e instalarla en la computadora de cada empresa, es posible instalar un parche que aún resuelva el problema, en menos tiempo y a un costo menor.

Es posible que esté pensando que no es culpa del desarrollador si una tarea está mal descrita. Por el contrario, independientemente de la situación, la persona responsable de implementar una solución debe asegurarse de comprender el problema que está tratando de resolver. Si no está claro, deberían preguntar.

Al adoptar este enfoque, el ejecutor de tareas podrá:

Proponer una mejor solución.

Piense en diferentes casos de usuarios.

Proponer una solución más rápida o eficaz.

Informe a la persona que planteó el problema si ya hay algo implementado (solo de una manera diferente) que pueda resolver el problema.

 

Nunca digas «Siempre ha sido así»

Considere este escenario: Paul comienza un nuevo trabajo y el gerente hace todo lo posible para asegurarse de que el empleado actual que será reemplazado comparta todo lo que sabe con Paul. De esta forma, Paul debería poder seguir desarrollando y manteniendo el proyecto por su cuenta. Una semana después, el empleado ha compartido todo lo que sabe, ha proporcionado una guía adecuada de sus actividades diarias (incluido un script que ejecuta manualmente cada mes) y deja la empresa. Ahora Paul está a cargo.

Seis meses después, el gerente busca ayuda y le pregunta a Paul en qué está trabajando actualmente. Paul responde informando que está ejecutando el guión mensual del proyecto y el gerente pregunta «¿Por qué?».

Pablo responde diciendo “siempre ha sido así”, lo cual sería correcto si consideramos que solo ha estado haciendo lo que se le pidió. Sin embargo, debido a que ignoró el impacto de la tarea en el negocio o por qué lo estaba haciendo, la respuesta no es válida. Para evitar esto, es importante ser inquisitivo y comprender por qué las cosas se hacen como están. Quizás hace 2 años se tomó la decisión de ejecutar el script manualmente debido a la falta de tiempo, pero se esperaba que fuera automatizado en algún momento. Quizás fue solo una solución temporal para otro equipo y ya no es necesaria. El punto es que nunca lo sabrá a menos que deje de usar esa respuesta y comience a hacer las preguntas correctas.

 

Haga seguimiento

Probablemente hayas escuchado que “no tener noticias es una buena noticia”, pero créeme, la gente podría estar quejándose a tus espaldas culpándote por no entregar algo a tiempo o diciendo que la última tarea en la que trabajaste no está completamente arreglada. Debido a que damos las cosas por sentado, después de entregar algo, generalmente pensamos que todo está funcionando bien, sin embargo, la persona que necesita la solución podría estar imaginando que usted sabe que todavía no está funcionando. ¿Cómo se arregla esto? Simplemente haciendo un seguimiento. La única forma de asegurarse de que su colega silencioso esté contento o satisfecho con su última solución es preguntándole directamente.

Por lo general, un Project Manager o Scrum Master debería encargarse de esto, sin embargo, las personas cometen errores y no necesito explicar cómo se lo verá como un mejor desarrollador si toma la iniciativa en el «seguimiento». Además de eso, la parte interesada apreciará su preocupación para asegurarse de que se aborden sus problemas.

 

Revisar su propio código

Hay dos reglas principales que tengo con respecto a enviar un correo electrónico: 1. Nunca lo envíe en el calor de la emoción. 2. Vuelva a leerlo siempre. El caso es que suelo hacer algunos cambios, ya que leer mi propio correo me pone en la piel de la persona que lo recibirá.

Cuando se trata de codificación, no hay diferencia. ¿Recuerdas aquella vez que miraste tu propio código y no pudiste entenderlo? Tal vez esto no hubiera sucedido si simplemente hubiera leído su código nuevamente antes del commit. Aquí hay una lista de algunos de los otros beneficios de volver a verificar su propio código:

Valide si su código será claro si alguien más intenta arreglarlo.

Literalmente refactorice.

Corregir un error o error tipográfico.

Recuerda otro caso de usuario y mejora tu solución.

Mejore el rendimiento o la arquitectura.

Si suena como algo demasiado complicado de hacer, sugiero planificar una revisión antes de un commit o una revisión en la diferencia antes de crear un pull request. Hágalo como si estuviera revisando el código de otra persona.

 

Tomar posesión

Imagínese un escenario en el que acaba de conseguir un perro nuevo y todos los demás en su casa lo cuidan menos usted. ¿Eso suena justo? Si no es así, ¿por qué su código es diferente? Actuar de esta manera con respecto a su código da la impresión de que no le importa. Debe comprender que asumir la propiedad no solo ayudará a la empresa, sino que también creará una buena imagen profesional para usted. Aquí hay algunas acciones de alguien que realmente se hace cargo:

Escribe tu código pensando que si sale mal, es tu responsabilidad arreglarlo. Aunque no lo sea.

Si alguien se hace cargo de la tarea, asegúrese de que aún esté bajo su control. No permita que se pierda solo porque se ha reasignado a diferentes personas.

Asegúrese de que esté bien documentado y el código bien escrito, de manera que se sienta orgulloso de hacerse cargo del proyecto.

Asegúrese de haber comunicado y registrado todos los eventos que ocurrieron durante la vida de la tarea / proyecto. Si alguien completamente fuera del proyecto verifica las tareas, ¿podría comprender todas las decisiones y cambios realizados?

Esto parece bastante sencillo, ¿verdad? Veamos algunos problemas que ocurren cuando nadie se hace cargo:

Es difícil rastrear el estado de una tarea que genera un montón de preguntas en el equipo.

Hay muchos errores, problemas de arquitectura y fallas de infraestructura porque a nadie le importaba desarrollar una tarea de manera adecuada.

Las tareas se pierden hasta que alguien de otro departamento las solicita. Luego volvemos a la etapa uno, tratando de averiguar todo lo relacionado con una tarea.

Se asigna a todos en un equipo, pero nunca se resuelve. Puede que no lo resuelva usted mismo, pero cuando se hace cargo, cuida de alguien que pueda ayudarlo a solucionarlo.