Пси-словарь для айтишников v1.1: Семейные ценности

В предыдущей статье я попробовала описать типы привязанности как сетевые протоколы, разобраться, как большинство из нас строит отношения. Было сделано предположение, что типы привязанности — те невидимые протоколы, по которым наше сердечко подключается к другим людям. Кто-то легко доверяет и остаётся на связи даже в шторм. Кто-то постоянно проверяет: «Ты ещё здесь?». А кто-то заранее закрывает порты, чтобы не рисковать.

И после возникает логичный вопрос: Если привязанность — это протокол, то кто его настроил?

От КАК к ПОЧЕМУ

Первая статья серии отвечала на вопрос «как» мы создаем связи с людьми и ведем себя в отношениях. Эта статья станет попыткой приоткрыть завесу и найти ответ на вопрос «почему».

Если представить вашу психику как приложение, то:

• Привязанность — это то, как вы подключаетесь к другим.

• Детство — это среда, где был написан исходный код.

Можно сколько угодно обновлять интерфейс, менять настройки, читать статьи об отношениях. Но если не заглянуть в исходный код — система будет стремиться вернуться к тому, что записано в ядре.

Не для того, чтобы найти виноватых. Не для того, чтобы сказать: «Всё плохо, и это неисправимо». А для того, чтобы понять. Понимание — это уже половина свободы. Когда вы видите, откуда растёт ваш паттерн, он перестаёт быть «просто мной» и становится «кодом, который можно переписать».

Эта тема может задеть за живое. Может вызвать грусть, злость, сопротивление. Это нормально. Моя цель — дать вам подсказку, показать путь к тому, как можно стать Архитектором своей жизни. Не исполнителем чужих скриптов, а Автором своего кода.

• Если вы читали первую часть и узнали себя — здесь вы, возможно, найдёте ответы на «откуда это во мне».

• Если вы замечаете повторяющиеся сценарии в отношениях — поймёте, где они записаны.

• Если вы хотите что-то изменить, но не знаете с чего начать — здесь будут инструменты.

• Если у вас сложные отношения с родными — эта статья написана так, чтобы речь шла о функциях, а не о биологии. Без вины. С пониманием

• Если у вас всё хорошо — здесь вы найдёте способы поддержать то, что уже работает. И передать следующему поколению более красивый (или чистый?) код.

Hello World — первый репозиторий

Представьте, что вы — приложение. У вас есть интерфейс (то, как вас видят другие), бэкенд (внутренние процессы) и API (способы взаимодействия с миром). У вас есть баги (паттерны, которые мешают) и фичи (сильные стороны). Вы регулярно получаете обновления (новый опыт) и иногда — критические уязвимости (травмы).

Вопрос: Где был написан ваш исходный код?

Если продолжить метафору — первая версия вас была разработана в детстве и чаще всего в семье. Это был ваш localhost, среда разработки, где вы провели первые 18+ лет. Там были созданы базовые скрипты:

• Как доверять миру

• Как строить отношения

• Как обращаться с эмоциями

• Чего ожидать от других

• Кто вы вообще такой

И самое важное: вы не выбирали эту среду разработки. Вам выдали доступ к репозиторию значимых взрослых — со всем их legacy-кодом, недокументированными зависимостями и скрытыми багами.

Жизненные сценарии как реализация кода

В транзактном анализе есть такое понятие как жизненный сценарий. Это бессознательный план, по которому человек живёт свою жизнь каждый день. В ИТ-терминах:

Жизненный сценарий = Runtime-реализация вашего кода

Код написан в детстве, но исполняется всю жизнь. И если в коде есть ошибка — она будет воспроизводиться снова и снова, пока вы не найдёте и не исправите её.

Например, код мог быть записан в возрасте 10 лет, когда значимые взрослые хвалили только за пятёрки. Но исполняется он и в 30, когда вы горите на работе ради одобрения значимого для вас человека (тимлида).

# Сценарий: "Я должен быть идеальным"
def self_worth(achievement):
    if achievement.perfection_level >= 100:
        return "temporary_ok"
    else:
        return "shame"

# Запускается каждый раз, когда вы что-то делаете
# Результат: хроническое чувство "недостаточно хорош"

Как создается исходный код?

Код не пишется за один день. Это постепенное накопление коммитов на разных этапах взросления:

Каждое взаимодействие со значимыми взрослыми — это коммит в репозиторий. Некоторые коммиты задокументированы («мы тебя любим»), некоторые — нет (холодность, игнор, противоречивые сигналы).

