De la educación informática en México y hacia donde ir

En días pasados tuve la oportunidad de tener una charla informal con un grupo de jóvenes recién egresados (y algunos en los últimos semestres) de la carrera de ingeniería en sistemas. Esto debido a que un buen amigo mío me pidió de favor que platicara con ellos acerca de mi experiencia en desarrollo (de hecho sus palabras fueron "háblales de lo que se te ocurra"). Amablemente accedí y dicha charla fue la que me inspiró a escribir este post.

Les hablé de varias cosas, entre ellas la premisa principal fue: Hacia dónde vas o a dónde quieres llevar tu carrera? Curiosamente la mayor parte de ellos quiere tener sus propias empresas. Esto nos llevó a hablar acerca de lo complicado y competido que se encuentra el mercado mexicano de software dirigido a pequeñas y medianas empresas (para el cual inevitablemente gran parte de nuestros egresados dirige sus esfuerzos en sus primeros años como profesional), en el cual lamentablemente la mayoría de éstas prefiere al que da mas barato y no al que ofrece la mejor calidad en muchos de los casos. Les hablé también de cómo a nadie le importa tu carrera mas que a ti, y es por esto que tienen que preocuparse por cultivar sus conocimientos y seguir aprendiendo frecuentemente. De cómo la "zona de confort" puede absorberte hasta el punto en el que dures cierto número de años haciendo lo mismo sin aprender nada nuevo (y en algunos casos ni ganar más), hasta que llega el día en que te das cuenta que te has quedado atrás... entre muchas otras cosas. En repetidas ocasiones noté la expresión de las personas a las cuales les estás hablando en otro idioma y no te entienden absolutamente nada.

He visto con tristeza cómo pasan los años y la calidad de la educación universitaria al menos en mi ciudad sigue siendo tan deficiente como cuando yo egresé. Es muy triste hablar con jóvenes que están en mi misma universidad y me repiten sus malas experiencias educativas tal y como si fueran las mías, después de 6 años de haber egresado: Profesores que no conocen las materias que imparten, que no asisten a clases, que insultan a los alumnos. Materias deficientes y desactualizadas, técnicas y/o lenguajes de programación que ya no se utilizan en la actualidad, etcétera. Dicho tiempo es el mismo que tengo esperando escribir lo siguiente: Es increíble, irritante e intolerable el mal estado de la educación en algunas universidades de México en lo que respecta a ingeniería en sistemas, o específicamente hablando, programación. Mientras que en Rusia, Estados Unidos, Inglaterra y otros países de primer mundo los jóvenes universitarios ya escribieron su propio protocolo de comunicación de datos, aquí apenas se nos menciona lo que es. Mientras ellos crecen con unix y lo utilizan durante toda su carrera, nosotros apenas y hemos escuchado hablar de "Linux", cuya definición generalizada es la de "un windows gratis"... Y podría continuar con infinidad de tecnologías y herramientas que mientras ingenieros en las últimas etapas de sus carreras conocen y utilizan en un muy alto grado en países de primer mundo, nuestros ingenieros ni siquiera saben que existen.

La pregunta es: Hay manera de cambiar esto? Definitivamente la respuesta no viene por parte de nuestro sistema de educación, el cual se encuentra afectado por algunas personas que por un lado no cuentan con dichos conocimientos y por otro no tienen el más mínimo interés en contar con ellos y mucho menos que sus estudiantes lo hagan. Yo creo que la solución mas viable viene desde afuera, está en cada uno de esos estudiantes a quienes realmente les interesa aprender. El problema viene cuando vemos ese porcentaje, el cual no es muy alto. En ese caso, cómo hacemos que nuestros jóvenes, futuros ingenieros en sistemas Mexicanos, se interesen por cultivar sus conocimientos, por aprender nuevas tecnologías o lenguajes de programación?

El estudiante de ingeniería en sistemas, inclusive el recién egresado PROMEDIO tienen un panorama muy limitado en lo que a su profesión respecta, incluso al egresar de su carrera (ésto con respecto a programación). No conocen más de dos o tres lenguajes de programación, de los cuales al menos dos son materias obligatorias dentro de su carrera. De éstos, el nivel de dominio es de aproximadamente (en mi opinión) un 60% del núcleo del lenguaje cuando mucho. Como consecuencia de esto, su conocimiento de frameworks de dichos lenguajes es nulo. Otra cosa verdaderamente alarmante es su falta de cultura informática. La mayoría nunca han leído un libro de programación que no haya sido parte de su carrera (esto asumiendo que efectivamente leyeron los libros de su carrera). La mayoría no ha oído hablar de libros como el pragmatic programmer, code complete o refactoring, y ni siquiera saben que existe el pragmatic bookshelf. No saben absolutamente nada de metodologías de desarrollo de software, especialmente de metodologías ágiles. No saben quiénes son los autores de los lenguajes de programación que utilizan, ni quiénes son los principales contribuyentes del open source. Muchos menos saben de personas más jóvenes cuyas contribuciones han hecho posibles las herramientas y técnicas de programación más utilizadas en el siglo 21 tales como Martin Fowler, David Heinemeier Hansson, Gavin King, Blake Mizerany, Venkat Subramaniam, entre muchos, muchos otros.

He tenido la oportunidad de trabajar con personas de muchos países (Estados Unidos, India, Rusia, Moldova, Argentina, Brasil, Inglaterra...). En algunos casos (no en todos) la educación universitaria ha sido superior a la que recibí yo. En otros, ha sido Infinitamente superior. Entiendo que no podemos ni debemos pedirle todo a la educación universitaria, pero si considero firmemente que dichas universidades de las que hablo tienen la obligación de actualizarse y preparar mejor a nuestros futuros ingenieros. Se me ocurren varias cosas que podrían llevar a cabo. Por ejemplo, los profesores deberían inculcar a sus alumnos la semillita de la curiosidad. No les cuesta nada darles a conocer que no sólo existen lenguajes como Turbo C y Pascal, y que en el mundo real dichos lenguajes no son con lo que la mayor parte de los sistemas empresariales están hechos. Que lo más seguro es que ni siquiera van a programar en ellos al egresar (de mis colegas de carrera, diría que un 10% utiliza en su trabajo los lenguajes de programación que nos enseñaron en la escuela). De igual manera, las personas que están al frente del departamento de informática deberían llevar a cabo una reestructuración mayor al catálogo de carrera, ésto con la finalidad de proporcionar a sus ingenieros herramientas y conocimientos acorde a las necesidades de la industria del software de hoy en día, la cual lamento informarles que ya cambió. Ya no es la misma de hace 20 años cuando hicieron el catálogo de carrera. Hoy en día necesita ingenieros que conozcan lenguajes como Ruby, Java, scala, groovy, javascript... Que conozcan tecnologías como ruby on rails, Spring, Hibernate, Grails y un largo etcétera. Que sepan de orientación a objetos, de patrones de diseño, de arquitecturas de software, de principios SOLID, de paradigmas de programación No Turbo C, ni Pascal, ni Flash...

