Как на самом деле делают софт: карта курса для начинающего разработчика

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

Этот трек — про тот слой. Не про алгоритмы, не про фреймворки, не про «10 советов, как стать сеньором». Про то, откуда в трекере берутся задачи, почему ваш идеальный PR висит четыре дня, что происходит в три часа ночи, когда падает прод, кто и на каком основании решает, что вы стали мидлом, и как устроены деньги, которые вам платят.

Главное, чего не видно снаружи: код — меньшая часть работы

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

В полевом исследовании Xin Xia и коллег «Measuring Program Comprehension: A Large-Scale Field Study with Professionals» (IEEE TSE, 2018) активность профессиональных разработчиков логировали прямо в IDE. Порядка 58% времени уходило на понимание уже существующего кода — чтение, навигацию, поиск. Не на создание нового.

И это только измеряемая часть внутри редактора. За её пределами — обсуждение требований, ревью чужого кода, уточнение у аналитика, дежурство, разбор инцидента, планирование, найм, документация, переписка.

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

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

Хорошая попытка честно описать, из чего состоит продуктивность инженера, — фреймворк SPACE (Forsgren, Storey, Maddila, Zimmermann, Houck; ACM Queue, 2021). Он раскладывает продуктивность на пять измерений: удовлетворённость, производительность, активность, коммуникация, эффективность потока. Ключевой тезис авторов: любая одиночная метрика продуктивности разработчика вводит в заблуждение. Ни строки кода, ни закрытые тикеты, ни коммиты по отдельности не значат ничего.

Почему вообще существуют процессы

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

Ответ — в одной картинке.

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

Идея о том, что стоимость исправления дефекта растёт экспоненциально по фазам, восходит к Барри Боэму («Software Engineering Economics», 1981). Относитесь к ней как к качественной интуиции, а не как к закону природы: Laurent Bossavit в книге «The Leprechauns of Software Engineering» подробно разбирает, как эта и другие «общеизвестные» цифры индустрии пересказывались десятилетиями со ссылками на данные, которых в исходниках толком не было. Полезный навык на весь курс: проверять, откуда взялась цифра, которой вас убеждают — и в статьях, и в оценке задачи, и в обсуждении зарплаты.

Практическая суть от этого не меняется. Все процессы разработки — попытки решить один и тот же конфликт: узнать больше до того, как менять станет дорого. Разные подходы решают его по-разному:

• Водопад пытается узнать всё заранее, на бумаге. Работает там, где цена ошибки в проде катастрофична и требования правда стабильны (медтехника, авионика, часть госсектора).
• Итеративные подходы признают, что заранее всё узнать нельзя, и режут поставку на маленькие куски, чтобы получать обратную связь чаще.
• Continuous delivery доводит идею до предела: выкатывать так часто и так мелко, чтобы цена отдельного изменения почти не успевала вырасти.

Про эволюцию этих моделей есть отдельные материалы на портале: https://courses.digitable.life/post/management/development-models/ и https://courses.digitable.life/post/management/development-approaches-and-methodologies/. В нашем треке мы смотрим на то же самое глазами разработчика, а не менеджера.

Путь фичи: то, что происходит на самом деле

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

Обратите внимание на четыре вещи, которые отличают эту схему от учебной картинки:

1. Стрелок назад больше, чем вперёд. Это норма, а не признак плохой команды. Возврат из ревью и из тестирования — штатный режим.
2. Приёмка может вернуть вас в требования. Самое дорогое возвращение: код написан, но решает не ту задачу. Каждый такой случай — сигнал, что на этапе требований чего-то не спросили. Про это — https://courses.digitable.life/post/sdlc-and-career/02-requirements/.
3. После релиза работа не заканчивается. Мониторинг, инциденты, поддержка — часть цикла, а не «эксплуатация, это не ко мне».
4. Петля обратной связи от пользователей замыкается на самое начало. Именно она делает продукт продуктом, а не проектом, который сдали и забыли.

