# Opinions

Don’t make everybody busy from day one. Use the first stages of a software
project to facilitate mob programming sessions and create a shared
understanding.

Embrace some early duplication. Use the first few weeks to explore the problem
space and try different approaches. Removing duplication is often easier than
dealing with flawed architectures.

Optimize for short feedback loops. Trunk-based development, test-driven
development, or continuous deployment are techniques that guide the team toward
this objective.

For your initial test suite, optimize for confidence rather than speed (you can
always fix performance later). That usually means creating more
acceptance/integration tests than unitary ones. Also, tests of higher
granularity levels help to develop test-friendly software systems.

When writing documentation, use how-to guides (how to execute a background job,
how to log analytics events) and architecture decision records (so everybody can
understand the WHY of certain design decisions).

Tackle the tasks with the most uncertainty first.

Simple !== Easy, but beware, they are often confused (perhaps because simple
solutions are harder to design and implement).

Good software design **always** pays off.

Slice the work wisely. Rather than slicing by technical layers (for example,
creating one task for front-end work and another for back-end work), use slices
that make business sense and provide value (i.e., the minimum viable feature).
Vertical slices enable shorter feedback loops and reduce integration problems.

If using a pull-requests-based workflow, avoid the notion of one feature = one
pull request. Use _stacked_ pull requests to generate smaller reviewable units.

