¿Cómo sugerir cambios como empleado recientemente contratado? [cerrado]

Recientemente fui contratado en una gran empresa (miles de personas, para dar una idea del tamaño). Dijeron que me contrataron por mi rigor y porque, a pesar de mi juventud (tengo 25 años), tenía experiencia como programador de C / C ++.

Ahora que estoy dentro, puedo ver que todo el sistema es viejo y a menudo utiliza tecnologías obsoletas. No existe una convención de nomenclatura (archivos, funciones, variables, ...), no usan Control de versiones, no usan excepciones ni polimorfismos y parece que casi todos perdieron su pasión (algunos de ellos tienen solo 30 años) )

Me gustaría sugerir algunos cambios, pero no quiero ser "el chico nuevo que quiere cambiar todo solo porque no quiere encajar". Traté de "encajar", pero en realidad, me lleva una semana hacer lo que haría en una tarde, solo por las malas herramientas que nos vemos obligados a usar. Muchos de mis colegas nunca miran las nuevas "cosas" y técnicas que la gente usa hoy en día. Es como si acabaran de rendirse. La situación es realmente frustrante.

¿Alguna vez has estado en una situación similar y, de ser así, qué consejos me darías? ¿Hay alguna manera sutil de cambiar las cosas sin convertirse en la oveja negra aquí? ¿O debería simplemente renunciar a mi pasión y energía también?

Gracias.

Actualizaciones

Siguiendo sus valiosos consejos pude sugerir cambios y ahora estoy a cargo del equipo que debe crear e implementar Subversion: D ¡Gracias a todos ustedes!

6 meses despues

Renuncié y encontré un entorno mucho más interesante, con una paga mucho mejor y desafíos más interesantes. No volvería por nada.

Estaba en una situación similar en mi empresa anterior, donde estuve durante 5 años. Cuando me uní en 2004, fueron:

• sigan usando Microsoft Access para sus bases de datos (incluso las críticas de negocios)
• usando Visual Basic 6 o Access / Excel VBA para el desarrollo
• utilizando una gran cantidad de terceros en lugar de utilizar recursos de desarrollo internos (los gerentes de negocios lideraron sus propios proyectos de desarrollo y el 90% del tiempo licitaban contratos sin el conocimiento de TI)
• jadeo sin control de versiones.

Cuando me fui el año pasado, la compañía era:

• usando .NET y C # exclusivamente
• había desterrado todo el desarrollo de Access
• usando SVN para control de versiones
• tenía 2 cajas robustas de SQL Server y estaba migrando bases de datos de Access existentes a SQL
• todo el desarrollo se realizó a través de los equipos internos y solo salió a licitación si los recursos eran limitados

En ese momento no había cumplido 21 años, y el siguiente más joven en el equipo de desarrollo tenía 30. No lo hice todo yo mismo. El gerente de TI se había unido a la compañía al mismo tiempo y quería llevar todo el desarrollo a través de TI.

SVN fue mi primer logro. Tuve una reunión con mi gerente de línea y destaqué un par de situaciones en las que el código se puso en funcionamiento o se modificó que causó problemas, y destaqué el hecho de que no había responsabilidad, básicamente no podía culpar a nadie, y después de esto, comenzó a escuchar

Luego preparé una presentación para el equipo y expliqué el concepto de control de versiones, y demostré un par de situaciones en las que SVN podría ayudarnos a los desarrolladores. Los más jóvenes lo tomaron como un pato al agua, los mayores no tanto pero lo intentaron y no se quejaron de aquellos que lo usaron.

Otro logro importante fue traer un sistema completo interno: encabecé un proyecto que ahorró a la compañía £ 120k al año en licencias. Pasé unos 2 meses de mi tiempo libre escribiendo un nuevo sistema, y ​​lo presenté al gerente de TI y le expliqué el ahorro de costos. Luego me permitió presentarlo al negocio y explicó cómo podríamos implementar lo que quisieran en el sistema, sin limitarse a los sistemas "listos para usar".

4 semanas después, mi sistema estaba en piloto en 10 ubicaciones, y 6 meses después se puso en funcionamiento. Un año después, cancelaron el contrato con un tercero, eliminaron todos los rastros de la red y vinieron a nosotros por un gran requisito de mejora de nuestro sistema interno.

Mi consejo para ti:

