Francamente, ¿prefiere la codificación Cowboy? [cerrado]

Creo que casi todos los programadores experimentados han pasado por tres etapas y algunos han pasado por cuatro:

1. Los programadores Cowboy o nuggets saben poco o nada sobre el diseño y lo ven como una formalidad innecesaria. Si se trabaja en pequeños proyectos para actores no técnicos, esta actitud puede serles útil por un tiempo; hace las cosas, impresiona al jefe, hace que el programador se sienta bien consigo mismo y confirma la idea de que sabe lo que está haciendo (aunque no lo haga).

2. Astronautas de la arquitectura han sido testigos de los fracasos de sus primeros proyectos de bola de hilo para adaptarse a las circunstancias cambiantes. Todo debe reescribirse y, para evitar la necesidad de volver a escribir otro en el futuro, crean plataformas internas , y termina gastando 4 horas al día en asistencia porque nadie más entiende cómo usarlos correctamente.

3. Cuasi ingenieros a menudo se confunden con actual , ingenieros capacitados porque son genuinamente competentes y entienden algunos principios de ingeniería. Son conscientes de los conceptos empresariales y de ingeniería subyacentes: Riesgo, ROI, UX, rendimiento, mantenibilidad, etc. Estas personas ven el diseño y la documentación como un continuo y generalmente pueden adaptar el nivel de arquitectura / diseño a los requisitos del proyecto.

   En este punto, muchos se enamoran de las metodologías, ya sean Agile, Waterfall, RUP, etc. Empiezan a creer en la infalibilidad absoluta e incluso en la necesidad de estas metodologías sin darse cuenta de que en el real en el campo de la ingeniería de software, no son más que herramientas, no religiones. Y, desafortunadamente, les impide llegar a la etapa final, que es:

4. Programadores de cinta de ducto AKA gurus o consultores altamente pagados saben qué arquitectura y diseño van a utilizar dentro de los cinco minutos posteriores a conocer los requisitos del proyecto. Todo el trabajo de arquitectura y diseño sigue ocurriendo, pero está en un nivel intuitivo y es tan rápido que un observador no entrenado lo confundiría con la codificación de vaqueros, y muchos lo hacen .

   En general, estas personas tratan de crear un producto que sea "suficientemente bueno", por lo que sus trabajos pueden ser un poco menos diseñados pero están a millas del código de espaguetis producido por los programadores de vaqueros. Los Nuggets ni siquiera pueden identificar a estas personas cuando les hablan de ellos , porque para ellos, todo lo que está sucediendo en el fondo simplemente no existe.

Algunos de ustedes probablemente se estarán pensando a sí mismos en este punto que no he respondido la pregunta. Eso es porque la pregunta en sí es defectuosa. La codificación del vaquero no es una opción , es un nivel de habilidad , y no puedes elegir ser un programador de cowboy más de lo que puedes elegir para ser analfabeto.

Si eres un programador de vaqueros, entonces no conoces otra manera.

Si te has convertido en un astronauta de la arquitectura, eres física y psicológicamente incapacitado para producir software sin diseño.

Si usted es casi ingeniero (o ingeniero profesional), completar un proyecto con poco o ningún esfuerzo de diseño inicial es una elección consciente (generalmente debido a plazos absurdos) que debe compararse con los riesgos evidentes. y se realiza solo después de que las partes interesadas los hayan aceptado (generalmente por escrito).

Y si usted es un programador de cinta de ducto, entonces nunca hay ninguna razón para "código de vaquero" porque puede crear un producto de calidad con la misma rapidez.

Nadie "prefiere" el código de vaquero sobre otras metodologías porque no es una metodología. Es el equivalente de desarrollo de software de combinar botones en un videojuego. Está bien para los niveles principiantes, pero cualquiera que haya superado esa etapa simplemente no lo hará. Podrían hacer algo que se vea similar pero no será lo mismo.

Sí.

También prefiero dejar mis calcetines en el piso donde me los quité, mi escritorio cubierto de impresiones y viejas envolturas de bocadillos, mi fregadero lleno de platos sucios y mi cama sin hacer.

