¿Debo despedir al programador si no es lo suficientemente eficiente?

Hay programadores que son mucho más efectivos que otros programadores, pero generalmente no por las razones que pueda imaginar …

La cuestión de escribir código es que se trata más de saber lo que se debe hacer que de hacer lo correcto. Es decir, escribir el código es la parte fácil y sucede bastante rápido.

La eficiencia del programador no se trata de la velocidad de escritura o incluso el esfuerzo. Se trata de saber qué hacer y cuándo hacerlo.

Ahora, admito, la mayoría de los programadores a menudo no saben qué hacer y cuándo hacerlo, así que se golpean la cabeza contra la pared y no logran mucho. Eso no significa que cada programador ineficiente sea un mal programador.

De hecho, hay un problema mucho mayor que los programadores ineficientes que arruinan los proyectos más que nada …

La dinámica del equipo, a menudo determinada por el gerente, suele ser un indicador más grande del desempeño individual que la capacidad del individuo. Esto es lo que quiero decir:

Cuando estás en un equipo, tu habilidad tiende a aumentar o disminuir para que coincida con el equipo. Entonces, si estás en un equipo de alto rendimiento, mejorarás para cumplir con la habilidad requerida del equipo. Si estás en un equipo de bajo rendimiento, tus habilidades también disminuirán para cumplir con las de ellos.

A menudo, un individuo con bajo rendimiento es un síntoma de un equipo mediocre a horrible. Si miras a tu alrededor, verás a otros que también funcionan mal.

Para remediar esto, no despides al programador, trabajas en la cultura del equipo para tratar la excelencia. Si construye una cultura de rendimiento previo y excelencia, realmente no tiene que preocuparse por el rendimiento individual de la misma manera.

Si su equipo está haciendo un gran trabajo, un individuo con bajo rendimiento sobresaldrá como un pulgar dolorido y el equipo los pondrá a la par o los obligarán a retirarse. De cualquier manera, es menos un problema.

Entonces, arregle la dinámica del equipo primero, luego vea qué sucede después.

-Brian

PD: Descomprimo más ideas en Creative Genius

Definitivamente no deberías considerar despedirlo en esta etapa.

En mi experiencia, algunos codificadores están altamente orientados a los detalles e increíblemente eficientes en la creación de líneas de código. Otros codificadores están menos orientados a los detalles, pero son más capaces de crear y mejorar el diseño del sistema.

Si el resto de su equipo nunca pone un punto y coma fuera de lugar o comete un mal parche, entonces no solo tiene algunos codificadores muy metódicos, sino que a la larga puede descubrir que se beneficia de tener a alguien un poco menos orientado a los detalles . Parece que ya ha proporcionado algún beneficio de alto nivel.

Como se ha dicho en otras respuestas, las ineficiencias más evidentes en el desarrollo de software en el transcurso de un proyecto no son una compilación rota o un error sintáctico aquí y allá. Hay muchos métodos económicos para prevenir este tipo de problemas, e incluso cuando ocurren, el costo no es tan alto como se podría percibir.

Los errores más costosos que he visto provienen de un único desarrollador, a menudo del tipo orientado a los detalles, que toma una decisión de diseño miope que nunca se revisa, y luego otros construyen sobre él hasta que se requiere un refactor costoso para abordar el diseño original. Error. Necesita un equipo con enfoques variados para que cuestionen y revisen el diseño juntos. Esto también requiere una gran dinámica de equipo, pero ese es otro tema.

En cuanto a abordar el problema original de lo que clasificaría como descuido leve, sugeriría la programación de pares, o si desconfía de eso, usted o su equipo deben responsabilizar amablemente y pacientemente a este empleado.

Un famoso ejemplo de cómo un equipo hizo esto fue que cualquiera que “rompió la construcción” en su sistema de CI pondría un patito de goma en su escritorio hasta que la siguiente persona lo rompiera. Sea creativo, manténgalo alegre, pero haga que rindan cuentas y mejorarán.

No he visto una respuesta como la que estoy preparando para escribir, aunque he visto algunas respuestas increíbles, y a las que realmente debes prestar atención y seguir.

He sido gerente, jefe de equipo, arquitecto, gerente de proyectos, prácticamente todas las cosas que uno puede hacer y escribir “Programador” en el cuadro marcado “Ocupación”. Pero lo que también he hecho que es muy relevante para esta conversación es “entrar” en nuevos gerentes. Y necesitas un buen “irrumpir”.

