• Se trabaja en un único problema durante todo el día (normalmente, el code retreat tiene un formato de ocho horas con una pausa para comer)
• El trabajo se organiza en sesiones de 45 minutos seguidos de una discusión de unos quince minutos sobre cómo ha ido la sesión
• Se trabaja siempre en parejas (esto es de suma importancia ya que facilitará que aprendamos unos de otros y hará más difícil que alguien se quede bloqueado)
• Antes de cada sesión se organizan nuevas parejas
• Al final del code retreat, se hace una sesión retrospectiva general sobre todo el día

Ten en cuenta el nivel de programación de los asistentes

No te preocupes si no todo el mundo consigue terminar el problema

No te cortes al introducir variantes

• Durante los quince primeros minutos, escribir todo el código posible para terminar el problema sin hacer ningún test
• Cambiar de parejas: uno continuaría trabajando su propio código y otro trabajaría con una nueva pareja sobre un código que no conoce
• Terminar el problema, esta vez haciendo TDD

• Introducción al formato de code retreat y al problema sobre el que trabajaríamos (25 minutos)
• Primera sesión: resolver el problema sin ningún tipo de restricción (una hora)
• Segunda sesión: no usar estructuras de control condicionales ni pattern matching y mantener todos los métodos/funciones lo más reducidos posibles (no más de 3 líneas de código) (una hora)
• Pausa para almorzar
• Tercera sesión: hacer el código puramente funcional (una hora)
• Cuarta sesión: trabajo sobre código hecho por otros y sin tests (una hora)
• Discusión final acerca de todo lo que hicimos durante el día, lo que habíamos aprendido y lo que nos había sorprendido más (45 minutos)

Tengo que confesar que tengo un problema: no respeto a la gente que trabaja mucho. Bueno, mejor dicho, a la gente que está siempre haciendo cosas. Bueno, tampoco se trata de respeto propiamente dicho, más bien de falta de entendimiento. Sí, creo que eso es más bien lo que me pasa: no entiendo a la gente que está todo el día ocupada haciendo cosas. Ahora está mejor (perdón a los que se hayan podido sentir ofendidos).


Profundizando un poco más en el tema, la gente que se empeña en rellenar cada espacio libre que les queda en la agenda para hacer todavía un poco más de no sé muy bien qué realmente me desconcierta. En mi mente, eso se corresponde con un esquema de pensamiento industrial que considera que lo más costoso es tener una máquina parada así que asegurémonos de que las máquinas estén siempre funcionando, haciendo algo, si es preciso organizando turnos, para que no paren nunca de producir.

Pero mi visión es diametralmente opuesta a ésa. Yo no veo ninguna maquinaria súper cara que haya que mantener todo el día en funcionamiento para que sea rentable y, por lo tanto, el tiempo ocioso no implica para mí una pérdida de dinero (ni de productividad) sino más bien al contrario. Para mí, el tiempo desocupado significa otra cosa bien distinta: significa oportunidad. ¿Oportunidad para qué? Para hacer algo que marque la diferencia, algo único, original, que sobresalga, y hacerlo realmente bien. Sinceramente, no me imagino haciendo algo de verdadero impacto si me paso veinticinco horas al día atareado con mil cosas. Y no quiero decir que sólo quiera dedicarme a hacer las partes más bonitas, chulas e interesantes de un proyecto o empresa en la que nos hayamos embarcado ni que le tenga tirria al trabajo duro y la dedicación a los detalles más oscuros y desagradables. Ciertamente creo en el valor del trabajo duro por encima de todo. Una vez que tienes definida una meta y sabes adónde quieres llegar, lo que debes hacer es trabajar duro hasta conseguirlo, tanto como sea necesario.

Pero también creo que hay que tener tiempo y cierto espacio mental para poder estar atento a la próxima oportunidad que se presente. Porque se van a presentar oportunidades, y muchas veces no somos capaces de verlas porque estamos ocupados haciendo otras cosas.

Creo que, en definitiva, el problema es que existe cierta confusión entre:

• Ser eficaz
• Ser eficiente
• Estar ocupado

Y el orden en que he escrito estas cosas no es casual: mi principal objetivo es siempre ser eficaz (porque quiero conseguir cosas). Si puedo conseguirlas empleando menos recursos, es decir, si puedo ser eficiente, estaré más contento. Pero eso es opcional, un segundo paso. Porque si he exprimido al máximo mis recursos para no conseguir lo que quería (o, peor aún, para conseguir algo que no es lo que quería), entonces no voy a estar nada contento. Y, por supuesto, lo último que quiero es estar ocupado.

