Demasiado tiempo, demasiada agua bajo el puente

¿Cuánto ha pasado? más de 10 años, y aquí estoy tratando de sacarle el polvo a un proyecto que ya dormido, y ahora diría oculto, bajo un exceso de contenidos en internet.

Parece chiste decir que no he abandonado, al menos la idea sigue  latente, como uno mas de mis muchos proyectos a medio empezar. Y efectivamente, no quiero abandonar este proyecto, aunque el enfoque haya cambiado demasiado respecto a la idea inicial. Las estrategias de búsqueda laboral han cambiado respecto a lo que eran hace 10 años atrás, partiendo por algo tan básico como el que la mayoría de las grande empresas delega sus procesos de reclutamiento a otras empresas, supuestamente empresas especialistas en reclutamiento, normalmente empresas de outsourcing, donde quienes realizan las entrevistas a los informáticos no son gente del área, sino sicólogos que, diciendo las cosas como son, muy rara vez (casi nunca) tienen idea del tema. Debido a lo anterior no es raro ver avisos donde requieran ingenieros comerciales (una carrera inventada en Chile, algo así entre un ingeniero industrial y un administrador de empresas) para puestos de análisis de datos; o bien soliciten 15 años de experiencia en Angular XP, siendo que Angular XP no existe (no que yo sepa) ni menos tienen 15 años de existencia.

Los años han pasado, y si,  tengo bastante más experiencia que en el momento en que dije tomar la decisión de escribir un libro orientado a la búsqueda de trabajo informático. Mas de 10 años que no han pasado en vano, pero que también han cambiado mis propias estrategias para la búsqueda de empleo. Mis últimos empleos fueron casi todos bajo la recomendación de algún colega con el que ya había trabajado anteriormente, y los pocos que conseguí por las mías, incluyendo donde estoy actualmente, han sido complicados. No complicados por la dificultad del cargo, sino por lo altamente competitivo que está el mercado, y porque querámoslo o no, podré tener más de 15 años de experiencia (desde 1995 haciendo cosas en el área TI), ya estoy "viejo" para los estándares laborales.

Encontrar trabajo para un profesional de más de 35 años es difícil, más para  uno pasado los 40, si nos hemos desempeñado bien en  nuestros trabajos anteriores, y si hemos logrado niveles de experticia importantes en  estas áreas, nos volvemos profesionales caros. Caros digo, también para el estándar de una industria TI nacional, donde pagar salarios que superen los 2 sueldos mínimos es mucho. Eso es un tema de  proyección y costos. Son pocas las empresas que consideran malo asumir el costo de tener a 3 recién egresados, o profesionales "Junior" como les dicen ahora, a cargo de proyectos sensibles, bajo los riesgos que  ello normalmente implica; versus tener a un solo profesional con más experiencia liderando y guiando a un equipo. Un profesional "Senior" no es precisamente barato, y sin duda también es un riesgo.

Me confieso mañoso, y excesivamente cuadrado. Y estoy agradecido de  haber pasado por las empresas donde he pasado, porque he tenido la oportunidad de trabajar, y en oportunidades de volver a trabajar, con gente de la que siempre he aprendido algo. Y empresas que han sabido darme la oportunidad, y la comprensión requerida para lidiar conmigo, si insisto, no soy fácil, sin embargo hago lo posible por hacer  bien mi trabajo, como debiera hacerse siempre. No hay excusas para hacer las cosas mal, o  a medias.

Así que con mucho que reformular, la idea del libro sigue en pie, y probablemente todo quede absolutamente obsoleto al momento del lanzamiento del libro.

Proyectos, riesgos y desafíos

Proyectos, riesgos y desafíos son 3 palabras bastante recurrentes en el vocabulario que he utilizado en este blog, y claramente lo seguirán siendo. Cada nuevo proyecto constituye un nuevo desafío (siempre, aunque sea un tipo de proyecto digamos habitual), y cada desafío va siempre de la mano de algún tipo de riesgo, en mayor o menor grado siempre existirá un riesgo.

El último tiempo, si bien las cosas no han cambiado tanto, si han cambiado, aunque no me termina de quedar claro si para mejor. Pero les quiero contar sobre 3 proyectos personales en los que me embarqué, y de a poco ir rescatando algunos elementos.