• si te importa la compañía, resiste. Si a otros no les gusta tu enfoque, deja que se lo lleven contigo: se trata de un compromiso
• Adapte las sugerencias a la persona con la que está hablando: a los gerentes les gusta saber cómo pueden a) ahorrar dinero, b) culpar con precisión a las personas cuando las cosas van mal, pero a los desarrolladores les gusta saber cómo pueden a) ahorrar tiempo, b) mantenerse para ellos, por ejemplo
• Si eres un apasionado del cambio (que parece ser que eres), muéstrale a la gente tu entusiasmo y no te desanimes cuando no estén tan entusiasmados.
• No hables de hacer cambios. Hazlos. Cuando comienzas a producir un trabajo fantástico en menos tiempo que los muchachos más experimentados, la gente comenzará a preguntar "¿por qué?"

Dijeron que me contrataron por mi rigor y porque, a pesar de mi juventud (tengo 25 años), tenía experiencia como programador de C / C ++.

Más probable porque eres más barato.

¿Alguna vez has estado en una situación similar?

Si.

que consejos me darias

Salir.

¿Hay alguna manera sutil de cambiar las cosas sin convertirse en la oveja negra aquí?

Puede haber. Introducir cambios y demostrar cómo mejoran las cosas para todos. Después de haberlo hecho varias veces, puede obtener el aprecio de aquellos que no están perdidos.

¿O debería simplemente renunciar a mi pasión y energía también?

De ninguna manera. Eres joven y tienes que aprovechar al máximo las oportunidades. No pierdas años "en algún lugar". Mire esta posición y comprenda si le brindará una experiencia valiosa para impulsar su carrera más allá. Si ves oportunidades, exploralas. Si no hay ninguno y es solo "un trabajo", salga. La práctica muestra que aquellos que perdieron su pasión (o nunca la tuvieron) no pueden volver a adquirirla. Busque un equipo de personas apasionadas y únase a ellos.

Liderar con el ejemplo . Incrementalmente pequeño cambio en el tiempo. Detén a un colega y demuéstrales algo. Si no lo entienden, no importa volver a intentarlo en otra ocasión.

Tomará tiempo. Simplemente no aleje a las personas de sus zonas de confort demasiado rápido.

Triste pero es por eso que estás aquí y ellos no.

Por ejemplo. Configure el control de versiones localmente y muéstreles cómo puede ayudar. Luego deles algunos recursos (lectura simple) que puedan respaldarlo.

Otra cosa sobre las herramientas . A veces tienes que gastar tu propio dinero comprando mejores herramientas. Sé que no es 'lo hecho', pero cuando hablo con otros oficios, encuentro que muchos ingenieros 'reales' crean / compran sus propios conjuntos de herramientas para hacer mejor su trabajo. Por mi parte, siempre he hecho esto donde puedo ver que me salvo de la atrofia de las habilidades.

Soy un hombre mayor (51) y he tenido este mismo problema en todos los trabajos que he tenido. ¡Tal vez solo viene de ser siempre el tipo más inteligente de la sala! :-) En serio, sin embargo, cuando sabes cómo hacerlo bien y no lo hacen, a menudo piensas: "Oye, les mostraré a todos esta técnica nueva y mejorada y todos quedarán impresionados y querrán participar. a usarlo ". Pero en la vida real, el 90% de las veces, le muestras a las personas una mejor manera, y se les ocurre una larga lista de excusas de por qué la forma en que lo han estado haciendo siempre es mejor. Cuando demuestras que sus razones no son válidas, surgen razones nuevas, incluso más vagas. He tenido muchas veces que '

Incluso si realmente eres un genio, debes aceptar que nadie más sabe que eres un genio hasta que lo demuestres. Me acuerdo de Kris, una amiga mía que comenzó un nuevo trabajo después de pasar 10 años con una empresa. Poco después de comenzar el nuevo trabajo, estaba en una reunión en la que discutían algún problema técnico y comenzó a ofrecer la solución sugerida. Entonces alguien más interrumpió y dijo: "Sí, gracias. Bob, ¿qué te parece?" Al principio estaba molesto: sabía la respuesta correcta, ¡pero a nadie le importaba! En cambio, fueron con la opinión de alguien que sabía mucho menos que él. Pero luego se dio cuenta, hey, en mi antiguo trabajo, había construido una reputación como alguien que sabía de lo que estaba hablando, así que cuando hablaba, la gente escuchaba. Aquí, todavía no tengo reputación, así que a nadie le importa lo que pienso.

Llevo 2 años en mi trabajo actual y solo en los últimos meses mi opinión ha comenzado a tener un peso real. Tienes que ser paciente.

