Категории 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+ годам вы не удосужились ничего выучить полезного / нужного / востребованного, а в голове опилки, ну… ну молодец. Только нафига тогда в разработку идёте? Дальше точно не будет легче.

Junior — роскошь

.. а не ресурс разработки Junior — человек, которому вы не можете выдать задачу сложностью выше некоторого уровня, если хотите, чтобы задача была решена в нужные вам сроки. Таким макаром в разных монастырях один и тот же человек может быть ранжирован не одинаково. В Кукусофте он middle, в Почтоваре он junior, а в учреждении для общественного воспитания детей дошкольного возраста и вовсе senior. Зависит от задач и сроков.
Ещё три исходящих пункта.
Раз. Джуниор (впрочем, как и любой другой) интересен тогда, когда для него есть фронт задач его уровня. Иными словами, стоимость их решения адекватна.
Два. Джуниор интересен тогда, когда из него хотят и могут [почти] любой ценой сделать что-нибудь другое. Характерно для больших компаний, выращивающих себе кадры, особенно штучные (тот же ШАД Яндекса примером).
Три. Джуниор интересен тогда, когда интересен не задачами и не ростом. Бывают занятные схемы. Скажем, вы аутсорсер, по контракту оплачивают работу с учётом занятых на проекте голов, выгодно эти головы набрать и демонстрировать. Это Вася. У него димплом МГУ, он джавист, уважаемый Джон Смит, похлопайте Васе и перечислите нам очередной транш. Что там за знания у Васи, чем он реально занят… никого не волнует. Такие схемы обсуждать не будем, достаточно того, что оно бывает и к разработке не относится.

Ещё ремарка про стоимость джуниоров. Давайте на пальцах следующую формулу зарплаты изобретём (почти по рынку, хоть для красоты округлил): J(unior) = n, M(iddle) = 2*J, S(enior) = 2*M. Это вот зарплата. Но работодателя интересует стоимость решений. Если junior делает софт 4 месяца, а senior тот же софт за 1 месяц, видим смешное: junior выпустил продукт на три месяца позже при senior’ной стоимости решения.
Слишком чистенько. На деле живые джуны делают ещё дольше и требуют ещё больше вложений. Они перетягивают на себя внимание middle+ (code review, консультации). Плохо интегрируются с нужной бюрократией (тексты коммитов, тикеты в JIRA). Плохо понимают командную работу (тусить в изоляции, забив на состояние мира вокруг — штатное состояние). Понимание ответственности на нуле (для них часто по воображаемым последствиям примерно равны «мама, я застелил постель» (не застелил) и «Аристарх Петрович, я протестировал все изменения перед выкаткой» (не все, не протестировал)), что добавляет рандома в production.
Всё это вместе с исправлением, обучением и банальным надзором замедляет работу остальных, что влияет на стоимость уже их решений. И, что прикольно, всё это в какой-то момент может оказаться пустотой — то вдруг оказывается, что чувак не подходит профессии. Или у него прошло увлечение и теперь он хочет на лыжах кататься. Или просто зайку не ценят и потому зайка уходит в монастырь. Или начитался про успешные стартапы и уходит в загул пилить Super Duper ToDo Tracker, который обязательно поглотит рынок.

Также нередко джуниоров, если они прям юные, надо учить:

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

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


Теперь подумайте и себе честно ответ: нафига всё это работодателю? Обычной софтварной конторе от гаражика до «это здание всё наше». Не приюту. Не благотворительному фонду. Не школе для одарённых детей. Не яростной молотилке кадров, в которой в день сто страниц копипасты. Вот нафига? Middle и senior выгоднее. Головняка с ними заметно меньше. Рандома в проде заметно меньше. Ставить их на путь истинный тоже проще, бойцы уже биты жизнью, могут гонор в карман спрятать и таки сделать то, что надо, а не «я так вижу». Прогноз работы с ними тоже проще — если до middle добрался, есть куда толкать и выращивать. Потому в общем случае джуниоров не нанимают. Убыточно. Проблемно. Результат не спрогнозировать. Нафиг надо.
Исключения бывают, безусловно (особенно когда у исключения «глаза горят», учебники от зубов отлетают и в анамнезе годный код на GitHub’е, тут прям удовольствие смотреть, как талант раскрывается). Но меня подбешивает, когда на голубом глазу говорят «а чё, ну наберите роту джуниоров, воспитайте, вот вам и будут кадры». Нет, спасибо. Сами набирайте. Все люди хорошие, братья, друзья и ромашки, но иногда полезнее тикеты вовремя закрывать, а не переоткрывать по десять раз, выполняя гражданский долг матери Терезы.
PS. Конечно, вы не такой junior. Это какие-то другие такие. А вы самый умный, самый хороший, самый клёвый junior в мире.

Профессиональная самооценка

Один из неловких моментов: человек считает себя senior’ом, а ты по итогам считаешь, что он в лучшем случае серединка middle, и вот надо как-то это обосновать. Неудобно всё это, травмирующе для обеих сторон. Лучше, когда человек оценивает себя адекватно, актуально, объективно. Чтобы после десяти «не знаю» и «не помню» не собеседующего странным считал, но задумался о повышении квалификации.
Сузим контекст. Пусть Java (язык), JDK (библиотеки), JVM (виртуальная машина). Как джависту понять, на каком уровне он всё это знает?