Muchos confunden eficacia y eficiencia, y creen que ésta significa estar siempre ocupados

Estar ocupado es una consecuencia de los objetivos que quiero conseguir y los medios que tengo a mi disposicion. Quizá estoy intentando conseguir algo muy difícil o muchas cosas al mismo tiempo (cuidado, la pérdida de foco es otro problema importante, pero de ese tema podemos hablar otro día) o quizá no dispongo de todos los recursos que quisiera para poder alcanzar mis objetivos. Entonces estaré muy ocupado trabajando para conseguir lo que quiero. Pero, por lo general, ése no es un estado en el que me quiera encontrar, y mucho menos todos los días de mi vida.

Desgraciadamente muchos confunden la eficacia con la eficiencia, priorizando esta última, que, además, creen que significa estar siempre ocupados. Es una forma de conseguir cierta paz mental al poder decirnos por la noche: "Hemos estado todo el día trabajando a destajo. No hemos parado ni un momento." Y así creemos que podemos estar tranquilos porque no se nos puede reprochar nada cuando lo hemos dado todo. Pero al final llega el día en que nos damos cuenta de que no hemos conseguido ninguna de las metas con las que soñábamos y nos preguntamos cómo fue posible, si estuvimos trabajando tanto.

Cuando veo a alguien que se pasa los días súper atareado haciendo mil cosas sin parar como si no hubiera un mañana tengo la tentación de preguntarle:

• ¿Qué estás haciendo ahora mismo?
• ¿Cómo lo estás haciendo? ¿Se podría hacer de otra forma que te llevara menos tiempo?
• Y, sobre todo, ¿para qué lo estás haciendo? ¿Qué vas a conseguir con ello?
• ¿Podrías estar haciendo otra cosa que realmente te aportara más de lo que estás haciendo ahora mismo?

Pero siempre me contengo y, al final, no digo nada. Al fin y al cabo, ellos están muy ocupados y probablemente no tendrán tiempo para escuchar a nadie.

Hay algo que está muy extendido entre los desarrolladores de software: la tendencia natural que tenemos a pensar siempre que existe un lugar de trabajo mejor que donde estamos. Sólo tenemos que encontrarlo para ser felices para siempre, al menos, laboralmente.

Lo cual, traducido a nuestras carreras profesionales, tiene su traducción en creer firmemente que la empresa donde trabajamos es una basura, que las condiciones son horribles, que el trabajo se hace mal (y que, en otra parte, existe una empresa donde las cosas se hacen realmente bien, donde nos sentiremos valorados, nos pagarán como nos merecemos y donde las condiciones serán tan buenas que ir a trabajar será mil veces mejor que irnos un mes de vacaciones a las Maldivas).

Normalmente este pensamiento no aparece instantáneamente nada más empezar a trabajar en una empresa. Algunas veces es un hecho concreto lo que lo dispara (una promoción que se nos ha escapado, un aumento de sueldo que no ha llegado, una discusión con nuestro jefe) aunque lo más habitual es que sencillamente se vaya formando en nuestra mente poco a poco, conforme la rutina empieza a impregnar cada aspecto de nuestro trabajo diario y la magia de estar en un sitio nuevo donde descubres algo todos los días se va perdiendo.

A partir de entonces empezamos a disfrutar cada vez menos de nuestro trabajo y, probablemente por ello, nos sentimos menos motivados. Lo que suele resultar, en casi todos los casos, en que nuestros resultados son peores. A veces, mucho peores (he visto a desarrolladores a los que consideraba genios hacer auténticas chapuzas y darme cuenta al final de que el problema estaba en que no se sentían motivados cuando las hicieron). Por supuesto, conforme los resultados son peores, la valoración que otros tienen de nosotros es peor, la promoción que esperábamos no llegará, tendremos cada vez más broncas con nuestro jefe, nuestro sueldo seguirá siendo igual de miserable. Y todo ello hará que cada vez nos sintamos más resentidos con nuestra empresa y más amargados en nuestro trabajo.

Pero no pasa nada, porque sabemos que existe ese otro sitio donde las cosas nos irían mucho mejor instantáneamente por la sencilla razón de que es un lugar mejor. Y entonces empezamos a buscar otro trabajo… de nuevo. Porque no es la primera vez que andamos buscando ese sitio. Es la misma búsqueda que hicimos la última vez que nos pusimos a buscar un nuevo trabajo (y que a lo mejor pensamos que había terminado cuando encontramos el trabajo donde estamos ahora). Si eres sólo un poco más listo que la mayoría de la gente ya te habrás dado cuenta de que tampoco va a ser la última vez que lo hagas.

