Creo que mi solución es mejor que la de mi jefe, ¿debería ignorarlo? [cerrado]


16

Estoy trabajando con php y sql.

Creo que mi método de implementación de funciones es mejor de lo que propone mi jefe. Justo ahora me explicó cómo hacer una verificación en una lista de direcciones de correo electrónico, y no me gusta su idea. Propuse el mío, que es mejor y más rápido de implementar, pero no estuvo de acuerdo.

Ahora creo que seguiré adelante e implementaré mi idea, porque su idea no era lo suficientemente clara para mí. ¿Crees que se enojará?


71
Parece que el problema podría ser que no estás haciendo un muy buen trabajo al explicar por qué el tuyo es "mejor y más rápido de implementar".
Nicole

21
Agregue más información: (1) ¿Puede su jefe programar? (2) ¿Cuál fue exactamente la solución de su jefe? (2) ¿Cuál es exactamente su solución? Hasta que se entiendan estas incógnitas, es difícil juzgar si su solución es realmente buena.
Darknight

44
¿Eres mejor que tu jefe? ¿Qué te hace pensar eso? Necesitamos detalles
Damien Roche

3
Creo que también podría ayudar editar su pregunta para vincularla con su otra pregunta relacionada: programmers.stackexchange.com/questions/28228/…
Damien Roche

3
Déjame adivinar, ¿has estado codificando por menos de 5 años? Niño dulce e inocente ... :-)
Ed Griebel

Respuestas:


83

Después de haber sido "el jefe" y, como se vio después, en realidad mejor que mi personal en todos los casos excepto uno - sí, que va a estar loco - o molesto o frustrado y, en cualquier caso, muy posiblemente, a la derecha en el primer lugar.

Si eres realmente mejor que él, entonces deberías poder entender su solución propuesta y ver por qué la tuya es mejor y luego explicar por qué.

Pero tú dices:

porque su idea no era lo suficientemente clara para mí

En ese caso, debe regresar y comprender lo que quiere y por qué y si, como ha sido el caso, tanto para mí como para hacer sugerencias a mi personal y para que mi personal me proponga soluciones, usted o él se han perdido algo. Pero no asuma que está equivocado y que tiene razón a menos y hasta que comprenda lo que está pidiendo y si está cubriendo algo en lo que no ha pensado (todavía).


Ah, y en un caso: es un mejor programador, pero no es tan bueno a un par de pasos del problema de que estoy mejor y nos divertimos mucho trabajando juntos por esa misma razón.


13
+1 "a menos y hasta que entiendas lo que está pidiendo"
Dean Harding

3
Gran respuesta, quería agregar que no debemos asumir que el jefe no tiene información adicional de su jefe o de alguien más alto que lo lleve a tener un conocimiento adicional que le permita concluir que su solución es mejor. He visto que esto sucedió antes y en lugar de parecer un imbécil, ayuda a asegurarse de que comprenda a su jefe y de dónde viene antes de saltar a "mi jefe no entiende que mi solución es mejor".
Chris

1
a veces tener la mejor solución no es suficiente ni lo más importante; la realidad es que existen egos, jerarquías y rituales de equipo / compañía consagrados y reconocidos por el tiempo, y son más grandes que usted y tienen importancia a veces más allá de nuestra comprensión inmediata. Lo mejor que puede hacer es analizar y diseñar las opciones una al lado de la otra y presentar sus beneficios y advertencias con suficiente detalle para que el gerente (o equipo) tome una decisión. al menos en ese punto, sabes que has hecho tu diligencia debida y que el destino del proyecto ya no está en tus manos.
jellyfishtree

1
Lo que me hace cuestionar esta respuesta es "haber sido mejor que mi personal". No quiero trabajar para un jefe que cree que es mejor que yo ...
Jason Baker

1
-1. Si realmente eres mejor programando que todos tus subordinados, entonces se te ha dado el trabajo equivocado. Nada dice que un gerente debe ser mejor en todo. Idealmente, un gerente debería ser mejor en la gestión del proyecto, y los programadores deberían ser mejores en la programación. Debería ser igual con todos en cada descripción de trabajo. Un equipo realmente excelente es un equipo donde las habilidades se complementan entre sí para que el equipo sea mayor que la suma de las partes. Lo siento amigo, pero tu actitud arrogante no tiene lugar en un equipo. Ve a trabajar solo y ahorra un poco de dolor a todos.
Riwalk

50

Usted está criticar a él por pensar que eres mejor que él, en lugar de criticar a sus ideas .

Debe cambiar ese comportamiento inapropiado en primer lugar.

