E3matheus

El mundo de los startups es increible. Entre las cosas que destacan a un startup es que tienes mucha libertad. tienes un horario más flexible, buscan tener proyectos con gran impacto social e incluso parece una familia. Adoptas prácticas y metodologías no tradicionales(metodologías ágiles, testing, programar en pares). Incluso, se desarrollan ideas propias de como compartir conocimiento(apps como hubot, eventos como hackathons), proyectos open source interesantes, etc.

Ciertamente, eso es un salto considerable a lo que estamos acostumbrados. Que la compañia adopte metodologías de desarrollo y ágiles rigurosamente, que crea en open source, que ayuden a capacitar al desarrollador, no exija al desarrollador tener multiples personalidades es un gran paso.

Sin embargo, he visto ya en muchas startups el mismo problema, creen a medias en estos conceptos. Algunas frases se me vienen a la mente:

• “No hacemos wireframes, solo por esta iteración”.
• “Estamos muy ocupados para hacer una reunión diaria(scrum)”.
• “Creemos en apprenticeships, solo que no hay gente”.
• “No podemos hacer testing ahora por cuestiones de tiempo”.

Aclaro, no estoy diciendo que tengas que creer en todas estas prácticas o que tengas que ser la persona menos flexible en el mundo. Es dificil tomar un rumbo diferente a muchas de las companias que ya existen. La cuestión es que para hacer estas prácticas, se necesita un esfuerzo sostenido. Se necesita fe y formar el hábito.

No se trata de forzar estas prácticas. Tu equipo de trabajo rechazará las metodologías o ideas con las que no se siente cómodo. La cuestión es que muchas de estas ideas, para lograr que formen parte de la cultura de tu empresa, se necesita un esfuerzo sostenido. Una vez más, se necesita fe y hábitos. Antes de ejecutar una metodología o una idea a medias, dedicale un esfuerzo sostenido porque no sabes el potencial que pueda tener.

Se que esto es idealista. La cuestión es que es triste ver, en primer lugar, que se pierda tiempo considerable en un proyecto por falta de fe en principios que si funcionan, solo que necesitan un esfuerzo consistente. Y en segundo lugar, que ideas mueran por el hecho de no darles seguimiento. Necesitamos ponerle un parado a esto. Necesitamos tener más fe en nuestros principios, más disciplina para probarlos y capacidad de adaptación para entender como podemos mejorarlos.

La programación es un tema muy complicado. Cualquier persona que crea que para crear una compañia que haga software mantenible y estable solo necesita un par de buenas ideas, comprar unas computadores y contratar a una docena de programadores de una universidad de prestigio se va a llevar tremenda sorpresa.

Aqui dejo algunos ejemplos, que en algunos casos pueden chocar con el sentido común, pero si les pido revisen a ver si les hace sentido:

• La educación en el trabajo lo es TODO

La computación, no es como la música o la medicina, que tienen más de 700 años existiendo. Es una ciencia que apenas comienza. Las carreras de computación vendrán de como mucho 1950. Hay gente en las universidades enseñando del tema pero es difícil atinarle sobretodo porque cambia tan rápido. Se hace lo posible por enseñar una base, pero en mi opinión se quedan cortos. Por lo que el trabajo, forzosamente, si quiere construir software mantenible, debe convertirse en educador.

Para mi la realidad es la siguiente: si quieres construir software estable, es necesario aprender TODOS los días y con una buena base. Es decir, en lugar de aprender con Google, me refiero a aprender leyendo código, libros, escuchando podcasts, teniendo conversaciones con un buen equipo de trabajo, programando en pares, yendo a conferencias buenas, dictando cursos, construyendo comunidades, etc.

• Si necesitas más sistemas, la solución no siempre es contratar más programadores

Si hay algo que es importante entender, es la gran diferencia que puede hacer un buen programador. Dos programadores malos no equivalen a uno medio. Nunca la cantidad de programadores malos, va a compararse a un programador bueno. Si creas programas sin entender acerca del lenguaje y de los principios de computación, la cantidad de errores puede ser enorme, el tiempo que te puedes tardar debugueandolos aún más y el tiempo que te puedes tardar creando mas funcionalidades, crecerá muchísimo.

Quiero aclarar que cuando digo un programador bueno, no necesariamente me refiero a un egresado de una universidad de prestigio. Va a ser uno que tome riesgos, que tenga ganas de aprender todos los días y que tome en cuenta más crecer como equipo, que crecer personalmente.

