¿Qué es lo que hago? II

En la entrada anterior sobre este tema explique que soy ingeniero en sistemas y por el momento me dedico a la programación. También intente explicar de manera general que es "programar", espero haberlo logrado =). A un programador también se le conoce como desarrollador.

El hacer un programa consiste en hacer que la computadora siga una serie de acciones en un orden específico, y que reaccione de cierta forma a lo que usuario le vaya proporcionando como información.

Esta serie de acciones y reacciones se pueden "dibujar" antes de introducirlos a la computadora, en una especie de planos que se le conoce como algoritmos, cabe señalar que estos algoritmos no solo son útiles en la programación, sino en cualquier situación donde se quiera dejar bien claro los pasos y acciones que se deben de seguir al realizar una actividad en específico y evitar que el que la haga la riegue y salga conque "es que yo no sabía y no me dijeron".

Haciendo una analogía se puede decir que un programador es un albañil que siguiendo estos planos , realiza "la casa" (el programa de la computadora). Siguiendo la analogía, un albañil conforme gana experiencia puede empezar a trabajar sin necesidad del plano, así se pueden hacer programas sin necesidad de hacer el algoritmo, pero si algo se nos pasa y lo hacemos mal, los resultados son igual de feos.

Sin embargo el algoritmo como tal no nos es suficiente para realizar el programa, ya que puede estar de forma muy general, dejando cabida a malas interpretaciones del programador o a partes incompletas.

Me explico, suponiendo un algoritmo para servir agua de una jarra en un vaso el algoritmo diria así: tomar vaso, tomar jarra, vaciar agua de la jarra en el vaso. Todos entenderíamos esto y lo haríamos sin problemas, pero este algoritmo deja sin especificar muchas cosas que nosotros damos por hecho pero que en una computadora no se puede, y aquí es donde está muchas de las broncas que ocurren al programar.

A lo que me refiero con esto es que si se quisiera hacer un programa que haga esta tarea tendría que ser mucho más explícito que el algoritmo que puse de ejemplo: extender brazo derecho, cerrar mano alrededor del vaso,sujetar el vaso, extender brazo izquierdo, cerrar mano izquierda alrededor del asa de la jarra, acercar vaso a la jarra... etc.

Como se puede observar, un paso intermedio que no se ponga como debe ser o que se de por hecho como en el caso del algoritmo y provocará un desastre, así que la programación tiene su grado de dificultad ( a diferencia de lo que el 90% de las personas cree).

Otro detalle que sucede es que en ocasiones uno como programador supone que las cosas saldrán siempre bien y que el usuario final del programa hará las cosas siguiendo siempre las reglas y al pie de la letra, ¡pues no es cierto!. Se debe de preveer siempre el peor de los casos y hacer alguna serie de tareas que se encarguen de solucionar el problema si algo sale mal por parte del usuario.

Regresando al ejemplo de servir agua en un vaso, todos suponemos erróneamente que el usuario siempre actuará bien, pero que creen, seguro habrá un usuario que agarre el vaso al revés, que se le suelte la jarra, que no dejará de vaciar agua cuando se llene el vaso, que no le atinará al vaso, etc., y si no preveemos todo esto, pues nuestro programa fallará y saldrán cosas mal. Preveer estos casos y saber como debe de comportarse la computadora para corregirlos es otra parte del trabajo que la gente no conoce y que los jefes por lo general no quieren reconocer.

La parte fea de la programación ya profesional (no a nivel de hacerlo amateur o en la escuela), es que al igual que el albañil, uno pasa deasapercibido si las cosas salen bien, pero si salen mal, toda la culpa es del programador.

Si un edificio queda bien, el mérito es primero de la constructora, luego del arquitecto encargado, si queda algo de crédito es del contratista y al pobre albañil que se estuvo partiendo el alma todos los días y que realmente fue quien hizo todo, pues ni se acuerdan de él. Pero si resulta que los planos eran un mugrero, la constructora eligio un lugar inhapropiado y quedó mal el edificio, la constructura se va contra el arquitecto, este contra el contratista y este contra el pobre albañil, que quedará ante todos como el culpable del fracaso.

Muchas veces desde que te dicen que es lo que hará el programa viene mal planeado y pues si te dan datos mal, tu trabajo saldrá mal, pero ¿de quién creen que será la culpa?, pero si sale bien, a pesar de que hayas corregido todas las tonterías que se hicieron en los algoritmos con los que tuviste que trabajar, pues el mérito será de todos menos tuyo.


Así la mayoría del reconocimiento (tanto profesional como monetario), se lo quedan los jefes y las friegas se las queda uno. Pero en fin, se siente bien cuando algo que sabes que salio de tu inventiva y tu esfuerzo queda listo y el usuario trabaja en ello y comienzan a verse resultados reales.


Otro detalle que comunmente sucede es que cuando el programa falla, todos se desentienden y quedas solo para arreglarlo, no importa que tu jefe no haya entendido lo que el usuario quería y haya hecho mal el esquema general, que el que realizo el algoritmo lo haya hecho con las patas, que todo lo que prometieron que haría el programa provoca más broncas que beneficios y por más que lo advertiste nadie te hizo caso, ahora eres tu solo (o el equipo de programación), el que debe solucionarlo todo y rapidito por favor.


En fin, programar es interesante, pero yo no lo haría si no me pagaran jeje, así que cuando cambie de trabajo, posiblemente deje de programar.