Superar la resolución lenta de problemas debido a un mayor conocimiento de lo que podría salir mal [cerrado]

Esto me ha estado preocupando por algún tiempo, y realmente agradecería el aporte de otros profesionales.

Breve descripción: comencé a programar cuando mis padres me compraron mi primera computadora en 1988 (a los 14 años, ahora tengo 39). Seguí un par de otras carreras antes de convertirme finalmente en un programador profesional en 1997. Florecimiento tardío, tal vez, pero así fue. Todavía estoy contento con mi elección, me encanta la programación y me considero bueno en lo que hago.

Últimamente, he notado que mientras más experiencia obtengo, más tiempo me lleva completar proyectos o ciertas tareas en un proyecto. Todavía no me voy senil. Es solo que he visto tantas formas diferentes en que las cosas pueden salir mal. Y las posibles trampas y problemas que conozco y recuerdo son cada vez más.

Ejemplo trivial: solía ser simplemente "está bien, escriba un archivo aquí". Ahora me preocupan los permisos, el bloqueo, la concurrencia, las operaciones atómicas, la indirección / marcos, los diferentes sistemas de archivos, la cantidad de archivos en un directorio, los nombres de archivos temporales predecibles, la calidad de la aleatoriedad en mi PRNG, la escasez de energía en el medio de cualquier operación, una API comprensible para lo que estoy haciendo, documentación adecuada, etc., etc.

En resumen, los problemas han pasado de "cómo hago esto" a "cuál es la mejor / más segura forma de hacerlo".

El resultado es que me lleva más tiempo terminar un proyecto que un novato. Mi versión puede ser sólida como una roca y tan impenetrable como sé cómo hacerlo, pero lleva más tiempo.

El ejemplo de "crear archivo" anterior fue solo eso, un ejemplo. Las tareas reales son obviamente más complejas, pero menos adecuadas para una pregunta genérica como esta. Espero que entiendas a dónde voy con esto. No tengo problemas para crear algoritmos eficientes, me encantan las matemáticas, disfruto de temas complejos, no tengo dificultades para concentrarme. Creo que tengo un problema con la experiencia y, en consecuencia, con el miedo a los errores (intrínsecos o extrínsecos).

Paso casi dos horas al día leyendo sobre nuevos desarrollos, nuevas técnicas, lenguajes, plataformas, vulnerabilidades de seguridad, etc. El enigma es que cuanto más conocimiento obtengo, más lento soy para completar proyectos.

Como tratas con esto?

No eres más lento en completar proyectos. Anteriormente, pensabas que tus proyectos de principiante se realizaban cuando en realidad no. Debe vender esta calidad a los clientes.

"Esta empresa podría hacerlo más rápido y más barato, pero ¿está realmente hecho? ¿O estarás cazando insectos durante años?"

Más allá de eso, necesitas conocer y aceptar el viejo idioma: "Perfecto es enemigo de lo bueno".

Parece que es hora de que te unas al lado oscuro: la administración.

No estoy sugiriendo que abandones la programación y te conviertas en gerente. Pero parece que toda la experiencia que ha citado hasta ahora ha sido de naturaleza técnica. En la simple operación de escribir un archivo, puede pensar en 10 aspectos diferentes que un desarrollador menos maduro nunca consideraría. No necesariamente es algo malo, pero ...

El lado oscuro tiene que ver con el valor presente. Se trata de hacer una inversión mínima para obtener la máxima ganancia (análisis de costo-beneficio). En los negocios, todo se reduce a cuánto me costará, la probabilidad de éxito, la probabilidad de falla, la probabilidad de falla espectacular y la ganancia potencial. Haz las matematicas; actuar en consecuencia.

Esto funciona igual de bien cuando eres un desarrollador: crea un archivo temporal, ignorando los permisos y las colisiones de nombres - 5 min. Ganancia neta, el resto del equipo puede comenzar a trabajar en cualquier código que dependa de la presencia de ese archivo. ¿Es una solución perfecta? Absolutamente no. ¿Te dará 99%, 95%, quizás 90%? Sí, probablemente lo hará.

