La importancia del título universitario: ¿Cada vez menor?

Esta es una idea con la que vengo danzando en mi mente hace buen rato. El disparador es sencillo: Veo muchos no-ingenieros trabajando por el mismo dinero que ingenieros, o incluso mayor. Evidentemente, al menos en este rubro, es la experiencia la que pisa fuerte.

El título cada vez importa menos, y casi nunca se conocen Magísters en sistemas (ingenieros que han completado una maestría). Son cosas que todo el tiempo parecen indicarnos que el estudio cada vez importa menos. Tampoco es inusual encontrar individuos que con apenas una licenciatura ya la están haciendo en grande, con una buena posición jerárquica o con un emprendimiento propio exitoso. De hecho, conozco una persona que ni siquiera teniendo nada ya tiene una empresa de carácter internacional teniendo menos de 23 años.

Creo que aquí es donde debemos preguntarnos. ¿Cuán importante es el estudio universitario? A decir verdad, soy uno de los que dicen que la universidad nos hace perder el tiempo. Sin embargo, no pienso parar hasta obtener mi título de ingeniero, pero es probable que de ahí en más no estudie para ningún otro título, pero sí me adentre en nuevas tecnologías y realice cursos de actualización, además de leer los nuevos libros. Tenemos que armarnos nuestro propio cronograma de estudio. Alimentar los que nos alimenta.

Es que realmente, la diagramación actual de las carreras de sistemas en las universidades argentinas es bastante pobre. Imaginemos un segundo que estamos los 5 años de ingeniería sin trabajar, y nos recibimos. Lo primero que se me ocurre pensar sobre alguien así es:

* No va a cobrar mucho porque es Junior en todo.
* No va a saber mucho de nada. Sólo lo básico de "algo". Ni siquiera de mucho.
* Podrá ser mal visto por más de un empleador, que considerará que no tomó su elección profesional en serio.
* En caso de orientarse a programación, seguramente tenga pocos conocimientos de arquitecturas y patrones de diseño, por más que los haya visto teóricamente en la universidad.
* Es una gran duda si puede trabajar en equipo o no.
* Pensaremos que no es una persona independiente, capaz de tomar decisiones propias, porque lo estuvieron manteniendo durante mucho tiempo y no se independizó y ni siquiera empezó aunque sea a trabajar part time. Es decir, qué esperar de alguien que no tuvo el suficiente interés para iniciar su carrera profesional a la par de su carrera universitaria?
* Seguro querrá cobrar más que un Junior porque tiene título, pero eso simplemente hará que pierda muchas oportunidades. Casi nadie paga por el título.
* Tiene que haber tenido compañeros de clase que trabajen y estudien al mismo tiempo. En sistemas es algo muy común. ¿Cómo es que nunca decidió arrancar también?

Son tantas interrogantes que como selectores nos veremos inundados de dudas y finalmente decidiremos no considerarlo como un candidato o hacerle una oferta mucho menor de la que el ingeniero esperaba, seguramente ofendiéndolo pero con motivo.

De hecho, en una charla con un estimado amigo y colega de profesión llegamos a la conclusión de que es muy probable que si no tuviéramos que consumir tanto tiempo en el estudio estaríamos mucho mejor posicionados económicamente. Quizás incluso hubiéramos podido desarrollar "esa idea" o "esa otra idea" que siempre nos rodea la cabeza. Arrancar un proyecto es la parte más difícil del mismo, especialmente si no tienes tiempo para ello.

Además, otra cosa que nos enseña el día a día es que tenemos que saber cómo vendernos para poder obtener mejores trabajos. Ya no se trata de si laburamos bien, de si no nos quejamos de ese monitor maltrecho que nos dan durante 6 meses para pagar derecho de piso, o de si podemos trabajar en equipo. Ahora es necesario tener amplias habilidades sociales para poder comunicarse con los clientes, compañeros de trabajo, stakeholders, project leaders, colegas y demás.

