Книга: Getting Started with SQL

lrg (1)
Thomas Nield.
Getting Started with SQL: A Hands-On Approach for Beginners.
O’Reilly, 2016.
Есть особая категория книг — помогающие переступить порог входа. Обычно в них нет откровений, нет сакральности, просто текст, который написан так доступно и так деликатно к измождённому учёбой мозгу, что после прочтения уже не страшно, можно идти дальше.
Вот эта такая. Всего 100+ страниц, базой SQLite, рассматривается самый ходовой набор SQL. Совсем немножко захвачена тема дизайна схемы базы данных, но тем, кто вообще никогда, и так норм.
Книга годная, советую тем, кто впервые сталкивается с SQL и хочет оперативно подхватить основы.

Инфраструктура стартапа

// По другому поводу написал конспект современной инфраструктуры, но получилось достаточно цельно, потому и за эссе сойдёт.
Развитие инфраструктуры идёт в сторону «делать больше, платить меньше». В общем, как и везде на рынке технологий. Небольшие компании не могут позволить себе сотни тысяч долларов ежемесячно, да и большие давно стараются ужаться в подобных расходах (один лишь GitHub на 1K пользователей в год начинается от 15М рублей), потому прогресс идёт вполне ожидаемым путём.
Под инфраструктурой далее подразумеваю всё, что обеспечивает процесс разработки и эксплуатации продукта, а не части самого продукта. Потому, например, Nginx в тренде, но это не инфраструктура.
Упомянутые названия считаю современным [хайповым] трендом. Иначе говоря, если собрать в небольшую толпу десятка два 20..30-летних разработчиков, из толпы будет доноситься то, что опишу ниже. Безусловно, существуют организации, живущие на другом софте, но речь не про них.
Каталог ниже также можно рассматривать, как первый набросок для первых обсуждений в начинающем стартапе. О, у нас есть N копеек и два человека, что мы можем из этого соорудить, чтобы продержаться десять лет до первого миллиона копеек? Если с этой позиции смотреть, так нынешний софт в какой-то мере представляет собою конструктор Лего. Кубики умеют работать друг с другом, редко являются обязательными, конструкцию по мере нужды можно наращивать и даже местами заменять с адекватной миграцией данных, ежели руки прямые. Я как-то прикидывал, нынче при действительно прямых руках можно чуть ли не всю инфраструктуру размазать за $150 в месяц. Не на сто человек, да, но мелкий коллектив вполне. Хорошие времена.

Нулевой круг: хостинг особо упомяну.
В тренде аутсорсинг и облачность. Соответственно, массово выбирают тех, кто на нормальном уровне за нормальные деньги предоставляет все те услуги, которые предоставлялись бы собственной серверной с отрядом админов, железячников, ноков и завхозов. Влёт можно назвать [в порядке убывания универсальности] Amazon AWS, Microsoft Azure, Google Cloud Platform. Это очень разные платформы со своей спецификой каждая, потому равными назвать не могу. Просто разные. Если нужно «в два клика» что-нибудь захостить, есть DigitalOcean. Сервисов на порядок (если не два) меньше, чем у того же AWS, но с задачей справляется.

Первый круг: VCS и Issue tracker.
VCS. Исходный код и прочее надо где-то хранить и обеспечить общину возможностью совместной работы с ним. Совместная работа нынче подразумевает активную вовлечённость, социальность, частично геймификацию, интеграцию со всем на свете. В тренде GitHub, GitLab, Bitbucket. Все три решения сделаны поверх git.
Issue tracker. Весело, молодо и задорно жить без тикетов или обходиться цветными бумажками на доске, но рано или поздно, а команда из этих штанишек вырастает. Задачи надо где-то описывать, обсуждать, отслеживать статус, строить графы зависимостей, получать срезы состояния и прочее. Тут устроить зоопарк проще, т.к. каждый год кто-нибудь пытается повторить успех JIRA (ведущий ледокол рынка трекеров, с каждым релизом бьющий рекорды неудобства). В спину ей дышат Bugzilla (для совсем олдскульных), YouTrack. С ощутимой натяжкой можно упомянуть Trello, но они всё-таки про другое. Но если далеко от системы карточек на доске уходить не хочется, то и Trello сойдёт.

Второй круг: общение, мониторинг и логи.
Общение. Команды часто распределённые (особенно если вы стартап и вам дешевле нанять двух senior’ов из Мордовии, чем одного московского middle), потому тема «где нам обсуждать работу?» поднимется быстро. Важной характеристикой решения является возможность видео на команду. Тут тоже бардак, т.к. долго не было единого продукта, решающего все задачи разработки (закрытые групповые каналы, архив, конференции, plugin’абильность, модные боты и т.п.). Потому у вас сейчас два варианта: устраивать конструктор из Skype / Jabber (ссылка на протокол) / Telegram или использовать Slack. Особняком варианты для knowledge base — что-то для хранения коллективных знаний. Тут у каждого своё, хоть одну из сотни Wiki поднимай, хоть один из вариантов по подписке, хоть закрытый репозиторий на GitHub. «Моделей» слишком много на любой вкус.
Мониторинг. В какой-то важный для команды момент количество тихо упавших сервисов начнёт действовать на нервы, после чего срочно вспоминают о нужде мониторинга живости машин и софта на них. Тут тоже не особо много боевых альтернатив. Частые метрики снимаются либо в Prometheus, либо в Influx. Событийный мониторинг есть смысл делать через всё тот же Zabbix. Приятные глазу графики как смотрели, так и будем смотреть в Grafana. А всякие стектрейсы и прочие ошибки можно отправлять в Sentry.
Логи. Весь софт пишет мегагигабайты логов, об которые ушатаешься ходить на каждую машину и грепать файл за файлом. Потому человечество придумало ELK stack (Elasticsearch, Logstash, Kibana). Держать в инфраструктуре эту триаду — та ещё головная боль, но иметь возможность удобно оперировать логами с кластеров… бесценно.

