Мои учителя

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

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

Хорошие люди

Последние года 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К). Прикинуть, с какой командой и какой стартап хотя бы в теории может выжить в период разработки. Всё просто считается. Ну а потом ещё раз перечитать список и прикинуть, что такое хорошо, что такое плохо.

Категории RDBMS

Вариантов разделения RDBMS на категории много. Зайду с позиции практики и выбора базы на тыщу лет вперёд.
Сначала три постулата.
Во-первых, базы данных — это давно не только лишь SQL и «сделать пару запросов». Оно как внутри теперь напоминает на картинках город (погуглите [oracle 12c architecture diagram], красиво нарисовано), так и по обилию возможностей потрясает (слово сильное, но меня именно оно). В современном мире вы можете почти всю логику приложения сделать на стороне базы, снаружи оставив лишь тонкого клиента.
Во-вторых, при выходе за рамки простых SELECT вы теряете совместимость (возможность легко сменить одну базу на другую). Так же и в инфраструктуре — едва начинаете активно использовать средства репликации, мониторинга, бекапа и т.д., вы снова привязываетесь к определённой базе. Соответственно, едва выходите в production, вам с этим жить долго и счастливо.
В-третьих, если последние два года вы не следили за прогрессом в RDBMS, вы зря. Пересмотрите changelog’и, актуализируйте информацию в голове. До сих пор живы разработчики с мантрой «PostgreSQL не умеет в репликацию», это скучные разработчики, фу.
Так вот. Категорий тоже три.

Платформы. Вы большой и толстый энтерпрайз с большой нагрузкой, десятками схем, тысячами таблиц. Вам нужна RDBMS, которая всё это потянет, а также даст определённые гарантии по SLA и по живучести данных. И чтобы система безопасности была страшнее руководителя безопасников. И чтобы админы не стрелялись, ворочая этой махиной. И чтобы можно было данными оперировать с разных направлений (корпоративные порталы, бухгалтерия, админки, импорты/экспорты и т.д. — всё это отличающиеся по трудозатратам задачи). И вообще чтобы всё. Ой, и чтобы облака. И чтобы RDBMS as a service. И документации целый шкаф. И чтобы интегрировать можно было до бесконечности! И чтобы регулирующие и дестабилизирующие органы по своим ГОСТам принимали! И вон тот кусок поля под помидоры!!!
На этом рынке рулили три монстра: Oracle (Oracle Database), IBM (IBM DB2), Microsoft (MS SQL Server). С некоторых пор их двигает PostgreSQL, который выгодно отличается стоимостью поддержки, динамичнее развивается и вообще «бесплатен» при наличии энтерпрайзных возможностей.
Если угодно, это категория RDBMS уровня предприятий, где предприятия — заводы, банки, гос.учреждения и прочие масштабные ребята. Для эффективного использования требуется специально обученный персонал. Масштаб на конкретном примере: переход Я.Почты с Oracle на PostgreSQL — обратите внимание на объём данных, на RPS, на железо.

База как база. Собственно, то, с чем работает большинство разработчиков. Если у вас сайт как сайт, продукт как продукт, а то и просто надо какие-то данные где-то хранить, но от MongoDB слегка тошнит, да и честный ACID нужен, выбираете… правильно, MySQL (вместе с InnoDB, например). Справедливости ради, MySQL из штанишек вырос давным-давно. Крайне богатый SQL, нагрузку держит отлично, скорость работы вне претензий, стабильность тоже норм.
Почему не «платформа»? Давайте сразу: Oracle не будет выращивать конкурента своему платному продукту. Не будет никакого MySQL EBS, не будет MySQL Forms, умеющих работать с PM/SQL, которого тоже не будет. Вообще много чего не будет из энтерпрайза. Вы хотите хранить охрениарды данных и быстро работать с ними? Ок, вот MySQL. Вы хотите вокруг этих данных с плотной интеграцией разных частей выстраивать орбитальную станцию и продавать в аренду марсианам? Ну, если времени много и нервы титановые, у вас это получится (и получается, да). Но следующее поколение после вас покрутит пальцем у виска и ВСЁ ПЕРЕПИШЕТ.
Важно понять следующее: нет смысла сравнивать MySQL с другими в области хранения и получения данных. Он норм для этого, по иным бенчмаркам лупит ребят сверху. Проблема как его, так и в категории (в которой у MySQL нет конкурентов) начинается при выходе за границы этих потребностей. Это вот та точка, на которой постоянно буксуют джихады MySQL vs PostgreSQL. Вроде и по скорости равны. И SQL везде клёви. И так обе могут, и эдак. Да что ж за нафиг, почему одни после research’а выбирают одно, а другие другое? Да вот ровно потому и: при выборе стратегической RDBMS рассматриваются не только скорости и диалекты. И вот ровно тут MySQL так у границы топтаться и будет.
Категория RDBMS уровня небольших предприятий, одного продукта. Или огромного продукта для хранения данных без особой логической нагрузки (иными словами, половина приложения не на стороне базы в виде процедур и функций). Для эффективного использования… Тут тяжело. Все считают, что знают MySQL, простота LAMP в наших сердцах. По факту мало кто использует именно MySQL, лишь разворачивают быстренько, слегка тюнят, потом обстреливают простыми запросами. Им хватает. А так-то MySQL — сотни страниц документации и сотни features.