Encima el SMM (Social Media Marketing) cada vez toma mas fuerza, aunque en Argentina todavía no haya hecho boom. Dentro de unos pocos años nos veremos obligados a una carrera por convertirnos en celebridades de Twitter y llamar la atención de los Recruiters IT, porque eso es lo que vende. No importa nuestro título, sino lo que hacemos creer a los demás que somos.

De hecho este blog es un poco eso. Armar una imagen pública, aunque sea pequeña, pero presente desde ya, antes de que el SMM explote en el país y si no tienes un Facebook-Twitter-LinkedIn totalmente tuneado, con increíbles posts, mensajes, fotos y videos subidos, y con actualizaciones periódicas, entonces no podrás anhelar a ese puesto de Gerente de Proyecto en esa empresa que tanto te gusta y te paga el departamento de tus sueños en 6 sueldos.

Podré ser un poco exagerado, pero estoy convencido que desde hoy tenemos que empezar a ser expertos en Marketing en internet para poder realmente llegar lejos. Eso, o tener una gran idea y transformarla en un emprendimiento, donde de todas maneras tendremos que saber mucho de marketing para promocionarnos.

De hecho, como anécdota, en la empresa donde trabajo un cliente de uno de nuestros productos posteó "no sé donde" que nuestro producto era el mejor del mercado en "tal" rubro. Inmediatamente llegaron 3 o 4 clientes potenciales muy grandes pidiendo una reunión para ver una demo del producto.

Es así, el día de mañana crear dinero será igual que jugar al monopoly online. Haremos click en bloques, los uniremos y probaremos y desarrollarremos productos con apenas pensarlos, y sus precios se dispararán en segundos o podrán estrellarse enseguida, todo como un juego de estrategia que dura las 24 horas del día, donde sólo vemos números y tendencias.

Ah pero ese que se graduó de ingeniero sin estudiar apenas estará como desarrollador semisenior mientras que tú, el que decidió complicarsela estudiando y trabajando a la vez, y encima intentar adelantarse en la era del marketing social, estás moviendo el dinero a gusto y decidiendo cuánto pagarle a ese ingeniero que te entrega los sistemas en término, pero sin buena calidad.

Sí, un poco exagerado puede ser, pero esto es parte del blog. Irnos a las nubes e imaginar el futuro extremo. Si estamos preparados para el extremo, de seguro estaremos preparados para lo que realmente va a ocurrir.

Entonces no, el título no es importante. Pero nos gustaría poner "Ing." en nuestra firma de mail verdad? Bueno, he ahí su utilidad.

¿Qué nos motiva a trabajar mejor?

Me levanté a las 8:20 de la mañana, bastante tarde. Me bañé, preparé unas cosas y salí hacia la oficina. 10 minutos después me encontraba en ella, haciéndome un café y hablando con mis compañeros.

Empecé el día sin preocuparme por la lluvia, ni por llegar tarde, ni por el trabajo que tenía que hacer. Mi escritorio no es gigante como algunos que tuve en trabajos anteriores, pero sin embargo es cómodo y más que suficiente. Tengo un monitor CRT de 15, pero que anda perfecto. Y sin embargo me han prometido un LCD 17 para esta semana o la que viene.

El café y el azúcar son gratis. Para otros empleados que prefieran hay té y mate. Tenemos un comedor con bastantes mesas, cocina, microondas, heladera. No estamos ubicados en el centro por lo que no escuchamos colectivos, puteadas de tacheros, ni motos gritando por celular "Del centro a Gerli? ESTOY EN 5 MINUTOS!".

Mis jefes son buenas personas, flexibles, organizados, profesionales, inteligentes. Mis compañeros igual, sin importar si alguno es flojo para codear, o si a alguno le gusta meter lógica de negocios en SQL Server en vez de hacerlo en una capa del proyecto. Ni siquiera importa el hecho de que no hacemos diagramas UML.

Vaya, para ser un purista de la buena calidad no parezco estar molesto por esas cosas... Que después de todo son "motivadores".