Ser un líder es un trabajo duro, y algunas personas no están preparadas para ello. Otros obtienen el título y no saben qué hacer con él. Tu trabajo número 1 es hacer que tu gente tenga éxito. Ese también es tu trabajo número 2, número 3 y probablemente incluso tu trabajo número 4. Tan pronto como se te ocurra que tu trabajo número 1 es asegurarse de que tu gente tenga éxito, puedes comenzar a trabajar en tu trabajo real número 2, lo que hace que tu jefe tenga éxito.

Existe un concepto llamado “Liderazgo de Servicio”. Significa que cuando usted está en un rol de liderazgo, su trabajo es servir a las personas que le reportan. Tienes un gran desarrollador trabajando para ti y él está teniendo problemas. Es tu trabajo número 1 arreglarlos. Otros han sugerido cambiar cosas sobre su proceso, y ese es un gran consejo. Definitivamente deberías seguirlo. Cuando haga eso, debe llamarlo a su oficina o a una sala de conferencias privada si tiene un plano de planta abierto, y debe preguntarle qué puede hacer para que tenga más éxito. Si tiene otras personas en su equipo, hágalo con todas ellas a medida que avanza en sus reuniones 1 a 1.

Si sigue este consejo, su equipo eventualmente comenzará a hablar sobre cómo mejorar su proceso. La “eficiencia” general (el término correcto es productividad) mejorará, su jefe lo amará y no lo despedirán por ser un mal gerente. Sigue así, las personas verán que “obtienes” tu rol como gerente, y antes de que te des cuenta, tendrás gerentes que te informarán. Hazlo realmente bien y un viaje a las suites C o al equipo ejecutivo podría estar en las cartas.

Si no sigue este consejo, publique el nombre del chico; a muchos de nosotros nos encantaría contratarlo. ¿Tú? No tanto.

Guau. Simplemente guau.

Parafraseando: hasta ahora es genial, pero hay algunos detalles que PODRÍAN ser un problema más adelante. ¿Entonces despedirlo?

Déjame darte algunos consejos útiles primero (antes de que pueda despotricar). Esto es lo que debes hacer:

• Encuentre un momento conveniente para reunirse con él en su oficina.
• Diga básicamente esto (¡o esto exactamente!): Hola, está haciendo un gran trabajo, pero hay algunos detalles que agradecería si pudiera practicar.
• Revisa tu lista. Tal vez escríbalo e imprímalo para que pueda consultarlo más tarde (para evitar “Olvidé”)
• Pregúntele si comprende por qué estos detalles son importantes para usted / por qué le importan estos detalles
• Pregúntele si ve algún problema al seguir estos detalles
• Pregúntele si hay algún problema con el que se encuentre y que le impida trabajar eficientemente en general.
• Hable con él (como un humano normal) acerca de cualquier problema que mencione o donde sea que vaya la conversación. ¡No lo eches por la puerta justo después de que le des tu lista de demandas!
• Al final, agradézcale por su cooperación con esto y por su arduo trabajo en general.

Si lo trata y habla con él como un humano y le explica por qué estas cosas son importantes para usted, entonces no debe molestarse durante esta conversación. Si él dice que entiende y cumplirá y luego REPETIDAMENTE no, entonces tiene razones para una acción disciplinaria, porque no importa cuán pequeños sean los detalles que acordó cumplir y luego no cumplió.

Tiempo despotricar

Los empleados no pueden leer tu mente:

• Recuerdo las reseñas de los empleados (hace mucho tiempo) en las que estaría furioso después. En general, no fue una mala crítica, por encima del promedio, por los puntos que decían que necesitaba mejorar o que no lo estaba haciendo, me disgustó. ¿Por qué? ¡Nunca fueron mencionados antes! No podía dejar de pensar “¡has sido mi pesebre todo el año y no lo has mencionado una vez! ¡Si me lo hubieras dicho antes, habría cambiado!” Tal vez desde su perspectiva “Debería haberlo sabido”, pero aún así, no puede enviarme uno para solucionar un problema que no saben que existe.
• Como gerente, también aprendí esto: ¡no pueden leer tu mente! Solía ​​enojarme mucho cuando encontraba ciertos errores repetidos. Me sentaba en mi oficina pensando “¡por qué esta persona está haciendo esto!” Esperé para calmarme, no iba a disciplinarme, solo decidí hablarles, no gritarles. Les dije por qué lo que hicieron no era bueno. ¿Su respuesta? “¡Oh! Lo siento, nunca nadie me dijo eso. No lo volveré a hacer así. Simplemente no lo sabía”. Me quedé sin palabras: pensé que eran flojos o incompetentes, pero me di cuenta de que si nunca se les dijo en el entrenamiento y yo, como su gerente, nunca les dije, ¿cómo podría mantenerlo en contra de ellos?