Последний круг: Continuous integration, Continuous delivery и остальное.
Темпы современной жизни диктуют темпы и разработке. Продукты надо делать быстро. Скорость часто бьёт по качеству, потому элементы CI/CD включают в себя также и максимальное исключение человеческого фактора — автоматизация проверок кода, автоматизация сборок, выкаток. В этой области раздолье и зоопарк полный. На деле же основной проблемой будет совсем не софт, но внедрение разработчикам в головы нужды в CI. Например, там тесты писать надо, а это же таааак скуууучно.
В этом же разделе решения, которые могут примениться раньше, могут позже, могут прямо-явно не относиться к CI/CD, но здорово его облегчают. В общем, список того, чем занимаются, когда хотят сделать всё правильно и есть возможность.
Контейнеры. Удобнее куда-нибудь доставить и где-нибудь поднять уже готовое приложение со всеми конфигами, файликами и прочим. Как минимум, это быстрее. На сцену выходит Docker, царь контейнерного хайпа. Лишь избранные знают и думают о других решениях. На самом деле вполне стоит и подумать, т.к. Docker не панацея и для ряда задач имеет смысл прикинуть альтернативы.
Оркестровка. Нравится это слово в контексте «хорошо, давайте управлять всеми этими контейнерами на этих инстансах в этих облаках». Тут поле боя, на котором рубятся Swarm с Kubernetes. Правда, тут снова тема Docker, но чё уж, мода. Сюда же Nomad для спартанцев.
Сборка и тесты. Так лаконично свёл CI в две задачи. На деле, конечно, решается гораздо больший спектр. Навскидку тут можно назвать три продукта: Jenkins, TeamCity, Travis CI (ваш выбор, если open source). Каждый со своими чудесами, своими лицензиями и ценами. Но вряд ли вы обойдётесь без них при внедрении CI в инфраструктуру. Писать скрипты запуска и сборки по крону занятно, спору нет, но лучше не надо.

Уверен, я не назвал десятки решений, которые вы считаете очень важными или лучшими или ещё какими-нибудь. Это нормально. Их назовёт кто-нибудь другой. Часть из них я просто не знаю. Часть не подходит небольшим командам (у вас целый департамент админов, это круто). Часть… кхм (знаю бойцов, живущих в IRC, им норм). Наконец, 35 ссылок в одном эссе — пока рекорд тут, ставлю запятую.

Оэрмаина не Баззия

То, с чего началось: «Не надо писать в резюме опыт работы с базой XYZ, если весь ваш опыт заключается в CRUD через ORM. Приводит к неловкости на собеседовании».
Если прищурить глаз, что такое ORM? Слой абстракции, который позволяет вам работать с объектами вашей предметной области, не задумываясь особо о том, как они хранятся, как выбираются и т.д. Собственно, потому ORM’ы и появились — разработчики тратили мегатонну ресурса на то, чтобы даже простой CRUD сделать — схему напиши, модель напиши, методы напиши, result set в объект разбери, объект в тот же INSERT расчлени… И так на каждую писюльку. Пальцы устают.
Заодно сбоку появились механизмы миграции, больше декларативщины и т.д. Откройте мануалы к Hibernate или Django, там всё есть.
Вроде бы круто, не? Круто. Только теперь разработчик умеет работать с ORM, не умея работать с базой данных. Иначе говоря, ORM’ы и сделаны для того, чтобы тебе не надо было уметь, а ты человек, потому не умеешь и не хочешь уметь то, что не применяешь прям каждый день.

Первый пример. Фигня в том, что ORM бывают не оптимальны. И баги там бывают. И вообще всякое бывает. Написали вы код, красивый, умный. Выкатили на тестинг. Работает. Выкатили на прод. Работает. Проходит неделя. Работает на 5% медленнее. Проходит месяц. Бывают провалы на 20% деградации. Почему?
Включается дебаг запросов. Вытаскивается результат ORM-генерации. По нему смотрится план выполнения. Находятся проблемные участки. Осмысляется причина проблемности. Устраняется.

Другой пример. На фронте страничка. На страничке график за пять лет. По сути надо вывести результат серии агрегированных запросов по двадцати таблицам и 20M строк, размазанных по этим таблицам. Задача за рамками CRUD, очевидно. Тем более, отработать должно не дольше 500ms. Надо заметить, что в современных ORM часть подобных задач вполне решаема, но только часть. В ряде случаев вы получите прямолинейный JOIN на всё поле данных, от чего база будет кряхтеть, а пользователь минуту смотреть на спиннер. Ваши действия?
Написать в итоге правильный оптимальный запрос на SQL, после чего либо перенести его в ORM с сохранением характеристик, либо из ORM сырым и дёргать, бывает. Некоторую часть таких запросов оптимальными можно сделать только со знанием конкретной базы данных.

Третий пример. Вы наплодили тысячу классов в модели. ORM пожал плечами и создал тысячу таблиц. Он ведь инструмент, а не заменяющая мозг штука. Молоток не отпихивает неправильный гвоздь, лупит куда сказали. Бац, всё просело. Ну вот просто адово медленно работает. И?
Схему базы данных тоже надо проектировать. И делать это с учётом множества факторов. Просто набросать кучу классов и надеяться, что прокатит, получается не всегда. И снова ORM тут не помощник, скорее, добавляет дополнительные факторы для учёта.

Фактически каждая задача в области хранения данных в базах сводится к набору из трёх переменных: { фреймворк, язык[и] запросов, база данных }. Например, { Hibernate, SQL, PostgreSQL }. Или { Spring Data, MongoDB QL / JavaScript, MongoDB }. Если значение (требуемый уровень знаний) переменной превышает ваш уровень, задачу в оптимальный с внешней точки оценки срок вы сделать не можете.
Отмечу: не оцениваю эту тему с позиции хорошо / плохо знать / не знать. Каждый сам задаёт себе границы полезности. Проблема в другом.
Предположим, у вас в резюме в опыте работы указаны «Московский метрополитен» и «вагоны Еж-3 и Еж-6 последние два года». Что думать читающему резюме? Какой опыт от вас ожидать и какие вопросы для проверки задавать? Вот, что я подумаю (простите дурака с уникальным ходом мысли): о, этот боец разбирается в вагонах! Ура.
Приходит боец. Многолетний опыт спуска по эскалатору, знает названия станций, знает особенности первых и последних вагонов некоторых линий. Начинаю разминку о вагонах. За 15..30 минут собеседования выясняется, что опыт заключается в том, что вагоны этих моделей перемещали человека от A до B. Человек заходит. Некоторое время ждёт. Выходит. Всё.
Так. Хорошо. Зачем в резюме указал? Формально говоря, опыт есть без сомнения. Только это опосредованный опыт, да ещё такого объёма, что совершенно бесполезен в употреблении другими людьми. Ровно так же звучат рядом стоящие Hibernate и MySQL, если MySQL для вас тот же вагон метро из аналогии выше. Почему бы тогда не указать в опыте, скажем, ПНО 63-12-8? Рязанский завод ЖБИ №2 выпускает плиты перекрытия, по которым вы ходите в домах. На плитах слой бетона, слой заливки, гидроизоляция, паркет. Кое-где штробили проводку. Всё это не вы, впрочем. Весь ваш «опыт» — вы по ним ходите. Эдак десятки страниц резюме можно забить.
Почему-то знание лишь одной трети от набора заменяет в голове знание всей триады. О, если я знаю ORM, я знаю SQL и базы данных. Да нет, конечно же.