Por otro lado, las personas nuevas a menudo tienen un millón de sugerencias para mejoras que realmente no son prácticas, porque todavía no saben lo suficiente sobre la organización y, por lo tanto, no saben por qué las cosas se están haciendo de la manera en que son. A veces, las personas continúan haciendo algo de la misma manera durante 20 años porque así es como siempre se ha hecho y nadie pensó en buscar una mejor manera; pero a veces las personas continúan haciendo algo de la misma manera durante 20 años porque la experiencia ha demostrado que es una buena manera de hacerlo y cada vez que intentan algo diferente es un desastre. Así que no seas demasiado rápido para concluir que todas estas personas son idiotas. Descubra por qué lo hacen a la antigua usanza antes de presentar su nueva y brillante sugerencia. He tenido muchas veces en mi vida cuando '

Encuentra aliados que también quieran mejorar la empresa.

Hay algo que decir para rescatar ahora y dejar que se pudran. Sin embargo, se verá increíble en su currículum si defiende con éxito el control de versiones y otras mejoras.

Utilice la prueba de Joel durante sus futuras entrevistas. Recuerda que también estás entrevistando a la empresa.

Mi primer consejo es que no intentes cambiar demasiado demasiado pronto. Primero consiga una reputación como un buen desarrollador confiable que pueda hacer las cosas. En este momento como novato, cualquier cosa que sugieras es sospechosa; ellos no te conocen y te respetan todavía. Obtén ese respeto como tu primer paso. Entonces es el momento de comenzar a introducir cambios.

Elige tu suelo con cuidado. Comience con el control de versiones, no con las nuevas tecnologías. Porque realmente ese es el cambio más importante. Incluso puede hacer eso solo con su código y luego asegurarse de que cuando tenga que volver a una versión anterior o coppare para descubrir qué ha cambiado, informe a las personas lo fácil que fue en una conversación informal.

Use su conocimiento más actual para ser la persona que brilla y luego la gente comenzará a preguntar cómo está haciendo esto. Cuando las PC llegaron al lugar de trabajo por primera vez, trabajé para una agencia de auditoría gubernamental. Los mayores estaban muy en contra de tener sus propias computadoras (porque eso era trabajo para las secretarias). Los juniors tomaron todas las primeras computadoras y comenzaron a hacer cosas que los seniors no podían hacer con Lotus 1-2-3 y Harvard Graphics y, de repente, las personas mayores se interesaron porque los chicos jóvenes estaban llamando la atención de la gerencia muy alta.

El cambio a una cultura organizacional no es un problema técnico, es un problema político. Lea un poco sobre la gestión de la política de oficina. Necesitará apoyo político a alto nivel.

Encontré una situación similar en mi trabajo actual. Fui contratado directamente de la escuela de posgrado para trabajar en un equipo compuesto principalmente por ingenieros que llevan aquí más de 15 años. Hacer cambios no fue fácil (todavía estoy presionando para que se hagan algunas cosas), pero es posible.

Por ejemplo, mi equipo estaba manteniendo, actualizando y usando una utilidad de prueba DOS de 16 bits. La actualización de la utilidad fue realmente difícil, porque la aplicación empujó los límites del enlazador de 16 bits hasta el punto en que si agregaba código, tenía que eliminar algo más para que encajara. Cuando se les preguntó por qué estábamos perdiendo tanto tiempo y energía en el código de 16 bits, su respuesta fue "porque necesitamos que se ejecute en DOS para poder ejecutarlo desde una unidad flash de arranque". Traté de convencerlos de que transfirieran la utilidad a Linux de 32 bits, pero la gerencia no quiso invertir el tiempo para hacerlo (ya teníamos demasiado trabajo para hacer como estaba). Entonces, seguí adelante y porté la utilidad en mi tiempo de inactividad (15 minutos aquí y allá durante el almuerzo, los fines de semana o mientras esperaba otro código para compilar). En el transcurso de un par de meses, Tenía la utilidad completamente portada, mejorada con todo tipo de cosas que la aplicación original de 16 bits no podía manejar, y arrancando desde una unidad flash Linux. La gente se dio cuenta cuando comencé a usarlo y comentaba cómo podía hacer las cosas más rápido y cómo mi utilidad generaba mejores resultados de depuración. Muy pronto, la gerencia se enteró de ello. Una vez que vieron los beneficios (y lo más importante, que el trabajo ya estaba hecho), ya no se opusieron a la idea.

La lección que aprendí de esta historia es esta: si cree que puede mejorar algo, hable con su gerente al respecto. Si no quieren gastar los recursos en él, hágalo usted mismo y demuéstrales que tu idea es válida y útil. Es mucho más fácil decir no a una idea que alguien propone que a algo que ves frente a ti y que tiene un valor obvio.

