¿Cómo defiendo los costosos programadores?

En nuestra empresa, necesitamos hacer muchas cosas aparentemente no complicadas, como desarrollar la interfaz de usuario móvil.

Digamos que los programadores experimentados nos cuestan 4 veces más que los principiantes.

Ambos son básicamente capaces de completar las cosas aparentemente simples en la misma cantidad de tiempo.

La diferencia es que los programadores experimentados producen menos errores y su código es más estable, etc. Los programadores principiantes pierden mucho tiempo de todos los demás (PM, clientes, etc.). Pero son significativamente más baratos.

El argumento contrario es que se necesita la misma cantidad de tiempo para principiantes y experimentados para hacer una tabla en HTML. Por lo tanto, es un lujo contratar programadores experimentados para hacer, lo que los programadores principiantes también pueden lograr.

Deberíamos invertir en más y mejores programadores o más y mejores PM, dado que la diferencia entre un programador experimentado y un nuevo programador en nuestro campo puede ser 4x.

Tengo experiencia de primera mano de ambas teorías que se están probando en el mundo real, en el mismo proyecto en realidad.

Antes de llegar, se tomó la decisión de contratar licenciados más caros y programadores muy baratos; la idea era que los programadores muy jóvenes siguieran servilmente las especificaciones de buena calidad.

Después de más de 6 meses del proyecto principal, asumí el cargo de gerente de desarrollo. Una vez que solucioné algunos factores de higiene, el problema de la calidad del código permaneció. Tenía un presupuesto extra y contraté a un programador muy experimentado (bueno, más un arquitecto de soluciones) con habilidades de comunicación fuera de lo común y una vida anterior como entrenador en C # (el lenguaje en el que se escribió el proyecto). La idea era mejorar la calidad de los otros codificadores al proporcionar mentoría y capacitación efectivamente gratuita.

Después de un mes o dos, se hizo dolorosamente obvio que incluso eso no iba a funcionar, por lo que el equipo original fue eliminado del proyecto y se agregaron un par de programadores más. Entregaron el proyecto que el equipo original no pudo entregar por completo en más de 8 meses de intentarlo en 3 sprints de un mes a partir de cero porque el código original era irredemable.

Si sus requisitos son muy básicos, es posible que pueda salirse con la suya utilizando un programador muy junior, pero lo más probable es que a la larga le costará mucho más. A veces, los requisitos "simples" evolucionan hacia una gran complejidad.

Si no hubiera tomado la decisión difícil de cambiar de dirección, probablemente todavía estarían trabajando en ello :) - Más en serio, en este ejemplo, la falta de comunicación y competencia por parte del equipo original significaba que no plantearían problemas con el especificación pero solo trataría de hacer lo que se les pidiera que hiciera si tenía sentido arquitectónicamente o no. Un desarrollador con más experiencia y confianza hizo preguntas y se ocupó de los requisitos subyacentes y, por lo tanto, terminó produciendo la solución correcta la primera vez.

Oh, otra cosa. No asuma que puede contratar de inmediato a un gran programador. Hay mucha gente por ahí con muchos años de experiencia en mediocridad que proporcionará un resultado casi tan malo como un junior pero costará lo mismo que una superestrella (a veces incluso más). Tengo una muy buena "tasa de éxito", pero eso viene con experiencia y tengo mucho. Ese es el tema de una conversación completamente diferente que está fuera de tema aquí ...

TL; DR Los buenos programadores son una ganga. Lo difícil es encontrarlos y crear un ambiente de trabajo lo suficientemente atractivo como para mantenerlos.

Si tiene estadísticas de rendimiento extensas, puede hacer el caso de negocios con las matemáticas. Esto podría mostrar que la velocidad de desarrollo compensaría el aumento en el precio, o incluso mejor, que un diseño robusto podría ahorrar más en mantenimiento y desarrollo de versiones posteriores. Desafortunadamente, tales cifras no están disponibles tan a menudo, especialmente para las tecnologías más nuevas.

Otro argumento puede ser el tiempo de comercialización. Esto es más fácil de entender por la alta dirección. Sin embargo, si el tiempo no es realmente crítico, esto no ayudará.

En último recurso, encuentre una foto de Red Adair , el famoso bombero, que fue llamado en un desastre mayor después de varios intentos fallidos de chicos menos experimentados. Su famosa cita:

Si cree que es costoso contratar a un profesional, espere hasta que haya contratado a un aficionado.

