Cómo motivarse para trabajar en tareas que no te ayudan a mejorar

Para mí, hay dos aspectos de cualquier tarea asignada a un desarrollador en un proyecto de software. Estos no son excluyentes, por lo que una tarea puede ser (por ejemplo) 40% aspecto 1 y 60% aspecto 2:

  1. Tareas que requieren que aprenda cosas nuevas o mejore su comprensión existente sobre ellas. Hacer esto lo mejorará como desarrollador y el conocimiento/experiencia adquiridos es transferible, ya sea a otras áreas en el mismo proyecto o a otros proyectos.
  2. Tareas que son específicas del proyecto o incluso de un área muy pequeña del mismo. Hacerlos solo puede mejorarlo como desarrollador particular en ese proyecto. Incluso entonces, el conocimiento/experiencia adquiridos solo es útil en esa parte específica del proyecto, por lo tanto, inútil, a menos que haya muchas tareas en el futuro enfocadas en esa misma parte.

No tengo problema en trabajar en tareas que son completamente de tipo 2, ya que son parte del trabajo, pero cuando hay otros miembros del equipo que ya han dedicado mucho tiempo a esas áreas específicas, me parece una tarea pérdida de tiempo y recursos para todos. Esto mata absolutamente mi motivación. Sobre todo en un proyecto próximo a terminar, cuando está claro que no habrá más tareas en esas áreas.

Esto puede ser útil para compartir conocimientos entre el equipo, por ejemplo, si alguien renuncia, otros podrían tomar el relevo, pero cualquiera puede dedicar unos días a descubrir un código. Hacerlo por adelantado es como pagar por un accidente que aún no ha ocurrido o que en realidad nunca ocurrirá.

¿Por qué otras personas tendrían que hacer el trabajo pesado que a ti no te gusta? ¿Alguna vez has considerado que a los "otros miembros del equipo que trabajaron mucho en estas áreas específicas" tampoco les gusta?
@MarkRotteveel De lo que estoy hablando no es de trabajo pesado en absoluto. Hay áreas que escribí, cuando alguien trabaja en ellas tomaría 5 veces el tiempo que me tomaría a mí y aprender esa parte no les agregará ninguna experiencia o conocimiento, creo que no hay razón para que lo hagan mientras no me voy
@uylmz Sospecho que has dado en el clavo sin darte cuenta: duplicar el conocimiento y la experiencia entre varios miembros del equipo es una buena práctica precisamente porque la gente se va, se enferma, muere, ese tipo de cosas.
Motosubatsu Siempre asumo que ganan la lotería, el tío rico les deja millones. Mucho más amigable para los empleados :-)

Respuestas (4)

Entiendo que no es agradable estar encasillado; Yo mismo estuve allí, trabajando en proyectos heredados que realmente no son relevantes para la tecnología, la arquitectura o las metodologías actuales. Si me hubiera dejado solo, probablemente habría terminado siendo el "chico del código heredado", así que hablé con mi gerente y le dije que quería hacer otras cosas además de trabajar en cosas heredadas. Entonces, creo que el paso 1 para usted es plantear algo similar a su gerente.

Siempre habrá tareas en el trabajo que no quieras hacer, pero no se resolverán solas y, eventualmente, alguien tiene que hacerlas. Sin embargo, no es justo que esto sea responsabilidad exclusiva de una persona, por lo que tiene perfecto derecho a pedir trabajar en otras cosas, siempre que acepte su parte de la responsabilidad general, tal como lo hace todo buen empleado cuando elige trabajar. para un empleador.

En términos de cómo motivarse durante esos momentos en los que está atascado haciendo cosas que no quiere, aquí hay algunos consejos que funcionan para mí:

  • Si el código es malo, considérelo como un ejercicio para aprender cómo no escribir su futuro software.
  • Recuerda que cualquier trabajo que hagas como desarrollador de software es una experiencia relevante para ti. No siempre tiene que usar la última moda tecnológica o aprender conceptos completamente nuevos para crecer profesionalmente; cualquier codificación que haga contribuirá a que se convierta en un mejor desarrollador.
  • Si es algo realmente horrible y tedioso (y no tengo que usar mi cerebro demasiado), escucho thrash metal y simplemente lo supero.
  • Durante largos períodos en los que no puedes trabajar en cosas interesantes, si realmente quieres convertirte en un buen desarrollador de software, entonces estudia en tu propio tiempo. Lea libros, haga proyectos personales, contribuya a algunos proyectos de código abierto, etc.

Por último, su punto sobre compartir conocimientos es válido. Sin embargo, tu siguiente comentario sobre que es una pérdida de tiempo no es válido; como dijiste, es

pagar por algún accidente que aún no sucedió o que tal vez ni siquiera suceda nunca