В стартапе половину этих шагов могут выполнять два человека за один день. В банке каждый переход может требовать формального согласования и занимать неделю. Оба варианта встречаются, оба бывают уместны, и мы разберём и то и другое — https://courses.digitable.life/post/sdlc-and-career/10-enterprise/ и https://courses.digitable.life/post/sdlc-and-career/11-startup/.

Жизненный цикл задачи в трекере

С процессом вы будете взаимодействовать через трекер (Jira, YouTrack, Linear, GitLab Issues — неважно). Карточка задачи путешествует по статусам, и эти статусы — не украшение: по ним считают метрики, планируют спринт и оценивают, кто чем занят.

Что тут важно понимать джуну:

• Статус Blocked — не позор, а инструмент. Самая частая ошибка новичка: молча сидеть три дня в задаче, где не хватает доступа или непонятны требования. Задача при этом формально «в работе», команда думает, что всё идёт, а на демо выясняется, что нет. Правило: если вы застряли больше чем на условные полдня — переводите в блок и говорите вслух.
• Возврат из Review и Testing — норма. Ненормально, когда его нет вообще: обычно это значит, что ревью формальное, а тестирования нет.
• Done определяется не вами. Что считается сделанным, задаёт Definition of Done — про него в https://courses.digitable.life/post/sdlc-and-career/04-development/. «У меня локально работает» никогда не входит в это определение.

У багов жизненный цикл похож, но с важным отличием — в нём есть развилка «а баг ли это» и приоритизация по severity:

Deferred и Rejected — самые политически заряженные статусы в индустрии. Решение «этот баг мы не чиним» принимается не потому, что всем всё равно, а потому, что ресурс конечен и его тратят на то, что важнее. Умение спокойно обосновать, почему баг критичен (сколько пользователей, сколько денег, какой риск), — навык уровня мидла. Про это — https://courses.digitable.life/post/sdlc-and-career/05-testing/ и https://courses.digitable.life/post/sdlc-and-career/07-support-and-techdebt/.

Кто с кем разговаривает

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

Реальность вносит поправки:

• Ролей может не быть. В маленькой команде продакт, аналитик и тестировщик — один человек, а иногда этот человек — вы. Не «роль отсутствует», а «функция выполняется кем-то другим или не выполняется вовсе, и последствия наступают».
• Стрелка «уточняющие вопросы» — самая недооценённая. Джуны боятся спрашивать, чтобы не выглядеть глупо, и делают по своим догадкам. Это самый дорогой способ ошибиться: цена вопроса — минуты, цена догадки — дни.
• Алерт может прилететь вам напрямую. Во многих компаниях действует принцип «вы написали — вы и дежурите». Это не наказание, а способ замкнуть петлю обратной связи: кто чувствует боль от плохого кода, тот пишет код лучше.

Подробный разбор ролей и зон ответственности — https://courses.digitable.life/post/sdlc-and-career/08-roles-and-teams/. Взгляд с другой стороны, со стороны тех, кто эти процессы строит, есть в треках https://courses.digitable.life/post/project-management/00-overview/ и https://courses.digitable.life/post/product-management/00-overview/ — мы на них будем ссылаться, но пересказывать не станем.

Ритм работы: спринт и релизный цикл

Работа в команде почти всегда имеет ритм. Чаще всего это двухнедельный спринт, но встречается и недельный, и поток без спринтов вообще (Kanban), и релизные поезда в больших компаниях.

Что в этой картинке обычно ломается на практике:

• Тестирование сдвигается вправо и сжимается. Разработка «немного» опаздывает, регресс режут, релиз всё равно в пятницу. Отсюда народная мудрость про «не деплой в пятницу» — она про то, что чинить придётся в выходные.
• Груминг пропускают, потому что «некогда», и в спринт попадают задачи с описанием в одну строку. Дальше — сюрпризы в середине спринта.
• Наблюдение после релиза не планируют вообще, и о том, что фича сломалась, узнают от пользователей через два дня.

