Писать ответы на статьи легко и приятно. Не надо часами корпеть над структурой статьи, достаточно следовать чужому плану и лишь внятно изложить мысли на бумаге. Тем не менее, рискну предположить, что критический взгляд «с другой стороны» на проблемы, поднятые в статье "Страх и ненависть в IT" уважаемым eugene_crabs, все же будет интересен. В роли адвоката дьявола, защищающего бесчеловечную системы выступаю сегодня я.
Я, в отличии от него, лычек сеньора не ношу, и стаж разработки у меня на пару лет поменьше, да и профильного образования, у меня, если честно, нет. Но вот проблем у меня с базовым интересом к работе не было, и мне кажется — причина в несколько ином восприятии реальности.
Статья для широкого круга читателей.
RE: Чрезмерная сложность
Отдельная тема — это господин Джаваскрипт с его бесчисленными фреймворками. Я честно не понимаю, как можно было изобрести СТОЛЬКО штуковин для инструмента, которому нужно просто нарисовать формочки на веб-страницы и время от времени отправлять запрос на бекенд. Хорошо, что я занимаюсь бэкендом.
На примере фронтенда (да и не только его) хорошо заметно, как мы ходим по кругу: давайте всю логику выполнять на стороне сервера -> а давайте теперь на стороне клиента -> а давайте теперь снова на сервере и так до бесконечности. Давайте фронтенд и бекенд писать на одном языке -> а давайте теперь на разных -> а давайте снова на одном. Давайте сделаем схемы для форматов данных -> схемы только для старпёров -> а не, схемы нужны всё таки. Один мой кореш перепиливает свою опенсорсную библиотеку с yaml на xml, просто потому, что там есть схемы и это очень здорово, когда клепаешь огромный конфиг, а IDE, осведомленная о XSD сама может выполнить за тебя половину работы. Из вышесказанного вытекает следующая проблема
Безусловно, приятно манипулировать простыми системами. Я понимаю ту магию, когда ты понимаешь, как это работает до мельчайших деталей: когда спускаешься на уровень ассемблера и машинного кода, и когда идешь еще глубже — туда, где процессор представляет собой ряды логических вентилей.
Текущая ситуация такова, что мейнстримовые разработки и в ПО и в железе процессоров уже очень далеки от кристального понимания того, как это работает, отдельно взятым человеком: процессоры полны генерированной логики, разноуровневого кеша и предсказателей ветвления настолько, что баги в них не то, что не замечаются, а даже не предполагаются целыми командами разработчиков, и цветут настолько буйным цветом, что прорываются в своих эффектах на уровень пользователя. Кроме того, мы вынуждены тащить за собой огромный багаж старых функций, обеспечивая тем самым обратную совместимость, иначе выиграем в скорости и простоте, но проиграем в работе того, под что это железо изначально разрабатывалось.
С софтом та же ситуация: понимание, и тем более написание ассемблерных инструкций осталось лишь в узко-специализированных областях, а в том, что живет и крутится в непосредственной близости от пользователя, безраздельно царят фреймворки и слои абстракции.
С точки зрения человека, желающего контролировать свой код и машину — это плохо. С точки зрения пользователя — хорошо, так как упрощает понимание, работы и путь от идеи к продукту. Цена, которую платим мы за это желание пользователей — то, что растущие мощности процессоров тут же сжираются сложностью программ, которая, вроде бы, ничем не обоснована, и не несет никаких плюсов (вэээээлью, как говорили на моем предыдущем месте работы).
Однако, если копнуть глубже, окажется, что мы меняем эти ресурсы на увеличение аудитории за счет упрощения взаимодействия. Если раньше терминалы заказа авиабилетов требовали знания сокращений, понимания, как работают авиакомпании и навыка работы с текстовым терминалом, то теперь любой пользователь заходит на условный Aviasales, и подбирает себе дешевый билет по сложному маршруту без особого геморроя.
Нельзя сделать понятный среднему человеку интерфейс на текстовом терминале, потому что понятность интерфейса — это и разрешение монитора, и приятные картинки, которые не пугают , и красивые шрифты, и подсказки, всплывающие при наведении на кнопку, и сенсорный интерфейс.
А еще, возможность тестировать все эти фишки, ориентируясь на поведение пользователя. Работая по waterfall, вы выкатываете релиз раз в год, собирая отзывы на текущую версию весь год. До какой-то стадии интерфейса вы идете десять лет, десять релизов. Выкатывая мелкие исправления и тестируя их тут же, вы придете к той же стадии через год-полтора. Но такая работы требует другого темпа, других инструментов и технологий, и отказа от некоторых вещей. В честности, от вылизывания кода: все должно работать сейчас, потому что того требует процесс такого темпа.
Взамен, эта сумасшедшая гонка за новыми фичами дарит нам растущую пользовательскую базу: чем проще нажимаются кнопки, тем больше людей смогут их нажать, а растущая пользовательская база несет деньги не только в ваши зарплаты, но и в разработку нового железа. Чем больше людей смогут продуктивно пользоваться смартфоном, тем больше его купят, тем лучше будет железо в следующей версии. То, что мы тут же размениваем это железо не на полеты на марс, а на растущую аудиторию… ну, это можно сравнить с компанией, которая вкладывает весь заработок в развитие, а не в дивиденды и прибыль в годовом отчете. Только вот вы почему-то оправдываете, когда так делают Маск и Безос, но не можете оправдать индустрию.
Хорошо это или плохо — можно спорить. С одной стороны качество ПО, с другой — постоянный прогресс в железе, аудитория и большие зарплаты в индустрии. Я, пожалуй, выберу второе (хоть и предпочел бы сбавить темп), но пойму людей, которые выберут первое.
Но объединит нас одно — мы ничего не сможем с этим сделать.
RE: Слишком много всего
Но даже плотная работа с определенным ЯП или, к примеру, СУБД в своей компании иногда не дает возможности оставаться в тренде, т.к. технологии устаревают раньше, чем их успевают применять. Даже джава сейчас релизится со скоростью фаерфокса.
Благодаря бесконечному потоку быстроустаревающих знаний многие из нас чувствуют себя вечными студентами или самозванцами, неважно сколько систем ты реально построил. И это очень на руку HRам и работодателям — ведь легко можно сбить твою ЗП парой заковыристых вопросов. Такой вид крысиных бегов HRы политкорректно называют саморазвитием.
То, что инструментов много — это логическое продолжение предыдущего пункта. Когда в области много энергии, это позволяет тратить лишнюю энергию на тестирование гипотез, часть из которых окажется провальными, часть засохнет, а вот часть ляжет в основу новых стандартов индустрии. Жалобы на хаос подобны жалобам на неэффективность эволюции, которая зачем-то создала кучу видов, огромная часть из которых тихо вымерла, и еще большая часть не очень успешна, и прозябает в узком ареале. Неужели нельзя было сразу создать человека, который может выжить хоть на северном полюсе, хоть в пустыне, несмотря на то, что сам довольно хилый — бегает небыстро, когтей нет, зубы маленькие и тупые, угол обзора небольшой.
На результат эволюции хорошо смотреть со стороны, и удивляться про себя, какой долгий путь потребовался для создания вполне очевидного преимущества — гибких пальцем и развитого .
Но вот в самом начале пути результат был совсем не так однозначен: динозавры-то тоже когда-то царили на земле безраздельно, и живи биржевые аналитики в их времена, мало бы кто поставил на каких-то млекопитающих крысок против этого явного фаворита.
Отходы в виде «неправильных» инструментов — это постоянный спутник того пути, что ведет на вершину.
RE: Программист должен быть бизнес-аналитиком & Собеседования
Собеседования
Это самый важный и горячо любимый мною вид спецдисциплины. Ведь по факту именно от этого зависит будешь ли ты спать на старом продавленном диване в арендованой однушке где-то за МКАДом, или же придется укрываться картонкой лежа на теплотрассе под мостом. Если в начале моей карьеры собеседование было чем-то типа разговора по-душам, то сейчас это больше напоминает экзамен. Возможно это связано с тем, что в те времена не было таких огромных зарплат и толп желающих войти в айти или просто мода, я не знаю. Но факт в том, что придя на собеседование на позицию старшего разраба, с огромной долей вероятности ты столкнешься с задачками, приправлеными вопросами-викториной. “Ну-ка реши на бумажке задачку, которую мы вчера стащили с leetcode. Ошибся на единичку в граничном условии? Фууууу лох! Не знаешь, как работает %methodName% в моднейшем %frameworkName%. Кто его вообще сюда пустил? Охрана!” Никого больше не волнует, что твоя голова устроена по-другому и ты не можешь в стрессе под презрительно-снисходительным взглядом высоколобых ботанов быстро и без ошибок наваять алгоритм под задачу, над которой ты и подумать ещё не успел. Как и то сколько за твоей спиной километров кода и продакшон-систем. Хорошо хоть вопросы-головоломки сдохли, и на том спасибо.
Да нет, не должен конечно. Но в условиях необходимости быстрой проверки гипотез, гораздо продуктивнее это делать в той же голове, которая принимает решения о архитектуре, просто потому что накладных расходов меньше: надо не два дня совещаться, а час подумать. Умеете в предметную область — молодец, спи на продавленном диване. Не умеешь — тебя ждут в тех областях, где надежность важнее прогресса: космос, медицина, военка, системы сигнальной связи. Эти области есть, и они ничуть не менее важны фронтенда. Правда, платят меньше. Такой уж перекос на рынке, который бы и я бы хотел исправить, но это нечто, что выше не только человека, но и большинства компаний.
Кстати, этот же фактор позволяет несколько свысока посматривать на HR с заковыристыми вопросами, вплоть до «не знаю я, чего пристали, давайте уже с техдиром пообщаемся». Не хотите быть аналитиком, а хотите писать код по готовому вылизанному ТЗ? См. выше — другие области для вас: хорошие программисты, не делающие ошибок и качественно и грамотно реализующие ТЗ тоже очень нужны.
RE: Айтишники
Собственно разработчики и сочувствующие. Вопреки стереотипам — в большинстве своём не ортодоксальные ботаны, а вполне себе нормальные ребята. Вот только как правило говорить с ними не о чем. Все разговоры во внерабочее время сводятся к работе. А как иначе, если ты вынужден круглосуточно вызубривать всю эту техномуть? Мой совет — держитесь подальше от ребят в клетчатых рубашках с рюкзаками, иначе можете заработать летальную дозу скуки. Многие из них ходят на работу не работать, а играть в игрушки. Давайте изобретем велосипед, давайте прикрутим новый фреймворк (и будем по ночам разгребать ад на проде) и непременно бросим всё на полпути, потому что эта игрушка надоела, к тому же новые завезли. Зато потом будем дуть щеки и рассказывать на конференциях, как мы победили проблему, которую сами же и создали. PROFIT! Эти люди так же легко ведутся на всякую чушь типа “интересных задач” и “сложных систем” (в айти культ сложных систем, поэтому калькулятор без десятка микросервисов сейчас построить нельзя), что в переводе на человеческий означает ковыряние в прокисшем дерьме мамонта, но за меньшие деньги, тем самым снижая ЗП по отрасли. Как в анекдоте “- Папа, а что мы сегодня будем кушать? — Ничего, сынок, я работаю над интересными задачами в дружном коллективе.”
Проджект-менеджеры. Честно говоря, за 10 лет я так и не понял кто такие проджект-манагеры и зачем они нужны. В совершенно разных конторах это выглядело примерно так: вот там пачка задач, разберитесь чего там и как и вот до такого-то числа сделайте. А я пошел возьму латте у хипстеров на первом этаже и напишу в инстаграме какой сегодня тяжелый день. Только однажды я видал чувака, который строил все эти скучные графики, жонглировал задачами и был нашим помощником, а не просто классным парнем, который не смог в программирование, но айтишную ЗП очень хочется.
Вайтишники. Нежно любимая многими категория. Благодаря их демпингу толковые и идейные джуны не могут въехать в индустрию — в погоне за длинным рублем, многие вкатывальщики готовы работать вообще бесплатно.
Про остальных умолчим.
Скучные разработчики, которые говорят только о работе? Странно, мне кажутся скучными те, кто хочет спокойно пилить код по готовому ТЗ с 9 до 18. Мы оба не правы, но я немного о другом: такая организация ума, при которой задача крутится в голове постоянно, дает весомый буст к скорости разработки и проверки гипотез. Чуть за грань, и там маячит выгорание, но это вопрос контроля ментального здоровья. Что не отменяет того факта, что некоторые компании (не будем показывать пальцем на тех, кто оплачивает сотрудникам такси после 22 часов, стимулируя задерживаться на работе) поняв, что горящий сотрудник работает лучше, предоставляют все условия для этого горения.
Проджекты? Вы просто не умеете их готовить. Проджект — это универсальный инструмент: с одной стороны, он берет на себя волшебные пинки для программистов (программист, предоставленный сам себе, переключается на производство приколюх для себя любимого), а с другой стороны, архитекторы и тимлиды могут сбрасывать на него львиную долю организаторской работы по организации встреч, поддержании актуальности графика, отчетам о проделанной работы, рутинной коммуникации с заказчиком и так далее.
RE: Бизнес
Тем кому важно как — чтобы внутри было всё красиво и правильно.
Тем кому важно что — те люди, которым важна суть продукта, который они делают.
Обычно в разработчике содержатся обе эти категории, просто в разных пропорциях.
Для обоих из них у меня есть печальные новости.
Для первой категории — с точки зрения зарабатывания денег абсолютно неважно насколько правильная архитектура выбрана и насколько красив код. Точно так же как и на всю эту вашу безопасность, лучшие практики, etc. Можно навтыкать костылей, заработать бабок, а дальше тот манагер, который всё это учинил спрыгивает на соседнюю шлюпку “получать новый опыт”, а команда ночами разгребает конюшни.
Для второй категории — 90% из вас делает то, что уже давно сделано другими. За редким исключением, все ваши продукты глубоко вторичны. Но тем не менее, ушлые дельцы пытаются придать “идейность” очередной платежной системе, онлайн-банку и тому подобному. Я сам все это проходил, и надо сказать, гораздо легче работать, когда у тебя есть четкий ответ на вопрос “зачем всё это нужно”. Все эти “менятели” мира почему-то забывают сказать, что изменение мира происходит как побочный результат зарабатывания денег, а не наоборот. Тяжело менять мир, когда к твоему виску приставлено дуло дробовика совета директоров, а на шею накинута удавка акционеров. Как по мне фраза “мы работаем для того, чтобы заработать денег” звучит гораздо честнее. Другое дело, что если сейчас сказать HRу, что ты работаешь на работе за деньги, то 146% получишь в ответ недоуменный взгляд и что-то типа “Вы нам не подходите, нам нужны увлеченные люди, которым важны саморазвитие и интересные задачи”.
Так уж случилось, что человек придумал деньги. Сделали это не в текущем поколении, и даже не сто лет назад. Деньги показали себя отличным инструментов для организации разнородного общества с разными понятиями о прекрасном и разными желаниями входящих в него людей.
Вы можете попробовать изобрести что-то другое, но пока что-то ничего кардинально лучше не придумали. Есть, конечно, мотивация типа социальной поддержки и командного духа, но первая — производная от денег, которые переварило государство, а второе — приправа, а не основное блюдо. В крайнем случае, десерт.
За вашу работу вам платят деньги. Если ваша работа не приносит денег — простите, она не нужна бизнесу. Грубо, знаю. Давайте попробуем мягче.
Бизнесу нужны деньги. Бизнес — это организация, которая зарабатывает деньги. Если вам не дают денег на то, что вы считаете нужным — значит, вы не показали, как эта штука принесет бизнесу еще больше денег. Научитесь обосновывать трату ресурсов, докажите, что это приносит пользу, пусть даже долгосрочную, и ресурсы будут. Бизнес и ЛПР бизнесу в этом плане гораздо адекватнее среднего человека, правда: там где человек будет жаться купить проездной на пол-года за десять тысяч, потому что это так много денег, и предпочтет покупать каждый месяц проездной за две тысячи, бизнеса интересует лишь одна цифра — прибыль на вложенные деньги. 16% прибыли? Берем! Нет денег, но можно взять кредит на эту траты за 5%? Берем!
Если в некой компании не удается обосновать ревью кода, потому что их код живет три месяца, после чего заменяется новым, то бегите оттуда, что вы там делаете? Есть огромное количество компаний, для которых ревью кода и рефакторинг — важные компоненты процесса. А первая компания сосредоточена на проверке гипотез, а не на кодинге: это тоже нормально, и позволяет найти новую нишу, в которой можно вырасти, заматереть, накопить жирок и начать практиковать ревью и рефакторинг.
Не стоит осуждать дизайнера, который строит домик из игрушечных кирпичей, не скрепляя их раствором: жить в этом домике хомячку, и задача этого дома — протестировать гипотезу внешнего вида, а не служить домом. И даже если этот дизайнер готов платить вам за то, что вы помогаете ему строить его игрушечный домик, не брызгайте на него слюной на то, что нужен раствор и котлован, а устройтесь в нормальные строители.
RE: Здоровье
Пожалуй, это единственный пункт, на который мне нечего полноценно ответить. Кроме того, что в моем мире человек обладает волей и разумом, и если считает, что ему не надо поднимать тяжести, то он не будет их поднимать.
Автор: Влад
