Varias personas me habían hablado de este título y era uno de los que quería leer prácticamente desde que, en 2019, terminé al etapa estudiantil y me introduje de lleno en el sector profesional del desarrollo de software. Sin embargo, no es hasta ahora (5 años después) que lo he leído. En parte, veo que estoy en un buen entorno laboral porque la mayoría de las cosas que defiende no resultan raras para mí. Por ejemplo, en mi caso no vemos los tests como un coste y somos bastante amigos de una buena metodología.

En parte por esto, considero que el título está algo sobrevalorado, no porque sea malo sino porque tenía, tal vez, las expectativas muy altas. Por un lado, porque al haber vivido ciertas cosas ya en mi propia piel, ahora me parece menos útil que el libro me las cuente. Y no es malo en sí. Muchas veces me gusta leer cosas que, sin aportar grandes cantidades de nuevo conocimiento, me ayuda a poner palabras a mi pensamiento.

Hay numerosas ideas en el libro con las que no estoy al 100% de acuerdo. No es que sean malas ideas en sí mismas, sino que son ideas que, siendo idílicas para buscar un mundo perfecto, chocan con la realidad del día a día.

El libro está bien pero hay que saber entenderlo. Digamos que hay que “leerlo con pinzas”. Lo que dice es verdad, no te voy a engañar. Pero me voy a remitir a otro libro “Manual de gestión de proyectos de software: proyectática” en el que hablan de la diferencia entre filósofos y gestores:

• “Aquellos que buscan la verdad (filósofos) y aquellos que tratan de funcionar con la readlidad (gestores) […] Los desarrollos software necesitan más de gestores que de filósofos”

Voy a traerme esta frase a mi terreno y voy a cambiar la palabra gestores por ejecutores o ejecutivos. Está bien filosofar, pero es mejor ejecutar.

Pues bien, claramente puedo encasillar este libro en un libro para filosofar sobre el desarrollo de software y, por supuesto, mucho contenido es de utilidad. Pero, sin embargo, numerosas afirmaciones deben tomarse con cautela. Los tests son buenos, pero también he vivido proyectos con demasiados tests, mal diseñados y te hace pensar que los tests no aportan (molestan, más bien). La calidad del código es necesaria, pero ciertas partes del libro, si las obecedes tal cual, pueden provocar que te pases todo el día pensando y al final no ejecutes nada. Es mejor ejecutar, fallar y aprender que sobre-pensar y no ejecutar. Así que no, no pasa nada si un día implementaste una solución un poco cutre o espagueti (en este libro parece que perderás todo tu derecho a estar en el sector si cometes esa osadía una vez en tu vida) ¿Se entiende lo que quiero decir? Deben tomarse sus máximas como normas ideales hacia las que avanzar, pero la realidad muchas veces es distinta. Por ejemplo, veremos que habla de que un desarrollador debe huir de los proyectos con pies de barro… Pues bien, puede que algún día te toque hacerte con el control de un mounstruo legacy, ¿huirás? O ¿serás profesional, afrentarás el reto y mejorarás las cosas? No todo es el último framework de javascript (sí, este libro también critica la velocidad vertiginosa a la que salen nuevas herramientas en este lenguaje y estoy totalmente a favor). Sino que también hay que saber comprometerse incluso cuando algo no nos parece ideal.

Además, ciertos capítulos se podrían unir en uno solo ya que son muy parecidos y mencionan lo mismo pero desde diferentes puntos de vista. Y también hay capítulos que les pasa al contrario, que parecen una antítesis, porque dicen lo contrario.

A continuación, destacaré algunas ideas a modo de resumen y comentaré aquellas que me parezca oportuno (tanto a favor como en contra). Podrás encontrar entre paréntesis mis comentarios personales de ciertas ideas.

Lo más destacado