... merece ser impreso en color y exhibido prominentemente en la puerta de su oficina, para que todos entiendan de qué se trata ;-)

Me gustó y voté por la respuesta de mcottle, pero quiero cubrir algunas otras dinámicas y argumentos que las otras respuestas aún no han mencionado.

Primero, implícito en la respuesta de mcottle está el hecho de que debajo de cierto nivel de habilidad, algunos problemas son simplemente imposibles. Desafortunadamente, la forma en que descubres esto es que tu equipo lo intenta y falla, lo cual es muycostoso. Después de fallar, hay dos lecciones posibles para aprender de esto. Una opción es aprender que necesita desarrolladores más competentes y, por lo tanto, contratarlos y completar el proyecto significativamente por encima del presupuesto y el cronograma, pero al menos está preparado en el futuro. La otra opción es que dicho proyecto es "demasiado difícil" para su equipo y tales cosas no deberían intentarse en el futuro, es decir, usted renuncia al proyecto y efectivamente cualquier otro similar. Por supuesto, rara vez se expresará como "somos demasiado tontos para hacer esto", sino que se racionalizará como "nuestros sistemas son muy complejos" o "tenemos mucho código heredado" o algunos otros. Este último punto de vista puede deformar significativamente la perspectiva de una empresa sobre lo que es posible y lo largo que debería ser el desarrollo costoso. "

Una pregunta es, ¿cuál es exactamente el plan de su empresa? De acuerdo, contratarán programadores baratos y junior. Pasan tres años, ¿y ahora qué? ¿Qué hacen con el desarrollador que ha estado con ellos durante esos tres años? ¿Simplemente nunca le dieron un aumento? Las opciones aquí son las siguientes:

• Dan aumentos competitivos para retener a los empleados, en cuyo caso ¿por qué tendrían problemas para pagar las tarifas de los desarrolladores senior ahora? Aunque volveré a esto.
• Tienen tasas estancadas, lo que significa que eventualmente van a "reducirse" a los empleados que carecen de impulso y / o habilidad.
• Eliminan más activamente a los empleados de más antigüedad.

Los dos segundos casos implican una gran rotación de empleados, lo que significa pérdida de conocimiento de la empresa y pagos continuos a los empleados. En el segundo caso, básicamente está seleccionando desarrolladores malos, por lo que los costos aumentarán en forma de horarios cada vez mayores. La forma en que esto se desarrollará es que todo va bien en el proyecto X hasta que de repente Jim se vaya, que fue uno de los mejores desarrolladores, porque no ha recibido un aumento en dos años, ahora el proyecto "comprensiblemente" tomará mucho más tiempo ya que debe contratar y capacitar a nuevos desarrolladores junior que (presumiblemente) no serán tan buenos como lo fue Jim. Así es como recalibras las expectativas.

Incluso en el caso de que se proporcionen aumentos competitivos, si todo lo que tiene son desarrolladores junior, ¿dónde y cómo se supone que deben aprender? Básicamente, espera que uno de ellos aprenda buenas prácticas por su cuenta a pesar de su entorno de trabajo, y eventualmente asesore a otros (en lugar de irse a pastos más verdes). Tendría mucho más sentido "preparar la bomba" con algunos buenos desarrolladores. Lo más probable es que desarrolles una cultura de Expertos Principiantes . El resultado es que terminarás pagando tarifas de desarrollador senior a personas que son solo un poco mejores que los desarrolladores junior y que son culturalmente tóxicos.

Una ventaja de, particularmente, los muy buenos desarrolladores, que me sorprende que nadie más haya mencionado es que pueden ser fácilmente un factor multiplicativo . Es muy posible que un desarrollador junior y un desarrollador senior tomen la misma cantidad de tiempo para hacer una tabla. Sin embargo, un buen desarrollador no hará eso. Harán un generador de tablas que reduce el tiempo para que todos hagan una tabla. Alternativamente / adicionalmente, elevarán el límite de lo que es posible para todos . Por ejemplo, los desarrolladores que implementaron el marco MapReduce de Google probablemente estaban extremadamente calificados, pero incluso si los usuariosde MapReduce son completamente incapaces de hacer una versión distribuida masivamente de su algoritmo por sí mismos, ahora pueden hacerlo fácilmente con MapReduce. A menudo, esta dinámica es menos evidente. Por ejemplo, un mejor control de origen, pruebas y prácticas de implementación mejoran a todos , pero puede ser más difícil de rastrear hasta una persona específica.