¿Qué hace a los peores gerentes?

Miedo a la confrontación

Como gerente, usted tiene que administrar las cosas. Eso significa que si no van de la manera prevista, debe dirigirse a ellos para cambiar de rumbo. Abordarlos generalmente significa confrontar a su personal, ya sea individualmente o en grupo. Desafortunadamente, he visto muchos gerentes que tienen una visión equivocada de esta ‘confrontación’. Temen la confrontación y entran en ella pensando que será un debate; “Yo contra ellos. ¿Cómo gano esto? Los atacaré temprano y con fuerza. Les mostraré quién es el jefe”. Sin embargo, ya ganaste, ya eres el jefe. No es necesario mostrarles nada excepto lo que esperas. Tienes el poder de despedirlos, ¿por qué no te escucharían? si no lo hacen, probablemente sea porque no te respetan. Si no te respetan, podría ser por muchas razones, pero en este escenario probablemente sea porque no les estás hablando con respeto. Si está abordando un problema pequeño, dígales que es un problema pequeño. Dígales que quiere que se modifique el pequeño problema pero que aprecia el resto de su trabajo. Si tiene dificultades para apreciar su trabajo, piense en todas las cosas horribles que hace su peor empleado, entonces cuando se reúna con este empleado, se alegrará de que no sea ese otro. Y, por supuesto, explica por qué. La gente quiere saber por qué. Si no lo hacen, es cuando piensan que el jefe es un imbécil y que simplemente está haciendo un viaje de poder o lo tiene para usted. Si haces un buen trabajo al explicar por qué es importante, generalmente DESEARÁN seguirlo. Es difícil seguir reglas que no entiendes (por ejemplo, piratear música porque no entiendes cómo perjudica a alguien. Fuera del tema, pero creo que es un ejemplo apropiado). Incluso he llegado a decir “esta es una política corporativa. No hay nada que usted o yo podamos hacer para cambiarla. Sería un dolor de cabeza tratar de hacer que la empresa cambie esto (porque probablemente nos ignorarán) ) que simplemente adherirme a él. Pero solo porque piense que es estúpido no significa que no te meterás en problemas si rompes esta política, porque tendré problemas con mi jefe si no hago cumplir esta política … y no le digas a mi jefe que creo que es estúpido “. Se rieron, firmaron su documento disciplinario, entendieron de dónde venía, no sostuvieron nada en mi contra y nunca más rompieron la política. Debe considerar el propósito de la confrontación: generalmente es para estimular la mejora. Es difícil hacerlo si no eres respetuoso.

Bien, estoy literalmente cansado de despotricar ahora. Solo que todos tengan en cuenta que nadie es perfecto, pero si señalas esas imperfecciones con respeto, intentarán trabajar en ello. Además, los gerentes horribles = lugares de trabajo horribles.

Los buenos programadores son escasos y parece que este tipo es razonablemente bueno. Nadie es perfecto, ni siquiera tú. Si eres demasiado duro con las personas de tu tripulación y esperas demasiada perfección, recuerda que pueden y saldrán del barco con una molestia mínima para ellos; pero para usted, significa invertir en anuncios, reclutadores, orientación y capacitación, para otra persona nueva que puede resultar peor.

Siempre busco:

• Actitud positiva
• Ansioso por aprender

Si algún desarrollador tiene estas cualidades, casi siempre será mejor entrenarlo que tratar de reemplazarlo.

“Entrena para retener”.

No. El problema es su proceso de software subóptimo que no detecta sus problemas menores antes de entregar el código. Necesita realizar pruebas de aceptación automatizadas antes y durante los registros para detectar estas cosas.

Dirigiendo sus comentarios directamente:

Lo acabo de traer a bordo y el tipo es genial hasta ahora, puede resolver muchos problemas de programación y errores en minutos e incluso mejoró algunas de nuestras bibliotecas ahorrando días de trabajo y le encanta programar y aprender rápido.

Eso es lo que hacen los buenos ingenieros.

Pero me di cuenta de que a veces olvida algunos detalles pequeños, como olvidar agregar un archivo cuando entrega el proyecto al control de calidad, o incluso algunas cosas pequeñas como un punto y coma. Siento que esto puede convertirse en un problema más adelante.

Eso es lo que hace la gente, por lo que utiliza un buen proceso para mitigar su impacto.