Otra pregunta para hacer: ¿Cómo te sientes acerca de la deuda técnica? Algunas personas piensan que debe ser eliminado. Creo que esas personas están equivocadas. Al igual que en los negocios, la deuda técnica le permite pedir prestado "efectivo" o "tiempo" para entregar algo antes. ¿Qué es mejor: una solución perfecta en 2 años o un truco completo que un cliente puede usar y comprar en 4 meses? Cada situación es diferente, pero en algunas situaciones si espera 2 años, su cliente ya se registrará con su competencia.

La clave es administrar la deuda técnica de la misma manera que un negocio bien administrado administra la deuda financiera. Si no adquiere lo suficiente, no está obteniendo un rendimiento óptimo de la inversión. Si tomas demasiado, el interés te matará.

Entonces, mi consejo: comience a evaluar su trabajo en función de si está maximizando su valor en lugar de maximizar su minuciosidad. Y si practica esto, desarrollará la misma intuición que ya desarrolló en su área técnica.

Como nota al margen, recientemente comencé a hacer la técnica de pomodoro y me ha ayudado mucho. En lugar de seguir una tangente de una tangente, concéntrese en pequeños intervalos de tiempo y luego asigne pomodoros para futuros trabajos / investigaciones. Es sorprendente cuántas veces hice una nota para investigar un tema, pero una hora después, cuando llegó el momento, pensé: "Hay al menos otras 3 cosas que podría hacer con mi tiempo hoy, que son todas más valiosas".

Tuve el (probable) mismo problema hace muchos años, duró unos años y lo superé. Entonces, quizás le interese saber cómo lo logré, incluso si no estoy seguro de que mi camino también se aplique a usted.

También debería echar un vistazo aquí: Las siete etapas de experiencia en ingeniería de software Muestra que la productividad es en gran parte un efecto secundario del nivel de habilidad. Es posible que todavía esté en algún punto entre la etapa 3 y la etapa 4 de la tecnología que está utilizando actualmente (el dominio de las habilidades depende de la tecnología, puede dominar algunas tecnologías mientras aprende otras).

Ahora empiezo con el testimonio biográfico.

Un poco de contexto. Tengo 47 años. Comencé a programar a las 12 en los años 80. Mientras estaba en la escuela secundaria también trabajé como programador de juegos profesional a tiempo parcial. Básicamente no me dio tanto dinero, solo lo suficiente para comprar hardware, pero lo disfruté y aprendí mucho. A los 18 años comencé un aprendizaje formal de informática.

Como resultado, cuando cumplí 20 años, cada vez que comenzaba una tarea de programación, conocía muchas formas de resolver los problemas dados y era muy consciente de los muchos parámetros y dificultades, y los inconvenientes y límites de cualquier método.

En algunos momentos (digamos unos 26 años) se me hizo muy difícil escribir cualquier programa. Había tantas posibilidades abiertas que ya no podía elegir entre ellas. Durante unos años (que sea 6), incluso dejé de programar y me convertí en escritor técnico de noticias.

Sin embargo, nunca dejé de intentar programar. Y en algún momento volvió. La clave para mí fue la programación extrema, más específicamente el principio de simplicidad: "Escribe lo más simple que posiblemente podría funcionar".

Básicamente me obligué a no preocuparme por la eficiencia del código (ese era mi obstáculo principal, evitar diseños ineficientes), pero simplemente seguí el camino más fácil. También me obligué a preocuparme menos por los errores, y retrasar el manejo de errores a un momento posterior, después de escribir las pruebas que provocan el error (realmente eso es TDD).

Eso es algo que aprendí cuando estaba escribiendo. Cuando no sabía qué escribir, o sabía que lo que estaba escribiendo era malo . Solo sigue. En realidad escribe las cosas malas. Eventualmente lo corregiré más tarde. O si es realmente tan malo borrarlo y reescribirlo, pero es más rápido escribir cosas dos veces que escriben algo perfecto la primera vez.

