2009-05-07 42 views
6

Un proyecto en el que estaba trabajando ha finalizado, por lo que me cambiaron a una nueva tarea en mi empresa. El trabajo previo fue muy ágil, pequeño equipo, progreso sobre el procedimiento, etc. etc.Cómo lidiar con la gestión inepta

De todos modos, el nuevo proyecto en el que estoy, me encuentro confundido sobre cómo tratar con la administración. No tienen una comprensión real de la programación orientada a objetos, las tecnologías actuales o las metodologías. Parecen temer el cambio y recientemente nos mudamos a la última JRE

Hacemos estas revisiones de código y tengo que escuchar "barbas grises" diciendo cuánto mejor está en ADA o cómo solían hacer las cosas en C Pero luego, cuando intentan revisar los códigos, carecen de la comprensión más básica del diseño y desarrollo de OOP. Se enfocan más en el estilo del código; espaciado; nombres de métodos; etc.

Una de las personas de alto nivel dice que deberíamos escribir nuestro propio registrador en lugar de usar log4j debido a una revisión negativa de log4j en un PDF académico escrito hace siglos.

¿Cómo manejo esto? ¿Cómo puedo explicarles que su diseño es defectuoso o que están realmente retrasados, sin que parezca un imbécil? Solo he estado con esta organización durante aproximadamente un año, así que no sé cuánta credibilidad tendré.

+2

Entiendo que el formateo estadísticamente inconsistente se correlaciona con un alto número de errores. Lo cual es lógico, porque si ni siquiera puedes formatear correctamente, entonces no hay esperanza. –

+0

Esta pregunta parece estar fuera de tema porque se trata del entorno del lugar de trabajo. Es demasiado viejo para migrar a [workplace.se]. –

Respuesta

11

En cuanto a la revisión del código, les digo que los hagan felices. Nombra y espacia las cosas como quieran. Enfoque su tiempo en un mejor diseño, por supuesto, y disfrute de los recuerdos de la ADA, todavía le puede dar una idea de dónde están las cosas hoy y cómo llegaron allí.

En otras palabras, no tome esa parte demasiado en serio. Preocuparse por lo que es importante para hacer el trabajo. El trabajo en este caso es hacer que aquellos que te importan sientan que hiciste una contribución positiva al proyecto.

En cuanto a Log4j, solo sugeriría un marco diferente. Ya sea el registro integrado de JDK (no se puede quejar de eso, es una API integrada) o algo así como SLF, que te permite conectar lo que quieras (incluido el tuyo, supongo, que luego puedes descartar y reemplazar con algo real cuando se dan cuenta de que fue un error, y solo tienes que cambiar el classpath).

Ahora habrá momentos en los que sea importante. En ese caso, haz que suene tanto como sea posible que sea su idea. Por ejemplo, en el registro, declare que existen muchos marcos de registro que representan muchas líneas de código, y se preguntaba si hay otras formas de aprovechar ese trabajo para este proyecto, y luego deje que ellos "se den cuenta" la solución.

Habrá momentos en los que tendrá que presionar algo como su idea: no habrá otra forma. En ese caso, adhiérase a la evidencia, aliados marciales tanto como sea posible manteniendo relaciones con aquellos que sí tienen buena influencia, y comprenda que en cada batalla que pelea, pierde posición, incluso si gana (quizás especialmente si gana). .

3

Recomendaría abordar sus inquietudes como 'sugerencias'. Haga una sugerencia y pídales su opinión al respecto, de esa forma se sienten como si todavía tuvieran el control a pesar de que han plantado la semilla y están dirigiendo la conversación.

Independientemente de cuánto tiempo haya estado en una organización, usted está allí y usted está allí por una razón (lo contrataron para su aportación). Encuentre su voz y la mejor forma de acercarse a los miembros de su equipo con sugerencias y/o inquietudes. Esta es una parte crucial de ser miembro del equipo y aumentará su valor.

1

Obtenga un buen formateador y cree sus nombres de métodos de los que no puedan quejarse, entonces su discusión puede pasar a problemas reales.

