Como ser un mal programador. Por el geek, para amador.

Relataré la historia de mi actual trabajo y evidenciaré cruélmente al desarrollador, invitando al mundo a que no le dé trabajo.

Estoy muy alterado, me he tenido que fletar horas extra leyendo el código de programación en VB6 (desarrollado por una persona inepta y falta de sabiduría llamado José Amador Palomera Aguilar). Es muy frustrante no tener documentación pertinente a un programa, ése es un paso primordial en el desarrollo de cualquier software. No entiendo como una persona de tan malos habitos pudo haber cobrado tanto dinero, sinceramente, por el dinero que le pagaron habrían podido integrar una cosa muy chingona y muy bien hecha en cualquier framework de java con un manejador de base de datos DECENTE. Técnicamente el proyecto es un desmadre en el que se comenzó a hacer una versión con el fork de otra, desafortunadamente el programador jamás se imaginó que su chingadera de software fuera a implementarse en una empresa con tanto potencial como esta, la cual ha crecido en 300% en el último año. Lo que me lleva a la pregunta ¿quién recomendó que se comprara el código fuente del sistema?, ¿cuánto dinero le habrá tocado de esa venta?, ¿por qué no buscaron más alternativas?. Teniendo como fundamento la existencia de un programa, lo menos que se puede hacer para desarrollarlo es esperar que te den los documentos pertinentes, pero cuando esto no pasa te enfrentas a un mundo de posibilidades además de entrar en la cabeza de otra persona para entender su forma de ver las cosas y así poder desarrollar lo que ya dejó hecho. En ultimas fechas, éste ha sido algo mayor a un reto por que, jamás me imaginé que se pudiera hacer tanto desmadre con tan pocas probabilidades. Ahora estoy seguro de que existen cosas que son MUCHO peores a esta, por que uno nunca llega al final del tunel, es mentira que tocas fondo o que ves la lúz es tan pinche falso como dios. Después de esto, contaré a grosso modo el “método” de desarrollo que utilizó el imbécil aquel para desarrollar. Hizo un sistema con una base de datos en access 97 con menos de 10 tablas, en las cuales quizo hacer una tabla interelacionada así misma, pero tiene un deficit de banderas que honestamente son una pendejada, para cada movimiento, en lugar de hacer una tabla de detalle (como se haría en el mundo real), solo se dedicó a  insertar registros del mismo cambiando 1 letra por otra, la teoría de las bases de datos, según el manual de referencia de SQL publicado por Mc Graw Hill dice que un modelo de base de datos para que sea funcional, debe ser lo más parecido posible a la realidad, pero no, este imbécil, lo hizo como lo pensó en su pequeño mundo de materia gris inérte. Después de eso, hizo una serie de proyectos en visual basic 6, sobre los cuales fué agregando cosas y cosas, pero los hizo forkeados, la cosa es unos proyectos carecen de cosas y otros están detenidos y otros más están avanzandose. La cosa de esta pendejada es que hay 16 proyectos distintos que pudieron haberse consolidado en 1 y hacer una modularización de banderas o procesos para evitar tener 1000 cosas diferentes. Lo que me molesta de todo esto es que tengo que estar haciendo todo a la mera hora, por que hay 360 ejecutables de 180 sucursales y la verdad, es pésimo el código y la lógica.

Ahora con ustedes, los pasos a seguir para ser un programador PERFECTAMENTE IMBECIL.

1.- Desarrolla en un lenguaje que apenas conózcas. Si eres actuario, vale verga en que hagas, no importa.
2.- Baja código de internet y pégalo en tu proyecto sin analizar que hace. Chingue su madre, total, es pa’ índios
3.- No documentes, eso es para niños, tu eres un hombre.
4.- No modeles una base de datos, haz el mínimo de tablas en la base y no hagas diagramas de entidad de relación. Todo está en tu cabeza y eres un chingón.
5.- Inventa rutinas que no hagan nada, pero que ocupen harto espacio en memoria. Así igual conseguiras trabajo en Microsoft
6.- No modularices, escribe código lineal.  Eso hará que parezcas un gran programador y se vea muy aparatoso tu sistema.
7.- No sigas estandares en variables, no hagas caso de recomendaciones de libros estupidos, por que eso es de nenas.
8.- Usa siempre las mismas variables en TODO el proyecto. No tiene caso que hagas una variable por necesidad, ya que eso no le da sentido a tu programa y así no programan los hombres.
9.- Forkea todos los programas y quitales características funcionales de unos a otros, para que haya más desmadre y sólo tú puedas entender tanta mierda.
10.- Por favor NO HAGAS ningún tipo de manual, documento o diagrama alguno. Eso sí es de hombres, cuando entreges el proyecto, sólo cobra y largate.