Так в том-то и дело, что ко мне приходили резюме и в стандартном шаблонном виде, и настроенные на "достижения". И в стандартном шаблонном виде их было даже больше. С достигаторными резюме я нашел такую закономерность не потому что отношусь к этому плохо, а потому что имею опыт ответов от довольно разных кандидатов, и есть с чем сравнивать. И я сам с резюме без достигаторных шаблонов переодически получаю приглашения побеседовать, так что точно дело не в пробитии ATS.
По личному опыту проведенных собеседований, соискатели с расписанными достижениями по шаблону "сделал действие, что увеличило мировое господство компании в полтора раза" были одними из самых слабых по хард-скиллам.
И для меня чаще это ред-флаг. Видишь, что написана полная чушь, которую не измерить и не подтвердить, но кандидат будто впал в отчаяние и добавил эти выдуманные метрики, потому что на самом деле чувствует слабину в своем опыте.
Люди с дефолтным структурированным описанием опыта без прикрас из разряда "делал то-то то-то на таком стеке в такой-то команде" гораздо интереснее в общении.
На самом деле корректировка зп - самая малая из бед, если вы поручили обязанности сотруднику, с которыми он не справляется. Потому что основной вид ущерба от неквалифицированных сотрудников - это устранение ошибок от их низкой квалификации. И чем выше должность такого сотрудника, тем больше времени людей требуется для устранения этого ущерба, что измеряется десятками а то и сотнями иксов от суммы его повышения.
И для таких "не тянущих" всегда есть свои алгоритмы их отстранения от вредительства. Они далеко не в возвращении зп на предыдущий уровень.
Никто не против роста, когда он справедливо компенсируется. Чаще всего человек хочет роста для повышения компенсации, а не внутренней гармонии. Лишь когда все базовые потребности закрыты можно рассуждать о духовном. Иначе всегда материальное будет перевешивать. Так что считаю, что любое расширение обязанностей должно компенсироваться, вне зависимости от итогов этого расширения. Если этого не происходит - пахнет жареным и впаренным, нужно тщательно думать перед соглашением на такие условия.
Обычно эти внутренние мотивации конфликтуют с компенсацией за них.
Чаще в компаниях встречал подход из разряда "воу, ты круто справляешься, давай тебе еще горку полномочий выдадим, расширим твой круг обязанностей, научим тебя на трубе играть чтобы команду вдохновлял, но деньги это не важно же - зато смотри как ты вырастешь".
И приходишь ты на сеньера, получаешь быстро в подчинение команду в роли лида, а про деньги компания забывает. В итоге сидишь ты обмазанный этими доп. внутренними мотиваторами и выгоранием поглядывающим из-за плеча из-за перенагрузки, не знаешь куда потратить. А лидскую зп тебе обещают выдать через полгода-год на очередном перформанс-ревью, которое естественно шатко и ничего не гарантирует, т.к. у компаний часто нужно пояса потуже затянуть перед ними.
На данный момент наблюдаю, как начальство объявило очередные "awards", где самых-самых сотрудников награждают статуэткой и мерчем. Довольно забавно будет посмотреть, т.к. большинство победителей и номинантов из прошлогодней "awards" ушли из компании.
Говорить о спасибах следует когда остальные процессы работают приемлимо. Премирование, мотивация, планирование, например. Спасибо в данном случае лишь пудра на пончике. На спасибо велись бумеры, потому что их базовые потребности были закрыты.
В текущих реалиях самое вкусное спасибо - это деньги. А уж как их оформить и преподнести - дело десятое.
В 21-22 годах пользовался этой подпиской, когда контента было много и она сама себя окупала за покупки. За год пользования сервисами накопил чуть больше 6000 баллов, а потом перестал пользоваться из-за переезда.
По возвращению В 25ом году подключил опять из-за того, что были выгодные условия по накопительному счету для подписчиков. За 3 месяца подписки посмотрел один сериал на кинопоиске, получил 25% скидки за один заказ с наценкой в еде и какие-то невыгодные предложения по кешбекам.
Не стал продлевать бесплатный подсадочный период по истечению, так как по сравнению с 21-22 все подорожало, а выгоды от использования сервисов стал получать гораздо меньше. Самой экосистемой яндекса пользуюсь все реже, т.к. там борзометр накруток по ценам и комиссиям совсем зашкаливает уже.
Часто помещения начинают подстраиваться под роботов вместо их донастройки, потому что легче конфликтующее нечто поправить в помещении, чем дождаться толкового апдейта от производителя.
Сам стал шторы поднимать в квартире, т.к. умная ии-карта у себя внутри поняла, что они для нее непреодолимое препятствие, хотя более простая модель с лидаром легко доезжала до них и ее останавливало только столкновение со стеной.
Пару раз такой подход меня выручал. Это был больше библиотечный код с необходимостью расширения и интеграции функционала в довольно разношерстные микросервисы. Не всем нужно, никого не уговариваю :)
Он обычно и выносится. Когда в модуль, когда в отдельный репозиторий. Но поддержка со стороны модулей-потребителей никуда не денется. Отсюда и получаются дто с имплементацией интерфейсов.
Да, изменение промежуточного слоя контрактов потребует поддержки. Но иногда он дает выгоду, потому что бывает частая смена структуры дто, внутренние рефакторинги модулей и так далее. Если мы внутри отрефакторим модуль и поддержим контракты, другие модули ничего и не заметят. Если мы отрефакторим дто, другим модулям уже будет посложнее. Целесообразность использования зависит от многих вещей и в большинстве случаев избыточна, согласен.
У вас какое-то странное толкование dip. Там как раз и говорится про любую зависимость, а вы абстрагировали этот принцип только бизнес-логикой.
На практике мы можем извлечь выгоду от общения через интерфейсы вместо самих dto довольно просто. Потому что расположение dto может быть внутри модуля, и тогда при смене структуры или переносе этого dto в другой неймспейс нам придется адаптировать другие модули под новые реалии. Если же мы спрячем контракт под интерфейс вместо реализации и вынесем эти интерфейсы отдельно, зависимость между модулями ослабнет, т.к. они будут общаться через интерфейсы промежуточного слоя, и перенос реализации интерфейса в одном модуле никак не повлияет на другой модуль, использующий промежуточный контракт. Но тогда мы подпишемся на поддержку этого промежуточного слоя. На больших проектах помогает.
Так если полностью соблюдать инверсию зависимостей, то весь граничный контекст должен общаться посредством интерфейсов, а не реализации. И мы не можем передавать эту реализацию напрямую. Тут и получается, что dto имплементирует интерфейс если мы хотим передать его соблюдая dip. И на выходе получаем интерфейс, который имплементирует уже другая часть граничного контекста, что чаще всего является тем же dto.
Рационально ли это? Далеко не всегда. По солидному? Да. Усложняет код и поддержку? В разы.
У всех свой усредненный проект. У кого-то говнокод приносит немалые суммы и кормит большие команды разработки десятилетями, у кого-то даже первого пользователя за два года разработки нет, а код продолжает вылизываться сжигая деньги инвесторов.
Эти два примера я привел из реальных проектов над которыми работал.
Лично мое мнение, что dip хорош только когда архитектурно продуманы точки роста проекта. И это обычно не любой класс под интерфейсом, а те части, которые действительно могут замениться на другие реализации или адаптеры. Совсем избегать интерфейсов не советую никому, но и доводить до того, что каждая дто может в себя имплементировать под пяток интерфейсов тоже не стоит.
1) Помимо создания файлика (а в некоторых языках интерфейс не располагается в отдельном файле) есть еще регистрация этого интерфейса. Не все языки и контейнеры зависимостей поддерживают автовайринг. И часто изменения класса будет требовать изменения интерфейса, либо наоборот. За этим нужно постоянно следить. А если еще нет нормального компилятора или статического анализатора - пиши пропало и имей множество дебага, из-за того, что кто-то что-то не дописал или описал не так.
2) У интерфейсов есть преимущества и их пользу я не отрицал. Но далеко не все проекты требуют обмазывания интерфейсами со всех сторон по разным причинам. Есть mvp, есть ограничения языка и используемых библиотек, есть недостаток времени и давление со стороны менеджмента, есть внутрикомандные регламенты и т.д. и т.п.
Сеньер как раз побывал в разных ситуациях и не видит только черного и белого от использования того или иного подхода, и может сконфигурировать код в зависимости от внешних факторов для оптимальной доставки функционала, по пути решив, насколько его код будет углублен в академичную сторону.
На один и тот же вопрос джуниор и сеньер отвечают по разному.
Джуниор может вызубрить солид на википедии, а сеньер тебе расскажет примеры из практики этих букв, в том числе и примеры, когда следовало избегать слепого следования какой-либо буквы солида, и когда та же буква D в итоге незнамо как переусложнила код и поддержку из-за обилия интерфейсов, а подмены реализации этих интерфейсов в приложении так и не случилось ни разу.
Джуниор тебе напишет алгоритм бинарного поиска, а у сеньера есть пару случаев из практики, когда люди писали этот бинарный поиск, и его поддержка и последующее устранение заняло несколько недель возни с легасней, потому что изначально не использовали более подходящие для этого инструменты.
Джуниор расскажет про базовую авторизацию фреймворка, потому что недавно читал доку и знания освежил. Сеньер расскажет про опыт использования различных подходов к авторизации на этом фреймворке и расскажет про бандлы, которые лучше стороной обходить, если не хотите столкнуться с теми то и теми то проблемами.
В целом, когда я задаю подобные теоретические вопросы на собеседовании, всегда стараюсь по первичному ответу понять погруженность в конкретную тему, и копать дальше, если есть куда. Только так можно раскрыть опыт человека. И не ответ на некоторые вопросы не означает, что человек провалил собеседование, потому что оно состоит из нескольких теоретических частей, по которым ты в целом можешь понимать, на какой проект и роль можно определить человека, и какой у него технический кругозор, абмиции и т.д.
Да, есть некоторые очень душные вопросы и задачки, по которым пытаются понять, сможет ли человек сделать хоть что-то. Но в целом, вам задают эти вопросы, потому что на общих терминах в индустрии происходит общение внутри команды. И даже если вы сами пересобрали все паттерны проектирования и сами досмыслили базовые архитектурные принципы, вы будете очень долго доносить идею до команды. И в команде вам скорее всего ответят, что "да ты же предлагаешь такую-то аббревиатуру". Быстрая синхронизация с командой и общение на одном языке на самом деле нередко перевешивают харды человека.
Люди повышают себе зарплату путем смены работы. Компании об этом знают, но адекватно реагируют на это единицы. Продолжается такое десятилетиями. Значит, людей, которые могут себе позволить тратить огромные бюджеты на найм вместо удержания, такая ситуация устраивает.
Некоторые даже специально настроены на постоянную смену днк внутри компании, и считают эти обновления коллективов во благо, потому что таким образом перенимается опыт новых сотрудников с другими подходами из более крутых команд. Иногда такое действительно работает, и проект начинает жить новой жизнью. Иногда становится лишь хуже, потому что компания сама оказывается не готова к новым подходам, либо новые люди не оправдывают надежд.
Уход ключевых сотрудников всегда является достаточно серьезным уроном по командам, в которых они работают. Но и случается ситуация, что команда бизнесу особо не интересна. И бизнес пускает ее на самотек вместо жесткого устранения, постепенно переводя на поддержку. Это и выливается в сопротивление от всех отделов внутри компании для этой команды.
В общем, чаще всего не hr принимают эти решения, а кто-то повыше. И полную картину вряд ли донесут полностью до рядового сотрудника, который хочет повышения.
Код может быть идеальным и работать без багов, но бизнес может использовать фичу себе в убыток.
Или фичу могут тормозить вообще по независимым от разработчика различным причинам.
Или количество пофикшенных багов может говорить о том, что код изначально был плохо написан, и его целый год с гордостью залатывали, по пути плодя еще больше багов.
Или написанную документацию прочел один человек, а остальным она оказалась не нужна.
Или собеседования велись в отдел, который на этапе формирования, и прибыль будет приносить лишь спустя несколько лет.
Не стоит перекладывать ответственность бизнеса на реализаторов. Они не могут быть ответственны за результат и прибыль, потому что над ними, как правило, есть своя иерархия управленцев, которые уже и влияют на прибыль.
Как мне видится, оценивать работу разработчика можно по количеству оставленных артефактов и следованию процессам разработки в компании, но не по итоговому результату отдела. Потому что чем больше компания, тем меньше разработчик может на что-то влиять в ее процессах непосредственно.
Писал сопроводительные письма когда имел очень ограниченный список вакансий на выбор, чтобы они сыграли дополнительным бонусом при рассмотрении моей кандидатуры. Пару раз помогло, и люди были впечатлены изложением и подходом.
Позже, когда стал более уверен в своих силах, и список подходящих вакансий разросся, попробовал тоже присылать сопроводительное письмо. Столкнулся с тем, что в большинстве случаев люди даже с резюме ознакамливались лишь во время непосредственного диалога на собеседовании, а сопроводительное письмо отфильтровывал hr и не пускал дальше себя. Получалось, что люди задавали вопросы, ответы на которые были в сопроводительном письме, но прочитать его люди не стремились.
Остановился на отсутствии сопроводительного письма и довольно подробном описании резюме. Плюс готовности расширить информацию о себе, если резюме оказалось недостаточным. На данный момент думаю даже сократить резюме, но желания писать сопроводительное письмо не возникает совсем. Считаю что не стоит оно того.
Так в том-то и дело, что ко мне приходили резюме и в стандартном шаблонном виде, и настроенные на "достижения". И в стандартном шаблонном виде их было даже больше. С достигаторными резюме я нашел такую закономерность не потому что отношусь к этому плохо, а потому что имею опыт ответов от довольно разных кандидатов, и есть с чем сравнивать. И я сам с резюме без достигаторных шаблонов переодически получаю приглашения побеседовать, так что точно дело не в пробитии ATS.
По личному опыту проведенных собеседований, соискатели с расписанными достижениями по шаблону "сделал действие, что увеличило мировое господство компании в полтора раза" были одними из самых слабых по хард-скиллам.
И для меня чаще это ред-флаг. Видишь, что написана полная чушь, которую не измерить и не подтвердить, но кандидат будто впал в отчаяние и добавил эти выдуманные метрики, потому что на самом деле чувствует слабину в своем опыте.
Люди с дефолтным структурированным описанием опыта без прикрас из разряда "делал то-то то-то на таком стеке в такой-то команде" гораздо интереснее в общении.
На самом деле корректировка зп - самая малая из бед, если вы поручили обязанности сотруднику, с которыми он не справляется. Потому что основной вид ущерба от неквалифицированных сотрудников - это устранение ошибок от их низкой квалификации. И чем выше должность такого сотрудника, тем больше времени людей требуется для устранения этого ущерба, что измеряется десятками а то и сотнями иксов от суммы его повышения.
И для таких "не тянущих" всегда есть свои алгоритмы их отстранения от вредительства. Они далеко не в возвращении зп на предыдущий уровень.
Никто не против роста, когда он справедливо компенсируется. Чаще всего человек хочет роста для повышения компенсации, а не внутренней гармонии. Лишь когда все базовые потребности закрыты можно рассуждать о духовном. Иначе всегда материальное будет перевешивать. Так что считаю, что любое расширение обязанностей должно компенсироваться, вне зависимости от итогов этого расширения. Если этого не происходит - пахнет жареным и впаренным, нужно тщательно думать перед соглашением на такие условия.
Обычно эти внутренние мотивации конфликтуют с компенсацией за них.
Чаще в компаниях встречал подход из разряда "воу, ты круто справляешься, давай тебе еще горку полномочий выдадим, расширим твой круг обязанностей, научим тебя на трубе играть чтобы команду вдохновлял, но деньги это не важно же - зато смотри как ты вырастешь".
И приходишь ты на сеньера, получаешь быстро в подчинение команду в роли лида, а про деньги компания забывает. В итоге сидишь ты обмазанный этими доп. внутренними мотиваторами и выгоранием поглядывающим из-за плеча из-за перенагрузки, не знаешь куда потратить. А лидскую зп тебе обещают выдать через полгода-год на очередном перформанс-ревью, которое естественно шатко и ничего не гарантирует, т.к. у компаний часто нужно пояса потуже затянуть перед ними.
Так что нет - давайте лучше деньгами.
На данный момент наблюдаю, как начальство объявило очередные "awards", где самых-самых сотрудников награждают статуэткой и мерчем. Довольно забавно будет посмотреть, т.к. большинство победителей и номинантов из прошлогодней "awards" ушли из компании.
Говорить о спасибах следует когда остальные процессы работают приемлимо. Премирование, мотивация, планирование, например. Спасибо в данном случае лишь пудра на пончике. На спасибо велись бумеры, потому что их базовые потребности были закрыты.
В текущих реалиях самое вкусное спасибо - это деньги. А уж как их оформить и преподнести - дело десятое.
В 21-22 годах пользовался этой подпиской, когда контента было много и она сама себя окупала за покупки. За год пользования сервисами накопил чуть больше 6000 баллов, а потом перестал пользоваться из-за переезда.
По возвращению В 25ом году подключил опять из-за того, что были выгодные условия по накопительному счету для подписчиков. За 3 месяца подписки посмотрел один сериал на кинопоиске, получил 25% скидки за один заказ с наценкой в еде и какие-то невыгодные предложения по кешбекам.
Не стал продлевать бесплатный подсадочный период по истечению, так как по сравнению с 21-22 все подорожало, а выгоды от использования сервисов стал получать гораздо меньше. Самой экосистемой яндекса пользуюсь все реже, т.к. там борзометр накруток по ценам и комиссиям совсем зашкаливает уже.
Часто помещения начинают подстраиваться под роботов вместо их донастройки, потому что легче конфликтующее нечто поправить в помещении, чем дождаться толкового апдейта от производителя.
Сам стал шторы поднимать в квартире, т.к. умная ии-карта у себя внутри поняла, что они для нее непреодолимое препятствие, хотя более простая модель с лидаром легко доезжала до них и ее останавливало только столкновение со стеной.
Пару раз такой подход меня выручал. Это был больше библиотечный код с необходимостью расширения и интеграции функционала в довольно разношерстные микросервисы. Не всем нужно, никого не уговариваю :)
Перенести, переименовать, свойство со снейк-кейса на кемел по внутреннему регламенту отформатировать и т.д.
На самом деле, в ходе бурной работы над проектом могут быть самые непредсказуемые изменения, в том числе не всегда чистые и честные
Он обычно и выносится. Когда в модуль, когда в отдельный репозиторий. Но поддержка со стороны модулей-потребителей никуда не денется. Отсюда и получаются дто с имплементацией интерфейсов.
Да, изменение промежуточного слоя контрактов потребует поддержки. Но иногда он дает выгоду, потому что бывает частая смена структуры дто, внутренние рефакторинги модулей и так далее. Если мы внутри отрефакторим модуль и поддержим контракты, другие модули ничего и не заметят. Если мы отрефакторим дто, другим модулям уже будет посложнее. Целесообразность использования зависит от многих вещей и в большинстве случаев избыточна, согласен.
У вас какое-то странное толкование dip. Там как раз и говорится про любую зависимость, а вы абстрагировали этот принцип только бизнес-логикой.
На практике мы можем извлечь выгоду от общения через интерфейсы вместо самих dto довольно просто. Потому что расположение dto может быть внутри модуля, и тогда при смене структуры или переносе этого dto в другой неймспейс нам придется адаптировать другие модули под новые реалии. Если же мы спрячем контракт под интерфейс вместо реализации и вынесем эти интерфейсы отдельно, зависимость между модулями ослабнет, т.к. они будут общаться через интерфейсы промежуточного слоя, и перенос реализации интерфейса в одном модуле никак не повлияет на другой модуль, использующий промежуточный контракт. Но тогда мы подпишемся на поддержку этого промежуточного слоя. На больших проектах помогает.
Так если полностью соблюдать инверсию зависимостей, то весь граничный контекст должен общаться посредством интерфейсов, а не реализации. И мы не можем передавать эту реализацию напрямую. Тут и получается, что dto имплементирует интерфейс если мы хотим передать его соблюдая dip. И на выходе получаем интерфейс, который имплементирует уже другая часть граничного контекста, что чаще всего является тем же dto.
Рационально ли это? Далеко не всегда. По солидному? Да. Усложняет код и поддержку? В разы.
У всех свой усредненный проект. У кого-то говнокод приносит немалые суммы и кормит большие команды разработки десятилетями, у кого-то даже первого пользователя за два года разработки нет, а код продолжает вылизываться сжигая деньги инвесторов.
Эти два примера я привел из реальных проектов над которыми работал.
Лично мое мнение, что dip хорош только когда архитектурно продуманы точки роста проекта. И это обычно не любой класс под интерфейсом, а те части, которые действительно могут замениться на другие реализации или адаптеры. Совсем избегать интерфейсов не советую никому, но и доводить до того, что каждая дто может в себя имплементировать под пяток интерфейсов тоже не стоит.
1) Помимо создания файлика (а в некоторых языках интерфейс не располагается в отдельном файле) есть еще регистрация этого интерфейса. Не все языки и контейнеры зависимостей поддерживают автовайринг. И часто изменения класса будет требовать изменения интерфейса, либо наоборот. За этим нужно постоянно следить. А если еще нет нормального компилятора или статического анализатора - пиши пропало и имей множество дебага, из-за того, что кто-то что-то не дописал или описал не так.
2) У интерфейсов есть преимущества и их пользу я не отрицал. Но далеко не все проекты требуют обмазывания интерфейсами со всех сторон по разным причинам. Есть mvp, есть ограничения языка и используемых библиотек, есть недостаток времени и давление со стороны менеджмента, есть внутрикомандные регламенты и т.д. и т.п.
Сеньер как раз побывал в разных ситуациях и не видит только черного и белого от использования того или иного подхода, и может сконфигурировать код в зависимости от внешних факторов для оптимальной доставки функционала, по пути решив, насколько его код будет углублен в академичную сторону.
На один и тот же вопрос джуниор и сеньер отвечают по разному.
Джуниор может вызубрить солид на википедии, а сеньер тебе расскажет примеры из практики этих букв, в том числе и примеры, когда следовало избегать слепого следования какой-либо буквы солида, и когда та же буква D в итоге незнамо как переусложнила код и поддержку из-за обилия интерфейсов, а подмены реализации этих интерфейсов в приложении так и не случилось ни разу.
Джуниор тебе напишет алгоритм бинарного поиска, а у сеньера есть пару случаев из практики, когда люди писали этот бинарный поиск, и его поддержка и последующее устранение заняло несколько недель возни с легасней, потому что изначально не использовали более подходящие для этого инструменты.
Джуниор расскажет про базовую авторизацию фреймворка, потому что недавно читал доку и знания освежил. Сеньер расскажет про опыт использования различных подходов к авторизации на этом фреймворке и расскажет про бандлы, которые лучше стороной обходить, если не хотите столкнуться с теми то и теми то проблемами.
В целом, когда я задаю подобные теоретические вопросы на собеседовании, всегда стараюсь по первичному ответу понять погруженность в конкретную тему, и копать дальше, если есть куда. Только так можно раскрыть опыт человека. И не ответ на некоторые вопросы не означает, что человек провалил собеседование, потому что оно состоит из нескольких теоретических частей, по которым ты в целом можешь понимать, на какой проект и роль можно определить человека, и какой у него технический кругозор, абмиции и т.д.
Да, есть некоторые очень душные вопросы и задачки, по которым пытаются понять, сможет ли человек сделать хоть что-то. Но в целом, вам задают эти вопросы, потому что на общих терминах в индустрии происходит общение внутри команды. И даже если вы сами пересобрали все паттерны проектирования и сами досмыслили базовые архитектурные принципы, вы будете очень долго доносить идею до команды. И в команде вам скорее всего ответят, что "да ты же предлагаешь такую-то аббревиатуру". Быстрая синхронизация с командой и общение на одном языке на самом деле нередко перевешивают харды человека.
Люди повышают себе зарплату путем смены работы. Компании об этом знают, но адекватно реагируют на это единицы. Продолжается такое десятилетиями. Значит, людей, которые могут себе позволить тратить огромные бюджеты на найм вместо удержания, такая ситуация устраивает.
Некоторые даже специально настроены на постоянную смену днк внутри компании, и считают эти обновления коллективов во благо, потому что таким образом перенимается опыт новых сотрудников с другими подходами из более крутых команд. Иногда такое действительно работает, и проект начинает жить новой жизнью. Иногда становится лишь хуже, потому что компания сама оказывается не готова к новым подходам, либо новые люди не оправдывают надежд.
Уход ключевых сотрудников всегда является достаточно серьезным уроном по командам, в которых они работают. Но и случается ситуация, что команда бизнесу особо не интересна. И бизнес пускает ее на самотек вместо жесткого устранения, постепенно переводя на поддержку. Это и выливается в сопротивление от всех отделов внутри компании для этой команды.
В общем, чаще всего не hr принимают эти решения, а кто-то повыше. И полную картину вряд ли донесут полностью до рядового сотрудника, который хочет повышения.
Так эти метрики не влияют на прибыль компании.
Код может быть идеальным и работать без багов, но бизнес может использовать фичу себе в убыток.
Или фичу могут тормозить вообще по независимым от разработчика различным причинам.
Или количество пофикшенных багов может говорить о том, что код изначально был плохо написан, и его целый год с гордостью залатывали, по пути плодя еще больше багов.
Или написанную документацию прочел один человек, а остальным она оказалась не нужна.
Или собеседования велись в отдел, который на этапе формирования, и прибыль будет приносить лишь спустя несколько лет.
Не стоит перекладывать ответственность бизнеса на реализаторов. Они не могут быть ответственны за результат и прибыль, потому что над ними, как правило, есть своя иерархия управленцев, которые уже и влияют на прибыль.
Как мне видится, оценивать работу разработчика можно по количеству оставленных артефактов и следованию процессам разработки в компании, но не по итоговому результату отдела. Потому что чем больше компания, тем меньше разработчик может на что-то влиять в ее процессах непосредственно.
Писал сопроводительные письма когда имел очень ограниченный список вакансий на выбор, чтобы они сыграли дополнительным бонусом при рассмотрении моей кандидатуры. Пару раз помогло, и люди были впечатлены изложением и подходом.
Позже, когда стал более уверен в своих силах, и список подходящих вакансий разросся, попробовал тоже присылать сопроводительное письмо. Столкнулся с тем, что в большинстве случаев люди даже с резюме ознакамливались лишь во время непосредственного диалога на собеседовании, а сопроводительное письмо отфильтровывал hr и не пускал дальше себя. Получалось, что люди задавали вопросы, ответы на которые были в сопроводительном письме, но прочитать его люди не стремились.
Остановился на отсутствии сопроводительного письма и довольно подробном описании резюме. Плюс готовности расширить информацию о себе, если резюме оказалось недостаточным. На данный момент думаю даже сократить резюме, но желания писать сопроводительное письмо не возникает совсем. Считаю что не стоит оно того.