No considero que las vacaciones planificadas de antemano sean unas vacaciones adecuadas, una comida que se toma con la mente adecuada para la nutrición, o la permanencia en senderos conocidos para excursiones a pie.

Me gusta divertirme, sorprenderme, aprender cosas nuevas, cometer errores y nunca estar seguro de si volveré a hacerlo. Y a veces, esa actitud es exactamente lo que se requiere para que un proyecto despegue ...

... pero la mayoría de las veces, es simplemente irresponsable. Cuando termine el baile, se le pagará al gaitero ... Olvídate de esto a tu propio riesgo.

Eres exactamente correcto. Este enfoque de "programación de vaqueros" puede hacer que la primera revisión del código salga más rápido, pero ese ahorro de tiempo se perderá más que gracias a:

• errores adicionales
• Tiempo adicional necesario para encontrar los errores que habría tenido de todos modos
• Tener que aplicar ingeniería inversa a su código para recordar lo que hizo cuando necesita hacer un cambio en seis meses
• Tiempo adicional dedicado a la capacitación de desarrolladores adicionales que necesitan trabajar en su código
• No tener un registro de las revisiones a las que mirar hacia atrás cuando realiza un cambio que rompe algo
• Al no tener módulos, puede reutilizarlos fácilmente en proyectos posteriores
• Y sigue y sigue y sigue

Como mencionó Neil Butterworth en su respuesta, a veces tienes que hacer lo que tienes que hacer. Sin embargo, como práctica general, no, eliminar el código lo más rápido posible sin perder tiempo en el control del código fuente, los patrones, la documentación, etc. es un hábito muy malo para entrar.

Es bueno para usted analizar a sus compañeros de trabajo y considerar si sus hábitos son beneficiosos o perjudiciales en lugar de hacerlo ciegamente como lo hacen.

Esto realmente se reduce a la cuestión de si puede o no implementar las cosas correctamente sin una estructura ajustada y mucho tiempo consumido en la planificación.

Voy a lanzar algo aquí sobre este tema que puede ser realmente impopular: los clientes generalmente quieren que las cosas se manejen de manera vaquera .

Es decir, quieren solicitar que se haga algo, y que alguien salte, lo ejecute y lo saque. No hay gestión de proyectos, reuniones, llamadas de conferencia, o formularios. Simplemente hazlo. Nunca he tenido un cliente que diga "hey, esto se hizo un poco demasiado rápido para nuestros gustos, le agradeceríamos que pusiera un poco de cascada o algo así la próxima vez".

Las metodologías y la estructura del equipo están diseñadas para nivelar el campo de juego de un proyecto y obtener diferentes niveles de desarrolladores en la misma página, trabajando para los mismos objetivos, de la misma manera.

Los "cowboys" exitosos con los que he trabajado pueden:

• Identifique la forma más sencilla de implementar algo rápidamente
• Sepa en qué punto se romperá
• Escriba código limpio, legible y directo
• Predice cómo los usuarios lo usarán, abusarán de él y lo romperán
• Escálelo / sáquelo en los lugares correctos, y no vaya a la arquitectura como astronauta
• Sepa dónde y cómo manejar casos y excepciones de borde

La gente como esta produce resultados realmente excelentes con muy pocos gastos de administración y estructura, pero son raros.

EDITAR: Para referencias futuras, mi respuesta es para otro pregunta, que se ha fusionado en este. Está bastante fuera de lugar aquí, pero esa no era mi llamada.

Ella es simplemente perezosa, arrogante, ignorante y extremadamente egoísta. Este comportamiento es imprudente.

Quiero decir, no es que ella utilice una metodología poco convencional o quizás desactualizada. Ella simplemente usa ninguno conscientemente. No hay normas. Sin garantía de calidad. No, en absoluto. ¿De dónde espera que venga la calidad del software? Árboles?
Es gracioso que en realidad niega la experiencia de las personas que cita, cuando obviamente carece de ella. Proporcionar argumentos verificables y relevantes para cuestionar sus reclamos es válido. Pero solo intentar desacreditarlos negando su experiencia no lo es.

