Fumo y Programo

Recuerdo la primera vez que fumé un cigarrillo. Tan solo un chiquillo tratando de aparentar ser un hombre. Que imbécil. Si hubiera sabido que ese lamentable hecho iba a cambiar mi vida y mi salud, nunca lo hubiera encendido.

Pienso que entre todos los vicios que tengo, este es el peor. Mil veces he prometido dejarlo y mil veces he fallado. El estrés en la carrera del software va en aumento con la edad, mas responsabilidades, mas problemas, mas cigarrillos :menos vida.

Claro, no todos lo hacen, pero para mi es un momento de paz interior, en el que puedo pensar como planear el siguiente sprint, o como programar un algoritmo que me tiene loco. Puedo decir que es mi pausa activa.

Se que no es excusa, se que me va a matar pero aun no he encontrado como dejarlo; y mientras escribo estas líneas enciendo un cigarrillo prometiéndome a mi mismo que será el ultimo.

Se que no lo será.

Un abrazo, desarrolladores.

 

Amigo: Te quiero, pero estas despedido.

Crecer profesionalmente en del desarrollo de software es un trabajo retador.  Como dicen los superheroes: un gran poder trae consigo una gran responsabilidad. Y esta responsabilidad trae consigo cosas buenas y también cosas malas.

Pues bien, esta semana tuve una de las experiencias más difíciles en mi vida laboral. Por primera vez tuve que despedir a una persona.

Los grupos de desarrollo de software generalmente son unidos. Tenemos que trabajar hombro a hombro; muchas veces trasnochando para sacar adelante un proyecto. Si uno falla, todos fallamos. En el día a día nos contamos las cosas, los problemas, y si lo piensan un poco, quizás compartan mas tiempo con los compañeros de oficina que con sus parejas!

Pues bien, después de varias fallas en uno de mis queridos amigos, y por supuesto de haberle pedido  varias veces que mejorara su rendimiento, tome la decisión de terminar su contrato.

Aquí algunos consejos si lo tiene que hacer usted:

1. La decisión ya esta tomada. No piense en nuevas oportunidades.
2. Haga una lista de las cosas, las buenas y malas. Lea esta lista justo antes de citarlo a la reunión para tenerlas en la cabeza.
3. Prepare la carta de despido.
4. Cite a la persona, sea directo y conciso: Comience con la dura frase: Estas despedido. Luego de unos segundos explique claramente las razones.
5. Déjelo expresarse, pero tenga en cuenta que no es una conversación. Ante cualquier duda recuérdele: La decisión ya está tomada.
6. Después de entregarle la carta dele instrucciones precisas de los siguientes pasos :liquidación, entrega de inventario, etc.
7. Termine con la frase: «Te dejo unos minutos a solas».

No hay un momento ni un lugar adecuado. En la experiencia que les estoy relatando esta persona lloró, me recordó que tenia familia, me recordó que eramos amigos.

El corazón se me hizo pedazos. Mis manos y mi voz temblaba, en ese momento solo le pude decir

Amigo: Te quiero, pero estas despedido.

Después de algunas semanas: aun me siento como un hijo de puta.

Sabe de computación? Me puede ayudar a arreglar la impresora?

Yo soy de la generación que pensaba que el futuro estaba en estudiar ingeniería informática. Soy de la generación que vio nacer los ordenadores, que los vio crecer hasta convertirse en las máquinas que son hoy en día.

Soy de la vieja guardia, que estudiaba en computadoras sin disco duro y sin ratón. Que pensaba en ser ingeniero de la NASA y que sabia ortografía porque no existía el corrector . Soy de la generación que pasó de una maquina de escribir a las primeras versiones de computadores y pensaba que el futuro estaba en mis manos.

El problema es que eramos miles los que pensábamos de esa manera, y una vez terminamos de estudiar, trabajar de ingeniero de sistemas era sinónimo de arreglar impresoras, armar computadores clones o dictar cursos de Excel.

Pero a veces las cosas cambian para bien y hoy que abro los ojos me doy cuenta como ha cambiado el mundo. Roles especializados y múltiples oportunidades. El abanico de posibilidades es extremadamente grande y  crece cada día más.

«La especialización es el consejo».

Arquitectos empresariales que ganan millones necesitan contratar Arquitectos empresariales de datos, de infraestructura, de software y de negocio. Estos a su vez necesitan DBAs, back-ends, front-ends, diseñadores de software. Cada uno hace lo suyo.

