Qué hace que una entrada técnica de blog sea sólida

Por qué esto importa

Cuando empecé a escribir publicaciones técnicas, pensaba que necesitaba explicar algoritmos complejos o construir algo revolucionario. Estaba equivocado.

Las mejores publicaciones técnicas no se tratan de presumir—se tratan de mostrar tu pensamiento. Los reclutadores y gerentes de contratación quieren ver:

• Cómo abordas los problemas
• Cómo aprendes de los fracasos
• Cómo comunicas conceptos técnicos
• Que puedes terminar las cosas

Esta publicación es una plantilla para escribir contenido técnico sólido, basada en lo que he aprendido de escribir, leer publicaciones de otros y recibir retroalimentación.

El planteamiento del problema

Empieza con el problema, no con la solución.

Mal ejemplo:

“Construí una app de React con Redux.”

Buen ejemplo:

“Estaba construyendo una función de carrito de compras y necesitaba compartir el estado del carrito entre múltiples componentes. El prop drilling se estaba complicando, así que necesitaba una mejor solución de gestión de estado.”

Por qué esto funciona

• Da contexto a tus decisiones
• Muestra que entiendes el “por qué” no solo el “cómo”
• Ayuda a los lectores a determinar si tu solución aplica a su problema
• Demuestra habilidades de resolución de problemas

Plantilla

1
2
3
4
5
6
7

## El problema

Estaba trabajando en [proyecto/funcionalidad] cuando encontré [problema específico].

El desafío era [describe la restricción o dificultad].

Necesitaba [lo que intentabas lograr].

Proporciona contexto

No asumas que los lectores conocen tu configuración. Explica brevemente:

• Qué estabas construyendo
• Qué tecnologías estabas usando
• Qué restricciones tenías (tiempo, recursos, nivel de experiencia)

Ejemplo

1
2
3
4
5
6

## Contexto

**Proyecto:** Aplicación web de finanzas personales
**Stack tecnológico:** React, Node.js, PostgreSQL
**Mi experiencia:** Cómodo con lo básico de React, primera vez usando una base de datos
**Restricción:** Necesitaba desplegar gratis (presupuesto de estudiante)

Esto ayuda a los lectores a entender tus decisiones y si tu enfoque se adapta a su situación.

Lo que intentaste

Documenta tu proceso de exploración.

Aquí es donde muchas publicaciones se quedan cortas. No solo muestres la solución final—muestra lo que intentaste primero. Esto es increíblemente valioso porque:

1. Muestra tu proceso de pensamiento
2. Ayuda a otros a evitar los mismos callejones sin salida
3. Demuestra persistencia
4. Es más realista que “lo construí perfectamente a la primera”

Ejemplo

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

## Intento 1: Estado local

Mi primer enfoque fue usar `useState` de React en el componente padre:

```javascript
function App() {
  const [cart, setCart] = useState([]);

  return (
    <div>
      <ProductList cart={cart} setCart={setCart} />
      <CartSummary cart={cart} />
      <Checkout cart={cart} setCart={setCart} />
    </div>
  );
}

Qué pasó: Esto funcionó inicialmente, pero a medida que agregué más funcionalidades, estaba pasando props a través de 3-4 niveles de componentes. El código se volvió difícil de mantener.

Por qué falló: El prop drilling hizo que el árbol de componentes fuera rígido. Agregar una nueva función que necesitaba acceso al carrito significaba actualizar múltiples componentes.

Qué pasó: [Describe el resultado]

Por qué no funcionó: [Tu análisis de por qué este enfoque falló]

Lo que aprendí: [Conclusión clave de este fracaso]

Qué pasó: Esto eliminó el prop drilling, pero noté problemas de rendimiento. Cada actualización del carrito re-renderizaba todos los componentes que consumían el contexto.

Por qué no funcionó: Context API re-renderiza todos los consumidores cuando cualquier valor cambia. Con más de 50 productos en la página, agregar un artículo al carrito causaba re-renderizados innecesarios.

Lo que aprendí: Context API es genial para datos que cambian poco frecuentemente (tema, autenticación), pero no es ideal para estado que se actualiza frecuentemente como un carrito de compras.

Por qué esto funciona:

• Los componentes solo se re-renderizan cuando sus datos específicos cambian
• La lógica de estado está centralizada y es testeable
• Redux DevTools me permite depurar cambios de estado fácilmente

Compromisos:

• Más código boilerplate que Context API
• Curva de aprendizaje más pronunciada
• Puede ser excesivo para apps muy simples

Para mi caso de uso (app en crecimiento con estado complejo), estos compromisos valieron la pena.

ANTES (Prop Drilling): App ├── ProductList (necesita cart, setCart) │ └── Product (necesita cart, setCart) │ └── AddToCartButton (necesita setCart) └── CartSummary (necesita cart)

DESPUÉS (Redux): App ├── ProductList │ └── Product │ └── AddToCartButton (useDispatch) └── CartSummary (useSelector)

Context API: 50ms por actualización del carrito (50 re-renderizados de componentes) Redux: 5ms por actualización del carrito (2 re-renderizados de componentes)

Ejemplo

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

## Conclusiones clave

1. **Empieza simple:** Debería haber mantenido el estado local más tiempo. Redux era excesivo hasta que tuve problemas reales de rendimiento.

2. **Mide antes de optimizar:** Asumí que Context API era lento antes de medirlo. Siempre haz profiling primero.

3. **Lee la documentación a fondo:** La documentación de Redux Toolkit tenía ejemplos que resolvían exactamente mi caso de uso. Perdí tiempo intentando resolverlo por mi cuenta primero.

4. **Los compromisos están bien:** Ninguna solución es perfecta. Entender y aceptar compromisos es parte de la ingeniería.

## Si hiciera esto otra vez

- Empezar con estado local
- Mover a Context API cuando el prop drilling se vuelva doloroso
- Solo agregar Redux cuando tenga problemas de rendimiento medidos
- Dedicar más tiempo a leer documentación antes de programar

Plantilla que puedes copiar

Aquí tienes una plantilla para tu próxima publicación técnica:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

---
title: "[Título descriptivo]"
date: AAAA-MM-DD
tags: ["etiqueta1", "etiqueta2", "etiqueta3"]
summary: "Descripción en una oración de lo que cubre esta publicación."
---

## El problema

[¿Qué problema intentabas resolver?]

## Contexto

- **Proyecto:** [Qué estabas construyendo]
- **Stack tecnológico:** [Tecnologías usadas]
- **Nivel de experiencia:** [Tu experiencia con estas herramientas]
- **Restricciones:** [Tiempo, presupuesto u otras limitaciones]

## Lo que intenté

### Intento 1: [Nombre del enfoque]

[Descripción y código]

**Qué pasó:** [Resultado]
**Por qué no funcionó:** [Análisis]
**Lo que aprendí:** [Conclusión]

### Intento 2: [Otro enfoque]

[Repetir estructura]

## Lo que funcionó

[Tu solución con explicación]

**Por qué funciona:** [Beneficios]
**Compromisos:** [Desventajas que aceptaste]

## Resultados

[Métricas, resultados o impacto]

## Conclusiones clave

1. [Lección 1]
2. [Lección 2]
3. [Lección 3]

## Recursos

- [Enlace al código]
- [Documentación útil]
- [Artículos relacionados]

Reflexiones finales

Las publicaciones técnicas sólidas no requieren conocimiento de nivel experto. Requieren:

• Honestidad sobre tu proceso
• Explicación clara de tu pensamiento
• Disposición para mostrar fracasos
• Ejemplos concretos y código

Tus proyectos “pequeños” y problemas “simples” son valiosos para escribir sobre ellos. Alguien más está enfrentando el mismo problema ahora mismo, y tu publicación podría ayudarle.

Empieza a escribir. Tu yo del futuro (y tus futuros lectores) te lo agradecerán.

Recursos:

• Repositorio de ejemplo en GitHub con código de esta publicación
• Documentación de Redux Toolkit
• Documentación de React Context API