Pero, el punto principal es: ¿Cuánto tiempo tarda el control de versiones?
Si no puede convencerla de que invierta los 5 segundos de vez en cuando, debe llevárselo a su jefe. El control de versiones no es opcional. Parada completa.

Y una vez que la tiene usando el control de versiones, puede rastrear fácilmente qué errores introdujo. Y deja que ella los arregle. Es su desastre, ¿por qué deberías limpiarlo? Si ella piensa que su enfoque es mejor, entonces déjala que lo haga: hasta el final .
Suponiendo que realmente pueda hacerlo (dentro de un tiempo razonable), todavía tiene un problema: el trabajo en equipo con ella es casi imposible. Y esto es algo que tendrá que resolver, ya sea convenciéndola (lo que suena poco probable), haciéndola irse (por el bien de su compañía) o dejando (por su cordura). Pero su fracaso, en primer lugar, es mucho más probable y debería probar su punto de vista. Y luego comenzará a adherirse a las mejores prácticas como lo hacen muchas personas con mucha experiencia.

Depende completamente de si trabajo solo o en equipo.

Si trabajo en equipo, se requieren algunas convenciones y acuerdos; todos los miembros del equipo deben seguir alguna norma comúnmente acordada para trabajar hacia el objetivo común para que sus los esfuerzos son compatibles.

Pero si trabajo solo, entonces, por supuesto, quiero ser un vaquero. Todas las grandes creaciones en el mundo han sido inventadas por una sola mente, o como máximo dos, trabajando al estilo de vaquero. Solo por nombrar algunos:

• Mecánica clásica? El vaquero Isaac Newton, adiciones posteriores de Leibniz, Lagrange, Hamilton.
• avión? Vaqueros Wright.
• Teoría de la relatividad? Vaquero Albert Einstein.
• ¿Ciencia fundamental de las computadoras? Vaquero Alan Turing.
• transistor? Vaqueros Walter Brattain y John Bardeen.

Los equipos son buenos para hacer mejoras incrementales y armar nuevos sistemas basados en recetas probadas con bastante rapidez (siempre que se estén liderando bien), pero es raro escuchar acerca de una invención real hecha por un equipo. El trabajo en equipo y los métodos que requiere tienen sus virtudes, pero también la codificación del vaquero.

Depende del problema. Un buen desarrollador senior escribirá un código muy compacto, simple y robusto que es muy estable y usa todas las mejores prácticas sin pasar por páginas de documentación y toneladas de diferentes patrones y paradigmas. Pero también sabrá cuándo puede permitirse hacer tales cosas.

Me sorprendería si tomara un nuevo problema y comenzara a diseñar una aplicación que requiera de meses-hombre desde cero. Pero si se trata de un complemento, una herramienta simple que puede escribir en 2 horas, una función que realiza algunas conversiones y no está diseñada para ser reutilizada, el diseño y los patrones son solo buenos para perder el tiempo.

También, creo que gran parte del diseño ya se procesó en un hilo de fondo en algún lugar dentro del jefe de desarrolladores senior.

Tienes que comenzar a preocuparte cuando el desarrollador senior comience a batir las clases de un sistema complejo o nuevas aplicaciones desde cero y sin planear un paso.

Depende de las circunstancias. Por ejemplo, después de algunos escándalos comerciales desastrosos, varias bolsas de valores electrónicas insistieron en que las banderas de comercio automático se agregaran a todas las operaciones. Y esto tenía que ser para todo el software comercial dentro de una semana. Quiero decir que tenía que hacerse, si la bandera no estaba allí, no podías comerciar. En circunstancias como esa, todas las buenas prácticas van en la pizarra, solo hay que ir (como solíamos decir) "hacky, hacky, hacky". Y en esas circunstancias, escribir el código de manera rápida y precisa es clave. Especialmente porque no había sistemas de prueba disponibles.

Desde mi experiencia, la codificación de cow boy CON el control de código fuente es la mejor y más libre forma de desarrollar sistemas de software de gran tamaño.

