CODENIGMA was my first serious competitive programming competition, and winning it taught me more about how I think under pressure than any project before or since.
Competitive programming is a different discipline to software engineering. The goal is not to write maintainable, well-documented code that other engineers can work with — it's to produce a correct solution to a precisely defined problem in minimal time. This constraint changes everything about how you approach it.
My preparation was deliberate but not obsessive. I spent four weeks working through data structure problems — arrays, linked lists, trees, graphs — systematically, focusing on recognising problem patterns rather than memorising solutions. The key insight is that most competitive programming problems are variations of a small set of patterns: can you recognise which pattern applies and implement it quickly?
During the competition itself, the most important discipline was time allocation. It's tempting to spend all your time on a hard problem you're making progress on, while leaving easier problems untouched. We applied a strict triage rule: spend a maximum of 15 minutes on any problem before moving on and returning later. This ensured we captured all the achievable points before getting stuck in a difficult problem.
The winning margin came from a problem that most teams abandoned: a graph traversal problem that required recognising a cycle detection pattern. Because we'd drilled graph problems in preparation, the pattern was immediately recognisable even under time pressure.
Lesson: preparation in competitive programming is pattern recognition, not knowledge accumulation.