Базёнки. Маленькие и/или встраиваемые RDBMS. Тут веселее: SQLite, Firebird, Derby и т.д. Типичное применение — local storage в Google Chrome, туда SQLite воткнули.
Няшные тем, что кушают очень мало ресурса, но при этом вполне толковые. Понятно, что нагрузку на них не пустишь, ожидать серьёзную репликацию и failover тоже не стоит, но для своих целей всё давно уже хорошо заточено.
Категория… ну вот какая? Если вам требуется маленькое встроить или рядом поставить, но при этом чтобы не требовалось админство-админство. Пусть будет «категория RDBMS уровня модуля приложения». Квалификация персонала — встроить и забыть.

Вот как-то так. Деление условное, простое, но достаточное, чтобы включить размышлялку и подумать о том, как правильно выбирать RDBMS, на что повлияет выбор, на какие качества базы смотреть.
PS. Любопытно ещё следующее на фоне фанатских войн… Любая RDBMS что категории «платформа», что «база как база» — сложный насыщенный продукт. Споры разработчиков о том, что лучше — зачастую споры людей, которые понятия не имеют, какой уровень SQL поддерживается, при каких условиях какие lock’и и на чём, как конкретно работают виды репликации, какие особенности шардирования и т.п. Большинство из вас не использует MySQL или PostgreSQL. Вы используете условную RDBMS, в которой вам интересно малое подмножество SQL (ну откройте спецификацию языка и скажите, действительно ли вы его знаете), ну и сверху ещё несколько шняжек, с которыми у вас получилось работать. С остальным сталкивается эксплуатация (которая тоже не всегда может выделить из своих рядов специалиста), а также бойцы, которые пытаются иногда выйти за рамки «стандартного SQL». Но и среди них редко встретишь полноценного DBA, прошедшего полноценное [само]обучение по продукту (у которого 3500+ страниц документации, например). Потому споры эти бестолковы и смысла не имеют, только бы совочками помахать.

О сертификациях

К сертификациям в разработке отношение сложное. Как 15 лет назад мы с недоумением смотрели на коллегу, который сдал пару Java-экзаменов, так и сейчас в наших краях оно вроде как и бесполезно, да ещё и дорого, три экзамена — топовый смартфон, ага.
Что любопытно, на Западе и на Востоке всё диаметрально иначе. Если речь идёт о вендорных дипломах (Oracle, Microsoft, Cisco, Amazon и т.д.), статистически вы заметно повышаете свой доход. А уж админы и NOC’и без сертификаций… скажем, приветствуются далеко не везде. На деле у них чуть ли не на порядок (относительно разработки) всё это развитее, особенно если с Cisco работать.

Итак, вы простой советский разработчик в размышлениях «а нафига». Вот мои ответы мне на эти «нафига». Собирал и осмыслял много лет, пока не собрал критическую массу, после чего сдвинул жопу с тёплого стула. Внимайте.
Во-первых, мотивация выучить то, до чего иначе руки не дотягиваются. Девять из десяти разработчиков знают области разработки на уровне «знаю только то, что применяю в своей работе на ПупкинСофт Ltd». Мне это стыдно и скучно, но всё равно не хватает пинка, чтобы вернуться к азам. Провалил экзамен — выбросил в окно 7 ящиков шотландского эля — жалко, блин. Лучше выучу.
Во-вторых, в процессе подготовки узнаёшь много интересного и немало полезного. У вас не получится тупо зазубрить ответы на билеты, т.к. билеты не публикуются. Приходится зубрить темы целиком, что приводит к просветлению головы и автоматическому повышению квалификации. Заодно это хорошее лекарство от избыточной самоуверенности, спеси и зазнайства. До подготовки ты крутой и всё знаешь, а тут вдруг того не знаешь, этого, сего и ещё про вон ту конструкцию даже не догадывался. Поневоле задумаешься о том, сколько раз за годы на основе такого невежества озвучивал совершенно идиотские суждения.
В-третьих, лидам полезно самим пройти распространённые сертификации из их области, чтобы объективнее оценивать наличие сертификатов в резюме. Как минимум, сможете сократить или упростить собеседования, что на потоке уже хорошо.
В-четвёртых, весь мой опыт говорит следующее — вы никогда не угадаете, какая бумажка вам поможет в будущем, но совершенно точно ни одна позитивная бумажка о ваших достижениях не будет лишней (ну, помимо диплома о первом месте на поселковой олимпиаде по информатике). Выстрелить в вашу пользу может в совершенно случайный момент. Да даже тем, что у рекрутера глаз зацепился и ваше резюме легло на верх стопки — уже это может сдвинуть жизнь на 90 градусов.
В-пятых, сертификаты действительно показывают профессиональный уровень их владельца. Да, там много наивных вопросов. Да, задачи бывают идиотскими. Фигня в том, что многие разработчики не могут ответить на эти вопросы и не могут решить эти задачи. Люди, может, и хорошие, но на Python-собеседовании на 10 минут уходят в себя, не в силах вспомнить, есть ли в языке тернарный оператор. И если я увижу в резюме хотя бы entry level сертификат (обычно они про синтаксис), я буду знать — этот боец знает, где какой оператор.
В-шестых, однажды вы можете мигрировать. Я минут тридцать ради fact checking листал job-сайты США и всё так же вижу много вакансий, в которых так или иначе, но варианты следующего: «Must possess at minimum an Oracle Certified Associate Java SE x Programmer certification or must obtain an Oracle Certified Associate Java SE x Programmer certification within 120 days after hire». Да, обычно это крупные бюрократизированные конторы. Но вы уверены, что уже через год от переезда нанявший вас стартап не развалится и вы не будете лихорадочно искать любое место?
В-седьмых, сертификации и сертификаты — объективная часть мира разработки. Никого не волнует ваше мнение о том, нужны ли они, полезны ли они, что они показывают и т.п. Они есть. Через них прошли миллионы разработчиков. Они влияют на оклады, на контракты, на собеседования. Вы либо принимаете правила игры и хоть ознакомительно осваиваете этот угол ринга, либо бестолково бунтуете, отрицая, либо равнодушно игнорируете, пока не столкнётесь. Как по мне, мудрее ознакомиться до того, как возникнет нужда.
В-восьмых, наконец, это fun. Не, правда. Годный вариант отойти в сторону от рутины и вспомнить, что такое учебники, билеты, экзамены, волнение «сдал? завалил?» Мне понравилось. Теперь точно буду в год хоть по два сертификата получать, чтобы развлечься.