¿Debo despedir a una niñera si no es lo suficientemente eficiente?

¿O debería quedarme con ella si trata bien a mis hijos?

¿Qué es lo que realmente espera de un programador?

Porque mi experiencia es que la mayoría de los programadores trabajan en entornos con alta incertidumbre:

a) No hay requisitos por escrito.

b) No hay objetivos claros del proyecto. ¿Qué estamos buscando realmente aquí? ¿Cómo declaramos el resultado final para asegurarnos de lograr el éxito?

c) ¿Qué dejar y qué dejar afuera? La mayoría de los gerentes de proyecto simplemente quieren hacer todo, y no está claro qué es importante y qué no.

Dado todo eso, los gerentes de proyecto generalmente entran en muchos detalles, como si fueran programadores, sin preocuparse por sus propios trabajos, que es hacer que el proyecto sea exitoso.

Si la definición de éxito es gastar lo menos posible, entonces el gerente del proyecto tratará de reducir la cantidad de trabajo, hará lo menos posible, y luego el proyecto estará condenado porque las cosas que las personas están haciendo son un desperdicio.

Los requisitos se malinterpretan y lleva una eternidad escribir todos los documentos, que de todos modos son incorrectos, porque de todos modos los requisitos eran incorrectos.

Por lo tanto, buscar eficiencia en un programador, en mi opinión, es lo incorrecto que buscar.

Cada vez que veo a un gerente de proyecto buscando eficiencia, sé que ese proyecto está condenado, porque lo que escucho decir a los desarrolladores es “omitir el proceso”, hacer las cosas a su manera, omitir, omitir, omitir … si solo pudieran omitir la escritura el código … pero generalmente omiten el uso del control del código fuente, los rastreadores de problemas, las pruebas unitarias, la integración continua, las máquinas de ensayo, etc.

El resultado final es una gran pila de basura y no les importa porque van rápidamente a trabajar en otra empresa y dejan que el problema lo resuelva otra persona.

¿Entonces quieres despedir a alguien porque es descuidado? ¿No tienes un proceso para asegurarte de que nadie cometa errores? ¿Como el que acabo de mencionar?

Deberías dispararte a ti mismo.

Tendrías que describir lo que quieres decir cuando dices “no lo suficientemente eficiente”. Con eso quiero decir, describir lo que hace que te hizo concluir que él es “no lo suficientemente eficiente”. La eficiencia no es algo subjetivo, por lo que no puedes decir “esto es lo que la eficiencia significa para mí “. No hay grados de eficiencia: uno es eficiente o ineficiente.

Entonces, al decir “no lo suficientemente eficiente”, ¿estás diciendo que él es ineficiente o que es eficiente pero a ti personalmente no te gusta la forma en que hace las cosas? Si este es el caso, ¿qué calificaciones tiene que le permitieron juzgarlo “no lo suficientemente eficiente” y qué programas ha implementado para ayudar a su personal a saber qué es “lo suficientemente eficiente”?

Perder un punto y coma aquí y allá debe estar marcado por el compilador o, en el caso de javascript, por cualquier herramienta de compilación decente. Omitir involuntariamente algunos archivos durante las pruebas no es un gran problema, ya que se pueden implementar fácilmente en cualquier momento. Aprenda hoy que la parte de la ingeniería de software de la programación puede ser larga y mentalmente agotadora. Entonces, si, a pesar de esa realidad, constantemente produce soluciones bien diseñadas, ¿cuánto significan para usted las deficiencias administrativas que mencionó? ¿Se elevan al nivel de “no lo suficientemente eficiente”?

Antes de despedir al programador porque no está trabajando lo suficientemente eficiente, debemos hacernos una pregunta. “¿Realmente estás haciendo el trabajo para ayudarlos a ser efectivos en el trabajo?”

Sugeriría encontrar cómo fue la causa raíz de hacer que esto sucediera. ¿Podrían ser problemas familiares? ¿Asuntos personales? ¿Entrenamiento insuficiente? ¿Contratación incorrecta? (¿Puede ser que el programador no tenga mucha experiencia en una pila tecnológica en particular?) ¿Podría ser que el programador tenga otra fortaleza principal en lugar de codificación? ¿O tienen problemas para llevarse bien con sus compañeros de equipo?

Y luego trataré de trabajar con él / ella y ver si podemos sacar una altenativa. Personalmente, creo que despedir a una persona en el trabajo es la última opción, porque despedir a una persona realmente lastima a ambos lados; el negocio y el empleado Pasar tiempo para contratar a una nueva persona realmente cuesta más tiempo y dinero, ¡así que normalmente queremos evitar eso!