Electrónica y dominación mundial
Un gran/buen amigo de la infancia (A), aprovechando su especialización en electrónica me propuso participar en un proyecto suyo, en conjunto con otros de sus colegas. Mi contribución sería, como quizás puedan suponer, mi experticia en el área informática, puntualmente en materia de software y más particularmente en el área de interfaces para sistemas web.
El proyecto en si, muy ambicioso, sacaría provecho de mini procesadores ARM para conectarlos con distintos dispositivos, donde el único límite venía puesto por la imaginación.
Mi primera misión consistía en hacer funcionar unas interfaces de video múltiples en linux, hacer prototipos de las interfaces de usuario y administración, y hacer funcionar todo eso en el ARM. Básicamente sacar muestras del universo, clasificarlas y demostrar que la respuesta a todo es 42. Tocó justo en un período de crisis de tiempo, mucho stress, exceso de trabajo. Sumado a unas fuertes diferencias de opinión con "mi amigo", opté por excluirme de ese proyecto.
Cosas que aprendí

1. Si el trabajo no es en equipo claramente las cosas no van a funcionar.
2. El arrogante siempre va a creer que su verdad es absoluta. Al respecto, yo me reconozco arrogante, pero con el tiempo he aprendido a escuchar y reconocer quienes a los más sabios.
3. Siempre hay que saber escuchar.
4. Hay que entender y asumir que hay que disponer de capital para poder conseguir resultados. No basta la buena voluntad, los esfuerzos de medio tiempo, ni la visión de ganancias a largo plazo. Dicho muy en fácil "La del cagado no sirve"
   

Hoy en día estoy re-evaluando mi reincorporación a este proyecto. Ha pasado mucha agua bajo ese puente, y se han dado cuenta que sin inversión es prácticamente imposible sacar a flote una buena idea. Sin embargo la visión de empresa sigue siendo estrecha, tal cual la idiosincrasia de mi país la ha forjado.

La gerencia y el control de los plebeyos
Otro gran/buen amigo de la infancia (M), basado en necesidades muy puntuales de su empresa, y la experticia que ha desarrollado en el área de recursos humanos (RRHH), me planteó la idea de trabajar juntos en el desarrollo de una herramienta de software.
Su gran respaldo son varias presentaciones de herramientas de software similares, sobre las que detectó mucha falencias. Siempre bajo el prisma de sus necesidades particulares.
Mi misión era complementar su visión de experto en el área, transformando sus ideas a módulos de software. Lamentablemente recae en mi la responsabilidad de todo tipo de definiciones (funcionamiento, interfaces, etc.), a las que mi amigo solamente entregaría su opinión final "Está bueno/está malo".

Cosas que aprendí

1. Ciertos perros viejos no van a aprender trucos nuevos. Es casi imposible enseñar o transmitir una metodología a alguien que jamás ha seguido una, y que está predispuesto a jamás utilizar una.
2. Se necesita una mirada crítica para enfocar las cosas de la manera más completa posible, y no solamente la punta del iceberg, ie nuestras propias necesidades y requerimientos particulares.
3. No es necesario reinventar la rueda.

Hoy en día, si bien he postergado analizar el tema en cuestión en profundidad, he preferido darle otro enfoque. Busqué herramientas de código abierto preexistentes, que respondan al requerimiento general. Las voy a instalar y después de ver si logro convencer a mi amigo a que las revise, veremos que personalizaciones será necesario incorporar.

Web 2.0<= y la proyección de las comunidades
En este caso particular pierdo un poco de objetividad, debido a motivaciones muy personales relacionadas con un enfoque del proyecto y una visión de negocios, que no se dan en ninguno de los casos anteriores. Quizás por esto me extienda más contándoles de la historia detrás de esto.
Un amigo de una Comunidad en la que participo me envió un mensaje, solicitando mi ayuda en relación a evaluar los recursos necesarios para poner en marcha una Comunidad en internet. Como no era algo que me demandara mucho tiempo le di una respuesta bastante completa. En función de ello empezamos a conversar y me confió la idea de su proyecto, haciéndome partícipe de ella.

Tratando de ordenar las ideas, más si consideramos que estamos a 7 horas de diferencia, le transmití un poco de las metodologías de desarrollo que estamos usando en la empresa.