Итого… Ну, понятно, что я в основном вижу лишь плюсы. Правда, важно помнить главное: сертификация — она для вас, она в ваших интересах, она решает ваши задачи и проблемы. Вас не будут носить на руках на следующий же день от сдачи, не будут на собеседованиях чествовать красной дорожкой. Это стратегический вклад кирпичика в вашу стену специалиста. Без остальных кирпичиков (интеллект, дисциплина, множество знаний из разных областей, трудолюбие и т.д.) не стоит ничего.
PS. Подчеркну: речь не про Курсеры и Брейнбенчи, речь про те экзамены, которые вы сдаёте производителям софта / железа, получая сертификат соответствия знаний стандартам производителя.

О жизни после 30

Раз за разом сталкиваюсь в сети с копипастой мнения о том, как трудно после 30 лет (или 35, или 40, да любое приятное глазу число) найти работу программистом. Даже бывают интервью со «старичками», мол, расскажите, как вам живётся-то, уникальные существа.

За последние лет пять я пару раз поднимал руку в режиме «свободная касса», ну и вообще был открыт предложениям даже из исследовательского любопытства. Безусловно, те, кого смущал мой возраст или потенциальный overqualified, не писали письма и не звонили. В то же время писавших и звонивших было много. Одна рекордная неделя словила в себя 20+ вызовов на собеседование. География: Россия, Украина, Латвия, Польша, Германия, США, Ирландия, Англия, Австралия, Вьетнам, Япония.
Так на что всё-таки влияет возраст? На него примеряют рабочий стаж и типичные рабочие пути развития. Если разработчик в 40 лет знает только один язык и только одну RDBMS, это странно. Если разработчик в 20 лет знает десять языков, пять RDBMS и пять NoSQL, это смешно (да, самые богатые на buzzwords резюме — резюме студентов). Если к 50 годам ни разу не был teamlead’ом, это интересно (не может или не хочет или не было возможности — выясняется на собеседовании). Также [условно] 30+ лет — это повод на собеседовании отдельно проверить, не выгорел ли, не устал ли от профессии, остался ли ещё задор и запал (об этом ниже).
Есть большой соблазн закрыть глаза на объективные (или важные субъективные) причины того, что вы кому-то куда-то не подходите. Внезапно да, чем больше стаж, тем большего от вас ожидают. Тем с бОльшим интересом читают резюме. И собеседуют не про таблицу умножения. И на позицию джуниора не возьмут, пусть вы туда и захотите. К вам выше требования, т.к. человек, который за 10+ лет опыта работы по специальности не нарастил знания и умения до этих повышенных требований, вызывает оправданные сомнения.
Есть ещё категория граждан, у которых проблема не с возрастом, но с затвердеванием и унылостью сознания. Человек устал. Или выгорел. Или осознал, что разработка не его, но идёт по инерции и кушать привык. Или отвык учиться. Молодым на азарте выучил, освоил, по накатанной как-то телепался, а груз невыученного уже тащит ко дну. Или закостенел в самодовольстве «я и так всё знаю, ничего не надо» (привет чувакам с Java 1.6 и Python 2.7). Да, на то, чтобы так сформировался взгляд на мир, потребовались те 10+ лет. Но проблема-то не в возрасте, а во взгляде. И собеседующий, созерцающий вас, тоже всё это видит, если не пофигист.
Ну а если вас куда-то ну совершенно точно не взяли из-за возраста (и это не экспедиция на Марс), уверяю, вы в таком месте и сами не захотите работать, там неумные. Например, у них молодой и энергичный коллектив 20-летних звёзд эстрады, а тут ты со своей постной физиономией. Непорядок.

