¿Está bien pasar tiempo aprendiendo en el trabajo?

Siempre que su tiempo de aprendizaje (cosas que está aprendiendo más allá del alcance del proyecto actual) no afecte los plazos del proyecto u otros entregables, ser proactivo en aprender cosas que lo ayudarán a mejorar su productividad y/o los proyectos que está trabajando será visto como un resultado neto positivo.

Pero recuerde: su trabajo es hacer que el producto se entregue de acuerdo con las especificaciones/requisitos que le dieron. A menudo, se enfrentará al dilema de "funciona, pero ahora veo que podría haberlo hecho mejor". No haga esto a menos que pueda justificar el tiempo requerido, y no habrá un impacto en las pruebas de aceptación o los plazos del proyecto. Tome algunas notas para usted mismo, y la próxima vez que esté trabajando en ese código, aproveche la oportunidad para mejorarlo.

Lea cuidadosamente la descripción de su trabajo. El mío (no soy un desarrollador junior, pero he tenido líneas similares en cada descripción de trabajo que he tenido a lo largo de mi carrera) tiene una viñeta que habla de esto directamente:

Siga y busque continuamente oportunidades para mejorar los estándares y prácticas de desarrollo, los diseños técnicos, la arquitectura y la estructura de gobierno.

En resumen, significa que parte de mi trabajo es hacer exactamente lo que usted describe.

¿Es generalmente aceptable tomarse un tiempo durante un proyecto para aprender cómo hacer las tareas asignadas de manera más eficiente?

Sí, lo es. Normalmente se espera que busque documentación y aprenda más sobre el oficio durante las horas de trabajo.

Esto incluye aprender y probar nuevas herramientas (bibliotecas, IDE y otras herramientas).

¿Es mejor navegar a través de las tareas y aprender cómo deberían haberse hecho las cosas cuando hay tiempo de inactividad entre proyectos?

Siempre hay algo que aprender de los proyectos existentes: esto también es parte del aprendizaje, solo que es un aspecto diferente.

Debe determinar por sí mismo cuál de estos sería más beneficioso para la empresa; tal vez discútalo con su gerente. De alguna manera, aprender nuevas herramientas y técnicas es más valioso que mirar hacia atrás, aunque hay mucho que decir sobre la introspección y la retrospección: aprender a evitar los errores del pasado.

Mi regla general es pasar el 30% de mi tiempo más o menos aprendiendo nuevas y mejores formas de hacer las cosas (o aumentando mi comprensión de las cosas que ya estamos haciendo). La forma en que lo veo es, si tomo diez minutos para aprender una técnica que ahorra diez minutos, entonces si hago eso una vez, he pagado por el tiempo. Si me toma 2 horas aprender algo que me ahorra 10 minutos, tengo que hacerlo 12 veces para pagarlo. Pero si es algo que hago a menudo, realmente puede valer la pena.

Al principio, el 30 % probablemente no sea una cantidad de tiempo realista para dedicarle a esto. Pero con el tiempo, el tiempo que ha invertido en volverse más eficiente y mejor en su trabajo comienza a acumularse hasta el punto en que puede decidir por sí mismo cuál es el equilibrio apropiado entre hacer el trabajo y aprender a ser mejor en el trabajo.

Una de las cosas que encuentro es que, a veces, paso más tiempo aprendiendo cosas nuevas cuando estoy en una fecha límite, porque las habilidades que tengo actualmente no me permitirán cumplir con la fecha límite. Estos crujidos han tenido algunos de los mayores impactos en mi productividad a largo plazo.

¿Es generalmente aceptable tomarse un tiempo durante un proyecto para aprender cómo hacer las tareas asignadas de manera más eficiente?

Esto, definitivamente esto. De la misma forma que cuando solucionas un bug solucionas la RAÍZ, no un síntoma. Tómese un tiempo cuando se acerque a una tarea para encontrar las herramientas adecuadas para el trabajo, para leer sobre la API. Casi siempre le ahorrará tiempo a largo plazo.

¿Incluso si eso significa correr un riesgo (como probar un marco de trabajo de terceros que puede o no ser utilizado... dependiendo de qué tan bien funcione)?

No tanto esto. Recuerda que eres parte de un equipo, trata de trabajar con ellos tanto como sea posible, no quieres construir una reputación como el tipo verde que sale corriendo y hace cosas enormemente complicadas que nadie más entiende.

Debe buscar sumergirse en una comprensión profunda de la tecnología que se utiliza en sus fuentes actuales y por su equipo actual. Desea que el resto del equipo se sienta relajado al leer su código, no aprensivo. Entonces, si el equipo usa Postgres SQL para todo, use Postgres usted mismo siempre que sea lo suficientemente bueno para el trabajo. Si desea utilizar algo original como MongoDb, primero obtenga la aprobación del resto del equipo discutiéndolo con ellos.

Si bien su estado junior puede hacer que pierda algunas de las decisiones tomadas, asegúrese de tomar nota tanto de los beneficios como de las dificultades de las tecnologías actuales utilizadas. Busque promover cambios en la cultura que crea que serían beneficiosos. Sea proactivo al recomendar tecnologías beneficiosas con un razonamiento convincente.

En poco tiempo serás uno de los chicos a los que acudir en busca de nuevas ideas y tecnologías, pero no esperes que la transición suceda de la noche a la mañana.

Su jefe decidirá en última instancia, por lo que me aseguraría de que lograra dos cosas:

1. Termina las cosas que tu jefe quiere que hagas a tiempo.
2. Si su jefe le permite/espera que mejore sus habilidades (esperemos que no quiera que sea un desarrollador jr. de por vida), asegúrese de que está aprendiendo lo que él cree que es importante. Puede haber planes para trabajar con una pila de tecnología diferente. Aquellos que son competentes pueden sufrir en esta firma.

Haz tu mejor esfuerzo para abrir y mantener las líneas de comunicación. Sepa lo que está pasando en el mundo de su jefe.

Los líderes de equipos disfuncionales rara vez son promovidos en empresas de calidad. Si él / ella no puede ser promovido, no puede ser promovido.