• Metodologías ágiles de desarrollo, con objetivos tangibles en el corto plazo.
• Mapas mentales colaborativos, utilizando la herramienta online mind42.com
• Wireframes colaborativos, utilizando un usuario común con gomockingbird.com
• Documento colaborativos, aprovechando Google Docs

Mi amigo (D), entendió el concepto detrás de estas herramientas, y lo ha sabido aprovechar. Poco a poco la idea va tomando formas mostrables, pero no es eso lo que despierta mi admiración, y por consiguiente me motiva en este proyecto. D tiene una visión de emprendedor, se informa, busca ejemplos a seguir, persigue objetivos, busca motivación. Y partamos por otros factores, es al menos 10 años más joven que A o M y ya tomó un riesgo que yo sería incapaz de tomar, se fue con una mano adelante y otra atrás (ie como llegó) lejos de su patria, con las limitaciones de idioma y las diferencias culturales. Allá se movió para salir adelante, y tomando prestadas y adaptando un poco sus propias palabras:

"Hace unos meses necesitaba financiamiento para vivir. Hoy necesito financiamiento para un PROYECTO GRANDE."

Simplemente me saco el sombrero.

Cosas que aprendí

1. No basta con tener la buena idea, ni con tener la gente adecuada, hay que tener una visión amplia del negocio y de la empresa.
2. El financiamiento es necesario y posible de conseguir. Quizás haya que trabajar mucho para conseguirlo, pero ese camino da mejores resultados que tratar de emprender con lo puesto. Es como remar y lamentar no poder comprar un motor para el bote, siendo que era cosa de preguntar por las opciones.
3. La visión de autosostenerse es más débil que la de ser exitoso.

Hoy en día quiero embarcarme en este desafío, ayudar a D en lo que mis competencias me permitan y aprender de él. Su entusiasmo me motiva, y esa motivación, que percibo como algo mucho más allá que las ganas de hacer dinero con el negocio, es el tipo de combustible que impulsa mis motores.

Yo comparto con A y M las ansias de no trabajar apatronado (bajo una empresa ajena, como subalterno) por mucho nás tiempo, pero siento que mejor que eso es transmitir un mensaje, marcar una diferencia, alcanzar un sueño.

Steve Jobs dió un discurso memorable en una universidad, y la esencia es

"Sigan sus sueños"

El escenario ha cambiado

Han pasado muchos meses. Si bien es cierto la idea de escribir el libro sigue en pie, el escenario ha cambiado. Claramente las cosas ya no son como hace 3 años atrás, y todo ha sido siguiendo un poco de la dinámica del último artículo.

El segundo semestre de 2009 fue un período marcado por un poco sano exceso de trabajo, más si consideramos que el equipo a cargo de sacar adelante todos los compromisos (mal llamados desafíos) eramos 2. Lo pudimos hacer, pero el desgaste no fue menor. Alguna vez se lo expresé a un jefe que tuve:

"Los ejercitos de un solo hombre tienen la misma efectividad que una hormiga contra una manada de elefantes."

Hoy la empresa avisa cambios, muy de la mano de los cambios que han afectado el país, cambio de geografía de mi país con el terremoto del 27 de febrero, cambio de gobierno con la ascensión al mando de Sebastián Piñera; cambios que hacen que incluso el libro posiblemente tome otro enfoque.
Este nuevo enfoque vendría dado por la transmisión de algunas cosas que he aprendido a lo largo de mi desempeño laboral, algo que va más allá de la búsqueda de empleos propiamente tal.

Debe ser de esa manera, y para ello debo además ordenarme. Hay muchos proyectos pendientes, y debo asignar a cada uno de ellos el tiempo y prioridad que corresponde.
Nuevamente tengo que decir "No he abandonado", pero las cosas SI han cambiado.

EAVB_FPLEKKHXVE

Pastelero a tus pasteles

Esta historia es de hace poco tiempo, cuando a un colega y amigo le informaron que sus servicios no serían requeridos.

Hace varios meses atrás nos vimos abrumados, como empresa, por una avalancha de nuevos proyectos. Si bién no son tantos, dado que cada vez somos menos, prácticamente nos vimos sobrepasados.