Creo que uno de los comentaristas lo entendió bien: todo se trata de los resultados.

Si la persona puede producir un buen producto, algo que hace lo que se supone que debe hacer y que es mantenible y confiable , entonces, ¿qué importa si las metodologías formales o se siguen los procesos? Los procesos son excelentes para asegurar un piso en calidad, pero si alguien ya está trabajando por encima de ese piso, entonces los procesos no agregan nada a la ecuación. Demasiados desarrolladores en estos días, parece que, creo que el punto de la programación es adherirse a los procesos, a diferencia de producir un buen producto.

Este tipo de persona se llama hacker, y generalmente no es un término complementario del más profesional entre nosotros.

Como ha notado, el tiempo ahorrado en diseño, organización y control se pierde en la depuración. Y, a menudo, al encontrar qué versión de código fue la que se envió realmente. ¡Si puedes encontrarlo!

Me parece que este tipo de persona está demasiado envuelta en sí misma, piensa que es demasiado buena para trabajar con las 'limitaciones' que otros tienen que sufrir y, por lo tanto, no se molesta con ellos, y eso pierde aún más tiempo como el El resto del equipo tiene que limpiar después de ellos. Tampoco están demasiado involucrados en el proceso de corrección de errores (esa es la tarea de un desarrollador de mantenimiento, muy por debajo de las habilidades y el talento de 'l33t coder').

Por lo tanto, podría ser un enfoque común en otros lugares, pero en mi lugar (y soy un programador senior que tiene tendencias a este enfoque, ejem) no lo sufrimos. No es que exijamos un montón de procesos y procedimientos, pero sí insistimos en una cantidad mínima de organización, control de código fuente (lo que para ser honesto es sangriento, ¡y muy útil!)

Kent Beck y otros, son profesionales que vieron que las viejas formas cargadas de procesos eran malas en sí mismas, por lo que creó nuevas metodologías para organizar la codificación a la vez que la mantiene más orientada a la artesanía, y luego se lo contó a todos los demás: publicó libros (¿de qué otra forma lo hizo antes de Internet?)

Parece que lo tienes bien, no aceptes malas prácticas solo porque alguien más no pueda piratearlo. El jefe o gerente de tu equipo debería estar afectando a este 'estrella de rock', pero si no lo están ... bueno, eso todavía no te impide hacer lo correcto. Simplemente no acepte prácticas de mala calidad de parte de ella, si se equivoca (¡y lo hará!), Entonces deje que lo limpie. Se adhiere a las buenas prácticas (y sabe cuáles son) sin permitir que tomen el control de su productividad de codificación, y será bueno para el futuro.

Aquí hay un ensayo de un escritor verdaderamente perspicaz. No soluciona tu problema, pero te da una idea de por qué es así y quizás algunos consejos para tratarlo profesionalmente.

El único hecho importante es el resultado a largo plazo de los productos del equipo.

Hay un reclamo de que un equipo que incluye un gran programador (o más) producirá mejores resultados que un equipo con un número aún mayor de programadores promedio que codifican a una tasa promedio.

Si el vaquero produce cosas que los programadores regulares no hacen (por una fecha límite o especificación), y el equipo con el vaquero incluso tiene que pasar algunas semanas / meses para limpiar el desorden del vaquero, todavía podrían terminar. con el mejor resultado antes.

Si el equipo con el vaquero no puede limpiar (documentar, depurar, integrar, mantener) el desastre incluso después de muchos meses / año, entonces cualquier avance que el vaquero creó no le dio una ventaja a largo plazo. / p>

Decida cuál y optimice la lista del equipo.

No todos los programadores funcionan (o deberían funcionar) de la misma manera, siempre que el resultado final sea bueno.

Puede encontrar información sobre mi respuesta a Francamente, ¿prefiere la codificación de vaqueros? El problema es, "codificación de vaquero" significa diferentes cosas para diferentes personas, y no es inmediatamente obvio, para el ojo no entrenado, qué versión está viendo.

