IT’S JUST GOOD BUISNESS

Дисклеймер

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

Предисловие

Это моя очередная статья на тему праздных рассуждений. Однако, в этот раз рассуждения не совсем праздные. Это моя попытка осветить и объяснить некоторые важные проблемы в IT-индустрии, где и находится моя основная деятельность. Множество раз я пересказывал свою точку зрения устно, но устал и решил оформить её в виде текста.

А ещё в конце статьи есть список литературы.

Ведение

Итак, технологии развиваются, скорость развития возрастает экспоненциально (возможно осуществление гипотезы «технологической сингулярности»). Вакансии образуются, на них нужно кого-то нанимать… Как известно, по-настоящему талантливых людей очень немного, но тут важно определиться с тем, что такое талант. Нередко определение ему дают приблизительно такое:

• это 10 тысяч часов, которые ты вложил в дело;

• это тренировки и практика в то время, когда другие развлекаются;

• это умение каждый день бить в одну точку;

• это способность верить в свои усилия;

• это железная дисциплина;

• это выбор быть талантливым.

Я бы ещё добавил сюда предрасположенность как последний пункт. Да, и без предрасположенности к математике, кандидатом математических наук стать возможно при должном усилии. Однако, людям, имеющим некую «предрасположенность», удастся сделать это гораздо быстрее и, вероятно, качественнее просто в силу того, что они такие (конечно, при наличии остальных критериев таланта т.к. без них даже «предрасположенному» математиком не стать). Кто-то расстроится, что не каждому дано стать математиком, ну а я скажу – «это хорошо», что все люди разные, ведь нужны не только математики, а, например, и лингвисты. Чем больше разных людей, тем больше мнений и подходов. И не надо никого ровнять, ведь чем больше подходов, тем больше потенциальных направлений развития (науки в том числе).

Следствием из вышесказанного идет то, что все должны заниматься своим делом… Но по факту это часто совсем не так. Это настолько «не так», что, грубо говоря, «экономисты становятся инженерами» – люди часто не знают, к чему предрасположены и занимаются не тем, чем следует.

И вот, случилось так, что в некоторые сферы можно попасть с минимальными значениями критериев таланта (т.е. без таланта, по сути). Точнее, там переопределяют талант, практически приравнивая к понятию «ментальная гибкость». Оставим за рамками статьи негативные стороны этого приравнивания (а про позитивные вы и так много раз слышали).

Люди, не имеющие таланта, попадают в IT просто потому, что «эта область быстро развивается и требуется много новых специалистов» (о кавычках поговорим позже). Приходится нанимать (как я их люблю называть) «быдлокодеров», «недопрограммистов» и «индокодеров». Ведь талантливых людей мало. А место кем-то надо занять… Также будет затронута потеря таланта (в связи с воздействием окружения) и просто работа «на отвали» в силу некоторых обстоятельств.

Рассмотрим причины подробнее.

Развитие IT

Все постоянно говорят об «экспоненциальных темпах развития технологий», которые создают пустые места, которые нужно заполнять. Однако, это может быть не совсем корректно. Дело в том, что развитие технологического прогресса и появление вакансий могут быть не связаны напрямую (бывает и так). Да, сейчас они коррелируют, но долгосрочный прогноз потребности в кадрах сделать выйдет едва ли и причина тому – автоматизация. Есть 2 основные точки зрения на «будущее кадров»:

1. специалисты будут нужны всегда и чем дальше, тем больше, ведь каждый «отвеченный вопрос» порождает ещё несколько «вопросов». Как пример можно привести возможное устаревание профессии программиста (как специалиста по машинному обучению), но появление, например, «проектировщика самообучающихся систем ИИ», «психолога систем ИИ», «эксперта по моральным ценностям ИИ» и др. с десятками подкатегорий в каждой (аналогично когда-то профессия наладчика вычислительной аппаратуры разделилась на несколько профессий: в том числе, и профессию программиста).

2. специалистов со временем будет нужно всё меньше, ведь средства автоматизации становятся всё совершеннее, а островок «эксклюзивно человеческих способностей» всё меньше (благодаря ИИ в том числе) – вполне вероятно, что со временем человек может быть полностью заменён почти везде, а там, где останется незаменимым, будут столь высокие требования к компетенции (и низкая потребность в кадрах), что там будет работать не более 1/1000 процента населения, при этом количество таких вакансии будет сокращаться.

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

Раз развитие технологий [относительно] слабо связано с появлением вакансий, то что же стоит за ростом спроса на программистов и других специалистов IT?

Рынок

Именно рынок определяет востребованность той или иной профессии. А вы сомневались? Рынок определяет практически всё, с чем взаимодействует житель развитой/развивающейся страны. Так, как он определяет набор продуктов на прилавках, он определяет и специальности, которые могут заработать, предоставляя те или иные продукты. Технологический прогресс определяет только потенциальный набор ниш рынка, но никак не то, какие ниши действительно образуются и как их займут. Даже самая продвинутая технология (или продвинутый с точки зрения технологий продукт) может не найти потребителя (применения при текущем раскладе товаров/услуг и текущей тенденции) и, как следствие, не образовать востребованности в специалистах, занимающихся изучением/разработкой/производством.

Рынок работает не так, как работает наука. Если для науки важны все технологии, то для рынка важно лишь то, что может «переварить» достаточное количество потребителей. В общем-то, рынок этих потребителей и настраивает – «подсаживает» на определённую «пищу» (если точнее, то на определённый «принцип»*). Информационные технологии, в частности, развиваются больше не по пути науки, а по пути рынка, чтобы производить то, что потребит современный потребитель.

Но почему, всё-таки, IT развивается не по пути науки? Ведь не обязательно с любой разработки деньги получать? На самом деле, в большинстве случаев – обязательно, ведь развитием IT занимается, в основном, бизнес.

Бизнес

Вот мы и подошли к этому ключевому понятию. Конечно, с его определениями вы знакомы, как и с его сутью: конечно же, это получение денег. Но если точнее, то суть бизнеса – только получение денег. Бизнесу не нужно ничего, кроме денег. Только вот беда: деньги сами по себе не делаются, из-за чего приходится что-то делать – зарабатывать эти деньги. И вот тут уже каждый выворачивается как может ради прибыли.

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

Если бы люди вдруг стали «идеальными» для какой-то компании (например, Apple), это бы означало, что эти люди готовы платить за отсутствие усилий со стороны этой компании (например, платить этой компании просто за то, что она есть, при том, платить столько, сколько эта компания скажет). Разумеется, эта компания с «идеальными» клиентами сразу же уничтожила бы любое производство, которое у неё было, уволила всех, кого только можно уволить, чтобы увеличить прибыль владельцев (руководства сокращение тоже коснулось бы, кстати).

И вот, с бизнес-целями (а точнее, с одной целью) люди, в основном, и начинают IT-стартапы*, которые позже становятся компаниями, а ещё позже – корпорациями – и уже нет никакого способа «слезть с денежной иглы».

Взяв во внимание всё вышесказанное, как вы считаете, каких специалистов нанимают корпорации? Да, конечно же, таких, чтоб как можно больше производили с допустимым уровнем качества при как можно меньших затратах.

Ключевым здесь из этих трёх параметров является допустимый уровень качества (на нём иногда можно заработать очень много за относительно небольшой промежуток времени). Да, среди корпоративных продуктов практически никогда нет 100% качественной продукции (и это не только к IT-индустрии относится). Обычно, порог устанавливается эмпирическим путём. Грубо говоря, требования к качеству (после некоторых проб) выглядят примерно так: «нам нужно, чтобы среди наших пользователей проблемы возникли не более, чем у 1-2%» (конечно, 1-2% — это довольно низкий уровень качества, но для примера сойдёт). Обычно, конечно, критериев качества больше, чем 1 и не все они формулируются именно так, но в целом идея такова: не нужно делать продукт с «военным» качеством, достаточно сделать просто чтобы работало у большинства, а возмущения меньшинства имели минимальное влияние на продаваемость.