La buena noticia: cada vez se necesitan más personas especializadas, y cada vez somos menos los que estudiamos esto.

Algo bueno tenia que salir de «comer» tanto libro y vivir de tantos sueños.

@DeveloperEnComa

Despotricando de los arquitectos de software y practicando mi ingles

The Software size and complexity have increased over the last several years. All kind of specialized developers have been included in the teams: back-ends, front-ends, database experts, even graphic designers. Nowdays, functional requirements are only a part of the equation and not the whole concern.

A new almighty role was required in order to rule them all. The need was born, the degree has been chosen: «Software architect». However the rights and obligations are not still clear enough. At the end of the day, anyone could be a software architect, because no one knows exactly what is it all about.

 

Software is different from other engineerings, it is immature, new , and even naïve.

Millions of dollars has been spent in software projects with not precisely happy ending. Companies all over the world know the importance of high level design before start coding. However not many of them are willing to take the step forward. If they were able to finish a project without an architect, why to start now? Evidence is not enough.

The software architecture is a new term and has evolved in the past few years. The Software architecture is not a fad, it is here to stay, it is here to help companies all over the world to create complex software with huge requirements.

 

Ya despotrique de los arquitectos, por favor, despotriquen de mi ingles.

N.T Despotricar = «hablar mal»

 

Lo que tengo contra de las universidades privadas.

Hace algunos días tuve una discusión con un compañero de trabajo, donde él argumentaba que la universidad en la cual había estudiado, por ser privada era mucho mejor que la mía.

Les pongo un dibujo para que se imaginen la escena (No se confundan, yo soy el que tiene el chancho en las manos):

Partamos de un punto importante.

La universidad no hace al profesional. Es el profesional, quien por sus propios méritos logra sobresalir.

La ultima vez que fui a una universidad privada quede con la boca abierta al ver los laboratorios, las salas de computo e incluso los baños. El acceso a la ultima tecnología trae consigo una gran ventaja competitiva.

Les voy a dar un dato personal: Los dos desarrolladores que más admiro y que por cierto son los mejor remunerados: nunca se graduaron.

Teniendo en cuenta esta información, y que además mi salario es competitivo con el de los desarrolladores egresados de universidades privadas, es hora de hacer un simple ejercicio matemático:

En mi caso particular, si hubiera terminado a tiempo, hubiese pagado un total, por toda la carera de ingeniería de 282 dolares. Si; leyeron bien. Por toda mi carrera pagué este valor.

Al compararlo con los más de 5 mil dolares que paga una persona por un solo semestre en una universidad privada, ese valor suena ridículamente menor.

Mi discusión termino así:

«No se si tu universidad es mejor o peor que la mía. Lo que si sé, es que yo pagué por toda mi carrera, lo que tu pagaste por estudiar algo más que una semana. En este momento tenemos las mismas oportunidades ¿Que inversión  fue mejor?»

¿Que tengo en contra de las universidades privadas? Nada, lo único que tengo es envidia, pero la conclusión es la misma: No importa la universidad, lo importante es el profesional.

Cual es el mejor lenguaje de programación?

Hace poco tiempo, @KazeEDP  estaba haciendo una pregunta que todos los desarrolladores alguna vez nos hemos hecho: ¿Cual lenguaje de programación debería aprender?. Después de una infructuosa encuesta en mi cuenta de twitter decidí hacer una pequeña investigación.

Existen organizaciones como TIOBE dedicadas a hacer estudios de aceptación y popularidad de lenguajes. De este estudio se puede sacar las siguientes conclusiones:

• En lo que se refiere a popularidad los puestos están asi: C(1), Java (2), Objective-C (3), C++ (4), C# (5) 
• Java baja un  puesto respecto al año pasado y Objective-C pasa del puesto 5 al 3.
• Visual Basic gana mucho terreno pasando del puesto 35 al 15.

Respecto a cantidad de trabajos encontré la página Jobstractor. De acuerdo a esta información, para Diciembre de 2012, se necesita más programadores para los siguientes lenguajes: PHP(883), JAVA(854), OBJECTIVE-C(678), Ruby(283) y C#(241).

La página de PyDatalog, hace comparaciones teniendo en cuenta únicamente la búsqueda de tutoriales, lo que da una idea de la cantidad de personas que están aprendiendo. El resultado en orden es: JAVA (30.5%), PHP (15.4%), C++(10.4%), C#(10.1%) Y C(9.2%).

