Skip to main content

Cosas que los programadores prefieren al dinero


Muchos de los desarrolladores que conozco llevan programando desde el instituto. Tanto si era construyendo juegos en modo texto en C como creando una aplicación para el banquillo del equipo de fútbol de la escuela en Visual Basic, es algo que hacían por el desafío y, claro, por las chicas. Las mujeres aman a un hombre que puede hablar en ensamblador con su 8086.

Los graduados universitarios se enfrentan a una triste realidad cuando abandonan el vientre protector de la universidad y tienen que conseguir su primer empleo. Muchos de mis amigos encontraron trabajos donde pagaban una miseria al salir de la universidad, y les asombraba que la diferencia entre salarios iniciales de ingenierías y salarios iniciales de informática era casi el doble. Pero la mayoría de los ingenieros en mi clase no se hicieron ingenieros por el dinero; lo hicimos porque teníamos un profundo deseo de trastear e impresionar a nuestros amigos. ¿Ya os he dicho lo de las chicas?

El dinero es un factor de motivación para la mayoría de nosotros, pero asumiendo una paga mínima, ¿qué es lo que hace que ciertas compañías atraigan y mantengan a los desarrolladores mientras que otras los reciclan como si fueran papel higiénico?


Reflexionemos sobre ello:
  • Motivación: Una pequeña empresa de nuevas tecnologías en una sórdida oficina sin ventanas, los beneficios son nulos, prácticamente sin supervisión (porque el Consejero Delegado está en la calle, vendiendo el producto) y sin políticas de empresa (porque el Consejero Delegado está en la calle, vendiendo el producto). Pero el subidón constante del aprendizaje, el ser responsable, en ocasiones directo o único, del éxito o fracaso de la empresa, y la creencia en el crecimiento futuro de la empresa hacen a este trabajo mucho más deseable para muchos desarrolladores.

  • Arte: Lo primero en obviarse cuando el tiempo es limitado es la calidad y la sostenibilidad. Lo peor que se le puede hacer a un artesano es obligarlo a construir basura. Presentar un proyecto a tiempo pero sabiendo que es un montón de mierda se parece muchísimo al fracaso para alguien que se enorgullece de su trabajo.

  • Aprendizaje: Haz que un programador siga aprendiendo y lo tendrás feliz trabajando en un sótano sin ventanas, comiendo pan rancio de una bandeja en la puerta. Y nunca te pedirá un aumento.

  • Desafíos: Los desarrolladores aman los desafíos. Muchas veces he visto a programadores quedarse a trabajar hasta el amanecer para resolver un problema técnico sin que se lo pidan y sin cobrar horas extra. Los mejores desarrolladores son adictos a la resolución de problemas. Tírales un Sudoku en medio de un grupo de ellos y observa cómo se atacan. Enfrentados a la clase correcta de desafío, muchos desarrolladores no pararán hasta que esté resuelto, especialmente si requiere de una solución particularmente creativa. Enfréntalos a la clase errónea de desafío y se vuelven instantáneamente al Messenger a hablar sobre los números chungos.
    Los tipos erróneos de desafío son cosas como: "Arregla el código de este otro tío. Ya sabes, programó un sistema que es una auténtica chapuza y ahora nos hace falta arreglarlo y hacer que sea de buena calidad y mantenible. Ah, y tienes hasta mañana para hacerlo."

  • Tener voz: Los desarrolladores están en las trincheras, y son los primeros en saber cuando un sistema o proceso no funciona. Cuando un programador habla, alguien debería escuchar. Cuando varios programadores están diciendo lo mismo, alguien debería escuchar y actuar... y deprisa.

  • Reconocimiento: Como ingenieros nos encanta construir cosas que nos impresionen a nosotros y a nuestros amigos. Al menos a aquellos que sepan lo duro que es escribir un compilador de Perl. Desde cero. En FORTRAN. En un Vic 20.

  • Utilidad: La mayoría quiere sentir que de alguna forma estamos contribuyendo a hacer del mundo un lugar mejor, tanto tecnológica como socialmente. Algunos de nosotros podemos pensar que lo hacemos sólo por la tecnología, pero en el fondo de nuestras mentes nos vemos como parte de un gran plan. El construir algo que importa hace que un ingeniero sea más feliz, ya que gracias a su software de búsqueda de caminos para GPS, los automóviles ahorran un 30% de kilometraje y combustible.
    Por otra parte, construir un interfaz para una API repleta de errores que se usará un total de quince veces el año próximo no parece que importe demasiado. Copiar y pegar una aplicación entera y cambiar un puñado de etiquetas no es tan excitante como puede parecer.

  • Autoridad: “Cuando entré en mi nuevo trabajo a tiempo completo me sentía frustrado, por cada página que quería desarrollar tenía que tener una reunión con seis personas. Cualquier cambio en la base de datos requería de la aprobación de otras tres. Era una locura, y las aplicaciones tardaban cinco veces más en construirse. Frustrante. La autoridad de hacer decisiones relativas al proyecto sin necesidad de convocar reuniones es importantísima.”

  • Herramientas: A nadie le gusta desarrollar contra interfaces con errores, código basura, y modelos de datos mal diseñados. Un exceso de limitaciones heredadas mata la creatividad, requieren actas parlamentarias para modificarlas, y generalmente le quitan toda la diversión al desarrollo de software.