Aproveche la oportunidad de desafiar sus ideas positivamente preguntando "why?"suficientes veces. Si la idea es tan estúpida, eventualmente la descubrirá él mismo respondiendo a sus preguntas.

Esta técnica tiene la ventaja de ayudarte a entender. Su idea es probablemente más inteligente de lo que piensas.

Además, seeking to understandantes de tratar de ser entendido, ayudará a su jefe a desarmarse contra usted. Cuando le propones algo a alguien, su cerebro de lagarto intentará determinar si es una delicia. Su cerebro de lagarto quiere que esté a salvo. Tratar de entenderlo reasegurará su cerebro arcaico.

Ahora, si tienes una mejor propuesta, estoy seguro de que estará más que feliz de escucharte. Esté preparado para que le pregunten "why?"suficientes veces hasta que esté convencido.

Después de todo, usted es el profesional, por eso lo contrató en primer lugar. Él debería escucharte.

Si sus ideas no le interesan en absoluto, solo hay una cosa que hacer: dejar de fumar .


2
+1 para "Debe cambiar ese comportamiento inapropiado en primer lugar". Primero entienda la propuesta de su superior por dentro y por fuera antes de criticarla.
Chris

38

Dices que tu método es "más rápido de implementar". Eso me suena a alarma.

El código que es más rápido de implementar puede, a menudo, ser difícil de mantener.

El es tu jefe. A menos que te quedes allí de por vida, él vivirá con ese código por mucho más tiempo que tú. Quizás su estrategia tenga en cuenta ese hecho.

Respuesta corta: la insubordinación es una forma segura de ser despedido.


44
Su respuesta corta es el mejor resumen absoluto del problema.
justkt

No estoy de acuerdo, más rápido y más simple es mejor. Más complejo con muchos casos de esquina es peor y más difícil de mantener. Incluso creo que siempre debes hacerlo de la manera más simple y luego evolucionará si es necesario.
IAdapter

En parte estoy de acuerdo con usted, también creo que 'Más simple es mejor'. Pero, favoreciendo "más simple para la persona que lee el código 3 años después" sobre "Más simple de escribir". Entonces, en ese sentido, 'Simpler' puede tener un compromiso con 'Quicker'. Si me entiendes.
JW01

9

El trabajo de tu jefe no es programarte mejor, es administrarte. Dejando de lado el hecho de que, dada su aparente experiencia en programación y que él puede saber las razones por las que su solución no es la mejor, muéstrele que puede tomar la dirección y confiará en usted más adelante cuando llegue a él con mejores soluciones. .

Casi puedo garantizar que es tu forma de decirle por qué está equivocado (¿qué hay de decir cómo podemos hacerlo mejor?) Lo que te impide ser escuchado.

... no quiere decir que no haya pollas reales sin experiencia por ahí :)


6

Considere que su jefe necesita algunas cosas de usted:

  • La capacidad de programar. Por todos los derechos, a menos que sea un gerente en desarrollo, él (con suerte) te contrató con la esperanza de que seas mejor que él.
  • La capacidad de trabajar en equipo: eso significa escuchar y explicar ideas.
  • La capacidad de hacer lo que te dicen. Cuando se ha dicho la última palabra, después de toda la discusión de un problema, no eres el jefe. Si intentas ser un hotshot cuando te han dicho específicamente que no hagas algo, no puedes confiar en ti.

Si desea continuar con el problema, puede implementar la idea de su jefe, implementar la suya propia (en su propio tiempo si le tomará un tiempo hacerlo) y demostrarles a ambos para demostrar que la suya es mejor. Dejaría la actitud en la ducha cuando lo hagas.


"Cuando se ha dicho la última palabra, después de toda la discusión de un problema, no eres el jefe". Lo que esto significa es que, cuando se trata de explicar a quien le está pagando a usted y a su jefe por qué no funcionó, se alegrará de que su jefe tenga que explicar y no usted.
flamingpenguin

6

Sí, se enojará . Por lo tanto, le aconsejo que le envíe un correo electrónico por qué su método es mejor. Y pídale una aprobación para seguir adelante con su método. Mi punto de "correo electrónico" es asegurarme de enumerar y cotejar todas sus razones antes de continuar cualquier discusión.

Intente redactarlo como " Confío en que este método se adapte al proyecto / problema ", por lo que, a menos que tenga una mejor manera, debería ir con usted.

Si está realmente seguro y tiene suficiente munición para respaldar su punto de vista, vaya con " Confío en que este método se adapte al proyecto / problema por 1,2,3 .. razones "

Otro consejo personal: decir "Soy mejor que mi jefe" parece un poco arrogante, entiendo que puede estar enojado en este momento, pero en un contexto profesional esto no será muy apreciado. Espero que tu jefe no lea esta publicación;)


