¿Debo hacer mi trabajo como dice mi jefe, si conozco una mejor manera?

¿Debo hacer las cosas como dice el jefe, lo que requiere un poco de estudio, o hacer las tareas a mi manera, lo que requiere el uso de un programa de código abierto en particular?

Le recomiendo encarecidamente que utilice la metodología y la tecnología descritas por su jefe. Él tiene más experiencia que usted y tiene más experiencia en dominios comerciales y técnicos.

Una vez que tenga algunos proyectos en su haber, siéntase libre de ofrecer sugerencias que podrían hacer que una tarea se complete más rápido. No se sorprenda de que cuando lo haga, es posible que tenga que justificar su sugerencia desde una perspectiva de tiempo de comercialización, costo inicial y propiedad total.

Discuta su enfoque con el jefe. No haga parecer que su enfoque es mejor y que está ignorando su enfoque.

Jefe, analicé esta tarea y me preguntaba sobre el siguiente enfoque alternativo. ¿Qué piensa usted al respecto?

Hay dos resultados principales, los cuales pueden ser beneficiosos para usted:

• Boss le explica ¹ por qué el enfoque que sugirió es mejor

  Esto le muestra una parte del panorama general y un adelanto gratuito de lo que sucede detrás de escena cuando los jefes toman estas decisiones. A medida que asciende en la escala corporativa, usted mismo será responsable de tomar estas decisiones, por lo que esta información le ayudará más adelante.

  Su empresa está haciendo negocios y el desarrollo de software es solo una parte de ese negocio. Por lo tanto, las consideraciones comerciales tienen prioridad sobre sus preferencias personales . Como desarrollador junior, es posible que te centres casi por completo en la parte de desarrollo de software, pero tu jefe es responsable de tomar la decisión comercial correcta.

• Boss se da cuenta de que su enfoque es mejor

  Esto es menos probable, pero no imposible. En este caso, no solo puedes hacer la tarea a tu manera, sino que también creas una impresión positiva. La próxima vez que tenga que hacer esta tarea o algo similar, su jefe lo recordará como la persona que encontró una mejor manera de hacerlo ² .

Entonces deberías hacer lo que dice el jefe , en cualquier caso. Sin embargo, con el enfoque anterior, su jefe vería que en realidad está pensando en el trabajo que está haciendo . Esto también suele ser una consideración importante al decidir sobre promociones en los niveles inferiores. Un desarrollador junior que solo hace lo que se le dice necesita supervisión constante y no será promovido, mientras que alguien que persistentemente trata de contribuir y comprender cómo funcionan las cosas puede confiar en una mayor responsabilidad.

¹ Si el jefe no está dispuesto a dar explicaciones, puede preguntarle cortésmente, pero no lo moleste. A veces, el jefe decide que hacer el trabajo es de suma importancia y convencer a un empleado subalterno está muy abajo en su lista de prioridades. En ese caso, solo haga el trabajo como él dice, y tal vez haga preguntas más tarde cuando esté más dispuesto a dedicar algo de tiempo a la explicación.

² A menos que su jefe sea un idiota que se ofenda, en cuyo caso tiene un problema mucho mayor, que está fuera del alcance de esta pregunta.

Cuándo debe seguir a su jefe
Cuando su jefe le da instrucciones explícitas sobre cómo debe hacer algo, debe hacer el trabajo de la manera en que lo describe. Por lo general, no se esfuerzan por delinear cómo se debe hacer algo a menos que les importe el cómo.

En especial, no debe 'volverse pícaro' haciendo lo suyo después de que el jefe le dé instrucciones si eso implica el uso de bibliotecas de terceros. Por lo general, existen numerosos problemas que podrían surgir del uso de software de terceros, y como nuevo desarrollador, esta no es una buena idea. El uso de software de terceros (especialmente sin aprobación) podría resultar en uno o más de los siguientes:

• Problemas de estabilidad
• ramificaciones legales
• Violación de la política de la empresa con respecto al proceso de aprobación de agregar nuevas bibliotecas al sistema.
• Vulnerabilidades o riesgos de seguridad
• Necesidad de volver a hacer el trabajo porque cualquiera de los anteriores fue un problema

Si tiene problemas con la forma en que el jefe le pide que haga el trabajo y está seguro de que hay una mejor manera, debe presentar sus hallazgos a su jefe y obtener la aprobación antes de hacer el trabajo a su manera. Por lo general, está mal visto cuando los nuevos desarrolladores demuestran que creen que saben más que los ingenieros superiores y no aceptan las instrucciones.

Cuándo debe tomar la iniciativa
Una vez que comprenda completamente el sistema y las necesidades comerciales detrás de un proyecto y tenga la libertad de completar un proyecto sin instrucciones adicionales o supervisión sobre cómo se debe realizar el proyecto, puede sentirse libre de hacerlo de la manera te parece bien. Por lo general, los desarrolladores más nuevos deben someterse a revisiones de código para que los ingenieros senior y de nivel medio puedan revisar el trabajo hasta que todos se sientan cómodos con la calidad del trabajo que se está realizando. (Realmente, las revisiones de código deberían continuar e involucrar a todos, pero esto se sigue con mucha menos frecuencia y es otra discusión para otro foro).

Escucha a tu jefe

Los desarrolladores junior a menudo no ven el aspecto de mantenibilidad de las soluciones propuestas. Sí, es posible que tenga un enfoque de código abierto genial para resolver el problema, pero no ayuda a su jefe (o a la empresa) a largo plazo si usted es la única persona del equipo que sabe cómo apoyarlo. Piensa en lo que sucede si te vas de vacaciones o te enfermas o te vas. ¿Qué pasa entonces? No es tu problema, pero tu jefe puede enojarse por eso.

Esto no es para matar su espíritu innovador, pero hay una realidad más grande a considerar cada vez que presenta algo nuevo.

¿Tengo que hacer las cosas como me pide el jefe?

SÍ

Siempre tienes que hacerlo como tu jefe te lo pide .

Si tiene una alternativa sólida y su jefe está abierto a recibir aportes, puede convencerlo de que le pida que lo haga de otra manera, pero aún lo haría de la manera en que su jefe lo pidió .

Supongamos que soy su jefe. Si te digo que hagas A...

1. ... y haces B, eres un mal empleado y probablemente me enojaré o me decepcionaré contigo. Confiaré menos en ti, ya que haces lo que te place.

2. ...y me convences de que B es mejor, entonces te pediré que hagas B y harás lo que te diga. Te tendré en alta estima. Ambos (encontraron una mejor manera de hacer algo) e (hicieron lo que se les dijo) .

3. ...y no logras convencerme de que B es mejor, y haces A, te tendré en mayor estima. Propusiste una alternativa, que podría haber sido mejor, pero aceptaste las órdenes superiores. Aprecio ambos.

4. ...y no me convences de que B es mejor, y haces B... ver (1) . Probablemente peor: no puedes alegar ignorancia o buena voluntad, ya que te dije explícitamente que no hicieras B.

5. ...y no logras convencerme de que B es mejor, y haces ambas cosas para "probarme" que es mejor... es un movimiento arriesgado. Pasarías más tiempo, tal vez innecesariamente, e incluso si tuvieras razón, podría resentir tu desafío. REALMENTE depende de mi personalidad, estado de ánimo actual y tu relación conmigo. Es arriesgado y solo lo recomendaría si CONOCES a tu jefe y REALMENTE CREES que funcionará bien. Incluso entonces, es arriesgado.