Seguramente no puedes hablar en serio. Y si es así, bueno. No sé si deberías tener objetivamente motivos para despedir a esa persona, pero quien sea responsable de ti debería leer esto y tener un amplio motivo de preocupación para mantenerte en tu posición.

• Enserio amigo. Tu trabajo es conocer a tu equipo y tus necesidades. Debe conocer las necesidades de la compañía, el trabajo que debe entregarse, cuándo, con qué proceso, en qué circunstancias, en qué grado se ha entregado y cuáles son las proyecciones para el futuro. Debe tener toda la información que necesita para hacer ese tipo de llamadas, y si no lo hace, entonces bien. Alguien no está haciendo el trabajo que le pagan por hacer. Y no es el programador.
• ¿Transmite los problemas de su proyecto y su equipo en un sangriento FORO DE INTERNET, especialmente para discutir temas negativos? Amigo, ni siquiera. Tenga un respeto básico por las personas a su cargo. Lo que sucede en la oficina, ESTANCIAS en la oficina. Eso ni siquiera es gestión, es un comportamiento profesional básico en cualquier campo.
• Definir “lo suficientemente eficiente”. La eficiencia en el trabajo, especialmente en tareas no mecánicas, es una red muy compleja de facetas entremezcladas. Da cuenta de la velocidad, la entrega, las necesidades específicas de los proyectos y el puesto, la disponibilidad de otros recursos, el legado, las especificaciones exactas del trabajo, los criterios de medición utilizados por la empresa, su adecuación y eficacia … sin una visión muy profunda e informada el proyecto, las posibilidades de que sepamos el impacto de esos errores que usted menciona o de la otra contribución que él hace, no estamos en condiciones de emitir un juicio válido, y debe asegurarse de que el juicio sea MUY válido cuando el trabajo de alguien está en la balanza.
• No despides personas por cometer errores. Todos cometen errores. Su trabajo como jefe es asegurarse de que las personas estén al tanto de dichos errores, se les den las herramientas (capacitación, supervisión, recursos) para corregirlos y luego, si él no mejora o no muestra ninguna intención, entonces podría considerar si sus habilidades y aptitudes se ajustan a su responsabilidad. No notas errores e inmediatamente piensas en disparar.

  En serio, hombre. Preocúpese menos por las deficiencias de otras personas y comience a trabajar en las suyas. Lea sobre la gestión de proyectos. Lea sobre liderazgo, metodologías de producción, psicología y desarrollo personal. He liderado un equipo muy cohesivo y exitoso y mis peras me han reconocido como un buen líder en mi campo, y ahora, después de ver esto, no confiaré en ti para que manejes algo más complejo que el armario de escobas de la compañía.

Antes de disparar, asegúrese de que su contribución no sea más difícil para el desarrollador. El desarrollador puede tener falta de experiencia, lo que significa que no espera un entorno de desarrollo maduro. Su función es habilitar un entorno de desarrollo maduro.

Otros han dicho, poner en proceso. Estoy de acuerdo, pero lo que está buscando apuntala con qué proceso ayuda. Está buscando consistencia, repetibilidad y previsibilidad. Ver “Nunca, nunca digas proceso” para más de mis pensamientos sobre eso. Parece que la falta de proceso no es compatible con este ingeniero.

En muchas empresas modernas, hay un equipo llamado desarrollador o productividad de ingeniería. Su función es brindar apoyo a los equipos e ingenieros para garantizar que sean productivos. Si su equipo es más pequeño, es posible que deba asumirlo usted mismo.

Comenzaría con algunos elementos mirando el proceso de facto o la norma de desarrollo que tiene. Con un fuerte ojo en lo que se puede automatizar para ayudar a los ingenieros a ser más productivos.

Comprobaciones previas a la confirmación : tenga una secuencia de comandos pequeña que realice una verificación previa dentro del área de desarrollo: compruebe si hay archivos sin etapas, ejecute la compilación, ejecute pruebas unitarias y realice algunas pruebas funcionales. Espere que los ingenieros ejecuten un solo script antes de la revisión del código o mientras se ejecuta la revisión del código. Es posible que pueda hacer que este script active el CI y la revisión de código.

Integración continua de sucursales : obtenga un sistema de CI (en la nube o en las instalaciones) que su desarrollador pueda impulsar a una sucursal que construirá y ejecutará más pruebas fuera de su máquina.