9
Nunca, nunca, intente resolver un conflicto con el correo electrónico. Los correos electrónicos le permiten reaccionar de acuerdo con el estado de ánimo que tenga cuando los lee.
Morten

Estoy de acuerdo con el comentario de Morten. La mayoría de los conflictos también comienzan en la conversación por correo electrónico. El lenguaje corporal es vital.

@Morten, Pierre: Acepta tus comentarios de "correo electrónico". Quise decir que debería haber una discusión sobre los puntos del OP frente a los puntos de sus jefes.
JoseK

El correo electrónico debe ser un paso posterior para hacer un seguimiento, documentar y detallar la conversación que debe ocurrir primero. Perdí la cuenta de cuántos correos electrónicos han llegado para reprimir a las personas que lo han enviado (yo mismo, incluido). Los desacuerdos y malentendidos más volátiles se debieron a la estrategia de "correo electrónico primero, hacer preguntas después". No importa el tono que tenga en mente al escribir un correo electrónico, el tono casi siempre será interpretado de manera diferente por el destinatario. Si hay una conversación primero, ya se ha establecido un tono.
Mark Freedman

4

¡Ser un gran desarrollador no es solo ser un buen programador! Parte del trabajo es trabajar bien con los demás y colaborar con sus equipos y jefes. Si crees que tu camino es mejor, intenta explicarle eso, mostrándole "datos" de por qué es mejor.

Si afirma que su camino es realmente mejor, intente mantener una mente abierta para el caso de que podría estar en lo cierto. Si no lo es, y solo está ejerciendo autoridad sobre ti, entonces tienes un mal jefe ... (porque parte de ser un gran jefe también es colaborar con tu equipo y administrarlo adecuadamente). En cuyo caso, podría no ser una mala idea comenzar a mirar alrededor.


2

Seguramente es una forma rápida y fácil de ser despedido.

Mi consejo es implementar ambos y usar el que tu jefe quiera.

Si hay un problema, dígale que tiene una solución y muéstresela, pero no le diga por qué la escribió.


Tengo que estar en desacuerdo con este. Crear dos implementaciones solo para demostrar que alguien está equivocado es simplemente una pérdida de tiempo. Estoy 100% seguro de que en la mayoría de los casos es suficiente una discusión normal sobre los pros y los contras de cada solución.
Tx3

No tiene que inclinarse en cada situación. Los jugadores de alto nivel conocen sus cosas, saben cómo demostrarlo y también saben cuándo retirarse. Y son los más buscados y pagan los mejores salarios. Los monos de código traducen especificaciones incompletas en un código incompleto.
Coder

2

No creo que tengas la actitud correcta aquí. Pensar que eres mejor que tu jefe o simplemente pensar que eres mejor que alguien más nunca ayuda. ¿Le dijiste por qué no le gustó su idea o simplemente le dijiste: "Tengo una mejor manera de hacer las cosas"? ¿Por qué es mejor tu idea exactamente? ¿Es un algoritmo menos complicado? ¿Tiene mejor tiempo de ejecución? ¿Es más fácil de mantener? ¿Utiliza patrones de diseño más fáciles de entender?


2

Como ya se han proporcionado muchas respuestas, no le aconsejo que codifique una solución que su cliente potencial no haya aprobado. Primero tiene que demostrarle que su solución es mejor de manera constructiva. Si es un buen gerente y cree profundamente que su solución es mejor que la suya, puede esperar de él que le explique por qué. No olvide que, como gerente, puede tener otros criterios además de usted para definir qué es una solución eficiente. El mantenimiento o la facilidad de lectura pueden ser uno de ellos.

Además, si es un buen gerente, no será deshonroso para él elegir su solución si ha logrado demostrar objetivamente que es realmente mejor.

Pero al final, incluso si aún no está de acuerdo con él, no lo engañe; no hagas algo que él ignore. La gestión del equipo también se basa en la confianza y la transparencia para que pueda arruinar su relación y la eficiencia del equipo. Y los objetivos del equipo deben ser su primera prioridad.

Si la situación ocurre una y otra vez, y sus elecciones siempre son malas, no debería seguir siendo su jefe por mucho tiempo. Si es ocasional, no se sobrecargue ...


1

Parece que estás en conflicto por algo, por lo que debes concentrarte en ser constructivo.

Si sinceramente no cree en su solución, debe encontrar una manera constructiva de decirle cómo se siente al respecto. Hay algunas cosas a considerar en esto. Usted es responsable de su entrega, pero él es responsable de la entrega del equipo. Tendrá que demostrar que su interés es el de la entrega de los equipos y el suyo (que estos dos se alinean).