Realmente es muy probable que un código que crees que es bueno en la primera escritura necesite tanta mejora como uno realmente malo.

Si sigues el camino de la simplicidad también obtienes una bonificación adicional. Usted acepta fácilmente eliminar / cambiar el diseño / codificación inicial. Obtienes una mente más flexible.

También tuve la costumbre de poner un comentario temporal en el código, explicando lo que no estaba haciendo ahora y tenía la intención de hacer más adelante cuando el código sería funcional en el caso de uso normal.

También asistí a un XP Dojo y practiqué katas de código con otros programadores para internalizar las prácticas de XP. Eso ayudo. Hizo que los métodos formales anteriores fueran instintivos. La programación en pareja también ayudó. Trabajar con programadores jóvenes da un poco de impulso, pero con la experiencia también se ve lo que no. Por ejemplo, en mi caso, a menudo los veo involucrados en diseños demasiado complicados y sé la pesadilla de diseño que puede conducir a ellos. Se fue de esa manera. Hizo que. Tenía problemas.

El punto primordial para mí es mantener el flujo. Ser rápido realmente está logrando mantener el flujo.

Ahora estoy de vuelta como programador profesional y creo que soy mejor y más rápido con una comprensión más profunda de lo que estoy haciendo. Practicando TDD Todavía puedo ser un poco más lento que cuando era un toro joven (y no probé nada), pero tampoco tengo miedo de refactorizar y ciertamente paso mucho menos tiempo depurando (casi nada de tiempo, hazlo menos del 10% del tiempo )

En resumen: superé mi bloque de código usando métodos ágiles (XP), buscando simplicidad, refactorizando y practicando para hacer eso instintivo. Funcionó para mi. No estoy seguro de que pueda generalizarse a nadie más.

En términos de nivel de adquisición de habilidades, aprendí principalmente a aceptar que cada vez que cambio la tecnología (aprendo un nuevo lenguaje, un nuevo marco, etc.) pasaré por una etapa cuando disminuya la velocidad. Esto es normal y eventualmente lo superará. También puedo compensar eso con una buena metodología y habilidades de programación de propósito general y no será tanto un problema.

Una parte importante de la programación es administrar y controlar la complejidad y, para mí, personalmente, es uno de los principales problemas. Si se ignora, la frecuencia de las deficiencias aumenta o, como en su caso, la ETA del software terminado aumenta dramáticamente.

La complejidad del software puede controlarse y gestionarse desde muchos niveles y formas diferentes, pero una buena regla general para obtener cierta perspectiva es esta: "La máxima prioridad de cualquier proyecto de software es la satisfacción del cliente, que es una función de sus expectativas".

En otras palabras, la complejidad del software depende en gran medida de su habilidad para controlar las expectativas de su cliente.

Cuando uno adopta esa visión, entonces dos puntos importantes se vuelven obvios:

1. las expectativas del cliente deben hacerse explícitas (en cualquier forma);
2. Las expectativas del cliente siempre se pueden modificar y eso se hace a través del arte de la negociación.

Su ejemplo es muy bueno, "simplemente escríbalo" frente a "una miríada de otras consideraciones". Piénselo: si alguien escribiera requisitos exhaustivos para ambas variantes, ¿puede haber una equivalencia en las características descritas o no?

Construir un F16 es diferente de construir un Cessna, aunque ambos pueden volar.

La respuesta simple es: acéptelo.

En todos los sistemas, se deben realizar compensaciones entre confiabilidad, robustez, seguridad, velocidad, costo de hardware, costo de desarrollo, tiempo de comercialización, lo que sea. No siempre estará de acuerdo con la forma en que el cliente hace esas compensaciones, pero usted no es quien toma esas decisiones. Todo lo que puede hacer es proporcionar una opinión considerada. El desarrollo de software cubre toda la gama, desde "mi página web personal" hasta "ejecutar el reactor nuclear", y el código debe escribirse en consecuencia. Si un bloqueo significa "volver a cargar mi página web personal", ¿a quién le importa si eso sucede? Pero si un bloqueo significa "Chernobyl", entonces su preferencia por un código sólido es algo casual para mi gusto.