Y así nos pasamos muchos de nosotros nuestra vida profesional, saltando de una empresa a otra regateando beneficios sin ser feliz en ninguna parte, hasta que llega el momento en el que empezamos a valorar más otras cosas como la estabilidad -por convencimiento o por pura necesidad. Y dejamos de buscar, no porque pensemos que hemos llegado al lugar correcto, sino sencillamente porque sabemos que ya no podemos seguir más adelante. Y terminamos en un lugar que no nos gusta, donde no disfrutamos ni un solo segundo que pasamos en él y de donde sabemos que ya no vamos a salir fácilmente.

Vale, estoy siendo un poco dramático pero quién puede decir que no reconoce un patrón parecido en su carrera o la carrera profesional de otros. Y, ¿realmente tiene sentido que sea así?

Rompiendo el círculo

Lo primero que tenemos que hacer para romper esta espiral de insatisfacción es darnos cuenta de una verdad: no existe la empresa perfecta. Sólo tienes que pensar en que la gente se va de Google porque está absolutamente quemada. Sí, los mismos que trabajan en esas oficinas tan chulas con salas de reuniones super guapas, restaurante propio donde te dan de comer chefs y te prepara el café que quieras un barista profesional, además de cobrar una pasta gansa, se terminan marchando porque están insatisfechos, aburridos, estresados, quemados.

¿Crees que serías más feliz si en vez de trabajar en tu empresa actual lo hicieras en Google? Pregúntales a los que se marcharon de Google (posiblemente te dirán que se fueron para trabajar en una empresa mejor). ¿Crees que vas a ser más feliz por trabajar en otra empresa? Puede que no porque las condiciones son sólo una parte pequeña de la ecuación de la satisfacción laboral. Cuanto antes te des cuenta de eso más tiempo tendrás para realmente planificar cómo quieres que evolucione tu carrera.

Conócete a ti mismo

Empieza por preguntarte qué es lo que realmente quieres conseguir de tu carrera profesional. ¿Te gustaría por encima de todo trabajar para una gran empresa? ¿Valoras más poder compartir tu lugar de trabajo con gente super inteligente? ¿Te gustaría dedicarte a gestionar en lugar de a hacer cosas por ti mismo? ¿Quieres trabajar en tu propia idea?

Mucha gente con la que he hablado no sabe en qué quiere que se convierta su carrera profesional. Muchos tienen dudas, les cuesta decidir, algunos ni siquiera se lo han preguntado. Y eso es lo que realmente nos hace infelices en el trabajo la mayoría de las veces.

Por eso, da igual lo que quiera que escojas, debes escoger algo y tener presente que no se puede tener todo. Si nos hicieran por separado cualquiera de las siguientes preguntas:

• ¿Te gustaría que tus compañeros de trabajo fueran personas super inteligentes de las que pudieras aprender todos los días?
• ¿Te gustaría trabajar en algo con un impacto global que potencialmente afecte a millones de usuarios?
• ¿Te gusta ver que tu trabajo diario tiene un impacto directo en los resultados de tu compañía?
• ¿Quieres ascender la escalera corporativa y llegar a ocupar el cargo con mayor responsabilidad posible?
• ¿Quieres desarrollar tu propia idea (revolucionaria) y cambiar el mundo?

Posiblemente responderíamos que sí a un buen número de ellas. Pero, puestas todas juntas, es imposible decir que sí a todas a la vez (al menos, de una forma realista). Sencillamente son cosas diferentes, en muchos casos contradictorias, que requieren seguir caminos divergentes para alcanzarlas. Así que tenemos que decir que sí a unas pocas cosas y empezar a decir que no a muchas otras.

Y empieza a moverte

Y cuando ya sepas adónde quieres ir entonces es el momento de empezar a moverte, de buscar siempre mejores oportunidades para seguir desarrollándote de la forma que has decidido hacerlo. Puede ser que un trabajo te dure unos pocos meses hasta que cambies a otro o bien que continues en la misma empresa durante años. En cualquier caso, cada paso que des lo harás convencido de que te acerca a tu objetivo. Y si tu objetivo cambia, no pasa nada, ajusta tu plan y empieza a ponerlo en marcha.

Los planes son inútiles, pero planificar lo es todo.

No ocurre nada si cuando llegas a una entrevista de trabajo presentas un curriculum que demuestra que durante 5 años quisiste ser experto en inteligencia artificial y durante los dos años siguientes cambiaste porque querías ser scrum master o agile coach. No se puede decir lo mismo si cambiaste diez veces de empresa para conseguir dos días más de vacaciones o una silla más cómoda.

Para quien navega sin rumbo ningún viento es favorable.

