Я ориентируюсь на изучение, а не на результат, здесь быстро результатов не добьешься, главное — понимать, что нужно сделать.
Сейчас в 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 → не поймет, как слияние индексов снижает производительность
Примитивные блокировки → не распознает эффект конвоя в системах с высокой нагрузкой
Практический пример
Ситуация: Платежный сервис теряет транзакции при загрузке.
Обычный разработчик:
Добавит логи
Увеличит время ожидания
Инженер:
Проверьте RCU в ядре (конфликтует с приложением)
Проанализируйте потерю пакетов PCIe с помощью perf
Найдите проблемы TSO/GRO в сетевом стеке
Устраните их с помощью eBPF + барьеров памяти**
Философия мастерства
Когда вы инвестируете в:
Глубокое понимание аппаратного обеспечения → вы начинаете «чувствовать» производительность
Анализ атак → проектирование систем с учетом требований безопасности
Стандарты чтения → предвидеть крайние случаи до того, как они появятся
Речь идет не о «большем количестве знаний», а о качестве мышления .
Я не хочу слишком растягивать пост, потому что, по‑моему, идея ясна. уж слишком все очевидно
и таких примеров много
❗Software Developer -> Software Engineer
Комментарии (11)
randomsimplenumber
19.07.2025 06:37Нейросетевое..
Обычный разработчик:
Добавит логи
Увеличит время ожидания
Инженер:
Проверьте RCU в ядре (
То есть обычный разработчик пытается разобраться что происходит. Инженер достает справочник по красным резиновым шарикам и шпарит по скрипту. Ну-ну ;) А того, кто поинтересуется, что в системе поменялось, в этой иерархии почему то нет.
Indifferentno
19.07.2025 06:37Щас тебе пояснят комментаторы кто где куда разработчик
MicroProger
19.07.2025 06:37Точно, это совсем не та аудитория :D
Но а с другой стороны, а почему бы и нет?
lamerok
19.07.2025 06:37Ситуация: Платежный сервис теряет транзакции при загрузке
Инженер, не разобравшись в проблеме начинает предлагать решения?
По-моему первый шаг в любой проблеме, это Анализ. И добавление логов очень для этого подходит.
А инженер, ощущение, что просто кидается фразами в стиле "На любой вопрос даю любой ответ"
Ну либо опять текст от ИИ, она тоже как инженер будет действовать.
VasilievVictor
19.07.2025 06:37Когда-то университеты выпускали инженеров, инженер-системотехник, инженер-программист… Со временем, получив реального опыта и продолжив самостоятельное развитие, ими стали. Но времена поменялись и оказалось что для большинства работ достаточно поверхностных знаний и умений, да это и выгоднее в ряде случаев.
Выводы делать сложно, каждый, прочитав статью ставит себя на место умудреного опытом инженера )), наверняка это было одним из пунктов промта, благодаря которому мы читаем этот около технический текст.
NeoNN
19.07.2025 06:37Проблема в том в первую очередь, что есть авторы, а есть нейросетевые выс*ральщики, вторых становится больше, и они ухудшают ситуацию на хабре.
Belkogoth
19.07.2025 06:37По мне так "программист против инженера" звучит примерно как "стоматолог против врача"))) Инженер это уровень образования, методы взаимодействия с информацией и широта познаний) Программист же - это разновидность инженера)) Просто есть те, кто считает себя программистом, а есть нормальные выпускники ВУЗов, которые освоили самую базу, кучу околодисциплин, и дальше уже идет надстройка из основного направления специальности. Знаете ли, во всяких шарагах типа интернет-провайдеров (домру привет)))) есть профессии типа "инженер по подключению физлиц" =)))) А по факту это обычный монтажер с бухтой витухи в рюкзаке и лесенкой под мышкой))))
Все же, как по мне, есть некая классификация. Есть инженер (набор знаний, полученный в ВУЗе в дополнение к общему курсу 9-11 классов средней школы), есть техник (набор знаний за 9-11 класс с уклоном в специфику профессии, плюс некий объем знаний, добавленный за оставшиеся 3 года). А есть просто выпускник курсов, где накинули узкий набор знаний, необходимый для выполнения строго определенной задачи.
Так вот, большинство нонешних "погромистов", который понаехали изо всяких модных нонче интернет-курсов не тянут, как правило, ни на первый, ни на второй подвид. Это сугубо третий. Одноразовый инструмент для насыщения потребностей рынка остро востребованной на текущий период технологией. Рынок насытится, технология сменится - пора снова лезть в интернет и записываться на новый курс.
Опять же, есть исключения, к примеру, человек с уже имеющимся средним специальным или даже высшим образованием, возможно, смежник, хочет быстро получить объем целевых знаний, и курсы - как раз тот самый сконцентрированный объем. Но в любом случае, инженер - он и в Африке инженер. Недостаток целевых знаний, как правило, компенсируется базой плюс логикой плюс методами работы с информацией. Которая быстро позволяет освоить какие-то смежные области.
Lewigh
19.07.2025 06:37Правильная мысль, поданная отвратительным образом и с отвратительными примерами.
Я бы все таки разделил на программистов и разработчиков.Программист - это специалист, понимающий основы информатики и вычислительной техники, который четко осознает предпосылки и последствия каждого осуществляемого им решения.
Разработчик - это узкоспециализированный специалист, способный воспроизводить множество операций внутри своей области компетенции основываясь лишь на своем опыте.
definitelyRealPerson
19.07.2025 06:37Статья явно переоценивает важность глубокого изучения микроархитектур и низкоуровневых деталей. В реальности большинство разработчиков сталкиваются с проблемами на уровне архитектуры приложений и базы данных, а не с тонкостями кеш-памяти и RCU. Мой опыт показывает, что фундаментальное понимание алгоритмов важнее микросекундных оптимизаций.
ErshoffPeter
Представил я себе прикладную задачу - когда людям (бизнесу, бэку, производству, не важно) что-то срочно радо автоматизировать - снизить нагрузку на людей, удовлетворить регулярным требованиям, выйти на новый рынок, освоить новый станок - вы уверены, что заказчикам всё перечисленное вами будет реально нужно, например, для MVP?
Программист решает прикладную задачу - инженер решает проблему работающей системы.