Una vez que su equipo / gerente implemente su idea y comience a ver los beneficios, será mucho más probable que escuche sus ideas en el futuro. Utilicé la "credibilidad de la calle" que obtuve de la reescritura de mi herramienta de prueba para convencer a mi equipo de que necesitábamos deshacernos de nuestro sistema de control de versiones arcaico actual (que permanecerá en el anonimato para evitar la vergüenza) y migrar a Subversion. Me ofrecí como voluntario para dirigir el esfuerzo de configuración / migración para ayudar a garantizar que la administración lo aprobara.

Es una especie de "paso a paso". Probablemente hay un montón de cosas que te gustaría cambiar, pero para empezar, elige algo pequeño (ish). Demuestre la calidad de sus ideas de una manera que su equipo y gerente no puedan decir 'no'. Al igual que su cuenta stackoverflow, cuantas más buenas ideas tenga, mejor será su reputación y más fácil será aceptar sus ideas.

Definitivamente, comience a usar las herramientas que desearía tener localmente (donde pueda, algunas empresas también parecen controlar lo que puede instalar en su caja con un puño extrañamente apretado). Configure su sistema de control de versiones favorito y comience a usarlo. En cualquier código que toque, realice pequeños cambios que hagan que el código sea más limpio, especialmente donde puede escribir cualquier código nuevo. Si te contrataron por tu rigor y experiencia, eso significa que ya te respetan.

Hace poco leí Contratar a Ren y Stimpy , y descubrí que el ejemplo de Stimpy era un gran desafío. Si sigues su ejemplo, terminarás pidiendo (amablemente) todo tipo de perspectivas a tus compañeros de trabajo, lo que te permitirá tener el conocimiento de que un desarrollador sin pasión no lo hará. Pasarás el tiempo libre que tengas imaginando formas de hacer mejoras. Si la empresa considera que su trabajo es valioso, usted se volverá invaluable. Si no lo hacen, probablemente querrás buscar trabajo.

Mucha gente ha respondido con sugerencias para centrarse en una cosa pequeña a la vez, y varias han sugerido el control de versiones. Iré un paso más allá: cree repositorios en su máquina de escritorio y trabaje desde esos repositorios. Actualícelos regularmente desde cualquier repositorio maestro que utilice la empresa. Cuando (no si) hay una crisis porque alguien dañó al maestro, dígales que puede cortar una nueva copia de su repositorio personal.

Sin embargo, bajo ninguna circunstancia coloque el código de la empresa en una máquina que sea de su propiedad o que se lleve a casa . Porque entonces puede encontrar que, en lugar de ser un héroe, está en el lado equivocado del escritorio de un abogado (en el mejor de los casos) o de la policía (en el peor).

Viniendo de otro desarrollador junior ... ¿tienes grandes habilidades con la gente? ¿Tiene un excelente sentido de autocontrol y una comprensión de cuándo es y no es apropiado proponer una idea, y cómo venderla mejor? Incluso si lo hace, podría terminar siendo "ese tipo" por decirle a otras personas cómo hacer su trabajo sin demostrar su valía.

Así es como TODAVÍA construyo mi credibilidad como desarrollador junior: identifico un kink / kludge / time waster. Luego lo arreglo automatizándolo (archivos por lotes, scripts de PowerShell, programa simple, nuevo software gratuito, lo que sea el fin de semana) sin molestar a nadie más. Me aseguro de que sea parte de mi autoeducación técnica continua para que pueda pensar en ello como "dedicar horas adicionales para enseñarme algo nuevo Y ayudar a la empresa".

Si mi solución es particularmente ingeniosa, la comparto y digo "Hola chicos, hice esta herramienta genial, automatiza XY y Z y hace esta otra cosa rápidamente". Mantén tu nombre en él. Repetir. El problema de credibilidad se resuelve en unos pocos meses si tiene un alto porcentaje de artistas para su nivel, y las personas por encima de usted estarán más abiertas a sus sugerencias si está listo para explicar por qué su idea es buena y cómo puede resolver sus problemas.

Recientemente pude proponer nuevas ideas a la alta gerencia que fueron aceptadas, principalmente porque me tomé el tiempo para explicar mi razonamiento, escuchar sus comentarios y tener la credibilidad de mi trabajo anterior.

APÉNDICE: Si su gerente está cuestionando su comportamiento ... no haga estas cosas a menos que sienta que su desempeño se mantiene al menos en el "25% superior", es decir, asegúrese de que su jefe esté contento con usted antes de que comience a pensar en todo tipo de soluciones inteligentes que lo empujan más alto en ese porcentaje superior o él pensará que está perdiendo el tiempo. Si está lanzando nuevas utilidades y soluciones a la vez que obtiene comentarios positivos sobre el rendimiento y aún así insiste en microgestión, puede tener un problema que está fuera del alcance de este tema.