Cuando alguien puede ver un problema e inmediatamente comenzar a aplicar el código de manera rápida y precisa, puede ser el signo de un ingeniero maestro que lo ha visto todo mil veces antes y ya conoce el La mejor manera de resolver el problema.

O, puede ser el signo de un amateur de rango.

Le diré una cosa: negarse a usar el control de versión o las pruebas de escritura porque son demasiado "académicas" definitivamente no es ni un enfoque "senior" o incluso remotamente profesional. Nunca, nunca verás hacer este tipo de cosas en una importante tienda de software como Microsoft o Google, y probablemente tampoco lo verás en la mayoría de las empresas nuevas o en equipos empresariales razonablemente maduros.

Los riesgos son demasiado grandes. ¿Qué pasa si tu PC muere durante la noche? Adiós 3 años de productividad. Bien, entonces haces copias de seguridad; entonces, ¿qué sucede cuando realiza un cambio importante, se da cuenta de que estaba completamente equivocado y tiene que revertirlo? Esto le sucede incluso a los desarrolladores más experimentados y talentosos porque los requisitos son incorrectos. Si no está ejecutando ningún tipo de control de versión, simplemente va a girar las ruedas en el lodo. He estado allí, una vez, y nunca volvería

Simplemente no hay excusa: se necesitan 10 minutos para configurar un repositorio y 10 segundos para hacer un compromiso. Supone tal vez el 1% de su tiempo total de desarrollo. Las pruebas, si tienes prisa, pueden reducirse fácilmente a 20-30 minutos al día y seguir siendo razonablemente útiles.

No soy un fanático de las metodologías ágiles (tenga en cuenta la capital A) pero a veces realmente necesita simplemente arremangarse y comenzar a escribir el maldito código. He visto personas y equipos con "parálisis de análisis" y la productividad realmente tiene un impacto visible. Pero el rechazo de las herramientas básicas de nuestro comercio como el control de revisión y las pruebas es realmente el factor decisivo para mí; esta persona no pertenece a una posición senior.

Sí, pero debes reconocer cuándo NO hacerlo.

En cualquier cosa pequeña, probablemente esté bien, pero si tiene algo complejo, peligroso, limitado, etc., debe poder reconocer cuándo vale la pena un tiempo extra para un diseño adecuado.

También creo que deberías pensar en la respuesta de Aaronaught. Vaquero significa diferentes cosas para diferentes personas.

Cuando pienso en metodologías "tradicionales", creo que "la administración no sabe cómo entender a los desarrolladores, así que en lugar de entrar en el mundo de los desarrolladores y entender lo que está pasando, hacen que los desarrolladores entren en su mundo" .

Fundamentalmente, cuando pienso en "Agile", creo que "haces lo que debes hacer para minimizar las ineficiencias introducidas por varias personas que trabajan juntas". Así que estoy firmemente en el campamento de que "no hay tal cosa como LA Metodología ágil , solo un conjunto de valores y principios".

En otras palabras, hay cosas que debes hacer en un proyecto muy grande, y hay cosas que debes hacer en proyectos pequeños, y hay cosas que haces en ambos.

Por ejemplo, no tendría más que el más simple de los trabajos pendientes para un proyecto en el que estoy trabajando ... Solo sería una lista de tareas pendientes. Si hay dos de nosotros, probablemente tendría esa lista compartida, pero en un formato muy simple (probablemente solo una nota almacenada en nuestro repositorio de código). Una vez que tengo 3 o 4, estoy buscando algún tipo de sistema de elementos de trabajo.

Solo cuando se realizan prototipos de características muy simples.

Luego, una vez hecho y considerado de la manera correcta, abandono el código y me pongo serio.

Lo hice una vez en un proyecto real (en el momento que lo llamamos Programación Samurai, después de la serie de bocetos Samurai Tailor en Saturday Night Live), y para mi sorpresa, funcionó bien. Por supuesto, lo que comencé con fue basura, por lo que había poco riesgo de empeorarlo.

Sin embargo, soy un "corpulento" de corazón y no me gusta el estilo de desarrollo de disparar desde la cadera.