Хочу ещё пройтись по мнению «это специальные знания, требования к которым надо особо указывать в вакансии». Возможно. Правда, я пока не готов с этим согласиться. Бекендер — разработчик, часто имеющий дело с базами данных. Вы можете смотреть на мир через любую любимую призму, но вот я открыл HeadHunter, вбил [Java backend] и нажал Enter. Читаем (попутно умиляясь подмесу совсем не Java) первые десять вакансий (цитирую прям копипастой подряд из каждой):

  • Опыт работы с базами данных: SQL, MySQL, JDBC, Oracle и т.д.
  • Понимание SQL, NoSQL, реляционных, объектных БД, blob и других решений для хранения данных.
  • Понимать, во что выливаются операции с ActiveRecord, оценивать эффективность получающегося SQL.
  • Знание принципов работы баз данных и опыт работы с MySQL/PostgreSQL, умение писать сложные SQL запросы.
  • реляционные СУБД, понимание принципов проектирования БД, отличное знание SQL
  • опыт использования NoSQL баз данных (Cassandra, Hazelcast).
  • Уверенное знание SQL (Транзакции, оптимизация запросов, планировщик запросов и т.д.) .. Знание PostgreSQL(9.x), .. Hibernate.
  • Опыт работы с базами данным .. SQL, .. MongoDB, Spring Data Reactive.
  • Опыт работы с БД SQL .. с MS SQL
  • Разработка с использованием одной из следующих БД: PostgreSQL, MySQL, AWS DynamoDB, Amazon Aurora; Опыт оптимизации БД и запросов к БД (SQL или NoSQL).

Скажите, вот по вашему ощущению объективной реальности… слова «знание», «опыт», «использование» и «понимание» означают «я работал с базой только через ORM»? Есть ли у вас ощущение, что от бекендеров ожидается незнание SQL и баз данных? Как всё-таки будет понимать ваше резюме читатель, если это резюме бекендера и в нём упоминается «опыт с MySQL»?

Пролистал следующие десять вакансий подряд. Картина точно такая же. Более того, вакансия «Специалист по тестированию» включает в себя «знание SQL» даже не в дополнительных требованиях. Переведу: индустрия не ожидает от бекендера раздельного знания одной из трёх переменных выше. Если ты позиционируешь себя бекендером, ты должен знать фреймворк (да хоть JDBC) AND язык (SQL) AND базу данных (XxxSQL). Не OR из мечт о лёгкой работе. Именно AND.
Вернусь к началу и доведу до абсурда. 2018 год. Россия. Вакансия, состоящая лишь из слов «Java, middle+, backend». Резюме, состоящее лишь из слов «Java, backend, MySQL». Скажите (таки полистав HeadHunter), сколько всё-таки человек из нанимающих будут трактовать это как приглашение не знать базы данных и не знать SQL? Сколько всё-таки человек из нанимающихся на позицию middle+ будут под словом «MySQL» подразумевать незнание SQL и MySQL? Да, не ноль. Иначе бы не было этого эссе. Но и даже не один из десяти, что радует.
Завершу цитатой Мартина Фаулера:

I’ve often felt that much of the frustration with ORMs is about inflated expectations. Many people treat the relational database «like a crazy aunt who’s shut up in an attic and whom nobody wants to talk about». In this world-view they just want to deal with in-memory data-structures and let the ORM deal with the database. This way of thinking can work for small applications and loads, but it soon falls apart once the going gets tough. Essentially the ORM can handle about 80-90% of the mapping problems, but that last chunk always needs careful work by somebody who really understands how a relational database works.

Вот между ORMonlybody и этим somebody есть разница. Постарайтесь её понять.

Опыт в годах

Не всегда получается звуками из рта объяснить, почему при рассмотрении разработчика пишут требуемый опыт в годах и нафига вообще это измерять годами, ведь я, Вася Пупкин, в свои N лет знаю десять языков, на доске решаю любую задачу за пять минут и вообще дерзкий пацан.

Сначала вводная и рамочная.
Вас нанимают для того, чтобы сделать продукт. Затасканное слово, но таки да. Продукт — что-то, чем люди могут пользоваться, желательно, без боли. Продукты бывают разного уровня: для себя, внутренние, массовый рынок, под заказ по ТЗ, гиперответственные (военка, космос, медицина, транспорт, энергетика).
У продукта разные стадии. Задумка, прототипирование, [мучительная] разработка, доводка, релиз, эксплуатация, поддержка, развитие[, закрытие]. Сроки у этих этапов… Ну, зависит от, конечно. Но субъективно с потолка средний продукт до релиза делается год-два, доводится год, живёт до переписывания два-пять лет. Но это с потолка. Важно понять: продукты делаются до состояния продукта долго. Можно за выходные нахакатонить меленькое мобильное приложеньице или каркас какой-нибудь библиотечки с братвой, но это будет творение хакатона, а не «этим софтом мы отгрызём 1% планеты у Google».
Чтобы из кода сделать продукт, часто надо сделать интересные 10% работы и неинтересные 90%. Например, однажды боец месяц писал тесты. Каждый рабочий день мерно покрывал модуль. Если мне не изменяет, там за тысячу тестов перевалило, к ним ещё и отдельно документация была написана прикольными табличками входа-выхода. Или вот у вас база, в ней 100+ таблиц, надо написать обвязку для CRUD. Интересно? Нет. Но надо. На такую работу могут уйти месяцы жизни. Приходите в офис. Садитесь. 8 часов пишете код, который почти такой же писали вчера, неделю назад и будете писать следующую неделю. Восхитительно.
Таким макаром кто наиболее интересен работодателю? Ну, помимо прорывных гениев, внезапными озарениями двигающих за пару дней человечество вперёд. Интересны, очевидно, разработчики, которые могут начать продукт, сделать его и продолжить. Иными словами, те, у кого набита достаточно чугуниевая жопа, чтобы год-два-три сидеть на ней ровно, доводя начатое до конца.
Искусство аналогий: вы собираете караван из Москвы до Владивостока. Ехать долго, муторно, машины разные (автобусы, грузовики, седанчики, даже два велосипедиста). Нужны водители. Которых в Москве за руль усадишь, через год во Владивостоке от руля отковыряешь. Я вам расскажу, чего вы на этом маршруте не хотите.