Можно возразить, что это мой личный опыт, у других иначе и т.п. Слава духам, как было на старте карьеры много знакомых, так и осталось. Десятки, если не сотни, людей, которые как тогда были сверстниками, так ими и остались. Большинству 30+ лет. Почти все, кто хотел, работают. Кто разрабами в окопах, кто лидами. Многие разбросались по миру. Вроде бы ни у кого не было явно выползшей проблемы из озвученных выше. Да, оно могло быть под ковром, да и не все мне всё рассказывают. Но такая фигня вызвала бы достаточно много смеха и лулзов, чтобы всплыть.
PS. Сегодня по Skype первично собеседовал разработчика. Ему 40 лет и у него всё хорошо.

Тимлид в трёх лицах

Одна из вечных тем — что такое [хороший] teamlead? И вечные споры и дискуссии. Как водится, у меня своя точка зрения. Тимлид — набор из трёх ролей, который может быть хорошим в одной ситуации и плохим в другой. Эта неоднозначность и небинарность является, как считаю, причиной споров.

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

  • Открыть рот и связно озвучить мысли так, чтобы было понятно, о чём речь. Без этого выше табуретки никак.
  • Открыть рот и звуками убедить кого-либо в чём-либо так, чтобы этот кто-либо понял, захотел, сделал. Первый шаг к тимлиду.
  • Подбор подходящих коллективу людей. Не запихивать тихонь в клетку с тиграми, не топить тигров в пруду тихонь.
  • Выслушивать. Очень важное умение, дающееся не всем. Слушать не себя, не перебивать, запоминать слова, интонации.
  • Объяснять, почему повышают или не повышают. Не самая приятная обязанность, но надо.
  • Донести критику или одобрение. Как, собственно, самому уметь принимать как одно, так и другое.
  • Управлять конфликтами. Они были, есть и будут. Люди не травоядные и некоторая доза конфликтов даже нужна. Задача психолога не допустить их перехода в системную проблему.
  • Определять человеческие факторы производства и понимать, что с ними делать дальше. Вася апатичен и вяло работает? Почему? Он изначально такой или есть внешняя причина? О, так он сова, а его запихнули в жёсткий утренний график. Давайте попробуем его на вторую половину дня. Попробовали, Вася начал отжигать напалмом и повеселел.
  • Внедрение мотивации в членов команды. Федя слабо работает. Если Феде доходчиво объяснить цели, выгоды и соответствие работы ценностям Феди, он будет работать сильнее. Или не будет. Феди всякие бывают.

Тимлид работает с командой и организует команду. Команда — люди. Человек, у которого психолог на нуле или даже в минусе, успешным тимлидом быть не может. Это просто невозможно.


Логистик (процессы). Понимание и выстраивание процессов производства. Спектр задач тут большой и включает в себя много всякого разного ранга: схема статусов у тикетов согласно проекту, элементы CI, распределение зон ответственности, протоколы безопасности, чеклисты реакции на мониторинг, организация нужных встреч, контроль планов и само планирование, и т.п., и т.д. Фактически всё, что является дорогой между пунктами A (задумка продукта) и Z (продукт в production’е).
По сути это навык организации, который начинается с самоорганизации. В какой-то мере тоже личностная характеристика в основе. У человека должно быть стремление к упорядочиванию окружающего, да и внутреннего. Чёт не верю я в раздолбаев, успешно спроектировавших и построивших сборочный цех софта. Подчеркну — речь о повторяемом процессе, а не про одноразовый [случайный] win.
Примеры типичных задач:

  • Организовать коммуникации внутри команды и команды с внешним миром. Живые встречи, каналы мессенджеров, рассылки, знакомство людей друг с другом.
  • Организовать отчётность (срезы статуса) как по отдельным задачам, так и всего в целом. В любой момент должно быть понятно состояние системы.
  • Организовать инфраструктуру производства. Где разработка, где тестирование, где боевые сервера, где сборочные фермы и т.п.
  • Определить зоны ответственности. Не должно быть кода, серверов, задач и любого иного, над чем не стоит конкретный человек с пониманием, что это его песочница, за успехи в которой хвалят, за поражения ругают.
  • Спланировать разработку продукта. Ох, планирование, да. Отдельная огромная тема.
  • Определять и убирать слабые звенья. Например, регулярные формальные встречи, на которых все зевают или играют в Тетрис под столом.

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