Tener revisiones de código : comparta la responsabilidad de identificar las brechas con el equipo. Si eres un equipo pequeño, súbete las mangas. Las revisiones de código ayudan al crecimiento profesional de varias maneras. Primero, empaquetan el trabajo para la presentación, de la misma manera que limpia su casa para cuando sus padres lo visiten. En segundo lugar, brinda una oportunidad de tutoría entre los pares. En tercer lugar, comparte la responsabilidad de la calidad mediante la firma. Si es posible combinar CI Pipelines y el proceso de revisión de código.

Tener un estado de sucursal visible . Tener una pantalla conectada a una PC que muestre el estado del entorno. Cuando la construcción se rompe, se vuelve roja con la primera confirmación que la rompió. No le gusta tener su cara visible asociada con algo negativo.

Como líder sobre un equipo. Las fallas del equipo son tus fallas. Si no habilita el equipo, el próximo desarrollador puede ser el mismo ya que su cultura de ingeniería no está habilitando la calidad, excepto a través de la fuerza intrínseca. Contrata personas inteligentes, pero asegúrate de que sean lo suficientemente flojos como para querer arreglar la norma de desarrollo para minimizar su propio reproceso y errores.

⇩Vota si te gusta⇩ | use-cases.org – Blog de Matthew Tippett

Hola,

Es una pregunta válida y, en muchos casos, la mayoría de las compañías importantes ahora tienen una actitud en la que si el empleado no se ajusta a su agenda, incluso si es leve, entonces considerarán despedirlo.

Sin embargo, me gustaría que el equipo de liderazgo adoptara una actitud más positiva, donde es más probable que tengan un enfoque de orientación y asesoramiento, en lugar de considerar al empleado como prescindible. Eche un vistazo a algunas de las formas en que podría mejorar el programador, ya que debe haber razones por las que son menos eficientes. La falta de motivación o incluso el deseo de trabajar podría ser otra razón, pero debería ser el equipo de gestión quien debería buscar resolver eso y no huir de la situación.

Espero que esto ayude. Alternativamente, eche un vistazo a estos artículos, tienen algunos puntos realmente buenos de mi propia experiencia de más de 15 años en la gerencia y el liderazgo de alto nivel.

Gestionar equipos exitosos

Un jefe nunca puede ser un líder

Entonces, usted tiene un empleado apasionado por su trabajo, resuelve problemas rápidamente y en poco tiempo formó parte de su equipo, mejoró sus bibliotecas y le facilitó la vida.

Y quieres despedirlo, porque a veces olvida algunos detalles, y esto podría ser un problema para ti más adelante.

Me pregunto si te diste cuenta de cómo suena esto para la mayoría de las personas después de escribir tu pregunta.

Los buenos programadores son escasos, y es su responsabilidad como gerente ayudarlo a mejorar y superar sus deficiencias.

Mencione el problema casualmente y pregunte si puede ayudar de alguna manera para evitar estos pequeños problemas en el futuro. La comunicación es clave.

No hay mediciones objetivas que determinen si un programador es eficiente. Si lo comparas con otros programadores y están de acuerdo en que es ineficiente, entonces probablemente lo sea.

Si no tiene a alguien con quien compararlo, esto es lo que debe hacer:

1. Establezca expectativas con el programador. Dile lo que te gustaría que lograra y para cuándo.
2. Pregúntele si cree que es posible y, si no es así, pregunte si puede necesitar hacer algunas compensaciones.
3. Si es necesario realizar intercambios, hable con él para comprender cuáles son y qué significará a largo plazo. Por lo general, una compensación será un mayor costo a largo plazo (mantenimiento o retrabajo) para un tiempo de comercialización más rápido. Esto a veces es necesario. SIN EMBARGO, sepa que necesitará aumentar su presupuesto en el futuro debido a esta decisión y debe regresar y hacer las cosas lo antes posible. Un desarrollador que puede tener esta conversación de forma inteligente suele ser al menos decente.
4. Si él piensa que no es posible, pase lo que pase, pregúntale qué sería. Si lo que se le ocurre no es aceptable, considere contratar a un contratista muy recomendado para que lo ayude a terminar y compararlo. Vigilarlos. Tenga reuniones diarias con ellos para ver qué están haciendo cada uno de ellos. Si juntos no pueden hacer lo que pides, debes restablecer tus expectativas.
5. Si lo logran, trate de entender lo que cada uno de ellos hizo con un marco de referencia de dónde están en sus carreras y cuánto ganan. Luego decida si necesita dejarlo ir y encontrar un desarrollador mejor o más experimentado. Sin embargo, sepa que esto puede terminar costando un poco más si obtiene su desarrollador actual a bajo precio.