Para discutir el otro lado por un momento, tal vez los superiores tengan razón. Quizás no sean necesarios desarrolladores más experimentados. Sin embargo, si ese es el caso, parecería que el desarrollo no es una parte importante de la empresa. En ese caso, simplemente eliminaría a los desarrolladores por completo y usaría software comercial o contrataría contratistas a pedido. Puede valer la pena explorar por qué no solo usan contratistas en lugar de un equipo interno. Si va a tener una gran rotación de empleados de todos modos, entonces aumentar los contratistas no debería ser un problema.

Esta no es una o una situación.

Especialmente en un proyecto de mayor envergadura, habitualmente tiene algunas personas relativamente experimentadas en roles superiores y varias personas menos experimentadas en roles menores. De esta manera, las personas mayores no solo pueden ayudar directamente en el proyecto escribiendo código y ayudando a tomar las decisiones más difíciles, sino que también pueden ayudar indirectamente guiando a los jóvenes.

Con un poco de cuidado, esto también puede ayudar a evitar que los ingenieros superiores se agoten rápidamente al pedirles que realicen constantemente un trabajo que carece de desafíos o interés para ellos. Al menos en mi experiencia, incluso un poco de tiempo asesorando a algunas personas entusiasmadas de nivel junior (o incluso de nivel interno) puede hacer que un sprint sea mucho más interesante.

Para ser justos, debo agregar que este tipo de posición probablemente no se adaptará a todos los ingenieros superiores. Requiere un mayor énfasis en la arquitectura y el diseño, la comunicación, la documentación, etc. Especialmente al principio, también requiere mucha disciplina: para alguien que ha hecho una carrera de escribir código, es tentador simplemente escribir el código, en lugar de enseñarle a un ingeniero junior cómo hacerlo. También es frecuentemente tentador hacer una reescritura completa desde cero cuando el código no es como lo preferiría personalmente, incluso si es perfectamente adecuado para el trabajo.

Si, sin embargo, realmente no se puede convencer a la dirección para ir con una mezcla de los niveles de experiencia, hay básicamente ninguna cuestión en todo lo que tiene que ir por más experiencia. Si deja un proyecto enteramente al personal junior, es muy probable que nunca obtenga un producto utilizable. Peor aún, no se darán cuenta de que lo que están haciendo no está proporcionando ningún progreso real hacia un producto utilizable, por lo que continuarán trabajando en una dirección elegida mucho después de que una persona con más experiencia se haya dado cuenta de que han hecho un error fundamental desde el principio, y necesita retroceder, reagruparse, orientarse y comenzar en una nueva dirección para tener alguna esperanza de llegar a un destino significativo.

Cualquier proyecto del mundo real está impulsado por la demanda del cliente y, por lo tanto, implica tareas de baja complejidad (por ejemplo, crear formularios CRUD) y alta complejidad (por ejemplo, construir un sistema de notificación basado en eventos). La única forma de tener solo tareas de baja complejidad es decirle repetidamente a los clientes la palabra "no", que ningún departamento de ventas del que haya oído hablar está dispuesto a hacer.

Si solo tiene desarrolladores de nivel junior, significa que solo podrá realizar tareas de baja complejidad y, por lo tanto, solo podrá construir un producto de bajo valor y luchar más en el mercado para diferenciar sus productos. Si desea diferenciar, debe crear una funcionalidad de alto valor, que inevitablemente se traduce en tareas de alta complejidad. Después de todo, si fuera fácil, no sería valioso. Eso significa que necesita personas para ejecutar esas tareas de alta complejidad y necesita desarrolladores de nivel superior.

Si solo tiene desarrolladores de nivel superior, desperdiciará sus habilidades en trabajos de bajo valor, tendrá problemas para retenerlos cuando los obligue a hacer dicho trabajo, así como arriesgarlos a ir a la tierra de la astronomía de la arquitectura al tratar de hacer tareas más simples interesante para trabajar. Esto significa que también debe tener algunos desarrolladores sin experiencia para recoger esas tareas.

Un equipo saludable que trabaja en productos orientados al cliente suele ser una combinación. La relación entre desarrolladores junior y senior depende de la relación entre las tareas de baja complejidad y alta complejidad, y eso depende de su estrategia comercial. Si busca activamente grandes volúmenes de trabajo de corte de cookies de bajo margen y fácil de entender, no tendrá muchas tareas de alta complejidad y probablemente contratará principalmente desarrolladores de nivel junior. Si busca activamente diferenciar y apuntar a nichos desatendidos con márgenes de beneficio más altos, tendrá muchas tareas de alta complejidad y buscará principalmente desarrolladores de nivel superior.