Hay algunos clientes que aceptan felizmente el código de nivel "Prueba de concepto" y lo ejecutan en sus sistemas en vivo, y a menudo tienen administradores de sistemas que están acostumbrados a eso. IME sus sistemas generalmente no están disponibles durante una hora más o menos en el medio de la noche mientras ocurren un montón de reinicios programados. Pero han tomado la decisión comercial de que así es como quieren avanzar. Idealmente porque su campo es tan rápido que el código de alta calidad nunca estaría listo, pero a menudo porque no pueden ver el valor (si un sistema "simplemente funciona" nunca lo notan, por lo tanto, ese sistema no representa el valor para dinero). Si te molesta demasiado, trata de evitar esos clientes.

Mantenerse al día es el tiempo que todos tenemos que pasar, o al menos deberíamos pasar. A veces eso te llevará a trabajar, otras veces solo mantiene tu mente en buena forma. De cualquier manera, intenta disfrutarlo.

Parece que sus habilidades serían muy útiles para el desarrollo de sistemas de misión crítica de muy alta calidad, como aplicaciones relacionadas con finanzas / comercio, difusión, aeroespacial, defensa ...

Los errores en este tipo de aplicaciones son muy costosos y emplean a personas que piensan como usted, ya que puede cubrir todos los casos.

La verdad es que los sistemas modernos son cada vez más complejos. La computadora ahora es similar a ese juego "Jenga" donde tienes todas estas piezas confiando en muchas de las otras. Saque la pieza incorrecta y tiene un error, extraiga una pieza correcta / necesaria y aún puede producir un error. Cuanto más complejo sea el sistema, más tiempo pasará pensando en formas de hacer que su código sea más robusto y, con suerte, más seguro también. La velocidad sería buena, pero creo que la velocidad pasa mucho a un segundo plano en estos días cuando escuchas en las noticias que la compañía "XYZ" fue pirateada y se robaron 6 millones de números de tarjetas de crédito de clientes.

Es posible que sus clientes no quieran escuchar que su programa debe ser seguro, robusto, etc. Pero podría decirles que su automóvil no necesita cinturones de seguridad y bolsas de aire ni que su casa necesita cerraduras y puertas ... porque quién quiere escuchar todo ¿ese?

Si está pensando demasiado, está haciendo las cosas de la manera correcta, excepto que necesita elegir una estrategia que parezca "concreta" y simplemente seguirla.

Parece que eres consciente de tu tendencia a pensar en todo lo que puede salir mal.

Los desarrolladores cautelosos experimentados a menudo aprenden a seguir el mantra YAGNI, no lo van a necesitar, cuando intentan volver a un flujo de trabajo ágil, ágil y productivo después de atascarse demasiado en la maleza del análisis del modo de falla.

Sin embargo, si de hecho está escribiendo algo en un dominio en el que ese nivel de atención no es inferior al que exige el profesionalismo, entonces debe darse cuenta de que su "velocidad", su "productividad", en términos netos, se puede medir por cuánto bien ( o daño) que está haciendo a su empresa, a sus clientes y al conjunto de software o familia de productos que está creando o manteniendo.

Recuerda:

• Incluya el costo total de mantenimiento, el costo total de propiedad y el costo total de implementación y mantenimiento de soluciones cuando considere cambios en su enfoque. Ir más rápido y cometer más errores puede o no mejorar las cosas.

• Si trabaja en una buena compañía, probablemente pueda discutir esto en su propio equipo y con su propio supervisor, sin que sea un movimiento de limitación de carrera. Si no puede, ahora es un buen momento para descubrirlo y encontrar un nuevo trabajo.