Mezclarse con.

Como dijiste, no quieres ser la oveja negra. Sin embargo, dado que usted (como yo) desea agregar algún cambio útil:

Agregue valor en el fondo.

Configure cronjobs para registrar el código de las personas en svn / hg / git. Cree sus propias herramientas, en su propio tiempo, que puedan mejorar los esfuerzos de desarrollo. En particular, desea realizar mejoras en la empresa que puede mostrar a sus personas mayores en su propio cubículo. Y aquí está el por qué:

factor sorpresa

Si puedes decir "Hola Alice, ¿sabes cómo Bob acaba de romper la compilación? Puedo revertir su edición y la compilación funciona de nuevo". Y cuando su superior diga cosas santas, tal vez despertará suficiente pasión en ellos como para impulsarlos, o al menos alentarlos, sus nuevas prácticas.

Aquí está mi consejo.

Estaba en una situación similar, primero debería decir, mi compañía es bastante pequeña con 6 desarrolladores, soy el tipo de programador que le gusta usar la nueva tecnología, las nuevas herramientas y cualquier cosa que haga mi trabajo más fácil y produzca software de mejor calidad. .

Cuando comencé, estábamos usando Visual Studio 2005, cuando VS2008 estuvo fuera por bastante tiempo, pero conseguir que mi jefe pusiera el dinero en la actualización a todos nuestros desarrolladores no fue fácil, tuve que plantear lentamente la idea, ya que más un "sería bueno si pudiéramos hacer esto", pero antes de presentárselo a mi jefe, me aseguraría de que los otros desarrolladores fueran buenos con la idea, porque ellos serían los que lo usarían y tendrían un grupo de personas el favor se parecería menos a una decisión de una persona.

Creo que, en lugar de simplemente presentarle la idea a su jefe, tal vez le plantee lentamente cualquier posible cambio, porque creo que si sugiere ideas que cambiarán la compañía de una mejor manera, también muestra que le importa su trabajo y muestra que planea en hacer un hogar allí.

Esto también dependería del entorno de trabajo en el que se encuentre y de la personalidad de su jefe, si son relajados y lo tratan como a su familia y le aconsejan, sugiéralo, pero si lo tratan como un número, sería muy cuidadoso cómo te acercas a eso.

Podría ser una oportunidad única en la vida: cambiar la forma en que una empresa trabaja a los 25. Si se resisten y muestran animosidad todo el tiempo, ese no es el lugar para usted.

Recuerde, su entrevista fue un proceso bidireccional. Podrías haber tenido una idea de lo arcaicos y resistentes al cambio que eran.

Ps, yo también tengo 25 años y sé cómo te sientes. Probablemente esté mucho más ansioso por aprender y probar cosas nuevas que sus colegas. De todos modos, debo volver a este trabajo .NET4 que estoy presentando;)

Lee Cómo hacer las cosas cuando solo eres un gruñido por Joel Spolsky.

... a veces no tienes el poder de crear cambios en tu organización por mandato ejecutivo. Obviamente, si solo eres un programador gruñón en la parte inferior del tótem, no puedes ordenar exactamente a las personas que comiencen a crear horarios o bases de datos de errores. Y de hecho, incluso si usted es un gerente, probablemente haya descubierto que administrar desarrolladores es muy parecido a pastorear gatos, pero no tan divertido. Simplemente decir "hazlo así" no lo hace así.

Puede ser frustrante cuando trabajas en una organización que tiene un puntaje bajo en The Joel Test . No importa qué tan bueno sea su código, sus compañeros de trabajo escriben un código tan malo que le da vergüenza estar asociado con el proyecto. O la administración está tomando malas decisiones sobre qué código escribir, por lo que se ve obligado a desperdiciar su talento depurando la versión AS / 400 de un juego de planificación de la jubilación para niños.

... lidiar con la vida en un mal equipo puede ser exasperante. Pero hay estrategias para mejorar su equipo desde abajo, y me gustaría compartir algunas de ellas ...

Trabajar con la gerencia; no "te vuelvas pícaro". Trabaje dentro del proceso y ponga las cosas en términos que la gente entienda, como "implementar svn nos llevará espacio en un servidor, dos días para configurarlo, y tendremos que respaldarlo, pero obtendremos x, y, z , lo que nos puede ahorrar mucho dinero ".

Dejar. Hay muchos trabajos por ahí. No es tu trabajo arreglar una compañía aleatoria que te contrató. Les gusta como son, de lo contrario contratarían un nuevo CTO o algo así.