Ser buen programador NO paga!!

Desde hace tiempo vengo viendo como muchos programadores compañeros de trabajo y amigos se esfuerzan mucho por dejar sus programas perfectos, alineando el código perfectamente, siguiendo todas las buenas prácticas que tanto les ha costado aprender y asegurándose de que cualquiera pueda luego leer su código y tratando de estar siempre al tanto de la ultima tecnología. Se esfuerzan por ser "buenos programadores".

Sin embargo con los pocos años que tengo trabajando de esto y viendo las experiencias de otros que tienen incluso mas tiempo programando he llegado a una conclusión. Ser buen programador no paga, y si paga pues no paga bien, hace poco leí la "parábola de dos programadores" de Neil W. Rickert, que aunque es muy vieja no dejó de asombrarme por la similaridad con innumerables casos que he visto que encajan con la actualidad.

En resumen, en la parábola, Charles, es un programador novato que es contratado por una empresa para hacer un software, pasa un tiempo sin avanzar nada, pero justo cuando lo van a despedir lo encuentran codeando algunas líneas y al final termina el programa en menos tiempo de lo planeado y con todas las características solicitadas. El jefe revisa el programa y ve que esta muy bien hecho, pero que es demasiado sencillo, y cuando es hora de aumentarle el sueldo a Charles el jefe recuerda la mala impresión que tuvo de el al principio y solo le aumenta una miseria. Charles termina desmotivado y renuncia.

Mientras tanto al mismo tiempo en otra empresa contratan a Alan, un programador experimentado para hacer exactamente el mismo software, Alan pide dos programadores mas para armar un equipo de trabajo, hace un plan, agrega las ultimas tecnologías y al finalizar el plazo apenas van por la mitad del proyecto por lo que pide mas tiempo y dos meses mas tarde terminan. Pero lo terminan sin todas las características originales y no todo funciona de la mejor manera, pero el resultado es aceptable. Su jefe revisa lo realizado y ve un código ilegible un programa muy complejo y un equipo exhausto. Alan es felicitado por terminar un programa tan complejo y recibe un jugoso aumento.

Esta historia podría ser falsa, pero lastimosamente hay muchos de estos casos donde sucede lo mismo o algo muy parecido. Muy buenos programadores (algunos algo perezosos otros no) recibiendo salarios muy bajos e incluso terminan siendo recriminados por sus errores entre otras cosas, mientras que otros a pesar de no ser muy buenos programando, llegan a ser felicitados, son bien remunerados y reconocidos e incluso son promovidos rápidamente.

Cual es la diferencia que hay entre estos dos tipos? a mi punto de vista es algo muy sencillo. Ser buen programador no paga. Ser buen desarrollador mas o menos, ser un buen analista podría ser, pero si quieres una buena paga, posiblemente tengas que convertirte en un "buen vendedor".

Perooo... ¿Que no es casi lo mismo un programador que un desarrollador? no, definitivamente no, un programador es alguien que ve código, recibe una especificación, la programa, y mantiene el código. Un desarrollador es alguien que aporta en mas de una etapa de desarrollo de un proyecto, que incluso tiene conocimiento funcional y de negocio de la solución que está desarrollando y además interactúa mas con todo el equipo.

Ahora, por que aun así un desarrollador puede ganar menos que un buen analista o un buen vendedor? pues, según dicen por ahí "lo que importa  no es el producto mientras el vendedor sea bueno". Para muchos esta respuesta será obvia, pero si estás iniciando tu carrera posiblemente esto te resulte chocante e incluso ofensivo. Pero es verdad.

Para los usuarios finales e incluso para los jefes es muy dificil saber que es exactamente lo que haces, y fácilmente pueden pensar que lo que haces es muy sencillo. A mas de alguno le debe haber pasado eso de que el usuario solo quiere "un botoncito nuevo" en alguna pantalla y que se moleste cuando les digas que eso va a estar listo en un mes.

Lo que importa es lo que se ve.