Специалист (разработка). Глубокое знание предметной области, контроль качества реализации продукта. Пожалуй, самая очевидная и самая распространённая роль из-за обычая брать тимлидов из среды разработчиков.
Хоть я ниже допускаю вариант слабого специалиста (и его компенсации) в тимлидах, но это больше теория. На практике всё сложнее. Если тимлид тотально слабее в матчасти своих бойцов, он не может выполнять чуть ли не половину функций — не научит, не проверит, не проконтролирует. Как если первоклашку поставить ведущим разработчиком на уроках матана девятого класса, много он там со своими счётными палочками наводит, ага.
Но есть ещё нюанс. По миру ситуация меняется, а вот на просторах xUSSR команды разработчиков всё ещё в массе мужские со всеми приметами мужского коллектива. Разработчики не будут уважать тимлида, если он не является в какой-либо смежной области заметно более сильным специалистом. Не примерно равным, но заметно более — это важно. Может, всё-таки и будут, но не как разработчика. А без уважения всё становится сложнее. Хочешь не только по трудовой быть тимлидом? Изволь спросонья озвучить лекцию по булевой алгебре и вариантах рекурсии. Нет? Удачи.
Примеры типичных задач:

  • Разработка софта. Если программист не программирует, он теряет квалификацию.
  • Определение стратегии технического развития. Примитивный пример: вводить ли в стек новый язык?
  • Определение квалификации членов команды. Надо понимать, можно ли давать Петрову задачу по проектированию схемы данных из ста таблиц или Петров не знает, что такое primary key (очевидно, сам тимлид должен быть на уровне задачи).
  • Подтягивание квалификации членов команды. Как быть ориентиром (наш Вася крутой, я хочу стать крутым, учусь у Васи быть Васей), так и микролекциями, литературой, дискуссиями, кодом и т.д.
  • Ревью кода и решений. Тимлид должен понимать и уметь в хороший код, чтобы контролировать создание оного членами команды.
  • Обеспечение или контроль инфраструктуры производства и продукта в рамках компетенции. Оптимально ли настроена база данных? Те ли типы инстансов в облаке? Куда и как складываются логи? Почему так долго собирается билд?

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


И вот тут проблема: людей, совмещающих в себе все три роли на высоком уровне, [почти] не бывает. Хотел бы сказать, что их вообще нет, но остерегусь, мало ли. Общение с компьютером с детства развивает специалиста, но не способствует росту психолога. Психолог развивает с друзьями модные soft skills, пока на полке пылятся так и не открытые учебники по программированию. Логистик рождается в муках опыта, наблюдений, размышлений и снова учёбы.
Я пока видел только два действительно работающих способа решения.
Во-первых, в Яндексе боевые пары, которые забавно напоминают ролями семью. Менеджер (часто девушка) — психолог+логистик, тимлид (часто мужчина) — специалист+логистик. Соответственно, вдвоём они представляют собою универсального лида. Менеджер (мама) утирает слёзы, смягчает конфликты, обеспечивает социализацию команды, организует логистику продукта, организует само понимание продукта (а то эти роботы без тени сомнения напишут двумерного коня в кирпичном эфире), служит посредником между командой и внешним миром, напоминает команде о пользователях, вообще душа и человечное лицо команды. Тимлид (папа) организует разработку проекта, карает и поощрительно трогает плечо, сам укладывается под танк на амбразуру авралов, укладывает других, корректирует планы согласно уровням разработчиков. Если сработались, результат офигительный. Если нет, всё идёт на дно и по дну, в чём и риск такого варианта относительно единоличной диктатуры.
Во-вторых, подбор команды под тимлид(а|ов). Если нет умения или желания возиться с психологией, набор зрелых взрослых людей без явных проблем с головой — это делает ненужным развитого психолога. Если слабый специалист в лидах, набор строго сильных разработчиков, которых не надо контролировать или выращивать — лиду достаточно не вмешиваться. Если проблемы с логистиком, набор опытных (сильные не всегда опытные, потому набор выше из другой оперы) разработчиков, они сами организуются — слабый логистик там же и обучится.

Стремящийся стать хорошим тимлидом понимает свои слабые и сильные роли. Плохой не понимает.
Плохой психолог устраивает показушные игры в «давай поговорим» или «вы можете подойти ко мне с любым вопросом». Хороший и так знает / чувствует, что происходит, а с вопросами к нему и без напоминаний подойдут. // Я, к слову, фиговый психолог, но все и так знают, что злобное бревно. Компенсирую тем, что пытаюсь выстроить процессы, при которых в психологе нет нужды — ясные правила поощрений, тщательный подбор адекватной команды, прозрачность всей работы всех и т.п.
Плохой логистик тащит всё хайповое как сорока в гнездо. Вчера у нас был водопад, сегодня скрам, завтра коворкинг на хакатоне с интенсивным митапом тренеров по TDD без ТЗ. Другой вариант плохого в силовом напяливании идеалистических схем на неподходящий коллектив. Да, отверстие круглое, а болт квадратный, зато я сильный. Хороший делает так, что именно эти люди делают продукты именно этой категории максимально эффективно с учётом ротации кадров, фазы Луны и законодательства Гаити. Если не получается, оставляет всех в покое и смотрит, какую схему выработает команда — сначала смотрим на народную тропинку, а потом на её месте асфальтируем дорожку.
Плохой специалист всем просто мешает. Арнольд два дня оптимизировал тяжёлый запрос к базе, а тимлид зарезал, так как не понял текст запроса (ридабилити пострадало! скорость нинужна!). Плохой специалист не может аргументировать решения, потому тупо насаждает свои субъективные вкусы. Хороший специалист не мешает команде, особенно если команда решает задачу по результату лучше, чем сам смог бы. Также он каждое своё решение объясняет так, что решение становится очевидным. В конце концов, если чего не знает, так и говорит: да хрен его знает, разберитесь сами, потом меня научите.

