Fail Fast, Fail Forward
Source: Dev.to
What fail fast actually means
Fail fast means getting feedback early.
Instead of spending weeks polishing something in isolation, you put it in front of reality as soon as possible. Reality can be code running, a question asked in a meeting, or trying a new approach even if you are not fully confident yet.
The goal is not speed for the sake of speed.
The goal is clarity.
A technical example from data structures
This idea shows up clearly in data structures.
In Java, HashMap is a good example of a fail‑fast data structure. When you iterate over a HashMap and modify it at the same time, Java throws an exception immediately. It does not try to recover or continue quietly; it stops execution so the problem is visible right away. This behavior is intentional: the goal is to surface bugs early, while they are still easy to understand and fix.
Other data structures are designed to be fail‑safe. For example, CopyOnWriteArrayList works on a copy of the data. Modifications do not affect the current iteration, so the program continues running without throwing an error. This feels safer, but it also means issues can go unnoticed longer.
Neither approach is wrong; they solve different problems.
- Fail‑fast structures prioritize early feedback and correctness.
- Fail‑safe structures prioritize stability and continuity.
Seeing this in code helped me understand the idea beyond theory.
A simple example from backend development
When I started building backend APIs, I would often overthink the structure before even running the application. I wanted everything to be clean before seeing if it actually worked. That usually backfired.
Now I run the application early, even if the code is incomplete. Errors show up quickly, misunderstandings become obvious, and I learn what the framework expects instead of guessing. Failing fast here means I spend less time being stuck and more time adjusting in the right direction.
Applying this idea to public speaking
Public speaking did not become easier because I suddenly felt confident.
It became easier because I stopped waiting until I felt ready.
Early speeches were imperfect—timing was off, feedback was direct. None of that meant I was bad at speaking; it showed me what needed attention next. Failing forward meant taking that feedback and applying one small improvement at a time, instead of trying to fix everything at once.
Why failing forward matters more than failing fast
- Failing fast gives you information.
- Failing forward means you use that information.
Failing forward looks like:
- Making one adjustment based on feedback.
- Asking a clearer question next time.
- Trying again with slightly better understanding.
It is not dramatic. Most progress is incremental and quiet.
The model I follow
The model I follow is simple:
- Try early.
- Observe what does not work.
- Adjust one thing.
- Try again.
There is no perfect time to start and no benefit in waiting. This approach works for tech, learning, and preparing workshops.
What I’m working on next
I am excited to share that I will be giving a workshop titled:
A Beginner‑Friendly Workshop: How to Speak Comfortably in Public
The ideas around failing fast and failing forward are a core part of how I approach public speaking, especially for beginners who feel pressure to be confident before they start. I will write more about the process, lessons, and practical exercises from this workshop in future blog posts.