Hace poco estuve en una empresa en la que no nos pasaron ningún requerimiento por meses a pesar de que nosotros insistíamos. Así que con mi compañero de equipo y yo, pasábamos viendo noticias o haciendo cualquier otra cosa desde las 9 hasta las 18, solo esperando que ya que en algún momento nos movieran a otro proyecto o nos despidieran ya que asumimos que no nos necesitaban o nos habían contratado nada mas por alguna razón política.

Sin embargo al principio de ese trabajo habíamos ayudado a otro equipo en un problema muy serio y habíamos solucionado un par de temas que no lograban resolver, con lo que nos habíamos hecho una muy buena reputación.

Y gracias a esa reputación, mientras veíamos a los chicos de ese otro proyecto cuando eran recriminados constantemente por su jefa, exigidos al máximo y humillados de vez en cuando a pesar de que trabajaban muy duro, a nosotros nos felicitaban.

Un día de esos de puras noticias en internet, esa misma jefa nos vino a felicitar por que había recibido muy buenos comentarios nuestros, que siguiéramos así y que nos extenderían el contrato. Y no, no era sarcasmo. Con mi compañero no pudimos evitar mirarnos y reír cuando se fue la jefa. Al parecer nuestra experiencia en el CV, además de la buena reputación ganada nos habían colocado como intocables a pesar que haber pasado meses nada mas calentando las sillas. Hicimos una buena venta.

En cambio en otros trabajos me ha tocado hacer el papel de los otros chicos, donde por mas que me haya esforzado en realizar un buen trabajo no lograba mas que algún "que bueno, por fin lo terminaste" o peor.

Cual es el error entonces? pues desde mi punto de vista el error en este caso es que el jefe, usuario o quien sea el que esta dandote ordenes no ve que es lo que haces, solo mira un resultado final que a veces ni siquiera es muy visible.

Vendete bien!

Parece mentira pero es así. Es un arte saber venderse como programador. Y aunque algunos lo podrían consideran poco ético yo lo considero algo necesario, quizá no en estos extremos pero siempre es necesario hacerse valorar. Muy seguido sucede que cuando alguien programa bien, a tiempo y sin quejarse, regalando horas extra y trabajando de mas, le sucede lo que le sucedió a Charles y a los chicos del otro proyecto: se asume que lo que hace es muy sencillo y por lo tanto no es muy valioso.

No es necesario llegar a ser Wally (Recuerdas el personaje en Dilbert?), pero hay que saber hacer ver a los usuarios/jefes/clientes que lo que uno hace no es sencillo (por que no lo es) y que aunque ahora podamos hacer algo en 5 minutos, tardamos 5 años para aprender a hacerlo en 5 minutos.

Ser buen programador no paga, al menos no por si mismo, hay que saberse vender y aspirar a algo mas. Hay que hacer relaciones públicas, crearte una buena reputación, saber explicar lo que se hace, saber decir "no" de vez en cuando y sobre todo saber cobrar lo que vale nuestro trabajo.

No nos conformemos con programar bien, vayamos mas allá y aprendamos a vendernos bien, aprendamos a cobrar bien y sobre todo aprendamos a hacernos valer.

Suerte!

El Config Freak

Hace un tiempo era normal ver al típico desarrollador al que incluso sus compañeros conocían como "code freak", aquel típico programador que prefería hacer todo su código en notepad sin importar el lenguaje que fuera o que herramientas tuviera a su disposición, compilaba desde consola y conocía de memoria todos los comandos necesarios para hacerlo, junto con cualquier parámetro que pudieran necesitar. Ojo, si no tenías un compañero que hiciera eso de seguro tu eras el coder freak de tu equipo.

Ahora eso es menos común al menos en ambientes laborales donde los proyectos informáticos han llegado a ser de tamaños inimaginables casi en cualquier industria, donde un simple sistema de gestión de clientes puede llegar a requerir grandes equipos de desarrollo junto con sus respectivos project managers, tech leaders, gerentes y hasta aguateros. Es difícil imaginar un proyecto de 2000 clases escrito en notepad.