Безусловно, всё ещё сложнее на пару порядков, всегда есть исключения и всё такое. Но мне схема выше удобна простотой и практичностью модели, от которой я могу отталкиваться, не затрачивая недели на принятие решений или на понимание явлений.
PS. Тем, кто обратил внимание на то, что по тексту в Яндексе менеджеры девушки, скажу следующее (и это нередко упоминалось в беседах с коллегами) — в Яндексе [не]удивительно много умных, энергичных и красивых женщин. Мне приятно называть их именно девушками.

Python и попкорн

Не всегда получается донести до собеседников причину, по которой я смотрю на мир Python с попкорном в руках. Попробую тут.
Сразу две вводные.
Python — инструмент. Если в нём что-то не устраивает, скорее всего, вы применили инструмент не к той задаче. Oy vey iz mir! Я написал на Python прошивку к реалтаймовому процессингу на карточных чипах, а оно не работает! Плохой, плохой Python! Очевидно, дело не в языке, но в ДНК специалиста. У правильно применяющих всё хорошо. У них, впрочем, и с BASIC хорошо будет. Голова на плечах рулит.
Python — не универсальный инструмент и не панацея от криворукости (уже писал, что на самом деле писать хороший код на Python сложнее, чем на Java/C++), но из-за кажущейся простоты порога входа получил армию фанатов. Часть критики Python вызвана желанием потыкать палочкой этот вот детский сад, для которого нет большего счастья и радости, чем не указывать типы. Так вот, это эссе не критика, не замахивание на святое и не всё то, что желает читать стремительно наполняемый кровью мозг.

Потреблению попкорна способствует история Python 3 и поддержки оной версии сообществом. Сегодня у меня в очередной раз всколыхнулся потому, что хотел почитать логи MongoDB более цивилизованно (aka с помощью mtools). Открываю, вижу «mtools is not currently compatible with Python 3», закрываю.

Шёл 2006 год (12 лет назад он был). Гвидо создаёт PEP 3000. Или лучше назад отойти? Не понять, какой год считать годом появления Python 3, т.к. Гвидо о нём думал ещё раньше. Скажем, в 2004 году запостил флеймообразующий постик «Optional Static Typing to Python» (у питонистов тогда знатно глаза и пальцы разгорелись, понадобились умиротворяющие постики). Как ни крути, но если вам кажется, что Python 3 — что-то новое, ну вот пару-тройку лет назад появилось, то нет. Более того, уже в декабре 2008 года был выпущен Python 3.0 final.
Добавлю фона для сравнения.
Kotlin — разрабатывается с 2010 года (думаю, всё-таки раньше начали), первый релиз в 2011 году. Swift — разрабатывается с 2010 года, первый релиз в 2014 году. Go — разрабатывается с 2007 года, первый релиз в 2009 году. Rust — разрабатывается с 2006 года, первый релиз в 2010 году. Эти даты должны вам помочь увидеть живую практику других языков. За 2..4 года разработка, воодушевлённый народ начинает фигачить вовсю тоже уже через 2..4 года, хоть у Swift особенный кейс, там один вендорный язык для вендорной платформы заменяется другим, потому особо выбора не было.

Что же произошло с 3.0? А ничего. Он сразу утонул под критикой. Вот удобная известная статья, в которой всё основное собрано. Шли годы. Вышел 3.1 (2009), 3.2 (2011), 3.3 (2012). Воз стоял на том же месте. Питонисты всё так же расползались по двум лагерям. В основном (я обгуглился переписок, интервью и прочего тех лет) война шла на трёх фронтах.
Во-первых, критиковали производительность. Бенчмарки, в которых 3.x был заметно медленнее 2.7, взывали к разуму. Но… матёрые сторонники прогресса (да и Python’а в целом) отбивались аргументом «нам и не надо!» С технической точки зрения аргумент настолько меня забавляет, что детализирую. Вот хороший пример — Python норм, проблема не в нём, а если в нём, напишите важное на C/C++ или юзайте Cython. Знаю немало питонистов. Живых таких реальных мужчин от 20 до 35 лет возрастом. С удовольствием представляю, как они пишут быстрокод на C/C++, ага. Гвидо, между тем, придерживался той же аргументации (говорящий заголовок статьи: «Van Rossum: Python is not too slow»):

It is usually much more effective to take that one piece and replace that one function or module with a little bit of code you wrote in C or C++ rather than rewriting your entire system in a faster language, because for most of what you’re doing, the speed of the language is irrelevant.

Я б добавил, что разумнее сразу писать на чём-то, что потом не потребует внедрения ещё одного-двух языков в стек, но это наверняка будет гораздо менее выразительно, чем писать на Python. В любом случае репутация 3.x была подмочена, т.к. столько лет делают, а везде и заметно быстрее не стало.