И вот что важно: ребёнок не может выбрать, какой код будет записан. Он вынужденно адаптируется к среде. Если среда требует молчать — пишется код suppress_emotions(). Если среда требует быть идеальным — пишется код perfectionism_check(). Если среда непредсказуема — пишется код hypervigilance_monitor().

Это не баг. Это адаптация, способ выжить. И вот этот сложный код как-то работал в тестовой среде (в семье), а после вы выносите его в production (во взрослую жизнь).

Какие сценарии возможны?

Вот несколько типичных «сценарных скриптов», которые мы видим на практике:

Сценарий 1: «Спасатель»

def handle_relationships(problem):
    if problem.severity > 0:
        self.sacrifice()
        fix_for_other()
    return "worth_through_service"

Откуда: Ребёнок научился, что любовь = полезность.
Во взрослой жизни: Отношения через служение, выгорание, обиды.

Сценарий 2: «Недостаточно хорош»

def evaluate_self(achievement):
    if achievement < perfection_threshold:
        return "shame"
    else:
        return "temporary_relief"  # не радость, а облегчение

Откуда: Хвалили только за достижения, имеющие ценность для взрослых. Во взрослой жизни: Перфекционизм, прокрастинация, выгорание.

Сценарий 3: «Не доверяй никому»

def handle_intimacy(request):
    if request.type == "emotional":
        raise ConnectionRefusedError("Too risky")
    return "isolation"

Откуда: Эмоциональная недоступность значимых взрослых, они непредсказуемы. Во взрослой жизни: Избегающая привязанность, одиночество.

Сценарий 4: «Не обременяй»

def express_need(need):
    if need.intensity > "minimal":
        suppress()  # Подавить, чтобы не грузить систему
    return "invisibility"

Откуда: Значимые взрослые были перегружены: работа, выгорание, кризис, много детей. Во взрослой жизни: Гипернезависимость, трудности с просьбами о помощи, «я сам», невидимость для других.

Сценарий 5: «Исправь значимых взрослых»

def handle_caregiver_mood(mood):
    if mood == "bad":
        self.adjust_behavior()
        try_to_fix()
    return "responsibility_for_others"

Откуда: Парентификация (смена ролей в семье, ребенок вынужденно взял на себя ответственность за состояние взрослых), ребёнок стал эмоциональным контейнером. Во взрослой жизни: Отношения с «трудными» партнёрами, желание спасать.

Важное уточнение: семейные сценарии редко запускаются по одному. Чаще это набор микросервисов, которые работают параллельно: где-то срабатывает «не доверяй», где-то — «будь удобным», где-то — «справляйся сам».

Пока сценарий работает в фоне (background process), вы будете думать: «Это просто моя личность». Но это не совсем так и не только личность. Во всем этом есть и “код, который был когда-то написан”.

И хорошая новость: код можно переписать. Не весь. Не сразу. Но можно:

1. Найти проблемные скрипты (наблюдение)

2. Понять, зачем они были нужны (контекст)

3. Решить, работают ли они сейчас (аудит)

4. Переписать те, что мешают (рефакторинг)

И да, идеальных семей, скорее всего, не существует. Как не бывает проекта без технического долга. У всех есть legacy. У всех есть баги, которые передались по наследству.

Core Dependencies: Значимые взрослые и другие сервисы

В программировании есть понятие dependency — внешний модуль, от которого зависит работа системы. Вы можете выбрать библиотеки для своего проекта. Но в детстве зависимости были прописаны принудительно.

Два основных сервиса, на которых держалась система в детстве:

• Первичная забота → Primary Backend Service (в статье условно «Мать»)

• Защита и социализация → Security Gateway / External API (в статье условно «Отец»)

Важное уточнение:

В этой статье термины «Мать» и «Отец» используются не как биологические роли, а как функциональные сервисы в системе развития ребенка. Эти сервисы могут предоставляться кем угодно:

Ключевой принцип: Психике важно не «кто по паспорту», а какую функцию выполняет человек. Если биологический отец отсутствует, но есть дедушка или дядя, который транслирует правила и защищает — дед (дядя) и есть Gateway для этой системы. Если значимый взрослый в депрессии, а заботу и любовь даёт бабушка — бабушка становится Primary Backend.

Primary Backend Service (условно «Мать»)

Британский педиатр и психоаналитик Дональд Винникотт ввёл понятие «достаточно хорошая мать». Это не идеальная мать, но ее роль наиболее важна в первые 3 года жизни ребенка, когда формируется базовое доверие к миру. Это значимый взрослый, который:

• Отвечает на потребности ребёнка в большинстве случаев

• Иногда ошибается — и это нормально

• Восстанавливает связь после разрывов

В наших терминах:

Ключевая мысль

«Достаточно хороший значимый взрослый» — это не 100% uptime. Это сервис с разумным error handling.

Именно в моментах «разрыв → восстановление» ребёнок учится:

1. Мир не рушится от ошибок

2. Связь можно восстановить

3. Я переживу фрустрацию

Если значимый взрослый всегда идеален (100% uptime) — ребёнок не учится справляться с фрустрацией. Если значимый взрослый всегда недоступен (<80% uptime) — ребёнок учится не доверять миру.

Типовые сбои Backend-сервиса

Security Gateway / External API (условно «Отец»)

Если Primary Backend — это внутренняя среда (питание, забота, базовая безопасность), то Gateway — это шлюз между внутренней системой и внешним миром.

Ключевая мысль

Gateway — это не «второй значимый взрослый». Это отдельный сервис с собственной функцией.

Если Primary Backend учит доверять, то Gateway учит взаимодействовать с миром за пределами семьи.

Типовые сбои Gateway-сервиса

Third-Party Services: Другие значимые фигуры детства

Довольно часто семья это не только два основных сервиса. Вот как выглядят другие фигуры в предложенном фрейме:

Важное замечание

Не все зависимости должны быть активны в проде.

Некоторые third-party services были нужны в localhost (детстве), но во взрослой жизни их можно оставить как есть, а можно:

• Отключить (disable dependency)

• Заменить (swap provider)

• Обновить (upgrade version)

Это и есть часть сепарации, развития и взросления каждого из нас.

Migration Guide: Как переписать код, не сломав систему

Принцип 1: Не вините разработчиков

Значимые взрослые действовали из своего legacy. Они передали то, что получили. Без вины, но с ответственностью

Метафора: Blameless Postmortem — разбор инцидента без поиска виноватых.

Принцип 2: Аудит кода

Прежде чем рефакторить — поймите, что работает, а что нет

Чек-лист:

• Какие паттерны помогают мне в жизни?

• Какие паттерны мешают?

• Откуда они пришли?

• Что я хочу сохранить?

Принцип 3: Постепенная миграция

Не делайте DROP DATABASE. Реализуйте постепенную миграцию.

Возможные стратегии вашей новой версии себя:

Принцип 4: Тестирование

Прежде чем внедрять изменения в production — тестируйте.

Практика:

• Пробуйте новые паттерны в безопасной среде (терапия, близкие отношения)

• Отслеживайте error logs (тревога, вина, сопротивление)

• Делайте rollback если слишком тяжело

Принцип 5: Документация

Запишите свои новые правила ❤️

# Personal Config v2.0
boundaries:
  caregivers: read-only access
  partner: full access with ACL
self_care:
  priority: high
  schedule: daily

Open Issues & Contributions

Эта статья, надеюсь, не останется монологом. Хотелось бы, чтобы текст стал началом разговора. И я приглашаю вас поучаствовать.

1. Оставьте лог в комментариях. Какой инсайт стал для вас самым неожиданным? Что «кликнуло» при чтении?

2. Предложите метафору. Как бы вы назвали свой процесс сепарации в терминах IT — Fork, Deploy, Migration, Refactor?

3. Запрос фичи для v1.3. Какую тему хотели бы разобрать следующей? Выгорание, команда, архетипы, синдром самозванца?

4. Поделитесь с тем, кому это нужно. Отправьте статью коллеге, другу или тому, кто сейчас в процессе «миграции» от родительской системы. Иногда один вовремя полученный код-ревью меняет всё.

Ключевая мысль статьи

Текст создан с целью понять архитектуру. Стать архитектором своей системы, а не исполнителем чужого кода.

Вы не можете переписать историю коммитов. Вы не можете выбрать репозиторий, в котором родились.

Но вы можете решить:

• Какой код пойдёт в следующий релиз

• Какие зависимости оставить, а какие — отключить

• Кто будет иметь доступ к вашей системе

• Какие протоколы использовать в отношениях

Это и есть свобода. Не в том, чтобы не иметь legacy. А в том, чтобы осознанно работать с ним.

Важное напоминание: Данная статья является метафорическим материалом для самоанализа и не заменяет профессиональную психотерапию. Тема может вызвать сильные эмоции. Если вы чувствуете сопротивление, гнев, грусть — это нормально. Иногда лучший рефакторинг происходит с внешним консультантом (терапевтом).