Sin embargo debido a la creciente complejidad de estos proyectos ahora parece haber surgido una nueva moda: El "config freak guy", que es nada mas que lo que dice el nombre, un tipo dentro de tu equipo que está loco por las configuraciones del proyecto, que es el que ves bajando maven, configurando todo en xml o en archivos properties, que conoce todas las librerías que se han usado en el proyecto (que muchas veces las bajo solamente las bajo el, configuró y usó) y todos los pasos secretos necesarios para hacer un deploy exitoso en el servidor que sea, llámele weblogic, IIS, apache, o esos servidores que nadie conoce a excepción de el.

Y claro, es común ver que si este tipo falta al trabajo, cosa muy rara ya que igual que los antiguos code freaks nunca se enferman y aunque lo hagan prefieren pasar cualquier angustia antes de faltar al trabajo, pero si lo hacen nadie mas tiene idea de como hacer andar las cosas. Muchas veces no se puede ni realizar un deploy de desarrollo o una depuración sin que este tipo mueva sus palancas y apriete esos botones que solo el conoce.

Pero que pasaría si este tipo no estuviera en el proyecto? pues seguramente los demás desarrolladores hubieran buscado alguna otra forma de hacer las cosas, quizá en lugar de configurar ese ORM de última generación y esa capa de administración de webservices o ese robot automatizado para pruebas unitarias, mejor hubieran creado algunas clases que hicieran nada mas lo que necesitaban, quizá no tan eficientemente o tan correctamente como debería de hacerlo pero lo hace. Está bien esto?

Entramos en otra duda que vendrá para otro post, conviene programar correctamente o rápidamente? que es programar correctamente? como debe de ser la arquitectura de tu sistema para que cumpla con lo que se necesita? Por que configurar en xml en lugar de programar?

Bueno, la ultima pregunta quiza tenga varias respuestas, por ejemplo muchos pueden argumentar que tener la configuracion centralizada es una buea practica. En parte estoy de acuerdo, pero tampoco es mucha gran ayuda si es una configuracion que no puede ser cambiada nada mas que por los desarrolladores. Viene a ser nada mas como una separacion de codigo, codigo por aca, xml por alla, y al final se vuelve nada mas un paso adicional en el desarrollo que muchos terminaran saltando con tal de programar rapido.

Pero entonces?? cual es el punto de este post? pues no es decir que ser un config freak este malo, tampco que ser un code freak este bueno. Quiza lo mas que puedo sacar es que simplemente no hay que preocuparse tanto por temas que no tienen que ver con el negocio a menos que en serio valga la pena, esto aplicaria a patrones de diseño, configuraciones, codigo bonito, e incluso rendimiento en muchos casos entre otros aspectos mas.

Seria genial tener un framework que se encargara de todo eso de antemano (librerias mas usadas,  facil configuracion en desarrollo y en tiempo de ejecucion para desarrolladores, administradores e incluso usuarios y otro "glue code" o trabajo lateral)sin agregar mas complejidad al proyecto no? alguien conoce alguno?

No, I won’t fix your computer

En mi nuevo trabajo donde recién comencé, me llamó mucho la atención la camiseta  que un compañero tiene, una camiseta negra que dice en letras medianas “No, I won’t fix your computer”. Me pareció genial por que resume algo que todos los informáticos y sobre todo los desarrolladores quisiéramos gritarles a todo aquel “amigo” que viene de vez en cuando con la típica pregunta de si le podes ayudar por que su máquina no anda bien.

Y claro, tenemos que comenzar a idear en nuestras mentes todo un plan para decir que no y quedar mal, o explicar que nosotros no nos encargamos de arreglar computadoras (apostaría que ya en estos días ni siquiera  nos molestamos en revisar nuestros propios equipos tan seguido), pero al final todo ese plan termina, al menos la mayoría de veces, en nosotros revisando esos equipos y quedando como que somos tontos por hacerlo, o como "malos informáticos" por no saber como arreglar una computadora.