• La habilidad es importante, pero más lo es la humildad

La habilidad puede impresionar, pero la humildad permite crecer todos los días y adaptarte con mucha facilidad. En una industria donde la comunicación es TAN vital como la nuestra, ser humilde se vuelve indispensable. No se trata de tener la mejor solución o la que corra en menos tiempo. Se trata de comunicar efectivamente lo que estás tratando de hacer y de ponerte en los zapatos del que viene despues que tú. Depende de la cultura de la empresa, pero en mi experiencia, tener a un programador bueno pero que no sea humilde puede ser un riesgo alto.

• Comunicación, comunicación, comunicación

Mucho de la programación se trata de comunicar. No se trata de hablarle a la computadora, sino de hablarle a la persona que viene despues que tu. Se trata de comunicación efectiva. Yo diría que las formas más efectivas de atacar este problema son: programar en pares, revisar el código que se hizo y tener un mentor. Consideraría un error desestimar estas actividades.

• Evita darle múltiples responsabilidades al programador

En una industria de software debería haber cuatro tipo de personalidades: un hustler, un operador, un diseñador y un programador. El hustler busca negocios y vende el sistema, el operador se encarga de las finanzas y de mantener todo en orden, el diseñador construye la interacción con el usuario, la hace natural y sencilla para el usuario, y el programador implementa la funcionalidad.

Cuando una persona acepta tomar estas cuatro responsabilidades(Ejemplo cuando aceptas tigritos), siento que se comete un error grave si es un trabajo importante. Los Wireframes son un buen ejemplo de lo que estoy hablando. Si además de una descripción de la funcionalidad que tienes que implementar, le muestras al programador como quiere que interactúe el sistema, le estás ahorrando mucho tiempo.

Para los que le interesa el tema pero que no quieran leer un post tan largo :)

Si les da mucha flojera leer todo lo que escribí(jejeje), los invito a ver dos videos(en inglés) que hablan acerca de lo que significa ser desarrollador. Aqui les dejo la parte 1 y la parte 2.

Un gran abrazo!

En el post anterior, hablé de mis experiencias en la universidad y de todo lo valioso que aprendí, aun cuando no fuera parte del curriculum de la universidad. Esta vez quiero comenterles cual es mi siguiente paso.

Cuando me fui de intercambio, un amigo me pregunto como me estaba adaptando a la carrera en México. En ese momento le dije que me sentía al mismo nivel académicamente hablando. Esto no sucedió cuando entré al trabajo. En el momento en que comencé a trabajar, me dí cuenta que el nivel de las personas que estaban ahí era mucho mejor que el mío. No me sentí preparado. Creo que se lo que están pensando: “Eso es normal”. Sin embargo, muchos conceptos me parecen fundamentales para cualquier programador que yo ni habia escuchado. No eran áreas triviales.

Aqui les dejo las áreas que en mi caso, necesito trabajar y las razones por las que siento que un postgrado no me ayudaría:

• Quiero aprender de comunicación, no tanto de eficiencia

Si bien la eficiencia es importante, no basta solo con que funcione bien. Sabias que uno se la pasa más tiempo leyendo código viejo que haciendo código nuevo. Eso implica que aun cuando funcione, cuando tengas que visitar otra vez ese código, hay una muy alta probabilidad de que pierdas tiempo más adelante y quizas lo rompas.

Desafortunadamente, siento que un modelo de exámenes y proyectos donde te evalúen en base a si tu programa funciona, no basta. Para mejorar tu comunicación lo más importante es obligarte a explicar tu código. Sea a manera de exponerlo, de tener un mentor que revise tu código, de hacer code reviews con tu equipo de trabajo, etc. ¿Sino cómo sabes si lo que hiciste otra persona lo va a entender?

Esa es una de las razones por las que el opensource es tan útil. Te obliga a tener código mantenible porque otras personas tienen que entenderlo si algo se rompe. Y también por eso me gusta tanto programar en pares, porque te obliga a explicar tu código desde el momento en que lo estas haciendo. Te obliga a escoger abstracciones entendibles, nombres de variables y metodos lógicos.

• Quiero aprender de muy buenos programadores con experiencia trabajando