Los tests son (MUY) importantes. De este libro he sacado la idea de que, cuando me involucre en un nuevo lenguaje o framework, una buena métrica para saber si lo domino con suficiente nivel es evaluar si conozco sus principales herramientas de testing y puedo hacer diferentes tipos de tests. Debo entrenar más el hábito de hacer tests cuando aprendo una tecnología. Cuando busco “como programar en react” por ejemplo, no puedo no buscar “testing con react” para, así, estar seguro de que conozco la herramienta más a fondo.

El capítulo de mayor importancia del libro es, en mi opinión, “El día a día de un buen desarrollador”.

Define un método de 3 fases que me ha iluminado en cómo enfrentarme no solo a grandes proyectos en el mundo laboral, sino también a todos esos side proyects que utilizo para hacer mis propias herramientas o aprender nuevos lenguajes.

• Comienza a abordar aquello que aún no sabes cómo se va a implementar, lo difícil, lo que no apetece, lo aburrido, lo que no te va a dar una sensación de avance vertiginoso nada más empezar.
• Tras realizar una de las partes y tenerla suficientemente probada con sus respectivos tests, comenzamos con la siguiente parte o módulo y trataremos de encontrar similitudes con las que podremos refactorizar la primera impelementación y no solo habermos implementado el segundo módulo, sino que también habremos mejorado el primero.
• El tercer paso es, cuando ya hayamos implementado numerosas partes o módulos, preguntarnos (ahora que conocemos mejor cómo se va a resolver la solución en su conjunto) qué partes son mejorables y proceder a una nueva refactorización si lo consideramos necesario.

“Las grandes mejoras de una solución no vienen dadas por un gran replanteamiento de su estructura, organización… Sino de la acumulación de pequeñas mejoras incrementales en el tiempo”

Sobre desarrolladores

El factor vocacional en el desarrollo de software es importante. (Considero que es totalmente cierto, pero como todo, esto tiene sus matices.)

Es importante cuidar la calidad, como el jardín. Si no cuidas las hierbas te toca perder N fines de semana enteros. Si lo vas tratando adecuadamente, parece que se cuida solo. Valorar el coste oculto de no hacer algo.

Buen código es código mantenible, testeable y FÁCIL DE ENTENDER.

Para destacar la importancia del refactoring, utiliza la comparación con un artista que realiza un boceto de un cuadro para evaluarlo con el cliente. Este le da nuevas instrucciones, por lo que empieza otro boceto de cero. Así sucesivamente hasta que ha tirado varias pruebas para poder construir el definitivo. En software podemos deshacer y hacer cosas nuevas cuando queramos. (Eso está bien pero tiene sus contras lo explico):

Como programador considero que mi goal principal es entregar valor en 3 frentes:

• Solucionar bugs
• Implementar nuevas funcionalidades
• Mantener la infraestructura.

Refactorizar es necesario y está muy bien, pero hay veces que el libro roza un extremo que me parece exageradamente filosófico y poco ejecutor de estar todo el día refactorizando. Más bien, yo lo entiendo como el introducir nuevas líneas lleva siempre aparejado cambiar líneas que ya existen, y punto. Interesante el concepto de revamping.

Sí, he pasado por proyectos con módulos a los que les vendría bien un lavado de cara, una refactorización. Pero, al final, el cliente dice que no quiere meter nueva funcionalidad en esos módulos, ¿para qué voy a gastar dinero si funciona bien? Y, sinceramente, tiene razón. Eso sí, yo tengo por costumbre ir comentándolo para que sepan que, el día de mañana, cuando quieran meter mano para añadir funcionalidad a esas partes, se va tener que costear un refactor previo.

¿Puedo hacer este código más entendible por otra persona? (Esto me parece super importante. He visto código que necesitaba de un senior de 30 años de experiencia en ese lenguaje para entenderlo, y todo porque el que lo hizo quería dejar claro que sabía mucho).

Un proyecto no puede considerarse de éxito solo por haber sido entregado a tiempo si el equipo que lo desarrolla está constantemente en estado de burnout. Así es imposible fomentar el ambiente de creatividad que necesita el arte del desarrollo de software.

Un buen manager debe detectar situaciones de fricción y fomentar un ambiente de cooperación y bienestar en el equipo, no debe buscar el famoso “exprimir al equipo”.