Otro indicador interesante podría ser la cantidad de proyectos en GitHub y la cantidad de preguntas en StackOverflow. Esto se puede observar en la siguiente gráfica.

Conclusión

• Existen lenguajes que tienen gran aceptación debido a que llevan mucho tiempo en el mercado, como Java, C,  C++ y C#
• Existen lenguajes que estan subiendo puestos como Objective C, Ruby y Visual Basic.
• Si no tienes ni idea de programar, yo recomendaría Ruby, que tiene gran mercado y gran popularidad dentro de aplicaciones en la Nube.
• Si ya sabes programar y quieres aprender algo nuevo, yo recomendaría Objective-C, ya que actualmente se requieren muchos desarrolladores para móviles  Ademas son los mejores pagos.
• Otra opción es dedicarte a aprender cosas de Front-End, que también  tiene buenos ingresos; ya sabes: javascript, jquery y todos sus juguetes.

Pero la conclusión mas grande es: El lenguaje no hace al programador. Todos los lenguajes tienen ventajas y desventajas, y los que hemos programado por mucho tiempo sabemos que esto es verdad.

C# o Java? Que mas da, mientras uno entregue un proyecto bien hecho y en el tiempo acordado. 

Atentamente: @DeveloperEnComa

 

SCRUM para pobres… una limosna para una certificación.

Al parecer, mi experiencia imaginaria en SCRUM no fue suficiente para conseguir un trabajo que me interesaba. Me pedían una certificación y aunque no son de mi agrado, me tome el trabajo de investigar sobre el tema. El resultado: Existen certificaciones en Scrum para gente pobre y certificaciones para gente rica. Así como lo leen.

Existen dos opciones para adquirir la certificación:

ScrumAlliance – Certified Scrum Master (SCRUM para ricos)

• Para certificarse en CSM es obligatorio asistir a un cursó, que en mi país tiene el valor de 1250 dolares. Casi 4 salarios mínimos.
• Ademas de asistir al curso, se debe presentar un examen de 35 preguntas. Solo se debe contestar correctamente el 68% de las preguntas para pasarlo.
• Si no aprueba el examen, puede pagar 25 dolares adicionarles y volverlo a presentar

Scrum.org-  Professional Scrum Master (SCRUM para pobres)

• Tomar el curso para scrum master en Scrum.org tiene un costo similar $1295, sin embargo no es obligatorio tomar el curso para hacer la certificación.
• La certificación (examen) tiene un costo de 100 dolares.
• Para pasar la certificación de Scrum.org, Professional Scrum Master (PSM) se deben contestar bien el 85% de 80 preguntas.

Resumen

Para obtener una certificación como ScrumMaster se tienen dos opciones, estudiar por cuenta propia o tomar un curso. Aunque he escuchado que los curso son buenos, siempre recomiendo ser autodidacta.

Yo, @DeveloperEnComa, tomaré la certificación con Scrum.org, estudiaré del libro gratuito durante 1 semana y me gastaré 100 dolares. Los restantes 1100 dolares me los gastaré en cerveza, a la salud de todos ustedes.

Salud!!

Certificaciones de software vs ingenuidad del empleador

Existen certificaciones para todos productos que se han popularizado.  Para cada lenguaje o framework; uno puede incluso certificarse en Word (MOS Certification).

Actualizando mi hoja de vida, me di cuenta que la lista de certificaciones no es muy larga y esto me puso a pensar: ¿Realmente vale la pena tener una certificación?

Desde el punto de vista de la entidad validadora, una certificación acredita a una persona de que tiene los conocimientos para utilizar un herramienta.

Desde el punto de vista del estudiante, es una forma de mejorar su hoja de vida y de demostrar sus conocimientos.

Desde el punto de vista del empleador, una persona con una certificación tiene prioridad sobre una no certificada.

En mi humilde opinión una certificación no sirve de nada, si la persona que la toma pagó por un curso de certificación o estudio de un mock.  Los cursos de certificación están orientados a darle la respuesta a los estudiantes. Los mocks son la manera mas fácil de hacer trampa: conseguir las preguntas de la comunidad que previamente tomó el examen.

La experiencia debería ser mas importante que las acreditaciones, pero como estamos en un mundo ingenuo: si  tiene la oportunidad es bueno colocar un par de estos sellos en su hoja de vida…. Quizás encuentre un empleador ingenuo.

Cronogramas en el desarrollo de software. La mayor falacia.