Как считать «нормально ли мы релизим» — есть измеримый ответ. Исследовательская программа DORA (и книга «Accelerate» Forsgren, Humble, Kim) выделяет четыре метрики: частота деплоев, время от коммита до прода, доля неудачных изменений и время восстановления после сбоя. Главный контринтуитивный вывод многолетних отчётов: частые мелкие релизы коррелируют не с большим количеством инцидентов, а с меньшим. Разбор метрик есть в https://courses.digitable.life/post/project-management/07-dora-and-engineering-metrics/, а инженерная механика частых релизов — в треке https://courses.digitable.life/post/devops/04-cd-and-release-strategies/.

Второе измерение курса: контекст компании

Одни и те же слова — «спринт», «код-ревью», «релиз» — означают очень разное в зависимости от того, где вы работаете.

Ни одна колонка не «правильнее». Инженер из банка, который два года выстраивал отказоустойчивую интеграцию под нагрузкой и регуляторными требованиями, и инженер из стартапа, который в одиночку поднял продукт от идеи до первых платящих, — оба сильные, но сильные в разном. Проблемы начинаются, когда человек из одного контекста приходит в другой и пытается применить привычные рефлексы: в стартапе требует ТЗ и трёх согласований, в банке катит в прод в обход процедур.

Этому посвящён отдельный блок трека: https://courses.digitable.life/post/sdlc-and-career/09-project-types/, https://courses.digitable.life/post/sdlc-and-career/10-enterprise/, https://courses.digitable.life/post/sdlc-and-career/11-startup/.

Третье измерение: вы сами

Дальше — половина курса, посвящённая не софту, а вам. Грейды, рост, деньги, собеседования, первая работа, развилки карьеры.

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

Полезно посмотреть на публичные карьерные лестницы реальных компаний — это лучший способ понять, что за словом «грейд» стоит: коллекция progression.fyi и открытый карьерный фреймворк Dropbox. Разбор — в https://courses.digitable.life/post/sdlc-and-career/12-grades/ и https://courses.digitable.life/post/sdlc-and-career/13-growth/.

Про деньги — честно и без выдуманных цифр

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

Вместо цифр мы разбираем механику:

• из чего складывается вознаграждение: оклад, премии и бонусы, опционы и RSU, переработки и дежурства, ДМС и прочие льготы, компенсация обучения;
• что такое грейд и вилка внутри грейда, почему в вилке есть «низ», «медиана» и «верх», и почему новичка почти всегда берут ближе к низу;
• как устроен пересмотр: ежегодная индексация, performance review, повышение грейда, контроффер — и чем эти механизмы отличаются по скорости и предсказуемости;
• почему смена работы исторически даёт больший прирост, чем внутренний пересмотр, и какова цена этой стратегии (потеря контекста, риск неудачного онбординга, обнуление доверия).

Как самому исследовать рынок — по открытым источникам, а не по слухам в чате:

• Хабр Карьера — калькулятор зарплат и полугодовые отчёты по грейдам, специализациям и городам;
• getmatch — статистика по реальным офферам на площадке;
• levels.fyi — глобальные данные с разбивкой на оклад, бонус и акции; полезен прежде всего пониманием структуры пакета в международных компаниях;
• Stack Overflow Developer Survey — международный срез с разбивкой по технологиям и опыту;
• ежегодные обзоры рынка труда от рекрутинговых агентств и HR-исследователей (например, обзоры Antal, Ancor, «Экопси», отчёты Хабр Карьеры) — их ценность не в конкретной цифре, а в динамике год к году;
• вакансии с открытыми вилками — самый актуальный источник, но с оговоркой: в объявлении обычно указывают верх диапазона.