Por otro lado, es alarmante la pasividad, parsimonía y conformismo (en muchos casos parte de nuestra cultura) que tienen nuestros estudiantes por aprender. Yo lo viví. Yo no leía, ni estudiaba, ni me preocupaba por aprender lo que se supone me deberían de enseñar como parte de mi carrera. Y como yo ha habido, hay y habrá muchísimos estudiantes en México. En general no nos educan ni nos enseñan a ser estudiantes activos. No leemos. No nos preparamos. No nos interesa. Creemos que saliendo de la universidad nos vamos a hacer ricos y vamos a ser exitosos, pero nunca nos preocupamos por el cómo. En otras palabras, es un problema de actitud, y en gran medida, cultural.

Sin embargo, el común denominador del ingeniero de software profesional desde mi punto de vista es el siguiente:

• Se preocupa por aprender nuevos lenguajes y tecnologías
• Es autodidacta y lo pone en práctica día a día
• Se mantiene informado con respecto a nuevos (y viejos) lenguajes, tecnologías y frameworks
• Tiene una mente abierta que le permite seleccionar la herramienta adecuada para el trabajo
• No tiene miedo ni parálisis paradigmática por incursionar con una nueva tecnología o lenguaje

Qué necesita el recién egresado o cualquier ingeniero de software para llevar a cabo esto? Si acaso la virtud de ser autodidacta, la cual no todos tienen. Fuera de ahí, todo es cuestión de actitud y y deseo hacer las cosas. Esto es algo que es necesario inculcar a nuestros jóvenes. Es necesario que los ingenieros en sistemas con experiencia como yo nos acerquemos a los jóvenes y a las universidades y hagamos esto de su conocimiento. Para ello existen las comunidades de software por ejemplo, donde la gente puede enriquecer sus conocimientos de manera gratuita y gratificante. Por otro lado, nada nos cuesta acercarnos a las universidades y hablar acerca de esto. Cuál es el beneficio? Generar una comunidad de profesionales que se ayuden unos a otros, lo cual inevitablemente elevará el nivel de la comunidad en cuanto a desarrollo de software y mejorará la industria mexicana. Sé que no es fácil, pero es la una de las formas más sencillas que tenemos de combatir el rezago informático en el que nos encontramos y así poder competir con los países de primer mundo en todos los aspectos.

Te interesa? Entonces ve y haz algo por nuestros jóvenes de alguna forma. Da una charla en una universidad. Asiste o expon en alguna de las comunidades de software en tu ciudad. Habla con uno, dos o un grupo de jóvenes de tus experiencias. Diles lo que en tu opinión deben hacer para mejorar. Más de uno te lo agradecerá.

Especialista o generalista?

Como producto de mis experiencias en el desarrollo de software a lo largo de estos años, me he formado una opinión/teoría/psicosis que dice así: En el desarrollo de software hay dos caminos que puedes seguir en los primeros años de tu carrera. Son como dos lados de la fuerza. No necesariamente uno es bueno y el otro es malo. No hay un lado de luz y uno de oscuridad, ni eres un Sith o un Jedi por estar en uno ni en otro. Me refiero a el ser especialista contra el ser generalista.

Hubo un momento de mi carrera en el que me preguntaron: Tú que quieres ser, especialista o generalista? En ese momento dije sin pensarlo mucho: Especialista! En ese momento no tenía clara ni la definición, ni las ventajas, ni las desventajas y sobre todo, diferencias entre uno y otro como la tengo hoy. Pensamientos que quiero plasmar para la posteridad.

Comencemos analizando al Especialista, alias mago, gurú o Master of the [inserta_nombre_de_lenguaje_o_tecnología] Universe. El especialista es un experto en una disciplina (al ser experto en varias se convierte en generalista). Conoce hasta los más mínimos pormenores y recovecos de dicha disciplina, ya sea un lenguaje de programación, una tecnología, un framework, etcétera. Así como un amplio set de características o herramientas que giran en torno al mismo. Se ha enfretando a los problemas más complejos de dicha disciplina, y ha aprendido cómo solucionarlos.

Y empecemos por el ejemplo. Un verdadero especialista en un lenguaje de programación o tecnología conoce el core de la misma a la perfección. Sabe las diferencias entre las versiones de la 1 a la más reciente (que puede ser la 12). Conoce los bugs que cada una de las versiones tiene, cómo pueden surgir y los workaround para "solucionarlos". Si tomamos como ejemplo más concreto a un especialista en Java, sabe como funciona la máquina virtual, cómo colapsarla, conoce incluso el código del garbage collector, el módulo de seguridad java y demás características o añadidos del lenguaje. Vive para solucionar problemas complejos en sistemas construidos sobre dicha plataforma. Y lo mejor de todo es que es capaz de hacerlo sin problemas gracias a sus múltiples experiencias, y en consecuencia percibe cuantiosas ganancias por hacerlo. Llega, soluciona el problema y la mayoría de las veces, se va. En ciertos sectores del software se le conoce como consultores. Exponle un problema en específico a un consultor y te lo solucionará de inmediato (básicamente porque para eso lo contraste como experto).

Por otro lado tenemos al generalista. El generalista conoce un gran número de lenguajes de programación, desde estructurados, funcionales, declarativos, orientados a objetos, etcétera. No es un experto en todos ellos pero conoce las características generales de cada uno, así como las ventajas de utilizar uno sobre otro para llevar a cabo una determinada tarea. De la misma manera conoce un gran número de herramientas y frameworks para llevar a cabo todo tipo de objetivos, desde el boostrap de un proyecto, pasando por migraciones de bases de datos hasta llegar al objetivo principal del sistema en cuestión. Conoce además los sistemas operativos y ambientes en los que se ejecutarán dichos sistemas, y saben cuál y porqué es el adecuado o los problemas que puedan existir a causa de dicho ambiente. Es el héroe de mil batallas (en este caso, mil proyectos). Es un consultor por naturaleza. Tiene la capacidad de llevar a cabo la incepción de un proyecto en su totalidad. Exponle el problema que tiene tu empresa y él analizará el problema y te dará una o varias soluciones para tu problema, basadas en diferentes lenguajes, herramientas, frameworks y sistemas operativos dependiendo el tipo de problema. Ya dependerá del cliente o la empresa la solución a tomar, ya sea la mas barata (y quizá la menos eficiente) o la más eficiente sin importar el costo de la misma. O inclusive un punto intermedio, ustedes me entienden.

Las ventajas de ser un especialista son, primero que nada, que el especialista generalmente tiene o puede obtener un empleo muy bien remunerado en base a esto (solucionar grandes problemas es bien pagado, no?). Si el especialista se dedica a dar consultoría, quizá ande por todas partes del mundo solucionando problemas específicos de su especialidad, y de paso divirtiéndose y viviendo bien de ello. Incluso si el especialista lo desea (sé de varios), puede convertirse en un referente de la tecnología o lenguaje que domina, ya sea en la empresa para la que trabaja o posee o como parte de una comunidad. Tal es el caso de infinidad de personas como Yukihiro Matsumoto, (creador de Ruby), David Heinemeir Hansson (creador de Rails), Blake Myzerany (creador de Sinatra), James Gosling (creador de java) entre muchos, muchos otros.