Ahora, ¿En que momento nos convertimos en los técnicos personales de nuestros amigos? Sin importar si sabemos o no arreglar computadoras, si somos desarrolladores, técnicos de mantenimiento, líderes de proyectos o documentadores, si trabajas con computadoras el mundo asume que sabes repararlas y que además, tienes la obligación de ayudarles a arreglar las suyas.

Para responder esa pregunta hay que hacernos otra: ¿quien tiene la culpa? lastimosamente a mi punto de vista, creo que somos nosotros mismos los responsables de que esto suceda. Tenemos la culpa cuando por ejemplo cuando no sabemos explicar al mundo que es lo que hacemos, o cuando por que nos gusta lo que hacemos comenzamos a hacerlo de gratis a todo el que nos lo pida, y no solo arreglar computadoras, no falta incluso el que le hace algún programita de gratis a algún amigo/familiar/colega que necesita algo y terminamos trabajando mucho, ya sea arreglando un "problemita" de alguna computadora en varias horas, o haciendo ese desarrollo, o peor aún, terminamos haciendo algo mal y ganándonos el enojo de esa persona que "amablemente" confió en nosotros para pedirnos ayuda.

Y si te ríes de eso es por que te ha pasado, y si te ha pasado vos tenés la culpa, y si vos tenés la culpa pues... bueno hay que hacer algo.

Y hay que hacer algo en definitiva, por que no sos el único afectado por todo eso, no, cada vez que ayudas a alguien a arreglar su computadora o a configurar algún programa o a limpiar algún virus o lo que sea, le quitas ese trabajo a un técnico de reparación de computadoras el cual si cobra por eso y posiblemente depende de esos trabajos para vivir. Mientras que tu solo ganas un par de falsos amigos gracias a eso (o hasta enemigos si metés la pata), y nada mas.

Ahh  eso no es todo, cada vez que lo haces, también haces que las personas a las que ayudas no valoren el trabajo de los informáticos, que nos trivialicen y que piensen que todo el que estudia esto se dedica solamente o a arreglar computadoras o a hacer videojuegos (y eso que ambas áreas ya son lo suficientemente complejas como para trivializar) y peor aún, que todo lo que hacemos es fácil y que cualquier mono entrenado lo podría hacer.

Entonces que hacemos? como decimos que no? Bueno, me acuerdo una vez en una fiesta, una chica atractiva le dijo a un amigo que es muy buen músico lo siguiente: "Que bien que tocas, por que no vienes a tocar a mi cumpleaños" y el le contestó a esta chica "Muchas gracias, y si puedo, pero cobro", la chica al principio pensó que era broma pero mientras se ponía pálida por que seguramente no estaba acostumbrada a ese tipo de respuestas le dijo "en serio" y este le dijo tranquilamente "Si, de esto vivo, soy músico y acá con mis amigos tocamos por diversión y sin presiones, pero si voy a algún lugar a tocar cobro ya que a eso me dedico", la cara de esta tipa fue épica, pero todos seguimos a lo nuestro.

Por que entonces nosotros no podemos hacer lo mismo? decirles a los que nos piden ayuda decirles sin presión "No, no me dedico a eso" o "Si, pero cobro tanto por eso"?? como dije antes, creo que es por nuestra culpa. Por que no tenemos el valor para decirle eso a quien sea. Pero tenemos que hacerlo y sin miedo!! nadie regala su trabajo por que entonces vos vas a regalar el tuyo!

Cuando haces eso te jodes vos, nos joden a los demás y quedan como tontos. Así que por lo menos asegurate que si lo vas a hacer cobra de alguna manera (y por que no, si se lo hacés a alguien atractivo/a que al menos te pague en especias no) por lo menos que te inviten a comer, algo! lo que sea! pero no lo hagas de gratis!! Tu dignidad, tu bolsillo y tus compañeros te lo van a agradecer.

Pago en especias... por que no?

Así que a la siguiente que alguien te pida algo parecido trata de por lo menos tener preparada una respuesta parecida a la de No, no te voy a arreglar tu computadora!