Notes from the terminalWhat a hackathon and a CTF taught me in 2025
Last year I did two things I had been putting off for a long time: I took part in a 24-hour hackathon, and I spent a few weekends on a beginner-friendly capture-the-flag competition. I am writing this a bit late, because it took me a while to work out what I actually took away from them. It was not what I expected.
The hackathon: scope is everything
Our team of four set out to build something ambitious and spent the first six hours arguing about architecture. By the evening we had a diagram and almost no code. The second half of the night was a scramble, and the thing we demonstrated on Sunday was about a third of what we had planned.
The lesson is old but I had to learn it the hard way: in a short event, scope is the only variable you fully control. The teams that did well picked one narrow problem, built the smallest version that could work end to end, and spent the last hours making the demo reliable rather than adding features.
- Decide the demo first. Know what you will show in three minutes, then build backwards from it.
- Hard-code freely. Nobody grades your configuration system.
- Freeze early. Stop adding features a few hours before the end and spend the time on rehearsal.
- Sleep a little. A tired team makes silly mistakes, and silly mistakes are what break demos.
The CTF: reading carefully beats being clever
Capture-the-flag challenges are small puzzles about software: a web form that trusts its input too much, a cipher with a mistake in it, a binary that hides a string. I went in thinking it was about knowing tricks. It turned out to be mostly about reading carefully.
Again and again, the answer was in something I had looked at and skipped: an odd response header, a comment in the page source, a value that was almost random but not quite. When I got stuck, the best thing I could do was slow down and describe in plain words what the program did, step by step. The gap between that description and what I assumed was usually the bug.
I also learned to read other people's write-ups after a competition ended. Seeing how someone else approached a problem I had failed was worth more than the problems I solved myself.
Debugging and puzzle-solving turn out to be the same skill: noticing what is actually there instead of what you expect to be there.
Small codebases worth reading
Both events pushed me to read more code written by other people, especially small, focused projects that a single person can understand in an evening. A few that I enjoyed, in case they are useful to you:
- micrograd, a tiny automatic-differentiation engine in a couple of hundred lines. It is a good example of how little code the core idea needs.
- nanoGPT, a compact implementation for training and fine-tuning small language models. Readable enough to follow from the data loader to the training loop.
- minbpe, a minimal byte-pair-encoding tokenizer. It makes a topic that seems mysterious feel approachable.
- llm.c, language-model training written in plain C. Reading it made me appreciate how much the usual frameworks do for us.
I have no connection with the author of these projects. I simply find that reading well-made small programs teaches more than most tutorials, and that the habit transfers to everyday work: when you meet a large codebase at your job, you already know how to look for its small core.
What I will do differently
- Enter more events, but with smaller goals.
- Keep a notebook of every puzzle I got stuck on and what finally unstuck me.
- Read one small project each month, all the way through.
That is the whole list. Neither event made me a different developer, but both changed how I read code and how I plan a weekend, and that seems like a fair return for a few sleepless nights.