Quizas en otra área, esto no podría suceder. La cuestión es que hay tantos programadores buenos que estan compartiendo su conocimiento. Están haciendo cursos en línea, podcasts, screencasts, dando charlas, tienen sus propios blogs, etc. Gente con experiencia real usando nuevas tecnologías quieren compartir su conocimiento porque saben que el estado de la industria no está bien y que se necesita compartir la experiencia para saber como se puede avanzar.

• Quiero fomentar una comunidad de programadores

Siento que las comunidades a las que quiero apuntar, están en el opensource y en los startups buenos que te rodean. La cuestión es que muchos de los programadores que hacen opensource y que estan creando software valioso, no necesariamente salieron de una escuela de computación. Asi como conozco computistas excelentes, también conozco programadores de muy buena calidad que no estudiaron computación: Matemáticos, Mecatrónicos, estudiantes de arte visual, etc. Estoy apuntando a la comunidad que esta saliendo de personas que tienen ganas de hacer software valioso, que toman riesgos y que está preparando a su personal bien para lograrlo, que no necesariamente son los que tienen un postgrado en computación.

Conclusión

Un nuevo modelo de aprendizaje es lo único que se me ocurre que puede funcionar. En buenas empresas se esta siguiendo este nuevo modelo. Donde se hacen Code Reviews, programan en pares, te obligan a explicar lo que hiciste. Te ofrecen un modelo de mentores que te puedan ayudar a tener feedback instantáneo de tu código.

Adicionalmente, Corey Haines, the software journeyman, habla de un modelo de escuela parecido a este en este artículo y en esta charla minuto 27. Iniciativas como Mendicant University seguirán saliendo porque es necesario atacar un problema real. Hay personas, como yo, que salen de la universidad(e incluso de un postgrado), sin entender aspectos fundamentales acerca de como hacer software mantenible.

Los mantendré al tanto :).

Aqui les dejo unos videos pequeños que preparé en donde relato algunas de las lecciones que aprendí durante el transcurso de mi universidad.

No esperen mucho, solo son pequeñas reflexiones informales que no quiero que se me olviden. Se las comparto a ver si les sirven de ayuda y tambien para que se animen a recordar y compartir las suyas.

• Invitación a recordar y motivación del video

• Baloncesto, Cambio de Carrera y Movimiento Estudiantil

• Centro de Estudiantes, Intercambio y últimas palabras

Aqui tambien les dejo algunos enlaces complementarios:

1. Final del discurso a los graduandos 2012 del vicerrector académico William Colmenares.

2. Generación de Espectadores de Adrian Cuadros

3. TED: Listening to shame

Les mando un gran abrazo!

No se ustedes, pero yo siempre he asumido que el hecho de que mi mamá no sepa navegar en internet es un problema generacional. Simplemente no están acostumbrados como tu y yo. Ultimamente he estado dudando de esta afirmación y preguntándome si existe algo de culpabilidad de los diseñadores, al no hacerlas lo suficientemente intuitivas.

Ahora pienso que un sitio web debe ser intuitivo para ser considerado de calidad. No se trata de crear una aplicación que tenga muchas funcionalidades o muchos efectos. Se trata de ayudar al usuario y no hacerle complicada su estadía. Tomando un ejemplo del libro super recomendado “Don’t Make Me Think”, el proceso realizado cuando estas en un sitio web no es del todo distinto al realizado cuando entras a una tienda por primera vez. Estas buscando algo y te fijas en los pasillos que tienen. Te fijas en los letreros ya que te ayudan a hacer un modelo mental.

En un sitio web, la experiencia debe ser muy similar. Debes construir la estructura del sitio para que sea fácil de entender. Y algo muy importante, debes seguir ciertas convenciones así como en la tienda se usan pasillos y letreros. Si existiera una tienda super original pero que sea muy dificil conseguir lo que necesitas, no sería muy popular.

¿A qué convenciones me refiero? Una página de inicio sencilla, un menú global, un menu local que te permita saber en donde estas, un cuadro de búsqueda preferiblemente arriba a la derecha. Si bien no son reglas fijas, son convenciones que puedes usar para que tus usuarios no se pierdan dentro de tu página y terminen con una cara como la de la niñita a continuación.

Tomemos por ejemplo las páginas de colegio en Caracas. Fijense en la página del colegio San Ignacio de Loyola. En uno que otro enlace, te dice donde estas. Es decir, si eliges ASIA, si aparece un letrero que dice que estas en ASIA. Pero si eliges “Enlaces institucionales”, ¿cómo sabes que página estas visitando?.

