¿En qué punto abandonaría algunos de sus principios de desarrollo de software en aras de más dinero?

Me gustaría lanzar esta pregunta para ver de manera interesante dónde está el medio.

Voy a admitir que en mis últimos 12 meses, adquirí TDD y muchos de los valores ágiles en el desarrollo de software. Estaba tan abrumado con lo mucho mejor que se convirtió mi desarrollo de software que nunca los abandonaría por principio. Hasta que ... me ofrecieron una función de contratación que duplicó mi salario neto para el año.

La compañía a la que me uní no seguía ninguna metodología específica, el equipo no había oído hablar de olores de código, SÓLIDO, etc., y ciertamente no me iba a pasar el tiempo haciendo TDD si el equipo nunca hubiera siquiera visto pruebas unitarias en la práctica. ¿Soy un vendido? No, no completamente ... El código siempre se escribirá "limpiamente" (según las enseñanzas del tío Bob) y los principios de SOLID siempre se aplicarán al código que escribo cuando se necesitan. Sin embargo, se me abandonaron las pruebas, la compañía no podía permitirse el lujo de tener un equipo tan desconocido que, francamente, incluso yo creé marcos de prueba, nunca usarían / ​​mantendrían el marco de prueba correctamente.

Usando eso como un ejemplo, ¿qué punto diría que un desarrollador nunca debería abandonar personalmente sus principios de artesanía por dinero / otros beneficios? Entiendo que esta puede ser una opinión muy personal sobre cuán preocupado está uno por sus propias necesidades, las necesidades comerciales y el bien de la artesanía, etc. Pero uno puede considerar que, por ejemplo, las pruebas pueden descartarse si la empresa decide que prefieren equipo de prueba, en lugar de entender las pruebas unitarias en programación, ¿sería algo por lo que podría perdonarse como lo hice yo? Entonces, dado que hay algo que dejaría, generalmente debería haber un costo igual en el negocio que compensa lo que deja caer; con suerte, a menos que, por supuesto, no esté dispuesto a llenar sus propios bolsillos y no a la colaboración comunitaria / social; )

Duplica tu dinero, vuelve a RAD? O sigue caminando y busca a alguien que esté haciendo Ágil, y nunca mires atrás ...

Desde que me volví adicto a las pruebas unitarias hace más de 10 años, en la mayoría de mis lugares de trabajo fui el primero que escuchó sobre estas. Sin embargo, seguí escribiendo mis pequeñas pruebas unitarias cada vez que podía, y calculando el costo de las pruebas unitarias en mis tareas. Cada vez que alguien preguntaba sobre mis hábitos de codificación, le decía lo que estaba haciendo y por qué me funcionó. Por lo general, al menos algunas de las personas estaban interesadas, y eventualmente tuve que dar presentaciones sobre el tema y asesorar a las personas para escribir sus primeras pruebas unitarias.

No necesita comenzar a convencer a las personas sobre la forma ágil el primer día en su nuevo lugar de trabajo. Simplemente siga los principios en su propio trabajo tanto como pueda. Si lo haces bien, entregarás un mejor código. Si sus compañeros de trabajo y / o la gerencia lo notan, le preguntarán cómo lo hace. Entonces puedes decirles.

Actualizar

La mayoría de los desarrolladores experimentados (y gerentes) han visto tendencias y modas ir y venir, por lo que no se entusiasman con las últimas palabras de moda. Sin embargo, si puede demostrar que cierto enfoque (herramienta, forma de pensar) realmente funciona en la práctica, en el proyecto real , los que se preocupan por su oficio casi seguramente se sentarán y escucharán. Pero si no tienes a esas personas en tu equipo, tal vez sea hora de buscar un lugar mejor ...

Aquí es donde creo que todos los desarrolladores también deben conocer un poco de gestión de proyectos. Todo es una compensación entre tiempo, dinero y recursos. Considérate el recurso.

En mis 12 años de programación, no creo que haya completado un proyecto y lo haya pensado como terminado, o lo haya completado en mi mente. Siempre había algo que desearía haber podido hacer mejor o más limpio. Me tomó mucho tiempo darme cuenta de que esto se debe a esas compensaciones.

Entonces, si está pensando en cambiar de trabajo solo porque las metodologías no están allí, lo pensaría nuevamente si fuera usted. Estas compensaciones son constantes y se aplican a todos los desarrolladores de software. Incluso los desarrolladores de juegos más dedicados desearían poder hacer algunas cosas nuevamente, o practicar una metodología diferente nuevamente si tuvieran la oportunidad.

Diría que debería observar sus prácticas de desarrollo ágil y darse cuenta de que puede hacerlo incluso a nivel micro. Seguro que tus compañeros de equipo pueden estar fuera de la tierra haciendo lo que quieran, pero tu satisfacción personal será mayor y seguramente generarás un código mejor que ellos a largo plazo. Luego, cuando llega el gerente y le pregunta por qué su código es mucho mejor, tiene la oportunidad de convertir el equipo :)

Pero si no te gusta la gente o el trabajo, creo que ya sabes la respuesta. Pero dudo mucho que alguien entre en la sala y te diga que no uses principios de desarrollo ágiles mientras codificas ... si lo hacen ... corre gritando.

Nunca deje caer algo que lo haga infeliz a la larga. Por supuesto, puede comenzar en tierra de nadie e intentar que el equipo se mueva en su dirección. Si estás dispuesto a esforzarte y el trabajo lo vale, incluso puede ser un desafío interesante.