Так, с уровнем качества, похоже, разобрались. Однако, кому-то покажется, что разобрались с ним довольно абстрактно и пока не видно здесь непосредственно причины падения качества кадров (в IT, например). Глубинная причина, однако, в основном, кроется именно в допустимом уровне качества. 99.9% проблем, которые вы обнаружите у купленных продуктов (будь то вещи или ПО), были известны производителям при продаже и, вероятно, даже до производства (т.к. есть специальные аналитики, которые предсказывают возможные проблемы конфигураций продукта), а на прилавки продукты попали потому, что их уровень качества оказался допустимым по мнениям производителей. Для гражданских уже никто не делает продукцию без проблем с качеством и даже не факт, что для военных целей продукция выпускается со 100%-качеством (на момент производства т.е. с теми технологиями, которые существовали на тот момент).

С чем напрямую связано качество продукции? Правильно, с количеством денежных средств, вложенных в неё. Если говорить о материальной продукции, то их количество может быть снижено, условно, экономией на материалах и средствах производства. Если говорить о ПО, то тут экономия, аналогично, касается отладки (устранения багов) и самих разработчиков. Экономия на отладке в данном случае сродни экономии на материалах, а экономия на программистах – экономии на средствах производства. Как и полагается, эти две экономии всегда ходят парой (но с разной степенью). По сути, экономия на отладке напрямую влияет на видимое качество получаемой продукции. Это почти тот случай, когда при достаточно продвинутом материале, достаточно простейших средств производства (как, например, для получения куска хлеба, достаточно иметь хлеб – продвинутый материал – и нож – простейшее средство производства). В контексте производства ПО, это звучало бы примерно так: даже плохие программисты при достаточном количестве отладки, смогут произвести качественный продукт (кто знает про процессы Test Driven Design, тот знает). Однако, с этим есть 2 проблемы:

1. ограничения по времени. Бизнес всегда ставит временные рамки на производство той или иной продукции. Нередко случается так, что соблюдение временных рамок оказывается важнее соблюдения допустимого уровня качества (это очень частый случай, кстати). Отладка кода требует гораздо больше времени, чем написание кода. Плохие программисты не смогут написать качественный код и будут добиваться правильной работы ПО отладкой. Значительно увеличатся (в процентном соотношении) объёмы отладки относительно объёмов написанного кода, и, как следствие, очень значительно увеличится количество требуемого на производство программного продукта времени. Это недопустимо, ведь чем скорее будет поступать продукция, тем больше будет получено денег, и у конкурентов будет меньше возможностей потеснить на рынке;

2. внутренние проблемы с качеством. В общем-то, у любой продукции есть видимая и невидимая части. У ПО такое тоже есть, разумеется: человек видит лишь интерфейс и его работу, но всё остальное остаётся за пределами видимости. Горы отладки, конечно, исправят ошибки, но вопрос в том, насколько эффективно эти ошибки будут исправлены. Для понимания проблемы можно привести аналогию: пусть у нас есть 3 города, каждый из которых соединён с другим ровно одной дорогой (все города на равном расстоянии друг от друга), а задача – добраться из города А в город Б. Случилось так, что дорога между городами А и Б неисправна. Можно было бы её починить, однако, задача-то просто добраться из А в Б, следовательно, можно просто поехать через город В и выполнить задачу. Задача выполнена? Выполнена. Ну а неэффективность такого решения никого волновать не будет, пока на постоянной основе не начнут образовываться пробки в город В протяженность с дорогу от А до В. Так вот, проблема 2 заключается в том, что эти пробки (длиной с дорогу от А до В) образовываться всё-таки будут.

«Как же тогда экономить?» — спросите вы. Как найти компромисс, если он вообще есть? На самом деле, этот компромисс есть и его можно чуть ли не Граалем современного IT назвать. Этот Грааль – различные языки программирования и корпоративные библиотеки/фреймворки. Они позволяют экономить и на отладке, и на разработчиках. А что, если я скажу, что они ещё и объёмы производства поднимают? Просто чудо какое-то!

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

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

Именно на сотнях слоёв абстракций и работает «Грааль IT». Один из плюсов для бизнеса был виден ещё в аналогии – меньше забот для программиста и, как следствие, меньшие временные затраты (со стороны программиста) на производство продукта, следствием чего является рост объёмов производства. Но есть и ещё плюс. С помощью абстракций можно упростить любой принцип донельзя (например, весь процесс работы радиоприёмника упростить до «переводит радиоволны в звук»). Таким образом можно кардинально снизить порог входа в ту или иную область (в нашем случае – в IT). А если порог входа снижен, то что? Правильно, можно нанимать более дешёвых специалистов (которых непомерно больше). Можно даже вообще не специалистов нанимать – всё равно они будут работать с чем-то, имеющим с реальными процессами крайне слабую связь.

Таким вот образом можно почти безгранично увеличивать объемы производства, экономить на заботах о качестве (т.к. создатели абстракций «уже позаботились») и производстве (т.к. специалистов требуется меньше и можно нанимать всё больше дешёвых «неспециалистов»). Ultimate combo!

Только вот есть и обратная сторона, а именно – 2 основных проблемы:

1. эффективность выполнения. Да её уже упоминали, но она достойна большего внимания. Как уже говорилось ранее, из-за большого числа слоёв абстракций падает скорость работы ПО (программы начинают работать медленно из-за больших накладных расходов). Думаю, всем уже понятно, как это происходит (если нет ­­– читаем аналогию с самолётом ещё раз). Это, надо сказать, довольно заметный эффект. Причём, слои бывают разные и существуют такие, которые по замедлению десятка других стоят. Однако, существует ещё кое-что. Системы абстракций всегда навязывают какие-то свои правила. Иногда в силу устройства абстрагирующей системы просто нельзя «проехать из города А в Б не через город В, даже если прямая дорога между А и Б исправна». Бывает так, что правила системы абстракций имеют совершенно другие принципы в сравнении с правилами, которые эта система абстрагирует – с таким случаем абстракции получается максимальное замедление (максимальное среди других случаев абстрагирования). Как аналогию можно было бы привести абстрагирование панели управления «классическим автомобилем» (с 3 педалями, механической коробкой передач и т.д.) панелью управления электрогенератором. Невозможно? Ну, вообще-то (при достаточной извращённости), возможно, просто одна команда с пульта генератора может вызвать десяток действий у системы управления автомобилем. Например, «движение вперёд» у автомобиля устроено сложнее вращения ротора генератора. А ещё в панели управления генератором нету, например, команды «движение назад» («вращение ротора в обратную сторону»), из-за чего можно будет ставить автомобиль только на сквозных парковках, ведь он не сможет парковаться ни задом, ни носом (потому что выезжать придётся задом). Это работает и в обратную сторону: чтобы сделать нечто, что с панели управления автомобилем делается легко (смена передачи, например), с панели управления генератором может потребовать десятка команд (просто потому, что панель управления генератором рассчитана на управление генератором, а генератор обычно не имеет аналога коробки передач). И это я ещё не затрагивал особенности представления данных об обстановке вокруг автомобиля на пульте генератора… Вам может показаться, что в IT такого уж точно нет, но, увы, есть. Иногда программисты всё-таки «управляют автомобилем с пульта управления генератором». Например, функциональное программирование (функциональные языки программирования) иногда похоже на это.

