Comments 25
Знакомо, только в моем случае я пришел очень далеко не Junior-ом, а эти люди без надлежащего профессионального уровня, мне указывали что и как я должен делать.
Есть три пути: потихоньку неспеша подыскивать новое место, либо втереться в доверие к кому-нибудь из верхушки и лизать ему задницу в надежде, что тебя примут, либо третий вариант — втихаря вкалывать, не гнушаться лишних заданий, проявлять инициативу, пытаться закольцевать как можно кода и решений на себя, помогать своим коллегам, пытаться выходить напрямую на контакт с клиентами. В определенный момент ты увидишь, как к тебе начнут прислушиваться как твои коллеги, так и "сверху". Помни, что ты развиваешься, а твоя "верхушка" нет, и скоро станет балластом.
Поэтому и оставил этот вопрос открытым. Тут каждый себе голова и каждый смотрит на это под своим углом обзора. Кто-то уходит, кто-то доказывает свою значимость, кто-то так и сидит на данной позиции и не куда не уходит. Вопрос субъективный, поэтому каких-то конкретных пожеланий — давать не хочется. Просто хотелось показать, что данная ситуация имеет место быть. Реалии — они порой суровее, чем краивая страница на hh.ru с описанием вакансии и наличием бесплатных «печенек и кофе» :)
А выбор — конкретно за каждым.
А выбор — конкретно за каждым.
Тихо вкалывать и наблюдать как другие занимаются любимым делом (пишут новый код, например), тогда как тебе приходится поддерживать старый, без какой-либо перспективы… Если в команде есть такие как ты и таких большинство, то можно наверно смириться в конечном итоге, если все остальные плюсы перевешивают. Вот только отсутствие развития и бесполезность получаемых знаний (особенно если остальная команда полным ходом пишет новую версию кода) не сделают тебя востребованным специалистом не только на рынке, но даже внутри этой же компании. В таком случае выход только один — нужно искать новое место.
Перед командой возникает вопрос: что делать.
…
Ты должен сидеть и поддерживать старый код, чтобы эти задницы переписывали систему используя современные наработки, чтобы снова получить профит и удовольствие от написания.
Эээ… я что-то не понял, почему эти люди вдруг стали «задницами»? Есть какой-то иной способ решить вопрос, кроме как нанять дополнительных людей на поддержку, пока основная команда переписывает проект? Лично вы бы как поступили — сказали «Да! Моя работа — дерьмо!», предложили для продолжения дела вашей жизни нанять каких-то других людей и уволились?
Тут скорее не в этом проблема. Тут проблема в замкнутом круге этой ситуации. И в командной работе. Согласитесь, что данную ситуацию можно было бы разрулить несколько иначе. А именно:
— посвящение тех, кто оказался «подушками» в планы команды;
— совместный выбор направления и фронта работы;
— совместная работа над поддержанием старого (приносящего деньги в данный момент) кода и над реализацией нового функционала (будь то рефакторинг, переписывание на фрэймворке и т.д.);
— полноправное членство в команде.
И так далее. Ваш вариант решения(Моя работа дерьмо! Увольняюсь!) — скорее крайность и понятно, что так никто не делает. За «задницу» прошу прощения) Может слегка грубо получилось. Никого не хотел оскорблять :)
— посвящение тех, кто оказался «подушками» в планы команды;
— совместный выбор направления и фронта работы;
— совместная работа над поддержанием старого (приносящего деньги в данный момент) кода и над реализацией нового функционала (будь то рефакторинг, переписывание на фрэймворке и т.д.);
— полноправное членство в команде.
И так далее. Ваш вариант решения(Моя работа дерьмо! Увольняюсь!) — скорее крайность и понятно, что так никто не делает. За «задницу» прошу прощения) Может слегка грубо получилось. Никого не хотел оскорблять :)
Нанять разработчика с целью доказать его ненужность? Действительно?
Вполне реальная ситуация. Есть большой проект, который пилится уже много лет. Работает откровенно хреново, но продаётся (в основном из-за фактической монополии или нишевости продукта). Что там внутри знает только ГУРУ(!), который его пилит в одно лицо с самого первого «Hello world». Но со временем от заказчиков всё громче звучит «КАКОГО ФИГА?!!!». ГУРУ не может исправить продукт без выкидывания 90% кода. Руководству докладывается, что слишком много требований и нужны дополнительные разработчики. Нанимаются люди на упомянутую в статье роль. И до момента окончательного схлопывания «пузыря» создаётся активная имитация бурной деятельности: добавляются новые формочки и отчётики, закрываются ошибочки орфографии или совсем уж наглые эксепшены, навешиваются рюшечки и фишечки. Обо всём этом браво докладывается руководству на планёрках и все рады, кроме пользователей, но кто их спрашивает…
> создаётся активная имитация бурной деятельности
Это другое. Автор написал, что разработчика нанимают, чтобы на фоне его никчемности подчеркнуть свою значимость. Вот это мне непонятно.
А что носитель сакрального знания не хочет ничего менять, и отдаёт новым коллегам только косметику с орфографией — бывает, сам сталкивался.
Это другое. Автор написал, что разработчика нанимают, чтобы на фоне его никчемности подчеркнуть свою значимость. Вот это мне непонятно.
А что носитель сакрального знания не хочет ничего менять, и отдаёт новым коллегам только косметику с орфографией — бывает, сам сталкивался.
Автор написал, что разработчика нанимают, чтобы на фоне его никчемности подчеркнуть свою значимость.
Мне кажется, автор неправильно выразил мысль. Или сделал неправильные выводы. Для менеджеров (как правило) не имеет смысла есть ли работники хуже, чем пресловутый ГУРУ, если ГУРУ — хреновый разраб. И для сохранения работы нет никакого смысла брать на работу джунов.
А вот в ответ на обвинения в никзком качестве продукта со стороны руководства сказать: Мне не хватает помошников. Набрать команду и нагрузить её кучей рутинных декоративных тасков — смысл есть. Тем самым можно отсрочить момент Х, когда даже самому генеральному из всех генеральных станет понятно, что продукт в таком виде использовать нельзя из-за фундаментальных огрехов.
Цель — показать руководству, что текущие разработчики профессионалы и делают максимум из того, что вообще возможно (в рамках выделенного бюджета, конечно), что смена основной команды не изменит качественно ситуации с разработкой, что можно нанять в два раза больше народу, но это в лучшем случае увеличит скорость разработки в два раза ( с демонстрацией проседания на старта), а для качественного изменения ситуации требуется на порядок большее финансирование.
Второй постскриптум улыбнул. ИТ-отделы в плане внутренних интриг обычно выглядят заповедниками розовых пони по сравнению с какой-нибудь бухгалтерией или отделом продаж. И только разработчики с удивлением открывают для себя мир подковёрной борьбы, игры на разнице заявленных и подлинных интересов и прочих подобных радостей менеджеров среднего и высшего звена.
Вашу гордость задели, и вы придумали целую статью себе в оправдание? Вы пришли в новый коллектив, по какой-то причине ваши отношения не сложились, но виноваты почему-то все кроме вас?
Ну и ну.
Ну и ну.
Ну нет, вы не правы. Я вполне нормально отношусь к данной ситуации. Более того, считаю что она частично-оправдана с позиции менеджмента. Выше откомментировали уже, что это вполне себе рабочая ситуация. Я в статье пытался показать это как мог (смотрите пункт «что делать?»).
Гордость непричём.
Гордость непричём.
Был в аналогичной ситуации. Гордость осталась совершенно не задетой. Да и как она может быть задета если ты приходишь джуном. Главное просто всегда выносить из любой ситуации уроки, плохие они или хорошие — всегда должны чему-то учить. Я получил опыт, отработал чуть больше года, понял что ситуация не изменится совершенно никак, и меня попросту «схантили» миддлом, увеличив зарплату ровно в два раза. И забрали на современную кодовую базу, которую можно «трогать» в отличие от старого и древнего, «работает не трогай» и продолжающего разрастаться «кода». Всем этим рулил один «главный» программист который все это написал, продолжает писать, и будет продолжать. На 5.3, с плоскими классами на >= 3к строк (no namespaces, no PDO, no mysqli, привет mysql), и твердо убежденного что все новое есть «говно» и «от лукавого», нанимают под запретом вносить даже идеи о чем-то новом (работает не трогай). Контора надо сказать изумительная, коллектив супер, было уютно и хорошо как в большой семье. Просто наступают моменты когда одни факторы перевешивают над другими. Зарплата, скиллованные напарники (лучше меня) интересный проект, современный код, с прекрасным тимлидом. Гордость по-прежнему на месте. Совершенно не задета. Но каждый выбирает как ему лучше. Так что в комментариях правильно пишут что ситуация не редкость.
Причины? Может быть конечно и не тешить ЧСВ такого вот «главного» программиста, но из своего опыта могу сказать, что мы решали рутинные задачи, вначале нас было четверо, потом трое осталось. Он жаловался, что он очень занят и надо еще программистов. После чего нас стало 7, из них 5 включая меня, продолжали делать «красивыми» формочки, добавляли «кнопочки», «отчетики», «фильтрики». Теперь я знаю что там уже 9 программистов. А у него по-прежнему не «хватает времени», он «очень занят» и важен для компании и начальства, и не может заниматься такой «ерундой», при этом никто толком не знает чем он реально занят. В основном администрированием системы в вопросах финансовой составляющей работы системы. К слову часть его времени уходит на «ручной» деплой, работы теперь уже 9 программистов. Вы же понимаете, что с ростом числа программистов, выкладывать больше, конфликтов кода больше. И нет совершенно желания автоматизировать процессы или исправлять ситуацию.
К слову, также, программист он хороший, правда, но нельзя быть настолько категоричным. Есть набор факторов объективных которые уже ушли далеко вперед за 8 лет, которые зарекомендовали себя, и могут улучшить работу, как коллектива так и кода или процессов разработки. Гордость моя никак не пострадала тогда, не страдает до сих пор. Обид нет, наоборот только благодарность, за рутинные задачи, которые надо кому-то решать. Не важно с какой кодовой базой. Опыт бесценен во всем, как я уже сказал в начале. Пользуясь случаем передаю привет и спасибо! =)
Причины? Может быть конечно и не тешить ЧСВ такого вот «главного» программиста, но из своего опыта могу сказать, что мы решали рутинные задачи, вначале нас было четверо, потом трое осталось. Он жаловался, что он очень занят и надо еще программистов. После чего нас стало 7, из них 5 включая меня, продолжали делать «красивыми» формочки, добавляли «кнопочки», «отчетики», «фильтрики». Теперь я знаю что там уже 9 программистов. А у него по-прежнему не «хватает времени», он «очень занят» и важен для компании и начальства, и не может заниматься такой «ерундой», при этом никто толком не знает чем он реально занят. В основном администрированием системы в вопросах финансовой составляющей работы системы. К слову часть его времени уходит на «ручной» деплой, работы теперь уже 9 программистов. Вы же понимаете, что с ростом числа программистов, выкладывать больше, конфликтов кода больше. И нет совершенно желания автоматизировать процессы или исправлять ситуацию.
К слову, также, программист он хороший, правда, но нельзя быть настолько категоричным. Есть набор факторов объективных которые уже ушли далеко вперед за 8 лет, которые зарекомендовали себя, и могут улучшить работу, как коллектива так и кода или процессов разработки. Гордость моя никак не пострадала тогда, не страдает до сих пор. Обид нет, наоборот только благодарность, за рутинные задачи, которые надо кому-то решать. Не важно с какой кодовой базой. Опыт бесценен во всем, как я уже сказал в начале. Пользуясь случаем передаю привет и спасибо! =)
Плюсы: свободное время (его будет в принципе достаточно)
Минусы: нет развития
Для развития можно пилить свой собственный pet-project, для этого конечно нужно свободное время, и тут такое интересное совпадение…
Случай хоть и не совсем фантастика, но мне не кажется «частым» гостем в разработке.
Если есть проблемы в продукте, смысла найма джунов (победа количеством) не имеет смысла, тут любой воротничок скажет. А наняв сеньера (победа опытом/качеством), его заинтересованные в успехе регулярно будут спрашивать, мол «Ну как там, какие прогнозы?», Как дела?" и тд
Если есть проблемы в продукте, смысла найма джунов (победа количеством) не имеет смысла, тут любой воротничок скажет. А наняв сеньера (победа опытом/качеством), его заинтересованные в успехе регулярно будут спрашивать, мол «Ну как там, какие прогнозы?», Как дела?" и тд
Мне кажется, в целом все примерно так, только заговора никакого нет. Обычно просто берут разработчиков на рутинную работу, чтобы было кому пилить задачи. Без всякой цели доказать что-то бизнесу или кому-то еще.
Был в похожей ситуации, не жалею что ушел, жалею что долго оставался. Узнал «как писать нельзя», а заодно хорошо изучил сырой PHP и MySQL. Насчет плюсов согласен, для новичка неплохой вариант, но лучше на полгода-год максимум.
Был в похожей ситуации, не жалею что ушел, жалею что долго оставался. Узнал «как писать нельзя», а заодно хорошо изучил сырой PHP и MySQL. Насчет плюсов согласен, для новичка неплохой вариант, но лучше на полгода-год максимум.
Понимаете, разговор руководитель IT — представитель бизнеса — это гораздо более сложный разговор, нежели «сейчас мы возьмём ещё людей на поддержку и всё перепишем». Не всегда так всё просто удаётся.
Как правило, объяснить бизнесу, что «мы не использовали фрэймворки(иные RAD-инструменты и техники), потому что было мало опыта» может вызвать бурю негодования. А почему Вы не использовали? Если Вы не использовали, есть люди которые используют? Давайте наймём тех, кто использует? Мы сами это можем использовать? Почему тогда Вы не использовали ранее? И т.д.
Как правило, объяснить бизнесу, что «мы не использовали фрэймворки(иные RAD-инструменты и техники), потому что было мало опыта» может вызвать бурю негодования. А почему Вы не использовали? Если Вы не использовали, есть люди которые используют? Давайте наймём тех, кто использует? Мы сами это можем использовать? Почему тогда Вы не использовали ранее? И т.д.
Все именно так. И обычно в итоге половина правды замалчивается. Но страшно не когда замалчивается, а когда тратятся деньги инвесторов на фантомные должности, что б прикрыть свою попу.
Но я верю, что есть способ подобрать для представителей бизнеса правильные формулировки типа «вышли новые фреймворки, которые отлично решают нашу задачу, имеет смысл переписать с нуля» «мы стали намного опытнее в нашей нише, и готовы сделать как надо», «прогресс не стоит на месте» и т.д
В своей практике, я в качестве рычага использую факт наличия множественных хотелок, которые всегда добавляются по ходу у длительных проектов: «вначале все проектировалось как Икс, но сейчас мы имеем крутой универсальный комбайн Игрек, и пора, пока не поздно, переделать все на современные рельсы»
Но я верю, что есть способ подобрать для представителей бизнеса правильные формулировки типа «вышли новые фреймворки, которые отлично решают нашу задачу, имеет смысл переписать с нуля» «мы стали намного опытнее в нашей нише, и готовы сделать как надо», «прогресс не стоит на месте» и т.д
В своей практике, я в качестве рычага использую факт наличия множественных хотелок, которые всегда добавляются по ходу у длительных проектов: «вначале все проектировалось как Икс, но сейчас мы имеем крутой универсальный комбайн Игрек, и пора, пока не поздно, переделать все на современные рельсы»
Мне больше представляется другая картина.
— Почему не сделали то-то и то-то?
— Продукт стал большой, задач много, не успеваем.
— Ну постарайтесь за следующий месяц доделать.
Через месяц.
— Почему опять не сделали то-то и то-то?
— Не успели, пользователей много, задач много. Давайте наймем нам пару человек, которые будут заниматься мелкими задачами. А мы будем делать то-то и то-то.
— Хм, ладно, давайте.
Через некоторое время.
— Вот мы тогда наняли людей, и появилось время сделать то что надо. А теперь оно требует поддержки, а нам еще делать то и вон то. Надо бы еще кого-нибудь нанять.
— Как вы мне надоели. Ладно, наймем еще пару человек, и студентов на практику позовем. Только в следующий год больше никакого расширения штата не будет. И чтобы все готово было.
— Почему не сделали то-то и то-то?
— Продукт стал большой, задач много, не успеваем.
— Ну постарайтесь за следующий месяц доделать.
Через месяц.
— Почему опять не сделали то-то и то-то?
— Не успели, пользователей много, задач много. Давайте наймем нам пару человек, которые будут заниматься мелкими задачами. А мы будем делать то-то и то-то.
— Хм, ладно, давайте.
Через некоторое время.
— Вот мы тогда наняли людей, и появилось время сделать то что надо. А теперь оно требует поддержки, а нам еще делать то и вон то. Надо бы еще кого-нибудь нанять.
— Как вы мне надоели. Ладно, наймем еще пару человек, и студентов на практику позовем. Только в следующий год больше никакого расширения штата не будет. И чтобы все готово было.
Мне кажется, это вполне обычная ситуация, когда опытные программисты не доверяют новичкам. Поручают им задачи менее значительные, где меньше цена ошибки. Практика позволяет понять, можно ли человеку доверить ответственные задачи или пусть ещё поучится «на кошках».
Есть ещё один вариант — придти к руководителю и предложить новый проект или фичу и себя в качестве исполнителя. Часто даже придумывать ничего не надо, у руководства уже давно готов список «проектов» на которые не хватает только ответственного и перспективного работника :)
Что делать, если ты понял, что ты подушка безопасности?
Есть ещё один вариант — придти к руководителю и предложить новый проект или фичу и себя в качестве исполнителя. Часто даже придумывать ничего не надо, у руководства уже давно готов список «проектов» на которые не хватает только ответственного и перспективного работника :)
Взяли меня на позицию Junior-а, но предложили довольно достойную заработную плату, что не могло не повлиять на решение работать в этой компании.
Нанять Junior c целью доказать его несостоятельность? Все семь пунктов подходят под обычного Джуниора с паранойей ( да, я знаю, что все в сговоре ).
1) Джуниор не часто им интересуется ( вектором развития ) или не всегда может его понять просто в силу своего опыта
2) Тебя не зовут и ты не участвуешь в принятии решений — следствие из того, что ты джуниор. Не станут советоваться со студентом-практикантом во время операции на сердце
3) Тебе кажется, что это ошибки. Но это продуманные решения или компромисы, связанные с кучей мелочей
4) Не все вы, а, возможно только ты. И дело только в тебе. Или тебе кажется
5) Дать джуниору разрабатывать архитектуру?
6) Потому люди делают дело, а не гоняются за модными словами. И понимаю, что внедрить новинку не всегда просто
7) собака лает, караван идет. Никаких личностей, но вес в принятии решений не дается просто так
8) Серьезно? Уважаемый джун, мы тут встречались с представителями бизнеса и решили…
ну и так далее
Проголосовал «нет».
Я хотел бы сказать автору и всем, кто оказывается в подобных ситуациях. «Давите интеллектом». Видите бедлам — требуйте устранения. Видите тупик развития — докладывайте на оперативных совещаниях. Прежде чем покинуть компанию — убедитесь, что вы приняли достаточные (но адекватные ситуации) меры, чтобы попытаться что-то изменить. Не думайте, что это произойдёт за один раз. Даже если вас выслушали и даже если _услышали_ — чтобы что-то изменить, нужно ежедневно добиваться маленьких целей шаг за шагом. Нет возможности поговорить с кем-то, кто принимает решения? Разъясняйте свою позицию команде. Не нойте, а объясняйте и доказывайте.
Я не сразу добрался до определённого уровня понимания программирования (хотя и сейчас далёк от желаемого уровня), но в какую бы команду я не приходил — принимаю собственную ответственность за итоговый результат. Всё развалилось? Это также ваша вина, хотя её доля может быть и незначительной.
Перефразируя классику, если вы такой умный — почему всё в вашем проекте до сих пор так неправильно?
Я хотел бы сказать автору и всем, кто оказывается в подобных ситуациях. «Давите интеллектом». Видите бедлам — требуйте устранения. Видите тупик развития — докладывайте на оперативных совещаниях. Прежде чем покинуть компанию — убедитесь, что вы приняли достаточные (но адекватные ситуации) меры, чтобы попытаться что-то изменить. Не думайте, что это произойдёт за один раз. Даже если вас выслушали и даже если _услышали_ — чтобы что-то изменить, нужно ежедневно добиваться маленьких целей шаг за шагом. Нет возможности поговорить с кем-то, кто принимает решения? Разъясняйте свою позицию команде. Не нойте, а объясняйте и доказывайте.
Я не сразу добрался до определённого уровня понимания программирования (хотя и сейчас далёк от желаемого уровня), но в какую бы команду я не приходил — принимаю собственную ответственность за итоговый результат. Всё развалилось? Это также ваша вина, хотя её доля может быть и незначительной.
Перефразируя классику, если вы такой умный — почему всё в вашем проекте до сих пор так неправильно?
Sign up to leave a comment.
Разработчик: подушка безопасности