No, hay muchos factores que llevan a la "tranquilidad" y a la seguridad que no tienen que ver con el dinero. Obviamente, el sueldo siempre es un 70% de nuestra motivación prácticamente, pero es importante tener en cuenta muchos otros aspectos. Tratemos de ver qué nos motiva en nuestro trabajo.

• El edificio. No es una boludez. Si nuestra oficina se cae a pedazos, hay mal olor, las maderas del piso rechinan, o hay poca luz eso nos desmotivará. Incluso podríamos sentir que trabajamos en un sótano o que no somos lo suficientemente importantes en la empresa. Casi como que nos hicieron un favor en ubicarnos en un lugar tan abandonado. No señores. Hay que trabajar con buena luz, en lo posible difusa y blanca, y en escritorios cómodos, con espacio para moverse. Nada que nos motive a querer estar todo tiempo en otro lado. La vista, la presencia de ventanas, y el espacio verde también es muy importante.
• Cocina y comedor. Esto no debería faltar en ningún lado, pero falta. Muchas empresas escatiman gastos a la hora de poner cómodos a sus empleados. Tener que comprar siempre afuera de la oficina insume un gasto muy importante, que debería ser tomado en cuenta a la hora de tomar un trabajo o no. Tener un comedor limpio y adecuado donde comer con los compañeros no sólo nos motiva y nos hace sentir cómodos, sino que también nos permite socializar con las personas con las que estamos 9 horas al día.
• Heladera. ¿Tan caro resulta poner una heladera para que tus empleados traigan comida? Vamos, admite que eres un tacaño. Permite que cada uno pueda seguir una dieta si quiere, o al menos traerse comida para ahorrar. Incluso, podrías de vez en cuando comprarles gaseosas o galletitas. Ojo, no compres tanto, porque sino puede convertirse en un gasto monstruoso. Pero considera que tus empleados necesitan comida para trabajar. Y es característico de la gente de sistemas de comer bastante :).
• Aire acondicionado. Nadie puede pensar con calor. Dejensé de joder.
• Computadoras capaces y rápidas. Quizás a un manager no le pasa, pero un experto o profesional de sistemas muchas veces vá más rápido de lo que puede la pc. Le tardan en cargar las aplicaciones o las consultas pesadas, o incluso internet. Si pretendes tener programadores muy productivos, otórgales con las herramientas para que eso sea posible.
• Si usas SharePoint, prepárate a gastar. PCs con 8gb de ram y 3.20 duo. Mínimo. Sin eso, tus programadores serán 10 veces menos productivos. Te aseguro que un desarrollo que podría hacerse en 1 día lo harán en 7.
• Cubiertos. Esto es pequeño pero ayuda.
• Sanitarios en orden. Creo que ninguna empresa decente puede tener sanitarios de estación de servicio. El día que entre a una empresa con un sanitario así, es el día que renuncio directamente.
• Limpieza. No sólo alguien que limpie la oficina sino que lave los platos, tazas, cubiertos y demáses. Tu gente está para trabajar y producir, no es un Gran hermano.
• Sé abierto a ideas nuevas y flexibles. No pretendas tener a tus empleados trabajando bajo la misma tecnología y de la misma forma durante 20 años. Promueve la mejora y la actualización. Otorga cursos e incluso becas. Interésate por el desarrollo profesional de tus empleados.
• No pierdas empleados por plata. Si un recurso es escencial o muy potente, no lo pierdas por unos meros pesos. Otorga bonos, facilidades, dias extra de estudios. Si quieres ser un gigante en tu rubro no puedes escatimar en profesionales de alta gama.

Son algunas cosas que se me ocurren que pueden motivar SIMPLEMENTE a que tus empleados se interesen por trabajar mejor. Y casi no toqué el tema de tecnología, relaciones humanas y demás, que son muy importantes. Pero quedarán para otro post.

Una nota sobre los generadores de código