Por otra parte, el modus operandi cargado de procesos tampoco es de mi gusto. Simplemente me gusta planear antes de actuar.

En general, creo que la cantidad de proceso formal que es apropiada depende en gran medida de la magnitud (tamaño del código, duración del proyecto, número de desarrolladores, tipos de requisitos, etc.) del proyecto. Quiero que se impongan criterios rigurosos y estrictos a las personas que desarrollan el software para aviónica o equipo biomédico, por ejemplo. Para los juegos, por ejemplo, hay mucho menos inconveniente con cualquier falla, por lo que el costo y la carga de las prácticas de desarrollo metódico y riguroso no están realmente justificados.

Depende (en gran medida) del tamaño del proyecto. Por un lado, para obtener un resultado decente, es necesario que tenga un diseño. Por otro lado, si el proyecto es lo suficientemente pequeño como para que pueda conceptualizar el diseño completo (de todos modos, en su mayoría) sin escribirlo, dibujar diagramas, etc., entonces probablemente esté tan bien sin ese trabajo extra de documentando todo lo que haces.

Casi todo el mundo ha escuchado suficientes historias de horror como para darse cuenta de que intentar saltar sin tener una idea clara de lo que estás haciendo y hacia dónde van las cosas es una receta para el desastre. Lo que mucho más raramente se señala es que lo contrario puede ser igualmente desastroso. Por ejemplo, la mayoría de nosotros escribimos habitualmente pequeñas herramientas en el proceso de programación. Escribir una especificación completa, pruebas, documentación a menudo simplemente no vale la pena. Hay un umbral debajo del cual la productividad no vale la pena: a las personas a menudo no les gusta reinventar la rueda, pero en algunos casos es más fácil reinventar que evitarla.

En casos como este, lo que a menudo vale es producir una biblioteca para facilitar tareas como esta. Con eso, el código de front-end a menudo se vuelve tan trivial que escribir (o modificar) el código para hacer lo que quiere se vuelve más fácil que determinar cómo obtener un programa completo para hacer lo que quiere. Considere, por ejemplo, gnu indent con sus más de 50 banderas diferentes, muchas de las cuales interactúan de varias maneras sutiles, por lo que las únicas opciones razonables son 1) no usarlo en absoluto, o 2) decidir si le gusta lo que le da en lugar de tratar de obtener lo que originalmente querías.

Parece que hay dos campos: los que favorecen los resultados y los que favorecen los principios. Caigo en este último.

Soy un programador mediocre pero discutiblemente concienzudo. Mi principal preocupación al programar, más allá de hacer el trabajo, es que estoy ayudando a quien usa mi código para que haga SU trabajo. No puedo decir que siempre lo he logrado, pero eso es lo que pretendo hacer.

Claro, usted puede tener un hotrod en su equipo, pero ¿qué sucede cuando se toman un par de semanas de licencia y se le pide que depure su trabajo o le agregue cosas? En última instancia, los programadores de vaqueros no son jugadores de equipo. Pueden hacer un gran código, pero si el equipo depende de ellos, es peligroso.

Tengo la sensación de que tu disgusto por su estilo está causando que lo tergiverses un poco. Usted dice que el enfoque de vaquero se paga en la depuración : ¿esto es lo que ya está sucediendo o es su suposición de cómo se desarrollará?

Divulgación justa: yo mismo soy un desarrollador senior y, a menudo, renuncio a un proceso formal de diseño y experiencia. No tener un proceso formal para alguien que tiene mucha experiencia en el dominio del problema es bastante común. Si resolvió un problema docenas de veces, no necesita un proceso formal para formular una solución similar nuevamente.

Un proceso formal tiene que ver con el diseño del código. No veo por qué se deben introducir más errores porque falta un proceso formal. El único gran problema que leí en su cuenta es que el control de revisión no se está utilizando, lo que no solo es egoísta, sino que es francamente imprudente en nombre del desarrollador. ¿De hecho ella no se está comprometiendo en absoluto, o simplemente no está cometiendo un patrón que sea de su agrado?