Empezamos toda una programación de actividades, de manera de interiorizarnos en las distintas tecnologías que usaríamos. Fueron meses entretenidos, de mucho aprendisaje, la meta era hacernos "expertos" en poco tiempo, y disponíamos de bastante tiempo para poder alcanzar un grado significativo de experticia. Sin embargo yo veía que mi colega poco a poco se hundía en un hoyo que el mismo cavaba. Partió medianamente motivado, pero se vió superado por el desafío, y lo complicado es que se notó, peor aún, el jefe lo notó.

Su fuerte claramente está en otra área, el problema es que tuvo 2 meses para documentarse, hacer pruebas y adquirir ese grado mínimo de experticia. Y no fue por falta de capacidad, sino, a mi parecer, por un asunto de motivación, fuera del tiempo que destinó a responder a negocios propios.

Pastelero a tus pasteles: Si tienes a un grupo de profesionales altamente especializados, dificilmente podrás esperar que sean expertos en otras áreas, y que se desempeñen de buena manera en áreas que no son las propias.

Pero..., si te dan el tiempo, el espacio y las herramientas para interiorizarte en otras áreas, distintas a la de tu experticia, no puedes desaprovecharlo, es más, NO DEBES desaprovecharlo. Tarde o temprano el cocinero jefe esperará que, si te dió todo para que aprendieras a hacer pasteles y no solamente pan, le rindas cuentas. Y por tu bién laboral, más vale que le hagas por lo menos un pastelillo.

Si estas conciente de tus limitaciones ten el cuidado de no aceptar desafíos que estén fuera de tu alcance. Como decía el Sr. Miyagi:

"Sólo lucha las batallas que sepas que vas a ganar, Daniel-san."

Es complicado, pero la muertes anunciadas no necesitan de una crónica previa.
Todo va en uno mismo.

Aprender a decir que NO

Han pasado muchos meses desde mi última entrada, demasiados meses diría yo, tantos que muchos deben creer que este es otro proyecto inconcluso de un computín ocioso que se cree lo máximo.

Han pasado muchas cosas también que me han hecho reformular muchos conceptos a priori de mi proyecto de libro. Así que debo empezar por algún lado.

El año recien pasado vivimos tiempos de crisis en la empresa, el potencial de proyectos se había dormido, sumado a las pocas intenciones de inversión de muchos de los empresarios en el país nos hicieron temer por todo. Sin embargo dijimos que no a algunas cosas, y de eso quiero hablar (no se que tan breve seré).

Lamentablemente uno se ve tentado a decir siempre que SÍ, no queremos dejar pasar ninguna oportunidad, pero debemos saber decir que NO.

¿Cuándo decir que NO? Hay muchas respuestas, pero lo recomendado es cuando derechamente nos vemos sobrepasados. Ante todo debemos ser sinceros con nosotros mismos, nunca podremos dar más de lo que podemos dar (en toda índole de cosas). Si no conocemos determinada tecnología, si los costos que van asociados a decir SI son superiores a la potencial ganancia, si notamos que el cliente en realidad tampoco sabe que es lo que quiere (lo que se traduce en que los 2 meses terminan siendo 6 y por la misma paga).

¿Cómo decir que NO? Diciendo que NO. La diplomacia no es precisamente una de mis virtudes, pero si la sinceridad. Nos veremos también tentados a dar miles de explicaciones, sólo hay que dar las justas y necesarias y nada que suene como una excusa que justifique, simplemente "Nuestra línea de experticia es distinta a la que nos indican en su requerimiento", por ejemplo, no voy a hacer sistemas de Inteligencia Artificial en Assambler si en realidad lo que se hacer son Sistemas Web.

No es pecado decir que NO, es preferible rechazar una opción y dar paso a otras que SI podemos cubrir, que aceptar todo y después no saber que hacer, bajo el riesgo de no hacer las cosas bién.

A veces incluso es necesario decir que NO cuando la propuesta no ofrece mayor proyección, no hay balance entre el precio y el esfuerzo que requiere, o bien no significa desafío intelectual (hay casos).

Al final uno es quien decide, pero siempre tomar en cuenta que no debemos sobreestimarnos.

Suerte.

A todo esto, ¿a alguien más le sucede que el editor de Blogger no le respeta el espaciado? Tuve que editar el HTML a la antigua (como en los viejos tiempos).

Para donde va la micro: ¿En qué me especializo?