A través de los años he conocido diversas empresas. Generalmente todas tienen su propio framework construído in-house, casi siempre por un programador que ya no está. Lo que me lamenta es ver siempre frameworks que nunca son robustos, ni están bien diagramados, carecen de patrones, y prácticamente no tienen documentación. Tener una nota sobre los frameworks es algo para un post totalmente distinto; incluso una serie de ellos.

Pero este pensamiento disparó en mí ponerme a analizar sobre los generadores de código. Muy pocas empresas están utilizando esto a su favor, pero las que lo hacen realmente tienen una gran ventaja sobre sus competidores. Quizás sea la falta de interés del management o de quienes "tienen la decisión" en ponerse a evaluar qué necesita un sector de IT para elevar su productividad. ¿No les ha pasado de tener una gran idea, o aunque sea alguna pequeña, que podría incrementar mucho la productividad, el manejo, la prolijidad, la calidad o aunque sea los tiempos de su trabajo? ¿Y que después la respuesta sea "No tenemos tiempo ahora"?

Ahí es donde muchas empresas hacen agua. Aquellas ideas que están bien elaboradas y consensuadas generalmente logran impactar de tal manera en un sector que lo cambian por completo. Por ejemplo, en mi primer trabajo de .NET desarrollé completamente las librerías de acceso a datos, manejo de errores, auditoría, seguridad y controles de usuario, y con ello pude incrementar considerablemente el tiempo en que se tardaba en desarrollar una aplicación.

Bueno, un poco me fuí de tema, pero creo que lo mismo pasa con los generadores de código. Incrementan nuestra productividad al eliminarnos de tareas tediosas y repetitivas, que ya están resueltas y podrían siempre realizarse por generador. ABMs, Consultas, Reportes, Impresiones. Son las opciones más comunes para empezar a pensar en un generador de código propio. Una herramienta que estoy evaluando para hacer esto es CodeSmith. Ojo, no la recomiendo ni tampoco digo que es mala, ya que apenas me estoy interiorizando en el tema. Pero quizás a alguno de ustedes les sirva para empezar a averiguar sobre el asunto.

Algunos pueden conocer el generador de código del Enterprise Architect (excelente herramienta si la hay). Sin embargo, suele quedarse corto y muchas veces terminamos haciendo bastante código igual. Es probable que todavía no haya descubierto la forma de ingresar reglas de negocio que se puedan auto-generar, aunque sea por OCL, pero no me parece que la generación de código sea, al menos por hoy, el fuerte del EA. Si no conocen esta increíble herramienta de UML es hora de que la conozcan: Enterprise Architect.

En fin. ¿Podrían los generadores de código ser una buena herramienta para tu empresa o sector? Por supuesto. Ponte a revisar qué tareas son repetitivas y cómo se podrían automatizar. Fíjate qué es lo variable en ellas y analiza cómo configurarlo. Busca herramientas o evalúa si hacer tu propio soft de generación de código. Quizás usando templates o podrías hacerlo todo por código. Obviamente el approach de templates es mejor pero puede resultarte más costoso en tiempo para desarrollar.

Mi consejo final es.

* Para desarrolladores: Promuevan sus ideas y defiéndanlas. Refínenlas y asegúrense de que están seguros de que funcionarán. Finalmente, busquen el argumento desde lo económico y productivo. A menos trabajo en tareas repetitivas, menos tiempo de desarrollo de grandes sistemas, por ende mayores ganancias y competitividad.

* Para project leaders, project managers, gerentes de proyecto: Evalúen si poseen los recursos humanos para encarar un proyecto propio de generación de código. Sino, al menos dediquen un tiempo a evaluar las diferentes herramientas. Recuerden, salvarán tiempo que se convertirá en dinero que encima les quitará trabajo de encima.

* Para gerentes y managers por encima de IT: Recuerden que la empresa se sostiene gracias a sus procesos, ya sean de Marketing, Ventas o Sistemas. Traten de ver si pueden optimizarlos o al menos asignar un poco de tiempo a dicha tarea.

