¿Qué opina de la afirmación “Cuanto antes comience a codificar, más tardará el programa”?

La mención de Christopher de la máxima de los carpinteros (“medir dos veces, cortar una vez”) me recordó cuán inhibida estaba por cometer errores cuando me metí en la computación tardíamente a los 20 años.

Me llevó un buen par de meses darme cuenta del hecho de que el tipo de errores que podía cometer era extremadamente improbable de tener consecuencias permanentes e irreversibles. Durante esos dos meses, mi progreso fue dolorosamente lento debido a mis esfuerzos desproporcionados para evitar errores.

Una vez que finalmente me di cuenta (a) de que era poco probable que mis errores resultaran en un daño real, y (b) que la experimentación es a menudo la ruta más rápida para el descubrimiento, sin embargo, las cosas realmente despegaron.

Sin embargo, una advertencia: si bien esto funciona bien como una técnica de recopilación de información mientras aprende a programar o interactuar con una tecnología de software desconocida, una vez que comienza a trabajar en sistemas (incluso subsistemas) de cualquier tamaño apreciable, pronto se da cuenta de que la “plastilina la “técnica de desarrollo de moldeo (básicamente” seguir haciendo calamar hasta que finalmente parezca ser más o menos la forma correcta “) que fue lo suficientemente buena como para ayudarlo a completar sus tareas de codificación, realmente no escala muy bien. Algún tipo de vista / hoja de ruta / diseño de alto nivel es imprescindible.

Personalmente, creo que el diseño de software se parece un poco a la composición musical (que es mejor cuando estoy lejos de cualquier instrumento), ya que hago esto mejor lejos de la computadora. Caminar, andar en bicicleta o simplemente rumiar a medida que crezco gradualmente más y más como una ciruela en el baño, todo parece funcionar bien para mí. Hay un cierto placer en haber pensado en algo abstracto y luego (y solo entonces) probar en carretera que abstracción a través de la implementación. Todavía estoy aprendiendo, tan a menudo paso por alto (o simplemente subestimo la importancia de) alguna faceta u otra, pero de vez en cuando es como magia. Te sientas, implementas cada pieza con apenas un golpe de teclado desperdiciado, las piezas se unen por primera vez, y – lor ‘- la maldita cosa * simplemente funciona * desde recién nacido.

Esta es la versión del programador del antiguo credo del carpintero:

“Mida dos veces, corte una vez.”

Significan primero que debes aprender suficiente material que vas a necesitar y luego comenzar a codificar. pero personalmente creo que esto está de alguna manera mal. a veces solo tienes que ensuciarte la mano y continuar hasta que te encuentres con un problema y es cuando aprendes algo nuevo. pero este segundo enfoque necesita al menos un nivel mínimo de conocimiento sobre lo que estás codificando. no puede comenzar a implementar un algoritmo de cifrado por C antes de aprender a codificar en C.

Estoy de acuerdo con esa declaración, y la he experimentado en mis proyectos escolares. Cuando comienzo temprano, me tomo mi tiempo para planificar bien la estructura del código, investigo mucho sobre cómo se pueden implementar ciertas cosas para lograr un mejor rendimiento y elegancia. Hago muchas reescrituras hasta que estoy satisfecho. Sin embargo, cuando postergo y comienzo tarde, no me importa nada de eso. Solo quiero hacer algo que funcione. No me importa si el código parece basura, o si no es la mejor implementación posible en términos de rendimiento o mejores prácticas. Solo quiero mi calificación.

Desde el punto de vista de la ingeniería, este es un buen consejo. Pero desde una perspectiva creativa, a veces solo tienes que codificar cuando tienes la inspiración, independientemente del estado del diseño. Por otro lado, si está codificando en un proyecto con otras personas, entonces la necesidad de coordinar tenderá a obligarlo a retrasar la codificación hasta que se definan al menos las interfaces entre los módulos. En realidad, iteras, arrojas código, reescribes, etc. Así que me gusta la idea general, pero no subestimes el poder y el valor de un momento inspirado.

Bueno, obviamente no es literalmente cierto: en el caso límite, tomar un tiempo infinito antes de comenzar a codificar (es decir, no escribir el código en absoluto) resulta en escribir el código en tiempo cero (es decir, aparecer mágicamente de la nada).