Во-вторых, несовместимость. За то, что 3.x не собирался поддерживать выполнение кода 2.x, Гвидо был виртуально бит задолго до релиза 3.0, но стоял на своём упорно. Мигрируйте и будет вам счастье, даже сделали 2to3, всех проблем не решавший, но всё же. Один фиг предполагалось, что вы просмотрите глазами весь свой исходник. И ладно бы, но как быть с мегатонной библиотек? Что вам радости, если 80% всех зависимостей совместимы с Python 3, а 20% нет? Должны быть 100%. Как итог, каждый уважающий себя питонист раз в неделю ходи(л|т) на py3readiness.org, проверяя, ну когда же, ну блин же. И если в Java/C++ 99.99% проблем миграции вам укажет компилятор, то в Python не так. При неудачном забеге звёзд вполне можно получить выстрел в рантайме просто потому, что в какой-нибудь уголок забытый не заглянул глазами, не потрогал руками.
В-третьих, нафига? Линейных разработчиков вопросы стратегии и legacy не волнуют. Их волнует, чтобы переход с X на Y был пыщ-пыщ. А Python 3 сумму пыщ-пыщ добрал лишь вот относительно недавно. Версия 3.6 (конца 2016 года) в сумме с возможностями предыдущих версий выглядит прям вот интересно и убедительно. Правда, с опозданием. Я не зря выше остановился на 3.3. Кажется, что это версия, на которой в умах произошёл надлом. Четыре года от первого релиза, а лучше не стало. Работает медленно. Никаких увлекательных свистелок-перделок, которыми можно заманить жаждущих хлеба со зрелищами. Планетарная миграция даже не началась, да и куда мигрировать, если вы сидите на версии Django, которую никто даже и чесать не собирается? В общем, всё плохо. И вот это «всё плохо» в головах устаканилось намертво.

И всё. Сообщество знатно затвердело. Как одни слепо за Путина, а другие слепо за Навального, так и тут. Можно хоть монтировку согнуть об иные лбы, но лбы совершенно искренне не будут понимать, зачем им Python 3. В их мире Python 2.7 вечен, Python 3 вечно медленный (это давно не так), не поддерживается (это давно не так), в нём нет прикольных фич (это давно не так). В 2018 году (спустя 10 лет релиза!) мир вовсю осваивает четыре новых языка, но мир питонистов до сих пор не может перейти на тройку. Ну вот никак. Это постоянный цирк и бардак. Самый распоследний 2.7.x вышел в конце 2016 года. Ветка не поддерживается, ветка не развивается. Всё равно будем держаться за неё до последнего!
В финале докину ещё примеров того, как в стороне от цирка развивается планета. С 2011 года по 2017 год вышли C++11, C++14, C++17. Вышел PHP7 в 2015 году. Вы [не] будете смеяться, но даже успели выпустить стандарт Fortran 2008 и вот-вот доработают Fortran 2018 (ранее Fortran 2015). Ужасный, медленный и кровавый мир Java успел выродить Java 7, 8 и 9 (позавчера и 10). А, да, первый релиз MongoDB вышел в 2009 году. Блокчейны… криптовалюты… квантовые процессоры…
А Python 2.7 (ветка началась в 2010 году, напомню) вовсю в production’е. И до фига живых людей не хотят от неё отказываться. Потому со стороны вся эта смешная история и смотрится с попкорном. Слишком уж в разрыве от общей практики происходит, слишком фанатично (aka не профессионально) воюет сама с собою эта часть сообщества, чтобы не превратиться в многолетний анекдот.
PS. Да, на собеседования приходят питонисты, которые заранее говорят, что Python 3 не знают совсем. Его нет в их текущей работе, а вне работы причин узнать не было. Радуюсь. Восхищаюсь.
PPS. Полтора года назад уже затрагивал тему, но чуть иначе и менее ссылочно. Не могу сказать, что всё кардинально изменилось. Не-а.

Бедные junior’ы

Чёт казалось, что достаточно ясно упомянул кейсы, когда junior’ов есть смысл нанимать (и их нанимают), при этом [напрасно] понадеялся, что продолжение этих кейсов не менее ясно, заинтересованные не поленятся хотя бы HeadHunter «погуглить» (ох, сложно-то как вбить там junior Java, ага). Но нет. Потому первое весеннее эссе 2018 года: куды податься беднягам без опыта.

Но сначала важное (даже ключевое). Набор вами опыта и вообще лично вы — не проблема работодателя. Рынок ещё не дошёл до стадии, на которой на каждого просто человека все бросаются, носят на руках и посыпают розами. Другие бойцы как-то извернулись и набрали опыт. Может, им повезло. Может, согласились на плохие условия. Или решили, что поспать можно и потом. Всякое бывает. В любом случае хватит считать себя вселенским подарком, с которым должны тетешкаться взрослые дяди. Не хватает чего-то (ума, усидчивости, самодисциплины, самоорганизации)? Значит, не будет и хорошей работы. Она будет у тех, у кого хватает и / или кто поработал над собой.
Иначе получается занятная ситуация. Скажем, чтобы пройти в олимпийскую сборную по отжиманиям, надо отжиматься 200 раз. А вы можете только 50 раз. Но в сборную очень хочется! Там и люди сильные, и награды, и вообще форма красивая. Что сделает толковый человек? Начнёт каждый день отжиматься, найдёт доступный спортзал, пойдёт работать грузчиком. Через год отожмётся 201 раз и хмыкнет, мол, фигня вопрос. Что делает каждый N-й дохляк? Начинает критиковать требования сборной (200? да вы офигели! да никто так не может! да что за дискриминация дохляков!). Отказывается начинать с нуля — грузчиком работать западло, в зале пыльный пол и доски скрипят, да и вообще мне никто не платит за отжимания. Терзает причину и следствие — нет, вы сначала дайте мне форму, награды и деньги, а 200 раз отжиматься я научусь потом.
Так вот это не работает. Чем раньше поймёте и посмотрите на мир иначе, тем вам же лучше.

