The Daily Challenge
At PT. Kosong Satu, where I serve as Technical Advisor, the developers started something they call the daily challenge. The idea is simple: a small technical task that has to be solved in a short window — minutes, not hours — using whatever programming language anyone prefers, including a new one they want to dig into.
A few weeks in, it has become the most useful ritual on the team.
The Mechanics
The format barely needs any structure. Each morning, someone posts a problem in the team channel — anything from draw a chess board in ASCII, to sort an array without using the built-in sort, to find the first ten primes. The constraint is time, not difficulty. Solutions have to be small enough to ship in a single sitting.
We don’t pick problems for production relevance. The point isn’t to write code we’d ever ship — it is to exercise the logic without the weight of production stakes.
What it Surfaces
Three things come out of doing this consistently for a few weeks.
Language fluency is the most visible. The same problem written in Go, JavaScript, and Python reveals less about the engineer and more about the language — what each one makes easy, what each one quietly costs. You can read about generics, closures, or first-class types in a tutorial; you don’t really see them until you have written the same trivial piece of code in two languages back-to-back.
Algorithmic instinct is the next layer. We benchmark every solution and try to understand why one runs slower than another. The answer is rarely the obvious one. Once you have watched a five-line solution outperform a more “clever” implementation by an order of magnitude — or seen the opposite happen — you start carrying small heuristics around as muscle memory rather than as something you have to look up.
Team dynamics is the quiet one. Code review under deadline pressure is rarely fun. Code review on a daily-challenge solution is. We laugh at our own benchmarks, argue about whether a recursive solution is genuinely “better” than the iterative one, and learn each other’s blind spots without anyone losing face. It is cheap, frequent peer review — without the politics that production reviews tend to accumulate.
Why it Works
The format works because it inverts the usual stakes of writing code together. Production code carries operational risk, deadline pressure, and review politics. Daily-challenge code carries none of that. Learning happens in the margin where stakes are intentionally low — and where being wrong is cheap.
The lessons stick anyway. They stick better, in fact, because nothing about the experience is defensive. You can be wrong publicly, ten times in a row, and the only consequence is laughter and a slightly cleaner mental model the next time around.
It is the same logic behind why kata, code retreats, and Advent-of-Code seasons work for the people who take them seriously. The practice is deliberately low-stakes, repeatable, and bounded in time — three properties that production work almost never has at the same time.
If You Want to Start One
Three things from our experience that matter more than they look:
- Time-box hard. The constraint is what makes it work. If solutions take all afternoon, the practice dies in two weeks. Twenty minutes is the right ceiling for most problems; thirty is the absolute outer edge.
- Encourage language sprawl. The interesting comparison is between languages, not between engineers. Make it normal to show up with a Haskell solution one day and a Bash one the next, even when the language is wrong for the problem — especially when it is wrong for the problem.
- Benchmark and read each other’s code out loud. This is the part that turns the practice from individual exercise into team learning. Without it, you will get fitness; with it, you will get fluency.
The tasks themselves don’t matter much. Draw a chess board. Sort an array. Find prime numbers. Count the words in a string. Walk a binary tree. Validate a credit-card number with the Luhn algorithm. Any of them will do. What matters is the cadence: small problems, short time, public solutions, honest benchmarks, regular laughter.
It’s the kind of small ritual that compounds. Your team might enjoy it too.