Про ответственность

Раз заговорили про ответственность, давайте глубже.
За кадром в интересах другого эссе оставлю тему «а за что же отвечает-то программист», ибо велика она, необъятна и по всей поверхности обмазана программистами, не желающими ни за что отвечать. Предположим, что общественность содрогнулась разумом и смогла сформулировать эти зоны. Скажем, раз ты эту строчку кода написал, ты за неё и отвечаешь. Раз ревьюирующий её вмёржил в мастер, он ТОЖЕ отвечает. И так дальше по цепочке до руководителей, пустивших код в продукт наружу. Утопия прям, ага.
Предположим, что в УК ввели статьи, предусматривающие наказание от 1 года до 15 лет за решёткой. А также ввели в культуру производства штрафы за то, что в УК не уместилось. Тут важно уточнить, что введут именно про программистов и для программистов, так-то и сейчас можно залететь на общих основаниях, если под режимом или по хитрому договору. А предположение затронет всех и везде. Твой код убил людей? Садись. Твой код привёл к простою завода на сутки? Штраф на пару пожизненных. Твой код продолбал миллион полезных чисел? Ну вот миллион и плати. Жёстко, угрюмо, но для модели самое то. К чему это приведёт?

Разработка разделится на две части: «сажабельная» и «всем пофиг». Произойдёт распределение кадров между потоками, подавляющее большинство прыгнет в ту, где риска меньше. Так же распределятся и входящие в профессию. Образуется и пограничная область «не посадим, но штрафами ушатаем», но её судьба после десятка громких дел категории «Петя поставил лишний плюсик, а его за это в рабство! Ироды! Сатрапы!» будет равна «сажабельной».
И да, первые громкие дела будут болезненными. Мало внести изменения в УК, надо воспитать поколения, привыкшие к ответственности. Пока воспитываются новые, будут страдать старые, ползущие в будущее на старой инерции. Бунты будут проходить под лозунгами «мы всегда так делали!», «деды не тестировали и мы не будем!», «все ошибаются, сажайте страну!»
В «сажабельной» оклады будут выше. Просто потому, что кадров у них будет намного меньше. А во «всем пофиг» оклады могут упасть, т.к. они в свою очередь испытают резкий рост кандидатов, готовых работать даже с понижением (лишь бы не посадили). Но не сразу. Долгий период игры и контрактов по новым правилам. Не все работодатели и не сразу осознают, что уже через сутки без дополнительной мотивации у них вообще никто на работу не выйдет, потом от испуга задерут оклад до небес, потом индустрия обвыкнется и нормализует. Но эти качели с дикими индивидуальными случаями войдут в легенду.
Резко скакнёт вверх рынок сертификаций как софта, так и людей. Законодательство может не сразу успеть за практикой, но подтянется (уж что, а регулировать государства любят). Если можно будет делегировать ответственность на других, появятся как другие, так и плата за их услуги. Хотите использовать последнюю версию MongoDB? Либо на свой страх и риск используйте, либо ждите, пока сертифицирующий центр её проверит, поставит штампик «ОТК принял», после чего и. И даже если баги там окажутся, и даже если из-за них нанесён ущерб, вы уже не отвечаете, ответит центр.
Людей тоже начнут сегрегировать. Если Игорю во «всем пофиг», всем пофиг. А вот если в «сажабельную», работодатель захочет больше гарантий того, что ты не просто хипстер с клетчатой рубашкой, но действительно знаешь. Потому сертификации, тесты, экзамены по всем областям. Потому каждый год подтверждение квалификации. Это несколько формализует рынок труда и переведёт его в область «докажи дипломом, а не языком».
Программисты научатся говорить «нет», а бизнес научится их слышать. Тут в целом начнётся интересный психологический сдвиг. Одно дело со стороны рассуждать о том, что тебя не касается и не коснётся. Другое дело не встретить сегодня на работе Васю потому, что он в суде приговор выслушивает. А через месяц увидеть offline у Вани, который в бегах в тайгу подался, дабы не выплачивать огромный штраф. Пока снаряды за горизонтом, сарказьм сарказьмирует, но тут-то они в окошко постучат, сразу интереснее жить и думать.
Так вот. Нет досрочной выкатке в продакшены. Нет нарушениям цикла. Нет работе с низкоквалифицированными коллегами. Нет поблажкам на собеседованиях. Нет внедрению непроверенных решений. Нет «у нас сроки горят, потому катим как есть». Повторю, всё очень просто: если неудачная выкатка подведёт Игната под статью, Игнат предпочтёт потерять работу, отказавшись от выкатки, но не свободу. Если эта же выкатка тянет за собою по цепочке в посадку и руководителей, руководители начнут внимательнее слушать разработку.
Но так будет не со всеми. В Китае 46 преступлений, за которые смертная казнь (от коррупции до наркотиков), всё равно 5000 казней в год. В новой разработке тоже найдутся камикадзе. Первыми падут те, кто не понял, что шутки кончились. Ребята, которым надо пять раз сказать «не влезай, убьёт», а они всё равно на шестой раз влезут, т.к. надо было сказать семь раз. Падут оставшиеся под стрелой за бабло, но без умения обеспечить качество. Падут случайные и племяши знакомых, которых не успеют вычистить руководители. Также падут и руководители, переоценившие уровень своей разработки и решившие, что с той же пионерской бригадой можно жить в новом мире. Жатва будет собираться ежегодно, прореживая контингент.
Разделение пойдёт и в области прогресса. Чем толще регламент, тем медленнее повозка. Бойцы из «всем пофиг» так и будут выпускать по десять фреймворков в год, а вот «сажабельные» бойцы начнут осторожничать и предпочитать проверенные годами решения. Соответственно, снова захватится и рынок. Часть вакансий и кандидатов с условно устаревшим стеком, часть с опережающим здравый смысл. Более того, не все технологии пройдут сертификацию, потому и стек «сажабельных» будет заметно меньше. Правда, это компенсируется нуждой в хороших знаниях.
Возможно, активизируется рынок «заградительных» решений. Более тонкие анализаторы кода, многослойное автоматическое тестирование, автоматические проверки безопасности, легко разворачиваемые стенды проверки на отказоустойчивость. Это тоже может породить свою нишу, в которой специализированные конторы смогут предоставлять недорогие облачные решения и сервисы, прохождение которых тоже могут прикрутить к сертификату качества.
Но всё равно ошибки будут. Меньше на пару порядков, а просочатся. Каждый такой случай будет вызывать шумиху в прессе и в тусовочке, раз за разом поднимая волну. Но общество, обнаружившее, что в каждом углу по десять программ (от прошивки утюга до «прошивки» Боинга), за сбои в работе которых наконец-то можно кого-то наказать, будет так же раз за разом эту волну гасить.