Un profesional no malgasta su tiempo en proyectos con los pies de barro. Detectar red flags para saber cuando cambiar. (Eso está bien, pero también hay que saber pegarse con el legacy y mostrar compromiso).

El programador, al igual que el autor de un cuento para niños, debe asegurarse de que su mensaje llega al lector. Debemos hacerlo sencillo y entendible hasta para niños. Evitar ser el típico desarrollador muy bueno pero que escribe código que solo él entiende. Hasta lo más difícil debe ser solucionado de manera simple. Y esto es verdaderamente la dificultad: resolver de forma sencilla los problemas más complejos. Descomponer y abstraer hasta hacerlo sencillo a grandes niveles.

Es muy fácil juzgar a posteriori el trabajo que han hecho otros compañeros […] en ocasiones no es cuestión de falta de formación o experiencia, sino la presión por terminar el proyecto a tiempo o la falta de recursos. (Me encantó esta parte porque POR FIN admite que no siempre se puede hacer lo que pretende predicar).

Es posible que incluso los clientes estén contentos, pero eso no significa que hayas hecho bien tu trabajo. ¿Tú entiendes en profundidad la mecánica del coche que te acabas de comprar? (Yo sí, y por eso es tan difícil encontrar el coche que se ajusta a mis requerimientos).

No caigas en el error de hacer algo complicado para ser imprescindible.

Debemos hacer sistemas preparados para el cambio continuo: apoyarse en trabajo de otros (librerías, frameworks…) es bueno, ahorra tiempo y aumenta calidad. Pero también hay que saber decidir. Utilizar piezas de código externas lleva riesgos intrínsecos que hay que evaluar. No hay que elegir algo porque nos apetece, sino que debe decidirse adecuadamente la elección de cada componente. Ejemplo: los frameworks de javascript que tan rápido evolucionan… (¿de verdad es necesario utilizarlos y provocar que, a corto plazo, se tengan que enfrentar a errores fruto de la falta de maduración?)

Los tests también deben ser mantenibles, legibles y simples (importante. Muchas veces olvidamos que los tests… también es código que hay que mantener).

Saber borrar o modificar profundamente partes que en su día se dieron por terminadas. (Programar, muchas veces, no es introducir más líneas, sino quitarlas!.)

No hay problema en borrar código viejo al igual que un pintor vuelve a empezar un cuadro. Vamos diseñando mejor el sistema a medida que conocemos mejor la naturaleza del problema a resolver (y conocemos más el problema gracias a todas esas posibles pruebas de concepto fallidas), borrar = avanzar. Concepto de revamp. (Me gusta el concepto de revamp pero creo que es aplicable pocas veces y en situaciones muy concretas, no debemos vender la idea de que es bueno estar todo el día haciendo refactorings extremos).

La UI es la cara visible de tu software. Cuídala. No dejes que una mala interfaz de usuario haga que las primeras impresiones de un software de calidad sean malas. Debemos buscar una interfaz ágil, sencilla de usar y con muy buen diseño. Aunque nos duela, debemos reconocer que un cliente no va a valorar lo bien que hemos resuelto algo que es realmente complejo. Además, la mayoría de las veces, las cosas que se pueden ver van a ser las principales medidas de progreso.

Se nos va a valorar más profesionalmente por los trabajos que hemos hecho (los problemas que hemos resuelto) que por conocer infinitas tecnologías.