Ahora hablemos de las desventajas. Primero que nada, y como bien lo dice Chad Fowler en su libro The Passionate Programmer: Estás poniendo todos tus huevos en una sola canasta. Y esto no siempre es bueno. Que pasa si el día de mañana la tecnología que dominas se convierte en obsoleta? Que pasa si (por ejemplo) en un año o dos otro lenguaje como Scala o el nuevo lenguaje G (si, saben de quien. Y no existe, aún) destrona a Java? En un momento dado sabemos que el experto pragmático se adaptará y tarde o temprano se cambiará al lenguaje G y dejará Java. Quizás.

Otra desventaja desde mi punto de vista es la falta de perspectiva. El ser especialista te convierte en experto de un área de la tecnología, pero muchas veces te roba la perspectiva que te otorga el ser generalista. El especialista quizá quiera hacer todo con el lenguaje de su especialidad, cuando muchas veces quizá no sea la mejor herramienta para el trabajo. Un ejemplo muy sencillo es, Abrir un archivo en Java toma 10 líneas de código. En Ruby o Perl toma 3. Ah, y Perl es mucho mas rápido que Java para dicha tarea.

Una más (y muy importante) es el mercado. El generalista en general percibirá mucho por la naturaleza de su trabajo, pero al ser consultor puede haber temporadas en las que simplemente no tenga trabajo... ups. Además, su mercado puede no ser tan amplio en determinado momento. Por otro lado, también habrá temporadas en las que deba rechazar trabajo porque simplemente no pueda con tanto.

Ahora platiquemos un poco acerca de las ventajas de ser generalista. Primero que nada, nuestro amigo generalista puede estar en cualquier tipo de proyecto llevando a cabo cualquier rol. Si, sabemos que no lo va a hacer tan bien ni en tan poco tiempo como el especialista. Pero el generalista acumula experiencia en cada proyecto que lleva a cabo, y en base a esto posee un buen juicio para seleccionar tecnologías progresivamente (Gracias a Blake Myzerany por esta idea). No tiene problemas en moverse de un lenguaje, tecnología o proyecto a otro y en consecuencia generalmente no tiene problemas en encontrar trabajo. Tiene la habilidad para aprender y adoptar una nueva tecnología sin problemas, y a una velocidad asombrosa.

Cual sería la desventaja del generalista? Una sería que no está a la altura ni tiene la experiencia y los conocimientos de un especialista con respecto a una tecnología en particular. El especialista puede resolver en 1 hora lo que al generalista le puede tomar cuatro. 

En mi carrera he tenido la oportunidad de trabajar con excelentes ingenieros, tanto especialistas como generalistas. En lo personal yo estoy siguiendo el camino del generalista. Por una parte porque es el que más me atrae. Es por donde me ha llevado la vida. La empresa para la que trabajo actualmente está llena de ellos, y son brillantes en lo que hacen. Cada día aprendes algo nuevo de ellos. He visto y vivido el cómo un generalista (o un conjunto de ellos) puede llegar con cualquier cliente o compañía y decirle: Esto es lo que necesitas. Y ver cómo se convierte en un éxito y cómo el cliente queda satisfecho con el producto o servicio que se le está brindando.

Por último, les dejo una idea que me compartió uno de mis ejemplos a seguir, el sr. David Martinez en alguna ocasión. El objetivo a largo plazo de un generalista debe ser convertirse en un generalista-especialista. Esto es, a lo largo de una carrera de más de veinte años, puedes ser un experto en varios lenguajes y tecnologías, siguiendo el camino adecuado, acumulando veinte años de experiencia valiosa y valuable (en contraste con acumular un año de experiencia repetido veinte veces) y llevando a cabo decenas de proyectos. Inevitablemente llegarás ahí. David Martínez se encuentra ahí. Y allá es a donde quiero llegar yo.

Y tu, qué quieres ser y a dónde quieres llegar en 20 años?

Magma Rails edición 2010

Antes de comenzar con el tema actual, quiero decir que por un lado me siento mal de tener casi un año sin escribir nada (y seis meses con este post en borrador), y por otro lado es increible como un proyecto (o dos, o tres... y así) pueden alejarte tanto de hacer las cosas que te gustan (como bloggear). Pero bueno. Es hora de retomar el buen camino.

En Octubre del año pasado (si, ya hace mucho de eso) tuve la gran fortuna de poder asistir al primer congreso de ruby on rails celebrado en Mexico (En Colima para ser exactos), MagmaRails, el cual estuvo simplemente Excelente con E.

Hacia varios años que no asistia a ningun congreso, basicamente porque a los que asistí en mis épocas de estudiante e incluso un poco después habian sido una verdadera pérdida de tiempo. Debo confesar que mis expectativas de éste eran altas debido a lo siguiente:

• Primero que nada, el eje central del congreso era... Ruby on Rails!
• Segundo, tanto los creadores de Ruby y Rails (empezando por Matz) como la comunidad siempre se han preocupado por crear de manera pragmática y apegados a buenas prácticas de ingeniería desde el principio, siguiendo, patrones de diseño, desarrollo, y ni que decir del nivel de testing. Al desarrollar con rails automaticamente implementas estos conceptos y tecnicas de desarrollo y se vuelven inherentes a tu forma de desarrollar.
• La comunidad de rails Mexico iba a estar involucrada, la cual tiene mucha experiencia real y valuable en proyectos internacionales hechos en rails.
• La conferencia tenia el apoyo de varios patrocinadores como rubycentral, the hybrid group, entre otros. Compañias que se dedican a Rails de tiempo completo. Mas experiencia!

Y no me equivoqué. Vaya que valió la pena!

La organizacion del evento corrio a cargo de la gente de Crowd Interactive, con la ayuda de varias empresas y patrocinadores externos como rubycentral, the hybrid group y la comunidad de rails en Mexico, entre otros.

La mayor parte de las conferencias fueron impartidas por los mismos desarrolladores y diseñadores de esta empresa. El resto fueron impartidas por invitados de el resto de las empresas, como Jonathan Dean, Blake Myzerany (creador del framework Sinatra para aplicaciones web en Ruby) y Ron Evans (Principal de The Hybrid Group), entre muchos otros. Como podria esperarse de gente que viene del extranjero dedicada al desarrollo profesional de aplicaciones rails, sus conferencias fueron simplemente extraordinarias. Me quedo con las siguientes enseñanzas:

• Ruby on rails es la mejor herramienta para desarrollar aplicaciones web a la medida que NO sean empresariales, por infinidad de razones.
• Los puntos debiles de seguridad de un sistema web son finitos, y no son los mismos que un sistema standalone. Si realmente quieres blindar tu sistema, estudia sus debilidades y aprende a protegerlas.
• La experiencia viene del buen juicio. El buen Juicio viene de malas experiencias (Blake Myzerany).
• Ruby no es bueno para absolutamente todo. Java tampoco. No hagas todo en un solo lenguaje. No seas experto en un solo lenguaje. Aprende muchos y selecciona la mejor herramienta para hacer el trabajo que tienes por hacer.
• Git es, por mucho, el mejor control de versiones que existe en la actualidad, principalmente por ser distribuido, por su manejo de ramas, repositorios remotos, etcétera (si, es tema de otro post).
• JQuery es un framework asombroso, pero si realmente quieres optimizar tu aplicación web con él, tienes que des-aprenderlo y aprenderlo, para después conocerlo bien y saber utilizarlo de la mejor manera (tips de Jonathan Dean).
• Si quieres migrar una gran cantidad de datos de un sistema a otro, de una base de datos o medio de almacenamiento a otro, etc. Existe una técnica llamada ETL (Extract, Transform and Load) y herramientas que te permitirán hacer el trabajo de una manera rápida y eficiente.
• La programación es como la música (notas perfectas en armonía para una pieza magistral) y un buen equipo de desarrollo es como una de las top rock bands del mundo (si, esa que te encanta). Este concepto es bastante interesante y yo ya lo había visto de esa forma, porque he tenido la fortuna de trabajar con excelentes "músicos", si saben a lo que me refiero.

Para mi es muy interesante y emocionante a la vez ver este tipo de congresos y actividades en México. Creo que nuestro país necesita de este tipo de eventos llevados a cabo por este tipo de organizaciones, a las cuales no les interesa realmente hacer un negocio de ellos, sino enriquecer los conocimientos de la gente y mostrar a la comunidad lenguajes, herramientas y principios para llevar a cabo software de calidad.

Me emociona aun más que no fue ninguna universidad ni corporación la que organizo este evento (al cual considero un evento de calidad y vanguardia por la tematica, el nivel de las conferencias, los invitados, etcétera) sino una empresa ubicada en Colima, ciudad hermosa y pequeña, donde a diferencia de mi natal Guadalajara, las distancias son cortas, la comida deliciosa, el clima es caluroso y al parecer es un lugar donde se puede vivir muy bien. En esta ciudad hay una empresa que hace software utilizando Ruby on rails, cuya gente es altamente profesional. Ellos fueron los que trajeron a nosotros (los pocos que contamos con la fortuna de, primero que nada enterarnos, segundo asistir) una probadita de las herramientas que existen para hacer software de calidad. Enhorabuena señores, se necesitan mas empresas como ésta en México. Gracias!

Y ya para terminar, estamos listos para la revancha! (MagmaRails 2011 en Manzanillo). Si tienen oportunidad de asistir, se las recomiendo ampliamente.

El valor del software en Mexico

Como todos ustedes saben, el software cuesta. Si, es de lo que nosotros los desarrolladores, ingenieros/arquitectos en software, Analistas de negocios, ideres de proyecto, testers y demas profesionales de IT vivimos. Es a lo que dedicamos gran parte de nuestro dia y de nuestra vida. Puedo decir que a la mayoria de nosotros nos gusta y nos apasiona lo que hacemos, pero esto no nos serviria como modo de vida si no nos pagaran por ello. El software tiene un valor cuantificable en base a diferentes metodos establecidos por la ingeniería del software y otras vertientes no "oficiales" (modelos de estimación, horas-hombre, etc.) y generalmente el software tiene un valor alto, especialmente porque en un sistema interviene mucha gente, requiere un gran esfuerzo y lo mas importante: esta hecho en su mayoria de neuronas. Es como un rascacielos, un ferrari, un F-16 o cualquier pieza formidable de ingenieria hecha por el hombre.

Gran parte del problema del que hablamos (Y no solo en Mexico, sino tambien en otros paises, especialmente de Latinoamerica) tiene que ver con la cultura de la gente con respecto al software, en este caso de nuestros clientes. Es bastante contradictorio porque al final gracias al cliente nosotros percibimos los frutos por nuestro trabajo (si, hablo de dinero). Pero a pesar de esto no deja de ser un problema. Antes de continuar, me gustaria aclara que no estoy hablando de todos los clientes. Hay clientes buenos y clientes malos, en todos los giros. Ahora, continuando con el tema, consideremos los siguientes argumentos:

• Primero que nada, desde mi punto de vista el problema mas grande es que en Mexico la mayor parte de la gente que utiliza software (cualquier software) tiene el falso conocimiento o la "cultura" de que el software no cuesta. Y reitero, la mayor parte, no todos. Ejemplo: Que sucede cuando necesitamos una persona o compañia necesita un software que no es gratuito? (parentesis, mucha gente ni siquiera sabe que hay software por el que hay que pagar, mucho menos que hay software open source) Acudimos al Centro de Distribucion de Pirateria mas cercano a comprar un cd pirata, o en su defecto, bajamos una version del software de internet y buscamos un crack. Listo! Un software que vale miles de pesos ya nos costo de 50 o 30 pesos, a nada. Lamentablemente en legislacion de software todavia estamos muy lejos de los paises del primer mundo, donde la pirateria no existe porque es penada por la ley. Lo mas ironico de todo esto es que en Mexico la pirateria es delito grave (Articulo 429 del Codigo Federal y 223 de la Ley de Propiedad Industrial), el cual esta penado con de 2 a 7 años de prision y multas de 100 a 10 mil dias de salario minimo. Sin embargo, en cualquier tianguis, mercado o puesto ambulante podemos ver y comprar software pirata. Es casi como ir a comprar un periodico, y las autoridades tan tranquilas...
• Segundo (en consecuencia del primero), el cliente generalmente considera alto el precio del software (de cualquier software). Punto. En mi opinion, esto es en gran medida (independientemente del primer punto) debido a que el software no es un activo tangible para las personas y/o empresas, la gente que lo compra no puede entender ni explicarse porque esta pagando tanto dinero por algo virtual e intangible. Al fin y al cabo no es lo mismo comprar un BMW que una licencia corporativa de Oracle, SAP o similares, cierto?
• Tercero. Los clientes siempre estan buscando "disminuir costos" y precisamente uno de los candidatos favoritos para hacer esto es disminuir los costos del software (o simplemente no gastar en el), sin saber o tener pleno conocimiento de que la funcion principal o razon de ser de un sistema es precisamente optimizar los procesos de la empresa, y por consecuencia reducir los costos de operacion de la misma.
• Cuarto. Otro factor que interviene en los bajos costos del software son lo que conocemos como "soluciones al vapor", de las cuales forman parte el ejercito de generadores de contenido tipo Joomla. Existen infinidad de herramientas (unas muy buenas, otras muy malas) tanto para acelerar el desarrollo de un software como para casi generar el software por completo. Esto es lo que hace posible que una empresa de software pueda entregar un sistema en cuestion de dias en lugar de meses. Tal es el caso de Joomla (por poner un ejemplo), donde en base a sus modulos puedes llevar a cabo un portal web completo con un template basado en CSS, foros, e-commerce, RSS etc. en un tiempo record. El problema viene cuando se desea dar mantenimiento o agregar nueva funcionalidad a dicho sistema, ya que en el caso de los modulos o el codigo generado, generalmente es bastante complicado de entender, y en consecuencia de modificar. En el caso de las herramientas aceleradoras de software es muy diferente. Si el o los desarrolladores seleccionan una buena herramienta y saben utilizarla, los resultados pueden ser por demas favorables tanto para el cliente como para ellos. Es muy importante remarcar que no todas estas soluciones son asi. Existen muchas soluciones por demas utiles y optimas, pero hay que conocerlas y saberlas utilizar.
• Quinto. Para cerrar con broche de oro, esto ocurre en consecuencia de todos los puntos mencionados anteriormente. Tristemente hay infinidad de desarrolladores que disminuyen extremadamente el precio que le ponen a su trabajo con tal de no perder el negocio y llevar a cabo el sistema, lo cual ha venido ocasionando desde hace varios años que la oferta del software a la medida disminuya sus precios considerablemente por la ya conocida frase (sarcasticamente) "Pero si el de enfrente me lo da en 3 pesos joven..."