В целом любопытная штука с непредсказуемым результатом. Пользователи могут получить возможность выбрать софт, который надёжнее, а не тестировать вместо разработчиков на себе. Разработчики могут выбрать между режимами жизни и отношением к. Работодатели получат более жёсткую выборку квалификаций без рандомного подбрасывания монетки. А может всё оказаться и наоборот, если звёзды сойдутся. Если разрабатывать программы под УК настолько медленно, что рынок не согласится столько ждать и публично подпишется на «мы готовы терпеть ваш говнокод, просто сделайте это вчера»? Или программисты массово сбегут в какую-нибудь Нигерию, в которой всем будет плевать на подобное законодательство?
Уверен в одном: что-то меняться будет. Толчком послужит всё большее вливание AI в быт. Роботы-хирурги. Роботы-такси. Роботы-няньки. Роботы-пожарные. Роботы-строители. Они тоже будут ошибаться, их ошибки будут приводить к смертям. И в какой-то момент накопится такое количество смертей, после которого общество захочет кого-нибудь посадить. И не один раз, а системно. Тут-то о программистах и вспомнят. И я чёт пока для себя никак не могу решить, в какую из контор после этого хотел бы пойти, в «сажабельную» или во «всем пофиг».

Элита

Update спустя полтора месяца: многие приходят в это эссе через прокси внешнего мнения вроде «Наткнулся на очередной наброс на тему дутой элитарности программистов. По факту, чувак с “двадцатилетним опытом” рассказывает, какие сегодняшние программисты лохи с его точки зрения (не то, что он сам, с двадцатилетним опытом-то)». Чуваки. Я уже убедился, что примерно 1/8 читателей таки может прочитать в моём тексте то, что в нём написано. В общем, мне этого достаточно, чтобы посчитать цель достигнутой. Если же вам кажется, что написано примерно то, что в цитате выше, вы не вошли в эту 1/8 и прочли что-то своё, не трудитесь делиться со мною реакцией, пожалуйста. Чуваки, решившие «не то, что он сам, с двадцатилетним опытом-то», вообще половину букв не смогли тут, мне думается, но до чего ж вас много-то, а. Хочется вам на форумах обсасывать, помидорить, в подкастах ёрничать, в Твиттере изумляться и страдать — да и фиг бы с ним. За мною только не бегайте с драгоценными мнением КГ/АМ, до вас тут уже стадо пробегало с какого-то ресурса.

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

Во-первых, программисты не инженеры. Раньше были, а всё. В массе своей это ремесленники уровня ПТУ. Наука не нужна, теория не нужна, культура не нужна, знания не нужны, нужно давать софтовые надои. Потому типичный средний программист дёргает корову за вымя, не особо желая разбираться в том, что именно и зачем он делает. Делает то, за что платят. Таксист в двигателях больше понимает, чем программист в компьютерах. Ну да, где-то там под крышкой процессор. И материнская плата. Штука, на которой процессор. По факту программист понятия не имеет, как всё это работает и от продавщицы Любы в ларьке отличается только тем, что Люба внутри ларька, а программист снаружи.
Во-вторых, программисты не учёные. Сосед Вася, может, и будет считать Петю в футболке «Е равно ЭмСиКвадрат» знатным ботаном с докторской степенью, но Петя ни фига не расскажет, почему квадрат, а не куб. Просто футболка прикольная, в «Теории большого взрыва» была. А так-то Петя тот же Олег из Кукуевки, только по верхам нахватался из ленты соцсеточек. И при работе с чем-либо опирается вовсе не на достижения научного метода последних ста лет, прямо скажем. Вне вымени Петя не знает ничего. Даже не запоминает. B-tree? Што? Мне это не надо.
В-третьих, программисты не работники. Рабочий день или рабочий режим — это вот не про Васю. Ну т.е. планета умеет с А утра до Бэ вечера головой думать и руками делать, а Васе для прикручивания кнопочки к верёвочке требуется нечто особое. Почитать новости. Полистать ленту. Обсудить осадок чая и ситуацию в Камбодже (о которой Вася только вчера из новостей прочёл два абзаца). Надо настроиться… Посмотреть в потолок… Возможно, почитать документацию (шутка, кто ж её читает, это же программисты). Опаньки, обед. Покушать. Разморило-то как… Где тикет? А вы читали, что вводят где-то 4-дневную рабочую неделю? И вообще хочу из дома работать, у меня там котик! Короче, работа — это не про программистов.
В-четвёртых, программисты неженки. Посмотрите на офисы топовых известных компаний, это ж детские сады. Зайка не сможет забить гвоздик, если над зайкой не будет стоять гурия с опахалом, за углом не будет велосипедика, а яблочки будут порезаны поперёк, а не вдоль. Т.е., блин, чуваки мирового уровня собирали из говна и палок первые компьютеры и софт следующих поколений в подвалах, а Серёже пальчиком тяжело шевелить, если на кофепоинте не десять сортов бесплатного печенья. И ладно бы гравицапу творил, так нет же, чинит свою же опечатку после опечатки, которую на прошлой неделе сделал в интересах исправления предыдущей опечатки.
В-пятых, программисты инфантильные. Тут это означает, что они понятия не имеют, как им справляться с собственной долбанутостью, не научились. Любая проблема, любая сложность, любое несовпадение реальности с внутренним миром Игоря — всё, мы все умрём. Апатия. Выгорание. Меланхолия. ДЕПРЕССИЯ. Блин, ясен пень, у тебя будет депрессия в предощущении того, как надерут жопу за десятки открытых тикетов, которые ты не сделал, ибо набирал мотивацию просмотром роликов, прослушиванием музыки и беседами о роли Путина в квантовой генетике Навального. Но нет, это не Игорь фигнёй страдал вместо написания тестов, это злые все обижали дражайший внутренний мир подростка с метрикой взрослого. Соответственно, токмо попробуй Игорю микрон критики в плечико вонзить… Страдания Вертера покажутся развесёлой комедией.
В-шестых, у программистов нулевая базовая литературная культура. Если пройдётесь по деревенскому рынку с опросом «читали ли вы Борхеса», результат будет тот же, что среди программистов. Разница лишь в том, что Нариман (вкусный абрикос! сладкий дыня!) может и устыдиться своего аборхесианства, зато программист Игнат с пеной на губах вам час будет плешь гладить обоснованием того, почему он не читает вообще, не читает книги, не читал Борхеса, почему культуры нет в принципе, человек современный вне культуры и т.д. Как вариант, ответно атакует глубоким знанием аниме и «Ричарда длинные грабли». Ну типа тоже культура. Великая японская. Ну и что, что не Кобо Абэ?
В-седьмых, программисты дремучи вне своей узкой сферы деятельности. Посмотрите в глаза Феди. Мудрость. Прищур. Всё понимающая роговица. На деле же Федя не знает ни.че.го. Биология. Химия. География. Литература. История (о, тут Федя скажет, что его обманули все историки, но не сможет назвать цвет обложки хоть одного исследования). Экономика. Физика. Социология. Ни. Че. Го. Я знал чуваков, что не могли указать, где у них печень, слева или справа. Просто не знали.
В-восьмых, отечественные программисты любят спорить. И ладно бы. Но предыдущий пункт же. Пример типичного спора: час бодаться про законодательство России, ни разу за жизнь не открыв УК. Википедия листается тут же по ходу обсуждения. Но мнение имеют. Уверенное такое мнение, увесистое. Вместо законодательства может быть хоть климат Венеры (Илья читал в детстве книгу про Венеру, потому невдолбический специалист), хоть сорта огурцов средней полосы (Павел помогал бабушке кушать огурчики, потому агроном).
В-девятых, программисты ощущают (и ведут) себя уникальными. Фиг с тем, что каждый год их миллионы. Но блин, овердофига специальностей, в которых извилины морщит так, что наш Стёпа помрёт на третий день. Более того, множество людей ещё и под стрессом ответственности за реальный мир морщатся, пока Стёпа оперирует виртуальными ценностями в песочнице. Бжчки, да сейчас софт даже дети пишут, выкладывают в магазины и этот софт покупается. А тот софт, что действительно крутой (ну-ка, моделирование нагрузки на конструкцию корабля в боковую качку), для Стёпы так же далёк, как Пугачёва во внучках.
В-десятых, программисты не читают. Типичный Алёша при задаче «сделать XYZ» пойдёт делать XYZ. Не хотя бы листать мануал. Не вникать в документацию. Что-нибудь нагуглит, как-нибудь сделает. Только если с десятого раза не заработает, нехотя подползёт к литературе и вытащит самую тоненькую книжечку, вдруг в ней ответы на главные вопросы. Лучше, чтобы один. На одну страничку. В 140 символов, как раньше было. Если тысячу лет протяну, всю тысячу лет буду помнить эпичный случай с человеком, писавшим софт 5+ лет. Человек очень плохо сделал генерацию уникального ID. Прям вот совсем на отвали. Я минут 15 объяснял, почему плохо и как надо, тут же пару раз сказал не использовать функцию id() у Python. Объяснил. Через час смотрю pull request. Там id(). На реактивной попотяге выясняю, что человек меня выслушал, открыл документацию к id(), прочёл первое предложение («Return the “identity” of an object») и решил, что норм. Первое. Одно. Он открыл документацию, прочёл шесть слов и закрыл документацию, не добравшись до следующих слов. 5+ лет разработки. Я плакал злыми слезами в углу. Совет RTFM придумали не химики и это не просто так. В детском саду детям больше текста читают, чем программист по специальности.
В-одиннадцатых, у программистов нет ответственности. Вот совсем. Ронять тесты, сервера, Боинги, Луну — задорно и молодёжно. Ежели слишком уж зарвался, всегда можно удрать на другую работу, в резюме же не пишут ДЕТАЛИ, а увольняют нынче красиво, без статьи. Лишь бы ушёл. Антону поди поясни, что такое ошибка, почему это плохо, зачем быть так, чтобы ошибок не было. Ну и что, что всё упало? Ну и что, что у клиентов убытки? Ну и что, что работодателю убытки? Ну и что, что коллеги через год застрелятся? Ну и что, что не по плану? Ну и что, что обещал? И вообще, я устал, у меня апатия, а вон там печеньки дают, я туда пошёл.