Hace un tiempo un amigo me pidió que le recomendara algunas lecturas apropiadas ahora que se iba a dedicar oficialmente a ejercer como arquitecto de software (¿todavía alguien quiere ser arquitecto de software?). Al final, nunca le envié la lista pese a que me pareció una pregunta de lo más interesante.
Ahí van mis diez lecturas recomendadas para cualquier ingeniero de software, en ningún orden en particular:

• Zen and the Art of Motorcycle Maintenance. Quizá no era lo que esperabas pero te aseguro que este libro cambió radicalmente mi visión acerca del desarrollo de software. Absolutamente imprescindible.
• Design Patterns: Elements of Reusable Object-Oriented Software. Creo que no es ninguna sorpresa que recomiende la lectura de este libro. Completa. De principio a fin. Por favor.
• Analysis Patterns: Reusable Object Models. Un clásico que te ayuda a pensar en sistemas orientados a objetos que nunca deja de estar de actualidad pese a la fecha de su publicación.
• Clean Code: A Handbook of Agile Software Craftsmanship. Ahora que está tan de moda el moviento de software craftsmanship se hace más necesaria que nunca la lectura del mejor libro de uno de sus más firmes impulsores.
• Extreme Programming Explained: Embrace Change. Para los que piensan que la programación extrema es algo que ha pasado a la historia y que son otras metodologías ágiles están más de moda, me gustaría recomendarles una lectura rápida. Después de eso, no hay mucho más que decir.
• Writing Effective Use Cases. Y para los que lo piensen, no, los casos de uso no han pasado de moda. Ni tampoco están reñidos con las metodologías ágiles, sólo hay que echarle un ojo a la biografía del autor para verlo.
• Domain-Driven Design: Tackling Complexity in the Heart of Software. Organiza tu software entorno a lo realmente importante: el dominio.
• Refactoring: Improving the Design of Existing Code. Porque las cosas nunca salen bien a la primera.
• Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Le tengo un especial cariño a este libro por haberme salvado tantas y tantas veces en las que he tenido que pelearme con las integraciones más raras, complejas y, en ocasiones, absurdas, que tenido que hacer en mi vida.
• Patterns of Enterprise Application Architecture. Este libro te introduce los bloques básicos para poder construir software de verdad basado en principios sólidos de diseño.

No es una lista exhaustiva ni son todos los libros que te recomendaría. Podría haber incluido en la lista xUnit Test Patterns: Refactoring Test Code o The Pragmatic Programmer: From Journeyman to Master. O tantos y tantos grandes libros que hay. Pero, sinceramente, creo que si llegas a leerte todos estos libros y te dedicas de forma habitual al desarrollo de software siguiendo lo que en ellos se dice, habrás alcanzado el punto en que te convendría mucho más leer cosas no relacionadas tan directamente con el desarrollo del software. Anque ése es otro tema del que hablaremos en el futuro.

Notas finales

Para que no sirva de excusa el tema del idioma, os dejo los siguientes con sus enlaces a la edición en español:

Ahora viene la parte que hace que esto tenga algo que ver con tu carrera profesional. La persona que va a leer tu currículum y decide si contratarte o no también está buscando aumentar beneficios o reducir los costes. Después de  lo que hemos visto arriba debería ser algo bastante evidente,  ¿por qué se nos olvida tantas veces? Y a la persona que te paga no le interesan las arquitecturas limpias, utilizar lenguajes de programación de moda, frameworks chulos, el software craftsmanship ni resolver problemas complejos que constituyen un reto para tu mente de ingeniero. Aumentar los ingresos. Reducir los costes. Ése es su interés y lo demás son sólo medios para conseguirlo. Así que no te sorprenda que te a ti te vea como una pieza de la que espera que, encajada dentro de su equipo, haga que algún coste se reduzca o que los ingresos aumenten.

Y tradicionalmente los ingenieros son en sí mismos centros de costes, y bastante caros, por cierto. Y cuando tú mismo eres un centro de costes muy caro para una empresa te estás poniendo una diana para que todas esas mentes maquiavélicas que tienen un MBA o creen que saben dirigir una empresa empiecen a pensar cómo quitarte de en medio. Así es como aparecen ideas tan interesantes como el outsourcing. (Por cierto, nunca he escuchado que ninguna empresa haya externalizado su departamento de ventas. ¿Empiezas a ver la diferencia?)