Pero si tiene que dejar las mismas cosas que mantienen el placer de codificar (o cualquier trabajo para el caso), mi experiencia es que se irá tarde o temprano. Aprendí que la frustración nunca debe subestimarse ...

Las personas en su último trabajo ya sabían acerca de TDD, SOLID, etc. Eso es genial. Estoy seguro de que disfrutaste trabajando allí y aprendiste mucho. Ahora tiene la oportunidad de enseñar esos conceptos (mientras hace mucho dinero al mismo tiempo). En mi experiencia, tener que enseñarle a alguien un concepto siempre me ha ayudado a aprenderlo con mayor detalle. Solo sé paciente con ellos y sigue impulsando tus conceptos uno a la vez. Cuando te sientas frustrado, ve a casa y cuenta tu dinero. O busque apoyo en SE.

Debo admitir que soy ab * tch en ese sentido. Como profesional independiente, cualquier cosa que el cliente considere como la metodología correcta para el proyecto, está bien para mí. Eso no significa que el dinero sea lo único que me importa, pero la decisión sobre qué hacer y qué dejar fuera depende del cliente. Sin embargo, no aceptaría malas condiciones de trabajo (ruidosas, largas horas, etc.).

Quiero citar a un ex colega mío. Dijo que cada vez que busca un trabajo o un proyecto a tiempo parcial, hay tres criterios que el proyecto debe cumplir:

• Debe ser divertido trabajar con
• Debe ser beneficioso para el desarrollo de su competencia (no estoy seguro de que esta sea la forma correcta de expresarlo)
• Debería pagar bien

Mientras leo su pregunta, este proyecto solo satisface los últimos criterios.

Como te has aficionado a TDD (igual que yo), creo que irás a diario y desearás que todos tus compañeros de trabajo hayan alcanzado la misma visión que tú. Por lo tanto, el primer criterio probablemente no se cumpliría.

En segundo lugar, si desea realizar proyectos TDD y tal vez obtener más experiencia en la creación de equipos ágiles, trabajar en este proyecto no lo ayudará a fortalecer esas habilidades. Por lo tanto, el segundo probablemente tampoco se cumplirá.

Entonces, personalmente, si estuviera en su posición y no estuviera en condiciones de ayudar a introducir TDD en la compañía, buscaría en otro lado.

Nunca.

La vida es demasiado corta (especialmente a medida que envejeces) para hacer cosas que odiarás.

Por supuesto, hace que sea más difícil cambiar de trabajo, y hay menos lugares para trabajar.

Pero al menos solo el código heredado huele mal. (Y tengo autonomía, por lo que podemos hacer cosas sensatas como pasar una semana eliminando las advertencias del compilador de la base de código heredada ...)

En resumen, la metodología de desarrollo no es parte de usted. No es una religión y no es quien eres. Es una herramienta. Haga lo que le digan, cómo se le diga y gane dinero extra. Miles de sistemas se desarrollaron y funcionan hoy sin TDD, Code Smell, etc. En pocos años, nadie sabrá qué significan estos términos porque las metodologías van y vienen con más frecuencia que un autobús urbano. Trabaja duro como te dicen y toma el dinero que se agradece en cualquier momento y todo el tiempo :)

Solo asegúrese de trabajar con el nuevo equipo es una buena inversión de su tiempo.

¿Quizás funcionan de una manera más eficiente de lo que te has encontrado hasta ahora? Si es así, trabajar con ellos será una gran experiencia de aprendizaje para usted (de ahí una buena inversión).

Por otro lado, las metodologías del nuevo equipo pueden ser de poco valor para usted (demasiada "codificación de vaquero", etc.). En ese caso, el dinero adicional probablemente no valga la pena (a menos que sea un inicio previo a la salida a bolsa o algo extraordinario). Probablemente no aprenderá mucho ... y corre el riesgo de agotarse.

No trabajaría en un lugar que no me permitiera trabajar como quería. Con eso quiero decir que no quiero ser microgestionado.

Trabajo bajo el supuesto de que soy bueno en lo que hago, y si me das algunas tareas, las haré de manera eficiente y efectiva. La forma en que los implemente, siempre que no rompa las pautas y patrones de su código, depende de mí. Esa es la parte divertida de mi trabajo.

Si quisiera hacer una prueba unitaria en cada clase que escribo, eso podría ser un problema, pero escribir pruebas unitarias generalmente está bien, siempre que cumpla con los plazos. Espero que un defensor de TDD argumente que escribir pruebas unitarias en realidad aumenta la productividad (más adelante, etc.). Si estuviera en su lugar, escribiría algunas pruebas unitarias que me ahorrarán algo de tiempo (probablemente menos errores, soluciones más fáciles). Si reinvierte ese tiempo ahorrado en más pruebas, se agravará aún más en el tiempo ahorrado y, con el tiempo, podrá sentarse con una gran sonrisa cuando tenga un conjunto increíble de pruebas, y puede verificar fácilmente los cambios en su código cuando haya una nueva hora 11 requisito entra.

Si no pudiera hacer eso, entonces no sé si me gustaría trabajar allí.

Lo que estoy diciendo es que creo que deberían darse y recibir estos asuntos, un poco de negociación. Cuanto más me pagan, menos sutilezas no monetarias espero. Pero siempre necesito un nivel de autonomía y autoestima, especialmente cuando no hay necesidad de negarse. Dejaré cualquier otro principio mientras tenga ese poco de autonomía. Después de todo, ¡lo que podría parecer una metodología al revés puede ser lo mejor que hayas hecho!