Единственная причина, по которой все эти слои всплыли и программисты как-то выделяются на фоне — мы живём в эпоху информатики и человечество пока не нагнало миллиарды выпускников ПТУ на новые станки. Первые операторы первых ткацких станков тоже были «элитой». Несколько десятилетий спустя превратились в обычнейшую профессию. Так и сейчас. Компьютеров и задач гораздо больше, чем людей, потому рынок поступает прямолинейно — рост условий работы (деньги, соцпакет, велосипедик за углом). Всё это в сумме даёт программистам ложное ощущение, что они важнее, лучше, умнее. Ну… Нет, ребята. Фигня в том, что компьютеров десять, а вас пятеро. И хвалить с поцелуями вас будут даже в случае, если IQ будет ниже планки армии США (81).
И мне чертовски любопытно дожить до эпохи десяти компьютеров на двадцать ребят. Уверен, будет весело.
PS. Читатель! Ты не такой! Ты трудолюбивый умница без снаряда в психике! Твоим воспитанием занимались не Наруто с кем-нибудь ещё крупноглазым, но Сенека с Вольтером! Всё будет хорошо! Это автор злобная скотина, а ты настоящая элита, правда-правда.
PPS. Не могу не проиллюстрировать вышесказанное прекрасным комментарием, полагаю, программиста. Тут и навык освоения материала до выводов. Тут и строгая логика. Тут и глубокое понимание связи возраста с используемым технологическим стеком. Тут и проверка сделанных выводов на дополнительном материале, вполне доступном, конечно же. В общем, если эссе нуждалось в картинке, то вот она.
PPPS. Тем, кто дочитал до этого блока, забавные числа покажу. Есть книга [Мартин Клеппман. Высоконагруженные приложения. Программирование, масштабирование, поддержка. Питер, 2018]. Действительно хорошая, довольно известная в мире. Я сначала увидел её на чужом мониторе, а потом на радостях купил отечественное издание в бумаге. Так вот у неё первый российский тираж 700 экземпляров. Потом меленькие допечаточки. Так издатели поступают в России с профессиональной литературой, т.к. (сюрприз!) умеющих читать всё меньше. Спустя пару месяцев книги в больших магазинах уже нет. Повторю: 700. На Россию. Книгу, которая вне России bestseller. Второе число: эссе, в котором говорится по сути, что программистам в голову только короткие тексты лезут, что программисты не могут в учёбу, что книги не читаются и вообще готовы фигнёй страдать, лишь бы не работать — подбирается к 7000 прочтений. В десять раз больше. По данным Роскомстата в 2016 году в IT было 440К+ человек. Пусть [с потолка] программистов 10%. Пусть из них половина бекендеры. 22К человек. И тираж в 700 экземпляров. Может, вы, на самом деле крутые перцы, сплошь PDF’ку купили или с торрентов скачали? Хорошо. А почему в англоязычных интернетах программисты эту книгу на форумах обсуждают, в блогах упоминают, друганам советуют, а в нашем сегменте болота тишина? Sapienti sat, не?

Зачем читать книги