2. эффективность реализации. А вот этот пункт можно назвать «business-friendly-вариацией» 2 пункта из предыдущего списка. По сути своей он так же вытекает из снижения порога вхождения, но имеет гораздо больший потенциал для коррекции (о ней позже). Дело в том, что абстрагирование – не панацея от, например, просто неэффективных алгоритмов. Абстракции не могут заставить программиста проектировать качественную архитектуру и писать алгоритмически эффективный код. Очень хороший вопрос: возможно ли каким-то способом заставить программиста писать эффективный код (и нужен ли тогда будет сам программист в нынешнем понимании). Из-за снижения порога входа в IT приходят «специалисты», у которых с алгоритмами и структурами данных (базовыми знаниями, по сути) всё довольно плохо, но это не мешает им работать и получать приличные деньги («быть востребованными на рынке»). Не факт ещё, что эти люди достаточно хорошо знают систему абстракций (язык, фреймворк), с которой работают, чтобы писать оптимальный код хотя бы с точки зрения этого языка/фреймворка, т.к. иногда одна лишняя команда может замедлить выполнение в несколько раз. Ошибки (в смысле неэффективной реализации) «абстрактных программистов» иногда могут стоить дороже ошибок «программистов конкретных». «Иногда» здесь потому, что «конкретные программисты», хоть их и сравнительно мало, часто делают самую ответственную работу (в силу уровня своих знаний), поэтому их ошибки, обычно, дороже ошибок «абстракционистов», но гораздо реже. Однако, «конкретики» не всегда работают над крайне ответственными участками и вот тут ошибка «конкретика», условно, может добавить 1-2 лишних операции, а ошибка «абстракциониста» – 100-200. Конечно, «абстракционисты» бывают разные – есть те, что знают, как делать качественно в рамках возможностей своего инструмента (да и инструменты выбирают умело), но «неспециалистов» гораздо больше (а много и тех, кому просто «не дано» – нет таланта), для которых и работы больше (потому что их работа дешевле, чем работа настоящего специалиста). Также нельзя приуменьшать значение качеств программистов. Если для становления «конкретиком» требуется пройти непростой путь (абы кто не пройдёт, не сможет качественно усвоить материал и, как следствие, не сможет с ним работать), то у «абстракционистов» путь гораздо проще, и пройти его могут многие, следовательно, «фильтрация по качествам» гораздо слабее, из-за чего проходят, например, «лентяи», которым легче подключить к коду целую библиотеку функций (возможно, целый слой абстракций добавить), чем самостоятельно реализовать одну несложную функцию. Алгоритмическая эффективность их кода также вызывает вопросы т.к. тут требуется думать над решением задачи (вероятно, разными подходами к решению), а лентяям над этим думать лень – от них часто можно увидеть решение «влоб» (а такое редко бывает эффективным). В этом месте логично припомнить понятие «ментальная гибкость» (далее – «гибкость»), упоминавшееся ранее. В наше время (и в прогнозах на будущее) его почти приравнивают* к таланту. Я нисколько не отрицаю и даже подчёркиваю важность этого свойства, но не в таком контексте, в каком его нередко преподносят… Ну вы ведь уже догадались, зачем это качество программистов нужно IT-фирмам? В основном, его они ждут от 2, условно, «категорий»: специалистов высокой квалификации и «абстракционистов» среднего и низкого уровней. Людей из 1 категорий (в мире) в десятки тысяч раз меньше, чем из второй, и понятие «гибкость» у них имеет более сложное наполнение, поэтому часто его упоминают в контексте именно 2 категории. Первой категории «гибкость» нужна, например, для рассмотрения альтернативных подходов к решению (при проектировании, например). Второй – для переключения между разными системами абстракций и эффективной работы с ними. Думаю, понятно, что во 2 случае (о котором, на самом деле, и говорят в контексте разработчиков) «гибкость» и близко не синоним понятию «талант». Это требование (нечто необходимое, в отличие от таланта, о котором говорилось в начале), без которого человек «абстракционистом» даже низкого уровня успешно работать не сможет.

Ну вот мы и рассмотрели проблемы этого «Грааля» и, думаю, вы поняли, что для всего кроме бизнеса, это «нечто» уж чем, но «Граалем» точно не является. Ну а для бизнеса нет ничего лучше, и 2 вышеописанные проблемы бизнес обходит не менее «бизнес-идейными» принципами. Так, первую проблему решают просто «горизонтальным масштабированием» – это когда наращиваются вычислительные мощности. Конечно, это «лечение не проблемы, а симптома», но бизнесу важно только чтобы оно работало, а как – не важно (важна лишь прибыль, которую приносят работающие системы)*. Со второй проблемой, может, показаться, разобраться будет сложнее, но нет, тут всё почти так же с одной лишь разницей – «масштабирование вертикальное» (т.е. алгоритмы запаковываются в очередные абстракции – думаете, почему, постоянно появляются новые JS-библиотеки, например?), но это не единственное практикуемое решение. На самом деле, «вертикальное масштабирование» – не самое дешёвое решение – можно проще и дешевле. Делается это с помощью бюрократии введения различных методик разработки и добавления различных остановок на пути deploy (публикации, по сути). Это оказывается куда дешевле и, хоть в полной мере не даёт результатов «вертикального масштабирования», уменьшает процент попадающих в релиз проблем с производительностью до допустимого уровня (вспоминаем допустимый уровень качества). Также эти распорядки решают многие организационные вопросы, по причине чего не могут быть полностью заменены «вертикальным масштабированием». На самом деле, внимание на производительность по заветам бизнеса начинают обращать только тогда, когда её не хватает. Аналитики предсказывают узкие места системы в большинстве случаев заранее, и алгоритмы на этих участках подвергаются большему контролю, а остальные места могут даже быть побоку: пусть хоть пузырьковую сортировку там делают. Нужно сказать, что на данный момент текущего уровня абстракций хватает (новые абстракции в том или ином месте появляются почти каждый день, поэтому правильнее было бы говорить о скорости появления абстракций, которой пока вполне хватает) для получения допустимого уровня качества с использованием довольно несложных методик.

Важно сделать заметку, что некоторые бизнес-практики и за пределами бизнеса имеют жизнь: например, code review, методологии разработки и др., но за пределами бизнеса эти практики не преследуют цели бизнеса, по причине чего работают немного иначе.

Теперь, наверное, вам стало гораздо лучше понятна проблема падения качества программирования (её комплексность, в частности). Выше я говорил о падении качества, как о результате прихода некачественных кадров, но это не всё. Не самом деле, падает качество не только новых (т.к. снижается порог входа), но и старых кадров. Связано это, разумеется, с бизнес-рамками… Даже высококлассного программиста на C++ могут заставить писать на Python для уложения в сроки сдачи проекта (ну и для избавления от «низкоуровневого» кода C++ в кодовой базе, что позволит «неспециалистам» гораздо лучше вливаться в проекты). Да, программист может возмутиться и уйти из фирмы, и, да, это происходит, но не столь часто, как кажется. После C++, Python будет как детский сад после университета, за который ещё и платят неплохо. То есть, например, зарплата та же, работать значительно проще. Неужто, думаете, от подобного часто отказываются? Так происходит деградация специалистов – важное негативное явление, о котором довольно мало упоминаний. Нередко инициатором этой деградации становится сам программист: он видит, что есть язык, на котором можно сделать то же самое (или почти то же самое), но гораздо проще и быстрее, да ещё и выплачивают суммы, сравнимые с з/п программиста на языке более низкого уровня. Разработка проще и быстрее, высокие зарплаты – одни плюсы! Абсолютное большинство людей ставят свой комфорт превыше качества того, что делают (да и вообще превыше всего свой комфорт ставят)…

Политика

Ну вот мы и подошли к ней – «причине всех причин». Разумеется, оставлять политику полностью за рамками данной статьи было бы неправильно.

Хоть, конечно, говорить о политике рискованно, мне придётся о ней упомянуть в чисто научных интересах.

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

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