No tener un enfoque formal para el diseño no es "codificación de vaquero" en mi libro (aunque no se usa el control de revisión). La experiencia debe usarse exactamente para eso, para reducir el tiempo necesario para encontrar una solución "suficientemente buena". Recuerde, tiene que resolver los problemas que tiene actualmente y hacer que el código sea fácil de cambiar, no diseñar para escenarios futuros que nunca podrían suceder. Con la experiencia, obtendrá una buena idea de cómo hacerlo muy rápido.

No, nunca.

Siempre hago análisis de requisitos, pienso en la arquitectura, diseño los detalles y luego codifico. Incluso si trabajo solo en casa para un proyecto personal.

Y instantáneamente despediría a un desarrollador en mi equipo si él / ella trabajara en un estilo de vaquero. Somos ingenieros y tenemos una responsabilidad con el cliente y los usuarios.

No creo que la codificación de vaqueros sea un enfoque de alto nivel.

Como han dicho otros, existe un peligro real al descartar el control de versiones. Omitir documentación y análisis también podría significar arriesgarse a entregar algo que el usuario no quiere. Solo mi opinión, pero no creo que vayas de "programador a desarrollador" si todo lo que haces es un código de vaquero.

Sin embargo, sí, hay excepciones como la que menciona Neil Butterworth. Y en estas situaciones, prefiero que un desarrollador senior con experiencia sea el que tenga que hacer la codificación del vaquero.

La programación de Cowboy es una forma bastante segura de crear una big ball of mud . Lo que, por desagradable que parezca, tiende a entregar ...

Creo que los programadores más nuevos tienden a hacer cosas de codificación de vaqueros al abordar aspectos de un proyecto / ámbitos con los que pueden no tener mucha experiencia o cuando están tratando de "hacer las cosas" debido a la presión de un jefe, etc. Sé que definitivamente he tomado este camino unas cuantas veces porque me faltaba el conocimiento del patrón apropiado para usar y simplemente "me abrí camino a través de él".

La diferencia entre yo y la persona por la que te quejas es que, por lo general, poco después me doy cuenta de que podría haberlo hecho mejor y hacerlo más fácil de mantener y generalmente me incita a aprender más y mejorar mis habilidades (leyendo libros / artículos sobre el tema). Cuando vuelvo a depurar algunas de estas soluciones pirateadas, por lo general me parece una molestia y contribuye más a mi deseo de aprender a hacerlo de la "manera correcta". Creo que esta persona que estás describiendo está básicamente atascada en un nivel infantil de auto reflexión y deja que su propio ego se interponga para mejorar sus habilidades como desarrollador de software, no parece ser alguien con quien quisiera trabajar.

Encuentro tu post interesante. A menudo he compartido opiniones con su tema, y su sensación es que los métodos demasiado formalizados son asfixiantes. Como alguien más notó, si ella es una genio y puede rastrear una multitud de notas mentales al mismo tiempo sin olvidar o confundirse, entonces es muy posible mantener un trozo monolítico de código enrevesado y hacerlo para hacer cosas sorprendentes con cambios completamente oscuros. . Hay una cierta felicidad mental que llega a los cerebros de las personas que pueden hacer eso, es como ser el Dios de un pequeño universo en tu mente.

Sin embargo, los empleadores inteligentes han aprendido de la manera difícil que nadie, excepto el autor original, puede hacer algo que valga la pena con ese código. Si el programador sigue adelante, terminan desperdiciando mucho dinero pensando que la única opción es volver a escribir (solía pensar que eso significaba una pérdida total, pero en estos días me doy cuenta de que no se destruye el resultado intrínseco de desarrollo iterativo a nivel de funcionalidad externa).

Personalmente, no me importaría tener a alguien así en el equipo, porque en una situación difícil, podrían hacer algo en lo que nadie más piensa.

Por otra parte, sé tu propia persona y decide por ti mismo cuál es la respuesta a tu pregunta, porque lo único que es seguro es que nadie lo ha descubierto cuando se trata de construir software. Es una de las cosas que lo hace un campo interesante ...