Ahora bien, de nada sirve quejarse si no propones soluciones. Que podemos hacer nosotros como profesionales del software para solucionar o al menos mitigar un poco toda esta situacion? Lo que escribo a continuacion han sido soluciones para mi y las personas cercanas con las que desarrollo sistemas. Ustedes, mis queridos lectores son completamente bienvenidos a adoptarlas como propias o rechazarlas categoricamente:

• Haz que el cliente te conozca a ti y a tu trabajo. Que el cliente se entere de que tu eres el mejor desarrollador que puede contratar en el mercado (porque lo eres, o no?) y demostrarlo. Muestrale tu curriculum, tu portafolio de trabajo, hablale de todo lo que has hecho, de tus experiencias en diferentes proyectos. La confianza del cliente es algo que debes de ganar y nunca debes perder a lo largo de todo el proyecto, e inclusive de proyectos posteriores para los que pueda contratarte en base a la primer impresion. (esto claro, si el cliente es buen cliente).
• Atiende a tu cliente. Siempre. Como ya lo mencione en el articulo pasado, el cliente es una pieza fundamental en el proceso de creacion de el proyecto, basicamente porque el es quien conoce perfectamente las reglas de negocio del sistema. Tener al cliente cerca garantiza que estas haciendo las cosas bien y que el sabe que estas haciendo las cosas bien. Involucralo lo mayor posible en tu proyecto y todo marchara bien.
• Fundamenta el costo de tu sistema. Porque tu sistema cuesta lo que cuesta? Es por el tiempo de desarrollo que se le invirtio? Es acaso porque no utiliza software libre sino con una licencia comercial? Que tipo de optimizaciones tiene? Que base de datos utiliza? Cual es el stack de tecnologias que involucra? Esta hecho en un solo lenguanje o el stack de tecnologias tiene una complejidad alta? Que tan complicado fue implementarlo? Cuanto costaria si lo compra con el de enfrente? Todas estas respuestas son las que tu le debes de dar a tu cliente a la hora de manifestar el costo del sistema. Quiza el cliente no te entienda, o quiza pida una segunda opinion y comprenda que realmente el precio que le estas cobrando es justo.
• Selecciona adecuadamente tus armas. Dependiendo del tipo de sistema que se va a llevar a cabo es necesario hacer un analisis acerca de el (o los) lenguaje(s) de programacion y herramientas a utilizar para construir el sistema. Elegir adecuadamente el lenguaje de programacion y el stack de tecnologias a utilizar garantizan en gran parte el exito del proyecto. No vas a hacer un sistema web en Delphi, verdad?
• Define lo que vas a desarrollar, y en consecuencia a cobrar. No trabajes gratis. Define (por contrato si es necesario) todos los pormenores del  trabajo que vas a llevar a cabo, asi como el costo total del mismo. De esta manera te evitaras retrabajo, contradicciones y malentendidos con tus clientes.
• Se etico y profesional. Una gran parte de mis clientes han venido a mi con una gran desconfianza debido a que "todos" los programadores anteriores que han contratado les han quedado mal, les han cobrado de mas, o todas las anteriores. Siempre tienes que mantener la etica y el profesionalismo ante todo. Cumple con tus fechas de entrega. Se transparente. No cobres de mas. Busca siempre la mejor solucion para tu cliente, y no la que mas te convenga a ti economicamente. No es necesario hacer un total rediseño de un sistema si el cliente solamente necesita ajustes de performance...

Y la mas importante:

• Selecciona tus batallas. Si el cliente no esta dispuesto a ayudarte con el proyecto, dedicarle tiempo a revisarlo junto contigo y ver que todo vaya bien, asistir a las juntas y a las demostraciones... No trabajes con el. Al final te veras envuelto en un proyecto tipo "marcha de la muerte" (death march) donde nada sale en tiempo, hay cambios de requerimientos constantemente y tu reputacion se vera dañada. Algunas veces es mejor decir no a este tipo de clientes. Ya vendran proyectos mejores.

En conclusion, el valor del software en Mexico es y sera por varios años muy bajo. Tristemente para nosotros los desarrolladores asi es. Es por esto que gran parte de nuestro trabajo es orientar al cliente en estos temas y difundir toda esta informacion entre la gente que no la conoce. Por otra parte, lo que yo creo que podemos hacer para que las cosas cambien poco a poco con respecto al valor del software en Mexico esta escrito aqui. Al menos si no podemos cambiar al mundo, por lo menos a nosotros como desarrolladores nos ahorrara muchos dolores de cabeza y retrabajo.

Hasta la proxima...

Agil como el viento

Como la mayoria de ustedes saben, la ingenieria del software es toda una ciencia, aunque algunos de nosotros la apliquemos y la queramos ver mas como un arte. Como toda ciencia, tiene procesos formales, metodologias, etc.
A lo largo de la era informatica, y desde que surgio la necesidad de desarrollar y manejar proyectos de software, se han inventado e implementado junto con ellos diferentes metodologias para dicho proposito. La mas comun (hasta hace tiempo) era el modelo de cascada (waterfall), donde un proyecto de software (sin importar su tamaño) pasaba por seis etapas perfectamente identificables:

• Planificacion y analisis (de todo el sistema)
• Diseño (de todo el sistema)
• Codificacion (de todo el sistema)
• Pruebas (de todo el sistema)
• Documentacion (de todo el sistema)
• Despliegue (de todo el sistema)

Existen dos principales (y muy grandes) inconvenientes al utilizar este modelo de desarrollo:

• Para cuando se pasa de una etapa a otra, las reglas del negocio ya cambiaron, lo cual repercute en un cambio en los requerimientos del sistema (queeeee?, pero si el diseño del sistema ya esta hecho!)
• La etapa de pruebas posterior a una etapa de codificacion de todo el sistema, arroja una gran cantidad de defectos, lo cual ocasionará volver a la etapa anterior (lo cual rompe con el modelo de cascada, y lo convierte parcialmente en un modelo iterativo)

En la compañia para la que trabajo se utiliza una metodologia de desarrollo un poco diferente. Su nombre es agil. Y se lo que se estan preguntando. En que difiere agil del resto de las metodologias? .

