Михаил

Нужен огромный и продолжительный труд, чтобы написать приличную книжку.
Чтобы в ней было не 10 страниц, а много хорошего материала, с примерами, с задачами, с изложением. Оформить, вычитать, отредактировать, договориться с издателем, выпустить, получить какую-то отдачу.
Хорошую книгу ты читаешь долго. Месяц, два, год. Перечитываешь.

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

В любой момент можно в тексте что-то найти, что-то подсмотреть в быстром темпе, и даже в бумажном варианте для этого достаточно просто содержания. А в электронном виде оттуда легко копируется текст, команды, код, конфиги.
Перемотка в видео так не работает. Закладки на видео в виде справочника не работают. Сам себе заметки в виде видео ты не пишешь, не выписываешь, и переписать из книги проще, чем из видео.

Также видео делать сложнее, чем писать текст. Гораздо дольше. Гораздо дороже.
Редактирование видео вещь в разы более муторная, поэтому чаще просто переснимают короткие блоки, а это опять таки непросто.
То есть сделать видео с таким же качеством материала и с такой же плотностью материала - в десятки раз дороже по всем ресурсам - деньги, время, оборудование.
И при этом никто не будет смотреть месяц видео (160 часов, например). Никто не будет делать поиск внутри видео, закладки на нужные отрывки и использовать видео как справочник.

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

Видео - это разок посмотреть на чей-то практический материал, разок посмотреть как это делает кто-то другой.

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

Да, конечно есть отдельные моменты, и их много, когда через изображение можно передать мысль или идею быстрее. Но частично это восполняется картинками, а частично - никто не запрещает смотреть видео в дополнение к тексту.
Да, конечно есть множество видео и видеокурсов, где можно раскрыть какую-то тему быстро, чтобы ухватить основную мысль или суть. Но в программировании нюансы решают все, а нюансы - они в тексте - в документации, в статьях, в книгах и в практике.

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

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

P.S. Одним из самых важных минусов видео я считаю то, что ты не можешь получать информацию в комфортном для себя темпе, с возможностью быстро перечитать слово/фразу и обдумать ее. Сам читаю множество лекций, и эта проблема, когда скажешь 2-3 предложения быстрее, чем обычно и половина учеников отваливается с бессмысленным взгядом. Так на живом курсе ты можешь обратить на это внимание и перефразировать, а записанное видео уже не изменишь.

3. Фронтед разработчики - сколько должно быть их в проекте?
4. Бэкенд разработчики - сколько должно быть их в проекте?
5. UI/UX дизайнеры - сколько должно быть их в проекте?
6. QA инженеры(тестировщики) - сколько должно быть их в проекте?
7. Бизнес-аналитик - сколько должно быть их в проекте?
8. Маркетолог - сколько должно быть их в проекте?

Столько, сколько нужно. Тоесть если 1 человек не справляется с количеством задач, и при этом их можно распараллелить - можно попробовать добавить ещё одного и посмотреть.
От 0 до бесконечности, в зависимости от задач.

Например если продукт не предполагается продавать (в принципе получать из него прибыль) - маркетолог не нужен.
БА не нужен, если ПМ и так нормально задачи ставит, и какой-то глубокой аналитики не нужно (или с ней справляются разработчики)
QA не нужен, если проект на столько небольшой, что с его тестированием справляются разработчики.
UI/UX не нужны, если нет дизайна.
Разделение на фронт/бэк не нужно, если справляется фуллстек.
Тимлид не нужен, если нет команды (команда состоит из одного человека)

Кого я мог не учесть?

Заведующего по карандашным резинкам. Без него никакой проект не может обойтись.

Ну вот вам такой пример

create table p (id serial primary key, val text);

create table c (id serial primary key, p_id int not null references p(id) on delete no action deferrable, val text);

insert into p (val) values ('a'), ('b');

insert into c (p_id, val) values (1, 'a1'), (1, 'a2'), (1, 'a3'), (2, 'b1');

begin;
set constraints all deferred;
delete from p where id = 2;
delete from c where p_id = 2;
commit;

Почитайте также про отложенные ограничения

Если вы шарите в архитектуре, то писать большие проекты вам будет в кайф

Декомпозиция

Git хочет показать вам более одного экрана с информацией, для этого он вызывает стандартную программу пейджера Unix less. Просто введите q, чтобы вернуться в терминал, когда вы больше не хотите перемещаться по выходным данным.

j перейти на одну строку вниз
k переместиться на одну строку вверх
space перейти на одну страницу вниз
b перейти на одну страницу вверх
h показать помощь
/ поиск вперёд
? поиск назад

Если вы не хотите less, просто замените его другим пейджером в конфигурации. Если вам вообще не нужен пейджер, просто используйте cat:

git config --global --add core.pager cat

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

Все сценарии приблизительные, потому что каждая проблема требует комплексоного подхода и знания возможностей инструмента, поэтому не поленись, а почитай вот это внимательно и полностью
https://git-scm.com/book/en/v2

Блок в размер картинки, у которого два фона - картинка и градиент https://developer.mozilla.org/en-US/docs/Web/CSS/C...
ну или псевдоблок :after над картинкой с абсолютным позиционированием и фоном с градиентом.