Entonces, si realmente cree que su camino (B) es mejor, debe presentar un buen caso para ello, lo suficiente como para que su jefe diga "Ok, adelante e inténtelo". No seas molesto ni demasiado insistente. Si no obtienes su aprobación, simplemente déjalo. Hazlo como dicen. Gánese su confianza y respeto con un trabajo sólido y probablemente la próxima vez estarán más abiertos a sus sugerencias.

Tu jefe es, bueno, tu jefe.

Están literalmente a cargo de lo que haces. Ese es su trabajo. Es su propósito de ser. Ellos están ahí para decirle qué hacer.

A veces pueden decidir que quieren escuchar sus consejos y, a veces, incluso pueden decidir seguir sus consejos. Pero no tienen que hacerlo, porque son tu jefe.

Es su decisión.

Esto no es difícil.

En una palabra, sí.

Si bien el uso de un programa de código abierto para resolver el problema puede funcionar a corto plazo, no hay forma de saber cuál será su estado en el futuro. Las empresas dedicarán un poco más de tiempo a hacer algo por su cuenta para garantizar el mantenimiento de ese software, porque se trata internamente.

Además, puede considerar que su jefe le presenta esta tarea como una experiencia de aprendizaje. No hay nada de malo en perfeccionar las habilidades :)

Considérese que tiene un cierto presupuesto de capital social que puede ser utilizado por un comportamiento "desafiante". Incluso un nuevo empleado junior tiene algo de este presupuesto.

Sin embargo, considere que tiene un suministro escaso de este presupuesto en el futuro previsible. Si gasta de más, se producirán consecuencias, que pueden incluir el despido.

En una situación como esta, la pregunta central es: "¿Vale la pena empujar a mi jefe mucho más cerca de despedirme?"

Si el problema es solo que su jefe le ha dicho que haga algo de una manera particular sin usar herramientas de código abierto, realmente no quiere desperdiciar su presupuesto de capital social en esto. Puede llevar más tiempo y requerir una depuración que el proyecto de código abierto ya ha realizado, pero la respuesta correcta, para un empleado que quiere estar en el mismo trabajo un año después, es " No " .

Como desarrollador de nivel junior (o cualquier cosa de nivel junior), no es su trabajo reinventar la rueda o ser "creativo": su trabajo es establecerse como un recurso confiable y creíble.

Si bien definitivamente puede preguntar por qué su jefe quiere que se haga de cierta manera, no se sorprenda si no obtiene una respuesta satisfactoria (en su opinión).

No hay nada más molesto para un gerente que un empleado que piensa que es más inteligente que su gerente. Desafiar repetidamente a tu jefe es lo que los expertos conocen como un "movimiento que limita tu carrera" y créeme, la gente lo recuerda mucho más tiempo de lo que puedas imaginar.

Será mejor si escucha a su jefe correctamente y programa según las instrucciones.

• La razón principal detrás de esto es que es posible que no sea el único programador del proyecto, por lo que si sigue la guía, eso será bueno para los demás programadores y los programadores que trabajarán después de usted.

• Cada empresa tiene una estructura/cultura de trabajo especial, aquí me refiero al modelo de software. si todos los programadores siguen la misma pauta, será fácil para todos comprender el código de los demás.

Si eres un desarrollador junior , entonces, sí. Su papel está integrado en su título. Los desarrolladores júnior son contratados para hacer el trabajo duro. Puede parecer un poco explotador, pero al mismo tiempo, hacer el trabajo duro ayuda a los desarrolladores a comprender el código y familiarizarse con los patrones y procesos, especialmente en lo que respecta a cómo los utiliza su organización en particular.

Haz las cosas como dice tu jefe, pero aún puedes ser creativo mientras coloreas dentro de las líneas. Busque formas innovadoras de mejorar la eficiencia, la legibilidad y la estabilidad de su código. Asegúrese de que se haya probado a fondo y piense en escenarios de casos límite para probar. Casi cualquier código de desarrollador junior se revisará en algún momento, y si el revisor ve constantemente un código sólido, eficiente, completamente probado y bien documentado, entonces su opinión tendrá mucho más peso. Con el tiempo, es posible que pueda sugerir nuevas formas de hacer las cosas, ya que ha demostrado una buena ética de trabajo y prácticas de codificación sólidas. También es más probable que te asciendan a un puesto con más autonomía en ese momento.

