The Joy of Small Projects
Feb. 06, 2026
I recently wrote a library and command-line tool to fetch data from NewsAPI.org, coded in Nim. Under 1000 lines, no external dependencies. And I realized something: it reaffirmed how good it feels to work on something this small. Day to day, bouncing between data science and systems development, it's all complex pipelines, heavy dependencies, distributed infrastructure. But with this project I could literally hold everything in my head. Every decision had consequences I could predict. Changes didn't trigger unpredictable cascades. Made me reflect on how size affects the relationship we have with our projects.
What really drew me in: in small projects, clarity just happens. It's not something you have to fight for—it's the default state. Sharp contrast with the data systems I usually integrate, where many dependencies and orchestration tools are unavoidable. Here, Nim's type system let me express things directly: enums for news categories, structs that map one- to-one with API parameters. No extra layers. All the relevant code in just a few files, no hidden magic, no dependencies to update, no new framework to learn. Even if you don't know programming, you glance at this code and understand it. That kind of total transparency is rare in larger projects, especially in the data science world.
For the README.md I went with the classic Unix man page style. Same old structure: NAME, SYNOPSIS, DESCRIPTION, OPTIONS, EXAMPLES. I like it because it mirrors how I actually look for information when I need something. No trying to teach or philosophize—just describe what the software does, precisely but without the fuss. Each function answers three basic questions: what it does, what it needs, what it returns.
Something I really enjoyed: the absence of temptation. It's way easier to resist the "just one more feature" when the project's small. Or reaching for some fancy library when ten lines will do. Or abstracting too soon. Every line is there for a specific reason. Tests work as executable specs—documentation that never goes stale. That discipline just emerges when the project fits in your head.
This project made it clear to me that size matters more than we admit. In data systems complexity often comes with the territory—distributed data, parallel processing, complex statistical models. But in tooling and infrastructure, how much of that complexity do we actually need? In large projects we're constantly fighting accumulated complexity. Every framework makes sense. Every dependency is justified. Every abstraction layer solves something. But in the end we wind up with a system that's more complex than the problem we were trying to solve. In a small project those forces don't get a chance to accumulate. I see all the code, understand the decisions, predict the consequences.
I'm not saying this is the answer for everything. Obviously there are problems that need complex systems. But I do think we're losing something important: the satisfaction of fully understanding what we're working on. The confidence to change it without fear. Knowing it'll work years from now without changing anything. When you manage to build something that fits in your mind, developing feels completely different. And that's worth preserving, especially for those of us working across multiple domains.
Resources:
Note: This article was originally written in Spanish.