Разработчик: подушка безопасности
Или по-другому: разработчик, нанятый с целью поднятия ЧСВ группы разработчиков, стоящих у истоков говнокода.
Pre: Термин был придуман лично мной и основывается на собственном опыте работы в компаниях [нашей] страны.
Как я впервые стал подушкой безопасности.
Я пришёл в компанию X (известная крупная российская компания) в 2007 г. Тогда ещё питался надеждами на грамотный российский бизнес, жил иллюзорными мечтами карьерного роста и личностного развития, одержимый доказать, что я могу работать ответственно и качественно, если будут поощрения и карьерный рост. Я ошибся, ошибался и продолжаю ошибаться.
Взяли меня на позицию Junior-а, но предложили довольно достойную заработную плату, что не могло не повлиять на решение работать в этой компании.
Только спустя многие коды годы, я понял с какой целью взяли на работу меня и многих моих коллег, которые до сих пор работают там (недавно заходил). А взяли меня работать подушкой безопасности.
Как определить, что ты работаешь подушкой безопасности?
1. Тебе как разработчику неизвестен вектор развития IT-команды и программных решений
2. Тебя не зовут на всякого рода совещания, ты не в курсе принятия важных решений (следствие из первого)
3. Тебе часто кажется, что разработчики стоящие вышедопускают ошибки, похожие на твои, но при этом тычат носом в твой код и твои ошибки
4. Тебе часто кажется, что все Вы за исключением определённой групп лиц месите одно и тоже, пишите «псевдополезный код»
5. Ошибки появляются часто, настолько часто, что ты как Junior работаешь над ними без перерыва и ни о каком развитии речь не идёт
6. Обсуждения о новых технологиях, о программной реализации того или иного блоков намеренно «умалчиваются и затухают»
7. Все попытки исправить положение — вызывают раздражение только у таких же как ты.
8. Определённая группа лиц встречается с представителями бизнеса и никогда не докладывает о своих планах.
9. Определённая группа лиц явно что-то пишет, но никогда не говорит об этом подушке безопасности.
10. Вам стабильно платят, что повышает Ваше желание молчать и продолжать своё дело.
Если во всех этих пунктах Вы себя узнали — вероятно, Вас взяли на позицию подушки безопасности.
Как, почему и для чего набираются разработчики такого плана?
В первую очередь для быстрого оперативного переписывания кода, чтобы профит достался всё той же определённой группе лиц. Представим себе ситуацию: 2000 год., несколько молодых людей затевают незамысловатый бизнес, найдены деньги и связи, нужны разработчики. Они приглашают в команду одного, второго третьего… Это командой пишется код в начальном приближении и бизнес начинает переть в гору. Чем больше проходит лет, тем более стремительно растёт «программный продукт» этой команды и чем более большие гонорары получает команда (бизнес и правда растёт). Но команда в свою очередь тоже учится… учится писать код, учится управлять ресурсами (программистами) и т. д. И вот наступает такой момент, когда тот код, который был написан не способен справляться с амбициями бизнеса, это момент X. Всё чаще команду прессует бизнес с вопросами, почему не работает там и там. Что будем делать и схренали я Вам столько плачу. Перед командой возникает вопрос: что делать. Объяснить бизнесу, что «мы писали говнокод» и текущая реализация оставляет желать лучшего — неудобно и не прибыльно.
И на ум приходит правильная и очевидная мысль: доказать руководству, что всё это «непросто», «трудоёмко» и что любой аналогичный программист — будет также долго и также некачественно выполнять работу, найди мы его за сумму «m». Она несколько больше рыночной стоимости, но найдя такого программиста (ибо опытный поймёт сразу в чём дело) — мы обеспечим подушку безопасности своей заднице. Мы убьём сразу несколько зайцев:
1) Покажем руководству, что современный разработчик — ничем не лучше нас
2) Оттянем время
3) Запросто делегируем часть задач (особенно неинтересных) на него.
И тут нанимается особый класс разработчиков. Это необязательно должны быть Junior-ы в плане знаний. Твои знания интересуют сейчас всех меньше. Ты должен быть тылом, чтобы прикрывать задницы тех, кто говнокодил несколько лет. Ты должен сидеть и поддерживать старый код, чтобы эти задницы переписывали систему используя современные наработки, чтобы снова получить профит и удовольствие от написания.
Что делать, если ты понял, что ты подушка безопасности?
Говоря проще — ничего не делать. В первую очередь тщательно взвесить всё, сформировать для себя определённый интервал, при котором ты явно поставишь себе цель выбраться из этой подушки, оценить перспективы команды, оценить возможность потенциального роста, оценить привлекательность зарплаты и прочих, прочих факторов. Самое главное понять, ты — там, где твоя голова. А дальше как с любой работой. Не устраивает — меняй. Устраивает — сиди и говнокодь пиши код на поддержку бизнесса и ради развития других задниц.
Немного о зарплате
Как правило, заработная плата «подушек» действительно выше, чем того же Junior-а в начинающем и качественном стартапе. Это обусловлено несколькими факторами:
1) Бизнесс дошёл до должного уровня и прибыль довольно большая. Уязвимость лишь в программного продукте.
2) При наборе «подушек» приоритет отдаётся лицам имеющим большой опыт, чтобы доказать бизнесу, что «он такой же как мы, но он также не справляется»
3) Руководство, как правило понимает, что на поддержке говнокода требуются стальные нервы… и не каждый сможет променять время и желание развиваться на поддержание этого кода.
Кратко плюсы и минусы работы.
Плюсы: достотйная зп, работа в компании с именем, как правило дружный коллектив (сдружитесь с такими же), свободное время (его будет в принципе достаточно), знакомство с говнокодом (как писать нельзя).
Минусы: нет развития, невозможность повлиять на вектор развития команды, говнокод (нервы нужны).
Перспективы: честно говоря их мало. Вы поймёте, что лавры достаются не Вам, что в Вас огромный потенциал, что Вы готовы бороться и принимать решения, что Вы хотите влиять на процесс разработки, но всего этого у Вас не будет.
Как площадка для старта и как запись в резюме — вариант идеальный. Не больше.
Повлиять на Ваше решение работать подушкой безопасности — я не могу и не хочу. Только Вам решать — устраивает ли Вас ваша работа или нет.
p.s. Мысли исключительно авторские и не претендуют на полную правоту.
p.p.s Я бы очень хотел, чтобы это прочитали заинтересованные люди от бизнеса, чтобы было более полное понимание того, что IT-отдел — это своя экосистема со своими правилами и установками, что это своя среда взаимодействия… и не всегда эта среда оказывается «правильной», как впрочем и всё в этом мире. Чтобы люди понимали, почему ушедший из их компании Вася потом пишет код и создаёт продукт, который известен всему миру.
Комментарии (16)
15 ноября 2016 в 14:17
+1↑
↓
Знакомо, только в моем случае я пришел очень далеко не Junior-ом, а эти люди без надлежащего профессионального уровня, мне указывали что и как я должен делать.
Есть три пути: потихоньку неспеша подыскивать новое место, либо втереться в доверие к кому-нибудь из верхушки и лизать ему задницу в надежде, что тебя примут, либо третий вариант — втихаря вкалывать, не гнушаться лишних заданий, проявлять инициативу, пытаться закольцевать как можно кода и решений на себя, помогать своим коллегам, пытаться выходить напрямую на контакт с клиентами. В определенный момент ты увидишь, как к тебе начнут прислушиваться как твои коллеги, так и «сверху». Помни, что ты развиваешься, а твоя «верхушка» нет, и скоро станет балластом.
modestguy
15 ноября 2016 в 14:51
+1↑
↓
Поэтому и оставил этот вопрос открытым. Тут каждый себе голова и каждый смотрит на это под своим углом обзора. Кто-то уходит, кто-то доказывает свою значимость, кто-то так и сидит на данной позиции и не куда не уходит. Вопрос субъективный, поэтому каких-то конкретных пожеланий — давать не хочется. Просто хотелось показать, что данная ситуация имеет место быть. Реалии — они порой суровее, чем краивая страница на hh.ru с описанием вакансии и наличием бесплатных «печенек и кофе» :)
А выбор — конкретно за каждым.
15 ноября 2016 в 15:02
+2↑
↓
Перед командой возникает вопрос: что делать.
…
Ты должен сидеть и поддерживать старый код, чтобы эти задницы переписывали систему используя современные наработки, чтобы снова получить профит и удовольствие от написания.Эээ… я что-то не понял, почему эти люди вдруг стали «задницами»? Есть какой-то иной способ решить вопрос, кроме как нанять дополнительных людей на поддержку, пока основная команда переписывает проект? Лично вы бы как поступили — сказали «Да! Моя работа — дерьмо!», предложили для продолжения дела вашей жизни нанять каких-то других людей и уволились?
-
modestguy
15 ноября 2016 в 16:13
+1↑
↓
Тут скорее не в этом проблема. Тут проблема в замкнутом круге этой ситуации. И в командной работе. Согласитесь, что данную ситуацию можно было бы разрулить несколько иначе. А именно:— посвящение тех, кто оказался «подушками» в планы команды;
— совместный выбор направления и фронта работы;
— совместная работа над поддержанием старого (приносящего деньги в данный момент) кода и над реализацией нового функционала (будь то рефакторинг, переписывание на фрэймворке и т.д.);
— полноправное членство в команде.И так далее. Ваш вариант решения (Моя работа дерьмо! Увольняюсь!) — скорее крайность и понятно, что так никто не делает. За «задницу» прошу прощения) Может слегка грубо получилось. Никого не хотел оскорблять :)
15 ноября 2016 в 15:16
+1↑
↓
Нанять разработчика с целью доказать его ненужность? Действительно?15 ноября 2016 в 15:33
+1↑
↓
Вполне реальная ситуация. Есть большой проект, который пилится уже много лет. Работает откровенно хреново, но продаётся (в основном из-за фактической монополии или нишевости продукта). Что там внутри знает только ГУРУ (!), который его пилит в одно лицо с самого первого «Hello world». Но со временем от заказчиков всё громче звучит «КАКОГО ФИГА?!!!». ГУРУ не может исправить продукт без выкидывания 90% кода. Руководству докладывается, что слишком много требований и нужны дополнительные разработчики. Нанимаются люди на упомянутую в статье роль. И до момента окончательного схлопывания «пузыря» создаётся активная имитация бурной деятельности: добавляются новые формочки и отчётики, закрываются ошибочки орфографии или совсем уж наглые эксепшены, навешиваются рюшечки и фишечки. Обо всём этом браво докладывается руководству на планёрках и все рады, кроме пользователей, но кто их спрашивает…15 ноября 2016 в 16:17
+2↑
↓
> создаётся активная имитация бурной деятельностиЭто другое. Автор написал, что разработчика нанимают, чтобы на фоне его никчемности подчеркнуть свою значимость. Вот это мне непонятно.
А что носитель сакрального знания не хочет ничего менять, и отдаёт новым коллегам только косметику с орфографией — бывает, сам сталкивался.
15 ноября 2016 в 16:23
+1↑
↓
Автор написал, что разработчика нанимают, чтобы на фоне его никчемности подчеркнуть свою значимость.
Мне кажется, автор неправильно выразил мысль. Или сделал неправильные выводы. Для менеджеров (как правило) не имеет смысла есть ли работники хуже, чем пресловутый ГУРУ, если ГУРУ — хреновый разраб. И для сохранения работы нет никакого смысла брать на работу джунов.
А вот в ответ на обвинения в никзком качестве продукта со стороны руководства сказать: Мне не хватает помошников. Набрать команду и нагрузить её кучей рутинных декоративных тасков — смысл есть. Тем самым можно отсрочить момент Х, когда даже самому генеральному из всех генеральных станет понятно, что продукт в таком виде использовать нельзя из-за фундаментальных огрехов.
15 ноября 2016 в 15:37
+1↑
↓
Второй постскриптум улыбнул. ИТ-отделы в плане внутренних интриг обычно выглядят заповедниками розовых пони по сравнению с какой-нибудь бухгалтерией или отделом продаж. И только разработчики с удивлением открывают для себя мир подковёрной борьбы, игры на разнице заявленных и подлинных интересов и прочих подобных радостей менеджеров среднего и высшего звена.
artyfarty
15 ноября 2016 в 15:42
+4↑
↓
Вашу гордость задели, и вы придумали целую статью себе в оправдание? Вы пришли в новый коллектив, по какой-то причине ваши отношения не сложились, но виноваты почему-то все кроме вас?Ну и ну.
-
modestguy
15 ноября 2016 в 15:52
+1↑
↓
Ну нет, вы не правы. Я вполне нормально отношусь к данной ситуации. Более того, считаю что она частично-оправдана с позиции менеджмента. Выше откомментировали уже, что это вполне себе рабочая ситуация. Я в статье пытался показать это как мог (смотрите пункт «что делать?»).
Гордость непричём.
RouR
15 ноября 2016 в 15:55
+3↑
↓
Плюсы: свободное время (его будет в принципе достаточно)
Минусы: нет развития
Для развития можно пилить свой собственный pet-project, для этого конечно нужно свободное время, и тут такое интересное совпадение…-
modestguy
15 ноября 2016 в 16:00
+1↑
↓
Как пожелание, тем, кто оказался в подобной ситуации. Таким образом повышать свой опыт и в этой среде Вас заметят. Либо в другой ;) Согласен с Вами.
15 ноября 2016 в 16:27
+1↑
↓
Случай хоть и не совсем фантастика, но мне не кажется «частым» гостем в разработке.
Если есть проблемы в продукте, смысла найма джунов (победа количеством) не имеет смысла, тут любой воротничок скажет. А наняв сеньера (победа опытом/качеством), его заинтересованные в успехе регулярно будут спрашивать, мол «Ну как там, какие прогнозы?», Как дела?» и тд15 ноября 2016 в 16:43
+2↑
↓
Мне кажется, в целом все примерно так, только заговора никакого нет. Обычно просто берут разработчиков на рутинную работу, чтобы было кому пилить задачи. Без всякой цели доказать что-то бизнесу или кому-то еще.Был в похожей ситуации, не жалею что ушел, жалею что долго оставался. Узнал «как писать нельзя», а заодно хорошо изучил сырой PHP и MySQL. Насчет плюсов согласен, для новичка неплохой вариант, но лучше на полгода-год максимум.
-
modestguy
15 ноября 2016 в 16:59
+1↑
↓
Понимаете, разговор руководитель IT — представитель бизнеса — это гораздо более сложный разговор, нежели «сейчас мы возьмём ещё людей на поддержку и всё перепишем». Не всегда так всё просто удаётся.
Как правило, объяснить бизнесу, что «мы не использовали фрэймворки (иные RAD-инструменты и техники), потому что было мало опыта» может вызвать бурю негодования. А почему Вы не использовали? Если Вы не использовали, есть люди которые используют? Давайте наймём тех, кто использует? Мы сами это можем использовать? Почему тогда Вы не использовали ранее? И т.д.