Recuerde también que, para bien o para mal, la comunidad de programación está muy basada en castas. Los desarrolladores senior no siempre son amables con los desarrolladores junior pensando que saben más, incluso si lo saben. En última instancia, debe mostrar respeto en todo lo que hace. Incluso si conoce a un desarrollador en particular, su jefe, etc., están completamente equivocados, no salga y diga eso. En cambio, aborde los conflictos desde una perspectiva de aprendizaje. Pídele a tu jefe o a quien sea (amablemente) que te explique por qué se debe hacer una cosa de la manera que dice que se debe hacer, para que realmente puedas entender. A menudo, puede comenzar conversaciones de esta manera y, potencialmente, presentar sus ideas de una manera más relajada, donde su jefe no escucha tanto "estás equivocado" como "trabajemos juntos para encontrar la mejor manera".

Por último, no seas arrogante. Todos los desarrolladores de todos los niveles de experiencia siempre piensan que son estrellas de rock. Es un efecto secundario de lo que hacemos, ya que el acto de creación hace que uno se sienta como un dios. Sin embargo, la simple verdad es que siempre hay algo nuevo que aprender y siempre áreas en las que puede mejorar. He estado programando la mayor parte de mi vida, y todavía aprendo cosas nuevas todos los días, todavía tengo momentos de estupidez que golpean la cabeza todos los días. Está bien. Eso es normal. El peligro viene cuando crees que lo sabes todo, porque entonces eres imposible de enseñar.

Sí, he recorrido este camino tantas veces que, con suerte, su jefe supervisará todo el panorama. He perdido la cuenta de las veces que pude hacer las cosas de manera más rápida y eficiente, solo para que me informaran más tarde sobre una dependencia/característica que cambia completamente el juego. Seguir el procedimiento establecido y posteriormente, en su caso, sugerir mejoras/retroalimentación.

Como han dicho otros, la respuesta corta es "sí". Haz lo que tu jefe te dijo que hicieras.

Puede pensar que su manera es "mejor", pero la definición de mejor de su jefe puede ser diferente a la suya. Si eres un programador junior, entonces, por lo general, tu jefe tendrá un conocimiento y una experiencia mucho más amplios que los tuyos. Por ejemplo, sabrá cosas como:

1. Lo que se ha intentado antes en la empresa, y por qué algunas cosas funcionaron y otras fallaron. Las causas de la falla a menudo no son técnicas; pueden estar más relacionados con la experiencia del personal, la voluntad de invertir, la estructura organizativa o incluso la política interna.
2. Qué proyectos futuros dependen del actual.
3. El plan estratégico de la empresa; específicamente la visión de la empresa de lo que quieren ser conocidos.
4. Qué atributos valoran los clientes en sus productos
5. Qué tipo de cosas pueden ser explicadas por su personal de Ventas/Marketing (si las hay) y, por lo tanto, utilizadas para vender el producto.
6. Las implicaciones legales de hacer las cosas de una manera frente a otra.
7. Los amplios impactos económicos/financieros de hacer las cosas de una forma frente a otra.
8. La vida útil prevista del código que está escribiendo.
9. Planes para mantenerlo/mejorarlo.

En un mundo ideal, su gerente le explicaría todas estas cosas para que conozca el contexto completo del trabajo que está haciendo. Pero no todos los gerentes tienen el tiempo o la inclinación para hacer eso. Puede presionar para obtener estas explicaciones, pero deje de presionar si siente alguna molestia. Sin estas explicaciones, no puede decir qué enfoque es "mejor", así que simplemente haga lo que su jefe le dijo que hiciera.