Программисты против инженеров: почему первые становятся бесполезными

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

Сейчас в IT есть четкое разделение:

• «Программисты» — это те, кто считает, что достаточно изучить пару библиотек и закрыть задачи в Jira. Их аргументы таковы:

• «Математика не нужна»

• «Английский не нужен»

• «Computer Science — для ученых»

  и другая чушь

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

А что насчет DDD? Может тоже стоит изучить?

Проблема в том, что первых стало больше, и они ухудшают ситуацию в отрасли. Их код — это костыли, их системы падают под нагрузкой, а их главный навык — поиск в Google Stack Overflow или в ИИ

1. Подсистема памяти: где "быстрый код" становится медленным

• Ложный общий доступ: Когда два потока записывают данные в разные переменные одной и той же строки кэша (64 байта), производительность падает в 10–100 раз.

• NUMA: Доступ к «чужой» памяти в системах с несколькими сокетами может быть в 3–5 раз медленнее

• Шаблоны предварительной выборки : Как написать код, чтобы аппаратная предварительная выборка работала на вас

2. Многопоточность без блокировок

• RCU (Read‑Copy‑Update): Как ядро Linux обрабатывает синхронизацию на более чем 100 ядрах

• Seqlocks: Оптимизация для сценариев с большим объемом чтения (и почему это не подходит для всех случаев)

• Порядок расположения памяти на разных архитектурах: x86-TSO против ARM/POWER (почему ваш код без блокировки будет взломан)

3. Особенности компиляторов и исполнения

• Неопределенное поведение (UB): Как -O3 превращает «рабочий» код в нерабочий

• Правило «как если бы»: Почему компилятор может изменять порядок операций

• Подводные камни встроенного ассемблера : Почему «asm volatile» не всегда достаточно

4. Глубокий анализ сетевого стека

• TCP_NOTSENT_LOWAT: Как уменьшить задержки в 2–3 раза с помощью настроек сокета

• eBPF/XDP: Обработка пакетов в ядре до того, как они попадут в пользовательское пространство

• QUIC против TCP : почему HTTP/3 не является панацеей (и когда это хуже)

5. Безопасность за пределами Топ-10 OWASP

• JIT‑распыление : Как движки JS используются с помощью тепловых схем

• Rowhammer: Чтение/ запись в память без доступа с помощью физических воздействий

• Атаки на спекулятивное выполнение : Почему защита снижает производительность на 30–50%

6. Нюансы оптимизации производительности

• Счетчики PMU: Как правильно интерпретировать perf stat (не все показатели одинаково полезны)

• Кэши VIPT : Почему выравнивание по‑разному важно в ARM и x86

• MLP (параллелизм на уровне памяти) : Как измерить и улучшить

Как глубокие знания создают нейронные связи для неочевидных решений

1. Механика понимания

Когда вы изучаете:

• Порядок памяти в C++ → начинаете замечать скрытые условия гонки в распределенных системах

• Предварительная выборка шаблонов процессора → прогнозирование узких мест в алгоритмах перед профилированием

• Внутренние компоненты QUIC → автоматически учитывают компромиссы при разработке API

Это не отдельные знания — это единая система, где каждая тема дополняет другие.

2. Реальные примеры междоменной аналитической работы

• Криптография + оптимизация:
  Знание AES‑NI → помогает оптимизировать завершение работы по протоколу SSL (в 5–8 раз быстрее)

• Сети + безопасность:
  Понимание Повторной сборки TCP→ позволяет находить уязвимости в IDS/IP‑адресах

• Компиляторы + распределенные системы:
  Знание Оптимизации LLVM→ поможет вам создавать эффективные сериализаторы для RPC

3. Почему поверхностные знания не работают

«Программист», который изучал только:

• REST API → не увидит проблему с блокировкой заголовка строки в HTTP/2

• Базовый SQL → не поймет, как слияние индексов снижает производительность

• Примитивные блокировки → не распознает эффект конвоя в системах с высокой нагрузкой

Практический пример

Ситуация: Платежный сервис теряет транзакции при загрузке.

Обычный разработчик:

• Добавит логи

• Увеличит время ожидания

Инженер:

1. Проверьте RCU в ядре (конфликтует с приложением)

2. Проанализируйте потерю пакетов PCIe с помощью perf

3. Найдите проблемы TSO/GRO в сетевом стеке

4. Устраните их с помощью eBPF + барьеров памяти**

Философия мастерства

Когда вы инвестируете в:

• Глубокое понимание аппаратного обеспечения → вы начинаете «чувствовать» производительность

• Анализ атак → проектирование систем с учетом требований безопасности

• Стандарты чтения → предвидеть крайние случаи до того, как они появятся

Речь идет не о «большем количестве знаний», а о качестве мышления ^[1] .

Я не хочу слишком растягивать пост, потому что, по‑моему, идея ясна. уж слишком все очевидно

и таких примеров много

❗Software Developer -> Software Engineer