A few years ago, I watched a movie called The Recruit. In one scene, an interviewer asks the main character a strange question:
“Which would you rather do: ride on a train, feel no pain, or dance in the rain?”
At the time, it sounded like one of those clever but meaningless interview tricks. However, over the past few weeks, this question has returned to my mind in several specific situations, and it slowly started to make sense.
Ambiguous questions and hidden signals
Interview questions like this are intentionally ambiguous. They are not designed to have a correct answer. Instead, they force the interviewee to project their personality, values, and preferences into a constrained frame. The interviewer can then interpret the answer as a signal; not about intelligence, but about mindset and fit.
In my interpretation, this question pushes the interviewee to choose between three different states:
- Dancing in the rain: a spontaneous, joyful, and creative activity. Unplanned, emotional, and energizing.
- Riding on a train: a predictable, engineered, and optimized system. Safe, efficient, and boring.
- Feeling no pain: a risky situation where pain is possible, but the focus is on managing or avoiding it.
Surprisingly, these three states map very well to the lifecycle of software systems.
Dancing in the rain: the early stage
At the beginning of a software project - or during a major rewrite or heavy investment phase - teams often find themselves dancing in the rain. There are visible results everywhere: new features, rapid progress, attention, excitement, and sometimes a lot of money.
For engineers, this phase can be deeply satisfying. Everything feels meaningful. The system is flexible, experimentation is cheap, and achievements are tangible.
From a business perspective, however, this stage is expensive. It is pure investment. While some stakeholders enjoy the momentum, others see mostly cost, risk, and uncertainty.
Riding the train: the stable phase
If the project succeeds, it may eventually reach the ride on a train phase. The system becomes well-engineered, predictable, and profitable. Incidents are rare, processes are clear, and scaling is mostly mechanical.
For some engineers, this phase feels boring. There is little room for creativity, and most work is incremental. But from a business standpoint, this is the ideal state: reliable revenue, minimal operational cost, and controlled growth.
This is the phase many companies quietly hope to stay in forever.
Feeling no pain: the aging system
Unfortunately, nothing lasts forever. Over time, technology stacks become outdated. Vulnerabilities start to surface. Simple feature requests require significant effort because every change risks breaking existing integrations.
This is the feel no pain phase.
Everyone feels the pain - engineers, managers, and stakeholders - but most energy goes into avoiding it rather than eliminating it. Short-term patches, partial refactors, and risk assessments dominate decision-making. The system becomes fragile, and progress slows down.
People, preferences, and timing
An important consequence of this model is that team structure, leadership style, and even decision-making processes should align with the current phase of the project. A mismatch here often creates friction that is hard to diagnose, because it appears as a people problem while its root cause is temporal and systemic.
For example, if the leader of a mature, well-engineered system strongly prefers dancing in the rain, they may constantly push for novelty: new architectures, rewrites, tooling changes, or features that are exciting in isolation but unnecessary in context. What feels energizing and meaningful to them can translate into wasted money, increased operational risk, and instability for the organization. In this phase, creativity without restraint becomes a liability rather than an asset.
On the other hand, placing a strict ride the train person in an early-stage project can silently suffocate it. Overemphasis on process, predictability, and optimization too early may kill experimentation, slow learning, and drain the energy that young systems need to discover what they should become.
The same tension exists in aging systems. Leaders who are overly pain-averse may delay necessary refactors or modernization efforts, choosing short-term comfort over long-term health. Others may underestimate the risk and trigger large-scale changes without preparing the organization to absorb the pain.
Understanding which phase a system is in - and which state people are naturally drawn to - allows teams to make intentional choices. It helps align responsibility with temperament, reduces unnecessary conflict, and prevents expensive mistakes that come not from bad intentions, but from misaligned timing.
Career paths and personal preference
This model is not only useful for designing teams and systems; it is also a quiet guide for individual careers. Many engineers experience dissatisfaction not because they are in the wrong company or role, but because they are in the wrong phase.
Some people are naturally drawn to dancing in the rain. They thrive in uncertainty, enjoy building things from nothing, and feel alive when the system is still fluid. These engineers are often at their best in startups, greenfield projects, or periods of intense change.
Others prefer riding the train. They value clarity, stability, and refinement. They enjoy making systems more reliable, scalable, and boring in the best possible sense. These engineers are essential for turning ideas into long-lasting businesses, even if their work receives less visible recognition.
A third group is comfortable with feeling no pain. They are drawn to hard problems, legacy systems, and high-risk environments. They develop strong instincts for risk management, trade-offs, and incremental improvement under constraints.
Problems arise when people interpret their discomfort as personal failure instead of contextual mismatch. Recognizing which state energizes you - and which one exhausts you - can lead to better career decisions, healthier teams, and a more honest relationship with your work.
Conclusion
The question from the interview is powerful not because it reveals a correct answer, but because it exposes preference, timing, and context. The mistake we often make in software engineering is treating one state as universally superior, instead of recognizing that each one is appropriate at a different moment.
Software systems evolve, and so do the people who build and maintain them. What feels meaningful today may feel exhausting tomorrow, not because something went wrong, but because the system - or the person - has moved into a new phase.
Perhaps the real skill is not choosing one state over the others, but knowing when it is time to let go of the rain, settle into the rails, or accept the pain, and act accordingly.