¿El uso de nuevas técnicas perjudica la productividad? [cerrado]

Parece que a medida que crece la experiencia con el conjunto específico de herramientas con las que tiene que trabajar, el incentivo para probar cosas nuevas se debilita.

Cuando era nuevo en este trabajo de programación, probar cosas nuevas, investigar en línea, me hizo más productivo, porque a menudo encontré una forma (o biblioteca) que hacía que la tarea fuera más fácil que el marco de código ya existente. Entonces, usar algo nuevo, tanto para mí como en el contexto de la base de código dada, me hizo más productivo.

Ahora me di cuenta de que hay cada vez más casos en los que, para un problema dado, sé que probablemente haya una mejor solución "allá afuera", y encontrarla, presumiblemente, mejoraría el código. Sin embargo, dado mi conocimiento ahora íntimo de la base del código, es mucho más fácil usar las herramientas subóptimas que tenemos y obtener una solución (incluidas las pruebas) que encontrar algo nuevo y "mejor" y "mejorar" la base de código.

Entonces existe esta tensión: "hazlo correctamente" versus "haz el trabajo decentemente ".

¿Es esto algo que le sucede a muchos desarrolladores? ¿Es este un problema específico conocido? (¿Es un problema real después de todo?) ¿Realmente tiene que ver con niveles crecientes de experiencia?

Ah, y nota: todavía me gusta mi trabajo y me gusta conservarlo. Es solo que parece que siempre es interesante. - La parte de investigación se vuelve más pequeña a medida que aprendo la base de código y los conjuntos de problemas que enfrentamos con nuestra aplicación.

A menudo es arriesgado probar cosas nuevas. A veces nos metemos en problemas porque tendemos a hacer dos cosas:

1. Sobreestime lo útil que es lo genial / nuevo / elegante. Vemos un buen ejemplo, algún código lanzado en línea. Muy bien, pensamos. ¡Muy genial! En XI puedo hacer la tarea Y diez veces más rápido. Es claramente superior. Todavía no vemos todas las "incógnitas desconocidas". No nos hemos tropezado con los problemas que omiten los vendedores de lo nuevo. No tenemos suficiente experiencia en lo nuevo para ver las minas terrestres esperando en el camino.

2. Subestime la utilidad de las herramientas / framework / software / cosas existentes. A menudo no estábamos allí cuando se creó inicialmente el sistema actual. No apreciamos las delicadas compensaciones que se hicieron. Es fácil jugar al quarterback del lunes por la mañana en un sistema existente, pero funciona . Probablemente tenga mucha rareza debido a compensaciones muy específicas entre mantenerlo mantenible, funcionando y funcionando bien. Sí, claro, es raro. Quizás lo más importante es que el equipo es un experto en la rareza actual y sabe cómo solucionar la rareza. Conocen las minas terrestres y las trampas y las trampas que deben evitarse. De hecho, es precisamente porque vemos todas las verrugas en la forma actual de hacer cosas que incluso nos interesa jugar con cosas nuevas.

Pero no probar cosas nuevas y actuar de manera conservadora es probablemente aún más peligroso. Claro que debemos pisar con cuidado, pero si no descubrimos cómo construir la mejor trampa para ratones, ¡nuestros competidores un poco más dispuestos a probar algo nuevo vendrán y patearán los traseros! Actuar de forma conservadora y no evolucionar puede resultar en una fatalidad inevitable, especialmente en un mercado competitivo.

Entonces, sí, debemos equilibrar el mantenimiento y el envío de lo actual con cierto nivel de experimentación lúdica / educativa con nuevas formas de resolver problemas, teniendo en cuenta que muchas de esas nuevas formas son callejones sin salida, mientras que otros pueden ser rentables. OMI Esta es una buena razón por la que muchas empresas tienen un 20% de tiempo para jugar con cosas nuevas. Saben muchas veces que no funcionan, pero muchas de las ideas que surgen del 20% del tiempo se convierten en gangsters. Sin tiempo para jugar y experimentar, puede estancarse fácilmente como una empresa y realmente perderse.

