Four ICPC Habits That Survived Production, and Two I Had to Unlearn

A developer who won the ACM-ICPC Asia Topi regional in 2021 and later built XR platforms, a cross-platform C# SDK, AR systems for fire response, and AI voice agents shares four competitive programming habits that proved valuable in production and two that had to be unlearned. The habits include staying calm in the face of unknown problems, rigorous testing for edge cases, and reading constraints carefully, which translate directly to engineering challenges like debugging AI voice agents and designing AR overlays.

Every few months the same argument comes back around: does competitive programming make you a better engineer, or does it just make you good at competitive programming? People who did it defend it. People who did not point out, correctly, that nobody has ever shipped a segment tree to production. I have been on both sides of that line, so here is my honest accounting. In 2021 my team won the ACM-ICPC Asia Topi regional as national champions and qualified for the ICPC World Finals. That is roughly as far as that track goes. Then I went and built things people actually use: XR platforms, a cross-platform C SDK that had to behave identically on three operating systems, AR systems for fire response, and now AI voice agents that answer real phones for real businesses at 2am. Four habits came with me almost untouched. Two I had to actively unlearn before I was useful on a real team. The short answer is yes, it helped, but not for the reason people usually give. I have not written a segment tree since university. It helped because contests train a specific relationship with a hard problem, and that relationship turns out to be the rare thing. This is the big one. Everything else on the list is downstream of it. In a contest you have five hours and a problem you have never seen. There is no Stack Overflow answer, no library that does it, no senior engineer to tap on the shoulder. You have a whiteboard, two teammates, and the requirement that something correct exists at the end. You learn to sit inside not-knowing without panicking, break the problem into a shape you can attack, and keep generating approaches after the obvious three have failed. That is exactly what production work asks for, just stretched over weeks instead of hours. When I had to make a live data stream sit correctly on top of the physical world inside a headset, nobody had written that blog post. When a voice agent starts behaving strangely on real calls overnight, there is no documented answer either, because the failure is specific to your prompt, your telephony provider, your callers and your Tuesday. The skill is not knowing things. It is having a reliable process for the moment you do not know, and a contest is five hours of pure practice at that, repeated for years. In a contest your solution is right or it is not. The judge does not care how confident you were. It does not care that it worked on the sample input. There is no partial credit for elegant code that fails one edge case. That is brutal and it is extremely healthy calibration. It kills the instinct to declare victory because something ran once without crashing. You start reflexively asking the question that separates working software from software that looks like it works: what input breaks this? Empty case, single element, maximum size, duplicates, the exact boundary between two branches. Years later that reflex is why I design the ugly call before the happy path when I build an agent, and why I pushed for honest staleness signals in AR overlays instead of a confident dot that might be lying. The contest version is "your solution fails on n equals one." The production version is "your booking flow fails when the caller gives a date in the past, and then confirms it out loud." Every contest problem hands you the constraints at the top, and reading them properly is half the solve. If n can be a million, you know your approach has to be roughly linear before you write a line. If n is twenty, brute force is intended and the clever solution is a trap you will spend two hours in. This transfers directly, and almost nobody does it. Real projects come with constraints too. They are just not printed at the top of the page, and nobody volunteers them. How many calls a day? How stale can this data be before it is dangerous rather than merely wrong? How long will a human wait before they hang up? What is the one thing this must never get wrong, at the cost of everything else? I now dig those out before touching architecture, because they collapse the design space fast. It is why an AR overlay for a firefighter and a voice agent for a clinic end up with the same shape underneath. Both have a hard latency ceiling and a hard correctness floor, and once you read those honestly, most of the design has already decided itself. Contests are timed, ranked, and public. You will fail in front of people. You will submit something wrong and watch the scoreboard move without you while your teammates watch. You learn to keep thinking clearly while behind, and to triage under pressure: this problem is not going to fall in the time left, move to the one that will. That composure is worth more than any algorithm. When I stepped in as CTO at a sports tech company during a critical phase, the technical problems were solvable. What the situation actually demanded was staying calm with a deadline moving toward me and choosing what not to do. Contests are a cheap, safe simulator for exactly that, and five years of them genuinely changes how a bad Friday feels. Now the part nobody says at the awards ceremony. Competitive programming also installs two habits that are actively wrong outside a contest, and my first year of client work was mostly discovering them. In a contest, code lives for five hours. Variable names are single letters. There are no tests, no comments, no abstraction that is not load-bearing in the next twenty minutes. That is optimal for the environment, and a disaster in a repository someone else maintains next year. Real code is read far more often than it is written, usually by someone who has never met you, and often by you having forgotten everything. I had to consciously slow down and write for the reader instead of the compiler. The speed I had spent years training was speed at producing a throwaway artifact, and the job was durable systems. This one took me longer to accept than I would like to admit, because the old habit felt like competence. ICPC selects for one skill: solving a well-specified problem. Someone else already did the hard part, which was deciding what the problem is. In real work that specification does not exist. The client describes a symptom, not a requirement. The actual difficulty is figuring out what should be built, what it must never get wrong, and what everyone in the room is assuming without saying it out loud. Almost none of my production time goes to algorithmic difficulty. It goes to ambiguity, integration, edge cases in other people's systems, and human factors. That was a genuinely humbling adjustment. Being world class at the last mile does not help if you are running the wrong direction, and I had to build the taste for problem definition from scratch, mostly by getting it wrong on other people's budgets. If you are a student deciding whether to spend two years on this: yes, if you go in knowing what it is. It is a gym, not a job. It builds problem-solving stamina, correctness instincts and composure at an intensity normal work will never give you, because normal work has deadlines measured in weeks and lets you look things up. But treat it as one input, not the whole education. Ship something real alongside it. I was freelancing in Unity through university while competing, and the combination is what mattered. Contests taught me how to think when I am stuck. Client work taught me what was worth thinking about. Neither alone would have gotten me to public safety AR or to production voice agents. The people I watched plateau were the ones who believed the ranking was the skill. It is not. The ranking is a side effect of having practiced not-knowing for thousands of hours, and that asset does not expire when the tools do. I have been paid for C++, then Unity, then mobile SDKs, and now LLM agents. Every one of those transitions was survived with the same muscle a five-hour contest builds: sit with the unfamiliar problem, decompose it, attack it, verify it honestly, and do not flinch at the clock. The segment trees, though. Those are gone. Originally published on my blog, where I write about voice agents, XR and the engineering behind both.