Comments

Popular posts from this blog

Programando un algoritmo de flocking / manada

Hace tiempo me interesé por los algoritmos de flocking o movimientos de manada. Esto pude sonar a chino, pero simplemente se trata de tratar emular los movimientos en conjunto de los pajaros, bancos de peces, ovejas…, vamos, cualquier conjunto de animales en movimiento. Las reglas de movimiento, a pesar de que puedan parecer complejas a simple vista, estan basadas sólo en tres simples leyes: Repulsión : Intentar no chocar con los compañeros. Alineamiento : Avanzar en una dirección semejante a la de tus compañeros. Cohesión : Acercarse hacia el centro del grupo. De la media de estos valores se extrae el vector director de cada individuo. VectorDirector = (Repulsión + Alineamiento + Cohesión)/3 Pues con esta idea intenté ayer programar una pequeña demo para implementarlo. Aquí os pongo un video de como esta quedando. Aún quedan por retocar varias cosas ya que algunas reglas no las estoy aplicando estrictamente. La parte más importante que no esta implementada es el

Himno de Teleco

Himno de la carrera de ingeniería de Telecomunicaciones, al más puro estilo Dragon Ball. Para echarte unas risas. Aviso de antemano: el humor de la canción está dirigido exclusivamente a estudiantes de Telecomunicaciones, ingenieros de ídem o a cualquiera que tenga unos conocimientos básicos (universitarios) sobre señales y sistemas. Vamos con Payán, todos a la vez a buscar con ahínco un sistema de transmisión. Sin duda será, convencido estoy, lineal, invariante y sin distorsión. Este mundo es como un filtro ideal donde hay escondido un suspenso en él. Como un filtro multicolor con un cero de transmisión, como una variable aleatoria con toda su gran inversión, el proceso empieza ahora, ¡vamos a filtrar, filtrar, filtrar, filtrar, filtrar! Hallaremos su covarianza y también su correlación, con la respuesta al impulso hallaremos convolución, el filtro sin distorsión será al fin nuestro, oh. Integrémoslo por Fourier, unidos a Gauss no hay que temer pues tenemos el DSP, ¡que no sirve p

Be a pointer, my friend

Empty your memory, with a free()… like a pointer! If you cast a pointer to a integer, it becomes the integer... if you cast a pointer to a struct, it becomes the struct... The pointer can crash..., and can Overflow… Be a pointer, my friend...