На этом моменте можно было бы и закончить статью, но мне хотелось бы ещё «пять копеек вставить».

Как считают некоторые люди, капиталистический строй находится не так далеко от «адского» строя и вот почему: в капитализме всё вращается вокруг денет, пренебрегая всем остальным. Пренебрегается то, что за этими деньгами стоит: откуда они пришли и куда идут; пренебрегается объект и субъект намерений: кто деньгами распоряжается и ради чего… Разумеется, «свобода» быть должна, но… сложно сказать, как и в чём она должна проявляться и что вообще считать «свободой» для становления «утопии»… У нас, людей на Земле, всё до сих пор не «по-адски» плохо лишь благодаря существованию институтов морали и права. Пример института морали – религия (она может быть очень разной, но самые базовые вещи везде схожи); пример института права – закон. Для превращения наш мир в ад нам достаточно подчинить эти 2 института деньгам: тот, кто имеет достаточно денег, будет прав всегда (и с моральной точки зрения, и с точки зрения закона — официально и бесповоротно). Think about it.

Послесловие

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

Список литературы

• Карл Маркс “Капитал. Том I.” – https://www.marxists.org/archive/marx/works/download/pdf/Capital-Volume-I.pdf

• Robert Martin “The Clean Coder: A Code of Conduct for Professional Programmers” – https://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073

• Howard Gardner “Frames of Mind: The Theory of Multiple Intelligences” – https://www.goodreads.com/book/show/294035.Frames_of_Mind

• Erich Fromm “Man for Himself: An Inquiry Into the Psychology of Ethics” – https://www.goodreads.com/book/show/40718037-man-for-himself

• Robin Hanson “Why Does Software Rot?” – https://www.overcomingbias.com/2016/06/why-does-software-rot.html

• Martin Fowler “What Is Refactoring” – http://wiki.c2.com/?WhatIsRefactoring

• Jonas Söderström “Onceability: The consequence of technology rot” – https://www.inuse.se/blogg/onceability-the-consequence-of-technology-rot-inuseful/

Еще около 30 лет назад никто не мог бы с уверенностью сказать, имеются ли у других звезд планеты. В настоящее время количество известных экзопланет превышает 5000, а с учетом планет-кандидатов, которых в 2021 насчитывалось 7913, общее количество таких внесолнечных миров приближается к 15000.

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

Соответственно, данные об экзопланетах отчасти неполные, а отчасти косвенные, поэтому классификация экзопланет затруднена. Тем не менее, уже открытые экзопланеты гораздо разнообразнее, чем миры, имеющиеся в нашей Солнечной системе. По некоторым источникам, самый распространенный класс планет – это «суперземли».  Примерно из 4000 экзопланет, достоверно известных к концу 2021 года, к числу суперземель относится примерно 1500. Возможно, это крупные скалистые планеты с атмосферой и гидросферой, превышающие по размеру Землю в 3-10 раз. Но почему, в таком случае, подобной планеты нет в нашей системе, ведь это противоречит принципу заурядности? Ниже мы обсудим, что нам сейчас известно о суперземлях и других экзотических классах планет, как образуются суперземли, и существуют ли они вообще.   

Итак, суперземли образуют наиболее обширный класс внесолнечных планет, известных в настоящее время. Суперземля в несколько раз крупнее Земли, но кратно меньше Нептуна. Она обладает обширной и плотной атмосферой, которая, вероятно, существенно увеличивает ее радиус. Суперземли часто встречаются в густо заполненных многопланетных системах красных карликов (звезд класса M), они располагаются близко от родительской звезды, именно поэтому период их обращения невелик – около 100 дней. Разница между землями и нептунами заключается, прежде всего, в массе и объеме атмосферы, но и те, и другие обладают крупным скалистым ядром. Суперземля меньше нептуна именно из-за того, что в процессе эволюции активно теряет атмосферу и уменьшается в диаметре. Основные причины такого уменьшения – рассеивание, испарение под действием света, охлаждение ядра и столкновения или близкие контакты с мелкими каменистыми телами, например, астероидами.    

Именно при помощи транзитного метода открыто большинство суперземель, известных сегодня. Транзитный метод очень точен, при определении радиуса планеты таким методом погрешность составляет не более 10%. Однако массу суперземли обычно гораздо сложнее определить, чем радиус; масса относительно достоверно высчитана примерно для 100 таких планет. Массу суперземли чаще всего находят методом вариаций моментов прохождений (TTV) и измеряя лучевую скорость. Поскольку в основе метода TTV лежит учет видимых орбитальных гравитационных возмущений, с его помощью измерена масса суперземель именно из многопланетных систем. Повышенное внимание к многопланетным системам также объясняется самой их кучностью: планеты разные, и в одной системе легче вывести закономерности их формирования. Также интереснее и информативнее пронаблюдать несколько планет, а не одну. По массе и объему суперземель также можно вывести их плотность и предположить, каков их примерный геологический состав. Совокупный анализ всех этих показателей позволяет заключить, что принадлежность планет к «суперземлям» во многом условна, так как эти планеты сильно отличаются по массе при относительно близком размере. В Солнечной системе такой разбежки не наблюдается ни между Землей и Венерой (скалистыми планетами), ни между Ураном и Нептуном (ледяными нептунами). Вероятно, это означает, что соотношение атмосфера-литосфера-(потенциально) гидросфера на суперземлях сильно отличается, и очень многие из них ближе по составу именно к Нептуну, чем к Земле. Кроме того, на суперземлях с плотной атмосферой граница между газообразными и жидкими слоями этой «атмогидросферы» может быть условной или колеблющейся. Именно эта неопределенность позволила в 2012 году всерьез усомниться в общепринятой планетезимальной концепции образования планет и сформулировать теорию галечной аккреции.

Галечная аккреция

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

Нельзя сказать, что гипотеза галечной аккреции сейчас способна заменить или потеснить гипотезу планетезималей. Некоторые аспекты геологического состава Земли (стратификация пород), а также состав пояса астероидов не позволяют исключить сценарий с планетезималями. Тем не менее, темпы образования планет при концентрации планетезималей не позволяют достоверно сформулировать, как за имеющееся время может быть пройден путь от пылинки до ядра такой планеты как Нептун. Даже если такой путь будет пройден, к моменту формирования этих ядер рассеются водород и другие газы, которые могли бы сформировать нептунианскую атмосферу. Таким образом, примирить гипотезу планетезималей и гипотезу галечной аккреции помогло бы понимание следующих факторов:

1. Как набор планет в конкретной системе зависит от состава и вязкости протопланетного диска;

2. Есть ли взаимосвязь в том, что в системах с несколькими суперземлями нет юпитероподобной планеты – ни горячей, ни холодной;

3. Как связана масса звезды и характеристики планет в ее системе.

В прошлом году в журнале The Astrophysical Journal Letters вышла статья голландского планетолога Гейса Мульдерса, работающего в Чили. Мульдерс сформулировал новую гипотезу формирования суперземель, позволяющую объяснить, почему в нашей системе ни одной суперземли нет.  

Он предположил, что именно газовый гигант, подобный Юпитеру, не дает образоваться суперземлям. В своих построениях ученый отталкивался от гипотезы галечной аккреции.

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

Но при определенной высокой вязкости протопланетного диска в его средней части возникает планета такого размера, как Юпитер, которая может достичь некоторой предельной «изолирующей» массы и практически перекрыть доступ камням, гальке и кометам во внутреннюю часть системы. Более того, такая планета собирает вокруг себя многочисленные спутники или кольца, выгребая последний твердый материал, и скалистые планеты во внутренней части системы оказываются мелкими, состоящими из материала, который не успели собрать один-два гиганта.

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