Методика простая и повторяемая: собрать 3–5 источников по вашей связке «грейд + стек + город/удалёнка + тип компании», отбросить выбросы, посмотреть на медиану и на ширину разброса, и отдельно оценить, где в этом диапазоне вы находитесь по объективным признакам (реальный опыт, домен, редкость стека). Условно: если по вашей выборке медиана — величина M, а разброс между 25-м и 75-м процентилем составляет примерно ±20% от M, то запрос «медиана плюс 10–15%» при сильном профиле — обоснованная позиция, а «медиана ×2» — требует объяснения, которого у джуна обычно нет. Числа здесь — иллюстрация метода расчёта, не рекомендация: рынок меняется, и проверять надо каждый раз заново.

Детально — https://courses.digitable.life/post/sdlc-and-career/14-compensation/ и https://courses.digitable.life/post/sdlc-and-career/15-negotiation/.

Про собеседования — с обеих сторон стола

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

Стоит сразу знать, что типичное собеседование — плохой измерительный прибор. Основные способы испортить его со стороны интервьюера:

• Неструктурированное интервью «поговорим за жизнь». Разным кандидатам задают разные вопросы, сравнить их между собой невозможно, решение принимается по ощущению. Google в своих материалах re:Work прямо продвигает структурированное интервью — одинаковые вопросы и заранее заданная шкала оценки — именно потому, что оно даёт сопоставимые результаты.
• Эффект зеркала: «он думает как я, значит хороший». Так команда постепенно становится клоном одного человека и теряет способность видеть свои слепые зоны.
• Оценка по нерелевантному сигналу: нервничает — значит слабый; бойко говорит — значит сильный. Умение проходить собеседования и умение работать — разные умения, и корреляция между ними слабее, чем кажется.
• Загадки и «алгоритмы ради алгоритмов» там, где работа состоит из интеграций и легаси. Проверять надо то, чем человек будет заниматься.
• Отсутствие обратной связи после отказа. Дёшево для компании, дорого для репутации и бесполезно для кандидата.

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

Разбор — https://courses.digitable.life/post/sdlc-and-career/16-interview-candidate/ и https://courses.digitable.life/post/sdlc-and-career/17-interview-interviewer/.

Карта трека

Полный список статей трека с тем, зачем каждая нужна:

Блок 1. Процесс: как задача превращается в работающий код

• https://courses.digitable.life/post/sdlc-and-career/01-what-is-sdlc/ — что такое SDLC, какие бывают модели жизненного цикла, почему «Agile против Waterfall» — плохо поставленный вопрос.
• https://courses.digitable.life/post/sdlc-and-career/02-requirements/ — откуда берутся задачи, что такое хорошее описание тикета, критерии приёмки, и почему «сделай как на макете» — не требование.
• https://courses.digitable.life/post/sdlc-and-career/03-design/ — зачем думать до кода, что такое design doc и ADR, когда проектирование превращается в вредный оверинжиниринг.
• https://courses.digitable.life/post/sdlc-and-career/04-development/ — ветвление, pull requests, код-ревью как социальный процесс, стандарты кода, Definition of Done.
• https://courses.digitable.life/post/sdlc-and-career/05-testing/ — что разработчик обязан протестировать сам, чем занимается QA, что такое регресс и почему «у меня работает» ничего не значит.
• https://courses.digitable.life/post/sdlc-and-career/06-release-and-operations/ — деплой, окружения, фича-флаги, мониторинг, алерты, дежурства, инциденты и постмортемы.
• https://courses.digitable.life/post/sdlc-and-career/07-support-and-techdebt/ — что происходит с системой после релиза, откуда берётся технический долг и как его обосновывать бизнесу.

Блок 2. Контекст: где именно вы это делаете