С первых же строк скажу, что разработчику можно книги не читать. Более того, подавляющее большинство не читало и не читает. В интернете хватает статей и форумов, StackOverflow открыт круглосуточно, документация щедра, наконец, исходники часто открыты. Так и справляются вплоть до senior’ов и руководителей разных мастей. Короче говоря, я в курсе.
И это не очень хорошо. Дальше вразброс и кратко накидаю, чтобы больше уместить, полноты и цельности не будет. Скорее, россыпь аргументов и примеров для осмысления.

Вне книг вам доступно не всё.
Во-первых, часть информации существует только в книгах. Если вы не читаете, значит, не читаете [Frederick P. Brooks Jr. The Mythical Man-Month. Addison-Wesley, 1995] или [Robert C. Martin. Clean Architecture. Prentice Hall, 2017]. Вам, быть может, такое и не надо, но вполне можно представить текст, что нужен, а проходит мимо. Также стоит упомянуть, что некоторые книги в наличии только в бумажном качестве. Из недавних примеров [Фельдман Б.Я. От калькулятора к суперкомпьютеру. РТСофт, 2014]. Интереснейшие мемуары, а тираж с гулькин нос.
Во-вторых, иная информация такого объёма, что даже в цикл статей не укладывается, а если уложить, получится та же книга, а распиливать её на автономные клочки глупо, т.к. главы опираются одна на другую. Обычно это фундаментальные труды по фундаментальным знаниям. Примером могут служить талмуды вроде [Andrew S. Tanenbaum, Herbert Bos. Modern Operating Systems. Pearson, 2014] или [Олифер В., Олифер Н. Компьютерные сети. Питер, 2017].
Как ни крути, а лишаете себя не свежих похождений клоунов из телевизора отказом от телевизора, но профессиональных знаний.

Книга — удобный контейнер для плавного и последовательного строительства системы знаний в голове. Это давно опробованный и оформившийся формат обучения. Современная практика делит ремесленный учебник на следующие части:

  1. Введение — небольшой рассказ о том, что за текст, как его читать, что пропускать можно, а что не рекомендуется и т.п.
  2. Софт — если нужен софт, тут объяснят, как его ставить, какие версии нужны, как вообще оборудовать рабочее место.
  3. Главы основы (entry level) — в голову внедряются понятия, без которых более сложные темы не понять. Здесь же иногда объясняют, для каких целей появился объект учебника, дают немножко теории. Для языков программирования вводят понятия функций, типов данных, элементы ООП и т.д.
  4. Специальные главы (middle level) — после того, как отработали первые helloworld’ы, переходят к более другим задачам: работа с RDBMS, графика, сеть, всё такое. В некоторых учебниках эта часть построена на микропроектах, чтобы собрать на одну нитку сведения из предыдущих глав: а давайте напишем небольшой почтовый сервер, ага.
  5. Дополнительные главы — сюда авторы скидывают style guides, best practices, немножко справочной информации, нужной для книги, и всё такое.
  6. Библиография — иногда невероятно важная и полезная штука, если хотите углубиться в какую-либо тему.

Таким макаром легко изучать что-то новое. Джависту вёрстку, фронтендеру Python, джуниору SQL, начинающему пользователю ClickHouse осваивать Kafka. Т.е. нет, книга не пересказывает документацию (иначе это плохая книга, я о таких иногда гадости тут пишу), она таки даёт курс от и дальше.


Иногда книга — продукт работы автора, дизайнера, вёрстки. Сам по себе файл / бумажный том сделаны так, что усвоение информации облегчается, да и вообще превращается в удовольствие. Элементы инфографики, разрежающие вставки, пиктограммы, выделение блоками. Шедевром считаю [Jon Duckett. HTML and CSS: Design and Build Websites. Wiley, 2011], вот уж где красота.
Мне очень нравится и то, как издают учебники западные лидеры мануалостроения, так сказать: Addison-Wesley, O’Reilly, Pearson, Prentice Hall, Wiley, MIT Press. Из относительных новичков отмечу ещё No Starch Press. Ни авторам, ни издательствам не интересно, чтобы у читателя вспухла и взорвалась голова, в которую всунули гранитную плиту знаний. Интересно, чтобы книга понравилась, информация дошла, автор запомнился. Если вам кажется, что до сих пор текст подаётся так, как подавался в учебниках издательства «Наука» (и как же прекрасно на их фоне выглядели издания, которые переводил и печатал с соблюдением формата «Мир»), прекращайте. С этим нынче всё хорошо, глаза под веки стекать не будут.

Если авторы хотят текстом повлиять на мышление и дать устойчивое мнение, без объёма никуда. Люди так устроены. Вас не убедит один пример и не убедят даже пять. Ну типа да, какую-то там стачку в 1903 году разогнали залпами, поубивав народ, и шо? А если таких стачек десятки, да ещё с годами, да ещё с фамилиями, да ещё с причинами каждой? Тут и дурак задумается о том, чем булки в России пахли. Только вот все эти примеры занимают место. Хочет автор или нет, а для подтверждения своих утверждений он будет страницу за страницей исписывать текстом. Объём, объём… Нет объёма и уместить в статью? Значит, минус примеры. Значит, минус убедительность. Значит, часть читателей пройдёт мимо чего-то важного, быть может.
Примером такой книги в разработке могу назвать [Jonathan Shariat, Cynthia Savard Saucier. Tragic Design: The Impact of Bad Product Design and How to Fix It. O’Reilly, 2017]. Как показать читателю (дизайнеру, разработчику, менеджеру), что он не просто делает софт, но делает продукты, которые влияют на жизнь людей? Как показать, что ошибки могут привести к трагедии (и хорошо, если только лишь к снижению потока пользователей)? Убедит ли читателя текстик в пять страниц (столько в распечатке занимает одна среднего объёма статья блогов)? Не думаю.
Кто книги не читает, тот среди прочего не знакомится и с культурой вот такого обоснования, понижая планку качества убеждений. Не ок.