Эта картинка – результат симуляционной модели, разработанной в 2022 году Андре Изидоро из университета Райса, штат Техас. Он попробовал создать такую модель, обратив внимание на то, что практически идеальные круговые орбиты Меркурия, Земли и Марса соответствуют трем линиям: 1) линия сублимации силикатов, 2) снеговая линия воды и 3) снеговая линия углекислого газа. 

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

Аналогичная работа, выполненная в 2021 году сотрудниками Пенсильванского университета и университета Айовы, также позволяет обосновать феномен TRAPPIST-1, то есть, наличия плотной компактной планетной системы у красного карлика (звезды спектрального класса M). Поскольку такая звезда сравнительно маленькая и холодная, протопланетный диск вокруг нее узкий, и вещество в нем распределено сравнительно густо, а также прогрето слабо и равномерно. «Колец» из протопланетного материала не образуется, так как нет явного температурного градиента, а сам протопланетный диск не так велик, чтобы в нем образовалась планета-гигант. Вероятно, в таком облаке зародыши землеподобных планет и суперземель соседствуют друг с другом, определяющую роль в формировании планет и орбит играет орбитальный резонанс, а у планет могут быть крупные спутники, даже обладающие атмосферой.

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

Тонкая грань между Землёй и Нептуном

Итак, среди 5000+ экзопланет, более половины из которых открыл «Кеплер», не найдено ни одного экзомеркурия или экзоплутона. Вероятно, не потому, что их нет, а потому, что современные технологии поиска планет не позволяют их обнаружить, в особенности – транзитным методом. Если бы мы отыскивали экзопланету у такого желтого карлика как Солнце, то «экзомеркурий» закрывал бы примерно 1/285 звездного диска, а «экзоземля» — 1/194 этого диска, если наблюдать с Земли. Напротив, нептуноподобная планета обнаруживается транзитным методом гораздо легче, будучи в четыре раза больше Земли.

Разумеется, такой класс планет существует, но классификация «по массе» или «по радиусу» явно представляется натянутой, так как большинство экзопланет укладывается именно в «диапазон» между Землей и Нептуном. Поскольку подобного объекта в нашей системе нет, а также по причине подразумеваемой суперобитаемости суперземель мы, естественно, склонны считать такую планету «большой Землей», а не «голым ядром Нептуна». То есть, выдавать желаемое за действительное.

Попытки объективной классификации

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

Если масса экзопланеты не более чем вдвое превышает земную, то эта планета почти наверняка скалистая. Если масса экзопланеты превышает 15 земных, то это практически определенно нептун. Планет, попадающих «в середину» этого отрезка совсем мало, и в основном эти планеты скалистые. Но они расположены очень близко к своим родительским звездам и представляют собой не «суперземлю» и даже не «супервенеру», а всего лишь ядро нептуна, теряющее остатки атмосферы – и это ядро как раз оказывается в несколько раз крупнее Земли.

Более точные данные, также учитывающие плотность протопланетного диска, даже позволяют предположить, что для превращения в нептун скалистая планета должна достичь не 2, а всего лишь 1,2-1,3 земного радиуса и 1,5-1,6 земной массы, чтобы начать активно собирать газовую оболочку. Если бы планета вдвое массивнее Земли была в Солнечной системе, мы бы явно не сочли ее землеподобной, а сочли бы, что она похожа на измельчавший газовый гигант. Промежуток между 1,6 и 1,75 массами Земли, с большой вероятностью являющийся водоразделом между землями и нептунами, иногда именуется «разрыв Фултона».

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

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

1. Землеподобные планеты — подобны скалистым планетам Солнечной системы. На них могут быть океаны, ледники и атмосферы из кислорода, азота и их соединений, но не из водорода и гелия

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

3. Юпитеры — это наиболее массивные газовые гиганты, которые начинают уплотняться под собственным весом, и из-за этого их радиус со временем немного уменьшается. Так, Юпитер похож на Сатурн внешне, но при этом он втрое массивнее Сатурна, хотя и всего на 20% его крупнее.

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

Заключение

В начале 2022 года Майкл Чжан из Калифорнийского технологического института и его коллеги, наконец, обнаружили две планеты, которые должны находиться прямо в разрыве Фултона. Одна из них получила название TOI 560.01 (находится в 103 световых годах от Земли), а другая – HD 63443c (до нее 73 световых года от Земли). Анализ в рентгеновском спектре показывает, что обе эти планеты скатываются к собственным звездам и стремительно теряют остатки атмосфер; гелий улетучивается с TOI 560.01 со скоростью 20 км/c, а водород с HD 63443c – со скоростью 50 км/c. Вот как примерно это выглядит:

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

Привет! 

Мы решили сделать серию интервью с проектами, которые проходили или проходят акселерацию в Privacy Accelerator. Это, чтобы, как говорится, и себя показать (то есть проекты, а они у нас достойные!), и людей посмотреть — ведь на Хабре самая классная техническая аудитория, которая разбирается в нашей теме.

Сейчас в Privacy Accelerator стартует пятый набор, но мы по-прежнему на связи со всеми выпускниками прошлых лет. Некоторые из первых резидентов Privacy Accelerator опять с нами, но уже в новом формате — инкубатора. Сегодня поговорим с участником самого первого набора, осень 2020 года.

Знакомьтесь — Кирилл, основатель и  CEO проекта SelfPrivacy. Два года назад его команда была отобрана в акселератор и активно в нем поработала: проверила гипотезу, провела серию пользовательских интервью, опрос, выявила ключевые боли, сделала MVP и разработала дизайн. А еще презентовала свой проект на питчинге перед экспертами и зрителями Privacy Day 2021 в Москве. Затем продолжила работу в инкубаторе. Как проект попал в Privacy Accelerator? Как проходила работа и что было особенно ценно? Чем сейчас занимается команда и какие у нее планы?

• Привет! Расскажи пожалуйста о своем проекте. Чем вы занимаетесь? 

Боремся за независимость от корпораций и за право на неприкосновенность частной жизни в сети. Развиваем приложение, которое управляет личными облачными сервисами, такими как почта, чаты, файловое облако, парольный менеджер и т.п. И не сливает ваши данные.

• Как появилась идея создания этого проекта? 

Идея появилась когда я понял, что Гугл и прочие корпорации — это “пылесосы” приватных данных. Их успех зависит от объема собранных данных. Почти все их “инновации” — попытки узнать о вас больше, чтобы сильнее влиять на потребительское поведение.

Как опытный IT-эксперт, я пользуюсь независимым приватным ПО каждый день и сокрушаюсь, что оно недоступно рядовому пользователю. И вот уже два года как мы с командой автоматизируем и упрощаем управление личными облачными сервисами для не продвинутого пользователя. И у нас получается!

• Что было самое сложное вначале? 

Самое сложное это столкновение идеи с реальностью. Первая версия SelfPrivacy заработала через месяц после старта, но стабильность и надежность мы повышаем до сих пор и будем делать это постоянно. Ведь наша цель — дать пользователям альтернативу gmail. Мало просто настроить сервер, его надо обновлять, делать резервные копии, следить за местом на диске. Это превращает продукт из простого скрипта по настройки сервера, в сложную систему управления личным хостингом.

• Как ты оказался в Акселераторе?

Было одиноко, казалось, что мне одному это надо, что все смирились с  монополией корпораций. И никого не волнует неприкосновенность цифровой жизни. Но я был рад понять, что ошибаюсь. Случайно в телеге увидел объявление о наборе в акселератор, как раз по моей тематике. Очень обрадовался, что не один, что есть целое privacy-cooбщество!

• Что было самое полезное в Акселераторе?