• https://courses.digitable.life/post/sdlc-and-career/08-roles-and-teams/ — кто есть кто, кто что решает, к кому идти с каким вопросом.
• https://courses.digitable.life/post/sdlc-and-career/09-project-types/ — продукт, аутсорс, аутстафф, внутренняя разработка, госсектор: как это влияет на вашу работу и рост.
• https://courses.digitable.life/post/sdlc-and-career/10-enterprise/ — как устроена разработка в больших компаниях: согласования, масштаб, надёжность, плюсы и минусы честно.
• https://courses.digitable.life/post/sdlc-and-career/11-startup/ — скорость, хаос, риск, опционы, отсутствие процессов как фича и как баг.

Блок 3. Рост: что происходит с вами

• https://courses.digitable.life/post/sdlc-and-career/12-grades/ — что реально отличает джуна от мидла и мидла от сеньора; почему это не про количество лет.
• https://courses.digitable.life/post/sdlc-and-career/13-growth/ — план развития, обратная связь, performance review, менторство, как просить о росте.
• https://courses.digitable.life/post/sdlc-and-career/18-first-90-days/ — первая работа: онбординг, ожидания, типичные ошибки первых месяцев.
• https://courses.digitable.life/post/sdlc-and-career/19-career-tracks/ — эксперт, менеджер, архитектор, фриланс, свой продукт: чем эти пути отличаются по содержанию работы.

Блок 4. Деньги и найм

• https://courses.digitable.life/post/sdlc-and-career/14-compensation/ — как устроено вознаграждение и как исследовать рынок самому.
• https://courses.digitable.life/post/sdlc-and-career/15-negotiation/ — переговоры об оффере: подготовка, что обсуждаемо кроме оклада, типичные ошибки.
• https://courses.digitable.life/post/sdlc-and-career/16-interview-candidate/ — этапы, подготовка, поведение, какие вопросы задавать работодателю.
• https://courses.digitable.life/post/sdlc-and-career/17-interview-interviewer/ — как проводить собеседования: структура, шкалы оценки, предвзятость, обратная связь.

Как читать этот курс

Курс написан линейно, но реальные сценарии разные:

• Вы учитесь и ещё не работали. Читайте подряд с https://courses.digitable.life/post/sdlc-and-career/01-what-is-sdlc/. Особое внимание — блоку про роли (https://courses.digitable.life/post/sdlc-and-career/08-roles-and-teams/) и первым 90 дням (https://courses.digitable.life/post/sdlc-and-career/18-first-90-days/): это то, чего не даёт ни один курс по программированию.
• Вы ищете первую работу. Начните с блока найма: https://courses.digitable.life/post/sdlc-and-career/16-interview-candidate/, потом https://courses.digitable.life/post/sdlc-and-career/14-compensation/ и https://courses.digitable.life/post/sdlc-and-career/15-negotiation/. Но прочитайте и https://courses.digitable.life/post/sdlc-and-career/09-project-types/ — выбор типа компании для первой работы влияет на следующие три года сильнее, чем разница в оффере.
• Вы уже работаете джуном и хотите понять правила игры. Идите в https://courses.digitable.life/post/sdlc-and-career/04-development/, https://courses.digitable.life/post/sdlc-and-career/06-release-and-operations/ и https://courses.digitable.life/post/sdlc-and-career/12-grades/.
• Вас позвали собеседовать кандидатов. Прямо в https://courses.digitable.life/post/sdlc-and-career/17-interview-interviewer/.

Смежные треки портала, которые дополняют этот:

• https://courses.digitable.life/post/intro/14-it-industry/ — если вы совсем в начале и хотите понять устройство индустрии в целом.
• https://courses.digitable.life/post/project-management/00-overview/ — как устроено управление проектами со стороны того, кто им управляет.
• https://courses.digitable.life/post/product-management/00-overview/ — как принимаются продуктовые решения, откуда берётся приоритизация.
• https://courses.digitable.life/post/devops/00-overview/ — инженерная механика того, что мы здесь описываем словами «CI», «деплой», «мониторинг».
• https://courses.digitable.life/post/time-management/00-overview/ — как выживать в дне, разорванном встречами и прерываниями.

