Страх и ненависть в IT
Всем привет. Я — обычный программист, носящий лычку сеньора в одной обычной продуктовой компании. Я занимаюсь коммерческой разработкой около 10 лет, начинал с разработки прошивок для небольших железок, а сейчас изготавливаю бекенды различной степени сложности преимущественно на модных нынче Java/Kotlin. Эту профессию я выбрал по призванию — будучи ещё школьником все время что-то паял, программировал на бумажке (компьютера не было) и всё такое. Дальше шли профильное образование, работа в различных компаниях — именитых и обычных, зарубежных и отечественных. Поэтому я могу сказать, что являюсь идейным программистом. И никогда не понимал людей, которые ждут пятницу — всегда с удовольствием ходил на работу, какой бы ад там не творился. Так было по-крайней мере до недавнего времени. С какого-то момента я “сломался” и с трудом мог заставить пойти себя на некогда любимую работу. Меня и раньше что-то смущало, но теперь, когда мысли до конца оформились в голове — я могу сказать, что же не так с моим некогда уютным IT-мирком.
Когда я занимался железками, мне очень нравилось то свойство, что я насквозь вижу как работает эта штуковина — какие байтики шевелятся, в какой области памяти это происходит и как обошелся с кодом компилятор. Было чувство спокойствия и контроля. Когда чуть позже я перешел в бекенд разработку, я хихикал над бесконечными xmlками конфигураций для EJB или того же спринга. Знал бы я, что меня ждет в будущем. Сейчас я просто не понимаю (и уже отчаялся понять), что происходит внутри моей же несложной приложухи. Куча слоев абстракций, контейнеров в контейнерах, тонны мануалов, скриптов, инструментов, версий, конфиг-файлов. Я до сих пор не разобрался, как деплоится проект, над которым работаю уже полгода. И конечно же нельзя сделать монолит, хотя бы на первом этапе. Обязательно нужно сразу же разделить всё на микросервисы, потому что так правильно (на конференции сказали, что так делают в компании Х). И конечно же мы не можем использовать старый добрый Apache HTTP Client для хождения вооон в тот сервис, который нам нужен 1 раз в несколько минут, ведь этот клиент недостаточно асинхронен, а также в нем нет встроенного рейт лимитера, механизма backpressure и прочих модных штук. На мой вопрос “А зачем это всё нужно для нагрузки 1 запрос/мин?” получаю лишь укоризненный взгляд от коллег, на лбах которых светится надпись “Вот ты тупоооой”.
Отдельная тема — это господин Джаваскрипт с его бесчисленными фреймворками. Я честно не понимаю, как можно было изобрести СТОЛЬКО штуковин для инструмента, которому нужно просто нарисовать формочки на веб-страницы и время от времени отправлять запрос на бекенд. Хорошо, что я занимаюсь бэкендом.
На примере фронтенда (да и не только его) хорошо заметно, как мы ходим по кругу: давайте всю логику выполнять на стороне сервера -> а давайте теперь на стороне клиента -> а давайте теперь снова на сервере и так до бесконечности. Давайте фронтенд и бекенд писать на одном языке -> а давайте теперь на разных -> а давайте снова на одном. Давайте сделаем схемы для форматов данных -> схемы только для старпёров -> а не, схемы нужны всё таки. Один мой кореш перепиливает свою опенсорсную библиотеку с yaml на xml, просто потому, что там есть схемы и это очень здорово, когда клепаешь огромный конфиг, а IDE, осведомленная о XSD сама может выполнить за тебя половину работы. Из вышесказанного вытекает следующая проблема:
Инструментов, языков, книг, конференций, фреймворков и т.д. Уже давно позади те времена, когда для разработки софта достаточно было знания одного ЯП, пары библиотек и в общем-то и всё. Теперь нас ожидают сотни фреймворков, с десяток языков (даже в рамках одного проекта), модные и не слишком СУБД, вездесущие брокеры сообщений, сотни квадратных километров разложенных граблей и прочего веселья. У среднестатистического программиста как правило нет времени на изучение всего этого на работе (кроме тех инструментов, что уже используются в его проектах), потому что на ней надо работать. Многим приходится тратить личное время на изучение этих технологий, хотя скорее всего 90% из изученного никогда не пригодится. У меня самого в покете лежит полтысячи статей, куча непосмотренных видосов с конференций, а каждый заход на Хабр предвещает обязательный визит Макконахи.
Но даже плотная работа с определенным ЯП или, к примеру, СУБД в своей компании иногда не дает возможности оставаться в тренде, т.к. технологии устаревают раньше, чем их успевают применять. Даже джава сейчас релизится со скоростью фаерфокса.
Благодаря бесконечному потоку быстроустаревающих знаний многие из нас чувствуют себя вечными студентами или самозванцами, неважно сколько систем ты реально построил. И это очень на руку HRам и работодателям — ведь легко можно сбить твою ЗП парой заковыристых вопросов. Такой вид крысиных бегов HRы политкорректно называют саморазвитием.
В последнее время я наблюдаю тренд навязывания разработчикам полномочий бизнес-департамента. Теперь помимо выполнения своих основных задач, разраб обязан разбираться в предметке на уровне хорошего аналитика и вообще думать про бизнес. Отстаньте от меня, я не знаю как повысить вашу конверсию
Это самый важный и горячо любимый мною вид спецдисциплины. Ведь по факту именно от этого зависит будешь ли ты спать на старом продавленном диване в арендованой однушке где-то за МКАДом, или же придется укрываться картонкой лежа на теплотрассе под мостом. Если в начале моей карьеры собеседование было чем-то типа разговора по-душам, то сейчас это больше напоминает экзамен. Возможно это связано с тем, что в те времена не было таких огромных зарплат и толп желающих войти в айти или просто мода, я не знаю. Но факт в том, что придя на собеседование на позицию старшего разраба, с огромной долей вероятности ты столкнешься с задачками, приправлеными вопросами-викториной. “Ну-ка реши на бумажке задачку, которую мы вчера стащили с leetcode. Ошибся на единичку в граничном условии? Фууууу лох! Не знаешь, как работает %methodName% в моднейшем %frameworkName%. Кто его вообще сюда пустил? Охрана!” Никого больше не волнует, что твоя голова устроена по-другому и ты не можешь в стрессе под презрительно-снисходительным взглядом высоколобых ботанов быстро и без ошибок наваять алгоритм под задачу, над которой ты и подумать ещё не успел. Как и то сколько за твоей спиной километров кода и продакшон-систем. Хорошо хоть вопросы-головоломки сдохли, и на том спасибо.
Тут разберем несколько подвидов этой популяции, с которыми чаще всего приходится иметь дело.
Собственно разработчики и сочувствующие. Вопреки стереотипам — в большинстве своём не ортодоксальные ботаны, а вполне себе нормальные ребята. Вот только как правило говорить с ними не о чем. Все разговоры во внерабочее время сводятся к работе. А как иначе, если ты вынужден круглосуточно вызубривать всю эту техномуть? Мой совет — держитесь подальше от ребят в клетчатых рубашках с рюкзаками, иначе можете заработать летальную дозу скуки. Многие из них ходят на работу не работать, а играть в игрушки. Давайте изобретем велосипед, давайте прикрутим новый фреймворк (и будем по ночам разгребать ад на проде) и непременно бросим всё на полпути, потому что эта игрушка надоела, к тому же новые завезли. Зато потом будем дуть щеки и рассказывать на конференциях, как мы победили проблему, которую сами же и создали. PROFIT! Эти люди так же легко ведутся на всякую чушь типа “интересных задач” и “сложных систем” (в айти культ сложных систем, поэтому калькулятор без десятка микросервисов сейчас построить нельзя), что в переводе на человеческий означает ковыряние в прокисшем дерьме мамонта, но за меньшие деньги, тем самым снижая ЗП по отрасли. Как в анекдоте “- Папа, а что мы сегодня будем кушать? — Ничего, сынок, я работаю над интересными задачами в дружном коллективе.”
Проджект-менеджеры. Честно говоря, за 10 лет я так и не понял кто такие проджект-манагеры и зачем они нужны. В совершенно разных конторах это выглядело примерно так: вот там пачка задач, разберитесь чего там и как и вот до такого-то числа сделайте. А я пошел возьму латте у хипстеров на первом этаже и напишу в инстаграме какой сегодня тяжелый день. Только однажды я видал чувака, который строил все эти скучные графики, жонглировал задачами и был нашим помощником, а не просто классным парнем, который не смог в программирование, но айтишную ЗП очень хочется.
Вайтишники. Нежно любимая многими категория. Благодаря их демпингу толковые и идейные джуны не могут въехать в индустрию — в погоне за длинным рублем, многие вкатывальщики готовы работать вообще бесплатно.
Про остальных умолчим.
Софт в современном мире не делается просто потому, что это прикольно (хотя иногда так кажется). Он делается чаще всего для зарабатывания бабок — прямо или опосредованно. И в связи с этим фактом можно разделить людей на 2 категории.
Тем кому важно как — чтобы внутри было всё красиво и правильно.
Тем кому важно что — те люди, которым важна суть продукта, который они делают.
Обычно в разработчике содержатся обе эти категории, просто в разных пропорциях.
Для обоих из них у меня есть печальные новости.
Для первой категории — с точки зрения зарабатывания денег абсолютно неважно насколько правильная архитектура выбрана и насколько красив код. Точно так же как и на всю эту вашу безопасность, лучшие практики, etc. Можно навтыкать костылей, заработать бабок, а дальше тот манагер, который всё это учинил спрыгивает на соседнюю шлюпку “получать новый опыт”, а команда ночами разгребает конюшни.
Для второй категории — 90% из вас делает то, что уже давно сделано другими. За редким исключением, все ваши продукты глубоко вторичны. Но тем не менее, ушлые дельцы пытаются придать “идейность” очередной платежной системе, онлайн-банку и тому подобному. Я сам все это проходил, и надо сказать, гораздо легче работать, когда у тебя есть четкий ответ на вопрос “зачем всё это нужно”. Все эти “менятели” мира почему-то забывают сказать, что изменение мира происходит как побочный результат зарабатывания денег, а не наоборот. Тяжело менять мир, когда к твоему виску приставлено дуло дробовика совета директоров, а на шею накинута удавка акционеров. Как по мне фраза “мы работаем для того, чтобы заработать денег” звучит гораздо честнее. Другое дело, что если сейчас сказать HRу, что ты работаешь на работе за деньги, то 146% получишь в ответ недоуменный взгляд и что-то типа “Вы нам не подходите, нам нужны увлеченные люди, которым важны саморазвитие и интересные задачи”.
Каждый знает, что если долго поднимать тяжести, то без должной подготовки (или даже с ней) гарантировано получишь проблемы со спиной и суставами. То же самое можно сказать про мозг, только это менее очевидно. Наша работа требует высокой отдачи и концентрации, даже если мы всего-лишь рефачим тесты на автомате, слушая в фоне очередной разведопрос. Мне кажется, что мозг просто не предназначен для таких ежедневных подвигов. Я работал на разных дерьмовых работах, в том числе физических и могу сказать, что я нигде не чувствовал себя настолько выжатым и разбитым, как выходя каждый день из офиса. Многие мои коллеги 35+ чувствуют примерно тоже самое, а на форумах начали появляться вопросы “Что делать, если тебе 25 и ты выгорел?” или “Как выйти из айти?”. Как долго удастся протянуть в таком режиме — вопрос интересный.
За 10 недолгих лет IT-сфера из уютненького мирка компьютерных ботанов, сидящих в подвале возле мерцающего монитора превратилась в огромную хайповую индустрию с большими зарплатами, маркетингом и прочим булщитом вокруг. Программирование больше не инженерное искусство, а всего лишь унылое ремесло, главное назначение которого — превращать говнокод и костыли в деньги. Осталось только дождаться, когда вся эта махина обрушится под собственной тяжестью и мы вернемся в свои подвалы. Или нет.
Чрезмерная сложность
Когда я занимался железками, мне очень нравилось то свойство, что я насквозь вижу как работает эта штуковина — какие байтики шевелятся, в какой области памяти это происходит и как обошелся с кодом компилятор. Было чувство спокойствия и контроля. Когда чуть позже я перешел в бекенд разработку, я хихикал над бесконечными xmlками конфигураций для EJB или того же спринга. Знал бы я, что меня ждет в будущем. Сейчас я просто не понимаю (и уже отчаялся понять), что происходит внутри моей же несложной приложухи. Куча слоев абстракций, контейнеров в контейнерах, тонны мануалов, скриптов, инструментов, версий, конфиг-файлов. Я до сих пор не разобрался, как деплоится проект, над которым работаю уже полгода. И конечно же нельзя сделать монолит, хотя бы на первом этапе. Обязательно нужно сразу же разделить всё на микросервисы, потому что так правильно (на конференции сказали, что так делают в компании Х). И конечно же мы не можем использовать старый добрый Apache HTTP Client для хождения вооон в тот сервис, который нам нужен 1 раз в несколько минут, ведь этот клиент недостаточно асинхронен, а также в нем нет встроенного рейт лимитера, механизма backpressure и прочих модных штук. На мой вопрос “А зачем это всё нужно для нагрузки 1 запрос/мин?” получаю лишь укоризненный взгляд от коллег, на лбах которых светится надпись “Вот ты тупоооой”.
Отдельная тема — это господин Джаваскрипт с его бесчисленными фреймворками. Я честно не понимаю, как можно было изобрести СТОЛЬКО штуковин для инструмента, которому нужно просто нарисовать формочки на веб-страницы и время от времени отправлять запрос на бекенд. Хорошо, что я занимаюсь бэкендом.
На примере фронтенда (да и не только его) хорошо заметно, как мы ходим по кругу: давайте всю логику выполнять на стороне сервера -> а давайте теперь на стороне клиента -> а давайте теперь снова на сервере и так до бесконечности. Давайте фронтенд и бекенд писать на одном языке -> а давайте теперь на разных -> а давайте снова на одном. Давайте сделаем схемы для форматов данных -> схемы только для старпёров -> а не, схемы нужны всё таки. Один мой кореш перепиливает свою опенсорсную библиотеку с yaml на xml, просто потому, что там есть схемы и это очень здорово, когда клепаешь огромный конфиг, а IDE, осведомленная о XSD сама может выполнить за тебя половину работы. Из вышесказанного вытекает следующая проблема:
Слишком много всего
Инструментов, языков, книг, конференций, фреймворков и т.д. Уже давно позади те времена, когда для разработки софта достаточно было знания одного ЯП, пары библиотек и в общем-то и всё. Теперь нас ожидают сотни фреймворков, с десяток языков (даже в рамках одного проекта), модные и не слишком СУБД, вездесущие брокеры сообщений, сотни квадратных километров разложенных граблей и прочего веселья. У среднестатистического программиста как правило нет времени на изучение всего этого на работе (кроме тех инструментов, что уже используются в его проектах), потому что на ней надо работать. Многим приходится тратить личное время на изучение этих технологий, хотя скорее всего 90% из изученного никогда не пригодится. У меня самого в покете лежит полтысячи статей, куча непосмотренных видосов с конференций, а каждый заход на Хабр предвещает обязательный визит Макконахи.
Но даже плотная работа с определенным ЯП или, к примеру, СУБД в своей компании иногда не дает возможности оставаться в тренде, т.к. технологии устаревают раньше, чем их успевают применять. Даже джава сейчас релизится со скоростью фаерфокса.
Благодаря бесконечному потоку быстроустаревающих знаний многие из нас чувствуют себя вечными студентами или самозванцами, неважно сколько систем ты реально построил. И это очень на руку HRам и работодателям — ведь легко можно сбить твою ЗП парой заковыристых вопросов. Такой вид крысиных бегов HRы политкорректно называют саморазвитием.
В последнее время я наблюдаю тренд навязывания разработчикам полномочий бизнес-департамента. Теперь помимо выполнения своих основных задач, разраб обязан разбираться в предметке на уровне хорошего аналитика и вообще думать про бизнес. Отстаньте от меня, я не знаю как повысить вашу конверсию
Собеседования
Это самый важный и горячо любимый мною вид спецдисциплины. Ведь по факту именно от этого зависит будешь ли ты спать на старом продавленном диване в арендованой однушке где-то за МКАДом, или же придется укрываться картонкой лежа на теплотрассе под мостом. Если в начале моей карьеры собеседование было чем-то типа разговора по-душам, то сейчас это больше напоминает экзамен. Возможно это связано с тем, что в те времена не было таких огромных зарплат и толп желающих войти в айти или просто мода, я не знаю. Но факт в том, что придя на собеседование на позицию старшего разраба, с огромной долей вероятности ты столкнешься с задачками, приправлеными вопросами-викториной. “Ну-ка реши на бумажке задачку, которую мы вчера стащили с leetcode. Ошибся на единичку в граничном условии? Фууууу лох! Не знаешь, как работает %methodName% в моднейшем %frameworkName%. Кто его вообще сюда пустил? Охрана!” Никого больше не волнует, что твоя голова устроена по-другому и ты не можешь в стрессе под презрительно-снисходительным взглядом высоколобых ботанов быстро и без ошибок наваять алгоритм под задачу, над которой ты и подумать ещё не успел. Как и то сколько за твоей спиной километров кода и продакшон-систем. Хорошо хоть вопросы-головоломки сдохли, и на том спасибо.
Айтишники
Тут разберем несколько подвидов этой популяции, с которыми чаще всего приходится иметь дело.
Собственно разработчики и сочувствующие. Вопреки стереотипам — в большинстве своём не ортодоксальные ботаны, а вполне себе нормальные ребята. Вот только как правило говорить с ними не о чем. Все разговоры во внерабочее время сводятся к работе. А как иначе, если ты вынужден круглосуточно вызубривать всю эту техномуть? Мой совет — держитесь подальше от ребят в клетчатых рубашках с рюкзаками, иначе можете заработать летальную дозу скуки. Многие из них ходят на работу не работать, а играть в игрушки. Давайте изобретем велосипед, давайте прикрутим новый фреймворк (и будем по ночам разгребать ад на проде) и непременно бросим всё на полпути, потому что эта игрушка надоела, к тому же новые завезли. Зато потом будем дуть щеки и рассказывать на конференциях, как мы победили проблему, которую сами же и создали. PROFIT! Эти люди так же легко ведутся на всякую чушь типа “интересных задач” и “сложных систем” (в айти культ сложных систем, поэтому калькулятор без десятка микросервисов сейчас построить нельзя), что в переводе на человеческий означает ковыряние в прокисшем дерьме мамонта, но за меньшие деньги, тем самым снижая ЗП по отрасли. Как в анекдоте “- Папа, а что мы сегодня будем кушать? — Ничего, сынок, я работаю над интересными задачами в дружном коллективе.”
Проджект-менеджеры. Честно говоря, за 10 лет я так и не понял кто такие проджект-манагеры и зачем они нужны. В совершенно разных конторах это выглядело примерно так: вот там пачка задач, разберитесь чего там и как и вот до такого-то числа сделайте. А я пошел возьму латте у хипстеров на первом этаже и напишу в инстаграме какой сегодня тяжелый день. Только однажды я видал чувака, который строил все эти скучные графики, жонглировал задачами и был нашим помощником, а не просто классным парнем, который не смог в программирование, но айтишную ЗП очень хочется.
Вайтишники. Нежно любимая многими категория. Благодаря их демпингу толковые и идейные джуны не могут въехать в индустрию — в погоне за длинным рублем, многие вкатывальщики готовы работать вообще бесплатно.
Про остальных умолчим.
Бизнес
Софт в современном мире не делается просто потому, что это прикольно (хотя иногда так кажется). Он делается чаще всего для зарабатывания бабок — прямо или опосредованно. И в связи с этим фактом можно разделить людей на 2 категории.
Тем кому важно как — чтобы внутри было всё красиво и правильно.
Тем кому важно что — те люди, которым важна суть продукта, который они делают.
Обычно в разработчике содержатся обе эти категории, просто в разных пропорциях.
Для обоих из них у меня есть печальные новости.
Для первой категории — с точки зрения зарабатывания денег абсолютно неважно насколько правильная архитектура выбрана и насколько красив код. Точно так же как и на всю эту вашу безопасность, лучшие практики, etc. Можно навтыкать костылей, заработать бабок, а дальше тот манагер, который всё это учинил спрыгивает на соседнюю шлюпку “получать новый опыт”, а команда ночами разгребает конюшни.
Для второй категории — 90% из вас делает то, что уже давно сделано другими. За редким исключением, все ваши продукты глубоко вторичны. Но тем не менее, ушлые дельцы пытаются придать “идейность” очередной платежной системе, онлайн-банку и тому подобному. Я сам все это проходил, и надо сказать, гораздо легче работать, когда у тебя есть четкий ответ на вопрос “зачем всё это нужно”. Все эти “менятели” мира почему-то забывают сказать, что изменение мира происходит как побочный результат зарабатывания денег, а не наоборот. Тяжело менять мир, когда к твоему виску приставлено дуло дробовика совета директоров, а на шею накинута удавка акционеров. Как по мне фраза “мы работаем для того, чтобы заработать денег” звучит гораздо честнее. Другое дело, что если сейчас сказать HRу, что ты работаешь на работе за деньги, то 146% получишь в ответ недоуменный взгляд и что-то типа “Вы нам не подходите, нам нужны увлеченные люди, которым важны саморазвитие и интересные задачи”.
Здоровье
Каждый знает, что если долго поднимать тяжести, то без должной подготовки (или даже с ней) гарантировано получишь проблемы со спиной и суставами. То же самое можно сказать про мозг, только это менее очевидно. Наша работа требует высокой отдачи и концентрации, даже если мы всего-лишь рефачим тесты на автомате, слушая в фоне очередной разведопрос. Мне кажется, что мозг просто не предназначен для таких ежедневных подвигов. Я работал на разных дерьмовых работах, в том числе физических и могу сказать, что я нигде не чувствовал себя настолько выжатым и разбитым, как выходя каждый день из офиса. Многие мои коллеги 35+ чувствуют примерно тоже самое, а на форумах начали появляться вопросы “Что делать, если тебе 25 и ты выгорел?” или “Как выйти из айти?”. Как долго удастся протянуть в таком режиме — вопрос интересный.
Итого
За 10 недолгих лет IT-сфера из уютненького мирка компьютерных ботанов, сидящих в подвале возле мерцающего монитора превратилась в огромную хайповую индустрию с большими зарплатами, маркетингом и прочим булщитом вокруг. Программирование больше не инженерное искусство, а всего лишь унылое ремесло, главное назначение которого — превращать говнокод и костыли в деньги. Осталось только дождаться, когда вся эта махина обрушится под собственной тяжестью и мы вернемся в свои подвалы. Или нет.
Комментарии 802
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.