Сам факт бескорыстной помощи. Я долго не мог поверить, что в мире победившего капитализма кто-то может помогать и ничего не требовать взамен. И что важнее, это нетворкинг, то, что появились новые друзья-единомышленники, крутые профессионалы, которые помогали в незнакомых областях, типа Customer Development и UI/UX.

• А чего не хватило в Акселераторе? 

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

• Если бы ты сейчас начинал новый проект, чтобы ты сделал в первую очередь? Может были какие-то фейлы, которых ты бы постарался избежать? Были ли какие-то правильные и крутые решения, которые помогли вам вырасти?

В начале проекта стоит смириться с тем, что в одиночку его не сделать. Каким бы ты крутым синьором айтишником не был, все равно есть недостаток компетенций в остальных областях: дизайн, UI/UX, CustDev, копирайт, тестирование, devops и т.п.

Второй момент, за один прилив энтузиазма проект не закончить. Будут качели отчаяния и безнадеги. Но если дело правое, есть команда и поддержка экспертов, сообщества, как, например, в акселераторе, — это очень поможет.

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

• Какая сейчас перед вами стоит задача? С какими сложностями сталкиваетесь? 

За два года SelfPrivacy сильно эволюционировал, команда выросла до пяти человек, и сейчас мы готовимся к запуску для всех платформ: google play-market, appstore, win, mac, linux. Проблемы в основном административного характера — сейчас очень сложно выводить проект с российско-украинско-казахскими корнями на международный рынок. Но мы уже на F-droid, с остальным справимся благодаря команде.

Будем рады вашим комментариям, предложениям и вопросам. И ждем вас в Акселераторе!

Первая публичная версия bash-5.2 теперь доступна по URL-адресам ниже. Подробности к старту курса по DevOps — под катом.

• ftp.cwru.edu/pub/bash/bash-5.2.tar.gz;
• ftp.gnu.org/pub/gnu/bash/bash-5.2.tar.gz;
• из ветки master git-репозитория bash;
• с обычных зеркальных сайтов GNU.

Bash — это проект GNU Bourne Again SHell, полная реализация спецификации оболочки POSIX с интерактивным редактированием командной строки, контролем задач на архитектурах, где это поддерживается, csh-подобный функционал (подстановка из истории и раскрытие скобок) и многое другое. Подробнее о функционале Bash, новом для этого типа оболочки, смотрите в файле doc/bashref.texi. Есть и большая man-страница, как на Unix, с полным описанием функционала оболочки.

Чтобы сообщать об ошибках в этой версии, воспользуйтесь bashbug. Программа собирается и устанавливается одновременно с bash.

Установка

Для начала прочтите файл README. Инструкции по установке находятся в файле INSTALL.

Новый функционал

Это обновление к пятому большому выпуску bash.

Полное описание нового функционала смотрите в файле NEWS дистрибутива bash-5.2. Ниже приведена копия соответствующих фрагментов.

В этом выпуске устранены баги версии bash-5.1 и добавлен новый функционал.

В числе устранённых — баги, из-за которых работа оболочки завершалась аварийно. Подробности — в файле CHANGES.

Самый заметный новый функционал — переписанный код парсинга подстановки команд, в котором рекурсивно вызывается bison. Это замена синтаксическому анализу прошлых версий, призванная улучшить проверку синтаксиса и отлавливать синтаксические ошибки намного раньше. Синтаксический анализ в оболочке должен стать намного лучше, допускается лишь однократное расширение индексов массива. Это выражается во встроенном unset, в расширениях слов, в условных конструкциях и т. д., в которых как побочный эффект могут присваиваться значения переменных. Встроенной командой unset в ассоциативных массивах отменяется установка ключа со значением индекса @ или *. Отменить её для всего массива можно с помощью unset arrayname.

Появился новый параметр оболочки patsub_replacement. Когда он включён, символ & в строке замены раскрытия подстановки шаблона заменяется частью строки, которая соответствует этому шаблону. Обратным слешем экранируется и вставляется в литерал символ &. Этот параметр включён по умолчанию. В bash добавлены случаи, при которых ветвление запрещено, в том числе в большинстве случаев с $(<file).

Описание всего нового функционала смотрите ниже.

Этот параметр появился и в Readline. В частности, новый параметр enable-active-region, с помощью которого активная область и bracketed-paste контролируются отдельно. Его значение по умолчанию для них одинаково, при активации bracketed-paste активируется и активная область. Теперь пользователи могут её отключить, оставив включённым bracketed-paste. Доступны две новые привязываемые строковые переменные. Их значения — escape-последовательности терминала, одной из которых задаётся цвет для отображения активной области, а другой он отключается. Будучи заданными, они используются вместо режима терминала standout. Наконец, в Readline теперь при каждом вызове проверяется наличие изменений в языковых настройках (`LC_ALL/LC_CTYPE/LANG`), а при изменении локали меняются соответствующее языковое отображение и переменные с привязками ключей.

Имеется несколько изменений, ломающих совместимость bash-5.1 и bash-5.2. Если уровень совместимости с оболочкой не более 50, в here-doc и here-строках используются временные файлы. Работа встроенного в bash-5.2 unset с индексами массива @ и * отличается от прошлых версий и зависит от того, индексный это массив или ассоциативный. B bash-5.2 должно предотвращаться двойное расширение индексов массива, которое происходит в определённых обстоятельствах (особенно при арифметических вычислениях), как если бы был задан параметр оболочки assoc_expand_once. Чтобы вернуться к прежнему поведению, задайте соответствующий уровень совместимости. Подробнее — в файле COMPAT.

При необходимости Bash можно связать с уже установленной библиотекой Readline, а не частной версией в lib/readline. Только в версии readline-8.1 и новее могут указываться все символы, необходимые для bash-5.2; работа прошлых версий библиотеки Readline не будет корректной.

Полный список изменений между bash-5.1 и bash-5.2 слишком большой, чтобы приводить его здесь. Он содержится в файле CHANGES.

Readline

Доступна версия 8.2 автономной библиотеки Readline с собственными скриптами конфигурации и файлами Makefile. Получить её можно по URL-адресам:

• ftp.cwru.edu/pub/bash/readline-8.2.tar.gz
• ftp.gnu.org/pub/gnu/readline/readline-8.2.tar.gz
• из ветки master git-репозитория GNU readline
• с обычных зеркальных сайтов GNU.

Форматированная документация Readline содержится в tar-файле дистрибутива readline. Изменения в Readline описываются отдельно. Как всегда, спасибо за вашу помощь.

Это краткое описание нового функционала bash-5.2. Как всегда, полные описания смотрите на справочной странице (doc/bash.1).

Новый функционал в bash.