Типичные ошибки, из-за которых первый год проходит хуже, чем мог бы

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

1. Молчать, когда застрял. Цена: дни вместо минут, плюс подорванное доверие, потому что со стороны это выглядит как «человек ничего не делал неделю».
2. Считать, что задача = написать код. Не прочитать критерии приёмки, не проверить крайние случаи, не подумать про миграцию данных — и получить возврат из тестирования.
3. Спорить на ревью про вкусовщину и не спорить про важное. Комментарий про пробелы решается линтером. Комментарий «здесь потеряется транзакция» решается обсуждением.
4. Обещать сроки, чтобы понравиться. «Да, завтра сделаю» без анализа — самый быстрый способ потерять репутацию. Оценка — навык, ему учатся; см. https://courses.digitable.life/post/project-management/03-estimation-and-planning/.
5. Игнорировать прод. Не смотреть на логи и метрики после релиза своей фичи. Про то, как это делают инженеры, — https://courses.digitable.life/post/devops/16-observability-and-oncall/.
6. Путать «мне скучно» и «я вырос». Ощущение скуки часто означает, что вы освоили один слой и не заглянули в следующий: нагрузку, надёжность, домен, влияние на команду.
7. Обсуждать зарплату без подготовки. Прийти на переговоры без исследования рынка и без понимания структуры пакета — гарантированно оставить деньги на столе или запросить нереалистичное.
8. Верить в единственно правильный процесс. Скрам не спасёт команду без доверия, а отсутствие процессов не сделает вас быстрым, если продукт не понимает, что строит.

Мини-итог

• Работа разработчика на большую часть состоит не из написания нового кода, а из понимания существующего, согласования и коммуникации.
• Все процессы разработки решают одну задачу: узнать про требования и риски раньше, чем изменение станет дорогим.
• Реальный путь фичи полон возвратов назад — из ревью, из тестирования, из приёмки. Это норма; отсутствие возвратов — подозрительно.
• Одни и те же практики выглядят по-разному в энтерпрайзе, стартапе и аутсорсе. Правильного варианта нет — есть уместный для контекста.
• Карьера — не лестница с фиксированными ступенями: грейды не стандартизированы, а переходы между инженерным и менеджерским треком обратимы.
• Про деньги: цифры устаревают, механика — нет. Учитесь исследовать рынок самостоятельно по нескольким открытым источникам и понимать структуру вознаграждения целиком.
• Собеседование — плохой измерительный прибор с обеих сторон. Понимание его слабых мест помогает и проходить, и проводить.

Что дальше

Начнём с фундамента — разберём, что такое жизненный цикл разработки, какие бывают модели, чем они реально отличаются на практике и почему спор «Agile против Waterfall» обычно ведут люди, не работавшие ни в том, ни в другом:

Что такое SDLC: из чего состоит путь от идеи до работающего продукта

Что почитать помимо курса

• Frederick Brooks. «The Mythical Man-Month» — про то, почему добавление людей в опаздывающий проект делает его ещё более опаздывающим. Написано в 1975 году и до сих пор актуально.
• Tom DeMarco, Timothy Lister. «Peopleware» — про то, что главные проблемы разработки не технологические, а социологические.
• Nicole Forsgren, Jez Humble, Gene Kim. «Accelerate» и отчёты DORA — что действительно коррелирует с результативностью инженерных команд.
• Camille Fournier. «The Manager’s Path» — полезна не только менеджерам: даёт язык для разговора о грейдах и ожиданиях.
• Gergely Orosz, The Pragmatic Engineer — регулярные разборы того, как реально устроена работа и найм в технологических компаниях.
• Google SRE Book — свободно доступная книга о том, как эксплуатируют системы, из которой стоит прочитать хотя бы главы про алерты и постмортемы.
• Martin Fowler, martinfowler.com — в частности Continuous Integration и Technical Debt Quadrant.