“Lo acabo de traer a bordo y el tipo es genial hasta ahora, puede resolver muchos problemas de programación y errores en minutos e incluso mejoró algunas de nuestras bibliotecas ahorrando días de trabajo y le encanta programar y aprender rápido. Pero me di cuenta de que a veces olvida algunos detalles pequeños, como olvidar agregar un archivo cuando entrega el proyecto al control de calidad, o incluso algunas cosas pequeñas como un punto y coma. Creo que esto puede convertirse en un problema más adelante “.

Soy ingeniero mecanico. El primer trabajo que logré para salir de la universidad, comencé cuando nuestro departamento no tenía plomo, e hice un buen trabajo. Rápidamente actualicé cientos de dibujos y ahorré a la compañía cientos de miles de trabajos perdidos debido a mi velocidad extremadamente alta como dibujante y mi conocimiento de ingeniería evitando que cometa los errores que otros redactores tienden a cometer.

También tenía contrato y pagaba en el 1% inferior de los redactores, aproximadamente la mitad del salario medio de entrada para ellos en mi ciudad.

El jefe de departamento que contrató la compañía era un poco TOC, y no le gustaba tener que revisar o corregir dibujos, y tenía en mente un estilo muy específico. Se quejó de pequeños problemas que no se convirtieron en problemas y que no habían sido problemas como usted está aquí, y como resultado me dijo que no me contrataría por completo ni me daría un pago que realmente cubriera mi renta y me permitiera comer alimentos.

Su falta de respeto y trato rudo, la falta de liderazgo y la incapacidad para manejar los problemas de manera madura y con un sentido de comprensión y visión de futuro, la incapacidad de trabajar conmigo para ver la visión que buscaba o incluso intentar hacerlo. El estrés lastimó mi salud sustancialmente, y estaba obteniendo muy poco trabajo.

Entonces tengo otro. El trabajo por el que dejé ese trabajo remunerado más del doble también, me trataron con dignidad y respeto, y luego diseñé muchísimos productos excelentes y resolví muchos problemas en esta empresa. Y esa primera compañía podría haber visto sus productos arreglados, podrían haber visto nuevos productos innovadores y mejoras de mí, si no me hubieran tratado tan mal. Casi me queman, pero hoy estoy viviendo una vida decente y respetable.

Despedir a ese empleado porque eres un mal líder, no sabes cómo manejarlo y piensas que el TOC es sinónimo de habilidad en lugar de no estar relacionado, sería un movimiento lo suficientemente estúpido como para que si yo fuera tu gerente, te despediría .

Recibió algunos consejos valiosos sobre por qué parece que debería retener al programador en cuestión. En lugar de aclarar los puntos que ya se han hecho, permítanme agregar algunos que no.

El tipo de detalles de los que estás hablando a menudo se pierden cuando las mentes fuertes se centran atentamente en abordar los problemas más grandes. ¿De qué servirían todos los punto y coma correctamente colocados si la arquitectura no fuera adecuada para lo que está tratando de lograr?

Por supuesto, queremos que cada programador sea fuerte con el pensamiento de alto y bajo nivel. También me gustaría un auto deportivo del que pueda transportar madera.

La atención al detalle es una forma de pensar sobre esto. Otra forma es: no exceder o perjudicar los períodos de atención.

La programación plantea enormes demandas de atención simultánea a una “pila” de preocupaciones. Demasiados detalles a la vez, o demasiado tiempo dedicado a hacer malabarismos con esos detalles, son una receta confiable para archivos y puntos y comas faltantes.

Hay una tendencia a pensar que ahorra dinero para obligar a los programadores a dedicar largas horas. Incluso hay una tendencia entre los programadores a presionarse * a sí mismos * para “superar las expectativas”. Incluso la falta de sueño “moderada” crea déficits de atención que probablemente produzcan exactamente los resultados que usted describe. La culpabilidad se puede compartir, pero probablemente indica menos sobre los individuos que sobre el proceso en el que están contribuyendo.

Entre un equipo de programadores, la carga no se puede distribuir de manera uniforme. Los déficits de atención, entre los programadores, cambian continuamente, a veces dramáticamente, a veces sutilmente. Las comparaciones de la eficiencia individual son más difíciles de lo que pueda imaginar, y sin embargo, son realizadas por todos los interesados, todo el tiempo. Estos juicios no solo son corrosivos, sino que a menudo son incorrectos.

