Learning to Code Without a Safety Net (of Time)
22 Jan 2026
Background Overview
As a Security Science student, my foundation has been built on traditional languages like C, C++, and Python. I am used to managing memory pointers, and worrying about the buffer overflows that come with them, or enjoying the simplicity of Python scripts for quick automation and packet analysis. However, the world of modern web development is relatively new to me. Coming into this course with limited experience in JavaScript and TypeScript, the learning curve has been very steep as it introduces two major shifts: a transition to the new syntax of TypeScript and the high-pressure pedagogy of “Athletic Software Engineering”. While the language itself offers the kind of structural integrity I value in secure coding, the method of learning it has been a new source of stress. Comparing TypeScript to the languages I am familiar with offers an interesting contrast. In C and C++, strict typing is the norm, but it comes with the overhead of manual memory management and complex compilation steps. Python, on the other hand, is flexible, perfect for writing quick exploits or scanners, but lacks the safety of compile-time checking. TypeScript, in my opinion, sits in the ideal middle ground. It provides the safety net I appreciate from C++, catching type errors before the code runs and acting almost like a built-in static analysis tool, while retaining the flexibility of a high-level scripting language.
WODS == CTFs?!
Regarding the WODs, while I see the value in the language, the Athletic Software Engineering approach is a different story. To be honest, I find the Workouts of the Day incredibly stressful. In my previous coding experience, whether debugging a C++ pointer mismatch or writing a Python script to parse logs, I usually had the time to think, research, and test. This methodology strips that time away. Because I am still relatively new to the syntax of TypeScript, fighting the clock feels overwhelming. It reminds me of the pressure of a Capture The Flag competition or a mock live incident response scenario, but without the adrenaline of the hunt. I often know what logic I want to implement, but I get stuck on the specific syntax required to make the compiler happy. The Rx times, in my opinion, are unforgiving, and the pressure to perform at speed often leads to simple typing mistakes that cost valuable minutes. But do I find the WODs useful? Yes! In a real security context, like patching a vulnerability or writing a script during an attack, you do not have time to browse through a forum or fact check an AI for the solution. This repetition is forcing me to memorize syntax that I would otherwise look up every single time. It is building muscle memory, which is the stated goal of the pedagogy. But is it enjoyable? Surprisingly, yes. There is a genuine feeling of accomplishment in realizing that a task, which might have taken me an hour just last week, can now be completed in half the time.
Finding the Middle Ground
Despite the stress, I think this style of learning will ultimately work for me. My background in C and Python gave me the logic to dissect vulnerabilities, but it didn’t prepare me for the speed required to fix them in a modern web environment. Athletic Software Engineering is forcing me to confront my lack of fluency head-on, treating code efficiency almost like a readiness drill for a security incident. It is an exhausting way to learn, and I certainly miss the slower, more analytical pace of reverse engineering or packet analysis. However, I cannot deny that I am writing TypeScript faster today than I was a week ago. If the ultimate goal is to be a security engineer who can not only break systems but also rapidly build and patch them under pressure, then this high-intensity training is exactly the hardening process I need.
ChatGPT was used for grammar checking and the title.