Hay un capítulo entero (Diletantismo tecnológico) dedicado a aclarar que no debemos malgastar el tiempo en intentar conocer numerosas tecnologías y que lo realmente importante es cumplir en nuestro trabajo. (Y estoy muy de acuerdo con ese capítulo). “Solo tendremos éxito si sabemos emplear la tecnología, cualquiera que sea, para resolver un problema y aportarle valor a alguien” Lo primero es el problema. Después elegimos cómo y con qué tecnología solucionarlo. De nada sirve picotear por aquí y por allí sin profundizar mientras, en nuestro trabajo, intentamos salir del paso de la manera más rápida y menos profesional. (Este capítulo choca de lleno con la recta final del libro en la que, constantemente, nos avisa de que el mundo cambia muy rápidamente y de que no podemos buscar zonas de confort en el desarrollo de software. Y sí, es verdad. Ahora bien, si te centras solo en esas últimas partes, tendrás la idea equivocada de que tienes que gastar tropecientas horas de tu tiempo libre para estar formado y disponible siempre con la última tecnología, cuando la realidad (que expresa muy bien en este capítulo) es que una mayoría abrumadora de software, actualmente, está hecha con tecnología que los “dilentantistas” calificarían de vieja y que, probablemente, tengas que dedicar más esfuerzos a tecnologías con cierta maduración que al último framework de javascript, que ya hemos criticado previamente).

No se trata de trabajar más horas, sino de trabajar mejor. Teniendo en cuenta que el desarrollo de software es una tarea muy creativa, es fácil ver que ese estado de creatividad o inspiración no puede durar jornadas maratonianas de (mínimo) ocho horas. (Esto me gustó mucho porque, por fin, no me siento un bicho raro. Hay momentos en los que he decidido cambiar de problema o dejar de trabajar hasta el día siguiente y, gracias a eso, después encontré una solución a un problema complejo mucho más rápido de lo que lo habría conseguido obcecándome sin parar en esa inquietud)

El hecho de necesitar más tiempo de la jornada laboral es un fracaso en toda regla. (A mí esto me pasa mucho: con las interrupciones del día mal gestionadas, a menudo he tenido que quedarme más tiempo para terminar todo lo que había prometido en el daily de ese día y que, al día siguiente no quedara como que no he hecho nada). Algunos factores que provocan pérdida de tiempo:

• No sabemos qué hacer con la suficiente antelación. Un viernes a última hora, ¿sabes lo que tienes que hacer el lunes o solo esperas a que lleguen correos y empezar a reaccionar?
• Tareas no previstas. A menudo, hace hincapié en que una de las funciones más importantes de un mánager es evitar tareas imprevistas que corten el flujo de concentración de la necesidad principal.
• Factura de deuda ténica. Somos improductivos cuando una ausencia de calidad en el pasado provoca que tengamos que estar en el presente lidiando con resolver problemas que no aportan nada a la necesidad principal.
• Planificación inestable (para mí, una de las cosas que más provoca tareas imprevistas).
• Ausencia de un ambiente de trabajo adecuado para poder concentrarse.
• No dominamos la tecnología que estamos empleando. (Y sí, aquí creo que tiene razón. Sin embargo, si pretendemos estar constantemente enfrentándonos a nuevos retos y resolviendo problemas nuevos con tecnologías nuevas para estar en la vanguardia y no ser desechados del mercado, es muy normal enfrentarse a problemas de este tipo. Y esta es la parte en la que creo que más va a ayudar la inteligencia artificial en el futuro). Habla también de cómo, cuando tiene que probar una tecnología nueva, primero hace una prueba de concepto fuera del proyecto para validarlo y luego ya lo ejecuta en el código de producción. (Puedo entenderlo, pero esta es una de las partes en las que, en mi opinión, se excede de filosofar y le falta algo de realismo. Las 3 jornadas de trabajo que hayas dedicado a ese programita en paralelo para esa prueba de concepto, ¿se las facturas al cliente?¿ ¿Te las comes? ¿Las haces fuera de tu horario?) (Normalmente, salvo que queramos que una estimación de una tarea sencilla se nos vaya a un mes por feature, es imposible estar entretenidos en este tipo de cosas. Que sí, que es ideal, pero la realidad suele ser diferente.)
• Incapacidad de realizar las tareas pendientes en orden. No cambiar de tarea hasta que esté completamente terminada. (A ver, igualmente que antes, esto como filosofía queda espectacular. Pero en muchas tareas resulta que tienes bloqueos porque, hasta que no te dan algo que no depende de ti no puedes continuar (acceso a una VPN, un puerto nuevo por abrir, una clave de acceso de desarrollo a la base de datos, una cuenta de administrador del servidor en una ventana de tiempo específica…). Así que estar algo preparado para esa multitarea (que no es multitarea, sino saber no estresarse por tener que cambiar de tarea) es también importante.)