Esto simplemente fué una especie de brainstorming. Disculpen si por momentos mezclé temas o soné un poco confuso :).

Au Revoir

.NET - Obtener el nombre de un método dinámicamente

A veces encuentro código donde los programadores hardcodean el nombre de su método por todos lados. Quizás por motivos de auditoría, o lo pasan por parámetro, etc. Los más osados pasan ese literal a una constante. Pero nunca pasa de eso.

¿Qué tal si pudiéramos obtener dinámicamente el nombre del método en el que nos encontramos? Bueno es bastante más fácil de lo que pensamos, y se puede obtener de varias formas.

Una forma es usando reflection:

string MethodName = System.Reflection.MethodBase.GetCurrentMethod().Name;

Y la otra es usando el objeto StackFrame:

string MethodName = new StackFrame(0).GetMethod().Name;

Bastante simple no? Sin embargo, a veces no queremos saber el método en el cual estamos sino el método que nos invocó. Esto se puede resolver fácilmente con un StackFrame.

string MethodName = new StackFrame(1).GetMethod().Name

Muy simple :). ¿Para qué podemos usar esto? Algunos usos simples son:

• Auditoría
• Si obtenemos los métodos, podemos obtener sus parámetros y sus valores. Es excelente información para armar todo un ruteo tras una Exception.
• Remover literales y constantes =)
• Cualquier uso que se les ocurra!

Fun Coding!

.NET - Debuguear una aplicación de Windows Service sin hacer deploy o instalar

Esto es algo bastante común que les debe haber pasado. Empezaron a diseñar y codear su primera aplicación Windows Service y cuando finalmente están listos para probarla se dán cuenta que no pueden debuguearla como si fuera una aplicación consola.

En fin, veamos una manera sencilla para poder debuguear un Windows Service.

Cuando creamos un proyecto de este tipo, lo primero que notaremos es la flamante clase Program en el archivo Program.cs con el método Main que es el punto de entrada de la aplicación. Desde aquí veremos que se llama a ServiceBase.Run que nos permite ejecutar una o varias instancias de nuestro servicio windows dentro de un mismo proceso. Por default, el código que aquí aparece correrá una sola instancia.

Pero hay un problema, el método ServiceBase.Run no funcionará en un ambiente de DEBUG debido a que este método registra el ejecutable en el Service Control Manager quien ejecuta un comando de start sobre nuestro servicio. En fin, no sería una solución agradable poder hacer un IF que nos permita conocer si estamos en DEBUG o no? Bueno, miremos el siguiente pedazo de código:

#if (!DEBUG)

    ServiceBase[] ServicesToRun;

    ServicesToRun = new ServiceBase[] 

    { 

        new MyService() 

    };

    ServiceBase.Run(ServicesToRun);

#else

    MyService service = new MyService();

    service.Initiate();

    System.Threading.Thread.Sleep(System.Threading.Timeout.Infinite);

#endif

No estoy inventando sintaxis. Estas instrucciones antepuestas con un # son lo que se llaman Directivas de Preprocesamiento que nos permiten establecer qué codigo debe ser compilado en tiempo de RELEASE, además de otras cosas útiles que pueden chusmear en el link.

En nuestro caso lo que estamos haciendo es preguntar por la variable DEBUG (ahora la vamos a explicar también, aunque es bastante obvia) y "expandir" nuestro código en base a eso. Si corremos el Windows Service desde el IDE en configuración DEBUG ingresaremos a nuestro método Initiate de nuestro servicio, sin pasar por el OnStart ni por el ServiceBase. Para que esto nos sea útil tenemos que agregar un par de cosas a nuestro servicio. No, el método Initiate no existe en tu servicio, lo puse yo.

Veamos antes que todo lo de la variable DEBUG. Esta es simplemente una variable definida por código que no manejamos nosotros, que nos indica si estamos en DEBUG o no. Bastante simple eh? Entonces podríamos agregar interesantes códigos que sólo se ejecuten en nuestras depuraciones.

