Comments 143
Роди ребенка Создай продукт, научи его жить самостоятельно, двигайся дальше.
В современном мире почему то сложилось так, что если ты не выкатываешь новые версии минимум раз в год, то для пользователей это повод паниковать, искать альтернативу, поносить разрабов. Казалось бы, часто можно наблюдать обратную картину, когда юзеры недовольны часто выходящими сырыми обновлениями, но это только подтверждает общий подход в разработке ПО.
Предлагаю модифицировать тезис: "Создай продукт, сделай его кому-то нужным, передай другому и двигайся дальше." ))
почему то сложилось так, что если ты не выкатываешь новые версии минимум раз в год, то для
пользователейотдела маркетинга это повод паниковать, искать альтернативу, поносить разрабов.
Пользователи, как правило, поносят разработчиков как раз за то, что те перекроили продукт, отобрали привычные и удобные фичи, досыпали новых багов, а на постоянно повторяемые требования практически полезных фич или починки старых багов - забили. При этом, такое встречается и в opensource, и в коммерческой разработке. Основная движущая сила этой апелляции к переоцененному novelty bias - маркетологи и менеджеры продукта, хотя иногда и сами разработчики (особенно - в opensource), которые работают не на полезный результат, а ради личного развлечения, начинают скучать от полировки старого и хотят добавить нового, совершенно не заботясь о последствиях.
Сколько раз читал такое в отзывах.
Вы не маркетолог, случайно? Вы описываете поведение нового пользователя, а не существующего. Существующий пользователь просто пользуется. Существующих пользователей всегда больше, чем (удавшихся или нет) новых в любой момент времени.
Конечно надо делать редизайны и вносить баги, чтобы оправдать платную поддержку :D
Именно потому я написал про совершенствование практически полезных фич и полировку существующих. Это достаточный аргумент для апгрейда, если продукт используется для практических целей. И этот процесс существует во многих коммерческих продуктах. Более того, раньше подобная модель преобладала, пока в сферу продажи софта не пришли люди, продающие гонку бесполезных обновлений. Где здесь курица, а где - яйцо, выясняется довольно просто.
Существующих пользователей всегда больше, чем (удавшихся или нет) новых в любой момент времени.
На растущем рынке абсолютно не обязательно так
последнее обновление выходило в 2014 году,
Если обновление выходило в 2014 году и в разделе Issue вереница не отвеченных сообщений до текущей даты, все реже и реже, и последние уже писались без надежды на ответ.
Так и есть. Все вокруг быстро меняется, софт должен к этому непрерывно адаптироваться.
Старый софт был монолитным и ориентировался в основном на оффлайн - он мог жить годами без изменений.
Современный софт - сборник библиотек и зависимостей. Зависимости постоянно меняются, особенно внешние: на веб-апи полагаться нельзя, как показывает практика они меняются даже когда не должны.
Пользователи, как правило, поносят разработчиков как раз за то, что те перекроили продукт, отобрали привычные и удобные фичи, досыпали новых багов, а на постоянно повторяемые требования практически полезных фич или починки старых багов — забили.
И те же самые пользователи поменяют продукт как только обновления замедлятся или приостановятся примерно на год. А блогеры и в википедию напишут что продукт deprecated.
Парадокс.
Предлагаю модифицировать тезис: "Создай продукт, сделай его кому-то нужным, передай другому и двигайся дальше." ))
Под "научить жить самостоятельно" я имел ввиду сделать так, чтобы продукт развивали другие люди, разные и сменяющие друг друга.
Мой принцип. Делаю блоки которые работают, без участия IT-отдела. Рассказывают другим сотрудникам как это работает, как задумано. (хотят ли они это знать? другой вопрос).
А далее, работы всегда хватает. Мне не хочется, чтобы я на одну задачу всегда был завязан. Нормального отпуска не будет.
Согласен, уникальных не бывает.
Также, стандарты на разработку подразумеваются в любой компании. Не обсуждается.
Но я встречал программистов, которые задают атмосферу раработки.
И, вот, эту самую атмосферу нелегко повторить.
Сложно передать словами, но после ухода таких ребят, разработка становится скучной, команда разваливается и расходится, развитие продукта буксует.
Бывают - например люди, которые годами не только прогали (что может любой студент), а полностью вникали во весь процесс, от разработки, до юридических нюансов использования
Если образовался незаменимый, значит в бизнес процессе что-то не так.
А вообще, если человек "повышает" стоимость своего увольнения, значит в фирме есть проблемы с кадровой политикой, и скорее всего с доверием между сотрудником и руководством.
Это в 90% компаний такое. Вне зависимости от доверия. У не-программистов типа продажников - да, недоверие к руководству, когда каждый менеджер носит с собой папочку на работу и домой, и без этой папочки компания потеряет несколько миллионов. У программистов эта папочка всегда в голове, и она называется контекстом разработки.
Решение данной проблемы - документирование и описание собственно разработки, архитектуры модуля, его взаимодействия с остальными модулями. И проблема даже не в деньгах (рабочем времени), а в банальном отстутствии времени у такого high-end разработчика на документирование.
Под продавцами горит кресло, надо срочно пофиксить критичные баги перед подписанием контракта. Есть волшебник, который может это сделать. При этом, как полагается хорошему волшебнику, он не работает больше 8 часов и в выходные, вне зависимости от того, сколько готовы ему заплатить за овертаймы. Выбор у руководства сложный - либо посадить волшебника фиксить критичные баги и продолжать развитие продукта, либо посадить документировать то, что уже есть. И это при условии, что волшебник согласится документировать вообще, а это бывает далеко не всегда - он обычно озабочен идеями саморазвития, и детальное документирование уже сделанного - в его сознании - редко является саморазвитием.
Тут ещё сложность с временем удержания: через месяц твой код для тебя уже чужой, его нужно изучать снова, всё нюансы уже "смыты" десятками других задач.
А чужой код документировать это неблагодарный труд.
Это вопрос сродни «Питон в ВУЗе изучал пару лет назад, но с тех пор на нем не работал». Сильно лучше, чем с нуля начинать.
Чужой немного, да, но далеко не совсем. Принципы все же в мозгу остались, поскольку убито время на отладку, есть знакомые крючочки, за которые цепляется сознание. Хотя, конечно, если на аутсорсе писать по таскам в Джире…
Лидеры мнений, да. Люди, которые по сути задают культуру внутри команды и настроение.
Таких ещё и нанимать весьма не просто. Не понятно как на интервью отследить эти качества
Нет, не одному. Но даже глядя на свой код полугодичной давности, мне кажется, что не вышло, хотя именно так как вы написали старался. Как говорится: для "хорошо" надо постараться, а "плохо" само получится. Хотелось бы верить, что мне не сильно прилетает в карму за былой код от тех, кому выпало его дорабатывать.
Вот лишь некоторые вещи, которые, по мнению разработчиков, можно делать, чтобы сохранить за собой место в компании. Но они обманывают только себя.
- Не писать документацию...
- Писать дрянной код...
- Единолично владеть некой основной частью системы...
Откуда идут эти дурацкие мифы и почему они такие устойчивые? Нет, всё ровно наоборот.
Нужно документировать код, продвигать использование wiki/confluence, написание аналитических и архитектурных документов разработчиками или аналитиками, если они есть.
Создавать рекомендации по написанию хорошего кода, следовать им самому и продвигать это среди других разработчиков.
Пытаться максимально передавать знания о разных частях системы другим разработчикам. В идеале проводить обучение.
Внедрять разные инструменты, упрощающие разработку (CI/CD, анализаторы кода, ...). В общем, создавать условия, чтобы новые разработчики могли с нуля максимально быстро погружаться в проект, а потом нормально работать, не отвлекаясь на рутину.
Обеспечивать себе и другим разработчикам комфортный режим работы, чтобы их труд оценивался не по скриншотам экрана, не по количеству часов высиженных за компом, не по активности в Jira. А чтобы наоборот у них было полно свободного времени на исследовательскую работу, предложение разных идей.
Такой человек конечно не становится незаменимым, но заменять его уже не очень хочется. Хотя это вопрос времени. Либо внешняя обстановка изменится (проект завершится, продукт загнется, в компании будут перестроения), либо сам человек выгорит (какая бы интересная не была работа, всё когда-то надоедает).
Из практики - такие люди сосредоточены на создании и не всегда оценены руководством. И лишь спустя время после их ухода остальные осознают, что все вертелось не само собой.
Тут скорее дело в том, что в РФ (может быть и в мире) не принято давать положительную обратную связь. Поэтому складывается ощущение, что руководство не ценит и не осознаёт. Такой вот недостаток менеджмента. Его стоит учитывать - не ругают, значит с тобой всё Ok.
Ну а насчет заменимости разработчиков.. а что в этом плохого?
Нет незаменимых разработчиков, нет незаменимых работодателей.
В дополнение сразу вспомнил картинку, распространяемую по соцсетям и близкую по смыслу, с надписью "незаменимых нет, есть неповторимые".
Мой бывший директор не то что не хвалил, а говорил, что я не стою тех денег, что мне платят и показывал стопку резюме, людей готовых меня заменить. Я ушел, а замену за пол года мне так и не нашли, хотя по факту там нужен anykey. А когда я был именно anaykey-ем в бюджетной организации, то отдел и людей в нем считали на уровне уборщиков или даже хуже.
Это очень сильно зависит от места работы, к примеру работал я в одной фирме с внутренней самописной crm на laravel, единственным разработчиком, где задания начальство предпочитало давать по телефону или личной встречи, какая документация, какое тестирование, тут успеть бы все правки сделать, а фикс багов идет уже между делом, особенно если зп на уровне джуна, за эти деньги я делал ровно то что от меня требовали
У меня первая работа была очень похожа на то, что вы описываете. Там было очень много задач, планов, начальников, а ИТшников мало (хотя и больше одного человека). На документацию и тестирование тоже не было времени. Хотя сейчас окажись я в таких же условиях я безусловно продвигал бы документирование и в целом нормальные процессы разработки. Когда привыкаешь к этому, то очень сложно потом работать иначе.
Там запросто можно было погрязнуть в рутине, например, там годами создавали разные учетные системы, пилили какие-то отчеты. Я поначалу ожидал от начальства и коллег осмысленных задач. Но в какой-то момент осознал, что когда часть данных хранится в фокспрошной базе без первичных и внешних ключей и эти данные используются только для распечатки документов, а потом те же самые данные вносятся в какую-нибудь аксесовскую базу, и кучу ещё других отдельных баз и потом с помощью какой-то магии по всем этим данным пытаются построить какие-то отчеты путем распечатки кучи отчетов и усреднения расходящихся показателей, то это полный треш.
Можно конечно продолжать тратить на всю эту жесть кучу времени, запилить ещё пару учетных систем. Но возникла идея почему бы вместо дублирования данных в разных базах не сделать одну базу и при этом нормальную, хотя бы с ключами, нормальными формами и т.п. Почему бы вместо того, чтобы пилить каждый отчет на каких-то корявых reporting-компонентах для Delphi не использовать нормальные OLAP кубы, и пускай пользователи сами в Excel тянут себе любые данные какие хотят. Почему бы не взять нормальный готовый движок для учетных систем.
Реакция на всё это варьировалась от "нафига" до "ну, делай, если надо, от меня-то что нужно". Я походил с этими идеями ещё какое-то время, а потом просто взял и сделал. После той работы я понял, что вообще не нужно ждать какой-то инициативы, одобрения или хотя бы здравого смысла от других. Никто лучше тебя в твоей работе не разбирается, у всех какие-то свои задачи, интересы. Если у тебя есть убежденность, что нужно делать так и есть желание это делать, то нужно просто забить на бессмысленные задачи и делать как считаешь нужным.
Чё-то какой-то пафосный комментарий, отдаёт немного инфоцыганскими тренингами :) Но, блин, на мой взгляд это реально так, на последующих работах я делал ровно так же, только уже не тратил время на ожидание осмысленных задач или того, что все сразу бросятся всё делать "правильно" (быстрее, проще, лучше).
О том, что незаменимых не бывает, веришь ровно до того момента, как приходится искать на рынке РФ специалиста по высоким нагрузкам. Даже если через полгода поисков по связям найдёшь подходящего человека, окажется, что ему надо платить в 3-5 раз больше, чем ты уже платишь "заменимым", а у тебя и так уже зарплаты в полтора-два раза выше рынка.
Неужели в хайлоэде зарплаты в 3-5 раз выше?
Можно просто стать перед офисом одноклассников/яндекса и раздавать вакансии листовками с такой вилкой.
Я конечно виноват, что в столь щепетильной теме, как размеры зарплат, прибег к грубым и несколько гиперболизированным упрощениям, но... Когда я говорю о рыночных зарплатах, то стараюсь опираться не на свой субъективный опыт, а на статистику, хоть и считаю, что её показатели занижены. Если опираться на статистику Хабра Карьеры и HH, то медиана мидла - 150k, медиана сеньора - 200k. В полтора раза больше - это соответственно 200 и 300. Так вот одного нашего сманили на должность архитектора за миллион рублей в месяц (!), а ещё пару других сманили западные компании, у них сейчас в пересчёте на рубли выходит 800-900k. Вот и получается, что мидла с двуста на грубо лям - это в пять раз, а сеньора с трёхста на тот же лям - это в три раза.
P.S. Одна только работа в Яндексе не делает человека специалистом по высоким нагрузкам. Более того, не гарантирует, что он вообще специалист.
Если опираться на статистику Хабра Карьеры и HH, то медиана мидла — 150k, медиана сеньора — 200k.
Это медиана специалиста по всем стекам( там прямо написано «По всем ИТ-специализациям») и по всем локациям. Возможно у вас с профилем есть более гранулированная статистика но мне показывает 140к медиану по всем специализациям и 150к среднюю.
Назвать ее рыночной это все равно что взять все машины диапазона 5-10 лет на сайте автомобилей, включая и спорткары и спецтехнику и распилы праворульных и советский автопром, посчитать медиану и называть это рыночной ценой своего автомобиля.
Я согласен что тема крайне щепетильная и если вы действительно можете регулярно нанимать синьоров на 200к то вполне можно это называть рыночной зп. Но я думаю что вы сами прекрасно понимаете что вам рассмеются в лицо на такое предложение. Если вы нанимаете на 300к и при этом к вам не выстраивается «очередь за забором» значит 300k это и есть рыночная цена а не то что вы платите в полтора раза больше рынка.
Вот например более детальная статистика habr.com/ru/post/672248 которая говорит прямо что рыночный ценник синьора в большинстве стеков только начинается от 300к. Это уже даже идет по верхней границе моей консервативной оценки.
Ценники в миллион рублей так же не выглядят чем-то космическим например в блокчейне, доплата за риск. А с учетом того как усиленно сейчас вымываются сильные кадры зарубеж это может стать нормой.
Одна только работа в Яндексе не делает человека специалистом по высоким нагрузкам. Более того, не гарантирует, что он вообще специалист.
Конечно не делает, но высокие нагрузки там присутствуют и а значит есть и специалисты. Если бы вы реально предлагали гиперболизированные x10 от рынка то вы бы их оттуда схантили бы с легкостью.
А пока извините но даже 1млн это x2-x3 от рыночной зп синьор+. Конечно это большие деньги, тут я согласен, но все же не повод так преувеличивать.
На хабр карьере в зарплатном калькуляторе, на сколько я понимаю, люди указывают текущие зарплаты. Вы говорите о предлагаемых зарплатах, чтобы человек сменил работу. Я не уверен, что сменил бы работу при предложении х2 относительно текущей зарплаты. На мой взгляд такая разница вполне ожидаемая.
Я-то всё это понимаю, а вот любители фразы "незаменимых не бывает" не понимают, о чём и был мой первый комментарий в этой ветке. Например, наш директор по кадрам опирается как раз на статистику HH, когда рапортует начальству о соответствии наших зарплат рыночным, а потом руководители отказывают в прибавках, ориентируясь на эти рапорты, и очень удивляются требованиям кандидатов.
Ладно бы высокие нагрузки, мы обычного мидла со знанием Camunda искали примерно в том же сценарии.
В каком смысле переоценил при поиске? Нам нужны были специалисты по Camunda, мы их искали, находился один человек раз в несколько месяцев, на собеседовании брезгливо морщился на наши 300k и уходил. Нанимать людей без опыта с ней пробовали, они и спустя год не могут решать с её помощью весь спектр требуемых задач и возникающих проблем. Да и я, чего уж греха таить, несмотря на опыт "с теми или иными BPM" не знаю с какой стороны подступаться например к проблеме низкой скорости миграции 24 тысяч активных процессов на новую схему. Слава богам, специалиста всё-таки нашли, она и API движка использует так, как мы бы не додумались, и схемы сильно лучше всей остальной команды составляет.
со знанием Camunda
А мы разрабатываем инструменты моделирования, анализа моделей и т.п. Люди с таким опытом просто не существуют :) Я немного утрирую, но на hh и других ресурсах не наблюдается избытка резюме.
Специалист по высоким нагрузкам это ещё относительно распространённая профессия. Гораздо сложнее, когда у организации есть такие уникальные бизнесс-процессы, которых просте нет больше ни у кого другого. И чтобы программист просто въехал в тему требуется никак не меньше года, а желательно пару лет. Попробуетй найти специалиста с опытом написания системы, организующей торговлю на фондовом рынке, например. (Не бота-трейдера, а именно саму платформу торгов).
Попробуетй найти специалиста с опытом написания системы, организующей торговлю на фондовом рынке, например.
Тут у меня странным кажется вообще желание найти специалиста с таким опытом. Когда таких платформ на всем шарике - дюжина хотя бы наберется? К тому же все которые есть - еще и под всякими NDA сидят, поди и в приципе не могут свой опыт использовать - потому что по результату засудят если не их, то сами платформы друг друга: "Была использована наши ИС и нарушены миллион наших патентов".
системы, организующей торговлю на фондовом рынке
Из компаний, что были в России мне вспоминается DevExpert(разработка), Exactpro(тестирование).
Работал он днями и ночами, чтобы система, не дай Бог, не вышла из строяСистема, требующая постоянного надзора — это плохо построенная система. И если для её поддержания нужно привлекать аж 10 сторонних программистов…
Я видел обратную ситуацию — когда незаменимым оказывался обычный рядовой программист, который со временем внезапно оказывался более квалифицированным, чем IT-директор. Найти 10 других на замену ещё можно, а вот сохранить продукту конкурентную способность — уже не факт.
Ну обычно если брать кодинг-поддержку и тд, то рядовой программист будет более квалифицированным чем директор. Задача директора - выстраивать процессы и создавать условия для работы рядового программиста, чтобы без метаний, переделок... Правда недалеко каждый директор это умеет
Система, требующая постоянного надзора — это плохо построенная система.
Если ваша система зависит от других систем (вне вашего контроля) — она будет требовать постоянного надзора и ничего вы с этим не сделаете, увы. Поправили где-то извне API чуть-чуть, отменили старый, изменили формат, да просто сменили провайдера потому что старый вышел из бизнеса — всё, приплыли, и это всего при одной зависимости, а представьте что их десяток, а иногда и не один.
Сделать стабильную не требующую надзора систему можно только если вы контролируете вообще всё, и то при условии что вы никогда ничего не меняете в этом всём — а это почти невозможно.
Существует очень много систем которые вынуждены с той или иной частотой реагировать на изменения в законодательстве. Предусмотреть все на уровне гибких настроек нереально, так что постоянный надзор, доработка на соответствие законам - частая причина привлечения программистов.
Не важно кто следит, без программистов все равно не обойтись. Иногда законодатели не торопятся настолько или настолько невнятны, что информация о том что же конкретно нужно реализовать становится доступной уже после того как прошли все сроки. Да, бегать может и не нужно, но как подвисают сайты того же 1с от наплыва посетителей, ожидающих новой/исправленной версии какого-нибудь отчета, у которого истекает срок подачи, видел неоднократно. Ни кто не хочет быть оштрафован, так что думаю программистов поторапливают. Так же неоднократно видел, как задним числом меняют трактовку уже реализованных в по законов после какого-нибудь пояснительно письма от ФНС, ПФР, ФСС и т.п.
Я бы просто не стал использовать стороннее апи, которое меняется по несколько раз на дню
Дело не в том что "несколько раз на дню", достаточно раз в год, и не всегда у вас есть выбор.
Пример — вы брокер, и используете API различных бирж. У вас нет влияния на эти биржы, а API периодически меняются, появляются новые биржи, etc. Вы можете конечно не использовать "стороннее API", но тогда вы не сможете вести бизнес — всё просто. Причём речь не только про API — про процессы, правила обработки, валидации и вот это всё — тоже меняется со временем.
Или к примеру вам нужна массовая рассылка SMS и верификация телефонных номеров голосом — можно конечно купить своё оборудование и написать софт прибитый к нему гвоздями, но скорее всего вы не можете себе этого позволить и найдёте провайдера для этой услуги, иногда даже не одного (не все покрывают все страны или цены неадекватные для отдельных стран), и вот у вас уже потенциальные проблемы — изменения в API, уход провайдера из бизнеса etc — и заранее этого не предсказать.
Вы можете учесть всё что описано в документации, но исключительно редко документация покрывает всё, и вот сегодня вы наконец-то сделали идеальный софт — а завтра с другой стороны поставщики изменили пару строчек в возвращаемых данным способом который не документирован (но и явно не запрещен) — и всё, ваше супер-пупер приложение вылетело с исключением "ошибка валидации".
И так, собственно, почти во всём что не замкнуто само на себя — посмотрите на слёзы разработчиков под Android — постоянно что-то новое, удаляется что-то старое или меняются уже существующее, и выбора увы нет, точнее, он-то конечно есть — но тогда вы теряете что-то существенное, типа доли рынка.
А внутри компании, для самой компании, или для себя, когда ничего не меняется десятки лет — ни процессы, ни требования, ни что-то ещё — конечно написать безупречно работающий код один раз и пользоваться вечно — почти раз плюнуть.
У вас биржа — а у меня металлургическое производство, на котором вылет приложения с исключением может стоить не денег, а жизни. Потому при обмене данными с внешними источниками варианты «что-то пошло не так» предусматриваются. Приложение не должно падать оттого, что пропала связь с БД, отсутствует таблица или разрешение на неё, или внезапно у субд деадлок случился, или OPC-сервер у поставщика данных завис. Приложение не должно терять ни какие данные, и даже в случае аварийного завершения уметь их сохранять. Серверное приложение вообще должно работать как служба, а не приложение.
Когда-то старался стать незаменимым, гордился этим. С годами пришло понимание, что это не есть хорошо. Теперь стараюсь организовать работу группы так, чтобы каждый разработчик мог легко заменить любого другого коллегу, и меня в том числе, на любом участке работ.
Если не делать это самоцелью, так как чрезмерное увлечение ведёт к деградации, то не вижу ничего плохого в незаменимости. На коммерческом рынке все компании стремятся стать незаменимыми для своих клиентов, работодатель стремится сделать своих сотрудников менее заменимыми, сотрудники наоборот. Это конкуренция, что само по себе неплохо.
Будете сидеть годами на одном и том же проекте/стэке, проклиная свою незаменимость, в то время как другие разработчики будут развиваться и идти вперед.
В отпуск будете ходить не когда вам надо, а когда можно, да и то со скрипом и постоянными звонками с работы.
Оно вам надо? Лучше развивайтесь и прокачивайте уверенность в себе и своих силах. Никакой незаменимости тогда и не нужно будет.
Вы путаете круглое с холодным, или выдумываете на ходу не читая комментарии. Во первых, написал же "не должно являтся самоцелью". Во- вторых, ваше развитие зависит от вас, а не от компании в которую вы попали, ровно как и отпуска и прочее.
Если вы ещё думаете в парадигме наёмного сотрудника, то вам надо тоже поднабраться уверенности.
в то время как другие разработчики будут развиваться
В чем вообще цель трудовой деятельности? "Развиваться и расти над собой" или получать хорошую зарплату? Если за "один и тот же проект/стек" хорошо платят, то в чем проблема?
- Папа, что мы будем сегодня кушать?
- Ничего, сынок, я работаю на интересном стеке в дружной команде.
Риторический вопрос. Кто бы подсказал, как стать заменимым, если ты единственный оставшийся разработчик внутреннего довольно объемного ПО в неIT компании на допотопном стеке, а новые задачи ставятся начальством быстрее, чем успеваешь осмыслить предыдущие. Когда мечтаешь поработать там, где какой-нибудь приятный Kotlin, быстрый и красивый Unreal, удивительный мир нейронок или в сфере дополненной реальности, а приходится развивать и поддерживать MsAccess+MsSQL древних версий? ))
Ну вас же что-то останавливает от перехода к прекрасному котлину etc?
Зарлпата? Коллектив? Осознание "незаменимости"?
Видимо, есть какие-то весомые плюсы на текущем месте?
Кто бы что ни говорил, но схемой деньги/работа или работа/деньги взаимоотношения между работником и конторой не ограничиваются. Существует ответственность перед организацией и людьми, которые пользуются прогами и поддержкой. При увольнении с ответственной должности принято передавать дела, а в некоторых случаях обучить приемника. С приемником как раз и проблема.
Да, плюсы есть: свобода творчества в рамках устаревшего стека при полном отсутствии конфликтов + хорошее отношение с коллективом. Конфликтов нет среди разработчиков, менеджеров проекта, аналитиков, тестировщиков, дизайнеров и т.д., потому что это ты один, конфликтов нет с заказчиком (начальством), потому что к тебе прислушиваются и твое мнение весомо.
Из минусов: з.п. ниже рынка (около 100К), ибо не айти контора, но выше чем у приходящего админа-эникещика, ну и главный минус - незаменимость со всеми вытекающими (нагрузка, отпуска, застой в развитии). Была безумная идея попробовать вариант пописать по свободке прилы для мобилок в одно лицо для андройда, но после известных проблем с монетизацией для РФ этот путь стал сильно под вопросом.
Ну вот, у вас очень даже хорошие плюсы, на мой взгляд 👍. Это дорогого стоит. А всех денег в мире всё равно не заработаешь.
А насчёт "обучить приёмника", есть такая штука как "кадровый резерв".
Если Работодатель этим не озаботился, это его проблемы.
В конце концов, bus factor никто не отменял. Как и многие другие причины, по которым работник может покинуть компанию, даже если не планировал.
Да, я тоже думаю, что свобода творчества и возможность влиять на любую часть приложения это то, что позволяет получать настоящее удовольствие от разработки. Не хотелось бы её терять перейдя каким-нибудь джуном-винтиком в контору, где правый отдел не знает, чем занимается левый, а целостную картину не видит никто.
Я тоже работал в неИТшной конторе. Там конечно было больше одного ИТшника, но в целом ситуация очень похожая, тоже не хотел уходить по тем же причинам. Очень нравился проект, это была медицинская информационная система для большого областного медицинского центра. Там были всякие интересные штуки связанные с анализом данных, анализом изображений, машинным обучением, process mining - это было лет 13 назад, когда это ещё не было мейнстримом. Данные о пациентах раскладывались не по тупым формам "бумажных" документов, а по функциональным системам организма, т.е. сведения о человеке представляли собой большой осмысленный граф, а каждый специалист наполнял и использовал какие-то срезы этого графа.
Процессы оказания помощи там тоже были очень интересные. Если в обычной поликлинике человек пришел на прием, ушел, про него забыли. То там эти процессы начинаются ещё до рождения человека, длятся до 18 лет и дальше. Во всём этом участвует множество медучреждений, врачи разных специализаций, плюс социальные работники, психологи. В общем, мне очень нравилось, мы делали что действительно клёвое, сами выбирали направления, а не занимались автоматизацией каких-нибудь изначально корявых процессов, генерацией отчетов для регуляторов, затыканием дыр.
Конечно идти в какой-нибудь интегратор, чтобы клепать CRUD, формочки, сайты и т.п. мне очень не хотелось. У нас в городе тогда даже вакансии BI-разработчиков были единичными, а ML просто не существовал в вакансиях.
Но жизнь заставила. Половину мизерной зарплаты забирали судебные приставы, другую половину выплачивал по кредитам, денег не оставалось даже на еду и дорогу. Причем, я даже не просил повышения зп, предложили другой вариант, после которого я понял, что в моей жизни что-то не так и ушёл с трехкратным увеличением зп и таким же уменьшением нагрузки, все проблемы сразу решились. Что удивительно и проекты оказались ещё интереснее. Потом уже со второй работы никак не мог уйти по тем же причинам. А сейчас на третьей работе всё очень нравится.
Я конечно не знаю нужны ли вам какие-то советы :) Но я бы предложил посмотреть среднюю зп по вашей специальности например здесь на хабр карьере. Придти к руководству и сказать, что хочу получать хотя бы среднюю по рынку. Если они отказываются, то искать спокойно другие проекты, вполне возможно, что они будут ещё лучше.
Вот, кстати, искренне спасибо, за историю. Видимо разработка для медицины, очень популярная ниша. По совпадению тоже на медиков работаю, хотя все намного прозаичнее, без МЛ и графов (если не считать идею из "долгого ящика" поучить какие-нибудь сетки на медкартах и данных исследований). Тоже припоминаю времена когда на первой работе (на муниципалку) на проезд мелочь занимал. Уйти на повышение было не сложно, благо оставался человек. Вот вторая работа как раз пока не отпускает, но приятно слышать, что у других в сходных ситуациях все получается, это мотивирует.
С приемником как раз и проблема.Логично, что молодёжь не хочет идти в застойное место, да ещё и ниже рынка.
Кладешь заявление на увольнение. Тут внезапно начинаются вопросы, а что не так, вроде все отлично было. Можно сказать, что конкурентная зп это 200-350 (не знаю ваш уровень). И далее сказать, что ок, согласен обучить замену и согласен тут задержаться при условии повышения зп на несколько месяцев. Про стек тоже можно обозначить проблему, возможно есть какие-то варианты. Я вот на прошлой работе, потратил 2 недели на передачу дел, а в итоге меня кинули на последнюю зп. Надо было сказать, что я ухожу и на следующий день не приходить. А насколько я там заменимый-незаменимый это не мои проблемы.
Схема довольно реалистичная, отмечу лишь, что хотелось бы свалить не на вольные хлеба, а уже имея предложение не хуже хотя бы по з.п., но для этого нужно "догнать" рынок освоив и как-то набрав опыт в востребованных стеках. В свободное от работы время это сделать не просто, а не юношеский возраст не добавляет привлекательности к резюме. Но это все отговорки, по факту при должном усердии и везении все хоть и медленно, но решаемо. Сложнее с заменой, которую тебе предложат подыскать, ибо сами не разбираются(а это так),а когда ты её не найдешь и свалишь, то все равно будет не красиво, и объективно чувство, что слега кинул людей останется.
Идеальный вариант - подождать удачный повод, типа конфликт с руководством, переезд в другой город по независящим причинам, смена ПО под давлением законодательства, предложение на стороне, отказ от которого не поняли бы даже текущие начальники, но то думки. )
Я уже проходил пару онлайн тестирований/соревнований даже не на должность, а на место на образовательных курсах в яндекс и озон. До живого собеса не дошел, т.к. по задачкам не прошел (где-то в серединке был). Места конечно халявные и желающих много, но, млин, и народу брали не мало, так что повысить скилы очень даже не помешает. Этож позор какой-то, не пройти тесты-задачки на то, чтобы слушать онлайн курсы! )
А что у вас за стек-то такой устаревший?
Ну причин несколько. Начиналось все давно еще при 97 офисе. Никто не ожидал, что микрософт по сути похоронит популярный инструмент для разработки корпоративных приложений, перестав развивать, а в последствии и убрав поддержку связки MS Access+MS SQL. Были давние попытки перескочить на другие технологии, были и C# + WPF (не устроило слабым удобством разработки и заметными тормозами на старом железе по сравнению с теми же устаревшими winforms), были стратегические идеи перевести все на веб, и даже на Qt, но все это затухало на этапе интересных, но незаконченных экспериментов и отдельных полезных мини приложений. Невозможно в адекватные сроки на пару с напарником одновременно разрабатывать новый движок, поддерживать старый и решать кучу эникейских задач несвойственных для разработчиков айтишных контор. А штат программистов в непрофильной фирме для разработки под себя никто держать не планировал и не планирует. Думаю, мы не одни оказались в такой ситуации, хоть типичной её и не назвать.
Вы несколько раз упоминаете большую нагрузку, а откуда она в вашей ситуации? Кто назначает вам дедлайны? Вас же некем заменить, а значит, и сроки решения задач можете ставить только вы сами себе. Просто ставьте их в расчетом на параллельное саморазвитие
Есть ежедневные задачи мало относящиеся к разработке, но которые нельзя отложить на потом. У кого-то компьютер завис/не грузится, сеть пропала, принтер не печатает, почта не приходит, вайфай не подключается, файл/сайт не открывается, телефоны не работают и много других характерных для эникейщика проблем. Плюс определенные задачи по разработке нужно делать в обозримые сроки, иначе смысл теряется. А так да, сроки не ставлю, приоритеты выбираю по ситуации, куча задач в вечном игноре, куча некритичных улучшений в долгом ящике, на работе особо не задерживаюсь, но и чем то посторонним не занимаюсь. Так что совесть чиста, все честно, время оплачено, работаю не на износ, но на саморазвитие остаются вечера дома, обед, выходные.
Отовсюду старался уходить также - не в середине этапа, отработать 2 недели, максимально закрыть задачи, оставить кодовую базу в поддерживаемом состоянии и все равно потом друзья говорили, что меня руководство считало негодяем. Вывод - не ценят, но сам себе изменить не могу.
>> Вывод - не ценят, но сам себе изменить не могу.
И не нужно, вы всё делаете правильно.
На мой взгляд, завершая работу на одном месте, и, правильно закрывая и передавая все дела, работник поступает профессионально. Это нормальный профессиональный подход к делу. Это как мыть руки перед едой что-ли.
Если кто-то этого не ценит, что-ж, это его сложности.
Кто бы что ни говорил, но схемой деньги/работа или работа/деньги взаимоотношения между работником и конторой не ограничиваются. Существует ответственность перед организацией и людьми, которые пользуются прогами и поддержкой. При увольнении с ответственной должности принято передавать дела, а в некоторых случаях обучить приемника. С приемником как раз и проблема.Так вы там вечно просидите, ибо на низкую сумму и древний стек никто вам на замену не пойдет, а сумму в свою очередь поднимать не будут, так как уже есть человек (вы), работающий за нее.
play.google недоступен с некоторого времени. А без него не загрузишь в Google Play свое приложение.
Изучить пару востребованных сегодня технологий и составить резюме.
Изучил и изучаю по мере возможности, даже резюме доступное только по ссылке на hh нарисовал, но без сколько-нибудь толкового приемника, которому можно передать дела, в активный поиск не выхожу - некрасиво так делать, т.к. основная вина за возникновении "незаменимости" как правило лежит на работнике.
Основная вина - лежит на индустрии в целом. Ибо доки писать надо. Вот чтобы приемник взял внутренний учебник 'как тут у нас все устроено и работает' и прочитал. Но таких учебников никто писать не умеет, ибо и не учат и не выделяют ресурсов на написание.
Да, про отсутствие нормальных доков несколько раз слышал от работников разных контор, все гонятся за скорейшим релизом, не до доков. Хотя написать подсказки для новичков с картинками куда жать если что, наверное и сейчас практикуют, где-то и полноценную актуальную документацию поддерживают. Правда если система работает с устаревшими технологиями, много желающих даже доками не заманишь.
Основная вина лежит на работодателе. Если бизнес не собирается управлять рисками, то при чем тут работник. Очевидно, работников должно быть минимум 2.
Конечно, нет. Какие приемники? Это твоя проблема только в том случае, если у тебя есть доля в фирме, которая выпускает продукт.
Если ее нет -то это проблемы владельца продукта, который такую ситуацию допустил. Басфактор в одного человека...
Вставлю свои 5 копеек :)
Вы же давно работаете в этой компании? Наверняка изучили довольно хорошо все изнутри, знаете, куда смотреть, если вдруг какой-то баг или нужно что-то новое сделать, и в целом ощущаете все на кончиках пальцев. Да, задач приходит много, но это не значит, что вы должны их делать 24/7 -- все-таки у вас тоже есть определенный ресурс, а если вы один не вывозите все задачи (причем не потому что не справляетесь по экспертизе, а просто потому что перегружены задачами), то, как минимум, вам имеет смысл попросить о расширении штата.
Если ситуация иная -- с задачами справляетесь, но уходить жалко, так как вы единственный разработчик и бросать людей не хотите (благородно, но нужно и о себе помнить: бизнес есть бизнес), то есть и иной вариант, который может вам подойдет: устройтесь на вторую работу (по ИП или по ТК РФ) :) Так вы двух зайцев убьете: и на текущем месте останетесь и с новыми технологиями на новом месте познакомитесь, и опыта нового наберетесь (да еще и приятный бонус в виде двойной зарплаты будет и диверсификации рисков). Если работаете удаленно, то этот вариант вполне адекватен и естественен
Мысли правильные, и были попытки параллельно поработать на других заказчиков, даже начальство было не против, ибо заказчики приходили от начальства в том числе (видели проги, хотели себе такие же). Но раз обжегшись на том, что подвел людей, тупо не успевая везде, зарекся брать новые проекты на стороне, а несколько ранних слава богу не требуют вмешательства. А так, идея наладить все до невмешательства и параллельно поработать на себя была изначально основной(да и сейчас не покидает), но не все можно предвидеть на несколько лет. Не ждешь от непрофильной фирмы постоянных новых идей и задач, а они регулярно волнами возникают, не ждешь забвения от любимого 3д пакета под который пишешь плагины, не ждешь от микростоков снижения выплат в разы, не ждешь от гугла блокировки монетизации для ру сектора. Это не жалоб ради, а наоборот, показать как интересно, творчески и разносторонне получалось проводить время в попытках найти приятный доп. доход. )
А чтобы вы по-прежнему ощущали себя порядочным можно предложить работодателю услуги по поддержке именно ключевого продукта, без эникейства и прочей непрофильной деятельности. С ценником эдак в 2-3 тысячи рублей в час (например) и абоненткой за саму возможность обращаться, если им нужна хотя бы минимальная срочность.
В итоге все в плюсе: вы не кинули работодателя, и при этом намного меньше связаны условностями при выборе другой работы. Работодатель получает возможность поддерживать неподдерживаемое.
Если же работодатель отказывается — не беда. Вы в режиме самовнушения уговаривайте себя, что сделали всё, что могли и поступили максимально (даже гипертрофировано) честно.
Удачи!
Просто не нужно брать на себя больше, чем требуется. А требуется мало. Для больших объемов работы нужен целые отдел, и это понятно любому. От одного программиста никто не ждёт, что он с этим всем справится. Непонятно только почему он на работе ночует, пытаясь успеть сделать работу за целый отдел.
Вероятно описанной компании просто повезло. Потому что если старший разработчик изначально не организовал всё для работы без личного вмешательства, то часто какие-то операции не то что делать никто не умеет кроме него, так даже доступа нет.
Многие привносят в бизнес отношения элементы отношений социальных. А оно того не стоит, проще когда вам платят вы работаете, мало платят мало работаете, много платят много работаете и все. А иначе будет разочерование типа: "Я тут все делал а меня выкинули!". А перекос был: "много работали за мало денег". И еще, если проблемы разработчкика не волнуют бизнес, то почему проблемы бизнеса должны волновать разработчика?
Многие привносят в бизнес отношения элементы отношений социальных. А оно того не стоит,
По моим наблюдениям такие "отношения" чаще привносят сами владельцы бизнеса, начиная ездить по ушам буллшитом про "мы одна семья". И, судя по тому, что такая практика себя не изжила, и бизнесы их процветают, "оно того не стоит" явно не относится к таким компаниям.
Crossover
А бывает и по-другому. Компания чувствует твой энтузиазм в продукте и ездит на тебе не то что за 10х оплату, а даже ниже рынка. Не забывает заливать в уши про твою исключительную пользу и что "мы семья, мы команда". А потом да, смачно выплевывает и нанимает нового. И бывшие "братья по оружию" даже с днем рождения не поздравляют.
lessons learned: всегда смотри на рынок, даже если ты в восторге от работы. Незаменимых компаний и проектов тоже нет.
А почему слово "разработчик" в данной статье не в %% ? Это проблема абсолютно любых наёмных работников. Если вдруг автор не в курсе - кругом капитализм. Капитализм это война (финансовая спецоперация) на которой одна сторона ищет способ поиметь с тебя по максимуму, а другая ищет способ поиметь по максимуму с первой. Где то в золотой середине находятся счастливчики. Остальные в большинстве случаев проигрывают "нападающим" т.к. имеют гораздо меньший ресурс чем у себя.
А по сути - с какого перепугу компания обязана держать крутого спеца всего лишь для поддержки продукта? Вы когда дома ремонт делаете потом со строителями живёте? Даже если один из 100 строителей на глаз может на 300 квадратах уровень выстроить и закрытыми глазами на скорость батарею прикрутить без инструмента...
А по сути - с какого перепугу компания обязана держать крутого спеца всего лишь для поддержки продукта?
Постановка вопроса неверная. Она должна хотеть крутого специалиста по поддержке, а не крутого разработчика. Это не одно и то же, хотя набор технологий казалось бы похож. И наша ндустрия почему-то упорно их смешивает делает вид, что вторые не нужны.
Вы когда дома ремонт делаете потом со строителями живёте?С ИТ продуктами обычно так происходит, что капитальная стройка идёт всю жизнь.
Ключевое слово "потом". А если "потом" не происходит никогда, и постоянно возникают новые хотелки (не всегда как самодурство, а вполне обоснованные), то да "живут" со строителями, причем с теми, которые начинали стройку и знают по какой диагонали брошена силовая линия, а какую задвижку лучше не задвигать. Крутизна этих специалистов только в уникальном опыте поддержки конкретной замороченной фирмы.
Всю жизнь было моей ключевой фразой - незаменимых людей не бывает!
Пишу как тимлид, стараюсь ребятам обеспечивать:
- регулярные отпуска,
- ротацию задач,
- отсутствие специализации в задачах,
- информирование по всему проекту всех,
- отсутствие конгруентных артефактов,
- перекрестное двойное ревью
- демонстрацию фичи проекта разработчиком для всех, если он написал крутую фичу
Люди видят, что с их задачами остальные ребята тоже отлично справляются, поэтому о незаменимости своей не думают, но при этом знают свои плюсы и минусы. О проектах тоже стараюсь привить мысль, что выгоднее выращивать проекты и отпускать, чем быть незаменимым в одной узкой области.
"Большая часть нашей работы — это CRUD с небольшой примесью интеграций cron-заданий." - а вы точно программист?..
Ой, как знакомо... Будучи ведущим разрабом/внедренцем на одном проекте, не нашел понимания с руководством и пришлось не очень красиво расстаться. Не буду врать, испытывал приятное злорадство, мол "сейчас без меня поплачете". Но никто не стал плакать. Да, было не легко, но Земля не остановилась. Предприятие как работало так и работает. Был некий дискомфорт, но они относительно быстро его преодолели. Вот тогда и пришло осознание, что незаменимых не бывает.
Сейчас же, являясь руководителем среднего звена, обозначил для себя критерий, что если с моим уходом работа отдела как то изменится - значит я плохой руководитель. Всегда расстраивался, когда мне звонили в отпуск с каким-то вопросом. Быть незаменимым - приятно, но плохо. Нельзя просто сменить работу. Начнутся уговоры, слезы, а груз ответственности за сделанное, будет гирями на ногах. А если Вы профессионал в своей области то работу потерять не так страшно. Профессионалы нужны всем. Особенно в ИТ)
В наше время разработчики меняют компании как перчатки.
Поэтому компании должны быть готовы к тому, что любой разработчик может уйти в любой момент. Жужжание в уши и повышение зарплаты на 3% больше не работают. Хотя не факт, что они работали и раньше.
Повесить у себя в резюме что-ли? А то в уши кладу, что человек который не держится на работе это очень плохо, а оказывается это уже норма.
Не писать документацию.
Писать дрянной код
Единолично владеть некой основной частью системы
Все это аннулируются работником должной квалификации. Некоторые фирмы специально учат работников разбирать код без комментариев и отказываются от их написания. А появление дрянного кода в принципе неизбежно в большом коллективе и "стартапах". В остальном знание шаблонов, алгоритмов а соответствующей API базы поможет как при написании так и при чтении кода.
Все это аннулируются работником должной квалификации. Некоторые фирмы специально учат работников разбирать код без комментариев и отказываются от их написания.
Я неоднократно встречал код, в котором без комментариев очень сложно понять, что имел в виду разработчик, так как полно "магии". Такое бывает, когда разработчик пишет "хитрый" код, вместо того, чтобы писать поддерживаемый. Да, разобраться можно, но это время (иногда много времени), а значит деньги компании. Ну и на мотивации сотрудника перейти в другую компанию это может отразиться, а значит снова тратятся деньги компании.
Если компания хочет чтобы в штате были только новички не желающие развиваться, то ей действительно придется вкладываться. А без комментариев ты сам захочешь написать или переписать код, чтобы как минимум самому в следующий раз было понятно что в нем - это стимул и мотивация. А если вам так сложно разобрать код над которым работает команда, что у вас уходит дополнительное время, то возможно вы чего-то не знаете. Большой объем кода даже с комментариями разбирать сложно. А если есть общее представление и вы можете масштабировать свое представление об алгоритмах в проекте (какие должны присутствовать и каким не место в отдельном участке), то вы быстрее находите в коде то, что может выглядеть не ахти и исправить это. Комментарии при этом только увеличивают объем текста для чтения.
Как бы то не было, "хитрый" или "неизбежный" нечитабельный код прочтет тренированный человек без особых затрат и с этим все равно приходиться иметь дело, а привыкший на каждом шагу видеть описание логики будет только возмущаться и тратить свое время. Кроме того человек разобравшийся в алгоритме может его улучшить, научится чему-то, или более правильно его использовать, а прочитавший описание может просто на него забить и пойти дальше городить, часто, уже написанный код.
Я про ситуации, когда приходится разбираться в большой и сложной legacy системе. Ваша уверенность в том, что любой тренированный человек без затрат разберётся в таком коде только говорит о том, что вы никогда не сталкивались с серьёзными проектами, которые содержат огромный пласт запутанного кода без комментариев. Документации нет и не было, спросить уже не у кого. Задача, например, разобраться и внедрить функционал в параллельную современную систему, либо добавить новый функционал, при этом не сломав старый.
а привыкший на каждом шагу видеть описание логики будет только возмущаться и тратить свое время.
Не нужно описывать каждый свой шаг - так делают новички, пускаясь в крайности. Нужно комментировать участки кода, по которому могут возникнуть вопросы.
Нужно комментировать участки кода, по которому могут возникнуть вопросы.
Т.е. приблизительно все. Потому что через 5 лет вопросы будут по всему. Не в смысле 'что мы тут делаем?'-- это можно разобраться. А в смысле 'а для чего все это нужно было?'
Знакомая история. Как раз ощущаю себя Шерлоком Холмсом, ведущим загадочное дело по поиску бага в огромной легаси кодовой базе, где страшно что-то тронуть, чтобы на другом конце галактики не открылась черная дыра.
А мои любимые комментарии - когда одна и та же сущность в проекте названа по разному - не иначе следы заметал какой-то незаменимый)))
Моя уверенность идет от того, что я как раз таки работаю с огромными онлайн проектами уже больше 20 лет, по заранее оговоренным правилам, где названия функций и имена переменных говорят сами за себя, да в разных проектах они разные. А те примеры, которые вы описываете, это повседневные задачи. И если вам оставили в наследство настолько непрофессиональный код, что банально не соблюдены личные правила его написания и нет ни каких критериев, по которым он проектировался или в отладчике что-то потерялось, то это беда не относится к комментированию кода. На моей же практике даже школьники, пишущие код буквально на русском языке, придерживаются хоть каких-то принципов, поняв которые можно легко сориентироваться в тексте.
Нужно комментировать участки кода, по которому могут возникнуть вопросы.
Код по которому возникают вопросы и прочая магия - это всегда код вне компетенции читающего.
А если вы надеетесь что ваша задача ограничится прочтением описания и вкостыливание туда своего решения, когда предыдущий разработчик не позаботился о расширяемости когда - то это только ухудшить его читабельность.
придерживаются хоть каких-то принципов, поняв которые можно легко сориентироваться в тексте.
Проблема не в ориентировании по коду. Проблема тут в:
"Вот тут нам Issue завели, что клиента обслужить не могут. По коду выходит, что когда 17-го число -- суббота, то клиентам, у которых четвертой буквой в фамилии является буквой 'у', мы должны отказать в обслуживании. Вот даже требование было 3 года назад так сделать. Тут как раз такой случай. Переписка по поводу этого требования, к сожалению, уже недоступна"
И никто (включая бизнес - там люди, что требования ставили, давно не работают) не может объяснить, для чего оно потребовалось и актуальны/осмысленны ли эти требования сейчас.
А вам станет легче, если в коде будет комментарий на подобии:
"Начальник был самодур или пьян и решил проверить сможем ли мы добавить такое правило, и я его добавил, удачи!"
Или просто предыдущий работник решил под конец нагадить и с тех пор не появилось квалифицированного работника, который мог бы в этом разобраться и убрать даже с присутствующими комментариями.
А если он вам в тумбочку нагадил... и тд и тп. Причем тут комментарии и документация?
Незаменимых конечно же нет, но нужно не забывать про теорию вероятности и сводить все риски к минимуму. И комментарии тут только предлог и критерий, а никак не рычаг устранение проблемы, потому что код иногда из бинарников восстанавливать приходиться. И приветы передавать не только соседу по кабинету, но и разработчикам OS и фреймворков, чтоб они пофиксили свои костыли, включая недописанные драйвера от закрытых операционных систем оригинальных устройств.
Как я уже сказал если в фирме нет ни гита ни жиры и разработчик ушел не оставив самого когда это не проблема комментариев не надо путать теплое с мягким.
А вам станет легче если в коде будет комментарий на подобии:
Вообще-то, да. Потому что такой комментарий значительно повышает вероятность того, что эту логику можно безболезненно удалить.
Общий же тезис - что разное проектное знание неизбежно со временем теряется, и чтобы с этим бороться, нужно коэффициент Cross Reference артефактов повышать. Включая добавление комментариев прямо в код.
Это повышает количество материала, за который зацепиться можно, чтобы контекст изменений восстановить путем обсуждения или поиска.
Код по которому возникают вопросы и прочая магия - это всегда код вне компетенции читающего.
То есть вы считаете, что опытный разработчик с первого взгляда на любой код понимает, что этот код делает?
А почему не со второго? Или вы думаете, что человек с кратковременным инсультом или скачущим давлением, имея за своими плечами годы опыта не превратиться в одночасье в ничего не понимающего человека?
И потом что вы подразумеваете под своим понятием "любой код"? Он что должен на слух данные с модема читать? С вашими якобы правильными выводами попахивает троллингом.
Как я уже сказал в рамках фирм в которых я работал это вполне рабочее высказывание, мало того является одним и перефразированных мною правил. Не надо забывать что они не работают без гита и документированных постановок задач, где вполне себе доступным языком описывается все внесенные в код правки начиная с 90-x. Но даже с этим приходиться рефакторить код годами.
А вы приводите примеры из фирм, которые обычно на моих глазах закрывались после ухода этого самого "незаменимого".
И тем не менее это вполне себе идеал к которому нужно стремиться, или найти того или то что поможет в этом вопросе, не начальнику, а самому программисту, благо ресурсы для этого доступны большинству прямо на рабочем месте.
Приведу в пример работу одного из отделов Касперского, где код анализируют по бинарникам и в поставленные сроки нужно проанализировать работу опкода для написания отчета, чтобы судья или следователь смог вынести приговор или задержать злоумышленника. И тут очевидно отмаза "нет документации" не прокатит, и растянуть сроки не получиться, поскольку по дедлайну человека просто отпустят за неимением доказательств из-за вашей некомпетентности. А завтра отпущенный позвонит вам и расскажет что вы ему должны за его нервы. Или за то что выполнили задачу будете потом еще угрозы получать.
Проходное тестовое задание на час - нужно расписать работу приложения по бинарнику и определить если там вирус. А банальный кейлогер там может быть, даже если в байткоде сервиса обновления какого-нибудь кодека или плейера нет его тела. Работа выполняется на удаленном рабочем столе отдельного компьютера либо из дома, либо в офисе. При том что первое задание вам дается на неделю для проверки как говориться на "робота".
Все сводится к правилу: из ресурсы/время/качество - выбери 2 из 3
"незаменимый", часто-густо помимо своей воли, является оптимальным выбором для руководства :(
" Таков уж современный корпоративный мир " (С)
Складывается ощущение, что автор никогда не занимался поддержкой legacy-продукта. Поскрипеть зубами и справиться работает, когда присутствует только одна проблема из: "отсутствия документации, дрянного кода, отсутствия возможности спросить у автора". Или когда они хотя бы не сильно запущены.
Но если софт писался 10 лет назад, документация состоит из раздела About или отсутствует от слова совсем, а предыдущий разработчик спился/умер/сидит в тюрьме, тогда начинается веселье. Я, конечно, немного утрирую, но проблемы вхождения в "пустой" проект - это далеко не лёгкие проблемы, на которые часто тратится приличное количество времени.
вас могут выбросить на улицу как щенка, если произойдет одно из следующих событий:
Мне одному кажется, что звучит как-то ... неуважительно?
Щенок, или питомец - по умолчанию неразумный и зависимый от хозяина.
Мы же с компанией - это две независимые стороны, заключившие трудовой договор. Никто никого выкинуть не может.
Да, трудовой договор можно расторгнуть по тем или иным причинам.
И именно поэтому у меня другая стратегия:
Быть готовым потерять работу (привет финансовая грамотность, включающая грамотно настроенные потоки денег, подушки, диверсифицированные активы и т.д.)
Работать так, чтобы компания во мне нуждалась больше, чем я в ней (Работать хорошо. Честно. С отдачей. Но не "прикипать" ни к компании, ни к проекту. Все это - чужое. И ни в коем случае не попадать в зависимость от компании, например, не брать кредит от работодателя)
Быть способным найти работу (Прокачивать себя как специалиста. Регулярно проходить "тестовые" интервью)
Благодаря этой нехитрой стратегии я не очень беспокоюсь по поводу сокращений. Ну, сократят - фиг с ними, получу выходное пособие, отдохну месяц, еще через 2-3 недели найду новую работу.
А расскажите про реальных 10х разработчиков? Как это выглядело и ощущалось?
Каждый человек в каком то смысле незаменим. А разработчик разве не человек? Просто с годами, наверное, "Искусство программирования" превратилось в "Технологию создания программных продуктов" и разработчик как художник в разработчика как раз-раба. Труд и работа разные понятия (корни разные) . И кесарю-кесарево, а богу-богово. Желаю всем творческого труда и достаточного дохода. И быть незаменимыми. :)
Незаменимых нет. Вопрос лишь в цене, которую придется заплатить за замену.
Нет незаменимых. Есть трудяги и ленивые. Ленивых больше. Ведь зачем напрягаться и делать что-то если тот парень все сделает? Надо только пару строк добавить и поучаствовать в митингах.
Допустим, что незаменимых нет. А заменяемость - это всего лишь вопрос времени. Тогда встаёт другой вопрос - как много денег компания готова потратить на замену "незаменимого сотрудника". Не получится ли так, что пока новый будет "въезжать" (а то, что он "въедет" в старую кодовую базу - еще вопрос открытый) - компания обонкротиться?
Простой пример: вот был разработчик Вася. Делал он продукт В. Потом Вася выгорел и из компании ушел. Продукт В. пришел поддерживать Петя. Но в продукте В. нашлось несколько багов, которые требудт закрыть клиенты. Те же клиенты ждут новых фич. А Петя еле-еле баги-то закрыть может. Что приводить к другим багам, т.к. Петя до конца не въехал ни в продукт В., ни в предметную область. В итоге, через какое-то время клиенты уходят к конкурентам, компания банкротиться... Или у неё падает прибыль. Возьмите к примеру BioWare и их последние игры...
Уже высказывалось здесь не раз и не два - незаменимых нет. Есть сумма в которую обойдётся замена. Другое дело, что, исходя из (моего личного, внутри РФ) опыта - обычно потратить х2 на нового/ых разработчиков для компании часто предпочтительней, чем удовлетворить старого. Почему так - не очень понимаю до сих пор. Я свалил еще пару лет назад в оффшор работу на иностранных дядек и чувствую себя замечательно.
Миф о незаменимом разработчике