Во-первых, «чёт я устал, у меня апатия». Машина Васи едет медленнее, Вася всё унылее. Проехали треть маршрута, минус боец. Вася так далеко от столицы не забирался, предела своих возможностей не знал. Фигово, что узнал так рано и на вашем маршруте.
Без аналогии: знать свои пределы важно. Но вы не можете узнать их вне опыта. Одни марафонцы, другие спринтеры. Одни могут год копать поле и вскопать, но не могут рывком за неделю без сна выложиться в месячную норму. Другие могут рывком выложиться, но сдаются через месяц монотонной работы. Собсно, пока не начнёшь бежать марафон, не узнаешь, сможешь ли, захочешь ли добежать. Нужны оба типа, но вы на старте хотите знать, куда кого поставить. Марафонец — тот, кто уже пробежал хоть один марафон до финиша, уже пережил этот опыт, осмыслил и даже вот хочет ещё. Боец, не переживший это, понятия не имеет, что такое раз за разом брать себя за воротник, открывать десятое дыхание и копать траншею дальше без перманентного нытья и всхлипываний. У кого больше вероятность такого опыта, у Васи с годом работы или у Пети с пятью?

Во-вторых, «мне разонравились автобусы, я теперь люблю самокаты». Вася выходит из автобуса и на обочине начинает изучать самокатное дело. Середина маршрута. Автобус Васи взят на ремень, едва тащится без водителя за бандой. Чудесно. Оказывается, Вася ещё не закончил поиски себя и своего дао на великом пути Дао, потому пока-пока.
Без аналогии: в разработке много специализаций и редко кто прям с порога выбирает действительно своё. Первые годы состоят из проб. Сегодня я люблю C, завтра Python, послезавтра бегаю за хайповым машинным обучением, через год обожаю базы данных, а вообще геймдев крутой, но виртуальная реальность рулит. Ой, нет, мобильные приложения. Хочу писать под железо! Блиииин, как круто ботов делать! Аааа! Конечно, интересно наблюдать за этими юношескими горячими метаниями со стороны, но вам работу работать надо. Кто кажется надёжнее, Вася с годом Python или Петя, который уже пять лет джавист?

В-третьих, «за окном скучно, дайте мне красивые пейзажи». Вася в позе, Васе не сказали, что между Москвой и Владивостоком лежит постядерная пустошь. Все водители знают by default, Вася не знал. Выбегает из автобуса, оскорблённой походкой ловит попутки в Москву. Там красиво, там огни. Треть маршрута.
Без аналогии: всё больше людей, для которых работа должна быть интересным развлечением. Если в работе есть рутина, это плохая работа, надо её бросить. Потому нанимающие нередко внимательно изучают количество лет на разных работах. Вот Петя, за пять лет шесть мест сменил. Вот Саша, за пять лет два места. Кто с большей вероятностью умеет в рутину и в скучные пейзажи за окном?

В-четвёртых, «меня все обижают!» Вася открывает мир. Продавец сигарет может не улыбнуться. Лидер колонны может гавкнуть в мегафон. Велосипедисты вообще матерятся, покрытые пылью в хвосте самосвала. Сменщик Васи моется раз в месяц, потому всё, невыносимые условия, Вася убегает в закат. Середина маршрута, паренёк держался изо всех сил.
Без аналогии: тонкая душевная организация прекрасна, но коммерческая / промышленная разработка — это область решения задач, нахождения оптимумов, работа в окружении людей, столкновение интересов и т.д. Сам мечтаю на старости лет иметь работу, при которой тихонько сижу в углу сычиком и кноплю код без споров, договоров, объяснений, выслушиваний, дипломатии и всякого такого, но большинство работ не такие. Потому… хочется, чтобы нанимаемый Вася уже обкатался в бою и не дрожал трепетной ланью под каждым злобным зырком или после внезапного синего экрана смерти. Чем больше лет в резюме, тем толще нервы, логика простая.

В-пятых, «а что такого?!» Начало маршрута. У Васиного автобуса летние шины. На дворе зима. А что такого? Треть маршрута. Отваливается дверь справа. А что такого?! Середина маршрута. Выпадает лобовуха. А ЧТО ТАКОГО?! Через пару метров двигатель глохнет. Вася в недоумении.
Без аналогии: уважение правил техники безопасности приходит с годами. К некоторым и вовсе не приходит (привет перебегающим шесть полос автобана). Уважение, понимание и следование заветам всяких code style guide и вообще содержание кода в постоянной чистоте — оно тоже приобретается не сразу. Да, мастер должен всегда собираться. Да, должны быть тесты. Да, документация. Да, это мусор. И это. И вон то тоже мусор. Да, эта тысяча строк нафиг не нужна, блин, убери уже говно из-под ног, в автобус зайти невозможно без противогаза. Чем дольше разработчик работает, тем больше он видит примеров отдалённых косяков из-за всяких «и так сойдёт», «а что такого» и классического «я потом уберу!» Соответственно, если не рандом в черепе, у шестилетнего Пети код будет хотя бы чище, чем у двухлетнего Васи.

Фигня человеческой головы в том, что словами до нас почти не доходит. Только до самой ментальной элиты хватит слов «ЗАКРЫТО», чтобы не дёргать ручку. Вот когда подёргают раз пять, а потом и на другой двери, да ещё разочек, вот тогда закрепится «надпись ЗАКРЫТО не просто так». Сам не раз наблюдал. У нас на районе как-то на месяц закрылся Дикси. На двери было шесть (!) разных табличек и наклеек с «ЗАКРЫТО». Один фиг подходили, читали (!!!) и дёргали дверь.
Разработчики люди. У них такая же голова, пусть чуть другой формы. Потому в ночных фантазиях нанимателя поля пашут бойцы, которые уже наигрались, уже наискались, уже перебесились, уже не рыдают в подушку от грубого слова, уже насмотрелись на травмы за станком, уже обкатались под танками. Да, другие тоже нужны. Всех к делу пристроить можно. Но иногда очень хочется просто собрать караван, усадить вот этих суровых дальнобоев и через год получить письмо «мы на месте, чего дальше?» Детское наивное желание, да.

Книга: Информационные технологии в СССР

