Или по-другому: разработчик, нанятый с целью поднятия ЧСВ группы разработчиков, стоящих у истоков говнокода.
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-отдел — это своя экосистема со своими правилами и установками, что это своя среда взаимодействия… и не всегда эта среда оказывается «правильной», как впрочем и всё в этом мире. Чтобы люди понимали, почему ушедший из их компании Вася потом пишет код и создаёт продукт, который известен всему миру.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (24)
ildarz
15.11.2016 15:02+6Перед командой возникает вопрос: что делать.
…
Ты должен сидеть и поддерживать старый код, чтобы эти задницы переписывали систему используя современные наработки, чтобы снова получить профит и удовольствие от написания.
Эээ… я что-то не понял, почему эти люди вдруг стали «задницами»? Есть какой-то иной способ решить вопрос, кроме как нанять дополнительных людей на поддержку, пока основная команда переписывает проект? Лично вы бы как поступили — сказали «Да! Моя работа — дерьмо!», предложили для продолжения дела вашей жизни нанять каких-то других людей и уволились?
modestguy
15.11.2016 16:13Тут скорее не в этом проблема. Тут проблема в замкнутом круге этой ситуации. И в командной работе. Согласитесь, что данную ситуацию можно было бы разрулить несколько иначе. А именно:
— посвящение тех, кто оказался «подушками» в планы команды;
— совместный выбор направления и фронта работы;
— совместная работа над поддержанием старого (приносящего деньги в данный момент) кода и над реализацией нового функционала (будь то рефакторинг, переписывание на фрэймворке и т.д.);
— полноправное членство в команде.
И так далее. Ваш вариант решения(Моя работа дерьмо! Увольняюсь!) — скорее крайность и понятно, что так никто не делает. За «задницу» прошу прощения) Может слегка грубо получилось. Никого не хотел оскорблять :)
Eldhenn
15.11.2016 15:16Нанять разработчика с целью доказать его ненужность? Действительно?
aquamakc
15.11.2016 15:33+4Вполне реальная ситуация. Есть большой проект, который пилится уже много лет. Работает откровенно хреново, но продаётся (в основном из-за фактической монополии или нишевости продукта). Что там внутри знает только ГУРУ(!), который его пилит в одно лицо с самого первого «Hello world». Но со временем от заказчиков всё громче звучит «КАКОГО ФИГА?!!!». ГУРУ не может исправить продукт без выкидывания 90% кода. Руководству докладывается, что слишком много требований и нужны дополнительные разработчики. Нанимаются люди на упомянутую в статье роль. И до момента окончательного схлопывания «пузыря» создаётся активная имитация бурной деятельности: добавляются новые формочки и отчётики, закрываются ошибочки орфографии или совсем уж наглые эксепшены, навешиваются рюшечки и фишечки. Обо всём этом браво докладывается руководству на планёрках и все рады, кроме пользователей, но кто их спрашивает…
Eldhenn
15.11.2016 16:17+4> создаётся активная имитация бурной деятельности
Это другое. Автор написал, что разработчика нанимают, чтобы на фоне его никчемности подчеркнуть свою значимость. Вот это мне непонятно.
А что носитель сакрального знания не хочет ничего менять, и отдаёт новым коллегам только косметику с орфографией — бывает, сам сталкивался.aquamakc
15.11.2016 16:23+3Автор написал, что разработчика нанимают, чтобы на фоне его никчемности подчеркнуть свою значимость.
Мне кажется, автор неправильно выразил мысль. Или сделал неправильные выводы. Для менеджеров (как правило) не имеет смысла есть ли работники хуже, чем пресловутый ГУРУ, если ГУРУ — хреновый разраб. И для сохранения работы нет никакого смысла брать на работу джунов.
А вот в ответ на обвинения в никзком качестве продукта со стороны руководства сказать: Мне не хватает помошников. Набрать команду и нагрузить её кучей рутинных декоративных тасков — смысл есть. Тем самым можно отсрочить момент Х, когда даже самому генеральному из всех генеральных станет понятно, что продукт в таком виде использовать нельзя из-за фундаментальных огрехов.
VolCh
16.11.2016 12:19+1Цель — показать руководству, что текущие разработчики профессионалы и делают максимум из того, что вообще возможно (в рамках выделенного бюджета, конечно), что смена основной команды не изменит качественно ситуации с разработкой, что можно нанять в два раза больше народу, но это в лучшем случае увеличит скорость разработки в два раза ( с демонстрацией проседания на старта), а для качественного изменения ситуации требуется на порядок большее финансирование.
feldwebel
15.11.2016 15:37+4Второй постскриптум улыбнул. ИТ-отделы в плане внутренних интриг обычно выглядят заповедниками розовых пони по сравнению с какой-нибудь бухгалтерией или отделом продаж. И только разработчики с удивлением открывают для себя мир подковёрной борьбы, игры на разнице заявленных и подлинных интересов и прочих подобных радостей менеджеров среднего и высшего звена.
artyfarty
15.11.2016 15:42+11Вашу гордость задели, и вы придумали целую статью себе в оправдание? Вы пришли в новый коллектив, по какой-то причине ваши отношения не сложились, но виноваты почему-то все кроме вас?
Ну и ну.modestguy
15.11.2016 15:52+3Ну нет, вы не правы. Я вполне нормально отношусь к данной ситуации. Более того, считаю что она частично-оправдана с позиции менеджмента. Выше откомментировали уже, что это вполне себе рабочая ситуация. Я в статье пытался показать это как мог (смотрите пункт «что делать?»).
Гордость непричём.
newpy
16.11.2016 20:33Был в аналогичной ситуации. Гордость осталась совершенно не задетой. Да и как она может быть задета если ты приходишь джуном. Главное просто всегда выносить из любой ситуации уроки, плохие они или хорошие — всегда должны чему-то учить. Я получил опыт, отработал чуть больше года, понял что ситуация не изменится совершенно никак, и меня попросту «схантили» миддлом, увеличив зарплату ровно в два раза. И забрали на современную кодовую базу, которую можно «трогать» в отличие от старого и древнего, «работает не трогай» и продолжающего разрастаться «кода». Всем этим рулил один «главный» программист который все это написал, продолжает писать, и будет продолжать. На 5.3, с плоскими классами на >= 3к строк (no namespaces, no PDO, no mysqli, привет mysql), и твердо убежденного что все новое есть «говно» и «от лукавого», нанимают под запретом вносить даже идеи о чем-то новом (работает не трогай). Контора надо сказать изумительная, коллектив супер, было уютно и хорошо как в большой семье. Просто наступают моменты когда одни факторы перевешивают над другими. Зарплата, скиллованные напарники (лучше меня) интересный проект, современный код, с прекрасным тимлидом. Гордость по-прежнему на месте. Совершенно не задета. Но каждый выбирает как ему лучше. Так что в комментариях правильно пишут что ситуация не редкость.
Причины? Может быть конечно и не тешить ЧСВ такого вот «главного» программиста, но из своего опыта могу сказать, что мы решали рутинные задачи, вначале нас было четверо, потом трое осталось. Он жаловался, что он очень занят и надо еще программистов. После чего нас стало 7, из них 5 включая меня, продолжали делать «красивыми» формочки, добавляли «кнопочки», «отчетики», «фильтрики». Теперь я знаю что там уже 9 программистов. А у него по-прежнему не «хватает времени», он «очень занят» и важен для компании и начальства, и не может заниматься такой «ерундой», при этом никто толком не знает чем он реально занят. В основном администрированием системы в вопросах финансовой составляющей работы системы. К слову часть его времени уходит на «ручной» деплой, работы теперь уже 9 программистов. Вы же понимаете, что с ростом числа программистов, выкладывать больше, конфликтов кода больше. И нет совершенно желания автоматизировать процессы или исправлять ситуацию.
К слову, также, программист он хороший, правда, но нельзя быть настолько категоричным. Есть набор факторов объективных которые уже ушли далеко вперед за 8 лет, которые зарекомендовали себя, и могут улучшить работу, как коллектива так и кода или процессов разработки. Гордость моя никак не пострадала тогда, не страдает до сих пор. Обид нет, наоборот только благодарность, за рутинные задачи, которые надо кому-то решать. Не важно с какой кодовой базой. Опыт бесценен во всем, как я уже сказал в начале. Пользуясь случаем передаю привет и спасибо! =)modestguy
16.11.2016 20:36Согласен с Вами, что любой опыт — это опыт. И для развития необходимо черпать полезное, что собственно и повлияет на твоё будущее.
RouR
15.11.2016 15:55+6Плюсы: свободное время (его будет в принципе достаточно)
Минусы: нет развития
Для развития можно пилить свой собственный pet-project, для этого конечно нужно свободное время, и тут такое интересное совпадение…modestguy
15.11.2016 16:00+1Как пожелание, тем, кто оказался в подобной ситуации. Таким образом повышать свой опыт и в этой среде Вас заметят. Либо в другой ;) Согласен с Вами.
uniqm
15.11.2016 16:27+1Случай хоть и не совсем фантастика, но мне не кажется «частым» гостем в разработке.
Если есть проблемы в продукте, смысла найма джунов (победа количеством) не имеет смысла, тут любой воротничок скажет. А наняв сеньера (победа опытом/качеством), его заинтересованные в успехе регулярно будут спрашивать, мол «Ну как там, какие прогнозы?», Как дела?" и тд
michael_vostrikov
15.11.2016 16:43+7Мне кажется, в целом все примерно так, только заговора никакого нет. Обычно просто берут разработчиков на рутинную работу, чтобы было кому пилить задачи. Без всякой цели доказать что-то бизнесу или кому-то еще.
Был в похожей ситуации, не жалею что ушел, жалею что долго оставался. Узнал «как писать нельзя», а заодно хорошо изучил сырой PHP и MySQL. Насчет плюсов согласен, для новичка неплохой вариант, но лучше на полгода-год максимум.modestguy
15.11.2016 16:59+2Понимаете, разговор руководитель IT — представитель бизнеса — это гораздо более сложный разговор, нежели «сейчас мы возьмём ещё людей на поддержку и всё перепишем». Не всегда так всё просто удаётся.
Как правило, объяснить бизнесу, что «мы не использовали фрэймворки(иные RAD-инструменты и техники), потому что было мало опыта» может вызвать бурю негодования. А почему Вы не использовали? Если Вы не использовали, есть люди которые используют? Давайте наймём тех, кто использует? Мы сами это можем использовать? Почему тогда Вы не использовали ранее? И т.д.helg1978
16.11.2016 02:35+3Все именно так. И обычно в итоге половина правды замалчивается. Но страшно не когда замалчивается, а когда тратятся деньги инвесторов на фантомные должности, что б прикрыть свою попу.
Но я верю, что есть способ подобрать для представителей бизнеса правильные формулировки типа «вышли новые фреймворки, которые отлично решают нашу задачу, имеет смысл переписать с нуля» «мы стали намного опытнее в нашей нише, и готовы сделать как надо», «прогресс не стоит на месте» и т.д
В своей практике, я в качестве рычага использую факт наличия множественных хотелок, которые всегда добавляются по ходу у длительных проектов: «вначале все проектировалось как Икс, но сейчас мы имеем крутой универсальный комбайн Игрек, и пора, пока не поздно, переделать все на современные рельсы»
michael_vostrikov
16.11.2016 06:08Мне больше представляется другая картина.
— Почему не сделали то-то и то-то?
— Продукт стал большой, задач много, не успеваем.
— Ну постарайтесь за следующий месяц доделать.
Через месяц.
— Почему опять не сделали то-то и то-то?
— Не успели, пользователей много, задач много. Давайте наймем нам пару человек, которые будут заниматься мелкими задачами. А мы будем делать то-то и то-то.
— Хм, ладно, давайте.
Через некоторое время.
— Вот мы тогда наняли людей, и появилось время сделать то что надо. А теперь оно требует поддержки, а нам еще делать то и вон то. Надо бы еще кого-нибудь нанять.
— Как вы мне надоели. Ладно, наймем еще пару человек, и студентов на практику позовем. Только в следующий год больше никакого расширения штата не будет. И чтобы все готово было.
devhard
16.11.2016 08:59Мне кажется, это вполне обычная ситуация, когда опытные программисты не доверяют новичкам. Поручают им задачи менее значительные, где меньше цена ошибки. Практика позволяет понять, можно ли человеку доверить ответственные задачи или пусть ещё поучится «на кошках».
Что делать, если ты понял, что ты подушка безопасности?
Есть ещё один вариант — придти к руководителю и предложить новый проект или фичу и себя в качестве исполнителя. Часто даже придумывать ничего не надо, у руководства уже давно готов список «проектов» на которые не хватает только ответственного и перспективного работника :)
vvscode
16.11.2016 20:37+1Взяли меня на позицию Junior-а, но предложили довольно достойную заработную плату, что не могло не повлиять на решение работать в этой компании.
Нанять Junior c целью доказать его несостоятельность? Все семь пунктов подходят под обычного Джуниора с паранойей ( да, я знаю, что все в сговоре ).
1) Джуниор не часто им интересуется ( вектором развития ) или не всегда может его понять просто в силу своего опыта
2) Тебя не зовут и ты не участвуешь в принятии решений — следствие из того, что ты джуниор. Не станут советоваться со студентом-практикантом во время операции на сердце
3) Тебе кажется, что это ошибки. Но это продуманные решения или компромисы, связанные с кучей мелочей
4) Не все вы, а, возможно только ты. И дело только в тебе. Или тебе кажется
5) Дать джуниору разрабатывать архитектуру?
6) Потому люди делают дело, а не гоняются за модными словами. И понимаю, что внедрить новинку не всегда просто
7) собака лает, караван идет. Никаких личностей, но вес в принятии решений не дается просто так
8) Серьезно? Уважаемый джун, мы тут встречались с представителями бизнеса и решили…
ну и так далее
Throwable
Знакомо, только в моем случае я пришел очень далеко не Junior-ом, а эти люди без надлежащего профессионального уровня, мне указывали что и как я должен делать.
Есть три пути: потихоньку неспеша подыскивать новое место, либо втереться в доверие к кому-нибудь из верхушки и лизать ему задницу в надежде, что тебя примут, либо третий вариант — втихаря вкалывать, не гнушаться лишних заданий, проявлять инициативу, пытаться закольцевать как можно кода и решений на себя, помогать своим коллегам, пытаться выходить напрямую на контакт с клиентами. В определенный момент ты увидишь, как к тебе начнут прислушиваться как твои коллеги, так и "сверху". Помни, что ты развиваешься, а твоя "верхушка" нет, и скоро станет балластом.
modestguy
Поэтому и оставил этот вопрос открытым. Тут каждый себе голова и каждый смотрит на это под своим углом обзора. Кто-то уходит, кто-то доказывает свою значимость, кто-то так и сидит на данной позиции и не куда не уходит. Вопрос субъективный, поэтому каких-то конкретных пожеланий — давать не хочется. Просто хотелось показать, что данная ситуация имеет место быть. Реалии — они порой суровее, чем краивая страница на hh.ru с описанием вакансии и наличием бесплатных «печенек и кофе» :)
А выбор — конкретно за каждым.
renskiy
Тихо вкалывать и наблюдать как другие занимаются любимым делом (пишут новый код, например), тогда как тебе приходится поддерживать старый, без какой-либо перспективы… Если в команде есть такие как ты и таких большинство, то можно наверно смириться в конечном итоге, если все остальные плюсы перевешивают. Вот только отсутствие развития и бесполезность получаемых знаний (особенно если остальная команда полным ходом пишет новую версию кода) не сделают тебя востребованным специалистом не только на рынке, но даже внутри этой же компании. В таком случае выход только один — нужно искать новое место.