Esclavo de tu propia solución. En este capítulo detalla razones de por qué no debemos ser los únicos o los qué más saben de algo específico. Cuenta como, en el pasado, estar en una situación así le provocó pérdidas de oportunidades, ya que le habían encasillado en eso y vio pasar oportunidades de otros proyectos y otras tecnologías. (Entiendo la base y la comparto. Ahora bien, mal interpretado puede llevarnos a una falta de compromiso. Saber cambiar de aires para seguir aprendiendo no significa tener que cambiar de proyecto cada 6 meses. Creo que tanto cambio termina quemando a cualquiera (por eso es difícil ver programadores de 50 años de edad) y que no está mal, de vez en cuando, gozar de períodos de comodidad en los que conoces todo y a fondo del cliente o proyecto actual, te desenvuelves bien y, por tanto, cumples muy bien y sin que suponga una salida constante de tu zona de confort. Tampoco se trata de estar 20 años tocando el mismo código. Sin embargo, la sensación de que vamos a hacer código que abandonaremos de aquí a 6 meses ¿no provoca, en la mayoría de grandes compañías, que el código que se hace sea una basura? Si se que voy a estar 2, 3 o 5 años con ese proyecto, estoy seguro de que mi compromiso aumentará drásticamente y me pensaré dos veces antes de dar una solución cutre o de echar balones hacia delante. Es curioso cómo se fomenta ese cambio constante y, sin embargo, hablando con numerosos reclutadores, ven como una red flag si has cambiado constantemente de compañía. Y es normal, quieren saber que, cuando te contratan, te vas a comprometer con tu puesto un mínimo.)

Un buen desarrollador debe leer y analizar proyectos realizados por otros para aprender nuevas formas de resolver los problemas. Al igual que los artistas van aprendiendo de otros o los autores consiguen la excelencia tras haber leído a muchos antes, igualmente el desarrollador irá aumentando su caja de herramientas mental con nuevas filosofías de resolución de los problemas a los que se enfrenta leyendo código de otros. (Es una muy buena idea que comparto. Sin embargo, llega a afirmar cosas como “¿podría un pintor crear su propio estilo sin haber bebido de fuentes de distintas escuelas artísticas”. A ver, sí que lo veo como algo bueno pero no como algo extremadamente necesario. A menudo, en muchas cosas desde política, moral, filosofía… y también programación, me encuentro con ideas que otros han escrito antes o después que, al leerlas, yo ya pensaba previamente (antes de leerlas, me refiero). Es decir, no me hace falta leer a alguien para pensar de una manera y, muchas veces, me gusta lo que leo porque está poniendo palabras a mi pensamiento dotándome de una nueva forma de comunicar mi ideario, pero no aportando ideas nuevas. Y por lo tanto, si bien es bueno, no considero que alguien que no lo hace se convierta automáticamente en alguien fuera del mercado. Tampoco será del top 10%, claro está.)

Sobre gestión y liderazgo

Incorporar más desarrolladores en una fase avanzada cuando se ve que no se van a cumplir los plazos no es una solución que funcione.

“Una de las máximas en software es que para que la productividad sea óptima, un proyecto lo comienza y lo termina el mismo equipo. […] Nada peor que una alta rotación de personal en cualquier tarea medianamente compleja que abordemos” (Genial. Rompe el modelo clásico español de consultoría. ¿Tal vez esta sea una de las principales razones por la que el software, generalmente, da un poquito de asco? Solo sabemos decir, cuando llegamos nuevos a un sitio “lo que hicieron antes era una mierda, déjame que yo lo hago mejor”. Y el siguiente dirá lo mismo de tí…)

