Hi, I'm Nikki. Backend developer, architect and a fox girl.

Why I use it

Where predictability under load matters. The compiler catches at build time what surfaces in production in other languages — for services that can’t go down, that’s the deciding argument. No garbage collector also means flat latency without surprise pauses.

How long

3 of my 6 years in development. It’s been my main language for the last few years — most of what I’ve built in that time is written in it.

What I build with it

• Platform cores and high-load services
• Data processing and transformation
• Telegram bots with non-trivial logic
• Parsers where speed and resilience matter

Зачем он мне

Там, где важна предсказуемость под нагрузкой. Компилятор ловит на этапе сборки то, что в других языках всплывает уже в проде — для сервисов, которые нельзя ронять, это решающий аргумент. Плюс отсутствие сборщика мусора даёт ровную латентность без неожиданных пауз.

Сколько пишу

3 года из 6 лет разработки. Основной язык последних лет — на нём написана бо́льшая часть того, что я делала за это время.

Что на нём делаю

• Ядро платформ и высоконагруженные сервисы
• Обработка и трансформация данных
• Телеграм-боты с нетривиальной логикой
• Парсеры, где важны скорость и живучесть

Why I use it

A compromise between strictness and writing speed. The type system is strict enough to keep silly things out of runtime, but it’s noticeably faster to write than Rust. Good where the JVM ecosystem is what you need.

How long

About a year. I picked it up for one project and kept it — a good example of how a new language shows up in my stack: out of a task, not out of a wish to add a résumé line.

What I build with it

• JVM services
• Telegram bots
• Integrations with third-party APIs

Зачем он мне

Компромисс между строгостью и скоростью письма. Система типов достаточно строгая, чтобы глупости не доезжали до рантайма, но писать заметно быстрее, чем на Rust. Хорош там, где нужна именно экосистема JVM.

Сколько пишу

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

Что на нём делаю

• JVM-сервисы
• Телеграм-боты
• Интеграции со сторонними API

Why I use it

The actor model on the BEAM solves a problem you otherwise assemble by hand: thousands of independent processes, supervisors, failure isolation. If part of the system crashes it restarts itself while the rest keeps running — for distributed services that saves an enormous amount of effort.

Where I use it

• Microservice architecture on a project with unusual requirements
• Services with many simultaneous connections
• Paired with Rust where both concurrency and raw speed are needed

Зачем он мне

Модель акторов на BEAM решает задачу, которую иначе собираешь руками: тысячи независимых процессов, супервизоры, изоляция отказов. Если часть системы падает, она перезапускается сама, пока остальное продолжает работать — для распределённых сервисов это экономит огромное количество сил.

Где использую

• Микросервисная архитектура на проекте с нестандартными требованиями
• Сервисы с большим числом одновременных соединений
• В паре с Rust там, где нужны и конкурентность, и сырая скорость

Why I use it

The shortest path from idea to a working result. I keep it for things that need solving once, or for testing a hypothesis — rewriting that in Rust for performance usually makes no sense.

How long

About two years out of six. These days it’s a supporting language, not a primary one.

What I build with it

• Prototypes and hypothesis checks
• One-off data processing
• Scripts and some parsers

Зачем он мне

Самый короткий путь от идеи до работающего результата. Держу его для того, что нужно решить один раз, или для проверки гипотезы — переписывать это на Rust ради производительности обычно не имеет смысла.

Сколько пишу

Около двух лет из шести. Сейчас это вспомогательный язык, а не основной.

Что на нём делаю

• Прототипы и проверка гипотез
• Разовая обработка данных
• Скрипты и часть парсеров

Why I use it

“Postgres for everything” is the most common default architectural decision, and the most common source of pain a year later. When data is wide, writes are heavy and load is distributed, Scylla gives predictable latency and horizontal scaling without rewriting the data layer.

Where I use it

• Cores of platforms built from scratch
• Write-heavy workloads

Зачем она мне

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

Где использую

• Ядро платформ, построенных с нуля
• Нагрузки с преобладанием записи

Why I use it

Time series live by different rules than ordinary tables: they’re almost always appended, read by ranges, and age predictably. Storing them together with the rest of the data means paying for it in both volume and query speed.

Where I use it

• Service metrics and monitoring
• Event logs and change history
• Range-based analytics

Зачем она мне

Временные ряды живут по другим правилам, чем обычные таблицы: их почти всегда дописывают, читают диапазонами и они предсказуемо стареют. Хранить их вместе с остальными данными — значит платить за это и объёмом, и скоростью запросов.

Где использую

• Метрики и мониторинг сервисов
• Логи событий и история изменений
• Аналитика по диапазонам

What that means in practice

The studio does outsourced development and is moving toward long-term contracts directly with companies rather than one-off orders. I hired the team myself, so I answer for their level personally.

What I take on

• Scoping and stack choice before the start
• Assembling and running the team for the project
• Responsibility for the result, not just my slice of the code

Что это значит на практике

Студия занимается аутсорс-разработкой и движется к долгосрочным контрактам напрямую с компаниями, а не к разовым заказам. Команду я набирала сама, поэтому за её уровень отвечаю лично.

Что беру на себя

• Оценку задачи и выбор стека до старта
• Сборку команды под проект и её ведение
• Ответственность за результат, а не за свой кусок кода

How I approach it

I start not from technologies but from how the system will behave under load and how it will be changed. The stack is chosen last, from the requirements rather than from habit. I keep the whole project in my head, not just my module.

What it covers

• Service boundaries and areas of responsibility
• Data model and storage choice matched to the load profile
• What scales and why, and where the bottleneck will be

Как я к этому подхожу

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

Что сюда входит

• Границы сервисов и зоны ответственности
• Модель данных и выбор хранилища под профиль нагрузки
• Что масштабируется и зачем, и где окажется узкое место

Why I combine the two

A tech lead who stops writing code loses their grip on estimates fairly quickly. I know how long the task I’m assigning actually takes, because I do the same kind of work on the same project.

What the project gets

• Honest timelines instead of optimistic ones
• Review from someone who knows the context from the inside
• One code standard across the whole team

Почему совмещаю

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

Что от этого получает проект

• Честные сроки вместо оптимистичных
• Ревью от человека, который знает контекст изнутри
• Один стандарт кода на всю команду

The main principle

Code is written once and maintained for years. So a solution that looks great in a demo and falls apart a year later isn’t a solution to me. I build in clear boundaries and predictable behaviour from the start — it’s cheaper than rewriting.

What it looks like in practice

• The stack is chosen for the task, not for fashion
• Service boundaries are designed up front, not after the fact
• A new tool comes in for a specific task, never just in case

Главный принцип

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

Как это выглядит на практике

• Стек выбирается под задачу, а не под моду
• Границы сервисов проектируются заранее, а не постфактум
• Новый инструмент приходит под конкретную задачу, а не про запас