Cada vez que escucho a algún compañero celebrar sobre un proyecto terminado, inevitablemente hago una pregunta horrible: ¿Lo terminaron a tiempo? Ya se la respuesta: No.

Los proyectos en desarrollo casi nunca terminan a tiempo. Trabajamos como mulas, con horarios extendidos para cumplir cronogramas imposibles y satisfacer así el ego de algún «gerentillo» de proyecto que piensa que nos dedicamos a hacer cajas; y que cree que puede controlar la productividad de un grupo de desarrollo usando un arma a la que todos le tenemos miedo: Microsoft Project.

 

 

No nos digamos mentiras, dedicarse a hacer cronogramas a largo plazo es tirar el tiempo a la basura. Sin embargo el tiempo siempre va a ser nuestro enemigo. Aquí algunos consejos:

• El cronograma de desarrollo debe ser obtenido de los mismos desarrolladores. Son ellos quien realmente saben cuanto se van a demorar; y por otro lado al recibir esta información de ellos estamos obteniendo un compromiso. 
• Hacer un cronograma toma tiempo. Las metodologias agiles sugieren hacer el cronograma máximo a un sprint (mas o menos un mes).
• La agilidad es la característica más buscada en el software actual. Cronogramas a largo plazo reducen la capacidad de tomar decisiones a tiempo.
• Prefiera las herramientas simples a las complejas  Ha probado BaseCamp? Incluso, podría decir que una hoja de Excel es mejor amigo que el project.
• Los requerimientos están cambiando constantemente. Si tiene esto en mente, sabrá que un cronograma nunca podrá ser estático.

Algunos pueden pensar que estoy dando un mal consejo. No me malentiendan, solo pienso que el tiempo mal invertido en hacer un cronograma de varios meses que no se va a cumplir se puede invertir en otras cosas.

Y por último, la siguiente vez que le pidan un cronograma a largo plazo pregúntele a esa persona ¿Alguna vez recibió un cronograma a largo plazo que de verdad se cumplió?

Desarrollador: Mentiras en la hoja de vida

En una hoja de vida, cualquiera puede escribir un sin número de mentiras; y en el campo de la tecnología es más fácil aun! Yo podría decir: experto en Ñ++, un lenguaje estructurado e interpretado similar al C++. Quien podría decir que no existe? y mejor aun: nunca me van a pedir que lo demuestre!

El problema viene cuando se colocan en la hoja de vida verdades a medias. Si alguien miente en un aspecto de la hoja de vida, porque no habría de mentir en el resto?

En la parte donde describimos la experiencia previa, estamos acostumbrados a escribir todos los lenguajes en los que hemos trabajado. Si alguna vez lo escuchamos: va a parar a la hoja de vida. Si hice un «hola mundo»: ya me convertí en un experto.

Por eso en las entrevistas que hago, siempre me gusta presentarme como una persona no técnica (no soy mentiroso, solo omito información). Siempre, al inicio de la entrevista digo algo así como: «trata de explicarme algunas cosas porque yo no se mucho de tecnología». No creerán la cantidad de burradas que la gente inventa!

Después de dejarlos hablar por varios minutos (en realidad me divierte), me pongo a hacer preguntas concretas. Hay cosas que no cambian entre los lenguajes, por lo tanto hay cosas comunes que deberían saber.

Puedo decir con toda franqueza que se muy poco, que me falta mucho por aprender. Pero aquí mis consejos básicos para tener una mejor hoja de vida.

• Por favooooor! usen el corrector ortográfico!. Cuando veo un error de ortografía siempre pregunto: «y que tal eres para la redacción y la ortografía?» a lo que  inequívocamente me responden: «Excelente» JA!
•  Hagan que alguien mas lea la hoja de vida. Alguien no técnico, alguien que les pueda decir si la redacción esta bien.
• Sean sinceros con el nivel de ingles. Si una persona escribe que es buena en ingles y no puede demostrarlo en la entrevista: queda marcado como mentiroso.
• Sean sinceros con los lenguajes: «Hice pequeños proyectos», «Hice algunas aplicaciones», «Conozco un poco», en lugar de decir que se tiene «basta experiencia».
• Ordenen la experiencia iniciando por la mas reciente. Lo ultimo es lo que mas importa.
• Siempre incluir referencias laborales. Uno generalmente no llama, pero al colocarlas se  da un mensaje claro: «Mis jefes han quedado contentos con mi trabajo».

Y usted, que mentiras ha escrito en su hoja de vida? La mía: SCRUM