Para poder llevar este modelo a buen puerto es necesario una buen figura de lider. No sirve de nada si 12 desarolladores “significan doce formas distintas de hacer las cosas” Debe unificarse y estandarizarse el desarrollo.

Cuando un equipo falla es responsabilidad del manager. “Somos profesionales en la medida en que conseguimos (y nos dejan) hacer trabajos profesionales. Participando en proyectos fallidos de antemano por falta de recursos o equipos de trabajo hostiles, solo conseguiremos quemarnos y no avanzar profesionalmente.”

El mal manager es el enemigo del proyecto (Capítulo entero en el que explica muy bien qué es un mal manager, aunque hecho en falta que explicase cómo hacerlo bien. Me suena al típico “todos lo hacen mal menos yo” y resulta que tampoco haces nada distinto…)

“La excelencia del equipo de desarrollo es la tapadera perfecta del mal hacer del gestor” (Entiendo el mensaje y lo comparto, pero no siempre es así. Cuando era manager novato, agradecía tener programadores lentos que me permitían gozar de más tiempo para definir nuevo trabajo. Con programadores senior más avanzados, rápidamente detectan si estás trabajando poco o mal. Por lo que no siempre es “bueno o cómodo” contar con gente buena (si lo que buscas es hacer el vago y cobrar, claro está)).

“Un manager tiene que conocer en cierta medida la naturaleza de un desarrollo de software”. (Totalmente de acuerdo). “Debería tener una visión general importante de todo el conjunto” (Horizontalidad y perfiles T).

Un gestor debe “trabajar duro organizando y planificando, no ordenando” (Está muy bien esa frase pero no profundiza en cómo planificar bien o cómo organizar bien. ¿Debería hacerlo? Tal vez no para no volver el libro exageradamente largo pero, una vez más, al ver la queja sin la explicación alternativa, suena a queja de programador viejo “dices tú de mili…”)