Haga una lista de ventajas y desventajas con las dos soluciones y discuta con su jefe de manera constructiva. A veces es más fácil mostrar que le falta un componente clave de la solución con una lista.

Intenta entender lo que quiere, es el objetivo final el propósito. Si entra en conflicto por esto, entonces no se está enfocando en el objetivo correcto.


1

Mi consejo es determinar primero si su solución es realmente mejor. Publique las dos soluciones, solicite a SE una opinión imparcial.

NUNCA ignoraría a mi jefe. Si tiene el conocimiento técnico, entonces no hay daño en una discusión saludable. Él considera su idea y tú propones la tuya.

Sin embargo, si determina que, de hecho, su método es inferior y no le permitirá hacer el trabajo para el que lo contrató, renuncie. No hay nada peor que tener a un idiota parado sobre ti diciéndote cómo debes hacer algo cuando claramente no tienen idea de lo que están hablando.


1

Comencemos con el hecho de que es el trabajo del jefe tomar decisiones, no el suyo. Vas en contra de esas decisiones a sus espaldas y es un camino rápido para ser despedido por causa.

Puede y debe presentar sus ideas antes de que se tome la decisión, pero una vez que se toma, es su trabajo hacer que la decisión funcione, incluso si no está de acuerdo con ella. Si no puedes hacer eso, tendrás una carrera muy corta.


0

Depende de la persona. Si es lo suficientemente razonable y le muestras tu solución y es mejor, probablemente no se enoje. Pero si no es así, entonces estás en problemas.

Ahora, para la parte de mierda no genérica: Él es tu jefe. Él no está allí para ser un mejor programador sino para ser un mejor gerente / líder. Tal vez tiene razones que no has considerado.

Si eres un tomador de riesgos, entonces hazlo, pero no te enojes si te despiden. Todo es una apuesta.


0

No muerdas la mano que te da de comer.
Si crees que el tuyo es mejor, incluso después de un análisis exhaustivo, entonces, haz lo que creas, pero vivirás con las consecuencias.


Por qué no? Nadie se beneficiará si el producto final se convertirá en un pedazo de basura. Es importante trabajar en equipo y decidir como equipo. Pero su tarea como desarrollador profesional es encontrar soluciones profesionales y defender su posición si es el momento adecuado.
Codificador

0

Mi jefe no puede programar su salida de una bolsa de papel (en realidad no puede programar solo un buen conversador y estafador, pero para satisfacer sus deficiencias, me obliga a hacer cosas que cubran mi trabajo, para que pueda cubrir lo real cerebros detrás de lo que está sucediendo. El 1% de las ideas provienen de las preguntas clave que hago. El 100% del código y los métodos provienen de mí. Cuando el jefe me da malas ideas, implemento las mías, mi jefe está más interesado en hacerse adelante, un programa exitoso. Mi estrategia de establecer contactos con todos los que lo rodean ayuda a sofocar sus mentiras a nivel local. Ahora trabajo para la división 1/3 de los estados en un cuerpo importante. Usaré la misma estrategia nuevamente, aunque yo ' Necesitaré ser aún más creativo en las redes.

Para responder a la pregunta original en esta publicación, el código de los jefes no es tan bueno como el mío. Como han dicho las otras personas. Qué te hace pensar eso. El código es la lógica. ¿Por qué exactamente crees que el tuyo es mejor? En mi caso, hay una política desarrollada que va más allá de tener un producto exitoso. En mi caso, quiere sofocar mi notarización para impulsar la suya. No estoy seguro de cuál podría ser su situación con muchas posibilidades aquí.


0

Puede ser de cualquier manera, dependiendo de los detalles.

Sé que he estado en muchas situaciones en las que he estado discutiendo con los jefes sobre una cosa u otra. Muchas veces he demostrado que mi idea es mejor, a veces me han mostrado una solución mucho más rápida y completa. A veces ninguno de nosotros lo sabía, así que tuve que hacer la investigación, comparar las ideas y tal vez incluso llegar a algo nuevo para la próxima ronda de toma de decisiones.

Si el jefe es un buen jefe, y usted está en el nivel superior, probablemente sepa que tiene mucha experiencia y una visión mejor / más fresca de los problemas internos, y comprenderá por qué hizo algo si lo explica. a él. También evitará micromanagearlo.

Y a veces, no importa cuán bueno seas, echas de menos cosas simples que luego te hacen preguntarte cómo podrías ser tan estúpido como para pasar por alto una solución trivial. Y el jefe, con su visión general desde la distancia, podría detectarlos mucho más fácilmente.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.