En mi respuesta, argumentaré que los programadores senior no necesariamente codifican más rápido que los desarrolladores junior. De hecho, los programadores más rápidos son en promedio hombres que acaban de salir de la universidad.

El conocimiento del dominio es clave para el desarrollador senior. Un buen desarrollador senior debe tener un conocimiento sólido del campo, algo que el desarrollador junior podría no tener. Los desarrolladores experimentados entienden el problema, qué resolver y cómo resolverlo. Pueden resolver problemas más complicados para el negocio que la mayoría de los desarrolladores junior.

La programación es un conjunto de habilidades relativamente barato, lo que cuenta es el conocimiento experto.

No intente "hacer el caso" El mercado fija el precio para los empleados. Si el mercado está dispuesto a pagar 4 veces más por la experiencia, es porque las compañías en su conjunto han deducido que hay un aumento de productividad 4 veces mayor.

Ahora, obviamente, el mercado podría estar equivocado, tal vez sea 3.5 o 5x, pero a menos que sea una agencia digital, competir contra el mercado o algo por el estilo no es importante.

Tu verdadero problema es: ¿Eres lo suficientemente bueno en las entrevistas para poder distinguir entre un desarrollador experimentado y solo un desarrollador antiguo que lo está criticando?

Su segunda pregunta de PM vs presupuesto de desarrollador. Diría que un desarrollador puede prescindir de un PM pero un PM no puede prescindir de un desarrollador. Primero ordene su motor de desarrollo, luego obtenga un PM para quitar al administrador de sus manos.

No encontrará a nadie en su propio país por un cuarto del costo de un desarrollador realmente bueno. Puede encontrar a alguien por la mitad del salario, y eso será un principiante absoluto. Para alguien con una cuarta parte del salario, debe salir del país y luego tendrá problemas con las comunicaciones, las personas que siguen ciegamente las especificaciones y todo tipo de problemas.

Usted necesita un desarrollador bueno. Si agrega más programadores junior, necesita un buen desarrollador con fuertes habilidades de comunicación, que esté dispuesto y sea capaz de vigilar a los junior. Sin un buen desarrollador, estás perdido. Es posible que tenga suerte de encontrar un principiante talentoso extraordinario, pero una vez que él o ella descubra que son buenos, querrán un salario mayor.

Si no tiene un buen desarrollador, no tiene a nadie que vea la imagen más grande, y nadie que pueda resolver problemas que no se pueden resolver con stackoverflow. Y tendrá un código que apesta y no se puede mantener, porque los desarrolladores junior no saben cómo crear código que se pueda mantener. Pueden aprenderlo, pero no lo harán sin algún buen desarrollador en el equipo.

Hay algunos obstáculos que su empresa tendría que superar antes de que pueda decidir si contratar a mejores programadores sería rentable. Lo siento si estoy haciendo algunas suposiciones negativas sobre dónde trabajas, pero no estoy convencido de que sepan lo que están haciendo.

1. ¿Han evaluado con precisión qué tan complejo es el software que construyes? Parece que no piensan que lo que estás haciendo es muy difícil, entonces, ¿por qué contratar a mejores personas? ¿Ha presentado el caso donde se cometen errores y cómo mejores soluciones y productividad harían dinero? Ahorrar tiempo es excelente, pero muchas compañías prefieren perder el tiempo de una semana entera de programador que darles el dinero para comprar una alfombrilla para el mouse.
2. ¿Su empresa es atractiva para los buenos programadores? ¿Son capaces de identificarlos? Nada peor que contratar a un Desarrollador Senior, pagarles más dinero y arrastrar a todo el equipo hacia abajo debido a su falta de habilidades y / o liderazgo.
3. ¿Puede su empresa utilizar un buen programador? Si todo lo que van a hacer es arrojarles especificaciones de mala calidad y simplemente decirles que solo vayan a construirlo, ¿cuál es el punto? ¿Les darán la libertad de hacer las cosas a su manera? Después de todo, un buen programador, por definición, sabe cómo utilizar mejor su tiempo. Impactan a quienes los rodean y hacen que otros programadores mejoren. Presentan mejores diseños y arquitecturas que el resto se basa en hacer que el producto sea mucho mejor.

Lo sentimos, pero siento que su empresa no sabría qué hacer con un buen programador, por lo que es conveniente convencerlos de que primero contraten mejores gerentes y resuelvan estos problemas internos.