1. В bash при вызове malloc возвращается память, выровненная по 16-байтовым границам.
2. Чтобы считывать тайм-ауты, используется новый встроенный фреймворк таймера.
3. Чтобы рекурсивно вызывать парсер и из проанализированной команды выполнять повторную сборку командной строки, переписан код для парсинга подстановки команд. В итоге — улучшается проверка синтаксиса, а ошибки отлавливаются намного раньше. При этом, если после парсинга подстановки команд остаётся считать here-doc, в оболочке выводится сообщение-предупреждение и тело here-doc считывается из текущего входного потока.
4. Операнд Во встроенном ulimit, который остаётся после анализа всех параметров и аргументов, теперь считается аргументом последней команды, указанной в параметре. Это нужно для совместимости с POSIX.
5. При считывании тела here-doc выполняется парсинг $'...' и $"...".
6. Возможна работа привязываемых readline-команд shell-expand-line и history-and-alias-expand-line с '...' и $"...".
7. Появилась привязываемая readline-команда spell-correct-word для проверки правописания текущего слова.
8. Во встроенном unset аргументы теперь должны считаться индексами массива без парсинга или увеличения индекса, даже когда не задан assoc_expand_once.
9. В config-top.h появилось значение по умолчанию для $BASH_LOADABLES_PATH.
10. Присваивание ассоциативного массива и некоторые случаи ссылок, например с test -v теперь можно использовать @ и * как ключи.
11. B bash, когда выполняются конструкции оболочки и расширения слов, индексы индексного массива должны раскрываться только один раз.
12. Во встроенном unset отменяется установка ключа со значением индекса @ или * для ассоциативных массивов. Отменить её для всего массива можно с помощью unset arrayname. В индексных массивах удаляются все их элементы без отмены установки ключа, например A=().
13. В других встроенных командах (printf/test/read/wait) лучше удаётся не выполнять парсинг индексов массива, если задан array_expand_once.
14. В числовой аргумент readline-команд задана новая переменная READLINE_ARGUMENT, определяемая с помощью bind -x.
15. Новый параметр оболочки varredir_close становится причиной автоматического закрытия в bash файловых дескрипторов, открытых с помощью {var}<fn и других стилей varassign-перенаправления, если это не аргументы встроенного exec.
16. В имени скрипта при запуске любых (неинтерактивных) загрузочных файлов, таких как $BASH_ENV, теперь задаётся специальный параметр $0.
17. В enable name при попытке включить встроенную команду без каких-либо параметров, которой нет, во встроенном enable должна загружаться (с помощью пути поиска по умолчанию) загружаемая встроенная команда.
18. Во встроенном printf появился спецификатор формата %Q. Отличается от %q тем, что к исходному аргументу без кавычек применяется любая заданная точность, затем он заключается в кавычки, и выводится результат.
19. Новым параметром noexpand_translations определяется, заключён ли в одинарные кавычки преобразованный вывод $«…».
20. Появился оператор преобразования параметров @k. В отличие от @K, после разделения слов результат в нём расширяется до отдельных слов.
21. Появилась альтернативная реализация массива, выбираемая во время configure (настройки). В ней скорость доступа оптимизируется за счёт бо́льшего расходования памяти (используется новый параметр конфигурации --enable-alt-array-implementation).
22. Если в перенаправлении [N]<&WORD- или [N]>&WORD- WORD раскрывается в пустую строку, оно будет считаться [N]<&- или [N]>&- и файловый дескриптор N (по умолчанию 0) закроется.
23. Недопустимые операторы преобразования параметров — это теперь недопустимые расширения слов, поэтому они становятся причиной неустранимых ошибок в неинтерактивных оболочках.
24. Появился новый параметр оболочки patsub_replacement. Когда он включён, символ & в строке замены раскрытия подстановки шаблона заменяется частью строки, которая соответствует этому шаблону. Символ & экранируется обратным слешем и вставляется литерал.
25. command -p больше не используется для поиска команд в хеш-таблице.
26. Чтобы включать в компиляцию или исключать из неё поддержку $«…», появился параметр configure -enable-translatable-strings.
27. Чтобы при раскрытии имени пути никогда не возвращалось . или . (если нет явно заданного соответствия), появился параметр оболочки globskipdots. Он включён по умолчанию.
28. Ссылки на массивы с использованием @ и * в качестве значения переменных nameref (declare -n ref='v[@]'; echo $ref) больше не становятся причиной выхода из оболочки, если включён set -u, а установка array (v) отменена.
29. Появилось новое название привязываемой readline-команды: vi-edit-and-execute-command.
30. В режиме posix встроенным printf проверяется наличие модификатора длины L. Для спецификаторов преобразования с плавающей точкой используется long double. А если их нет — double.
31. Появился параметр globstar, который учитывается при автодополнении кода в globbing. ff. С suspend -f теперь работа оболочки приостанавливается, даже если контроль задач отключён. gg. Поскольку нет declare - (эквивалента local -), использование local - в выводе local -p обязательно.

Новый функционал Readline

1. Номер версии библиотеки истории для использования в приложениях содержится теперь в HS_HISTORY_VERSION.
2. Дорабатывается множественное раскрытие истории со строками, которые раньше могли быть для этого препятствием (например, abc!$!$).
3. Появился новый фреймворк для тайм-аутов readline. И с ним новые общедоступные функции для задания тайм-аутов и запрашивания времени до их срабатывания. А ещё функция перехвата, которая может активироваться по истечении времени readline. Для указания тайм-аута теперь имеется новое значение состояния.
4. Сочетания клавиш с автоматической привязкой к termcap для пролистывания вперёд и назад history-search-backward и history-search-forward соответственно.
5. Для получения записи по числовому аргументу появилась новая привязываемая команда fetch-history. Отрицательные аргументы отсчитываются с конца истории.
6. Теперь vi-undo — привязываемая команда.
7. Появился параметр enable-active-region, с помощью которого активная область и bracketed-paste контролируются отдельно. Его значение по умолчанию для них одинаково, при активации bracketed-paste активируется и активная область. Теперь пользователи могут её отключить, оставив bracketed-paste включённым.
8. Теперь rl_completer_word_break_characters — это const char *, как rl_basic_word_break_characters.
9. Readline используется для поиска пользовательского расширения имени файла в $LS_COLORS (*.readline-colored-completion-prefix), которое используется в качестве цвета по умолчанию для отображения общего префикса, когда задан colored-completion-prefix.
10. Две новые привязываемые строковые переменные active-region-start-color и active-region-end-color. Первая — чтобы задавать цвет для отображения активной области, вторая — для её отключения. Будучи заданными, они используются вместо режима терминала standout.
11. С новым состоянием readline (RL_STATE_EOF) видимой в приложении переменной (rl_eof_found) в приложениях можно определять, когда в readline происходит считывание до EOF (конца файла) перед вызовом хука deprep-terminal.
12. Появился новый параметр конфигурации -with-shared-termcap-library, которым принудительно связываются библиотеки общего доступа readline и termcap (или curses/ncurses/termlib), так что в приложениях этого делать не нужно.
13. В readline теперь при каждом вызове проверяется наличие изменений в языковых настройках (LC_ALL/LC_CTYPE/LANG), а при изменении локали меняются соответствующее языковое отображение и переменные с привязками ключей.

Поможем разобраться в bash и не только, чтобы вы прокачали карьеру и стали востребованным IT-специалистом:

• Курс по DevOps (6 месяцев)
• Профессия Data Scientist (24 месяца)

Чтобы увидеть все курсы, кликните по баннеру:

Российский рынок труда для IT-специалистов вновь оживился. Мне регулярно приходится собеседовать кандидатов в команду «Иннотех». За сотни проведённых интервью скопился список типичных ошибок на пересечении hard и soft skills, которые чаще всего допускают претенденты на lead-позиции. Их исправление повысит шансы на получение желаемой должности.

1. Нет ответа на конкретный вопрос

Эта ошибка бесспорный лидер на собеседованиях. Кандидат не обязан знать ответа на каждый вопрос. Более того, это почти невозможно. Но, так или иначе, для эффективной работы с людьми важно умение слушать и слышать собеседника.

Рассмотрим реальный пример вопроса системному аналитику:

Вопрос: расскажите, для каких классов задач, на ваш взгляд, стоит применять асинхронные коммуникации и message-брокеры?

Ответ: асинхронный транспорт позволяет нам не ждать результата выполнения интеграционного запроса в рамках основного потока. А очереди на RabbitMQ мы активно применяли в одном из проектов, где задачи — бэктесты торговых стратегий — могли выполняться часами и даже сутками.

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

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

Вывод: без навыка чётко ставить вопросы и давать чёткие ответы будет сложно построить продуктивную коммуникацию с другими членами команды.

2. А порассуждать?

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

Рассмотрим такой вопрос: как вы думаете, системному аналитику стоит проектировать API своего сервиса или лучше оставить это полностью на откуп разработчикам?

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