Keep your options open, especially at the beginning. Use the
[Last Responsible Moment](https://blog.codinghorror.com/the-last-responsible-moment/)
technique to drive your decision-making process.


Opinions

React

# Adding an RSS feed to a Next.js site

Really Simple Syndication (**RSS**) has been a pretty popular format for
syndicating and publishing content on the web. Still, platforms don’t usually
provide an out-of-the-box solution to adopt it.

For Next.js projects, specifically, I’m sure there are probably thousands of
articles explaining how to do it (and probably a handful of `npm` packages,
too!), but in this post, I will try to outline my own approach to this problem
to add [RSS capabilities for this very same blog](/feed.xml).

## How to build the RSS feed

The only thing I didn’t want to do was study the
[RSS](https://validator.w3.org/feed/docs/rss2.html) or
[Atom](https://validator.w3.org/feed/docs/atom.html) spec myself to know how to
create a valid document. For that reason, I browsed the web looking for a
well-maintained `npm` package that could help me externalize part of the work.

[`jpmonette/feed`](https://github.com/jpmonette/feed) ticked all the boxes (some
recent commits, a good amount of stars, and TypeScript support), so I installed
the package and started coding the `RssFeedGenerator` class.

The `RssFeedGenerator` is a simple TypeScript class that receives an array of
paths and gets all the posts that live there. Then, it makes minor adjustments
(flat the collection of posts, order by date) and uses the `jpmonette/feed`
package to return a valid atom feed string. Since this blog is open-sourced, you
may see the actual code for this class in
[`codecoolture/codecoolture.com`](https://github.com/codecoolture/codecoolture.com/blob/fdcbcd2ff6307f5fb42ec463b2547e572edf8047/bin/rss/RssFeedGenerator.ts).

```ts
export class RssFeedGenerator {
  constructor(private paths: string[]) {}

  public async generate(): Promise<string> {
    const feed = new Feed({
      /* Add some feed configuration */
    });

    const allArticles = await Promise.all(
      this.paths.map(async (path) => {
        const repository = await MarkdownRepository.fromDirectory(path);

        return repository.all({ drafts: false });
      }),
    );

    const articlesFromNewestToOldest = orderBy(allArticles.flat(), "date", [
      "desc",
    ]);

    for (const article of articlesFromNewestToOldest) {
      feed.addItem({
        /* Add properties for each item */
      });
    }

    return feed.atom1();
  }
}
```

The `RssFeedGenerator` does not know by itself what the paths are, so it expects
them to be injected during initialization. This decision was driven by my
approach using test-driven development since I wanted to create different
fixtures to test different scenarios without relying on the actual production
data (posts may change title, date, or even get deleted!).

Design-wise, injecting the RSS feed generator would also be desirable, so we
could rely on our own abstractions rather than having this code coupled to a
third-party library. Still, the use case is so simple that I decided to skip the
extra work (I hope it does not bite me in the future!).

## How to integrate `RssFeedGenerator` with Next.js

At this point, this site uses `next export` to build a static website.
Therefore, I couldn’t rely on some of the more advanced Next.js features such as
[API Routes](https://nextjs.org/docs/api-routes/introduction) or even
[middlewares](https://nextjs.org/docs/advanced-features/middleware). So instead,
I decided to integrate the RSS feed generation within the Next.js build by
adding a new `npm script` that executes `bin/rss/index.ts` (a TypeScript script)
and creates a `RssFeedGenerator` instance with the right content paths, using
its output to save a file inside the Next.js `public/` folder. This is what the
script and the new build command look like.

```diff
-    "build": "next build",
+    "build": "yarn build:rss && next build",
+    "build:rss": "NODE_ENV=development yarn ts:exec ./bin/rss/index.ts",
```

```ts
import { writeFile } from "node:fs/promises";
import { join } from "node:path";
import { getConfig } from "../../config";
import { RssFeedGenerator } from "./RssFeedGenerator";

(async function run() {
  const generator = new RssFeedGenerator([
    getConfig().writing.articles,
    getConfig().writing.notes,
  ]);

  const feed = await generator.generate();

  await writeFile(join(__dirname, "../../public/feed.xml"), feed);
})();
```

With all these pieces now working together, new deployments of this site will
always create a valid RSS feed that can be found at [`/feed.xml`](/feed.xml),
keeping the static nature of the website and leveraging a more sophisticated
build process.

What do you think if we make good use of this new feature and subscribe to the
RSS feed? 😃


Adding an RSS feed to a Next.js site

# Quarterlinks #9: Q3 2021

## Career Framework

Una buena parte de este tercer trimestre la dediqué a diseñar una primera
iteración del career framework para el equipo de ingeniería de PrivacyCloud.
Muchas empresas tecnológicas tienen públicos estos documentos así que, como no
podía ser de otra manera, aproveché la oportunidad para leer un montón de ellos,
aprender y tratar de implementar uno que recogiese con acierto nuestras
expectativas de cada rol (siempre, claro, adaptadas al propio contexto y cultura
del equipo y la empresa).

Además de un índice muy útil como [progression.fyi][progression.fyi], os dejo
por aquí los cinco ejemplos que más me han gustado (tanto por su filosofía, como
por su explicación y diseño de cada camino y nivel).

- **[Career Ladders by Sarah Drasner][career-ladders]**: es un punto de partida
  fantástico para diseñar un career ladder para un equipo de ingeniería: define
  cada rol con 4-5 puntos que ejemplifican los comportamientos y expectativas,
  huye de la trampa de un checklist y explica con bastante acierto cómo encaja
  el rol de Tech Lead (en mi experiencia, muy ambiguo) en todo esto.
- **[Engineering levels at Carta][carta]**: lo más interesante son las partes
  donde explican el razonamiento y filosofía detrás de su framework (_fairness_,
  _compensation_, _career progression_).
- **[Dropbox Engineering Career Framework][dropbox]**: su definición de impacto
  y cómo articulan todo el framework alrededor de este concepto.
- **[Engineering Levels at SoundCloud][soundcloud]**: es bastante conciso y me
  ha ayudado a no irme por las ramas (_keep it simple_).
- **[CircleCI Engineering Competency Matrix][circleci]**: es, de los cinco, el
  que mayor exhaustividad muestra a la hora de definir las compentencias en
  diferentes niveles. Personalmente, no he seguido su enfoque, pero me ha
  ayudado a perfilar algunas ideas.

> Si quieres echar un vistazo al Career Framework de PrivacyCloud,
> [escríbeme](mailto:sergio@codecoolture.com), cuéntame un poco sobre ti y
> estaré encantado de enviarte una copia!

## 🛠 Código

- **[`searls/todo_or_die`][todo]**: no sé si sería buena idea utilizarlo en una
  proyecto _real_ pero me ha encantado la idea: ¿qué te parece si esos `TODO`
  que NUNCA resuelves empiezan a lanzar excepciones pasados N días? 😄

```ruby
class UsersController < ApiController
  TodoOrDie("delete after JS app has propagated", by: "2019-02-04")
  def show
    redirect_to root_path
  end
end
```

- **[`radix-ui/colors`][radix]**: me gusta crear interfaces usables, accesibles
  y bonitas a pesar de no tener conocimientos de diseño (más allá de los
  adquiridos con la experiencia), así que recursos como este siempre me parecen
  oro. Radix UI tiene un módulo de colores que puedes instalar de manera
  independiente y que, más allá de tener unas escalas muy bonitas, tiene una
  documentación ❤️ que te ayuda a decidir qué tonos tienes que utilizar en cada
  momento (como fondo cuando el elemento tiene el `:hover`, como borde cuando el
  elemento no es interactivo, como color de texto, etc.). Simplemente funciona.

## 🎱 Bola extra: Love, Death & Robots

Netflix produce esta pequeña joya de animación. Son 2 temporadas con capítulos
muy cortos (algunos no duran más que unos pocos minutos) que muestran diferentes
distopías donde, cada vez más, los humanos tienen que compartir su vida con
avances tecnológicos de todo tipo.

[progression.fyi]: https://www.progression.fyi/
[carta]:
  https://medium.com/building-carta/engineering-levels-at-carta-d33db2a55a20
[dropbox]: https://dropbox.github.io/dbx-career-framework/
[soundcloud]: https://developers.soundcloud.com/blog/engineering-levels
[circleci]:
  https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo/edit#gid=0
[career-ladders]: https://career-ladders.dev/
[todo]: https://github.com/searls/todo_or_die
[radix]: https://github.com/radix-ui/colors


🔗 Quarterlinks #9: Q3 2021

# Quarterlinks #8: Q2 2021

Qué mejor manera de arrancar el verano que con una buena colección de enlaces y
recursos interesantes 😃

## 💻 Blogposts

- **[An incomplete list of skills senior engineers need, beyond
  coding][skills]**: típico ejemplo de post cortito pero con mucho contenido
  para reflexionar. Y es que medir el _seniority_ únicamente por las habilidades
  técnicas es simplificar demasiado el impacto que ~~podemos~~ debemos tener.
- **[About Derek Sivers][sivers]**: bueno, no es exactamente un blogpost pero...
  esta página en la web de Derek Sivers me ha gustado mucho, especialmente
  después de haber leído su libro (Anything You Want -como comenté en el
  [anterior Quarterlinks](/notes/quarterlinks-q1-2021/)). Sin duda, Derek es una
  persona con las ideas muy claras y una manera de entender el trabajo (y la
  vida) muy interesantes. Revisando también
  [su lista de libros favoritos](https://sive.rs/book), me he encontrado con
  varios libros que he leído también en los últimos meses: _The Obstacle Is the
  Way_ de Ryan Holiday, _Mindfulness in Plain English_ de Bhante Gunaratana o
  _Meditations_ de Marco Aurelio.
- **[I could build this during the weekend][weekend]**: ¡culpable! Sirva este
  post como recordatorio de todas las complejidades subyacentes a la hora de
  desarrollar un negocio y un producto digital.
- **[My thoughts about the Principal role][principal]**: es un rol que aparece
  en empresas de gran tamaño y del que no había leído (aún) demasiado.
- **[JWT should not be your default for sessions][jwt]**: _food for thought_! Y
  es que a veces las opciones que asumimos por defecto pueden tener _trade-offs_
  de los que no estamos al tanto.
- **[Defining the Value Proposition on a co-creative dynamic with Sales &
  Product][value]**: me ha gustado este post de Álvar Montes explicando las
  dinámicas que facilitó en un offsite de los equipos de ventas y producto en
  OnTruck.

## 🛠 Código

- **[`google/zx`][zx]**: este proyecto open source de Google me ha parecido
  súper interesante. Últimamente, todos mis scripts ya los escribía con Node y
  `zx` propociona abstracciones _amigables_ para lidiar con funciones habituales
  de más bajo nivel.

## 📚 Libros

- **[An Elegant Puzzle: Systems of Engineering Management][puzzle]**: en este
  libro, [Will Larson](https://lethain.com/) (Digg, Stripe, Uber) condensa mucha
  de su experiencia liderando equipos de ingeniería en forma de anécdotas,
  fórmulas, estrategias, prácticas y consejos. Es un libro de múltiples
  lecturas. De momento, he terminado una primera de principio a fin, pero voy a
  tenerlo bien cerquita para consultarlo cuando me enfrente a próximos retos.

## 🎱 Bola extra: El método Kominsky

22 capítulos de menos de 30 minutos cada uno (¡se ven como nada!), repartidos en
3 temporadas. Está disponible en Netflix, y está protagonizada por Michael
Douglas en el papel de un profesor de interpretación que otrora tuvo poco éxito
como actor. La verdad es que me he reído mucho con [El método
Kominsky][kominsky]. En cierto modo ha sido como ver a Hank Moody, de
Californication, 30 y pico años más viejo (y con un punto menos canalla).

[skills]:
  https://www.elidedbranches.com/2021/06/an-incomplete-list-of-skills-senior.html?m=1
[sivers]: https://sive.rs/about
[weekend]:
  https://world.hey.com/joaoqalves/i-could-build-this-during-the-weekend-aa093c5e
[principal]:
  https://www.galiglobal.com/blog/2021/20210313-The-principal-role.html
[jwt]: https://evertpot.com/jwt-is-a-bad-default/
[zx]: https://github.com/google/zx
[value]:
  https://nerds.ontruck.com/defining-the-value-proposition-on-a-co-creative-dynamic-with-sales-product-9ccf3026414d
[puzzle]: https://www.goodreads.com/book/show/45303387-an-elegant-puzzle
[kominsky]: https://www.filmaffinity.com/es/film813870.html


🔗 Quarterlinks #8: Q2 2021

# Quarterlinks #7: Q1 2021

Como de costumbre, vamos allá con algunos enlaces interesantes del pasado
trimestre.

## 💻 Blogposts

- **[Basal Cost of Software][basal-cost]**: Edu Ferro nos habla del coste que
  tiene para el sistema el acumulado de funcionalidad a medida que avanza la
  vida de un producto.
- **[Small batches for the win / Continuous Delivery][small-batches]**: uno de
  los conceptos clave para entender (e implementar) _continuous delivery_:
  trabajar en pasos pequeñitos, pero de manera continua (de esa manera, podemos
  obtener feedback más rápido a la vez que minimizamos los riesgos).
- **[No Meetings, No Deadlines, No Full-Time Employees][no-meetings]**: muy
  interesante conocer la filosofía de trabajo en [Gumroad][gumroad], contada en
  primera persona por su CEO: Sahil Lavingia.
- **[What Makes A Strong Product Culture?][product-culture]**: empoderar equipos
  de producto... si llevas siguiendo esta sección durante los últimos meses,
  habrás visto que siempre cae una pieza sobre este tema.
- **[10 bad TypeScript habits to break this year][typescript]**: soy culpable de
  alguno de los malos hábitos que se detallan en el artículo. Desde hace meses
  estoy luchando activamente por evitar al máximo los puntos 4 y 5.
- **[Your engineering team is (probably) too big][teams]**: quizás (?) el enlace
  más controvertido. Siempre es interesante recordar que es posible conseguir
  muchas cosas con equipos relativamente pequeños (en el artículo se cita a
  Notion, con más de 1 millón de usuarios, siendo una empresa de 10 personas).

## 📚 Libros

Os dejo un par de libros que me han parecido muy interesantes y que se leen
rápidamente:

- **[Measure What Matters][okr]**: John Doerr, que trabajó durante buena parte
  de su carrera junto a [Andy Grove][grove], nos explica OKRs a través de la
  experiencia de múltiples empresas que lo han adoptado de manera exitosa
  (Google, YouTube, Gates Foundation).
- **[Anything You Want][cdbaby]**: Derek Sivers nos cuenta, en primera persona,
  su aventura creando CD Baby, una empresa que en el año 1997 empezó a vender
  música por Internet de artistas independientes (cuando sólo se podía acceder
  al circuito a través de las grandes distribuidoras). Una ejecución brillante y
  una manera poco convencional de entender la empresa y el trabajo.

## 🎱 Bola extra: Leftovers

Tenía en el radar esta [serie de HBO][leftovers] desde hace tiempo, pero no fue
hasta finales de 2020 cuando me lancé a empezarla. De digestión lenta, quizás el
final es un tanto acelerado para el ritmo habitual de la serie, pero yo la
disfruté tanto que terminé por votarla con un 9 en FilmAffinity.

[basal-cost]: https://www.eferro.net/2021/02/basal-cost-of-software.html
[small-batches]:
  https://www.eferro.net/2021/01/small-batches-for-win-continuous.html
[no-meetings]: https://sahillavingia.com/work
[product-culture]:
  https://newsletter.bringthedonuts.com/p/what-makes-a-strong-product-culture
[typescript]:
  https://startup-cto.net/10-bad-typescript-habits-to-break-this-year/
[teams]: https://simpleshapes.io/articles/your-engineering-team-is-too-big/
[okr]: https://www.amazon.es/dp/B078X4HKS9
[cdbaby]:
  https://www.amazon.es/Anything-You-Want-Lessons-Entrepreneur-ebook/dp/B013XUNUAA
[grove]: https://en.wikipedia.org/wiki/Andrew_Grove
[leftovers]: https://www.filmaffinity.com/es/film349114.html
[gumroad]: https://gumroad.com/


🔗 Quarterlinks #7: Q1 2021

# Quarterlinks #6: Q4 2020

Vamos con la colección de recursos interesantes leídos durante octubre,
noviembre y diciembre del pasado (¡por fin!) 2020.

## 💻 Blogposts

- **[Forms best practice][forms]**: esta guía escrita por Geri Reid se ha
  convertido en mi sitio de referencia a la hora de construir formularios en
  aplicaciones web. Hay dos cosas que me gustan especialmente: 1) que está
  repleta de opiniones 2) que todas las opiniones están contrastadas con
  diversos estudios y ejemplos del mundo real.
- **[Packlink engineering vision for 2021][packlink]**: quienes sigáis esta
  serie de posts de manera habitual sabréis que me gusta mucho leer artículos
  donde empresas tecnológicas publican datos de su día a día, tecnologías que
  utilizan, objetivos, estrategia, etc. Pues este artículo escrito por Packlink
  tiene un poco de todo lo anterior.
- **[Write five, then synthesize: good engineering strategy is
  boring][strategy]**: muy relacionado con el artículo anterior, aquí se
  reflexiona sobre cómo escribir una buena estrategia, por qué es importante y
  qué primeros pasos podemos dar para arrancar con todo ello (en forma de
  heurístico).
- **[How to Write Well: 4 Steps to Improve Your Writing][writing]**: y como la
  cosa va de escribir... lo suyo es hacerlo lo mejor posible, ¿no?
- **[Dual-Track Agile][dual-track]**: no es el artículo más completo para
  explicar dual-track pero sí es una buena introducción (además de ser,
  posiblemente, la primera referencia escrita). Sin ser perfecto, es un marco de
  trabajo que puede funcionar a la hora de construir un equipo de producto donde
  las diferenes patas de la organización (product management, product design,
  engineering) se sientan representadas y con libertad para moverse entre tareas
  de diferentes naturalezas.

## 🎙 Podcasts

- **[Producto desde el minuto 0, con Javier Escribano][ontruck]**: me ha gustado
  mucho escuchar a [Javier Escribano][escribano] explicar el proceso de
  desarrollo de producto en OnTruck. Además, con algún ejemplo concreto de cómo
  es el proceso de conceptualización de una funcionalidad.
- **[Product Teams con Edu Ferro][eferro]**: siempre es un gusto escuchar a
  [Edu Ferro](https://www.eferro.net/) hablar de tecnología y desarrollo de
  software. ¿Que os podéis encontrar? Entrega continua de software, desarrollo
  de producto, excelencia técnica... en definitiva, 1 hora y 40 minutos muy bien
  invertidos 🙂

## 🃏 Comodín

- **[How Notion Uses Notion][notion]**. Vale. Lo reconozco. Este artículo NO lo
  leí durante el último trimestre de 2020 pero se me olvidó compartirlo en su
  momento 🤦‍♂️ Es un artículo muy meta donde Notion explica qué uso hace de su
  plataforma y cómo organizan la información. Yo me he cogido unos cuantos
  trucos. Especialmente sobre su gestión de la documentación.

[forms]: https://gerireid.com/forms.html
[packlink]:
  https://medium.com/packlinkeng/packlink-engineering-vision-for-2021-c8f10eb369cf
[strategy]: https://lethain.com/good-engineering-strategy-is-boring/
[writing]: https://adamfaliq.com/2020/10/28/write-well/
[ontruck]:
  https://open.spotify.com/episode/2Py63SXJ7yhe18Wxuf9TKK?si=U_onblSoQUSLu9L0s0BvLA
[eferro]:
  https://thebigbranchtheorypodcast.github.io/post/product-teams-edu-ferro/
[dual-track]: https://svpg.com/dual-track-agile/
[notion]:
  https://www.notion.so/How-Notion-Uses-Notion-616f41d2f5124f3185cf1c36d267c07e
[escribano]: https://www.javierescribano.me/


🔗 Quarterlinks #6: Q4 2020

# Liderazgo técnico y generación de espacios

Reflexionando sobre mi trabajo los últimos años, donde he tenido que cumplir con
ese rol dual de liderazgo técnico (tech lead, lead engineer) y manager de
equipos (engineering manager, vp of engineering) en startups con equipos de
producto e ingeniería pequeños (máximo 10-12 personas), me doy cuenta de que
**lo más valioso que he conseguido ha sido facilitar espacios de reflexión,
discusión y aprendizaje continuo**.

¿A qué me refiero cuando hablo de espacios? Realmente, a nada físico o temporal,
sino a una manera de entender el trabajo del equipo y sus actividades en el día
a día. En muchas ocasiones, especialmente en los contextos en los que yo me he
desarrollado, nos vemos atrapados en un ritmo frenético de trabajo (con el
objetivo de demostrar la viabilidad de la empresa, buscar su product market fit,
conseguir una nuevo cliente, etc.) y ese rodillo puede sepultar las capacidades
del equipo para abstraerse y ganar la perspectiva necesaria para servir como
motor de cambio y mejora continua. Aunque seguro que no únicamente en startups
se vive con prisa, ¿verdad? 🙂

Mis iniciativas en este ámbito han orbitado siempre en torno a los siguientes 3
puntos:

- **Utilizar cada tarea (story, feature) como una oportunidad única para
  aprender**: como desarrollador, no hay curso o taller que me haya enseñado más
  que el propio día a día escribiendo código y desafiando mi propia manera de
  hacer las cosas una y otra vez en búsqueda de soluciones alternativas que sean
  mejores (más sostenibles, escalables). Introducir en el equipo el mindset de
  que cada nueva tarea es una oportunidad para aprender y experimentar requiere
  tiempo, y constancia (y, especialmente, ¡no desdecirte a las primeras de
  cambio!), pero estás contribuyendo a crear un espacio de aprendizaje continuo
  en el día a día.
- **Utilizar cada code review como un espacio de discusión**: este espacio viene
  casi _de gratis_, ya que no son pocos los equipos que tienen integrado en su
  día a día la revisión de código a través de pull/merge requests. Me gusta
  fomentar un entorno donde las revisiones de código no sean únicamente un
  trabajo de revisión (valga la redundancia) sino que se utilicen como un
  instrumento de aprendizaje y conversación. Evidentemente, con matices, ya que
  no todas las merge requests contienen cambios tan interesantes como para
  generar un debate a su alrededor. Del mismo modo, no todos los debates merecen
  bloquear una merge request, por lo que debería ser natural continuar una
  discusión incluso habiendo fusionado ya los cambios propuestos (¡o incluso
  arrancar la discusión con la merge request ya cerrada!).
- **Crear eventos recurrentes PARA el equipo**: y aquí hablo únicamente de mi
  experiencia trabajando en empresas de producto. Hay pocas cosas que generen
  más inercia que un compromiso explícito por parte de la empresa en desarrollar
  una cultura de aprendizaje continuo. Sin necesidad de negociar cosas (tan
  importantes) como presupuestos de formación, es posible realizar pequeñas
  inversiones a través de actividades como clubs de lectura (una hora a la
  semana -¡en [PrivacyCloud](https://privacycloud.com/) lleva funcionando desde
  2017!), meetups internos donde integrantes del equipo puedan compartir hitos,
  realizar presentaciones sobre aprendizajes de las últimas semanas, ver alguna
  charla juntas, practicar una kata...

## Y de manera tangencial...

- En mi experiencia, invertir tiempo en **tener ciclos de feedback (muy) cortos
  fomenta sin lugar a dudas espacios de experimentación dentro del equipo**. A
  todos los niveles. Si poner cambios en producción se puede hacer de manera
  autónoma, rápida y confiable, me animaré seguro a validar diferentes hipótesis
  lo antes posible. Si se cuenta con rituales como retrospectivas (en un
  contexto donde se puedan realizar de manera honesta) cada 1-2 semanas,
  abrazaré el cambio con mayor seguridad, ya que podré ir revisándolo cada poco.
- Las pull requests son un compromiso en el camino por alcanzar un trabajo 100%
  colaborativo (a través de pair o mob programming -dinámicas que aún no he
  conseguido interiorizar completamente ni ver aplicadas de manera recurrente en
  ningún equipo en los que he trabajado, pero que me encantaría). Razón de más
  para aprovechar esos tiempos de revisión para crear nuevos espacios de
  discusión.


Liderazgo técnico y generación de espacios

# Quarterlinks #5: Q3 2020

Vamos con la colección de recursos interesantes leídos durante julio, agosto y
septiembre de este 2020.

## 💻 Blogposts

- **[Writing system software: code comments][comments]**: al igual que me pasó
  con
  [_A Philosophy of Software Design_](/notes/a-philosophy-of-software-design),
  disfruto un montón con los textos que hablan sobre cómo escribir buenos
  comentarios (reflexionando, creo que viene de haber sufrido en equipos donde
  se malinterpretaban algunos principios de _Clean Code_ y el código
  autodocumentado). En este caso, el artículo va un poco más allá y realiza una
  clasificación con los diferentes tipos de comentarios que nos podemos
  encontrar, a la vez que muestra ejemplos concretos sobre el código fuente de
  Redis. Tengo sentimientos encontrados con lo que el autor denomina _Guide
  comments_ pero me encantaría conocer vuestra opinión!
- **[You’ve only added two lines - why did that take two days!][two-lines]**:
  creo que este artículo recoge muy bien el heurístico que la mayoría utilizamos
  al resolver bugs y que no siempre se consigue entender por personas que están
  fuera del proceso de escritura de software (empezando por ese _all lines of
  code are NOT equal_).
- **[Why are CEOs failing software engineers?][ceos]**: lectura interesante para
  personas que se encuentren en áreas de gestión/liderazgo técnico en
  organizaciones de software (¿queda alguna que no lo sea? 😉).
- **[Don’t Compare Averages][averages]**: aquí, Martin Fowler sale un poco de su
  temática habitual sobre ingeniería de software para hablar de diferentes
  visualizaciones que nos ayuden a comunicar información de manera más efectiva
  (es decir, escapando de las habituales gráficas de barras mostrando medias
  aritméticas).
- **[The Cabify engineering stack, 2020 edition][cabify]**: mola mucho conocer
  las tripas tecnológicas de grandes organizaciones de software y, en este caso,
  Cabify nos enseña parte de su stack y cómo gestionar una arquitectura web de
  alta disponibilidad y mucho, mucho _tráfico_ 🙂.

## 🎥 Vídeos

- **[Tidy First?][tidy]**: un vídeo muy cortito donde Kent Beck introduce el
  concepto de dividir en diferentes pull requests los cambios de comportamiento
  y los cambios de estructura. Sin llegar a la clarividencia de Beck, creo que
  esta nota sobre
  [revisiones de código efectivas](/notes/effective-code-reviews) y cómo aplicar
  ahí el principio de responsabilidad única puede ayudar a empezar a andar ese
  mismo camino.

[comments]: http://antirez.com/news/124
[two-lines]:
  https://www.mrlacey.com/2020/07/youve-only-added-two-lines-why-did-that.html
[ceos]: https://iism.org/article/why-are-ceos-failing-software-engineers-56
[averages]: https://martinfowler.com/articles/dont-compare-averages.html
[cabify]:
  https://medium.com/cabify-product/the-cabify-engineering-stack-2020-edition-34edcaff5ad0
[tidy]: https://youtu.be/BFFY9Zor6zw


🔗 Quarterlinks #5: Q3 2020

# Quarterlinks #4: Q2 2020

Con unos días de retraso pero ahí va el conjunto de links con contenido
interesante consumido durante el segundo trimestre de 2020.

Como curiosidad, ha sido un trimestre movidito (¡COVID aparte!) y he vuelto a
unirme al equipo de [PrivacyCloud](https://privacycloud.com) para tratar de
ayudar al equipo a alcanzar nuevos objetivos.

## 💻 Blogposts

- **[When should I write an Architecture Decision Record?][adr]**: Cómo y cuándo
  se escriben ADRs en Spotify. Este artículo ha servido de empuje para que
  empecemos a utilizar este tipo de documentación dentro del equipo.
- **[Empowered Engineers FAQ][empowered-engineers]**: En general, todos los
  artículos del Silicon Valley Product Group sobre cómo construir equipos de
  producto son muy recomendables pero este, que es uno de sus últimos artículos
  al respecto, responde a varias preguntas enviadas por personas con dudas sobre
  cómo implementar esta manera de trabajar en sus equipos.
- **[Ana Asuero, Aplazame CPO, on how to do product when there are limitations
  you can’t control][aplazame]**: Pues poco más que añadir; _insights_ muy
  interesantes que nos llegan desde Aplazame sobre desarrollo de producto.
- **[Case study: Analyzing Notion app performance][notion]**: Artículo
  mastodóntico sobre cómo se podría mejorar el rendimiento de la aplicación web
  de Notion. Más allá del caso de estudio concreto, para mí el valor del
  artículo se centra en conocer qué estrategias existen para mejorar el
  rendimiento de aplicaciones web (al final, todas sufren de más o menos los
  mismos problemas, aunque a diferente escala).

## 🎥 Webinars

- **[Technology at the Core of Product Discovery][product-discovery]**: En este
  webinar, [Eduardo Ferro][eferro] presenta la importancia de la tecnología
  subyacente como _enabler_ para implementar una cultura de _product discovery_
  en equipos de producto.

## 📚 Libros

- **[Creativity, Inc.][creativity]**: Ed Catmull (director en Pixar Animation y
  Disney Animation) nos sumerge en un viaje por la historia de Pixar y por su
  propia estructura organizativa (que les ha servido para revolucionar la
  industria de la animación desde la innovación tanto organizativa como
  tecnológica). Aunque pueda no parecerlo en primera instancia, todos los
  capítulos de este libro contienen píldoras muy interesantes para cualquier
  equipo de desarrollo de producto y yo, sin duda, me veré influenciado por su
  lectura de aquí en adelante.

## 🎱 Bola extra: DEVS

Esta [serie de HBO][devs] es un _thriller_ de ciencia ficción donde, en una
empresa de alta tecnología, desaparece un ingeniero de software en
circunstancias sospechosas... su pareja (también ingeniera de software) comienza
una investigación para tratar de esclarecer los detalles alrededor del caso 🙂

[adr]:
  http://labs.spotify.com/2020/04/14/when-should-i-write-an-architecture-decision-record/
[aplazame]: https://www.javierescribano.me/ana-asuero-aplazame/
[creativity]: https://www.goodreads.com/book/show/18077903-creativity-inc
[devs]: https://www.filmaffinity.com/es/film120510.html
[eferro]: https://twitter.com/eferro
[empowered-engineers]: https://svpg.com/empowered-engineers-faq/
[product-discovery]: https://www.youtube.com/watch?v=xeGHvXwCk1M
[notion]: https://3perf.com/blog/notion/


🔗 Quarterlinks #4: Q2 2020

# Portfolio y blog utilizando NEXT.js

En esta nota os quiero contar algún detalle sobre cómo construí este website
utilizando NEXT.js, un framework desarrollado por Vercel que utiliza React como
librería principal y que permite, de manera sencilla, servir una aplicación
React desde el servidor utilizando _server-side rendering_ (¡aunque quedarnos
únicamente con esto sería simplificarlo demasiado!).

> Mi intención aquí no es hacer un recorrido en profundidad de NEXT.js o cómo
> implementar un portfolio utilizándolo. Si os pica la curiosidad, el proyecto
> tiene una muy buena [documentación](https://nextjs.org/docs/getting-started),
> con
> [multitud de ejemplos](https://github.com/vercel/next.js/tree/canary/examples)
> y [tutoriales](https://nextjs.org/learn/basics/create-nextjs-app).

## Iterando entre diferentes versiones de Next

El primer commit para desarrollar [codecoolture.com](http://codecoolture.com) es
del 24 de agosto de 2018. Por aquel entonces las necesidades del proyecto eran
tener un montón de ficheros estáticos que explicasen qué servicios tenía pensado
ofrecer como _freelance_ y, para ello, utilicé la funcionalidad de Next:
`next export`, que genera un conjunto de ficheros HTML como resultado de aplicar
_server-side rendering_ a la aplicación y _exportar_ su resultado.

Más adelante, me decidí por añadir un blog (y este apartado de notas) y en ese
punto, las cosas empezaron a complicarse (sobre porqué decidí implementar mi
blog _in house_ en lugar de utilizar plataformas como Medium, las razones son
muy parecidas a las expuestas por Marina Aisa cuando
[escribió sobre su experiencia trabajando con Nuxt](https://marinaaisa.com/es/blog/blog-usando-vue-nuxt-markdown/)).
Para seguir manteniendo ese enfoque estático, tenía que añadir las diferentes
entradas manualmente en alguna página tipo índice que sirviera para que el
proceso de exportación supiese que existían y pudiese crear sus ficheros HTML
relacionados (simplificándolo mucho, sería algo similar a lo que necesita un bot
para hacer _crawling_ de una web).

Para no depender de un proceso manual, me decidí por abandonar la exportación
estática y desplegar Next en una instancia de AppEngine para hacer que las
páginas del blog (junto con su índice) se comenzasen a pintar dinámicamente
utilizando SSR. Veréis que aunque Vercel es una plataforma que le encaje como
anillo al dedo a un proyecto que utilice Next, este se puede desplegar en
cualquier servicio que admita ejecutar aplicaciones Node (aunque no todos son
capaces de sacarle partido al potencial _serverless_ del framework, pero eso
sería un tema para otro momento).

Actualmente, y tras actualizar Next a su versión 9.3, pude recuperar la
exportación estática gracias a la adición de una función `getStaticPaths` que
permite indicarle a Next (de manera programática, en tiempo de compilación) qué
paginas existen y cuáles tiene que exportar. En el mismo fichero que se utiliza
para definir una entrada en el blog, se exporta un función cómo la siguiente:

```tsx
export const getStaticPaths: GetStaticPaths = async () => {
  const repository = await MarkdownRepository.fromDirectory(
    getConfig().writing.articles,
  );

  const paths = (await repository.all()).map((article) => {
    const slug = article.metadata.slug;

    if (!slug) {
      throw new Error(
        `ERROR: Missing slug for article: ${JSON.stringify(article.metadata)}`,
      );
    }

    return { params: { slug } };
  });

  return { fallback: false, paths };
};
```

La función pide a un repositorio de artículos que devuelva todos los documentos
que existen y utiliza esta información para indicar a Next cómo encontrarlos (a
través de la propiedad `slug` de cada _path_). `MardownRepository` es una
entidad de mi proyecto (y no algo que venga con Next), y es que el patrón
_Repository_ es una abstracción que utilizo muy habitualmente ya que encaja en
un montón de escenarios (realmente, en casi cualquiera que tenga acceso a
datos).

> Como [Cassidy Williams](https://twitter.com/cassidoo) lo explica mejor que yo,
> podéis echar un vistazo a
> [este blogpost](https://www.netlify.com/blog/2020/05/04/building-a-markdown-blog-with-next-9.4-and-netlify/)
> donde explica en profundidad cómo crear un blog con Next.

## MDX: escribiendo contenido de manera cómoda

No, la verdad que React + JSX no es la mejor manera para escribir contenido de
manera ágil y cómoda... Para hacerlo, me decidí por un
[plugin de Next](https://github.com/vercel/next.js/tree/canary/packages/next-mdx)
que permite generar páginas escribiendo directamente ficheros
[MDX](https://mdxjs.com/) (que, en resumen, son ficheros en formato Markdown
pero que permiten integrar componentes React directamente en el cuerpo del
documento). Este mismo esquema es el que utilicé para escribir los artículos del
blog y las notas; todo junto, en resumen, hace que el 100% del contenido de la
web se escriba en MDX y únicamente utilice React + JSX para definir los
componentes.

Además, con MDX, podemos indicar qué componentes React queremos mapear con cada
elemento HTML. Esto es especialmente útil para poder reutilizar los mismos
componentes a través de toda la aplicación:

```tsx
import { Blockquote } from "../../components/Blockquote";
import { Link } from "../../components/Link";
import { List } from "../../components/List";
import { Text } from "../../components/Text";
import { Title } from "../../components/Title";

/* ... */

<MDX
  components={{
    a: Link,
    blockquote: Blockquote,
    h1: Title,
    ul: List,
  }}
>
  {post.content}
</MDX>;
```

## Otros detalles

- Para los estilos de la aplicación me decanté por utilizar CSS y no una
  solución CSS-in-JS, aunque seguramente mi decisión ahora hubiese sido distinta
  (después de utilizar `emotion` durante los últimos meses, la verdad es que me
  he sentido muy cómodo). Ambos enfoques se pueden utilizar sin mayores
  problemas en Next (siendo el uso de CSS soportado por defecto, sin necesidad
  de configurar nada).
- La web se sirve desde Firebase Hosting (tengo la mayoría de proyectos en
  Google Cloud y me era más cómodo mantener todo dentro de la misma nube que
  desplegar este site en Vercel o Netlify -opciones también muy válidas y con
  una _developer experience_ muy bien ejecutada). Los despliegues están
  automatizados a través de GitLab CI/CD.


Portfolio y blog utilizando NEXT.js

# Quarterlinks #3: Q1 2020

## 💻 Blogposts

- [**How GitHub’s CTO Architects Engineering Teams That Scale**][github-cto]
- [**Production Oriented Development**][production-oriented-development]: Si
  solo tenéis tiempo para atender una recomendación, que sea esta 😁

> [...] code in production is the only code that matters. Staging doesn’t
> matter, code on your laptop doesn’t matter, QA doesn’t matter, only production
> matters. Everything else is debt.

- [**Documenting Architecture Decisions**][document-architecture-decisions]:
  Este blogpost tiene ya algunos años (2011) pero su idea es perfectamente
  relevante. Documentar decisiones de arquitectura es la única manera de
  empoderar a las personas que se vayan a hacer cargo del proyecto _en el
  futuro_.

> Agile methods are not opposed to documentation, only to valueless
> documentation. Documents that assist the team itself can have value, but only
> if they are kept up to date. Large documents are never kept up to date. Small,
> modular documents have at least a chance at being updated

## 🛠 Código

- [**zalando/tech-radar**](https://github.com/zalando/tech-radar): Herramienta
  basada en el Tech Radar de ThoughtWorks y pensada para que equipos de
  ingeniería puedan documentar el estado de su stack tecnológico.

## 📚 Libros

- **Object-Oriented Reengineering Patterns**: Publiqué una pequeña nota sobre el
  libro [aquí](/notes/object-oriented-reengineering-patterns).

## 🎱 Bola extra: musicforprogramming

Seguramente sea ya todo un clásico, pero
[**musicforprogramming**](http://musicforprogramming.net/) contiene un montón de
listas de reproducción para concentrarse programando (o haciendo cualquier otra
actividad que requiera foco 😄).

[github-cto]:
  https://medium.com/@FirstMark/githubs-cto-on-architecting-engineering-teams-that-scale-cb79dd6132ae
[production-oriented-development]:
  https://paulosman.me/2019/12/30/production-oriented-development.html
[document-architecture-decisions]:
  http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions


🔗 Quarterlinks #3: Q1 2020

Books

# Object-Oriented Reengineering Patterns

[Este libro](https://www.amazon.es/Object-Oriented-Reengineering-Patterns-Engineering-Programming/dp/1558606394)
es una magnífica colección de heurísticos y estrategias para ayudarnos a
comprender un sistema de software complejo y ser eficaces a la hora de poder
evolucionarlo y mantenerlo.

Los últimos capítulos están dedicados a estrategias de diseño de software que
permitan extender un modelo ya existente, y son los únicos donde se hace
referencia a orientación a objetos. Personalmente, también son los que menos
valor me han aportado, quizás porque ya han sido desarrollados ampliamente en
otro libros
([Practical Object-Oriented Design](https://www.amazon.es/Practical-Object-Oriented-Design-Agile-Primer/dp/0134456475),
por poner un ejemplo).

Un libro muy interesante si te toca unirte a un proyecto ya en marcha o te
enfrentas a un cambio de trabajo, ya que independientemente del objetivo final
(reingeniería) sus consejos son muy útiles para poder entender bases de código
relativamente grandes, utilizando las herramientas y actores adecuados (que se
cubren en profundidad en la parte II: _Reverse Engineering_).

> A culture of continuous reengineering is a prerequisite for achieving ﬂexible
> and maintainable object-oriented systems.

- «_It is easy to get seduced by focussing on the technical problems that
  interest you the most, rather than what is best for the project._»
- «_Other engineering disciplines rely on the laws of nature to hide irrelevant
  details, but software engineering must build on less solid foundations.
  Consequently, it is essential to pay attention to the details. The only
  question is how to filter out those details that do not matter, because you
  cannot possible investigate everything._»
- «_Documentation is almost always out of date with respect to the actual
  situation. [...] Consequently, avoid to make important decisions based on
  documentation only —first verify your findings by other means (in particular,
  Read all the Code in One Hour and Interview During Demo)_»
- «_As a rule of the thumb, assume that a single team can reengineer as much
  code as they can write from scratch._»
- «_If you fail to deliver good initial results, you will learn a lot, but you
  risk losing credibility. It is therefore critical to choose carefully initial
  tasks which not only demonstrate value for the customer, but also have a high
  chance of success. Therefore, take great care in estimating the effort of the
  initial tasks._»
- «_Nevertheless, even outdated information may be useful, because at least it
  tells you how the system was supposed to behave in the past. This is a good
  starting point to infer how it is used today._»


📚 Object-Oriented Reengineering Patterns

Code Review

# Revisiones de código efectivas

[Single-responsibility principle](https://en.wikipedia.org/wiki/Single-responsibility_principle)
es, sin duda, uno de los principios de diseño de software que más me gusta.
Aplica muy bien a un montón de escenarios, tanto a escala "micro" (funciones,
clases) como "macro" (arquitectura, microservicios). Si estáis lidiando en un
escenario donde las _pull requests_ son, habitualmente, más grandes de lo que os
gustaría y por tanto, necesitan de mucho tiempo para ser revisadas
(convirtiéndose casi accidentalmente en cuellos de botella) os ánimo a probar la
aplicación de SRP.

¿Cómo encajaría en este contexto? A mí me gusta enunciarlo de la siguiente
manera:

> Una pull request debe contener cambios relacionados con una única
> responsabilidad.

Como veis, dentro del enunciado anterior, tendrían cabida _code reviews_ con
multitud de cambios pero (y este _pero_ es importante) siempre y cuando estén
relacionados con una única responsabilidad. Y es que, en la práctica, la
complejidad a la hora de revisar una _pull request_ no está tanto relacionada
con el número de cambios, sino con el volumen de responsabilidades que están
siendo cambiadas a la vez (es decir, un _renaming_ por aquí junto a un cambio en
el código de esta función por allá).

Como ejemplo, uno de los sospechoso habituales de generar un montón de cambios:
renombrar un método, clase, etc. Si este cambio se traduce en una única _pull
request_, estaremos facilitando mucho la vida de la compañera que tenga que
revisar nuestro código ya que todos los cambios están relacionados con una única
_responsabilidad_ y sólo deberá poner el foco en garantizar que la acción se
haya hecho correctamente (¡imaginad que, además, tuviera que validarlo junto a
otro montón de cambios de diversa índole que acompañen a la pull request!).

> La complejidad a la hora de revisar una _pull request_ no está tanto
> relacionada con el número de cambios, sino con el volumen de responsabilidades
> que están siendo cambiadas a la vez.

Conseguir un flujo así implica que tengamos que quitar de nuestra cabeza la idea
de que _1 feature_ equivale a _1 pull request_ y eso es algo que sólo podemos
conseguir si
[desacoplamos nuestro repositorio de nuestra estrategia de entrega de software](/blog/decoupling-vcs-from-software-delivery).

Por supuesto, todos los consejos habituales sobre cómo realizar buenas
revisiones de código aplican también con este enfoque (y si queréis un repaso
completo sobre cómo realizar _la pull request perfecta_, os recomiendo
[esta charla](https://www.youtube.com/watch?v=8-ymTkrZPLg) de
[Patricia Gao](https://twitter.com/patriciagao)).


Revisiones de código efectivas

# Quarterlinks #2: Q4 2019

## 💻 Blogposts

- [**The Amazon Builders’ Library**](https://aws.amazon.com/builders-library/):
  Conjunto de artículos que reflejan como Amazon _builds and operates software_.
  Se explican desde sistemas distribuidos a gestión de _pipelines_ de
  integración y entrega continua.
- [**Ruby, Where do We Go Now?**](https://metaredux.com/posts/2019/12/06/ruby-where-do-we-go-now.html):
  Es muy interesante ver la evoluación de Ruby para mantenerse como una
  alternativa interesante todavía en 2020. Pero más interesante es leer cómo
  Bozhidar Batsov (creador de [Rubocop](https://github.com/rubocop-hq/rubocop)
  -el linter más popular en el ecosistema Ruby) da su particular visión sobre el
  estado actual del lenguaje en su versión 2.7, repasando algunas de sus
  decisiones de diseño más controvertidas.
- [**El role de un Engineering manager**](https://medium.com/@flopezluis/el-role-de-un-engineering-manager-91afebbbf7d0):
  Este es el primero de una serie de artículos escritos por
  [Félix](https://twitter.com/flopezluis) para hablar de las responsabilidades
  de un Engineering Manager y cómo utilizar varias de las herramientas de las
  que disponemos: one on ones, performance reviews, etc. Un contenido súper
  interesante y... ¡en español! 😉
- [**Experts aren’t good at building shared understanding**](https://lorinhochstein.wordpress.com/2019/08/22/experts-arent-good-at-building-shared-understanding/)

## 📚 Libros

Este último trimestre lo he dedicado a picotear artículos y capítulos de varios
libros pero, si tuviera que quedarme con uno, diría que
[**Accelerate**](https://www.amazon.es/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339/)
es el mejor recurso para entender (y defender) porqué aplicar una cultura de
entrega continua es el camino a seguir para mejorar el rendimiento de un equipo
de desarrollo (y de cualquier empresa de software en general).

## 🎱 Bola extra: Notion

Durante este último trimestre he pasado a darle mucho uso a
[**Notion**](https://www.notion.so/) para administrar diferentes tareas,
proyectos y conocimiento. Es multiplataforma y su plan gratuito es lo bastante
amplio para poder utilizarlo (durante un tiempo largo) sin mucho problema.


🔗 Quarterlinks #2: Q4 2019

# Quarterlinks #1: Q3 2019

## 📚 Libros

Durante estos meses he tenido _mucho_ viaje. Muchas horas de tren (a Madrid,
cinco horitas por trayecto...) y alguna escapada en avión para disfrutar de las
vacaciones de verano 🙂, así que el número de libros ha sido superior al que
acostumbro (aunque bien es cierto que un par de ellos ya los había leído
anteriormente).

Como veréis, esta vez son libros más cercanos a negocio que a la práctica de
desarrollo de software en sí:

- [**Scrum and XP from the Trenches (2nd Edition)**](https://www.infoq.com/minibooks/scrum-xp-from-the-trenches-2/):
  importante que sea la segunda edición, ya que contiene _cortes_ del autor 8
  años después de la primera edición. Me ha gustado el enfoque pragmático del
  libro. Con muchos accionables.
- [**The First 90 Days**](https://www.amazon.es/First-90-Days-Updated-Expanded/dp/1422188612):
  si te encuentras en un momento de transición (cambio de puesto y/o empresa)
  estoy seguro de que podrás sacar algo positivo de este libro. Tienes 90 días
  para empezar a conseguir tus primeras victorias y encajar en el engranaje de
  la empresa, ¿por dónde empezarías?
- [**Extreme Programming Explained: Embrace Change**](https://www.amazon.es/Extreme-Programming-Explained-Embrace-Embracing/dp/0321278658):
  poco que decir... cualquier persona que haya trabajado en entornos _Agile_ ha
  sido expuesta, de alguna manera, a las prácticas de Extreme Programming. Se
  lee muy bien y sigue aplicando 100% al contexto actual.
- [**Effective Workshops**](https://www.bracketcreative.co.uk/book-effective-workshops/):
  siento mucho interés por la cultura de _workshops_ (en general, pero
  especialmente aplicado en empresas) y es una habilidad que me gustaría
  entrenar. El libro está pensado para ayudarte en tu camino como
  host/facilitadora, desde los preámbulos del evento hasta qué hacer una vez ha
  terminado. Eso sí, ¡no esperes encontrar ejemplos de ejercicios concretos!

## 🎬 Charlas

- [**Deliveritis Aguda**](https://www.youtube.com/watch?v=vGCowJY5QCQ) por
  [@buenosvinos](https://twitter.com/buenosvinos): en líneas generales, creo que
  la manera de entender el desarrollo de software por parte de Carlos está muy
  alineada con mi propia visión y, aunque es muy difícil condensar tanta
  información en tan pocos minutos, se exponen de manera clara los _pain points_
  más habituales en el proceso de entrega de software junto con estrategias
  eficaces para tratar de mitigarlos. Me quedo con ganas de conocer (más en
  profundidad) sus opiniones sobre cómo integrar los procesos de QA dentro del
  equipo de desarrollo.

## 💻 Blogposts

- [**No Software: No Agile, No Scrum**](https://ronjeffries.com/articles/019-01ff/no-software/)
- [**The boring technology behind a one-person Internet company**](https://broadcast.listennotes.com/the-boring-technology-behind-listen-notes-56697c2e347b):
  siempre me parecen súper interesantes este tipo de artículos donde se
  desgranan parte de los _internals_ de un proyecto. Me ayuda a coger
  perspectiva pudiendo comparar mi experiencia con la de otras personas.
- [**17 Reasons not to be a Manager**](https://charity.wtf/2019/09/08/reasons-not-to-be-a-manager/)

## 🎱 Bola extra: Una serie de televisión

- [**Escape at Dannemora**](https://www.filmaffinity.com/es/film696304.html): la
  vi casi por casualidad (no recuerdo que se hablase demasiado de ella) pero la
  verdad es que me ha encantado; el trío protagonista está muy bien desarrollado
  y el ritmo de la serie a mí me ha tenido bastante atrapado (_disclaimer_: me
  gusta que se tomen su tiempo en contar la historia).


🔗 Quarterlinks #1: Q3 2019

# .dotfiles

Muchas de las herramientas que utilizamos a diario almacenan su configuración
utilizando ficheros denominados _dotfiles_, (llamados así por su esquema de
nombrado, empezando habitualmente por un _punto_: `.bashrc`, `.zshrc`).

Al tratarse de ficheros en texto plano, es muy sencillo poder almacenarlos en un
sistema de control de versiones y poder reutilizarlos (y sincronizarlos) desde
diferentes equipos.

En Internet ya hay muchos ejemplos de [_dotfiles_](https://dotfiles.github.io/)
que pueden servir de referencia (los de
[Jess Frazelle](https://github.com/jessfraz/dotfiles) son espectaculares) pero,
al final, es normal que cada persona tenga su propia configuración con detalles
que le hacen ser más productivo o productiva.

Alguna de las estrategias más populares para poder instalar _dotfiles_ es hacer
uso de [_symlinks_](https://en.wikipedia.org/wiki/Symbolic_link) y requerir el
menor número de dependencias posible (precisamente, uno de los casos de uso más
habituales es utilizarlos para replicar las dependencias y configuraciones
existentes en otro sistema).

En mi caso, [mis _dotfiles_](https://github.com/sergioalvz/.dotfiles) tienen
como únicas dependencias `curl` y `make` (disponibles tras una instalación
_limpia_ de macOS), que se utilizan para instalar `homebrew` y, a través de un
fichero `Brewfile`, instalar automáticamente el software con el que trabajo
habitualmente 🚀


.dotfiles

# A Philosophy of Software Design

Durante las últimas semanas he estado leyendo este maravilloso libro escrito por
John Ousterhout y me gustaría compartir algunas conclusiones que he podido
extraer tras su lectura.

Lo primero, es que el libro me ha parecido un contrapunto muy interesante a
[_Clean Code_](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882).
Básicamente, ambos presentan estrategias para reducir la complejidad en el
diseño, desarrollo y mantenimiento de software (y la complejidad es un término
sobre el que se discute largo y tendido en
[_A Philosophy of Software Design_](https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201))
pero lo hacen, bajo mi punto de vista, desde dos ópticas diferentes.

Robert C. Martin (y mucha de la literatura que hay por ahí fuera) pone el foco
especialmente en **reglas** y **principios**: tamaño de las entidades
(¡funciones de menos de 10 líneas!), el número de responsabilidades de una
abstracción, código sobre documentación, evitar duplicidades, etc. Sin embargo,
en _A Philosophy of Software Design_ nos encontramos un par de capítulos
dedicados en exclusiva al “arte” de escribir buenos comentarios y a las ventajas
de invertir tiempo en expresar, a través de los mismos, aspectos relacionados
con el diseño de software que son prácticamente imposibles de describir
utilizando únicamente código (por ejemplo, el conocimiento del dominio que nos
lleva a aplicar ciertos patrones o arquitecturas, _workarounds_ para lidiar con
_known issues_, etc).

De todos, el capítulo 10: _Define Errors Out Of Existence_, me ha parecido una
delicia, y creo que introduce conceptos muy interesantes para lidiar con los
casos esquina y errores de cualquier aplicación.

Del mismo modo, algunos pasajes hablando sobre la ventaja de definir
abstracciones “profundas” (_deep_) en lugar de “planas” (_shallow_) ilustran
bastante bien los problemas de llevar técnicas de _Clean Code_ al extremo, sin
aplicar un buen criterio.

Creo que la lectura de este libro me ha servido para adoptar un enfoque más
pragmático a la hora de escribir código, alejado de dogmatismos y poniendo el
foco en lo que realmente importa, tratar de reducir al máximo la complejidad de
nuestras soluciones (lo que implícitamente nos llevará también a la aplicación
de buenas prácticas de diseño).


📚 A Philosophy of Software Design

Test-Driven Development

# Introducción a TDD en AsturiasHacking

Los pasados días
[4 y 5 de abril impartí mi primer taller de introducción a TDD](https://www.meetup.com/AsturiasHacking/events/258852355/)
en AsturiasHacking. Después de varios años (co-)organizando esta comunidad,
tenía claro que el tema levantaba cierto interés entre los participantes, que
siempre intentaban algún tipo de aproximación cuando realizamos actividades
prácticas (como el [Global Day of Coderetreat](https://www.coderetreat.org/)).

Mi objetivo para el taller era introducir _test-driven development_ desde una
perspetiva nada dogmática, basada en mi experiencia y donde quedara evidente que
se trata de otra herramienta más, útil especialmente de cara a diseñar software
y **poco efectiva** de cara a realizar labores exhaustivas de _quality
assurance_.

La manera de organizar el taller se dividió en dos tardes, con dos horas de
duración cada sesión. Durante el primer día realizamos una introducción teórica
a la metodología: cuáles son sus "normas" y beneficios. Para después dedicar un
rato a programar en parejas para poder aplicar los conceptos aprendidos.

El segundo día, sin embargo, lo aprovechamos para discutir diferentes
estrategias para enfrentarnos a código _legacy_ y cómo relacionar nuestro código
con el resto de colaboradores de un sistema ya en producción. Para ello,
introdujimos el concepto de _test doubles_, con sus diferentes tipos y
propósitos, para terminar con una parte práctica donde los participantes debían
enfrentarse a un código sin pruebas, con un diseño muy acoplado y sobre el que
realizar una pequeña extensión de su funcionalidad.

El feedback sobre la sesión fue muy positivo. Por ejemplo, las siguientes citas
ilustran bastante bien las conclusiones que salieron en el _closing circle_:

> He aprendido, más bien descubierto, una nueva forma de afrontar o aproximarme
> a la creación de código nuevo.

> Me ha sorprendido la forma real de usar TDD ya que sí creía que era únicamente
> \[hacer\] tests.

> Me ha sorprendido como trabajar en pequeños pasos ayuda a centrarte en el
> problema.

En este enlace os dejo
[un documento con todos los recursos y bibliografía](http://bit.ly/2U6e5fo)
utilizados durante la sesión.


Taller de Introducción a TDD en AsturiasHacking

# The Nature of Software Development

> \[...\] If you’ve been involved in software development, you too have probably
> often felt that all this should be simple, but somehow it gets all
> complicated.
>
> — <cite>Ron Jeffries</cite>

Llevaba unos cuantos meses con ganas de poder leer el libro _The Nature of
Software Development_ de Ron Jeffries y, por fin, este enero, he dedicado unas
cuantas horas a poder estudiarlo, disfrutarlo y compartirlo con varias personas
del equipo y colegas de profesión.

Para quien no le conozca,
[Ron Jeffries](https://en.wikipedia.org/wiki/Ron_Jeffries) es uno de los
creadores de _Extreme Programming_, firmante del
[manifiesto Agile](http://agilemanifesto.org/) y un profesional con dilatada
experiencia en el desarrollo de software. Un breve vistazo al índice de
contenidos o al resumen de la contraportarda ya es suficiente para entender que
el libro, aunque no mencione explícitamente niguna metodología concreta (más
allá del _Natural Way_ del propio Jeffries), va a ofrecer una lectura amena y un
tanto filosófica sobre el desarrollo de software desde una óptica Agile. En lo
personal, encontré la visión del libro muy alineada con mi propio entendimiento
sobre cómo se deberían desarrollar productos y proyectos digitales.

A través de sus páginas, Jeffries no sólo habla del proceso de implementación
(del que, realmente, apenas menciona más que la búsqueda constante de la
excelencia técnica y los beneficios de aplicar _Refactoring_ de manera regular),
sino que gran parte del libro está centrado en la própia definición de _valor_
(«lo que necesitas», en palabras del autor) y cómo se puede identificar y
alcanzar lo más rápido posible a través de la construcción de equipos de alto
rendimiento que tengan maestría en técnicas de entrega continua de valor,
_planning_ y _slicing_ de funcionalidades y capacidad para ejecutar y entregar
productos donde la calidad sea una máxima no negociable.

Como imagináis, construir un equipo de estas características requiere de
perfiles multidisciplinares donde personas de negocio y desarrollo trabajen codo
con codo compartiendo una filosofía común.

Sin duda, si trabajáis en una empresa de software (a cualquier nivel), este se
trata de un libro imprescindible.


Notes

2023

2022

2021

2020

2019