aab2ea96887a7168249c05cbf9131473
Ревич Ю.В., Малиновский Б.Н.
Информационные технологии в СССР. Создатели советской вычислительной техники.
БХВ-Петербург, 2014.
Ревич взял за основу книгу Малиновского «История вычислительной техники в лицах», расширил, [заметно] дополнил. Получился вполне хороший сборник биографий основного пантеона советского вычтеха.
Есть два нюанса.
Во-первых, речь почти только о «железячниках», конструкторах, делавших именно компьютеры. Программисты вне темы книги.
Во-вторых, авторы стараются быть положительно-нейтральными, так скажем. Лишь изредка прорываются штуки вроде письма Ревичу: «Опыт внедрения Эльбрус-1» от того, кто над этим Эльбрусом в 1982 году всем телом бился. Т.ч. срывания покровов нема, они в других статьях и книгах. Просто ровные истории о.
Книга годная, читать было интересно. Получил много поводов подумать и порыскать по другой литературе.

 

Мои учителя

Любой нормальный программист учится постоянно с первой же клавиатуры. Ненормальных надо учить. И у каждого своё понимание объёма «учить». Вспоминаю тех, кого считаю учителями, и считаю, что подхватил у них правильное, применяю правильно и «учу» правильно. Имена далее с потолка, мало ли. Кому надо, себя узнают.

Ваня (мой первый лид) смотрел с недоумением. Мне было 18 лет, не знал C, попал в контору по знакомству с директоратом, денег первые месяцы не получал и не просил, хотел учиться правильной разработке. Все мои дурацкие фантазии о какой-либо заботе были разбиты. Получил разработку небольшого (программируемый софтовый калькулятор) коммерческого проекта в одно рабочее рыльце. Получил лида, который жёстко придерживался правила «умный сам научится, а дурака учить — время зря тратить». Получил первый опыт прямого общения с заказчиком, да ещё и на английском (тогда я влепил в письмо чудесное слово «fitches» вместо «features», ведь все вокруг говорили «фичи»!). Получил первый опыт стороннего тестирования — Ваня подходил, с закрытыми глазами проводил полной ладонью по клавиатуре и порождаемый этим хаос раз за разом валил моё приложение в корки. Корки были болью, ибо кто писал на C под MacOS 7/8, тот танков не боится. Ваня пожимал плечами и уходил. Ревью кода проходил раз в месяц в режиме «ты чем думал, когда эту х..ню написал? а это вообще п….ц, а не код». Всё усугублялось тем, что при отсутствии информации об API MacOS я в процессе наваял свою библиотеку control’ов. Думали, выкинем этот ужас, но заказчик вдруг захотел ТАКОГО, что только кастомное рисование и спасло.
В итоге метод Вани сработал. Я написал и сдал свой первый коммерческий проект. Ваня получил оффер и уехал в США в один из мировых top-10 руководителем. Что важно? Если ты хочешь научиться программировать, тебе не нужен учитель. Есть книги. Есть компиляторы. Есть сотни часов теории и практики. Человек извне нужен лишь для того, чтобы корректировать вектор, дабы ученик не упоролся в совсем уж идиотию (ну и явно показать, что каждую итерацию ты делаешь хрень, а не стабильный продукт, да). Ване не было пофиг. Слегка злобный, едкий и честный мужик, которого откровенно тошнило при взглядах на меня и на мой код. Но Ваня НЕ МЕШАЛ. Ученик хочет учиться? Так учись, кто не даёт-то. Хочешь программировать? Вот компьютер, программируй. Нужна нянька? Вернись в детский сад, няньки в нём остались, освободи место тем, кому нянька не нужна. Хочешь за свою работу получать деньги? Делай работу так, чтобы было за что платить деньги. Честно, откровенно, справедливо.
Урок #1: если хочешь учиться, будешь учиться и без нянек; если не учишься, просто не хочешь, иди в жопу тогда, в чём проблема?

Петя задолбал занудством и педантичностью. До меня не сразу дошло, что это я идиот, прямо скажем, но потом дошло. Тогда ещё не было принято фигачить прототипы в продакшен и отстаивать это как вариант нормы. Если ты катил в прод туфту, которая валилась с пятисоткой, ты криворукий олень, а не спешащий навстречу рынку хипстер. Всё просто. Петя рулил проектами на 10..20 человек с планами на 1..2 года. Опять же, это я сейчас понимаю, что организовать наше стадце так, чтобы мы уложились хотя бы приблизительно в годовой план… Дай мне такую задачу, убегу с паническими криками. А Петя справлялся. Пожалуй, то очень важное, чему у него научился (опять же, не меня учили, но достаточно было смотреть на крутого чувака внимательно) — ДОКУМЕНТИРУЙ. ЧИТАЙ МАНУАЛЫ. ПЕРЕПРОВЕРЯЙ СЕБЯ. ПЕРЕПРОВЕРЯЙ ЗАКАЗЧИКА. ВСЁ ПЕРЕПРОВЕРЯЙ. Тогда это раздражало. Сейчас хочется извиниться за свою тупость, но как-то уже и не к месту, много лет прошло. Петя, ты был прав.
Урок #2: без бумажки не только ты какашка, но и твой код, и твой сервис, и вообще всё.

Олег работал тестировщиком. Спокойный боец, даже флегматичный. Торкнуло меня однажды, когда мы в очередной раз сидели ночью, я катил релиз за релизом, а Олег заворачивал из-за багов релиз за релизом. Мы очень устали, была ответственность, всё такое. Олег как-то… всё так же спокойно и с пониманием проверял, возвращал, проверял, возвращал… И снова только позже, рефлексируя, я посмотрел на ситуацию со стороны. Стало стыдно. Разработчик, легко относящийся к своим багам, он… как бы так сказать… я совершенно точно не считаю такого разработчика хорошим. Никакой. Обычный. Возможно, плохой. Но точно не хороший. Твои баги часто бьют по другим людям. Вместо того, чтобы сидеть с девушкой в кафе, лежать с женой на диване, пить вкусное вино, гулять в красивом лесу или просто спать, другой человек тратит свою жизнь на твои косяки. Ты поленился подумать? Тестировщик сидит лишние часы. Поленился проверить? Менеджеру лишние циклы с тикетами. Поленился не быть мудаком? Пользователи исходят истошными кликами на неработающем софте. Фактически ты вор чужого времени, обычный раздолбайский разработчик за свою жизнь умудряется угробить и чужую, если просуммировать все убитые из-за него часы. Потому, если не хочешь быть редисом, становись специалистом, баги которого вызывают хотя бы интерес, а не фейспалм класса «опять этот криворукий, как же заманал».
Урок #3: твои баги влияют на всех и на всё; заядлый багодел крайне вреден, его надо искоренять.
Также Олег молча своей работой показал мне, что разработчик не пуп земли. Не будь тестировщиков, мы со всей своей гениальностью катили бы заказчикам такой кошмар, что из судов не вылезали бы. Не будь техписов, фиг бы кто понял, что за бред мы в очередной раз выдаём за удобный юзерфрендли суперпродакт. Не будь менеджеров, уже через неделю лебедь, рак и щука казались бы верхом организации. Не будь лидов (бьющих дубинкой по задранным лбам)… вот тут не уверен, кстати, потому замнём для ясности. Короче, не будь их всех, разработчики были бы тоже не нужны в том виде и качестве, в котором они есть сейчас — изнеженные капризные создания, вокруг которых всё должно улыбчиво вертеться в темпе вальса.
Урок #4: тестировщик очень нужен.