Lo único que puedo ver es: "Te estás volviendo cada vez más valioso".

A medida que obtenga más experiencia, aprenderá sobre cosas que debe evitar, y esto es lo que lo hace mejor que los demás.

Una cosa que habrás notado es que tu código sería más seguro y más fácil de mantener ahora.

• Lo único que debe hacer es explicarle a su cliente por qué tomó tiempo y cómo sería útil para ellos.
• Necesita mostrarles la profundidad de su conocimiento.
• Debe decirles por qué lo hizo, qué hizo y cómo les importaría a ellos y a sus negocios.

Mi sugerencia sería concentrarse en esta parte.

en caso de duda, por defecto, citando mal a Knuth ...

"La optimización temprana es la raíz de todo mal."

Esto es lo que sugeriría, ya que parece que tienes un problema que tengo de vez en cuando ...

Lo que realmente funciona para mí ...

1. Escriba las pruebas unitarias, como si todo el código estuviera hecho.
   
2. documentar la interfaz.
   
3. implementar la interfaz

lo que realmente has hecho:

1. trabajar a través de los requisitos de las capas del modelo
2. realmente establece la división del trabajo, qué objetos son responsables de qué
3. trabaje en un entorno en el que pueda avanzar por el código de trabajo, lo que hace que las cosas sean mucho más rápidas y más precisas ...

también confíe en afirmaciones en el desarrollo temprano ... luego descubra qué remedios deben implementarse y no escribirá código que sea inalcanzable o difícil de probar.

Creo que debe cumplir con sus estándares de codificación, pero asegúrese de ser sincero con sus clientes. Muchos clientes no saben lo que se necesita / cuesta construir un buen software. Es parte del trabajo del desarrollador profesional educarlos.

Tanto si es ágil como en cascada, obtiene algún tipo de acuerdo del cliente sobre lo que esperan que haga la aplicación. Demasiados desarrolladores (OK, tal vez más vendedores) son culpables de sacos de arena . "No dijeron que querían un sitio web altamente seguro". En la mayoría de los casos, es porque no se les preguntó. "¿Te importa si tu sitio de comercio electrónico es pirateado?" Por supuesto que les importa y ¿por qué lo construirías para permitir que alguien penetre en la seguridad? Tienes que educarlos.

Solo asegúrese de hacer solo lo que el cliente le está pagando por hacer. Parte de su servicio es su experiencia. Los clientes esperan que conozcas las trampas sin que tengan que preguntar. Depende de ellos incluir el requisito. Es posible que desee transmitir a los clientes que quieren algo barato.

Piense en las consecuencias prácticas de un error en comparación con todos los demás problemas que deben resolverse.

Considere las siguientes consecuencias de crear un código mal escrito:

1. Toda la base de datos se descarga cada dos meses. 48 horas de tiempo de inactividad mientras se restauran las copias de seguridad.
2. Los registros de clientes se entrecruzan. $ 200 en pedidos se envían a los clientes equivocados por mes.
3. Una orden se atasca en un estado incorrecto una vez por semana. Ordene los barcos pero el almacén debe llamar al servicio de asistencia cada vez que ocurra.
4. Una vez que haya transcurrido aproximadamente dos semanas, la aplicación se bloquea y el usuario tiene que volver a ingresar 2 minutos de datos.
5. Una vez al mes, la aplicación se bloquea al inicio. El usuario tiene que matar el proceso y comenzar de nuevo.

El primero es obviamente inaceptable. # 2 - # 5 puede o no ser, dependiendo de la naturaleza del negocio. # 2 - # 5 debe evaluarse en el contexto de otros problemas que enfrenta el negocio.

Idealmente, # 2 - # 5 nunca, nunca sucedería. En la vida real, con prioridades en conflicto, las personas que firman su cheque de pago pueden querer que usted esté trabajando en otras cosas en lugar de escribir un código perfecto que nunca, nunca tenga un problema. No quedarán impresionados si el # 5 se arregla a expensas de no corregir un error más grave en otro programa.