Tú mismo lo dijiste; no está garantizado que estos desarrolladores experimentados siempre estarán disponibles, por lo que es mejor para la empresa asegurarse de que suficientes personas conozcan estos productos para poder mantenerlos en funcionamiento en caso de que la gente se vaya (o, como es cada vez más el caso con el código heredado , morir).

Probablemente comenzó por uno de esos "otros miembros, que pasaron mucho tiempo allí" diciendo que también deseaban trabajar en otras tareas, además de que el factor autobús también es un buen argumento.

He usado varias estrategias, según el tipo de tarea, la cantidad, el tiempo esperado, etc.:

  1. ¿Tarea manual aburrida? En lugar de hacer una tarea simple más de 100 veces durante las próximas 5 horas, encontraré una manera de automatizarla (o semiautomatizarla al menos). Puede terminar tomando 8 horas, pero es a) más divertido, b) menos propenso a errores (casi siempre), c) reutilizable (porque sabemos que los problemas puntuales tienden a resucitar repetidamente), d ) al menos, practicó sus habilidades de secuencias de comandos y la próxima tarea será más fácil y más efectiva [usando sus palabras, acaba de mover la tarea al grupo 1]
  2. Conviértelo en una competencia. Mide algo y trata de batirlo continuamente. Seguramente ayuda si no eres el único que hace el trabajo.
  3. Trate de encontrar diversión dentro de la tarea misma. Esto depende mucho de la tarea y su tipo. Si está trabajando en un código heredado desordenado, muéstrele a su colega las partes divertidas "Hola Pete, solo estoy trabajando en , cuando abre esa clase en IDE, el linter parece una gran barra de desplazamiento". Si se pone a trabajar en eso a menudo, puede hacer una competencia (mensual) para "el código peor/más loco/más feo encontrado" o algo por el estilo.
  4. Funciona para tareas más bien cortas: pon música alta (basura), apaga el cerebro y hazlo.
  5. Recuerda que aprendes más de las cosas malas. Siempre supe que es un antipatrón para iniciar sesión y lanzar una excepción en Java. Ver el registro real de esto te hará recordarlo/comprenderlo mucho, mucho más (y para siempre). He despotricado acerca de algunos trucos expertos que son difíciles de entender. Entonces vi scripts de hormigas. De repente ya no me quejo.
  6. Haga la tarea más grande al incluir partes del primer grupo: ¿parte del código con errores? Escribir pruebas (unitarias). Infierno heredado? Haz un poco de refactorización. [los flujos de trabajo modernos deberían ayudarlo a justificar el tiempo que pasa allí]
  7. Hacer la paz interior: si tengo que trabajar en algo que no me gusta, me ayuda escribir un correo electrónico después sobre el tema, cómo se debe hacer correctamente, etc. Incluso si sé que las posibilidades de éxito son cero, lo haré. hazlo Cuando vuelva a explotar, escribiré un seguimiento en ese correo electrónico. [y posiblemente divertirse de cómo las personas evitan el problema, ponen excusas, etc.]
  8. Al igual que en el anterior, crearé tareas para todo lo que esté mal y las mantendré en el trabajo pendiente, luego acepto que es de baja prioridad, pero nunca cerraré a menos que se resuelva. [ayuda con otras cosas también]
  9. La forma de "sentirse bien" funciona para los problemas, etc. Para mí se siente bien ser "el tipo que sabe" y otros vienen en busca de ayuda o ser el "chico que salvó un día" o simplemente ser un buen compañero de equipo y tomar uno por el equipo (como ofrecerse como voluntario para una tarea que todos odian y usar cualquier método para hacerla más divertida y, si es posible, deshacerse de eso).
  10. Tome descansos regulares para mantener la cordura.

Nota: Hay literalmente cientos de formas, según el tipo de tarea (error de código heredado, función de código heredado, clic manual, arreglos manuales de datos, creación de informes, aprendizaje de tecnología antigua/impopular), tiempo esperado de finalización (5 minutos de locura). haciendo clic, 1 hora de reflexión, 3 meses de investigación, ...) etc.

Cómo motivarse para trabajar en tareas que no te ayudan a mejorar

Incluso si tu tarea actual no tiene posibilidad de mejorar (lo dudo), al completar estas tareas liberas tiempo para trabajar en tareas que te ayudarán a mejorar.

Entonces, si su único propósito para trabajar en su empresa es mejorar, su motivación debe ser terminar la tarea A "que no mejora" para que pueda trabajar en la tarea B "que mejora".

Piense en formas de automatizar su trabajo de rutina. Utilice los sentimientos de frustración y aburrimiento como un sistema de encendido para su descubrimiento de métodos de automatización.