Sucede todo el tiempo . Lo he dicho en otras publicaciones, pero la mayoría de las veces, no estás en el negocio de desarrollar código elegante, estás en el negocio de enviar un producto. Como tal, será difícil encontrar un gerente que esté dispuesto a asignar nhoras para que usted arregle algo que no está roto y que realmente (al final del día) no mejora en gran medida la experiencia del usuario final. Será tan difícil encontrar un gerente dispuesto a asignar nhoras para investigar (sin un objetivo final claro) que no sea "probablemente hay algo mejor que lo que se está haciendo".

Dicho esto, si descubrió que hay cuellos de botella en su aplicación al usar herramientas de creación de perfiles y tal, y puede cuantificar claramente la mejora esperada de la experiencia del usuario que su reparación traería, entonces debería (bastante fácilmente) tener tiempo para hacer un poco de I + D trabaje para optimizarlos utilizando técnicas que puede encontrar en varias fuentes.

Creo que parte de esto se reduce a tener experiencia y un conocimiento más profundo de cómo resolver con éxito algunos problemas.

Cuando eres nuevo, todos los problemas también son nuevos y debes investigar cómo resolverlos. Pero a medida que ha resuelto el mismo tipo de problema repetidamente, la necesidad de investigar disminuye ya que conoce una solución exitosa para ese problema.

Entonces, solo tiende a investigar los nuevos problemas o aquellos en los que el viejo probado y verdadero ya no funciona (ya que ha quedado en desuso) o está causando un problema de rendimiento o falla. A medida que comienzas a comprender un sistema complejo con más profundidad, sabes que no tienes el tiempo de manera realista para usar nuevas técnicas cada vez que aparecen y descubres por experiencia que muchas veces la nueva técnica no funciona hasta su exageración y crea más problemas de los que resolvió. Por lo tanto, se vuelve menos propenso a usar nuevas herramientas y técnicas cuando en realidad no las necesita para resolver el problema.

Pero menos inclinado no debería significar que dejes de aprender o nunca uses una nueva técnica, solo que eres más juicioso sobre cuándo son apropiadas.

Aquí hay algunos detalles:

1. Hay plazos : los programadores deben tener de antemano todos los detalles necesarios disponibles de las herramientas que está utilizando. Leer un sitio web, encontrar algo nuevo y genial, y luego usarlo en un entorno de producción es un gran no-no. Simplemente no tiene suficiente experiencia con la herramienta y, lo que es más importante, simplemente no tiene el tiempo necesario para comenzar a aprender algo nuevo. Si quieres algo nuevo y genial, apréndelo medio año o año antes de usarlo.
2. Asegúrese de conocerlo correctamente antes de usarlo : alguna herramienta nueva y agradable puede ser divertida de usar, pero buscar soluciones en Google y luego usarlas sin aprenderlas adecuadamente puede ser muy malo. Simplemente no tienes suficiente experiencia con eso. Si necesita googlearlo para descubrirlo significa que simplemente no lo sabe lo suficiente como para solucionarlo cuando se rompe la mitad del sistema.
3. Usar las cosas más nuevas no es hacerlo correctamente : las cosas nuevas no son tecnología probada. El año que viene, la tecnología probablemente haya desaparecido por completo, ya que eres el único en el mundo que la usa por más tiempo. Todos los demás notaron que simplemente no funciona. Se necesita mucho trabajo para evitar la bala de plata más nueva, pero vale la pena.
4. Concéntrese en las técnicas que son su conocimiento principal : cada programador conoce solo una pequeña parte de todo el conocimiento de programación disponible en el mundo. La parte donde el programador se siente lo suficientemente cómodo al usarlo es aún más pequeña. La parte que realmente funciona es aún más pequeña. Utiliza solo el conocimiento que has aprendido correctamente y sabes que funciona. Esto te hace programador más rápido y da como resultado un mejor código.
5. No lo modifique sin cesar : el código perfecto es un buen objetivo, pero esto no significa que primero escriba un poco de basura, y luego lo modifique sin fin para que sea incrementalmente mejor. Escríbelo perfectamente la primera vez usando todos los buenos conocimientos que tienes. Confiar en ti mismo. No confíes en el mundo. Nadie más sabe exactamente lo mismo que tú. Su opinión no importa. Eres el programador, necesitas que funcione. El mundo no puede hacerlo por ti. Una vez hecho esto, detente. No lo toques hasta que alguien se queje.
6. Dedique tiempo a aprender cosas nuevas : todos deben aprender continuamente cosas nuevas. Nuestro futuro depende de ello. ¡Solo rechaza usarlo! Aprenda cosas nuevas, pero no las use hasta que esté seguro de que realmente están funcionando. Tendrá la oportunidad de usarlo el próximo año, una vez que sea tecnología probada. O simplemente lo olvidaste, como todos los demás, solo quedan las cosas buenas ...
7. No pierda las cosas buenas : una vez que haya construido con éxito grandes sistemas y solucionado todos los problemas en ellos, y haya aprendido algunas buenas técnicas, lo peor que puede hacer es deshacerse de ese conocimiento y buscar algo nuevo. Ya sabes cómo funciona, qué problemas hay y cómo resolverlos. Tirarlo a la basura es solo una pérdida de tiempo.
8. Manténgase al día con la nueva tecnología : uno de los nuevos sistemas tendrá éxito. Tiene algo fundamentalmente mejor que cualquier otra cosa en el mercado. Simplemente no sabes cuál es la bala de plata. Si no lo encuentra a tiempo, su conocimiento quedará desactualizado. El mundo puede hacerle perder todas las cosas buenas al eliminar el acceso a los sistemas antiguos.

