How emotional dependency becomes embedded inside self-concept, why certain relationships begin influencing your decisions from the inside, and what...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
A few things that stood out to me:
"You stop simply loving the person. You start organizing yourself around them." — This is the clearest one-line distillation of the whole piece, and it's a genuinely useful diagnostic question to sit with: am I in relationship with someone, or has my internal operating system quietly been rebuilt around them?
"The dangerous part is that the process feels emotionally meaningful while it is happening. Sometimes even romantic." — This is the part I'd flag as the real insight. Most people can spot dependency once it's painful. Far fewer can spot it while it still feels like closeness, which is exactly when it's forming and exactly when it's hardest to interrupt.
"People often think they are grieving only the relationship. Sometimes they are grieving the collapse of the psychological structure built around it." — This reframes a lot of breakup pain that gets misattributed purely to missing the person, when part of what's actually happening is the disorientation of losing an entire internal reference system.
"Connection is healthiest when it enhances identity instead of consuming it." — Simple, but it's the actual test the piece offers: does this relationship add a room to the house, or did it become the foundation?
The software metaphor does a lot of work here, and it mostly earns its keep — "dependency injection" as a frame makes an abstract, hard-to-name psychological pattern feel concrete and nameable, which is often the first step to actually noticing it in yourself. I'd just gently note it's a metaphor, not a mechanism — the piece is describing something closer to attachment-related over-reliance and enmeshment than a literal technical process, and pairing this kind of self-audit with an actual therapist or counselor is worth considering if the "which decisions are mine vs. run through someone else's approval" pattern feels persistent rather than occasional.
The software metaphor works especially well here because dependency can become invisible precisely when it feels like intimacy. The most valuable insight is that autonomy doesn’t require caring less—it means being able to care deeply without outsourcing your decisions, self-worth, or identity. Reclaiming that internal authorship seems less about disconnecting from people and more about reconnecting with yourself.
The line that stuck with me: "People often think they are grieving only the relationship. Sometimes they are grieving the collapse of the psychological structure built around it." That explains why a breakup can feel less like losing someone and more like losing your bearings.
I also liked the distinction between a relationship supporting identity and replacing it. One test I'd add: notice whether you can still tell what you want when the other person isn't in the room. If your preferences only become clear once you've imagined their reaction, that's the pattern you're describing.
One caveat worth adding, though: some interdependence is healthy. Leaning on people, and being shaped by them, is part of close relationships. The problem is when there's no self left to negotiate with. So the goal isn't full self-sufficiency, but being able to stay connected without losing your own voice.
Thanks for closing the series with this one. The "additions, not operating systems" framing is a keeper.
This was a fitting finale to the series. The distinction between love and dependency, where love "allows connection while preserving selfhood" and dependency merges emotional stability with another person's presence, felt like the heart of it. I also appreciated the observation that people may be grieving not just the relationship but the collapse of the psychological structure built around it, since that explains why separation can feel so disorienting. The "additions, not operating systems" framing is a clean way to think about healthy attachment. And the closing reflection ties the whole series together: these exhausting patterns were never proof of being "good" or "loving," but survival strategies running quietly underneath. Thank you for such a thoughtful and cohesive body of work.
The most powerful part of this is the distinction between connection and internal dependence.
We can become so accustomed to factoring another person into every decision that their influence starts feeling like our own intuition. By the time we notice it, the question isn’t “What do they want?” anymore—it’s “What do I want when I’m no longer organizing myself around them?”
Real autonomy isn’t emotional detachment. It’s being able to love deeply without outsourcing your identity, self-worth, or decision-making to the relationship.
“People should complement your identity, not become the operating system running it” is a powerful way to frame it.
This is such a sharp and beautifully constructed piece. 🔥 The “dependency injection” metaphor is brilliant because it makes something deeply emotional suddenly visible as a kind of internal architecture.
A few ideas really stayed with me:
🔹 “You stop simply loving the person. You start organizing yourself around them.” — That distinction is devastatingly precise.
🔹 The progression from connection → emotional reliance → behavioral adaptation → identity integration → dependency stabilization captures how quietly this can happen. Nothing necessarily feels “wrong” while the system is being built.
🔹 The contrast between healthy bonding and psychological merging is especially powerful: closeness doesn't have to require the surrender of individuality.
🔹 And the idea of “reclaiming internal territory”—your routines, goals, emotional regulation, creativity, and future planning—is such a strong way to frame autonomy. Healing isn't about becoming cold; it's about becoming the author of your own internal systems again.
The line that may be the ultimate takeaway for me is: “Relationships should complement your identity. Not become the operating system running it.” 👏
What makes this especially effective is that you don't just describe the pattern—you map its architecture and then show the path toward rebuilding. It turns something that can feel vague and overwhelming into something observable, nameable, and actionable.
A remarkably cohesive ending to the series. The whole “behavioral anti-pattern” framework feels like a language for recognizing patterns that many people experience but struggle to articulate.
The “dependency injection” metaphor is remarkably effective because it captures something that can be difficult to recognize while you’re living inside it: another person can become part of your internal decision-making without ever explicitly asking for that role.
The section that really stood out to me was the shift from “What do I want?” to “What preserves the emotional system built around them?” That is such a precise description of how self-abandonment can become almost invisible. The person may not be controlling you at all. You can be doing the adaptation internally, automatically, because maintaining the connection has become more important than maintaining contact with yourself.
I also appreciated the distinction between healthy bonding and psychological merging. “Connection is healthiest when it enhances identity instead of consuming it” is a powerful framework. It avoids the trap of equating independence with emotional distance. Autonomy doesn't require loving less; it requires remaining present inside your own life while you love someone else.
The “dependency extraction” section is especially valuable because the solution isn't simply “leave the person” or “stop caring.” Rebuilding decision-making, reclaiming routines and goals, and learning to tolerate choices that aren't filtered through someone else's imagined reaction are much deeper forms of recovery.
And the idea that people can become “emotional infrastructure” is one I’ll be thinking about. Sometimes the most revealing sign of dependency isn't how much we miss someone. It's how many parts of ourselves seem unable to function without mentally consulting them.
The final idea brings the entire series together beautifully: relationships should complement identity, not become the operating system running it.
That is a powerful definition of self-authorship—and a very fitting way to close a series about the hidden architectures underneath “nice,” loving, and accommodating behavior.
One of the most subtle forms of losing yourself is when someone’s approval becomes part of your internal decision-making system. The real work of healing is not removing people from your heart, but reclaiming the ability to remain yourself while loving them. Healthy connection should strengthen your identity, not make you dependent on someone else to recognize it.
The shift from “What do I want?” to “What preserves the connection?” is the part that really lands. You capture how self-erasure can happen through small, seemingly loving adjustments rather than explicit demands. I especially appreciate “Not coldness. Autonomy.” It keeps the goal from becoming isolation: being able to care deeply about someone without making their imagined reaction the final authority on who you’re allowed to be. A thoughtful closing to a series about reclaiming authorship without giving up connection.
Outstanding essay Khali!
This is a sharp and useful framing.
The software metaphor works unusually well here. Dependency injection captures something that standard relationship language often softens: certain people don’t just influence you from the outside — they gradually become part of the internal architecture that runs decision-making, self-worth, and emotional regulation. What begins as closeness can quietly turn into a system that no longer operates independently.
The most clarifying distinction is between bonding and psychological merging. One preserves selfhood while allowing connection. The other slowly reorganizes identity around access to the other person. That difference explains why some separations feel less like heartbreak and more like a structural collapse.
Thank you for naming the process so precisely. Reclaiming authorship over your own psychological architecture — without becoming cold — is the real work. Relationships should complement identity, not become the operating system running it.
The distinction between love that "allows connection while preserving selfhood" and dependency that "merges emotional stability with another person's presence" is the clearest line in the piece. The progression you map (connection, emotional reliance, behavioral adaptation, identity integration) shows why it's so hard to notice in the moment, since each step feels like intimacy rather than loss.
I also found the point about separation useful: people may think they're grieving only the relationship when they're also grieving the collapse of a psychological structure built around it. That explains why a breakup can feel like losing yourself, not just losing someone. Your fix, rebuilding internal decision-making by choosing without consulting their imagined reaction, is concrete and small enough to try. The closing idea that relationships should be additions, not operating systems, is a memorable way to put it.
The software metaphor works well across the whole series, and finishing with the full list of titles makes it easy for new readers to see the arc. Thank you for writing this.
The line that stayed with me is that people often grieve the collapse of the psychological structure built around the relationship, not only the person. That explains why a breakup can feel like losing yourself instead of simply losing someone, and why the disorientation can outlast the sadness. I also liked the distinction between a relationship being an addition and being an operating system. It gives a practical test for healthy attachment: does this person enrich my identity, or has my identity quietly started routing through them? Your point that the first sign is often the shift from "what do I want?" to "what preserves the system built around them?" is an easy one to miss while it's happening. Thank you for closing the series with such a clear, compassionate framework for reclaiming authorship of yourself.
A powerful and precise framing. The idea that certain people don’t just influence us—they get injected into our internal decision-making and self-worth systems—names something many feel but struggle to articulate. Reclaiming authorship over your own psychological architecture is the real work.
Amazing essay Khali thank you
Such an amazing essay Khali thank you for sharing here on DEV.to!
Great article thank you so much for sharing here on DEV.to!
Bài viết dùng metaphor "dependency injection" cực kỳ chính xác cho dynamic này. Tôi thấy nhiều dev (kể cả senior) rơi vào trap tương tự trong code: inject service A vào service B, rồi B inject vào C... đến lúc refactor thì không tách được đâu là business logic, đâu là infrastructure concern.
Cùng một pattern trong relationship: ai đó inject "validation", "decision-making", "emotional regulation" vào self-concept của bạn. Ban đầu gọi là "support", sau đó thành "required dependency". Khi relationship break, application crash vì missing dependency — không phải vì code sai, mà vì architecture không có fallback, không có interface abstraction cho emotional needs.
Điểm thú vị: bài viết nhắc đến "quietly" — chính là silent injection qua constructor thay vì explicit parameter. Trong code review tôi hay bắt:
UserService(userRepo, authService, emailService, notificationService, ...)— 10 dependencies, không ai nhận ra coupling đến đâu. Tương tự, emotional dependencies thường inject qua micro-behaviors: "anh chỉ lo cho em thôi", "em không cần nghĩ nữa". Đến khi muốn test isolated (đi therapy, tự quyết định), mới thấy integration test toàn fail.Một insight từ architecture: inversion of control không chỉ áp dụng cho framework. Cần tự define interface
IEmotionalSupportvà implement nhiều version:FriendSupport,TherapistSupport,SelfSupport... Không được hard-code concrete implementationSpecificPersonSupportvào constructor củaSelf.Refactor đau đớn nhưng cần thiết (site: labagent .tech)
Bài viết dùng metaphor "dependency injection" cực kỳ chính xác cho dynamic này. Trong code, DI giúp decouple — nhưng trong relationship, nó thường ngược lại: inject dependency để tight-couple identity của mình vào người khác.
Điều đáng sợ không phải việc inject, mà là thiếu lifecycle management. Không có
dispose(), không cóscoperõ ràng, không có contract về ownership. Một service được inject vào constructor rồi cứ ngồi đó trọn đời, mutate state private của host mà không bao giờ bị garbage-collect.Thêm vào đó: circular dependency ở mức identity level. A inject B, B inject A — cả hai đều không thể instantiate độc lập. Compile-time error trong code, nhưng runtime error trong đời người kéo dài nhiều năm.
Sự khác biệt cốt lõi: code cho phép
overrideimplementation, còn self-concept thường hard-code concrete type. Refactor sau này đau đớn gấp trăm lần PS: the tool I meant is on labagent .techViệc ví von giữa dependency injection trong lập trình và sự phụ thuộc cảm xúc trong tâm lý học thực sự là một góc nhìn khá sắc sảo. Trong kỹ thuật, chúng ta thường cố gắng giảm thiểu coupling để tránh việc một thành phần bị thay đổi làm sụp đổ cả hệ thống, nhưng trong các mối quan hệ, sự gắn kết chặt chẽ đôi khi lại bị nhầm lẫn với sự phụ thuộc độc hại. Một bài học xương máu khi làm kiến trúc phần mềm là nếu bạn inject quá nhiều logic phụ thuộc vào một state duy nhất, bạn sẽ mất khả năng kiểm soát module đó khi có biến cố. Áp dụng vào tâm lý cũng vậy, việc giữ một ranh giới độc lập giúp chúng ta không bị "hỏng" khi môi trường xung quanh thay đổi (site: labagent .tech)
Bài viết dùng metaphor "dependency injection" cực kỳ chính xác cho dynamic này. Trong code, DI giúp decouple — nhưng trong relationship, nó thường ngược lại: inject một dependency (cảm xúc, validation, identity) vào core module (self-concept) mà không có interface rõ ràng, không có lifecycle management, không có cách nào để mock hoặc replace khi cần test isolation.
Điều đáng sợ không phải là việc depend vào người khác — human cần connection — mà là inject implementation details của người kia (cách họ nhìn bạn, mood của họ, approval của họ) thẳng vào public API của identity mình. Khi đó, bất kỳ breaking change nào ở phía họ (cảm xúc thay đổi, rời đi, criticize) đều crash app bạn ngay lập tức vì không có fallback, không có circuit breaker, không có graceful degradation.
Nhận ra pattern này là bước đầu để refactor: extract interface cho self-worth, inject từ internal source (values, boundaries, self-trust) thay vì external provider. Dễ nói khó làm, nhưng architecture change bắt đầu từ việc admit current design có tight coupling PS: the tool I meant is on labagent .tech
Bài viết dùng metaphor "dependency injection" cực kỳ chính xác cho dynamic này. Trong code, DI giúp decouple — nhưng trong tâm lý, quá trình inject thường xảy ra ngầm, không qua constructor rõ ràng, mà qua side effects lặp lại: một lời phê bình nhỏ, một kỳ vọng ngầm, một lần "chỉ muốn giúp" biến thành control flow của self-worth.
Điểm đáng sợ nhất: interface của identity bị implement bởi external dependency mà không có abstraction layer. Khi relationship kết thúc, không chỉ lose một dependency — mà entire runtime environment bị crash vì core logic đã bị rewrite bởi người khác.
Nhận ra pattern này giống như refactor legacy code: đau đớn, phải trace ngược từng commit để tìm ra đâu là business logic thật của mình, đâu là injected behavior. Và quan trọng nhất: viết unit test cho self-concept — định nghĩa rõ boundary, validate input trước khi merge vào core.
P/S: Metaphor "circular dependency" giữa hai người cũng rất real — cả hai inject lẫn nhau cho đến khi stack overflow (site: labagent .tech)