Игорь, под руководством которого я впервые сделал что-то, что включил во внутреннее «сперва добился», закрепил во мне ощущение: хороший руководитель НЕ МЕШАЕТ. Да, это риск. Легко продолбать момент, когда прям вот надо было коршуном пасть на жертву и помешать творить зло (собсно говоря, на это я пару раз напоролся и до сих пор размышляю о том, когда же всё-таки авторитарно бить по рукам). Но в то же время это в какой-то мере… правильное деяние с точки зрения человечности? Когда не вмешиваюсь, молча говорю что-то типа «считаю тебя взрослым зрелым специалистом, которому я могу доверить реализацию проекта без постоянного контроля, потому не подведи, пожалуйста». Постоянный контроль убивает творчество, мысль, инициативу. А так… заодно и воспитывает ответственность.
Урок #5: нет ничего круче самостоятельности.
Евлампий, Ефим и Егор в свою очередь примерно в тот же период жизни и осмысления показали мне, что плохой руководитель почти всегда мешает. И почти всегда тому причиной два кита: 1) некомпетентность, 2) страх потери контроля. Как и все неудачные в своих проявлениях люди, эти тоже учителя. Просто научили не быть (не стать) таким же. Спасибо.
Урок #6: внимательно смотри на плохих специалистов и учись у них не быть ими.

Анатолия показала, каким полезным и нужным может быть менеджер. И, соответственно, каким идиотом на фоне будет разработчик, считающий, что менеджеры не нужны и вообще лишнее звено. Тогда же я вывел правило: если у тебя бюджет на трёх разработчиков, найми сильного разработчика и сильного менеджера, тогда сдашь сервис в срок. Тогда же в голове устаканился один из маркеров проверки разработчика на правильный опыт работы и жизни: спросить о роли менеджеров. Если снисходительно пожимает плечами, значит, пионер. Вообще это коротенький абзац, да, т.к. тема чуть ли не отдельного эссе. Наконец, я не выдержал и женился на Анатолии (нормальный разработчик нормального менеджера не отпустит далеко), потому хвалить как-то неловко.
Урок #7: менеджер очень нужен.

Наблюдение за Кимой дало понимание… даже не нужды, она очевидна… роли саппорта в жизни планеты. И снова тупоголовый тот разработчик, что относится к саппортам свысока. Если человек хорошо и тщательно выполняет эту работу, на большом продукте он стоит пары разработчиков. В конце концов, именно следствия разработческих недоделок и косяков входят волной гуано в первую линию обороны психики наших нежняшек — в саппортов. Святые люди, ейбо. Мало того, что им приходится вежливо, тактично и толково отвечать на сотни «ааааа, вы уроды, ничего не работает, верните как было! атписька!», так ещё они продолжают улыбаться и общаться с теми, кто допустил столько багов. Я бы уже после первого дня такой нагрузки настроил бы форвард на разработку, пусть наслаждаются. Но нельзя так делать почему-то. Разбегутся-с.
Урок #8: саппорты святые.

Что в этом списке важно… Вас не должны учить, чтобы вы научились. Просто смотрите на людей. Наблюдайте за их работой. Не стесняйтесь спрашивать о том, как и что в их процессах работает. В десятый раз повторю то, что через раз тут пишу: учитесь самостоятельно. Нет, никто ничего вам не должен. Это ваша жизнь, вы за неё в ответе. За будущее, за свою специальность, за состояние мозга, за конфигурацию нейронов. Не мама, не папа, не бабушка и даже не цепочка лидов до боженьки. Вокруг вас всегда есть кто-то, кто умеет что-то лучше вас. Учитесь у них, достаточно иногда просто посидеть рядом. Человек не должен вас учить, чтобы быть учителем. Часто достаточно уже того, что он есть. Всегда есть что-то, что вы умеете плохо. Добудьте учебники, наточите пальцы и научитесь делать это хоть чуточку лучше.
В конце концов, попробуйте себя в разных ролях. Протестируйте продукт Альберта (и получите те же баги ещё раз пять обратно, после чего посмотрите в зеркало). Попробуйте отменеджить проект (тикеты, заказчики, формулирование ТЗ, подбивка сроков, планов, всё такое). Напишите мануал к своему сервису, дайте своей бабушке (не поняла? отличный у вас мануал). Замените саппорта на сутки. Ладно, жестоко. На час. Часа хватит. Побудьте лидом недельку (заодно поймёте, почему ответ «а потому!» не считается правильным).
PS. Ну и да, у всех (кроме Евлампия, Ефима и Егора) прошу прощения. До того, как стать умным, я был глупым. Жаль, что вы при этом присутствовали и вынуждены были из меня эту глупость своим примером изгонять. 🙂

Книга: Low-Level Programming

