No escribas código, primero resuelve el problema

Cuántas veces te ha pasado que estás programando y te quedas completamente atascado en lo que estás haciendo.  En esta situación es muy probable que lo primero que pienses es en mejorar tu código Ir a Google buscar en el stack overflow, esa porción de código que mejore lo que tú ya estás haciendo.

“En este post de stackoverflow voy a  encontrar el código exacto que necesito para solucionar mi problema “.

Y seguramente piensas, que lo que ha resuelto tu problema es el código exacto que encontraste en ese foro. Cuando la realidad es que hay ciertos patrones que has seguido para realizar búsquedas, que de alguna manera han llegado a ser más efectivas tus resultados. 

En 1984 George Polya, descubrió y compartió una estrategia brillante para solventar problemas. Seguramente George no compartió este conocimiento con la intención de ayudar al desarrollo de software. Pero a día de hoy es una estrategia de mucho valor para todos los que nos dedicamos al desarrollo de software.

Muchas ideas y pensamientos prácticos fueron aprendidos del libro “How to Solve It: A New Aspect of Mathematical Method”, escrito por George Polya.

Recomendación: Guia conviertete en desarrollador Backend

Resolver problemas no es un regalo.

Solventar problemas es una habilidad práctica, como lo puede ser la natación. Vamos adquiriendo estas habilidades, por medio de la imitación y la práctica. Con el ejemplo de la natación, cuando nadas, vas imitando los movimientos de otros nadadores, teniendo como resultado que aprendas a nadar.

En este sentido, si quieres desarrollar la habilidad para solventar problemas, tienes que imitar lo que otras personas hacen para resolver problemas. Aprender a solventar problemas no es una habilidad única para los superdotados.

Resolver problemas no es un tema intelectual

"Enseñar a resolver problemas es una educación de la voluntad. Resolviendo problemas que no le resultan demasiado fáciles, el alumno aprende a perseverar en los fracasos, a apreciar los pequeños avances, a esperar la idea esencial, a concentrarse con todas sus fuerzas cuando ésta aparece." - George Polya

Un factor importante al momento de resolver un problema es la determinación que tengas frente a esto. Seguro identificas este punto en tu labor como desarrollador de software.

Según George, un buen solucionador de problemas, debe ser una persona decidida, ya que en algunos casos, no tendrá ni idea de cómo abordar un problema y solventarlo.

¿Porque deberias aprender Javascript ? << te lo explico

El proceso que cualquier puede aprendera

Cuando te estás adentrando a un proceso para solucionar un problema, te recomiendo tengas a consideración los siguientes puntos:

• Comprender el problema.
• Diseña un plan.
• Ejecuta el plan.
• Retrospectiva y actualización

Comentar estos puntos, parecería algo supremamente sencillo y que cualquier persona lo puede ejecutar. Es un poco más difícil de lo que parece y vamos a adentrarnos en cada uno de los puntos.

1. Comprender el problema

"Es una tontería responder a una pregunta que no entiendes. Es triste trabajar por un fin que no se desea". - George Polya.

Es muy común querer saltar directamente a solucionar el problema, sin antes tener claros todos los elementos. Tener claro todos los factores elementos o criterios que involucran el problema te ayudará a tener una mejor comprensión.

"Hablar y pensar están estrechamente relacionados, el uso de las palabras ayuda a la mente. Algunos filósofos y filólogos fueron un poco más allá y afirmaron que el uso de las palabras es indispensable para el uso de la razón." - George Polya.

Una estrategia muy útil, es explicarle el problema a otras personas. Con esto, nos estaremos forzando a tener una comprensión, que sea lo suficientemente clara del problema como para enseñarselo a alguien más.

Entendamos las restricciones del problema.

En primer lugar debemos entender el problema en su conjunto. Una vez comprendido el problema, estableceremos mejores condiciones para juzgar los puntos en concreto que pueden ser más importantes. Habiendo examinado estos puntos importantes, vamos a tener mejores condiciones para determinar qué otros detalles merecen un examen más detenido. De esta manera tendremos suficientes detalles para descomponer el problema de forma gradual.

2. Diseñar un plan

Normalmente si conocemos el contexto de una situación es fácil tener un plan para solventar un problema. Por esta razón, al no tener idea clara del problema, diseñar un plan para solventar un problema, puede ser una tarea realmente dolorosa.

Inclusive te puedo asegurar que teniendo más claridad del problema, diseñar la ruta para solventarlo, se te podría complicar.

Para que esta tarea se te facilite , te recomiendo tengas a consideración lo siguientes pasos:

• No pienses en el código primero.
• Escribe tus ideas primero en papel y dibuja las posibles opciones favorables.
• Escribe tus primeras líneas de código, cuando tengas las solución en tu cabeza completa y la puedas explicar.
• No olvides el paso 1, y no ejecutes el paso 1 con el 2 en paralelo.
• Tu mejor herramienta al iniciar será el pseudocódigo.

Recomendación: Enfócate primero en entender los aspectos más básicos de tu problema y escala a lo más complejo.

Siempre recuerda que idear un plan y diseñar una solución no será tarea fácil, va a requerir mucha experiencia, la cual la puedes obtener de investigación en casos similares a los que estás tratando de solventar.

3. Ejecuta el plan

Ahora que ya tienes claro el problema y has podido diseñar una solución que por medio de tu experiencia e investigación te parecen la mejor. Es momento de traducir todo esto a código. Únicamente ten siempre algo en cuenta.

A pesar de que pienses que tu idea es la mejor para solventar el problema. Cuestionala en todo momento.

• Sustenta cada paso que estes ejecutando, con datos, 
• Prueba los componentes, 
• Evalúa tiempos de carga y rendimiento.

Al final de cuentas, en tu diseño de la solución debes saber que es el principio para generar tus documentos de requerimiento en desarrollo y también para la creación de los casos de prueba.

4. Retrospectiva y actualización

Nunca olvides que incluso las personas mas inteligentes del mundo cometen errores. ¿ Entonces porque pensarías que tu solución está libre de estos ?

Cuando hayas terminado todo el proceso de diseño y construcción, debes mirar atrás y hacer una retrospectiva de lo realizado, buscar errores y mejoras en tu solución. Esto no lo harás con la intención de frustrar y deshacer todo el trabajo. Es un proceso creativo que te permitirá consolidar el conocimiento implementado y mejorar tu proceso actual para solventar problemas.

No mirar hacia atrás y apreciar las ventajas y desventajas de tu solución es algo que ocurre mucho cuando las cosas se hacen con demasiada prisa.

Abre la posibilidad a explorar nuevas implementaciones en tu solución, ya sea para el proyecto que fue pensado o en otros proyectos.

Aprende más de programación:

Si quieres conocer otros artículos parecidos a No escribas código, primero resuelve el problema puedes visitar la categoría Consejos.