Si te pones la etiqueta "programador" lo que estás diciendo sobre ti es "soy un peón muy caro que pica teclas". Y creo que esa no es la mejor idea sobre ti y tu trabajo que quieres que alguien se quede, ¿verdad?. Al menos, no lo es si quieres ser valorado (o sea, ganar más dinero). En vez de eso, intenta describir cómo has ayudado a las empresas en las que has estado anteriormente a reducir costes o aumentar los ingreso. Y si no has tenido oportunidad de hacerlo aún, busca una descripción que sugiera que eres capaz de hacerlo en el nuevo puesto que ocupes. 

Analista es mejor descripción que programador (y, piénsalo, seguro que has estado haciendo un montón de análisis hasta ahora aunque nadie te haya llamado así). Desarrollador es mejor que programador (si encima has desarrollado la solución que ha hecho ganar un montón de dinero a esa empresa en la que trabajaste, dilo). Arquitecto es mejor que programador. Creo que lo único peor que programador es progamador Java (además de ser un coste, tienes un ámbito de trabajo limitado).

A lo mejor ha sido algo que no has tenido en cuenta. ¿Te ha ido bastante bien hasta ahora sin prestarle atención? Sencillamente has tenido suerte de que alguien te haya estado viendo como un activo en lugar de como un coste (aunque si ignorabas esto, seguramente tú no hayas puesto mucho de tu parte y podrías haber ganado mucho más dinero si lo hubieras hecho).

Creo que inconscientemente casi todos saben esto. Al fin y al cabo, muchos queríamos promocionar rápidamente a categorías como analista dentro de las consultoras porque, de alguna forma, pensábamos que era mejor. ¿Mejor trabajo? ¿Más prestigio? ¿Quién sabe? Definitivamente, más dinero, sí. Pero ahora ya no debería preocuparte tanto siempre que sepas explicar lo realmente importante.

Grábalo en tu mente: reducir costes y aumentar ingresos. Eso es lo que le interesa a quien te paga así que es mejor que también te interese a ti. Y que seas capaz de reflejar ese interés.

A continuación comento las diez cosas que todo el que se dedique al desarrollo de software de una forma más o menos profesional debería saber (junto con una breve descripción):

1. Análisis y diseño orientado a objetos. Para que tus sistemas consistan en grupos de objetos relacionados que interactúan entre sí en lugar de un remix de líneas de código en un estilo pseudo-procedural. Si además representan el negocio de la aplicación, mejor :). Por eso, hay que tener claro qué es el análsis y diseño orientado a objetos, principios SOLID, Domain Driven Design... Si algo de esto te suena a chino, deberías empezar por el principio. Créeme, desarrollarás más rápido, tus sistemas serán más mantenibles y podrás reutilizar muchos más componente. Fundamental.
2. Patrones de diseño. Porque hay que conocer las soluciones que ya existen para esos problemas que siempre se repiten.
3. Refactorización. Porque nadie es perfecto y el software que hace uno menos, es necesario conocer las técnicas que te permiten arreglar ese pequeño lío que has formado (o que te han formado).
   
4. Estructuras de datos y algoritmos. Porque a veces hay que hacer algo un poco más complicado que recorrer una lista y no todo se puede resolver con un algoritmo de fuerza brutal. ¿No te suena? Entonces deberías probar a hacer "divide y vencerás", "programación dinámica", crear estructuras de grafos para aplicarles algoritmos conocidos, etc.
5. Notación UML. Porque nadie trabaja solo y, a veces, hay que entenderse con otros (o con uno mismo). Eso sí: nunca intentes generar código a partir de un diagrama (LOL).
6. Fundamentos de sistemas operativos. Pocas cosas hay más tristes que sentarte con un desarrollador y que te diga que no sabe abrir una conexión SSH con el servidor o que no conoce el comando para listar los ficheros de un directorio en Linux porque "él trabaja con Windows". Lamentable.
7. Testing (automatizado). "Todo el software es culpable hasta que se demuestre lo contrario". Así que, si quieres que alguien confíe en tu software, tedrás que demostrarlo. Haz pruebas que demuestren que funciona bien. ¡Y si son automatizadas, mejor!
8. Gestión de dependencias. Al final, o desde el principio, mejor dicho, tienes que trabajar con librerías de otros. Asegúrate de que sabes controlarlas y no son ellas las que te controlan a ti.
9. Sistemas de control de versiones. Si no quieres perder tu trabajo y además ser capaz de colaborar con otros desarrolladores, tienes que conocer las herramientas que te premiten compartir software. Si encima utilizas Git o Mercurial, podrás llamarte Desarrollador, así, con mayúsculas.
10. Patrones arquitectónicos. Para organizar el software a gran escala, hay que tener una visión global del código y por dónde quieres que crezca. ¡Dale forma a tu código!

¿Qué añadirías tú a la lista? Se aceptan sugerencias.