414l6NJ8yyL._SX348_BO1,204,203,200_
Igor Zhirkov.
Low-Level Programming: C, Assembly, and Program Execution on Intel® 64 Architecture.
Apress, 2017.
Про low level сейчас мало свежих книг, потому мимо этой пройти сложно. Но лучше бы и пройти, отложив на будущее. Озлоблённость и недоумение вызваны неудовлетворённым ожиданием. Я хотел книгу про ассемблер, процессоры, архитектуры, красивости и всякое такое. А получил методичку какую-то отечественному студенту.
В книге 446 страниц. Если убрать «технические» страницы (обложка, содержание, индекс, благодарности, титульные страницы глав и т.п.), а их 36, получим 410. Но ещё есть приложения: про gdb (9), make (5), семь из 333 syscalls (6), сводочка про перфтесты (3). Ещё минус 23 страницы, в остатке 387. Буду злобным и summary-страницы в конце каждой главы посчитаю ненужными: 17. Итого получаем книгу в 360 страниц.
Но… тадам! Со 127-й страницы по 220-ю нам пересказывают основы языка C! А с 221-й по 231-ю галопом про БНФ, AST и парсинг с семантикой. Зачем-то. А с 241-й страницы по 261-ю галопом про good code practices. Снова зачем-то. Эдак 120 страниц добавляю в минус. Осталось 240. Из которых 115 посвящены «Assembly Language and Computer Architecture» и 125 теме «Between C and Assembly».
Вот сами подумайте, что можно уместить в 115 страниц по заданной теме? Правильно. Снова галопом. И автор прям сознательно указывает, что команды не описывает, мол, всё устаревает, топайте в интернеты, в мануалы от Intel, там научитесь. Ну офигеть мне удобно метаться туда-сюда, просто вот разе на десятом восторг от решения. Проверочные вопросы примерно из той же области: «What is the difference between sar and shr? Check Intel docs» — кхм, уважаемый Игорь, мне казалось, что задача учебника также и в том, чтобы рассказать мне об этой разнице, а не форвардить в мануалы Intel, которые я и без того почитаю. В общем, в сравнении с другими книгами эта тема разобрана просто никак. Очень конспективно, лишь бы зачёт сдать.
Единственное, за что хочется сказать «спасибо» — Between-тема. Она тоже конспективно, тоже галопом, но весь этот дайджест собран в одном месте и позволяет раскручивать интернеты более точечно и системно.
Итого… Ну, 125 страниц из 446. Я не знаю, кому и зачем нужна такая книга. Не знаю, кто ставил ей хорошие оценки на Амазоне. Есть гораздо более правильные книги по C. И гораздо более правильные о практике программирования. И про ассемблер, как уже знаю. Автор очевидно хорошо знает тему. Но нафига пытаться упихнуть в удава десять слонов? И о чём и для чего всё-таки книга? Практику всё равно после неё до фига молотить. Теоретику слишком мало написано. Интересующемуся (вот типа меня) слишком конспект и как-то… чуть дубово написано, пардон.
В общем, я грустно разочарован.

Хорошие люди

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

Давайте на примере. У вас есть ближний набор задач ABC (написать сейчас-сегодня сервис поиска работы, вакансии, резюме, это вот всё). И есть дальний набор задач XYZ (рекомендации после машинного обучения, рекламная сеть работодателям, служба умных рассылок, собственный биллинг, соцсесточка кандидатов, тестовая платформа). Идеи есть, даже бюджеты есть, но проблема с людьми. Вы не IT-беспомощный, есть опыт и всякое нужное, потому вполне внятно представляете, какой стек где используется. Потому вывешиваете вакансию с перечислением… скажем, Python, PostgreSQL, Django, Linux, ну и фоновый фундамент в виде алгоритмы + процессы + адекватность.
Приходит Петя. Не ваш знакомый. Не по рекомендации знакомого. Человек, которого вы не знаете совершенно. Но он считает, что подходит к работе, что вы предлагаете. Как вам удостовериться, что это так и что Петя не пекарь, месяц назад решивший сменить профессию? Про пекаря не шутка, реальный случай. Дядька много лет в пекарне работал, утомился и захотел начать с чистого листа. Чем-то понравилось программирование, месяц прозанимался по вечерам, пришёл на вакансию middle.
Для удобства (иначе можно расходиться) предположим, что вы не идиот, не эльф, не вчерашний выпускник детского сада. Потому знаете, что люди могут заблуждаться, обманывать, переоценивать себя, смещать акценты, умалчивать, выпячивать и т.д. А ещё каждый день утром перечитываете список когнитивных искажений, потому даже в зеркало смотрите с прищуром.
И да, вы не телепат. И не гений психологии. Вы, конечно, уверены, что глазом-алмазом раскусите любой орешек, но этой вашей уверенности есть название в списке выше. Нет, не раскусите. Потому вооружайтесь всем, что прочли на Хабре и в Твиттере, и айда отделять пекарей от прирождённых питонистов.
Блин, ещё лирический абзац. Вышесказанное, конечно, подразумевает, что нанимать пекаря вы не готовы. После ряда бесед я не уверен в этом «конечно», отсюда и абзац. Пекари пекут хлебобулочные изделия. Они этому учились теорией и практикой. Программисты пишут программы. Этому они тоже учились теорией и практикой. Если в вас 146% оптимизма в конце жизненного квартала, вы можете предположить (ну, читали же про случаи!), что пекарь Петя за полугодие наваяет вам бекенд с API, от которого не повесится фронтендер, не будут нервно смеяться админы (они делают ставку, будет ли побит рекорд в 1000 алёртов мониторинга за сутки), не будет стыдно перед колбасником Игорем (которого вы наймёте после увольнения Пети). Но это даже не сказка и не фантазия. В общем, не надо пороть фигню. Есть работа для программиста? Нанимайте программиста. Скучный вариант, но часто срабатывает.

Уф. Ну и? Какие вопросы задавать будете? Человек явно хороший. Лицо доброе, речь гладкая, в глазах отсветы печи (огнём горят, ага). Котяток любит. Дома жена и двойня малявок на лавке, ножки свесили, болтают. С хорошестью проблем нет. Сервис-то напишет? А когда? А какой? А с каким качеством? Заодно придумайте вопросы, которые вам прям вот сейчас (а не через год) дадут понимание, обучаем ли Петя. Да, он не знает Django. Но по-братски клянётся, что за две недели выучит! Поверите? Нет? Да? А на основании чего?
В процессе интервьюрования вы, возможно, вспомните, что разработка сервиса — это не только код писать, но ещё и тестировать, документировать, эксплуатировать. Хороший разработчик этому учится достаточно долго уже потому, что нужда в таких умениях в голову пролезает не сразу. Очень туго идёт, прямо скажем. Пока сто раз не напорешься на баги (Вова тесты не написал), не уткнёшься в пустоту информации (Олег документацию не написал), не поднимешься в три часа ночи по звонку (Игоря потребление памяти не волновало)… Хотя… Хорошему человеку разочек объясните и он всё поймёт, да? Не проблема, согласен. Это только какие-то плохие человеки даже после десяти напоминаний в прод мимо теста катятся, ага.
Уже готовы спрашивать? Давайте я финально масла в азарт подолью. Петя хочет 150К в месяц. Консилиум лидов прикинул, что нужный вам сервис писать от первого символа до прода надо год. Потому сейчас вы решаете следующую задачу: кто получит ваши 1.8М рублей, хороший человек или хороший программист? Вот и решайте. Интересная задачка. Ещё интереснее в том, что никакой Петя никаких гарантий вам не даст. Он ничего не должен. Наёмный работник, о чём Пети в удобный им момент легко вспоминают. Просидит свои месяцы, получит зарплату, разведёт руками и пойдёт дальше. Потому ВСЯ ответственность на вас. Вам решать, вам потом разгребать и думать, чего дальше делать.
Всё. Время пошло. Вам ещё троих таких же нанять (и через год объяснять результат за 7М+ рублей). Постарайтесь не скатиться в банальное техноинтервью, это нынче моветон. Enjoy.