La solución es crear una colección de bibliotecas con funciones de uso común que pueda reutilizar en todos los proyectos. Por ejemplo, tengo una biblioteca .NET StringFunctions.dll que hace cosas como codificación, cifrado, descifrado, evaluación de expresiones regulares, etc. De esta manera, no tengo que reescribir continuamente cosas que no cambian.

Tener un contenedor para las tareas de creación de archivos también tiene mucho sentido. Su biblioteca podría exponer un método llamado GetFile () que realiza todas las comprobaciones por usted y devuelve nulo o un archivo (o lo que considere útil).

Creo que debe aprender a decidir cuánto debe hacerse para cada proyecto. Algunos proyectos pueden ser triviales y realmente no es necesario dedicar todo ese tiempo a perfeccionarlos. No todo necesitará un cifrado sólido como una roca, ni todo se ampliará a millones de usuarios.

Escribir un programa que pueda escalar bien para más de un millón de usuarios tomará tiempo y experiencia que tiene ahora, pero si sabe que su aplicación no será utilizada por más de 1000 usuarios como máximo, no tiene sentido gastar todo esa vez perfeccionándolo.

Creo que esta es una etapa importante en su carrera de programación y ahora necesita pasar al siguiente nivel, que tiene que ver con la madurez y no con la programación. Debe poder decidir correctamente cuánto tiempo y código debería ser suficiente para un proyecto en particular.

Y como todo lo demás, puede lograr esto también con la práctica. Así que trate de decidir esto antes de comenzar un proyecto, en algún momento incluso cuando ya esté trabajando en él, con experiencia también lo superará. Puede haber algunos aciertos y errores al principio, pero con el tiempo lo perfeccionará (toma de decisiones, no código).

@Zilk, no soy un gran programador y llevo programando desde 1998. Incluso ahora estoy enfrentando este problema. Pero lo que me di cuenta es que, en última instancia, la calidad es importante. Si muero hoy, alguien debería poder recoger lo que estoy haciendo ahora desde donde me fui. Tales deberían ser los estándares de programación (Universal).

Me he mudado de desarrollador a arquitecto ahora. Pasar a la administración es cambiar la línea. Si quieres continuar con tu pasión, puedes moverte para convertirte en Arquitecto.

Inicialmente como Arquitecto Técnico -> Arquitecto de Soluciones -> Arquitecto Empresarial -> Arquitecto Jefe y así sucesivamente.

Como arquitecto, guiará a las personas hacia el éxito. Personas como usted que han estado programando durante décadas esos años de experiencia que puede utilizar para guiar a otros.

Como un pájaro más alto, vuela más tierra que puede ver, así es su experiencia.

Permítanme decirles que programar una implementación correcta es importante que programar una implementación incorrecta más rápido. Recientemente, uno de mis juniors programó algo mal y le costó mucho dinero a un banco. Por supuesto que habíamos entregado a tiempo antes, ¡pero no sirvió de nada! ¿Me dieron el papel de guía aunque el mismo joven hubiera codificado que el problema no hubiera sucedido? Estoy dando este ejemplo para enfatizar que dar una buena orientación también es importante. Algunos llaman a este trabajo como Consultoría.

Otra opción es: dejar de escribir código, en lugar de vender su experiencia para detectar los problemas de antemano.

En otras palabras, conviértase en consultor .

Muchas organizaciones están felices de pagar dólares caros (si no es el mejor precio) para que alguien detecte los problemas antes de pasar meses creando el código que los causa. Es bien sabido que arreglar un error en el diseño es mucho más barato / fácil que corregirlo después de que se haya codificado, probado y desplegado.

No escribirá tanto código, y es probable que se lo pierda, pero parece que las líneas de código reales no son su fortaleza principal, sino saber qué líneas de código deben escribirse y cuáles no.

Concéntrate en tus fortalezas.
(bueno, si eso es lo que disfrutas ...)