Список ниже я составил по:

  • собственному опыту и по озвучиваемому в беседах опыту коллег;
  • вакансиям как на сайтах агрегаторов, так и прямых работодателей;
  • последним строчкам резюме, которые приходят на почту — иными словами, смотрю, с чего начинали живые люди.

Есть и другие варианты. Люди попадают на первую работу по знакомству (и тогда в резюме между строк читаешь «админил комп в киоске дяди Вахтанга»), например. Некоторые (таких мало, впрочем) активно фрилансят. У некоторых вообще загадка загадочная (первая же работа «Ведущий разработчик»). Всякое бывает. Но опишу массовые варианты.

Итак, традиционные потребители плохо отжимающихся вот такие…
Бадишопы. Термин размытый и давно уже означает не только лишь схему «чувак официально передаётся в аренду другому работодателю». По факту сотни и тысячи разработчиков сгребаются в одно ведро, менеджеры токуют и сгребают сотни заказчиков в другое ведро, потом сбиваются проектные команды, делают проекты и всё. Три основных признака бадишопа: 1) не делают собственный софт, 2) жополиард разработчиков с большой текучкой, 3) широкая заявленная экспертиза («мы делаем гвозди и ракеты»). Правда, эти ребята тоже начали считать деньги, похоже, потому открытых junior вакансий у топовых бегемотов почти и нет. Есть подозрение, что разумнее выходить на них письмом кадровикам или через знакомых в этих фабриках пота.
Госструктуры. В той же Почте России есть вакансии, у которых требуемый опыт от 1 года. Если вы из какого-нибудь специфического вуза (тот же МАИ), можно на год распределиться внутрь отрасли инженером. Даже в библиотеках бывают вакансии. Вы ни фига не заработаете на этой работе, конечно. Но это будет год стажа, что уже плюс к вакансиям, у которых «от года» строго соблюдается. Правда, тут заковыка: всё-таки большинство открытых мест с цензом на уже поработавших. Но исключения бывают.
Стартапы. Довольно часто вакансии джуниоров находятся с текстами «в новый проект». Вполне хороший вариант, если вы оформляетесь с трудовой. У стартапов огромный риск не получить в итоге ни копейки, но зато вы получите нужную стартовую запись стажа. Также риск бестолковости кадрового вопроса: бывают требования к джуниорам такие, что не каждый middle подходит. В общем, тут постоянно угадайка. В самом крутом варианте вы попадаете в хороший коллектив, в нём набираетесь опыта, в нём и остаётесь на N лет.
Толстячки. Чем толще контора (от бадишопов до Яндекс / Mail.ru), тем больше в ней рутинной скучной простой работы, на которую нет смысла брать сильных специалистов. Часто это всяческая автоматизация тестирования, для которой бывают вакансии без опыта работы вообще. Современная автоматизация вполне включает в себя Python, Java и остальное разработческое, потому языковый опыт, если не будете тупо делать ровно по тикетам, вы получите.

В целом намного проще искать работу, если вы не ленивы, адекватны и явно занимаетесь, чтобы попасть в профессию. Пробиваетесь на живое собеседование, изумляете собеседующих знанием языков, алгоритмов и технологий, объясняете жизненную позицию («я джуниор, хочу у вас работать, набираться опыта реальной работы», а не «я наглый невежа, ничего не знаю, хочу много бабла, чешите мне спинку, договоримся, кароч») — вуаля. Не получилось раз, другой, десятый. Получится на двадцатый.
Повторюсь, вы всё ещё убыточны. Ни один работодатель не рассматривает вас как полноценную боевую единицу. Ваша задача: показать, что именно вы тот джуниор, у которого путь от «этот чувак только ломает и отвлекает» до «это наше молодое дарование» занимает заметно меньше, чем у всех джуниоров мира, при этом вы не застрелитесь, справитесь, обучитесь и начнёте жечь напалмом. Чтобы это показать… очевидно, надо сначала потрудиться.
Чего я точно не знаю, так это как искать работу, если вы пинали балду и ни в чём не разбираетесь. Толковый junior — не отсутствие мозга и знаний, но отсутствие опыта. Если к 20+ годам вы не удосужились ничего выучить полезного / нужного / востребованного, а в голове опилки, ну… ну молодец. Только нафига тогда в разработку идёте? Дальше точно не будет легче.