У меня чего сарказьму и йаду столько-то… Честное слово, насмотрелся на «хороших людей» до упокоя души. Не работает этот метод. Ничем не лучше бросания монеток в кандидата. Девять из десяти раз будет устрашающий код, уволенный человек и рыдающие переписывающие. Но об этом статью никто не напишет, чё, звучит как-то обыденно. Один раз монетка попадёт в чувака, который и так бы норм собеседование сдал. Да, он выстрелит. За год в сеньора, за два года в лиды, за три года в CTO на IPO. Про него сложат легенды и будут тыкать примером. Красивые твиты напишут. Что-то типа «Петя на собеседовании не смог в XOR, через три года директор PetiaSoft, будь как Петя» и 123К ретвитов от тех, кто не может в XOR (словно это пропуск в директора). Но ещё раз: один из десяти. А с теми девятью вам надо будет чёт делать нехорошее. Пять раз объяснить задачу. Четыре раза попросить её сделать. Шесть раз убиться глазами о предложенное решение. Трижды напиться от отчаяния.
PS. Метод «хорошего человека» работает только в одном варианте: хороший человек УЖЕ знает столько, что ваш стек и ваше доучивание для него являются привычной каплей в море. Для него нет проблемы хорошо освоить MySQL, у него за плечами Oracle и PostgreSQL уровня DBA. Для него нет проблемы освоить Python, он 120 лет пишет на C / C++ / Java / PHP / Perl / JavaScript. И ваши нюансы местного хайлоада для него не проблема после 15 лет хайлоада в пяти топовых центрах обработки данных. Алгоритмы? Ну… активный коммитмент в SciPy устроит вместо зачёта? Вот такое норм. Таких бойцов и в самом деле не собеседуют, просто говорят о жизни за чашкой чая, осторожно подманивая.

Таки что должен разработчик

Порою бывают разговоры с разными разработчиками, которые (разговоры) после суммы за N..M времени дают интересную картину. Прочтите список ниже. Уверен, хоть с парой пунктов, но сталкивались. А часть одобряете.

Разработчик не должен ставить себе задачи. Этим занимаются лиды и менеджеры.
Разработчик не должен проверять свою работу. Этим должны заниматься тестировщики.
Разработчик не должен хотя бы думать про эксплуатацию. Этим должны заниматься админы.
Разработчик не должен делать архитектуру. Этим должны заниматься архитекторы и лиды.
Разработчик не должен учиться. Его должен обучать работодатель.
Разработчик не должен думать про юзеров. Этим должен заниматься саппорт.
Разработчик не должен разбираться в базах. Этим должен заниматься специальный DBA.
Разработчик не должен разбираться в железе. Этим должен заниматься хелпдеск или железячник.
Разработчик не должен заниматься продуктом. Этим должен заниматься product owner.
Разработчик не должен в удобство. Этим должен заниматься UX-боец.
И ещё куча всего. Бекендеры не должны даже админку на бутстрапе. Фронтендеры не должны даже Node.js на Ubuntu поставить. Джависты не должны в JVM, а питонисты в PVM, так сказать. Скучной тикетной бюрократией тоже менеджеры. А планы оставим лидам и… да, менеджерам. Про прибыль пусть голова у бизнеса болит.

Тут… сложно с оценкой. Формулировать не хочу, попробовал, получил даже наброском две страницы. Предлагаю умственное упражнение. Найдите ответы на вопрос «в какого рода бизнесах и в каких задачах такие разработчики применимы?» Из «таких» при этом исключим редких узких специалистов, которые ничего больше не знают, но могут по названию функции сказать файл и номер строки в исходнике JVM. Их очень мало, живут справа на крае распределения.
Напомню некоторые важные элементы производства софта, чтобы вам было удобнее.
Экономика. Грубо говоря, количество денег на старте. Влияет на то, как долго вы можете что-либо делать до момента, когда что-то начнёт приносить прибыль, достаточную, чтобы покрывать текущие расходы. Например, у вас 1М рублей и разработчик Иванов за 100К рублей. Соответственно, уже через 10 месяцев на рынке должен быть МойСуперПродукт с остатком в 100К рублей (вам ведь всё ещё платить Иванову) после выплат за хостинг, рекламу, налоги и т.д. Если Ивановых два, у вас 5 месяцев, а продукт должен выдавать 200К. Если для надзора за этой парой вам нужен Сидоров за 200К, вам хана — бюджета на два с половиной месяца, затем пополнение списка «миллион закрытых стартапов». Примитивно, но наглядно.
Продукт. Разработка ради разработки не нужна вне стен квартиры. Программист программой решает задачу / проблему. Цельная совокупность решений составляет продукт. Целью разработки является выход продукта на рынок / в науку / в народные массы. Пока продукта нет, все работают в минус и на перспективу (ща мы наберём компетенцию на семи граблях и каааак ух!).
Качество. Иванов, не умеющий в эксплуатацию, склонен делать сервисы, падающие под слабой нагрузкой. Петров, не умеющий в базы, поставит базу колом своим селектзвёздочка на месячном логе. Мало того, что вы можете так нарваться уже на репутационные риски, так впереди могут оказаться претензии от клиентов. А, да, ещё Иванов и Сидоров будут месяц чинить. Посмотрите на Экономику — это минус 200К от вашего начального бюджета.
Форсмажоры. У вас два разработчика и один лид. Лида сбивает автобус. Что дальше? У вас бекендер и фронтендер, фронта сбивает автобус. Что дальше? У разработчиков всё хорошо, но автобус добрался до вас. Что дальше? Bus factor в прямом виде редко бывает, но в вариантах постоянно: болезни, семья, государство (смешные кейсы, когда руководителя проекта с Болотной в автозаке на весь день), усталость (мужики, не могу больше, ухожу в отпуск на месяц), бабло (мужики, за углом на 10К больше, пока-пока) и т.п. Ваш бизнес остановится или нет? А почему?

Как-то так. Клеймить и размахивать шашкой не буду. Можете посмотреть вакансии и резюме. Посмотреть оклады (почему Иванов 100К, а Петров 200К). Прикинуть, с какой командой и какой стартап хотя бы в теории может выжить в период разработки. Всё просто считается. Ну а потом ещё раз перечитать список и прикинуть, что такое хорошо, что такое плохо.