Fijense en la página del Colegio 12 de Febrero. Hay aspectos de esta página que me gustan. A diferencia de la página de San Ignacio, fijense que esta si tiene navegación local. Si sigues Galerías > Maraton 2011, puedes ver un menu local mostrando que llegaste de la siguiente forma: Home > Galerías > Maratón 2011. Pero por ejemplo fijanse que el enlace de “Tecnología” te lleva a un sitio muy distinto. Es como si entraras a la tienda y existiera una sección que no es parecida a la tienda en general. Vas a sentir que te perdiste.

Y así como estos errores, hay bastantes:

• Colocar música apenas entras a una página(como el caso del Emil Friedman).
• No colocar el cursor del mouse para que aparezca como una mano cuando pasas por encima de un link(Como en el caso del Champagnat).
• Colocar tantos elementos que se confunde la navegación global(como el caso de La Salle La Colina.
• Casi ninguna página de un colegio en Caracas tiene un buscador arriba a la derecha que tenga el campo de búsqueda y un botón que diga “Buscar”(No siempre se entienden cuando es un campo de texto y se asume que tienes que darle a enter para buscar).

En mi opinión de humilde programador web, pienso que si nos enfocamos en hacer las cosas sencillas e intuitivas para el usuario, nos irá mejor. Mostrar poca funcionalidad pero muy bien organizada puede llevarte más lejos. Todos estos errores los comentó no a manera de frustración, sino para que aprendamos que existe una mejor manera de hacer las páginas. Y quizas para que reflexionemos de eso la próxima vez que perdamos nuestra paciencia explicando a nuestra mamá.

Hace casi un mes, escribí un artículo acerca de las bondades que tiene aprender una nueva herramienta haciendo tutoriales en grupo y con la asesoría de gente con experiencia. Para probar este punto, organizamos un retiro de código un fin de semana(De 930 a 4:30pm). Este artículo retrata la experiencia de la ejecución de este retiro.

La meta fue enseñar las bases del framework Ruby on Rails a un grupo de 12 programadores con un rango de experiencia distinto. Para lograrla, en primer lugar, los pusimos en pareja y les pedimos que trabajaran sobre una sola computadora. Cada ejercicio que hicieran era necesario discutirlo con otra persona hasta que lo entendieran ambos. Esto permite ejercitar una parte del programador comunmente ignorada, “La comunicación”. Aquí hay que tener cuidado porque la velocidad de los participantes puede ser distinta y ademas, pueden tenderse a distraer. Nos mantuvimos observando las parejas para tratar de evitar estas situaciones y adicionalmente, las alternamos.

El segundo aspecto a tomar en cuenta, es que los organizadores (Ivan Acosta Rubio, Laura Gomez y yo), les imploramos que preguntaran cualquier duda que se viniera a la mente. De esta forma, no se estancan y no tienen que adivinar. El resultado fue un aprendizaje por ambos partes, recibimos críticas de Rails y tambien aclaramos dudas afincándonos en los principios e implementaciones del framework.

El último aspecto fue que no solo enseñamos la parte técnica de Rails. Enseñamos la cultura empresarial y las metodologías ágiles que vienen de la mano de Ruby. De esta forma, mínimo se llevaban una idea de como es el mundo en estas compañias. Con este objetivo, dimos una presentación en vivo de como funciona TDD, realizamos un pequeño tour por las aplicaciones que se usan en producción (Heroku, Pivotal Tracker, entre otros) e incluso hicimos un pequeño foro en donde nos podían preguntar cualquier cosa acerca del mundo de Rails (para qué es bueno usar Rails, que tal es la comunidad de Ruby, cuánto se gana?, entre otras cosas). El foro en particular fue bastante interesante porque contamos ademas de la presencia de un tremendo programador como Ivan, con Anibal Rojas, programador venezolano de la comunidad de Ruby y fundador de la empresa “Has Many Developers”. Anibal subió a la Universidad para observar el retiro de código (Sip… asi de cool es la comunidad de Ruby).

Ademas de las presentaciones mencionadas, el foro y el tutorial en vivo de TDD, se abarcó Rails for Zombies, tres capítulos del tutorial del libro y vimos una presentación corta de REST preparada por Ivan.

Parece mucho para un par de días, no? Si bien no todos terminaron todas las actividades, lograron aprender de la manera correcta. Lo clave para entender como se avanzó de esta forma es que se aprendió en grupo y con gente a la cual le puedes preguntar. NO es cierto que siempre tienes que aprender dándote golpes. Quisiera saber cuantas personas aprendieron a sumar solos… Cuando aprendas una herramienta, no temas pedirle ayuda a gente que sepa de la materia y reunirte con otros personas para aprender juntos. No escatimen de tiempo en aprender las bases. En la mayoría de los casos, un tutorial en línea y una aplicación hecha a los trancazos no es suficiente.

Finalmente, les quiero agradecer una vez más a los que participaron en el retiro de código. Se que no es fácil sacrificar un fin de semana para aprender una herramienta. Espero lo hayan disfrutado y sigan motivando estas iniciativas. Adicionalmente, agradezco a las personas que me ayudaron a organizarlo. A Ivan Acosta Rubio y Bellatrix Martinez de la empresa Bakedweb, quienes sacrificaron un fin de semana de sus vacaciones en Venezuela para ayudarme a mi y a los participantes. A Laura Gomez de la empresa Open English, que tambien nos apoyó durante todo el evento :). Y finalmente a Innku, por enseñarme con buenas bases.

