You are currently browsing the category archive for the ‘Uncategorized’ category.
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.
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.
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.
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ó?
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
«Zona de confort» es un termino que todos los desarrolladores conocemos después de trabajar varios años en la misma empresa.
Cuando una persona es nueva en una organización existe un periodo de tiempo interesante en el que se aprende de tecnología y del negocio. La empresa le brinda al empleado conocimiento y le comienza a exigir resultados.
A medida que el tiempo pasa, la curva de aprendizaje termina. Es ahí cuando el empleado se vuelve productivo para la compañía, y es ahí cuando comienza la pesadilla.
Después de trabajar varios años en una empresa, el empleado es reconocido por su trabajo. Se vuelve importante, sabe todo lo relacionado con el negocio, se conoce los trucos y las soluciones. Algunas veces es bien remunerado.
Por otro lado dejo de aprender. Es común que el código legado sea parte del día a día. La tecnología avanza y el desarrollador continua utilizando lo mismo que usaba hace 2,4 o 5 años. Le suena familiar?
Porque no conseguir un trabajo nuevo? La zona de confort marca la diferencia. Pensar en empezar de nuevo, en buscar un trabajo mejor pago, en ganarse la confianza nuevamente. Muy pocos dan el paso.
Hace un tiempo tuve una entrevista y el resultado fue : «Esta persona sabe mucho….. pero del producto en el que ha trabajado durante los últimos 5 años.»
Amigo desarrollador, que no le pase a usted. Si no esta aprendiendo: es hora de buscar un nuevo trabajo.
Developer En Coma 