Ahora, esto así como está no funciona porque ese método Initiate no existe. Veamos qué le hice a la clase. Agregué un método Initiate que llamo tanto desde mi código de DEBUG como desde mi OnStart en el servicio. Entonces queda algo así:

protected override void OnStart(string[] args)

{

    Initiate();

}

Como podrán entender, simplemente puse toda mi lógica de inicialización en el Initiate en vez de en el OnStart y nada más. No podemos llamar a OnStart directamente porque éste método es Protected. Como nota aparte, noten que el OnStart recibe un array de strings como parámetro. Éstos son argumentos que puede enviar el Service Control Manager a nuestro servicio. Puede resultarles interesante jugar con esto.

Fun Debugging!

.NET - Valores enum como flags de bits

Una vez que entendemos el uso de los ENUM pensamos que eso es todo lo que hay. Sin embargo, en algún momento caemos en alguna instrucción o con algún componente que parece sumarlos, restarlos, y combinarlos con operadores que no conocíamos. Bueno, este es un conocimiento que un semi-senior no puede desconocer, y si eres Senior y todavía no lo conoces entonces preocúpate un poco :).


A veces nos gustaría usar un enum como si fueran flags. Es decir, que hipotéticamente tendríamos la colección de ceros "0000" y cada cero es un switch, donde un 1 representa encendido. Por ejemplo, 0101 significa que encendimos los flags 2 y 4. Esto podría ser útil para reemplazar variables booleanas en algunos casos.


Arranquemos con enum común:


public enum ExportTypes
{
   None,
   Text,
   Excel,
   CSV,
   JSon,
   XML
}


Copado. Representa diferentes tipos de exportación para algo de nuestra aplicación. Sin embargo, teniéndolo de esta forma sólo podemos tener un tipo de exportación a la vez. ¿Qué hay si quiero hacer tanto JSON como XML a la vez? ¿Realmente es necesario que ejecute una rutina dos veces con parámetros diferentes? Imaginen sino, un servicio de Windows que recibe por MSMQ mensajes XML para procesar exportaciones. En este caso recibiría información y el tipo de exportación JSON. Y luego para hacerlo con XML lo tendríamos que mandar todo de nuevo. Pues no, podemos mezclar los enum utilizando el atributo Flags.


[Flags]
public enum ExportTypes
{
   None,

   Text,
   Excel,
   CSV,
   JSon,
   XML

}


Vaya. ¿Qué nos cambia esto? Ahora los valores de cada valor de enum son como siguen:


None = 0
Text = 1
Excel = 2
CSV = 4
JSon = 8
XML = 16


Noten como cada valor 2 a la N, donde N es la posición del valor en el enum, por decirlo de una forma. Lo mismo ocurre en un grupo de bits 00000. El bit de la derecha vale 1 y el de la izquierda de todo vale 16. No hay bit que represente el cero. Entonces si queremos tener TEXT y CSV tenemos que hacer algo como 00101.


Ya hemos declarado el enum con el atributo flags. Veámos cómo lo podemos utilizar.


ExportExecution.ExportTypes = ExportTypes.Text | ExportTypes.Excel;


Utilizamos el operador | que es un OR. Esto quiere decir que ahora nuestra variable ExportTypes de una hipotética clase ExportExecution vale 00011. Entonces en nuestra aplicación podremos preguntar si están en 1 alguno de esos bits.


if(this.ExportTypes & ExportTypes.Text == ExportTypes.Text) {


Esto se fija que tengamos el bit de Text seteado. Lo mismo podemos hacer para cualquier valor del enum.

Nota: El debugger de .NET no nos mostrará los diferentes valores, sino el menor de los activados. En este caso sólo nos mostraría Text.

Bastante simple no? Finalmente algo a tener en cuenta es que el primer valor del enum, en este caso None, siempre nos dará true, porque el valor 0 no tiene bit que le represente. Por eso hemos nombrado como None este tipo de exportación.