Иногда встречаю узкий взгляд на профессиональную литературу: разработчики сводят книги к сугубо техническим мануалам. Словно книги и документация дублируют друг друга. Повторюсь, если книга дублирует документацию, автор плохой и книга его плохая (любители такую фигню выпускать: Packt и Apress). Реальный репертуар же намного шире.
Во-первых, есть «культурные» книги. То, что не научит вас циклы правильно лепить, но расскажет историю того, в чём вы варитесь. Может, даже воодушевит. К персональным историям этой категории можно отнести [Linus Torvalds, David Diamond. Just for Fun. HarperCollins, 2001] или [Kevin Mitnick. Ghost in the Wires. Back Bay Books, 2012]. Истории корпораций не менее интересны: [Tim Jackson. Inside Intel. Dutton Adult, 1997]. Как и их сражения: [Fred Vogelstein. Dogfight: How Apple and Google Went to War and Started a Revolution. Sarah Crichton Books, 2013].
Во-вторых, есть мануалы не к софту или технологии, но к профессии. Пишут их вполне толковые люди, а уровень текстов… В общем, когда подобное читаю, представляю, как сижу с автором в пабе, цежу пиво, заодно слушая детальный и любопытный рассказ о том, как писать софт, как проектировать, в чём сила. Такие книги всем известны, но напомню пару примеров: [Steve McConnell. Code Complete. Microsoft Press, 2004] и [Martin Fowler с толпой чуваков. Refactoring. Addison-Wesley, 1999]. Из недавних снова упомяну задорную [Катрин Пассиг, Йоханнес Яндер. Программирование без дураков. Питер, 2017].
В-третьих, есть книги по довольно специальным темам, совершенно не укладывающимся в статью. Известные труды такого рода написаны хорошим языком, глубоко и профессионально разбирают объект по косточкам, да и просто интересные. Вот некоторые. [Henry S. Warren. Hacker’s Delight. Addison-Wesley, 2012] — распрекрасные игры с битами и байтами от аксакала индустрии. [Robert Love. Linux Kernel Development. Addison-Wesley, 2010] — интересная книга о том, как работает ядро Linux. [Jeff Duntemann. Assembly Language Step-by-Step. Wiley, 2009] — настолько доступно, толково и занятно рассказать про не самую весёлую область — автор гений.
А ещё сборники интервью [Federico Biancuzzi. Masterminds of Programming. O’Reilly, 2009] и [Peter Seibel. Coders at Work. Apress, 2009]. И классика азов информатики с 400+ customer reviews на Amazon [Charles Petzold. Code. Microsoft Press, 2000]. И взорвавшая девопсами мир [Gene Kim, Kevin Behr, George Spafford. The Phoenix Project. IT Revolution Press, 2013]. И до опупения ещё всякого. В общем, не мануалами едиными.

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

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


Как-то так. Вряд ли скажу лучше или обосную глубже, т.к. всю хоть сколь объективную аргументацию исчерпал. Для меня вопрос «зачем читать книги» звучит как «зачем быть здоровым, умным и [разумно] богатым», настолько лежащими на поверхности кажутся ответы.
Но в стопицотый скажу: вы можете не читать. Вас не заставляют. Чтение книг само по себе не делает человека умнее или глупее (если он не ребёнок, тут уже в тысячный раз упомяну [Манфред Шпитцер. Антимозг. Цифровые технологии и мозг. АСТ, Кладезь, 2013]). Как говорят наблюдения, семь миллиардов разработчиков не читали и не читают, но при этом работают, успешно зарабатывая евродоллары в кубышку. Джуниоры, сеньоры, руководители. Так зачем книги читать-то, раз всё хорошо и без них? Затем, что, быть может, всё-таки всё не так уж и хорошо. Просто достаточно.

Почему Python и Django

После ряда вопросов дополню предыдущую простынку ответами на вопросы ряда «почему [не] XYZ».
По себе знаю, профессиональная деформация меняет угол оценки людей. Если день за днём 90% круга общения могут читать исходники, упоминать big O, ностальгировать по ZX Spectrum и гадать про Эльбрус, забываешь очевидное — другим людям бывает сложно даже AND от OR отличить. Они умеют включать компьютер, гулять в интернете, писать письма. Всё. Это раз.
Программирование не является естественной деятельностью человека. Фактически никакой предварительный опыт к ЭТОМУ не готовит. Сугубо умственное самонасилие, структурирующее мысли так, чтобы после конвертированиях оных в примитивные инструкции процессора что-то заработало. Вспомните, как мучительно застывал народ перед первыми банкоматами. Итическая мощь цивилизации, какую же кнопку нажать, чтобы денег дало..? Левую или правую? Или вот эту посерёдке? Аааа, оно жужжит! Вот первый опыт разработки круче банкомата.
Короче говоря, я не сторонник фантазий о том, как из толпы выдёргивают рандомную репку и за месяц из неё куют разработчика на любом языке. Выдрессировать обезьяну, бездумно повторяющую действия по шаблону — да, реально. Остальное считаю кунсткамерными казусами, цели и нюансы которых многое бы объяснили. Ну и да, великий рандом существует.

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

  • Попасть на высокооплачиваемую (относительно другой «обычной») первую работу.
  • Удержаться год на этой работе.
  • Полученными знаниями и опытом значительно расширить выбор следующих мест и вариантов работы.

Ограничения:

  • Самостоятельная учёба. Во-первых, проверка мотивации — не тянешь, значит, не хочешь, пока-пока. Во-вторых, не тратимся на бесполезные курсы, повторяющие то же, что есть либо бесплатно, либо за весьма меньшие суммы.
  • Уложиться в год по два-три часа в день. Вполне возможно, человек уже работает или учится [на кассира в свободной кассе с высшим филологическим]. А года хватит на всё. Если потребовалось больше, что-то не так.
  • Москва. Просто трусливый выбор, т.к. понятия не имею, как джуниору найти работу в Красноярске или в Бахчисарае.

Временные затраты: при режиме будень(30м чтение + 90м практика) и выходной(60м чтение + 120м практика) получаем на год с округлениями… около 250ч чтения и 600ч практики, если я не обсчитался по производственному календарю.