От более опытных специалистов, разумеется, ожидается формулирование чётких аргументов по пунктам с готовностью защитить каждый. Ну и 80-й lvl достигается, когда кандидат может защитить несколько точек зрения, разграничив их по конкретным классам задач и процессам.

Вывод: не стоит пренебрегать возможностью продемонстрировать и навыки логического мышления, и умение аргументированно защищать свою позицию. До собеседования можно потренироваться в дебатах с коллегами по цеху или перед зеркалом. Кстати, в «Иннотех» уже проходили дебаты по теме «Разделение на PO и аналитика оправдано».

3. Нечёткое позиционирование

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

Пример хорошего ответа: последние 5 лет работал в телекоме на ведущей позиции, поэтому в этом домене однозначно senior, а вот в банкинге опыта ранее не было, поэтому скорее middle/middle+.

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

Вывод: важно подумать о своём позиционировании до собеседования, соотнести зарплатные ожидания с рынком соответствующего уровня, а также принять во внимание специфику конкретной деятельности компании и проекта.

4. Шаблонная мотивация

Мотивация к работе — один и ключевых «софтовых» признаков, на базе которых принимается решение о кандидате. Все мы работаем за деньги, и это нормально. Разумеется, возможна ситуация, когда, кроме финансового фактора, кандидата не интересует ничего другого, однако чаще всего в нашей сфере это не совсем так.

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

Пример плохого ответа на вопрос о мотивации: люблю интересные задачи, хочу профессионально расти, работать в сплочённой и дружной команде и так далее.

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

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

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

Вывод: очень полезно при подготовке к собеседованиям поразмышлять о собственной мотивации и зафиксировать её не только для интервью, но и для самого себя.

5. Обилие негатива

Эта ошибка тоже про мотивационную составляющую. А именно, как кандидат рассказывает про свой предыдущий опыт. Если в рассказе слышим один лишь негатив, то с вероятностью 99 из 100 история повторится вновь. Причины подавляющего большинства случаев смены работы в IT — это неудовлетворённость чем-либо на текущем месте. Нормально быть чем-то недовольным и в спокойной форме этим делиться, но если плохо сразу всё, то такая позиция заставляет задуматься.

Примеры здорового выражения негатива: незрелые процессы, постоянная смена приоритетов и вектора развития продукта, обилие давящей бюрократии и политики, устаревший стек технологий.

Для позиций senior/lead обязательно задаём вопросы «А что вы сделали, чтобы исправить ситуацию?», «Обсуждали ли проблему с руководством?», «Предлагали ли свои решения?». Если ответы неконкретные, то весьма вероятно, что на новом месте сотрудник будет так же накапливать в себе негатив и рано или поздно «взорвётся» и уйдёт.

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

6. Книжная и не очень лексика

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

Пример: применив кэш второго уровня, мы получили прирост производительности запросов к базе на 30–40%.

Сложно представить, как сложно было бы рассказать про это без употребления термина «кэш». В профессиональной среде разработчиков, архитекторов, аналитиков никто не подумает о том, при чём тут наличность. Такие примеры на интервью вызывают желание попросить кандидата рассказать о кейсе поподробнее.

Если терминология не употребляется, в частности, и там, где было бы очень уместно, то либо кандидат ей не владеет, либо не умеет применять. Но есть и другая крайность:

Пример ответа на вопрос (далее цитаты из статьи на wiki): REST — архитектурный стиль взаимодействия компонентов распределённого приложения в сети… REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиасистемы…

Такая лексика в устной речи наводит на мысль, что ответ был заучен или читается с той самой статьи на экране. Более того, термин «гипермедиасистема» так и просится, чтобы в разговорной речи убрать пресловутую «гипермедиа».

Вывод: здорово владеть профессиональной терминологией и применять её, но не менее важно сохранять диалог живым, не перегружая его книжной лексикой.

7. Непонимание своей миссии

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

При этом даже сеньоры зачастую дают весьма расплывчатые ответы на вопрос о том, какова твоя основная задача как аналитика, разработчика, архитектора.

Ответ опытного архитектора о своей миссии в проекте, который вызывает ещё больше вопросов: архитектор играет роль связующего моста между бизнесом и командой разработки.

И вроде бы явно не глупость и во многом соответствует действительности, только здесь опять же смотрим пункт №1. Мост между заказчиком и командой разработки — это не только архитектор, но и бизнес-аналитик, и руководитель проекта, и product owner, а вот задачи у каждого свои. При этом, разумеется, нет никаких сомнений в том, что общее представление о своём назначении имеется и у джуна, и у лида.

Вывод: будет весьма полезно иметь простой, понятный и лаконичный ответ на вопрос о предполагаемой зоне ответственности в предлагаемом проекте.

8. Нежелание работать с документацией

Творческие люди склонны не любить кропотливую и зачастую рутинную работу с документами. В разных компаниях и процессах уровень бюрократии различается. Как правило, чем компания больше, тем большее внимание уделяют качеству документации и соблюдению процессов её согласования.

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

Пример с диалогом на позицию старшего QA:

— Расскажите, каким образом, на ваш взгляд, лучше вести учёт тест-кейсов в интеграционном проекте в банке.

— Не вижу большого смысла тратить время на их учёт, так как продукт меняется очень быстро, многие быстро становятся неактуальными, тестирует продукт всё равно одна и та же команда.

Разумеется, здесь можно и нужно поспорить, так как отсутствие документации по тестовым планам и сценариям может привести на проекте к массе проблем: bus-фактор ключевых QA, сложный и долгий процесс передачи знаний новому сотруднику, невозможность эффективной автоматизации тестирования и так далее. Но самое главное про кандидата в этом ответе уже стало понятно: раз он сам не любит работу с документацией, то тестирование сможет построить только в команде из 2–3 человек, но это не будет масштабируемой и системной организацией процессов.

Вывод: в собеседованиях любого типа компаниях больше начинающего стартапа стоит быть готовым к вопросам о документации. Противники её ведения имеют существенный риск не стать team player.

9. Незнание хороших и плохих процессов

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

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

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

Диалог с разработчиком уровня middle+/senior:

— Вы упоминали о том, что в текущем проекте у вас накапливается много техдолга, на который никогда не было времени, в результате чего он рос как снежный ком. Как бы вы предложили решить этот вопрос?

— Не раз предлагал на уровне проектного менеджера и владельца продукта выделять каждый второй спринт не менее 15% ресурса разработки на задачи техдолга и рефакторинга, однако всегда получал ответ, что сейчас очень много критически важных для бизнеса задач, которые никак не можем отложить.

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

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

10. Неискренность

Общаясь с аналитиком, архитектором, разработчиком, мы всегда так или иначе примеряем на себя возможность работать с ним в команде. Поэтому даже случайно продемонстрированные кандидатом soft skills будут ожидаться от него и в будущей работе.

Чем более непонятным для собеседующего остаётся кандидат после проектного интервью, тем больше будет сомнений в пользу офера. Любая скрытность, наигранность, неискренность, фальшь, уход от ответа будут заведомо трактоваться не в его пользу.

Вывод: искренне рекомендую всем быть на собеседовании самим собой, проявлять простоту и искренность, стараться быть, а не казаться. В таких условиях наиболее вероятно, что удастся продемонстрировать то, что умеете, проявить лучшие качества и установить тёплый контакт с будущим руководителем. Чем больше в уравнении переменных, тем сложнее его решить. Это правило применимо и к людям.

What’s next

Устранение описанных ошибок существенно увеличивает шансы получить желаемую позицию. Кроме того, собеседования пройдёт менее напряжённо и более комфортно как для интервьюера, так и для интервьюируемого.

Рекомендую сохранить статью в закладки, чтобы она была под рукой, когда захочется сменить место работы. И всем прочитавшим желаю продуктивных собеседований.