Si ha tomado medidas para asegurarse de que su personal está bien descansado y opera a la máxima eficiencia con una capacidad óptima de atención, y aún ve buenos programadores que faltan puntos y comas, entonces empareje a cada programador de “profesor distraído” con un programador anotado para detalles. Puede descubrir que los dos juntos, * trabajando en una tarea *, son más eficientes, a la larga, que los dos trabajando por separado.

Soy disléxico Significa que tengo dificultades para escribir (sí, me da la ironía de que estoy escribiendo aquí, pero la práctica hace la perfección … también lo hace el corrector ortográfico).

Mis gerentes han dicho antes que soy rápido y eficiente en lo que hago. Me han dicho que puedo sacar cosas de mi cabeza y ponerlas en el “papel” muy rápido, lo que ven como la parte más difícil del trabajo. Después de hacer un volcado cerebral rápido de 2 horas, le di mi galimatías disléxicas a mi gerente, y no tenía idea de cómo lo hizo, pero mi inglés destrozado se convirtió en un documento brillante.

Una vez pregunté por qué mi gerente no estaba molesto porque no podía escribir las cosas correctamente. Siempre recordaré su respuesta.

“Puede que sea disléxico, pero estoy seguro de que es un regalo disfrazado. Puede dar grandes saltos de lógica y obtener una solución que funcione en segundos. Puede obtener grandes cantidades de datos de su cabeza y en el papel”. en una fracción del tiempo le tomaría a otros. Si todo lo que tengo que hacer es agregar estructura a su escritura, algo que encuentro muy fácil de hacer, entonces estoy dispuesto a hacerlo para que pueda continuar con algo más acorde con tus habilidades “.

Aprecié a ese gerente. Siempre lo miraré con cariño, y al final aprendí a estructurar mejor lo que escribo (aunque todavía me resulta difícil).

Empezaste a decir lo genial que es este tipo, y también hablas de despedirlo. Ambas cosas están en extremos opuestos del espectro. ¿Estás desbordando talento de ingeniería que fácilmente puedes permitirte perder a este tipo que te está ahorrando tiempo por todas partes? ¿O podría ser que necesitas trabajar más con él, animarlo o incluso apuntalar las áreas que le faltan para que, como equipo, ambos puedan moverse más rápido de lo que cualquiera de ustedes podría estar solo?

Puede hacerlo si lo desea, suponiendo que no haya implicaciones legales.

Sin embargo, parece que solo tienes un programador. ¿Cómo sabes que es ineficiente si no tienes una base para comparar?

La mayor parte de la estimación en el área de desarrollo de software es pobre. Se dan objetivos arbitrarios y luego no se cumplen. Si el programador no está cumpliendo los objetivos, tal vez sea culpa de los objetivos y no del programador.

La eficiencia de la programación es difícil de medir de todos modos. Las líneas de código producidas son un indicador deficiente, ya que la calidad es más importante que la cantidad. Pero no ha dado ninguna indicación de que haya intentado incluso esta medida.

Otra cuestión es la experiencia. Si su programador ha acumulado años de experiencia, sería un revés reemplazarlo. No querrás hacerlo sin tener confianza en la exactitud de tu decisión.

Aunque, a pesar de todo esto, puedes estar en lo correcto. Debido a que los programadores varían mucho en habilidad, tal vez tuviste mala suerte cuando lo contrataste. En ese caso, despedirlo y encontrar un reemplazo es una opción viable.

Asegúrese de que su próximo programador pueda pasar las pruebas de programación o tenga la certificación correcta.

Definir “eficiente”. Cuando se habla de eficiencia en el mundo de la programación, posiblemente haya infinitas dimensiones para pensar. ¿Y cuál es su base para juzgarlo “no lo suficientemente eficiente”? Si eso es:

” Pero me di cuenta de que a veces olvida algunos detalles pequeños, como olvidar agregar un archivo cuando entrega el proyecto al control de calidad, o incluso algunas cosas pequeñas como un punto y coma. Siento que esto puede convertirse en un problema más adelante”.

Quizás tú eres el que debería ser despedido. Si olvidarse de pequeños detalles como ese lleva mucho tiempo, usted mismo ha realizado un proceso ineficiente. Es común que ocurra en las empresas, pero si tiene el poder, debería poder simplificar el proceso. ¿Olvidaste agregar un archivo a QA? Entonces solo agrégalo. ¿Olvidaste un punto y coma? Solo agregue, comprométase y presione. NO compliques las cosas simples y luego culpes a quienes tienen que pasar por eso.