Mi mejor recomendación para ti es: bloques de construcción.

Cree un bloque de creación de archivos en el que pueda confiar siempre, cree uno para su API, deje de perder su tiempo escribiendo lo mismo una y otra vez. Piensa en cada problema una vez y arréglalo de una vez por todas.

Nadie se pondrá al día con eso, ciertamente no es el novato que pasa el 80% de su tiempo depurando el código que falla en casos de esquina que no entienden.

Sobre todo, no solucione problemas que no pueden suceder, como permisos incorrectos.

Si los permisos son incorrectos, algo ya está mal y debe solucionarlo en lugar de hacer que su programa sea a prueba de balas.

En algún momento, simplemente no debes dispararte en el pie en lugar de comprobar siempre si lo hiciste o no.

En lugar de dedicar tiempo a la documentación, dedique tiempo a que su código se auto documente y sea lo más breve posible. Reemplace todas esas funciones duplicadas. Reduzca su biblioteca, cambie el nombre de las cosas con precisión.

No seas demasiado duro contigo mismo. Está trabajando en una profesión de complejidad creciente, que requiere más inteligencia humana, conocimiento y experiencia que nunca.

El poder de procesamiento de la computadora se está ralentizando, tal vez pronto se estanca, lo que lleva a la necesidad de introducir chips multinúcleo, números accionados por gpu, paralelismo, etc. Solo hay tantos transistores que se pueden colocar en un chip.

Por lo tanto, los grandes avances actuales y futuros vendrán de los programadores: algoritmos avanzados y código más eficiente.

Si nos fijamos en GTA 4 y GTA 5, las diferencias son asombrosas. Pero ambos se ejecutan en el mismo hardware. Este es el resultado de una práctica de programación muy inteligente y avanzada que simplemente no era necesaria o no estaba disponible hace 10 años.

También podría significar que los programadores experimentados pueden volverse más valiosos en el futuro, al igual que otras profesiones, como la ingeniería, donde las ganancias máximas generalmente ocurren al final de la carrera.

Al igual que tú, comencé a programar a los 14 años, también cuando obtuve mi primera computadora (aunque había estado estudiando durante unos meses en ese momento). Sin embargo, ahora soy "solo" 33. :-)

Mi sugerencia es que, al desarrollar algo, tome cada una de esas preocupaciones (permisos de archivo, número de archivos en un directorio, etc.) y luego use toda su vasta experiencia para responder algunas preguntas al respecto, en este espíritu:

• ¿Cuánto tiempo llevaría manejar ese problema correctamente en su código?
• Si no lo manejas adecuadamente, ¿qué tan probable es que esto te muerda más tarde?
• Si te muerde, ¿cuáles son las consecuencias?

Armado con esas respuestas, un tipo tan experimentado no tendrá problemas para tomar una decisión acertada. ;-)

Es responsabilidad de los "veteranos" como usted hacer este tipo de requisitos, y eso implica identificar lo que puede salir mal y decidir a qué problemas potenciales debe prestar atención.

Conocer todos los criterios posibles mientras se desarrolla la aplicación es lo más importante en el desarrollo de un producto de calidad. Lo estás haciendo bien en esto. Una cosa que puede hacer es: puede clasificar el requisito en nivel de calidad y luego asignar el nivel con la fecha límite dada. De esta manera puede cumplir fácilmente con la fecha límite del proyecto.

En palabras de Edsger Dijsktra: "Si la depuración es el proceso de eliminar errores de software, entonces la programación debe ser el proceso de ponerlos". Simplemente está haciendo menos de lo último, por lo que debe hacer menos de lo primero. Es solo una cuestión de aprender a pasar el tiempo codificando correctamente. Todavía soy un programador relativamente joven (léase 20) y aspiro a poder codificar algo completamente correcto una vez. Una hora de planificación y 10 minutos de codificación es mucho mejor que 10 minutos de planificación, una hora de codificación y tres de depuración.