Agil propone un modelo de desarrollo donde la totalidad de requerimientos del sistema (todas sus reglas de negocio) se pueden dividir en pequeñas tareas llamadas historias (normalmente llamados requerimientos). En lugar de tener un solo ciclo de desarrollo (tambien llamado release), se tienen pequeños ciclos de desarrollo llamados iteraciones. La duracion minima de una iteracion es una semana, y la maxima es un mes. Durante dicha iteracion, el equipo de desarrollo en conjunto con el cliente, evaluan las historias de mayor prioridad y hacen un estimado de las historias que se pueden llevar a cabo durante el tiempo que dura dicha iteracion. Esto genera un compromiso del equipo de desarrollo hacia el cliente de tener una pieza de software funcionando y con un numero de defectos minimos al terminar la iteracion, y esta es la principal premisa de agil: Desarrollo estable y funcional de una pieza de software en pequeños ciclos de tiempo. Lo anterior permite que el proyecto tenga una gran adaptabilidad a los cambios, los cuales resultan relativamente faciles de integrar en cualquier etapa del proyecto.

Un equipo de desarrollo agil es un conjunto de personas dedicadas a llevar a cabo un proyecto de software apegandose a los lineamientos de la metodologia agil. Generalmente involucran roles como pueden ser lider de proyecto (PM), analista de negocios (BA), analista de calidad (QA), desarrolladores (si, esos que programan) y lideres tecnicos (si, esos que saben como hacer sistemas de la A a la Z, toman las decisiones dificiles y dan la cara si se equivocan). Cada uno tiene su rol bien definido dentro del proyecto, y trabaja en conjunto con el resto del equipo para llevarlo a cabo. Lo ideal es que esten en constante comunicacion y fisicamente en el mismo lugar. Si esto no es posible... lean el siguiente parrafo (y si no, tambien).

La segunda premisa principal de agil es el scrum. El scrum es una pequeña reunion diaria que se integra a la metodologia agil y se convierte en una poderosa herramienta para la colaboracion. En dicha junta (de 10 minutos aproximadamente) se reunen los integrantes del equipo de desarrollo y el cliente (es opcional para el, pero recomendado). Cada uno de los integrantes del equipo expone al resto del grupo cuales fueron los objetivos que alcanzo el dia anterior, que objetivos planea alcanzar y si tiene algun problema o inconveniente (roadblock) para hacerlo. Si lo tiene, una persona del equipo se debe ofrecer a ayudarle, y en caso de que nadie pueda hacerlo se debe llegar a un acuerdo acerca de como esta persona podra continuar trabajando. Esto ayuda a una constante comunicacion por parte de todo el equipo, a medir el progreso constante de cada uno de los integrantes del equipo y a que cada uno de los integrantes logre un progreso bastante considerable durante la iteracion. Todo mundo se mantiene ocupado, nadie se mantiene bloqueado.

Hum... Mencione tambien que nos ahorramos generar toda esa documentacion (inuti, tediosa y que nadie lee ni vuelve a leer, en muchas ocasiones) cuando se lleva una metodologia formal (como puede ser CMM)? Ah, pero esto es una bendicion y una maldicion a la vez, ya que genera una gran desventaja para agil... Al ser una metodologia no tan formal como las demas, no todos los proyectos de software se pueden llevar a cabo con ella. (Nada es perfecto en esta vida).

En la actualidad una gran cantidad de compañias de desarrollo, e incluso consultores externos han adoptado metodologias agiles para el desarrollo del software, ya que con este se pueden generar piezas de software de mayor calidad en un tiempo relativamente corto, ademas de que tanto el cliente como la parte que desarrolla se mantienen satisfechos con el desempeño, ya que los objetivos y el progreso se van visualizando al termino de cada iteracion.

Si eres consultor externo, puedes leer un poco mas acerca de la metodologia y sus practicas. Si trabajas en una compañia de software que aun no adopta esta metodologia (o peor, que no tiene procesos formales) es una buena oportunidad de presentarselo a quien debas...

Interesante, no?

De empleos a empleos

En nuestro México lindo y querido, la gente de IT en general (IT, Tecnologias informaticas) sufre bastante para encontrar un buen empleo. Un buen empleo desde mi perspectiva es donde se tiene un sueldo competente y acorde con las labores que se llevan a cabo, donde se paga puntualmente, y te dan un poco o un mucho mas que nuestras fabulosas y omnipotentes prestaciones de ley mexicanas. Y sobre todo donde te sientes a gusto trabajando. Al menos esa fue mi experiencia y la de muchos colegas que conozco al comenzar a trabajar en nuestra area.

Ocasionalmente buscando en las bolsas de trabajo en internet, nos podemos encontrar diferentes tipos de ofertas de empleo, entre las cuales "sobresalen" anuncios como el siguiente, en el cual respeto la pésima redacción para fines críticos:

Se solicita ingeniero en sistemas con los siguientes requisitos:

*EXPERIENCIA: MINIMA 3 AÑOS COMPROBABLES
-LIDER DE PROYECTO
-DESARROLLADOR DELPHI 2007 VER 2010, Win32, Net, Kylix
-MODULOS ERP
-REDES
-DESARROLLO WEB, .NET, WIN32
-ADMINISTRADOR SERVIDORES WIN´NT Y LINUX
-BASES DE DATOS; FIREBIRD, INTERBASE, SQL, SERVER, PARADOZ, DBF, My SQL
-INSTALACIÓN, MANTENIMIENTO Y ADMINISTRACIÓN DE SERVIDORES WINDOWS.
-CONOCIMIENTOS DE PROGRAMACIÓN BÁSICA EN OTROS LENGUAJES: VISUAL, BASIC,
jBUILDER, BUILDER C++, PHP, JAVA

Cual es tu impresion al ver este anuncio? Estas sorprendido? asustado? te mueres de risa...? Analicemos la oferta de trabajo con detenimiento:

• Comencemos por los 3 años comprobables de experiencia. Nosotros los programadores sabemos que en 3 años no puedes aprender todo esto. Por lo cual deducimos que el autor(a) del anuncio no tiene la mas minima idea del tiempo que toma adquirir experiencia en todo lo que pide en 3 años. En mi opinion, al menos se necesita el doble de tiempo, y aun asi no se es un experto en todas las areas.
  
• Que sepa redes. El concepto de redes es muy general y ambiguo... Que parte del campo de estudio de las redes? Quieres que tu ingeniero monte toda una infraestructura de red, conecte un modem de Telmex, configure la conexion a internet en una PC o todas las anteriores...?
• La administracion de servidores de Windows NT y Linux es una ciencia aparte. Para llegar a ser un administrador decente en solo UNO de los dos sistemas operativos (y estoy hablando sin certificacion incluida) tienes que dedicarte a la infraestructura un par de años como minimo. Tienes que ser un experto en el sistema operativo a nivel administrador, lo cual incluye (ademas del total dominio y conocimiento del sistema operativo) otras cosas como cuestiones de seguridad, certificados de red, conexiones remotas y un largo etcetera...
• Solicitan experiencia en ParadoZ, dbase, interbase, firebird, mysql, sql server... Wow. Solo un administrador de base de datos sabe tanto. Iran a hacer una migracion de sistemas de .NET y Delphi (o legacy systems) a mysql? ...O al reves???
  
