¿Qué va a pasar?

En solo tres pasos tu aplicación empresarial comenzará a ser una realidad

Registro
Escuchamos tus necesidades

Programar: ¿se trata solo de picar código?

PageLines-header-fondo-imagen-02.jpg

Detrás de la pregunta que da título a este artículo hay implícito una nota de monotonía asociada con el mundo de la programación. Pero la realidad y la experiencia nos dicen que en este sector la cosas cambian de forma muy rápida y todo escala a una velocidad de la luz.Esta cuestión da para un largo debate y se podrían escribir millones de líneas sobre el tema, pero he decidido darle forma de cuento, el cuento real de un programador que va de ser un novato absoluto a convertirse en un profesional que resuelve problemas en el mundo real.

"Cada día sabemos más y entendemos menos"— Albert Einstein

En verdad todo versa sobre cuánto tiempo le das vueltas al problema. Empiezas por los cimientos y vas construyendo a partir de ahí. Durante este proceso, a menudo te distancias para ver el plano completo. De forma reiterada, cambias tu atención para poner el foco en lo que más importancia tiene. Esto no solo es verdad para la programación, sino que lo es probablemente para cualquier otro aspecto en la vida. Voy a intentar poder ejemplificar esto desde el punto de vista del desarrollo de software.

Los primeros pinitos

Los cimientos en programación es cuando aprendes las construcciones del lenguaje, escribes programas tipo "hola mundo" y otros programas sencillos. El siguiente nivel es cuando solucionas algún tipo de problema usando un ordenador y que serían muy difíciles de solventar usando un papel y un bolígrafo. Por ejemplo, determinar la raíz cuadrada de un número gigantesco. Llevas al límite tus conocimientos matemáticos y tu sentido común para crear un software o un programa nuevo. Y te das cuenta que existe un límite a lo que puedes hacer con estas destrezas básicas.Dentro de tu repertorio como programador ya tienes dos herramientas: tus destrezas básicas como programador y tu sentido común.

La etapa de la frustración

Tras comerte mucho la cabeza para solucionar una serie de problemas pequeños, caes en la cuenta de que aún no has sido capaz de darle salida a los problemas más complejos y es hora dar el paso al siguiente nivel. Para poder dar el salto te metes en el mundo de los algoritmos. Los algoritmos no son más que soluciones a problemas ya resueltos. Empiezas a dominar algoritmos y estructuras de datos. Árboles Binarios, Búsquedas Binarias, BST, programación dinámica, gráficos, pilas, búsquedas, búsquedas prioritarias, conjuntos y demás materia.Ahora ya dispones de un repertorio y una caja de herramientas mucho más grande para enfrentarte a los problemas. Tiendes a trabajar partiendo de o modificando algoritmos y estructuras de datos para solucionar los problemas que tienes delante. Algunos temas que te parecían incomprensibles antes, ahora te parecen pan comido. Pero no todos.Entre tu repertorio ya dispones, pues, de estructuras de datos y algoritmos.

Descubriendo la productividad y practicidad

Pero incluso con esas herramientas, aún no puedes solventar todos los problemas a la hora de programar. Y es aquí cuando aprendes sobre las clases de complejidades P y NP. Son una clase de problemas que aún no se pueden solucionar en tiempo polinómico. Aprendes que cuando te enfrentas a una complejidad NP, es mejor evitarlo en vez de intentar solucionarlo. Aprendes a dejar de intentarlo, y a no desperdiciar tu tiempo y energía, en vez de trabajar para nada.A estas alturas como programador ya probablemente eres un tomador de decisiones ninja. No siempre sacas tu caja de herramientas para solucionar un problema programando, ya que primero ponderas si merece la pena atajarlo o evitarlo. Valoras la productividad, además de la destreza programando.

El mercado laboral, primeros contactos

Ahora consigues un trabajo y te expones al mundo real. Los problemas ya no son de juguete, empiezas a diseñar y desarrollar software para ayudar a las personas a superar problemas reales. Diseñas páginas web, aplicaciones de gestión, apps móviles, etc... Y te das cuenta después de un punto, que sería muy difícil de mantener el nuevo módulo que desarrollaste con tus destrezas actuales. Puede que se trate de un montón de problemas de diseño conocidos, denominados antipatrones de diseño en software. Y ahí caerás en la cuenta que , que tienes que aprender algo sobre la ingeniería del software. Interfaz, classes abstractas, herencia, composiciones, acoplamiento, cohesión, y ¿qué no?... Tela. Y entonces aprendes sobre estas cosas. Aprendes que ya hay soluciones de diseño a problemas ya existentes. Se llaman patrones de diseño.Tu repertorio ahora incluye destrezas ADOO (Análisis y Diseño Orientado a Objetos).En esta fase usas tus recién adquiridas destrezas de diseño para crear software y caes en trampa de tender a reinventar la rueda. Pero esto es algo bueno porque al final aprendes Dras cuando reinventas la rueda. ¡Todo el mundo debería hacerlo alguna vez en su vida! ;)

En busca de la rentabilidad

Pero el tiempo es finito, y encuentras que ya otros han hecho entornos sobre los cuales puedes trabajar. Entornos MVC como Djano o Cakephp, SDKs completamente funcionales como Android e iOS y APIs de AWS, librerías de código abierto como Boost para C++, peticiones para Python, de todo hay...Ahora antes de sentarte a solucionar un problema, te paras a pensar y investigar si alguien lo ha resuelto ya. Usas el código de terceros y partes de ahí. Te centras solo en la lógica de negocio de tu cliente y evitas picar código estándar en la medida de lo posible.

A los mandos de la nave

En esta fase ya eres un probablemente un ingeniero de software ninja. Empiezas a programar software con varios componentes, bases de datos, Android, iOS, web, logs, almacenamiento, etc... Las cosas se vuelven grandes y complejas. Tu principal tarea es tener bajo control la complejidad de los sistemas en general y intentar que no se te vaya de las manos. Ya has atravesado la barrera del paradigma de las aplicaciones distribuidas. Los sistemas de software se ejecutan en diferentes máquinas. Gestionar esta complejidad requiere destreza y experiencia. Te abstraes de los detalles nimios de implementación y pones el foco más en como interactuan entre sí las diferentes partes de tu software.¡Aquí ya eres todo un arquitecto de software!A estas alturas ya eres bueno desarrollando sistemas de software cuando los requisitos de la solución están claramente definidos. Eres bueno en "como hacer software".

Solucionador de problemas no resueltos

El siguiente paso es "¿qué software hacer?".Una buena aplicación de software que nadie usa es una inutilidad. No has ayudado a nadie a solucionar un problema. Tienes que buscar problemas no resueltos que pueden tener una solución usando tecnología. Aquí es cuando haces un esfuerzo real por solucionar los problemas existentes. ¿No te parece maravilloso?Es un viaje fascinante. Ahora dime, ¿sigues pensando que la programación se trata solo de picar código?Nota: este post está inspirado en una contestación a un hilo de este foro.