“Organizar es también dividir lo complejo en tareas sencillas”.(Me gusta mucho(.

“Si un proyecto de software fracasa […] el principal responsable es el gestor”

Mantener la metodología incluso en momentos de crisis. A veces, sobretodo cuando tenemos la fecha de entrega al cuello, es fácil “no percibir la rentabilidad metodológica de aplicarla con disciplna”. Comparando el desarrollo de software con la construcción, la metodología es como los planos y documentación que debe terminarse antes de construir un edificio. La diferencia entre un amateur y un profesional radica en la capacidad de seguir la metodología y no olvidarla en la primera crisis. (Entiendo lo importante de la metodología, por supuesto. Sin embargo, citando de nuevo al libro de Proyectática, “Los equipos exitosos enfatizaban que no habían seguido métodos formales […] y que habían estimulado la comunicación y las pruebas”. Esto no significa que no haya que tener metodología (si insisten en pruebas, ya veo yo que el testing debería fromar parte importante de la mayoría de metodologías) sino, más bien, que la realidad dista mucho de la teoría. Como había introducido al principio, este es un libro que se dedica a filosofar sobre cómo debería ser un desarrollo idílico. Y eso está bien, pero hay que saber encasillar al libro y combinarlo con el realismo ejecutor del día a día).

“En la mayoría de los proyectos no hace falta un rol de arquitecto de software”. El software “es mucho más imprevisible de lo que esperamos”. Por tanto, “el único enfoque posible es hacerlo poco a poco, paso a paso”. Es un error definir la arquitectura desde el principio ya que el diseño y la arquitectura van surgiendo. En este sentido, la figura del arquitecto deja de cobrar sentido para favorecer la figura de un líder técnico, aunque no explica sus diferencias ni define exactamente qué debe hacer un líder técnico.

Ideas con las que no estoy de acuerdo

Sí, es vocacional, pero trabajamos por dinero. Soy desarrollador porque en esta profesión confluyen varios puntos: es suficientemente divertida o apasionante (para mí), me siento realizado (porque creo cosas, como si fuera un carpintero de tecnología) y se cobra suficiente como para vivir bien. No es un trabajo con el que tienes una mala vida, por así decirlo (tampoco creo que sea el trabajo en el que más se cobra). El día que cobre más moviendo cajas en un almacén sin tener que pensar y sin tener que estresarme leyendo libros y formándome en casa, cambiaré gustosamente de trabajo y la programación quedará, como el simracing y el karting, en otro hobby más.

Compara el hacer tests con el hábito de lavarse los dientes después de comer. Yo no tengo ese hábito y me parece exagerado, no es comparable. Además, al igual que he vivido proyectos sin tests, he vivido proyectos con demasiados tests. Y casi es peor. Si los tests no ayudan, tardas igual que si hubiera tests en encontrar la solución pero tardas el triple en implementarla por la cantidad de tests que rompes.

“Refactorizar, en la mayoría de los casos, supone realmente poco esfuerzo”. Por ahora es la frase en la que más en desacuerdo estoy. Sí, cuando metes funcionalidad nueva en un método pequeño seguramente sea fácilmente mejorable o refactorizable. Yo mismo estoy preparando un artículo de un refactor que me quedó muy bonito y, además, es un buen ejemplo de refactoring de calidad, mejoró mucho el diseño y costó muy poco. Ahora bien, en mi caso me he encontrado mayoritariamente con tropezones de código que querría refactorizar y que es imposible. Sí, he trabajado mucho con proyectos legacy, y estos tienen un trato especial, puede ser. Pero que pasa, ¿que solo hacemos código nuevo o proyectos modernos? ¿Quién se pega con esos módulos legacy que llevan años funcionando? Diremos lo que queramos pero eso sí que es software rentable, con sus más y su menos por supuesto. Aquí parece que si estás manteniendo un proyecto que por su envergadura no puedes refactorizar todo lo que desearías tienes que abandonarlo. Muy bien, así mañana la mitad de los bancos dejan de funcionar. Eso es total ausencia de profesionalidad. Que sí, que todos queremos tocar proyectos con métodos pequeños, con multitud de patrones bien establecidos, bien documentados. Pero eso es como el niño que quiere que los exámenes sean fáciles. Si eres profesional, lo eres en proyectos nuevos y viejos, modernos y legacy.

En la página 45 vuelve a hablar de la vocación y el amor por el software, y yo vuelvo a responder: trabajo por pasta. Lo demás está bien, pero ponme la pasta primero. Parece que a veces se olvida. El hecho, tal y como afirma en repetidas ocasiones, de que el trabjado de desarrollador sea tan creativo y, por tanto, sea tan difícil de estimar y planificar, provoca que sea un trabajo en el que sea típico estar estresado. Por tanto, lo siento mucho, el día que los sueldos bajen en proporcion al estres soportado, me cambiaré gustosamente a otra cosa. Parece que está de moda presumir de que tenemos pinpon en la oficina o de que la concilación y todo eso (que es importante, sobretodo la conciliación, por eso siempre busco oportunidades en remoto con teletrabajo 100%) pero si no pagan… (¿Te imaginas, como a los becarios, que te dicen que no te pagan porque te dejan trabajar cuando quieras? No serviría de nada, ¿verdad?

Conclusión

Hasta aquí mis comentarios y críticas sobre el título. Me parece un título altamente recomendable. Además, puedo recomendarlo tanto a novatos como a expertos.

• A los novatos: si estas empezando, es un buen libro para saber hacia dónde debes intentar llegar.
• A los expertos: léelo y ríete compartiendo las ideas que verás reproducidas y que tantas veces has vivido. Léelo con espíritu crítico, peléate con el libro y échale en cara cuando diga algo y tu pienses “este vive en un mundo de yupi. Muy bien lo de evitar los diletantismos y conocer tecnologías por doquier, pero luego me sueltas que si no hago eso estaré fuera del mercado prontísimo”. Qué pasa, ¿no se puede tener familia, hijos y disfrutar del tiempo libre después del trabajo? ¿es necesario trabajar más de lo que te pagan solo para mantenerte en el mercado? Otra cosa es que quieras ser el mejor, pero no necesitamos que todos sean los mejores.