Cómo construí coderkrow: aprendizajes, errores y dolores de cabeza
Construir coderkrow empezó como una idea bastante simple:
- Hacer un lugar propio para publicar cosas.
- Sin algoritmo.
- Sin perseguir métricas.
- Sin intentar convertir cada publicación en contenido.
Solo código, ideas, proyectos, errores y cosas que vale la pena dejar por escrito. Pero construirlo terminó siendo bastante más complicado. No por hacer una web. Por decidir qué debía ser.
Empezó con código
La parte fácil fue abrir el editor.
- Astro.
- EmDash.
- Cloudflare.
- Git.
- Un dominio.
- Un montón de archivos.
Después apareció la parte difícil:
¿Qué quiero decir con coderkrow?
No quería otro portfolio lleno de:
"Software Engineer passionate about building scalable solutions."
Tampoco quería una página personal que pareciera un CV con animaciones. Quería algo que se sintiera como entrar a una terminal.
- Oscuro.
- Directo.
- Un poco raro.
- Técnico, pero sin convertirse en documentación.
De ahí salió buena parte del lenguaje visual y editorial.
Los `[01], [02]`, comandos, referencias, categorías, pequeñas piezas de texto.
No son decoración. Son parte del lenguaje.
Después llegó infraestructura
Y aquí empezó el verdadero entretenimiento. Publicar contenido parecía sencillo hasta que tocó conectar todas las piezas.
EmDash + Astro SSR + Cloudflare Workers
Después Wrangler.
Después bindings.
Después KV.
Después permisos.
Después errores de API.
Después de configuraciones que parecían correctas.
Después, configuraciones que no lo eran.
Y luego volver a empezar.
Hubo momentos en los que desplegar una página parecía más difícil que construirla.
Aprendizaje importante:
La complejidad de un proyecto no siempre está donde esperas.
Puedes pasar horas escribiendo componentes y luego perder otra cantidad absurda de tiempo intentando descubrir por qué Cloudflare no quiere crear un recurso que, en teoría, debería existir.
El valor de eliminar para crear
No todo lo que parecía buena idea terminó dentro de coderkrow.
Algunas páginas cambiaron.
Algunos textos fueron descartados.
Algunos nombres no funcionaron.
Algunas ideas parecían interesantes hasta verlas dentro del sitio.
Y eso fue probablemente una de las partes más útiles del proceso.
Construir no es solamente agregar. También es borrar.
Borrar hasta que quede algo que se siente propio.
El problema no era código
Después de suficiente tiempo trabajando en esto, empezó a quedar claro:
El cuello de botella no era escribir código. Era decidir.
¿Qué publico?
¿Cómo lo digo?
¿Qué merece convertirse en página?
¿Qué debería desaparecer?
¿Qué parte necesita explicación?
¿Qué parte simplemente necesita existir?
Incluso algo tan pequeño como un formulario de newsletter terminó teniendo más decisiones detrás de lo esperado.
- Backend.
- Validación.
- Buttondown.
- Cloudflare.
- Errores.
- Estados.
Una línea de HTML puede terminar arrastrando media infraestructura.
¿Qué aprendí?
[0] Tener stack moderno no elimina problemas
Los mueve.
Astro resuelve cosas.
Cloudflare resuelve cosas.
EmDash resuelve cosas.
Y luego aparecen problemas nuevos en lugares diferentes. La herramienta correcta no elimina complejidad. La cambia de sitio.
[1] Diseño también es ingeniería
Elegir una palabra para un título puede tomar más tiempo que escribir un componente.
Elegir qué quitar puede ser más importante que agregar otra feature.
La interfaz no termina cuando el código compila.
[2] Proyecto personal no significa proyecto pequeño
Un sitio personal puede tener:
frontend, SSR, CMS, infraestructura, DNS, deployments, email, contenido, diseño, analytics y decisiones editoriales. Todo para publicar un artículo.
[3] La fricción enseña
Los errores de Cloudflare enseñaron más que una implementación que funcionara a la primera. Las cosas que se rompieron me obligaron a entender qué había detrás. No siempre fue agradable. Pero sí útil.
[4] Necesito construir cosas que quiera mantener
Ese terminó siendo el criterio más importante.
No:
"¿Puedo construir esto?"
Sino:
"¿Quiero seguir manteniendo esto dentro de seis meses?"
Cambia bastante las decisiones.
coderkrow todavía está en construcción
Y probablemente siempre lo estará. No quiero presentar coderkrow como proyecto terminado. Porque no lo está. Es más interesante verlo como un sistema que va tomando forma:
código → ideas → errores → aprendizaje → código otra vez.
Quizás esa sea parte del punto. Construir algo propio no consiste en llegar a una versión final. Consiste en crear un lugar donde puedas seguir construyendo.