El concepto de “Code Retreats”, viene de los denominados retiros espirituales, donde vas a un lugar distante por un día a reflexionar junto con un grupo de personas. En este caso, me refiero a un retiro para aprender acerca de fundamentos de programación. Corey Hanes, uno de los programadores insignes de rails, inventó este concepto y viaja alrededor del mundo haciendo “code retreats” de un día, enseñando los fundamentos del desarrollo y diseño de software.

Yo siento que este concepto puede ser utilizado para aprender un lenguaje de programación o un framework. Lo creo, puesto que en esencia, fue la forma en que aprendí Rails. No se si les suena familiar esta secuencia, pero esto es lo que me ocurrió a mi cuando intenté aprender Symfony, JSP y varias tecnologías por mi cuenta.

“Busqué un tutorial que me explicaba las funcionalidades básicas con una parte práctica. A medida que iba haciendo los ejercicios, me salían errores y me metía en Google para revolverlos… Revisaba el error y me trancaba. Pensaba: “Debe ser un error del tutorial”… Y me devolvia al código, trataba de arreglarlo y cuando ya no podía, me cansaba y empezaba al proyecto. Cuando empezaba a trabajar, me estancaba mucho y tenía que buscar ejemplos en línea. Copiaba, pegaba y me ajustaba hasta que funcionara. Como es de esperar, no entendía mucho de la herramienta, aun cuando le dedicaba mucho tiempo”

En el trabajo, yo aprendí Rails de una forma muy similar. Hice un tutorial de funcionalidades básicas con una parte práctica. Cometí errores varias veces tratando de saltarme pasos.. Sin embargo, terminé el tutorial en un par de días.

La diferencia mas grande fue que no estaba solo! Estaba en una mesa con programadores de distintas experiencias. Algunos tenian un par de meses, otros algunos años, y otros no tenían ni un dia (como era mi caso), pero lo importante es que había gente con experiencia a mi alrededor. Yo desestimaba mucho aprender en grupo porque sentía que iba a distraerme. Si bien había momentos en que podías distraerte, en muchos casos, eran conversaciones de errores que habían ocurrido y experiencias de las cuales podías aprender.

Lo importante es que tenías varias personas a las cuales pedir ayuda. No solo con errores, sino con dudas de conceptos básicos del framework. Podías comenzar preguntándole a otro nuevo, y si no te podía ayudar, le preguntabas a uno de los de mayor experiencia, hasta que poco a poco podías resolver el problema y podías tener una explicación completa.

No es muy pesado para los programadores con experiencia, porque generalmente son dudas de principiantes, y aún asi, entender esas dudas pueden hacer un mundo de diferencia. Además, en estos retiros aprenderías codificando, haciendo uso de programación en pares y metodologías de desarrollo como BDD, de modo que puedes tener un sentido del potencial que tienen las metodologías ágiles.

Cuando intentes aprender una herramienta nueva, mi recomendación es que no aprendas solo. Es importante darte cuenta que necesitas ayuda para avanzar como programador. Busca un grupo de amigos, gente de experiencia variada, leanse la guia y prueben por un momento esta forma distinta de aprender.