Algunas personas no pueden olvidar estos pequeños detalles durante las revisiones, por lo que debe dejar de ser un problema.

0

No estoy de acuerdo con la recomendación de otro marco de trabajo de registro además de log4j. Citar una revisión anterior, sin ningún tipo de experiencia personal, no debería ganar el día aquí.

Sin embargo, podría haber una manera de aprovechar esto. Si acepta y recomienda el registro integrado en el registro JDK o Apache Commons, encontrará que ambos son bastante similares y que realmente pueden usar log4j como su implementación subyacente.

Si su adversario no está prestando mucha atención, puede ganar puntos por ceder y evitar un argumento de abandono de bicicletas y TODAVÍA obtener lo que quiere.

+0

Ciertamente estoy de acuerdo en que no debería (yo uso Log4J regularmente, funciona bien, y de todos modos, tal atención al marco de trabajo es algo ridículo en la mayoría de los casos). Pero eso simplemente no es su realidad. – Yishai

-9

Mi invitado, usted está equivocado. Mal desde el principio.

Mi invitado de nuevo: no dude en ACEPTAR las reacciones de contienda!

Puede pasar ese rango: novato.

Nota: La gerencia es nuestros empleadores. Nos pagan siempre que podamos ayudarlos. Si no te quieren, estás equivocado, y tienen razón, ya que hablamos de que hay dinero. Si tiene el derecho solo en su libro, tiene un problema ...

+0

¿Qué? Creo que el inglés no es tu primer idioma, así que ten cuidado con la elección de tu palabra y la ortografía para que podamos entender. – thursdaysgeek

+0

Tienes razón, soy francés y no hablo inglés. Es decir, su comentario no aporta nada a la discusión. – SRO

+0

¿Por qué es esta la respuesta aceptada? No entiendo. – Parappa

1

Su trabajo debe ganar credibilidad antes de que lo escuchen. Entonces, sí, haga lo que otros recomendaron, y asegúrese de cumplir con las leyes de formato sin importancia. Pero también haga un trabajo de tanta calidad que no puedan ignorarlo o marginarlo. Intente guiarlos de manera que los haga pensar que las ideas provienen de ellos.

1

Respeto a tus mayores Yo digo! :)

Realmente, solo recuerda que muchas de estas barbas grises probablemente fueron programadas mientras estabas en pañales. Eso no los convierte en expertos en las últimas tecnologías, pero al menos debería ganar su respeto. Y a veces, si puedes encontrar una manera de mirar más allá de todo el dobladillo y el alabeo y "volver a mi día", ¡puedes recoger algunas perlas de sabiduría de esos viejos perros!

Ahora, desde la perspectiva de la programación, parece que Yishai tiene razón. Debería ser bastante fácil ajustarse a los estilos de codificación que desean, y una vez que los haya hecho felices, puede ejecutar el código de la forma que desee.

Y si tiene que presentar una opinión contraria, haga una copia de seguridad. Si desea usar algo como log4j, hable sobre proyectos ESPECÍFICOS en su pasado donde lo haya usado y funcionó bien, y ofrezca ayudar a cualquiera a superar cualquier problema que tenga, etc. etc.

Recuerde , mientras miras las viejas barbas grises como si no supieran cómo hacer una buena programación nueva, probablemente te vean como un pargo joven con muchas ideas locas para cambiar el mundo. Una pizca de paciencia te dará una libra de respeto.

1

Soy una vieja barba gris, pero abandoné COBOL hace 35 años y codifiqué en dotNET C# y me mantuve en contacto con los jóvenes traperos y trato de guiarlos también. Dicho esto, veo una gran cantidad de gerentes y programadores que todavía están en la era oscura como VB6 y no pueden aceptar granjas web, servicios web, algunas de estas barbas grises y jóvenes navegantes no pueden normalizar una tabla de base de datos a 3NF y mucho menos codificar nTier, WCF o tengo una pista. Peor aún, algunos de los gerentes tienen 30 años de retraso y confían en el VB6 en el mejor de los casos y en un archivo plano que usa Access97.

Cuestiones relacionadas