• Es Paradox, no ParadoZ. Aqui hay que resaltar la importancia de la correcta escritura de las tecnologias. Y no es el unico error que hay en el anuncio. Puedes volver a leerlo si quieres.
  
• Mantenimiento y administracion de servidores windows (otra vez). Al parecer, el ingeniero en sistemas, aparte de programar y mantener a punto los servidres web, tendra que repararlos cuando algo malo suceda

En mi opinion, la persona que escribio el anuncio (que muy posiblemente sera el jefe del ingeniero al que contraten):

• Claramente no sabe de lo que esta hablando
• No sabe lo que necesita de un ingeniero
• En consecuencia, no le va a pagar ni siquiera cerca a lo que una persona que va a llevar a cabo ese gran numero de labores se merece.

Por desgracia, ese es el problema al que nos enfrentamos cientos de profesionistas en un determinado momento de nuestra vida (y muchas veces, incluso en mas de una ocasion).
En la opinion personal de su servidor, esto es lo que puedo puntualizar:

• El sueldo promedio de un ingeniero en sistemas, licenciado en informatica o afin en Mexico (que no trabaje para una compañia de IT) es de 6 a cuando mucho 12 mil pesos netos en su primer empleo, algunas veces en el segundo y en casos extremos puede tener hasta 3 empleos ganando una cantidad menor a los $12K. Incluso puede permanecer varios años sin un aumento de sueldo.
  
• En las empresas que no son de IT (entiendase oficinas, despachos contables o pequeños comercios), el "ingeniero" es el que se encarga de TODO lo referente a IT (programacion, reparacion de equipo, montado de redes, configuracion de servidores, etc.) Tal como la persona que solicitan en la vacante que acabamos de analizar. Muchas veces por un sueldo que no remunera adecuada o equitativamente el gran numero de labores que desempeña dentro de dicha empresa.

• Para muchas empresas los ingenieros en sistemas son intercambiables o desechables. Contratan a uno mientras soporte el sueldo y las condiciones de trabajo, pero jamas estan dispuestos a ofrecerle un mejor sueldo o mejores condiciones. Simplemente el dia que tiene una mejor oportunidad, lo dejan ir y contratan otro. Generalmente son empresas cuyos sistemas e infraestructuras son un caos por lo mismo. Si te encuentras una de estas, huye lo mas pronto que puedas!
  
• Al egresar de la universidad, como la mayoria de los ingenieros "no tenemos experiencia" vamos a parar a alguno de estos mencionados empleos. Lo peor es que mucha gente que no adquiere conciencia se queda en este tipo de empleos durante toda su carrera. Se estancan y nunca se desarrollan como profesionales realmente.

Lo mejor que nosotros, la gente de IT, ingenieros y licenciados podemos hacer para obtener un buen empleo es, en mi opinion, lo siguiente:

• Dignificar nuestra profesion. No prestes tus servicios por menos de lo que valen. Piensa que empleos como ese al que le estas apostando por unos cuantos pesos hay miles. Muchas veces nos vemos envueltos en ellos porque tenemos meses sin conseguir empleo, tenemos necesidades económicas que no podemos evadir y tenemos que trabajar. En todo caso, no vivas pensando que tu vida va a cambiar por intervención divina. Gana dinero, trabaja, pero al mismo tiempo busca siempre ir hacia arriba, busca un mejor empleo! Si sabes que tu empleador no hara nada por mejorar tus condiciones de empleo, ese empleo no es para ti. Simplemente no te merecen.
  
• Invierte constantemente en tus conocimientos. Nuestra área de trabajo (IT) ha estado, esta y estará en constante cambio. No te estanques. No te quedes atras. Estudia constantemente, aprende nuevas cosas, LEE! incluso acerca de aquellas que no te gustan. No sabes cuando surgira una oportunidad de desarrollo basada en esas tecnologias o cuando lo tendras que utilizar.
• Enfocate en un area de conocimiento. Esta es la teoria de David Martinez, un colega mio y de los mejores programadores que conozco. Generalmente si tratas de abarcar todo el campo de conocimiento de IT (redes, programacion y su enorme numero de lenguajes, mantenimiento, sistemas operativos, tareas de infraestructura) poco a poco tenderas a ser un experto en todo... Quiza cuando tengas 50 años. Trata de enfocarte en un area del conocimiento (digamos... programacion para moviles) y vuelvete un experto en ello. Un gran numero de compañias o clientes buscaran al experto y le pagaran lo que el cobre.
  
• Preocúpate por ser de los mejores. Siempre. La razon por la que en el tipo de empresas que mencione los buenos ingenieros no duran, es porque son de los mejores. Los mejores se van en busca de nuevos retos, los comunes se quedan, y se estancan. Haz lo posible por ser de los mejores hoy, mañana y siempre. Un lugar donde tu eres el mejor y mas experimentado ingeniero (el "experto") no aportara nada a tu carrera. Debes ir a donde tu eres el ingeniero mas novato, el menos experimentado. Si no tienes un reto no podras crecer como profesional.

Una vez dicho esto, tengo dos preguntas para ti:

• En que tipo de empresa quieres/mereces trabajar?
  

Si estas en una buena empresa que te valora como profesional, con un buen sueldo, prestaciones y ambiente de trabajo, donde simplemente estas contento. Te felicito enormemente!

Si no... Respóndete a ti mismo lo que acabo de preguntar. Analiza tu situacion y que tienes que hacer para cambiarla. Y comienza hoy. Ahorita.

Las nuevas compañias de software

Muchas veces nosotros (los ingenieros en software) nos hemos preguntado... Cual seria la compañia ideal para trabajar?

Esta pregunta nos lleva a una segunda (y mas importante que la primera): COMO seria la compañia ideal? Que caracteristicas debe de tener?

Yo me pregunte esto hace 3 años. Lo que me hizo preguntarmelo fue un correo que recibi con imagenes y una descripcion de las condiciones de trabajo de una compañia llamada google. La mayoria de la gente que se dedica a IT sabe que los empleados de google tienen muchas "prestaciones interesantes", como sofas super comodos y raros tipo puff, cuartos de juegos, lavanderia, etc. Todo por parte de la compañia... Pero ese es otro tema. Si te interesa, puedes empezar aqui. O mejor aun, googlealo!
Asi que entremos en materia. Dejenme contarles algo acerca de las compañias desarrolladoras de software "modernas" (y mas pequeñas que google) de estos dias...

Primero que nada, para este tipo de compañias lo mas importante no son los clientes. Ya no. Adivina que? Son los EMPLEADOS.

Dificil de creer, no? Quieren saber porque? Despues de pensarlo dos veces, creo que si realmente quieres entender el porque, entenderas mejor de lo que hablo si te ha ocurrido alguna (o mas de una) de las siguientes experiencias en tu vida:

• Te dedicas al desarrollo softwar
• Sabes lo importante que es trabajar a gusto
• Trabajas o has trabajado en una compañia grande de desarrollo (IBM, TCS, HP, Dell, etc.)
• Has leido al menos un libro acerca de la importancia del empleado en una compañia, como peopleware
• Tienes conocimiento acerca de lo que realmente significa el manejo de personal (o management), y que es lo que es realmente importante para los ingenieros de software.

De cualquier forma, vamos a hablar de la compañia para la que trabajo. La oficina esta ubicada en el penthouse de uno de los edificios frente a la Minerva (un punto turistico de Guadalajara, cercano al centro de la ciudad). Porque decidieron que la ubicacion de la oficina deberia ser esa? Por los empleados. Porque es un lugar centrico a donde cualquier persona que viva en casi cualquier punto de la ciudad puede llegar en un tiempo relativamente corto. Puedo decirles que la renta y el mantenimiento no son nada baratos. Esta es nuestra vista:



Genial, no? Ahora, permitanme platicarles que es lo que hace a esta compañia especial y diferente de todas las demas (ademas de la vista).

Primero que nada, cada uno de nosotros los que hacemos el software tiene una laptop personal. Y es una mac. Si, leiste bien. Cada uno de nosotros tiene una MacBook Pro, Doble Core 2 Duo con 8 Gigas de RAM. Asi como tambien cada uno tiene un monitor extra de 22 pulgadas LCD para poder trabajar. Esta es mi "oficina":


But no, wait, Wait! Why a laptop and not a desktop, if it's cheaper? Geez, laptops are really expensive. Specially macs!!!
Yeah, but having a laptop you can be mobile, you can work from your house, from a starbucks, from the tire dealer, from the car shop... From anywhere where you can find a wireless network. And maybe even from the market while you are getting your breakfast, offline of course. Developers are way more productive with a laptop, and they can work from any place on earth, anytime. Smart move.

Each one of us has his own chair (some of us, me included, have big pilates balls as chairs).



Pero a ver, porque una laptop y no una desktop? Que no es (bastante) mas barata una desktop? Ademas, las macs son extremadamente caras! Y una por developer???

Lo que muchas empresas no ven es que un desarrollador con una laptop (y no cualquier laptop) puede mantenerse trabajando en cualquier parte (en su casa, en un starbucks, de viaje, en el taller mecanico...). Todo lo que necesita es una conexion a internet. Inclusive puede trabajar aun sin internet. Desde cualquier parte del mundo, en cualquier momento. Con esto, la gente se vuelve mas productiva.

Cada uno de nosotros tiene su propia silla. Incluso algunos de nosotros (y me incluyo) tenemos pelotas de Pilates como sillas. Esto ayuda a mantener tu espalda recta y fortalecer tus musculos abdominales, ademas de romper con la monotonia clasica de las oficinas.

Tambien cada uno de nosotros tiene su propio escritorio, pero usualmente trabajamos en mesas de trabajo debido a que somos un solo equipo aunque estemos en diferentes proyectos. En esta empresa se utilizan muchas tecnicas de trabajo "nuevas" para las empresas mexicanas, como puede ser la programacion en pares, la programacion orientada a pruebas, etc. Nunca subestimes el poder de la colaboracion. Aprendemos mucho unos de otros, nos ayudamos y apoyamos unos a otros, y eso es precisamente lo que hace que un equipo de desarrollo sea tan efectivo y productivo.

Vayamos a la cocina. Tenemos una cocina llena de cosas para comer y beber (pan, corn flakes, papas, galletas, sopas, palomitas, refrescos, cervezas, vodka, tequila, ron, etc.). Todo esto va por cuenta de la compañia para sus empleados, los cuales no son muchos. Esto es posible gracias a eso, ya que entre mas crece el numero de empleados mas crecen los costos y no es tan sencillo.


Pasemos a la terraza, donde puedes salir a tomar aire fresco a cualquier hora del dia (o incluso te puedes salir a trabajar, ya que hay una mesa y sillas afuera), y donde tambien el primer viernes de cada mes tenemos kilos y kilos de carne asada y cervezas, cortesia de la compañia. Hay compañias donde ni siquiera tienes una ventana por donde entre luz natural.

Hablemos ahora del horario. Ninguno de nosotros tiene un horario fijo. Uno puede llegar a la oficina a la hora que quiera (lo cual no hacemos porque no es ni profesional ni recomendable). Pero de cualquier forma puedes llegar un poco tarde (o muy temprano) e irte un poco mas temprano, para despues reponer el tiempo en tu casa. De igual manera, si lo deseas puedes trabajar desde tu casa. Existe flexibilidad total en los horarios, siempre y cuando seas productivo.

Ok, el tour por la empresa ha terminado. Hey, esperen... Ya hable de mi sueldo y mi paquete de prestaciones? Solo les voy a decir que es superior que cualquiera de las compañias que mencione al inicio del articulo :)

Finalmente hablare de lo mejor que hay en la empresa para la que trabajo, el motivo real por el cual me quedaria varios años mas en ella: Sus ingenieros. Esta compañia tiene algunos de los mas experimentados, pragmaticos e inteligentes ingenieros en software del mundo, los cuales tambien son los mejores desarrolladores con los que puedes trabajar. Como es esto posible? La compañia es muy selecta con su personal. La compañia es un lugar para crecer, un lugar para convertirte en un mejor programador, un mejor ingeniero. Porque? Porque trabajas con los mejores. Asi que despues de un tiempo, tu tambien pasaras a formar parte de ellos. Esto no tiene precio, y ninguna compañia te lo da.

Estas son algunas de las razones por las cuales me gusta y disfruto lo que hago. En estos tiempos modernos, uno puede trabajar en compañias de este tipo con todos sus beneficios y horarios flexibles, donde no tienes que estar encerrado 9 horas en un cubiculo gris sin ventanas, donde no tienes que checar tu hora de entrada y salida, donde no te prohiben entrar a trabajar si llegas 5 minutos tarde, donde no te despiden por tonterias, y muchos otros "no's" que hacen de estas compañias los mejores lugares para trabajar. Desafortunadamente (y hasta donde yo se) solo hay 3 o 4 compañias de ese tipo en esta Ciudad. No creo que haya mas de 10 a lo largo y ancho del pais. Yo tengo la suerte de estar en una de ellas, y me encanta trabajar aqui.

Ya para terminar, lo que falta es hablar de lo que la compañia requiere de ti. Que tienes que hacer o saber para poder trabajar en una empresa como estas?

Ser un excelente programador pragmatico.

La mayoria de este tipo de compañias requieren excelentes ingenieros de software. Que es un excelente ingeniero de software (o "rockstar", como nos llaman a nosotros)? Eso es un tema para un nuevo post. Mantenganse en sintonia.

El mensaje que realmente les quiero dejar con todo esto a mis lectores es el siguiente: Existen compañias para las cuales eres y seras el elemento mas importante de la misma. Porque tu ERES la compañia. Porque tu CONSTRUYES el software. No lo hacen los jefes, ni los gerentes, ni los recursos humanos. Tu eres lo que la empresa vende. Y sin ti no hay empresa. Asi de simple. Si tu trabajo esta a mil millas de ser como el que estoy, siempre puedes buscar uno mejor... :)