Самое это самое: какой язык? Мы можем выбрать только один основной. Выбирать, понятно, топовый. Много учебных материалов, вероятность найти советчика под боком, больше вакансий и т.д.
Go и Rust отметаем — хватит и того, что работы мало. Swift мог быть вариантом, но мобильная разработка специфична и всё то же количество вакансий. C / C++… хороши, но для изначально профессиональных джуниоров, я бы сказал — многое надо знать дополнительно, на собеседовании спросят и про разный low level, а у рандомной репки беда. Ну и снова вакансий так себе. Есть ещё кластер всякого вокруг Microsoft (C#, например), но у меня в этом месте лакуна, а гадать не хочу. Может, у них всё офигительно. С другой стороны, учебной литературы на порядок меньше, да и платформа ограничивает вакансии. У Ruby всё плохо с количеством информации, вакансии тоже не очень. Остаются Java, JavaScript и Python.
Java великолепна на рынке труда. Работу найдёт даже джавист с тремя судимостями, опытом в месяц, образованием в два класса церковно-приходской в деревне староверов, глазами наркомана и повадками сомалийского гопника. Но это не язык для начинающих с самостоятельным обучением. Чтобы начать на ней писать хотя бы похоже на правильную Java, надо прям вот долго и с ментором, ещё и помнить тонну нюансов. Собсно, потому количество литературы по ней огромно, но доля учебников для самых маленьких исчезающе мизерная. Маленьким этот язык не дают.
JavaScript тоже прям сверкает вакансиями. И материала много. И в каждой щели он. И учить просто, да ещё снежинки с часиками на экране. Одна фигня: рынок JavaScript — это рынок фронтенда с редкими вкраплениями «мы пишем на Node.js« (скорее, на Ноде будете вспомогательные скрипты фронту писать). Иногда в дискуссиях с матёрыми джаваскриптизёрами начинается выдвижение списка софта на Node.js, но в сравнении с Java / Python… вышла шаланда под ГРКР «Москва». Также фронтенд со старта не учит многому хорошему (нафига снежинкам алгоритмы, например?), да и вообще ограничен в качестве вакансий. Оптимистично говоря, бекендер может вчера писать банковский софт, сегодня геймдевить, завтра машинное обучение в Hadoop ломать. Фронтендер вчера верстает страничку для банковского софта, сегодня страничку для игры, завтра страничку для админки машинного обучения. Утрирую, да. Но и нет. При этом просто знакомить с разработкой на примере JavaScript отлично.
Python достаточен вакансиями. У него всё замечательно с литературой (даже детской хватает). Его берут учебным языком в вузах — современный BASIC, чё, вона как SICP им… не подберу глагол. Он нередко приветствуется вторым языком. Переживает второе рождение в ML. Многолетние legacy на нём ещё ваших внуков пережить могут. И для простых задач он простой как ведро с краской. И, что очень важно в контексте, питонистам не надо знать ничего (заранее отключить комментарии к эссе, шоле…)! Плюсовиков погоняют по low level и OS. Джавистов по ООП, шаблонам, API и GC, придавив многопоточностью и «ну, теперь давай про базы данных». Этих, которые JavaScript, будут спрашивать про React во Vue.js с AngularJS в соусе из jQuery в Internet Explorer на семиугольном мониторе. Питонистов не спрашивают ни о чём, окромя Python и одного из фреймворков, да и тому научат. Лишь бы лапками по кнопкам нужным попадал в первый год. Ну не прелесть? А уж освоить и запомнить за год Python так, чтобы от зубов отлетал, не хитрое дело.
Потому и Python. Что, впрочем, не помешает в дальнейшем изучить другой язык, было бы желание. Ещё отмечу наблюдение из практики: очень, очень часто питонисты (как живые люди, так и резюме) — выходцы из тестировщиков, 1С, поддержки и прочих мест, в коих разработка на зачаточном уровне, если вообще есть. Python — их первый и нередко единственный язык. Они смогли, сможет и наша репка.

Подчеркну всё-таки важное. Начинающему следует не просто найти первую работу, но за два года учёбы и работы открыть себе двери в разные ветви разработки. Ведь лучше работать тем, что нравится, а не только тем, что умеешь. В Python легко войти и с Python легче пойти дальше в девопсы, в админство, в web, в ML, в сбор данных и т.д. Когда первый голод удовлетворён (ура, я пишу программы! ура, мой первый миллион [рублей]!), бывший начинающий пойдёт дальше. И вот тут должны выстрелить дополнительные знания и появившаяся привычка учиться. В этой же точке привычка быть бездумной обезьяной с сотней CtrlC/CtrlV на пальцах закроет ряд вариантов, я уверен.
А вот это не подчеркну, но отмечу [ещё раз]: разработка софта очень толерантна к разным людям разного уровня. Войти в разработку можно миллиардом путей. Если у начинающего есть явные наклонности к несколько иной ветви развития (пусть даже ценою снижения универсальности), может хоть Fortran осваивать по аудиозаписям лекций. Фишка в доступности. Запрыгнуть на первую ступеньку может любой с желанием, волей и достаточным количеством полезных клеток в черепе.
PS. Выбор Django в качестве фреймворка объясняется просто. Во-первых, в ней (нём?) есть всё для обучения, ничего дополнительного ставить не надо. Во-вторых, количество вакансий с упоминанием Django довольно велико — прям сейчас 200+, например. В-третьих, после Django освоить другое не так уж сложно.

Как заработать больше посудомойки

Твитторская вакханалия «один лайк — один факт» не обошла стороной, потому полным заголовком этого списка был бы твит «1 лайк — один твит о том, как зарабатывать больше посудомойки сетевой забегаловки в Москве». Получился вполне цельный вариант. Один из, конечно, а не единственный, но именно он мне кажется достаточно надёжным, разумным и стратегически правильным.

1. Надо меньше тратить. То, что вы экономите, не оплачивая фигню, вы пустите дальше на учёбу и работу. Как минимум, вам нужны компьютер и интернет.
2. Напишите список из десяти специальностей, которыми вам хотелось бы заниматься. Откройте сайты вакансий, найдите эти специальности и в своём списке напротив каждой проставьте минимальную зарплату начинающего без опыта. Порыдайте над результатом.
3. Оставьте все специальности, у которых устраивает минимальная зарплата. Теперь уберите из них все, которые невозможно освоить самостоятельно. Оперный певец круто, но нет. Экономист круто, но без диплома нет.
4. После этого у вас либо пустой список, либо остаётся «разработчик [программного обеспечения]». Да, это единственная специальность, которую вы можете освоить прям дома самостоятельно в разумные сроки, и войти в тусовочку пацанов, упоротых по смузи и Лондону.
5. Если у вас нет компьютера, купите. Лучше ноутбук 13″..15″, можно б/у. Главное в нём — процессор и оперативная память. Остальное пофиг, только на экран сначала посмотрите. От совсем плохих глаза вытекут за сутки.
6. Вы будете учить язык Python. Нет, не JavaScript и не вёрстку. Именно Python, т.к. только так вы дёшево для головы получите хоть поверхностное и немного ущербное, но знание разных вариантов разработки.
7. Освободите в будни 2 часа (30 минут чтение, 90 минут практика) без разрыва, которые вы обязательно используете для учёбы. В эти часы вас запрещено трогать, вы не пьёте, не тусите, не смотрите кино, вы учитесь. В выходные 3 часа (60 минут чтение, 120 минут практика).
8. Ваша первая книга [Bryson Payne. Teach Your Kids to Code. No Starch Press, 2015]. Вы ничего не знаете, она вам норм. 300 страниц очень, очень лёгкого текста с картинками. Так вы проведёте первый месяц, пробивая порог входа и набивая первые шишки.
9. На второй месяц пора ставить IDE. Это будет PyCharm CE. Неделю потратите на то, чтобы настроить, обнаружить и запомнить нужные кнопки, запустить в нём ваши ранние эксперименты. Нет, другие IDE ставить не надо. Станете старше, решите сами. Сейчас PyCharm.
10. Теперь вам надо набивать руку на микропроектиках и заполнять память языком. Ну и не помереть с непривычки. Потому [Paul Barry. Head First Python. O’Reilly, 2016]. Книга на два месяца, много картинок, язык простой, всё на пальцах, но информации больше.
11. Всё, вы офигенно крутой питониста, потому учите Django в качестве первого фреймворка. Помогут Django Tutorial, чугуниевый зад и любые книги, т.к. хороших всё равно нет. Придумайте себе простой проект (магазин вышиванок, например) и делайте его, пока не сделаете.
12. Ладно, пошутил. Вы всё ещё ничего не знаете, потому месяц поиграйте с алгоритмами и структурами данных: Problem Solving with Algorithms and Data Structures using Python Хоть базовое, хоть простое, но в голову должно войти. Если не войдёт, вас никто не будет любить так, как надо.
13. Отворачиваемся от Python, смотрим на базы данных. Берём книгу [Thomas Nield. Getting Started with SQL. O’Reilly, 2016] и прорабатываем её всю от обложки до обложки. На неё у вас должно уйти 2..3 недели, не больше.
14. Если ещё почему-то не, заведите аккаунт на GitHub и перевезите все свои поделки на него. Да, они ужасные и корявые, никто не будет читать, всем пофиг, а вам надо освоить git. Пусть уйдёт неделя.
15. Отдых! Читаем [Катрин Пассиг, Йоханнес Яндер. Программирование без дураков. Питер, 2017]. Весёлая и толковая книга, заменяющая будущим джуниорам более серьёзные труды. Выделяем на неё месяц. Читать вдумчиво, осмыслять, примерять к прошедшим месяцам.
16. Чарующий мир красивых страничек со снежинками откроет книга [Jon Duckett. HTML and CSS: Design and Build Websites. Wiley, 2011]. Ей семь лет, она знатно устарела, но я не знаю более крутой, красивой и доступной книги, вводящей в вёрстку. Полтора месяца, наслаждайтесь.
17. После отдыха и красот вернёмся к пункту 11. Django и маленький магазин чего-нибудь. Чтобы база данных была, странички и всё прочее. Вы всё равно напишете фигню, но старайтесь. Не ленитесь возвращаться к раннему материалу. Один месяц.
18. Прошло 8.5 месяцев. Отдохните. Топайте на HackerRank и прорешайте там задачки из всех областей, на которые вас хватает. Заодно подтянете снова забытое, набьёте пальцы на новом. Две недели.
19. Теперь важное. Вы должны понимать тестирование своего кода и уметь. Без этого вы мина под попой, а не джуниор. Упорно осваиваем [Harry J. W. Percival. Test-Driven Development with Python. O’Reilly, 2017]. Полтора месяца. Книга годная, в ней не только про тестирование есть.
20. Ожидаемый пункт: обложите тестами свой магазин вышиванок. Все триста ошибок надо будет исправить. Потом те сто, что появились из-за исправлений. Две недели.
21. Теперь думаем (наконец-то). Что больше нравится, страницы верстать или остальное? Выбор между фронтендом и бекендом. Погуглите про эти специальности, подумайте много раз. Они разные. Сразу развивать обе надорвётесь. Если выбрали бекенд, читаем дальше.
22. Идём на HeadHunter, ищем Python junior. Выписываем из требований всё, что вы не знаете, сортируем список по кол-ву вакансий. Если в 10 вакансиях слово «MongoDB» попадается 10 раз, вам есть куда развиваться. Ещё пару месяцев учите то, что сверху списка.
23. Переписывайте магазин вышиванок с использованием максимального кол-ва технологий, требуемых в вакансиях Python junior. Не забываем про тесты. Ну… Ещё месяц. По пути добавляйте в магазин фенечки. Корзину, письма заказов, рекомендации нейронной сети (хаха) и т.п.
24. Неделю отдыхайте, потом тридцать три раза вылизывайте код магазина. Это ваш magnum opus, который покажете и будете защищать на собеседованиях, если захотят посмотреть на исходник. Оформите проект так, как делают крутые пацаны — изучите чужие проекты, ту же Django.
25. Теперь соберите ВСЕ вакансии Python junior, которые хоть как вас втискивают (если от джуна ждут 5 лет опыта, вы не). Разделите на три части: «не хочу», «фиг знает», «хочу». Идите на собеседования к первым. Смысл в получении опыта собеседований, а не в офере.
26. Вам причинили боль, унизили, показали, что вы на дне знаний. Это обычно. Главное не хлопать ушами и запоминать, что спрашивают. Чем частотнее вопрос, тем лучше, значит, модно сейчас. После этой стопки учите то, отсутствие чего выявили собеседования. Для того и ходили.
27. Иди во вторую часть списка. Тот же алгоритм действий, но вы уже морально готовы и знаете больше. Если не тупили за год, один-два офера получите. Это запасной вариант, к нему можно будет вернуться, если не спешно давят с наймом (что подозрительно).
28. Третья часть списка интересная. Многие годные вакансии от джуна чудес не ждут, окромя «уверенного» или «хорошего» знания языка. Ну т.е. фиг с опытом, но заучить синтаксис и библиотеки мозгов должно хватить, иначе смысл. Потому пока мы туда не идём.
29. Две недели вы готовитесь. А именно учите Python снова, но по взрослой книге: [Alex Martelli. Python in a Nutshell. O’Reilly, 2017]. Даже не учите, но выбираете из неё то, что забыли, не выучили раньше, не поняли и т.п. Книга-справочник.
30. Топайте на собеседования в третью часть списка. Выспитесь. Отдохните. Не напрягайте нервы. Все знают, что вы джуниор. Если память не дырявая, слова складывать умеете и что-то осмысляли, а не только зубрили, оферы у вас будут. От 50К до 100К в зависимости от.
31. Главная задача — проработать не меньше года. Учитесь работать как вообще, так и в коллективе. Берите все знания, что дают. Это будет адовый год работы, учёбы и «я тупое ничтожество и ничего не умею». Это нормально. Вы ничего не умеете. Учитесь уметь.
32.0. Также вы должны продолжать накачиваться книгами. В них системные знания, они трамплин для дальнейшего освоения. Важно понять и принять, что вы пока junior junior, а не junior. Очень мало знаний про OS, базы данных, шаблоны, архитектуры, компьютеры, разный нужный софт.
32.1. Потому читаем. Python: [Mike Pirnat. How to Make Mistakes in Python. O’Reilly, 2015] — полезная брошюра, старая [David Beazley, Brian K. Jones. Python Cookbook. O’Reilly, 2013] и новая [Steven F. Lott. Modern Python Cookbook. Packt, 2016] для мелких хинтов.
32.2. Потому читаем. Эрудиция: серия In Seven Weeks попсовая, но даст вам понять, что мир сложнее и многомернее. Попробуйте [Luc Perkins, Eric Redmond, Jim Wilson. Seven Databases. Pragmatic, 2018] и [Paul Butcher. Seven Concurrency Models. Pragmatic, 2014].
32.3. Потому читаем. Linux: [Christine Bresnahan, Richard Blum. Linux Essentials. Sybex, 2015] — чуть устарела, скучновата, но простым языком для самых маленьких. Пробить порог входа, а дальше уже крутиться, как получится. Без Linux вы будете страдать, потому надо, надо.
32.4. Потому читаем. Классика: [Charles Petzold. Code. Microsoft Press, 2000] — очень доступная книга о битах, байтах, кодах и т.п. Я б её школоте в информатику добавил. Если вштырит, читайте [Henry S. Warren. Hacker’s Delight. Addison-Wesley, 2012] — брулянт, а не книга.
33. Всё. После года учёбы и года работы вы должны понимать, что вам нравится, в чём вы сильны, а в чём слабы. У вас год опыта в трудовой, что открывает двери к вакансиям, на которых не хотят учить малышей (потому ставят лимит в год+). И да, зарплата посудомойки 30К. У вас больше.

При чтении этого списка надо помнить следующее: список для тех, кто прям совсем нулевой. Не выпускник годного физмата с опытом трёхлетнего фриланса, например, но человек, который только пользуется компьютером, но хочет попробовать пользоваться им круче, да и вообще уехать в Дублин или Лондон кошмарить тамошних CEO от Google и Facebook. Также должно быть понятно, что таким новичкам не надо давать читать Кнута, Мартина (он лёгкий и клёвый, но слишком много спорного), Макконнелла, Дейта и т.д. В голове у начинающих и без того каша, а такими снарядами только волю к жизни убивать в первый год этой жизни. Станут старше в специальности, тогда и осилят. Наконец, текст выше про ремесло. Так не получить конструктора, инженера, изобретателя за год. Получится боец, умело красящий заборы или таскающий мешки с песком в нужные для мешков места. На старте больше и не требуется.
PS. Ну и да, всё станет интереснее, если вам будет помогать знакомый разработчик. В идеале муж или жена, чтобы можно было ночью разбудить и красными глазами напугать. Дерзайте, в общем. У девяти уже к третьему месяцу азарт пропадёт, а вот один прорвётся к финишу.

Памятка рекрутеру

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

Во-первых, не надо мне звонить. НЕ НАДО. ЗВОНИТЬ НЕ НАДО, БЛИН ВАШУ. Разговор голосом в отношениях «разработчик vs рекрутер» — это финальная стадия отношений, не стартовая. Во время вашего звонка я могу быть фиг знает где, услышать фиг знает что (если вообще захочу), вы всё равно весь текст вакансии мне не расскажете (а если расскажете, я треть не услышу) и т.д. Внезапно звонящий рекрутер звучит как стопицотый телефонный спамер, вносимый в чёрный список, не более. Если у вас есть мой номер телефона, у вас должен быть и email. Как вы, блин, вообще представляете себе процесс? Оу, звонит незнакомая девушка, тарабанит два-три предложения, а я «уря! хотеть к вам сходить прям сейчас вечером нет сейчас хотеть берите аааа»? Нет, правда?
Во-вторых, читайте резюме. Рекрутер, предлагающий мне вакансию фронта, изумляет до невозможности. Рекрутер, спрашивающий, какой у меня стаж и опыт, тоже. Рекрутер из Екатеринбурга, удивлённый «ой, а вы не в Е.?», удивил взаимно. Вы потратите пять минут на человеко-кандидата, но избежите кучи нелепостей, после которых у разработчика подозрения, что всё у них так, потому нафиг надо.
В-третьих, почта. Офигенное изобретение человечества, позволяющее рекрутеру дать мне 1) много нужной информации, 2) возможность вдумчиво исследовать вакансию. Погуглю контору. Посмотрю на карте офис. Прикину требования к себе. Вдруг у меня знакомые есть в конторе, им напишу, спрошу. Вот только после этого процесса что-то внятное отвечу. Не потому, что я сноб и зануда (хоть я сноб и зануда). Потому, что вакансий много, рекрутеров много, у меня есть выбор. Если рекрутер не осиливает в этот выбор доложить свой лист текста, для меня это точно не трагедия, просто я не нужен этому рекрутеру, а этот рекрутер мне.
В-четвёртых, общение, личность, социализация, всё такое. Пункт со звёздочкой, да. Письма из шаблона убогие («Уважаемый(я) Сергей», ага). Рекрутер, общающийся не со мною, но с анонимным ресурсом, от найма которого рекрутер получит копеечку, скучен и ничем не выделяется на общем фоне. С таким же успехом могу HeadHunter полистать. Особенно несчастно выглядит на фоне рекрутеров, с которыми сложились товарищеские отношения. Разница в том, что они начинали не шаблоном. Попробуйте написать простое человеческое письмо. Не надо стихами, не надо клоунады. Простое человеческое. Можно даже без полной вакансии сразу. Устроит «Сергей, привет. Знаю, что не в поиске работы, но не считаю лишним обменяться контактами, если вы не против. Вы всё так же джавист, специализацию не сменили?» и т.п. Я общительный и отвечу. А рекрутер мне ответит. А я. Но вот именно с человеческим общением у рекрутеров не складывается, сплошной равнодушный поток.

А так-то ребята и девчата нужную работу делают, аки пчёлки, цветочки опыляющие.

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

То, с чего началось: «Не надо писать в резюме опыт работы с базой 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 и вообще содержание кода в постоянной чистоте — оно тоже приобретается не сразу. Да, мастер должен всегда собираться. Да, должны быть тесты. Да, документация. Да, это мусор. И это. И вон то тоже мусор. Да, эта тысяча строк нафиг не нужна, блин, убери уже говно из-под ног, в автобус зайти невозможно без противогаза. Чем дольше разработчик работает, тем больше он видит примеров отдалённых косяков из-за всяких «и так сойдёт», «а что такого» и классического «я потом уберу!» Соответственно, если не рандом в черепе, у шестилетнего Пети код будет хотя бы чище, чем у двухлетнего Васи.

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

Мои учителя

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

Ваня (мой первый лид) смотрел с недоумением. Мне было 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. Ну и да, у всех (кроме Евлампия, Ефима и Егора) прошу прощения. До того, как стать умным, я был глупым. Жаль, что вы при этом присутствовали и вынуждены были из меня эту глупость своим примером изгонять. 🙂