Во-первых, сертификация. У Oracle три уровня: Associate (junior), Professional (middle), Master (senior). Попробуйте их сдать. Как вариант, можно купить mock certification у Enthuware и потренироваться. Или осилить книги вроде OCA: Oracle Certified Associate Java SE 8 Programmer I Study Guide: Exam 1Z0-808 или OCA Java SE 8 Programmer I Certification Guide. После чтения задуматься: да, обо всём этом спрашивают и всё это считается нужным для подтверждения уровня. Если вы не согласны и можете несогласие аргументированно оформить в текст, напишите в Oracle. Быть может, к вам прислушаются.
Слышал мнение, что никто сертификацию не сдаёт, никому не надо и т.п. Так вот, количество сертифицированных приближается к миллиону. Последнюю статистику нагуглить не удалось, но вот текст от Oracle времён семёрки: Java Programmer Certification: Java SE 7 Certified Programmers И да, работодатели тоже с интересом смотрят на сертификат.

Во-вторых, собеседования. Если вы являетесь senior’ом, для вас не составит труда за несколько месяцев пройти senior собеседования в top 20 работодателей. Вроде бы мороки много, но уверяю, оно того стоит. Сначала может оказаться больно и обидно, но после здравого размышления всё становится на свои места. И, грубо говоря, либо 20 человек признают ваш уровень, либо вы спуститесь на землю. Ну или затаите обиду непризнанного гения, что тоже бывает.
В top надо идти потому, что у них есть выбор, а вокруг десятки разработчиков, с которыми можно сравнить. И если местные senior’ы среди ночи легко ответят на вопрос «как выглядит integer underflow в Java», сам собою формируется некоторый стандарт уровня. Вы не можете на подобное отвечать? Окей, возможно, вы и senior, но не нашей мануфактуры.

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

В-четвёртых, конференции. Их полезно смотреть и слушать. Умные люди отбирают доклады умных людей, чтобы умные люди послушали. Послушайте и вы. После каждого доклада говорите вслух: «озвученная тема не нужна, не интересна, никто не использует, да что за бред вообще, это не надо знать». Чем менее смешной вам будет казаться эта фраза, тем дальше вы от senior Java, например.
Понимаю, тот ещё показатель. Но умиляет же, когда Шипилёв, например, собирает сотни слушателей, зал впитывает, статьи пишутся, софт делается, а потом мимоидущий senior expert guru Java developer роняет, шо то никому не надо. В общем, на этом оселке тоже не мешает после всего остального сверить себя с внешним миром.

В-пятых, определение. Подумайте и последовательно сформулируйте собственные определения senior, middle и junior. Именно в таком порядке. Опишите обязательные знания и умения уровней. Только честно и злобно. Словно перед вами сто кандидатов, надо нанять двоих и от этих двоих зависит, выйдет ваш бизнес на IPO завтра или через год. Сделали? Ожидаемо примените к себе. Всё хорошо? Теперь то же объективно примените ко всем своим знакомым разработчикам. Откалибруйте шкалу, попробуйте посмотреть на каждого через оценку его знаний в каждой области. И снова примеряйте к себе.
Надеюсь, что вы определили уровни не через скорость гугления неизвестного. И здорово, если вам хватило мудрости не определять через «о, я не умею в рекурсию, значит, настоящим senior’ам рекурсия не нужна».

Всё это я в какой-то степени прошёл. Разве что собеседований мне хватило и трёх, чтобы понять, что после двухлетнего перерыва был самоуверенным бревном, а не Java senior’ом. Правда, сейчас тоже вряд ли потяну полновоенное собеседование, ведь есть ещё Spring, Hibernate, NoSQL, RDBMS, алгоритмы, Linux, сети… Да-да, всё то, что вы обязательно нагуглите, если вдруг понадобится. ^_^

О самостоятельности, часть I

Сначала про обычный фейл руководителя: делать всё самому. А если и не самому, то оценивать сделанное строго с позиции «как бы это сделал я». Начинающие (особенно из технарей) с этой грабли начинают, после чего либо стремительно умнеют, либо стремительно уходят из руководства (что тоже равно «умнеют»), либо становятся тем, что вроде бы должны изгонять — проблемой.
Если руководитель умнеет, он старается выделить самостоятельных бойцов и делегировать им задачи. Иначе говоря, не делает то, что могут (и/или для чего были наняты) другие. Не потому, что ленивый, но потому, что у него задач на тыщу человек, можно лопнуть лягушечкой на глобусе.
И вот тут начинается интересное. Какие качества должны быть у потенциально самостоятельного бойца (часть I)? Что такое самостоятельность и где её границы (часть II)? Как ею создать коллектив и как развалить (часть III)?

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

Что в итоге? Самостоятельность для тех, кто:

  1. Хочет её получить.
  2. Достаточно квалифицирован.
  3. Созрел для ответственности.
  4. Понимает и принимает выход за границы разработки.

Этого чеклиста безо всяких нюансов уже хватает для оценки и постановки. Да, в реальном мире такого бойца поди найди. Но чем дальше, тем увереннее думаю (а пару раз и точно знаю), что «я тебя слепила из того, что было» зачастую убыточнее по всем ресурсам, чем, скажем, бездеятельность в направлении за отсутствием человека нужных качеств.

Продолжение следует.