saber cuándo no codificar
Productividad,  Programación

La habilidad más importante que un programador puede aprender

No, no, no, no y no. Y no

Un gran NO. Claro como eso.

Todo lo que tienes que hacer es reunir esas dos letras y decirlo.

Ahora, digámoslo juntos. NOOOOOOO!

Buen comienzo.

Pero espera un minuto. Decir NO a qué y cuándo?

Bueno, este es el punto importante donde la mayoría de los programadores (incluso los senior) se confunden fácilmente.

Como programador, escribir código es la parte más importante de su trabajo. En su vida útil de programación, tendrá que lidiar con diferentes tipos de solicitudes. Cada solicitud te obligará a tomar decisiones difíciles. Que todo esta bien. Nada de malo con eso. Esto es lo que todos esperan de usted, como programador: escribir código.

Sin embargo, aquí hay una pregunta: ¿Debe escribir código cada que le solicita?

Esta pregunta nos lleva a la habilidad más importante que un programador puede aprender:

Saber cuándo no codificar es posiblemente la habilidad más importante que un programador puede aprender.

No podría estar mas de acuerdo. ¿ Por qué es eso ?

La programación es el arte de resolver un problema. Así que, naturalmente, los programadores son solucionadores de problemas, cuando tenemos un nuevo problema frente a nosotros listo para ser resuelto o cualquier otra razón que necesite de nosotros para escribir líneas de código, nos emocionamos.

Y eso está bien porque somos programadores. Nos encanta escribir código.

Sin embargo, el hecho de estar demasiado entusiasmados con escribir código nos hace ciegos. Nos hace ignorar algunos hechos importantes que nos puede causar problemas más grandes que tendremos que enfrentar en el futuro.

Entonces, ¿ Cuáles son esos hechos importantes que tendemos a ignorar ?

Cada línea de código que escribes es:

  • Código que debe ser leído y comprendido por otros programadores.
  • Código que debe ser probado y depurado (Pruebas unitarias)
  • Código que aumentará los defectos en su software.
  • Código que probablemente introducirá nuevos errores en el futuro.

Como Rich Skrenta escribió que el código es nuestro enemigo :

El código es malo. Se pudre, Requiere mantenimiento periódico. Tiene errores que necesitan ser encontrados. Las nuevas características significan que el código antiguo tiene que ser adaptado.

Cuanto más código tenga, más lugares habrá para ocultar los errores. Las salidas o compilaciones más largas toman tiempo. Lo que toma más tiempo a un nuevo empleado darle sentido a su sistema. Si tienes que refactorizar hay más cosas para mover.


Además, más código a menudo significa menos flexibilidad y funcionalidad. Esto es contraintuitivo, pero muchas veces una solución simple y elegante es más rápida y más general que el desorden de código producido por un programador con menos talento.


El código es producido por ingenieros. Para hacer más código se requieren más ingenieros. Los ingenieros no tienen costos de comunicación, y todo ese código que agregan al sistema, al mismo tiempo que amplía su capacidad, también aumenta toda una cesta de costos.

Es tan cierto, ¿verdad? Los programadores que te inspiran con su productividad y su mentalidad de codificación son aquellos que saben cuándo decir no y cuándo no codificar. El software que es fácil de mantener, que dura mucho tiempo y sigue ayudando a sus usuarios es el que no contiene líneas de código innecesarias.

El mejor código es aquel que no está escrito de todo y el programador más efectivo es el que sabe cuándo no codificar.

¿Cómo puedes saber cuándo no codificar?

Es natural emocionarse cuando estás trabajando en un proyecto y pensar en todas las características geniales que te encantaría implementar. Pero los programadores tienden a sobreestimar cuántas características realmente necesita su proyecto. Muchas funciones no están terminadas o no se utilizan, o simplemente hacen que la aplicación sea demasiado complicada. Debe saber qué es esencial para su proyecto para evitar cometer este error.

Comprender el propósito de su software y su definición central es el primer paso para saber cuándo no codificar.

Déjame darte un ejemplo. Digamos que tiene un software que tiene un solo propósito: administrar correos electrónicos. Y para ese propósito, enviar y recibir correos electrónicos son dos características esenciales para su proyecto. No puede esperar que el software también administre su lista de tareas pendientes, ¿no es así?

Por lo tanto, debe decir NO a cualquier solicitud de características que sea irrelevante para esta definición. Este es el momento en el que puede estar seguro de saber cuándo no escribir el código.

Nunca expanda su propósito de software.

Una vez que sepa lo que es esencial para su proyecto, estará consciente la próxima vez que evalúe posibles solicitudes de código. Usted sabrá exactamente sus requisitos para escribir código. ¿Qué característica se debe implementar? ¿Qué código vale escribir? Cuestionará todo porque sabrá exactamente cómo un código innecesario puede matar su proyecto.

Saber cuándo no codificar mantiene tu código base pequeño

Solo hay dos o tres archivos de origen cuando inicia su proyecto. Todo parece tan simple. Solo lleva unos segundos compilar y ejecutar el código. Sabes dónde encontrar exactamente lo que estás buscando.

Luego, a medida que el proyecto crece, cada vez más archivos de origen llenan su directorio. Cada archivo de código contiene cientos de líneas de código. Para organizarlos todos, necesitará varios directorios pronto. Recordar qué funciones llaman a otras funciones es más difícil, y rastrear errores requiere un poco más de trabajo. La administración de su proyecto se vuelve difícil y necesita más programadores para ayudar.

Al final, el proyecto se vuelve enorme. Añadir nuevas funciones es doloroso. Incluso hacer pequeños cambios lleva horas. La corrección de errores actuales siempre introduce nuevos errores. Empiezas a perder plazos …

Ahora, la vida es una lucha para ti. ¿Por qué?

Porque no sabías cuándo no codificar. Usted respondió SÍ a todas las solicitudes de funciones posibles. Estabas ciego Codificar algo nuevo hizo que ignoraras hechos esenciales.

Es como una película de terror, ¿verdad?

Esto es lo que sucederá si sigues diciendo SÍ a todo. Sepa exactamente cuándo no codificar. Elimina todos los códigos innecesarios de tu proyecto. Esto hará su vida más fácil y hará que su software dure más tiempo.

Uno de mis días más productivos fue tirar 1000 líneas de código

Ken Thompson

Sé que saber cuándo no codificar es tan difícil. Incluso para programadores senior. Tal vez, todo lo que escribí en este artículo es difícil de entender para los programadores junior y eso es totalmente correcto y comprensible.

Sé que acabas de comenzar tu viaje de programación y quieres escribir código. Estás muy emocionado por eso. Esto es bueno. Nunca pierdas esta emoción pero tampoco ignores los hechos importantes. Los aprendimos cometiendo nuestros propios errores. También cometerás errores y aprenderás de ellos. Pero al menos puede ser más consciente si puede aprender de nuestra experiencia.

Mantenga la codificación pero sepa cuándo decir no a la codificación.

Publicado originalmente en http://huseyinpolatyuruk.com

Desarrollador, Consultor, Arquitecto de Software, con mas de 3 años de experiencia. Certificado por Microsoft como especialista en .NET Interesado en la innovación y preocupado por la calidad del servicio.