Sí, me ha pasado eso. Por lo general, debe hacer un análisis de riesgos sobre cuánto tiempo le costará aprender la nueva técnica, y puede recuperarse y usar una técnica más antigua en caso de que la nueva técnica no cumpla con las expectativas. Prefiero aprender nuevas técnicas cuando puedo, pero cuando la presión está activa y no puedo permitirme pasar el tiempo probando cosas nuevas que pueden fallar, me quedo con métodos probados y verdaderos.

En general, creo que el mejor momento para aprender nuevas técnicas es al comienzo de un nuevo proyecto. Por lo general, no hay demasiada presión y si encuentra algo nuevo que funciona bien, puede integrarlo fácilmente con el resto del proyecto en el futuro. El peor momento para intentar aprender cosas nuevas es en las últimas semanas frenéticas antes de un gran despliegue.

Sí, cosas nuevas perjudican la productividad.

Sí, por supuesto. Incluso para el mejor de los casos, las cosas nuevas requieren tiempo adicional porque no son familiares. A menudo puede costar mucho más tiempo.

No, las nuevas técnicas pueden mejorar la productividad.

Cualquier nueva técnica que le permita expresar más fácilmente la solución mejorará su productividad. Esto puede ser tan simple como pasar de grandes if-elseifcondiciones a una tabla de despacho.

Sí, puede dañar la productividad. A mi ex se le pidió que hiciera un trabajo de procesamiento de datos aburrido una vez, por lo que decidió que sería mejor escribir un programa largo para manejar los datos y luego ejecutarlo, lo que solucionaría el problema en segundos.

Le tomó una semana escribirlo, por supuesto, pero el problema se resolvió en segundos después de eso.

Creo que lo mismo se aplica a su pregunta: sí, puede aumentar su productividad al aprender cosas nuevas, pero aún así sería mejor aplicar su conocimiento existente a la tarea y, en general, hacerlo más rápido. A quién le importa encontrar y aprender una nueva biblioteca, si puede escribir la suya en menos tiempo.

No se olvide también, a menudo hacerlo de manera decente con las herramientas existentes es una mejor solución que poner las cosas nuevas. Cada vez que agrega nuevas, aumenta la superficie de mantenimiento que se requiere, lo que a su vez ralentiza a todos los demás (y puede haga que su código sea bastante desordenado: pienso en las capas de 'nueva' tecnología que pasaron al legado con el tiempo pero que aún están en nuestro código haciendo las cosas horribles. Mirando hacia atrás, hubiera sido mejor usar las viejas formas de C en lugar de agregar todo ese COM y todo ese VB y todo ese .NET y ahora también incluirá HTML)