Respondiéndole a Malw Dark, en relación a que lenguajes escoger para especializarnos debo decir que no es precisamente un tema simple. Esto es ya que el mercado de la informática tiene períodos erráticos donde muchos piensan en la muerte de este o aquel lenguaje.

Sin embargo mi respuesta natural a la pregunta es una sola:

Aprendan y especialízence en JAVA

Mis argumentos van básicamente sobre una cosa de mercado. Java ha demostrado ser un lenguaje sólido, tanto técnico, práctico como formalmente, su penetración en el campo de las TI es no despreciable y tienes algo cuyo valor agregado supera a todos los demás lenguajes: Al funcionar sobre máquinas virtuales es multiplataforma. No se vuelve necesario reescribir o recompilar el código para cada sistema operativo o cada máquina en la que quieras usar tu programa.

Muchos dirán que precisamente el hecho que la característica de ser multiplataforma de Java sea basado en máquinas virtuales hace que Java sea un lenguaje lento y pesado.

• Lento: Cada benchmark dependerá de quien lo haga. Yo he conseguido excelente resultados para operaciones muy pesadas. He logrado optimizaciones increibles usando rutinas de la librería Javalution, así que debo discrepar. Probablemente en un 386 las rutinas en Assambler muestren un rendimiento insuperable, pero seamos realistas. La idea es demostrar que nuestra mejor solución es precisamente mejor en nuestro contexto.
• Pesado: Evidentemente más pesado que Assambler, pero no más que C (consideremos la cantidad de librerías que necesitamos para hacer cualquier cosa), para que hablar del infierno de DLLs y dependencias de cualquier Visual .
  .NET , claro, el framework pesa tanto como la JRE de Java, que por lo demás cada vez es más liviana.

Tengo como rebatir casi cualquier argumento.

Pero como casi todo lenguaje, por si solo no es mucho tampoco. Se vuelven indispensables hoy en día conocimientos avanzados en HTML, Javascript (de hecho miren las librerías de JQuery), SQL y XML (idealmente con XSL).


La especialización se vuelve cada vez más atractiva para los empleadores, quieren tener expertos, lamentablemente buscan el experto en TODO y que además les cobre barato. Háganse valer, profesionales mediocres sobran, pero de los buenos hay pocos.


Muchos hubieran agregado Ruby y Python. Si bien es cierto son lenguajes robustos y muy poderosos, la realidad del mercado informático chileno apunta hacia Java. Cada cual en su propio país puede darse cuenta hacia donde va el mercado.


PHP, ASP, ASPX y lenguajes para web son algo por lo que todos debiéramos pasar. El problema es que en términos prácticos no aplicas casi nada de lo que has aprendido, modelamiento, programación estructurada u orientada a objetos. Salvo muy curiosas y raras prácticas que debo confesar no haber visto de manera cercana, los lenguajes para web son enemigos de los desarrollos bien hechos. Hay que conocerlos y dominar sus aspectos clave, pero no necesariamente convertirlos en nuestra especialidad.
No agregue JSP, pués lo considero incluido en Java.


Yo digo Java, vean ustedes que les dice una vista al mercado.
Espero que mi respuesta les dé una buena idea. Y como esto parece que funcionara sigamos con las preguntas.

Hagamos que la rueda gire

Estaba pensando en como movilizar este blog y hacerlo un poco más dinámico (en vista de mi falta de tiempo e inspiración), así que, honorables lectores, les propongo algo.

¿Qué les parece hacer el ejercicio donde me hacen una consulta y yo genero un artículo respondiéndola?

Obviamente lo haré según mis experiencia en dicha materia.
Considero que es una buena manera de hace que la rueda empiece a moverse.

Aunque no lo crean: No he abandonado

Si, a pesar de no actualizar los contenidos desde el 2006(!!!) no he abandonado la idea de escribir este libro.

Tienen que imaginar lo complicado que resulta encontrar la inspiración cuando se dispone de tiempo limitado. El mismo trabajo donde me desempeño, las obligaciones en el hogar y el mismo tiempo libre del que dispongo son a veces limitantes para este tipo de proyectos. Eso, sin contar otros proyectos que tengo pendientes.

No pierdan la esperanza, este blog no está muerto y mucho menos abandonado, simplemente está dormido, esperando despertar.