Меня так госка упустила. Прошёл собеседование, отправили анкету в СБ. Обещали месяц, после месяца сказали, что ещё рассматривают. Я принял офер другой компании. Эти потом опомнились, мол, куда же ты убежал?
Серьёзно? В прод релизит сам разработчик? Расскажите подробнее? Это раскатка сначала на маленькой аудитории? Как тестирование строится? Кто за факапы отвечает?
Ну да, "чтобы он подумал, что" - это не про явные договорённости "ты мне, я тебе", а скорее про симбиоз.
Программисту нужно до зарезу перейти с Vue2 на Vue3, а у менеджера сроки-дедлайны, и не очень понятно, зачем отдавать человеко-месяц фронта на работу, результатом которой будет "всё осталось ровно так, как было". Вопрос в аргументации
Это ваша постановка видения ситуации, вы так интерпретируете. Я написал по-другому. Это перечислено в числе прочих заходов, и как последний вариант. У меня нигде не написано, что руководитель шантажирует продвижением вашей идеи за мелкий прайс.
Эффективно, когда разработчик сразу заявляет: вижу риск, что задача не будет выполнена, потому что то-то и то-то. Предлагаю... или жду ответа, как быть. Тут выкидывается куча ненужной коммуникации, а также риски, что уведомлений о сотне задач руководитель не увидит нужное. Быстро и сразу к делу.
Нет, вопрос вовсе не в этом, а в том, что если руководитель не согласен развивать ценные идеи разработчиков, если лавры достанутся не ему – это очень плохой руководитель.
Хочется ответить репликой из "Москва слезам не верит": "Гоша! Нельзя быть таким серьёзным!"
Дело не во вредности руководителя, а в том, что он тупо не понимает, в чём преимущество нововведения. Можно просто принять, что руководитель тупой (хотя на самом деле может быть n причин что-то тормозить, о которых разработчик просто не догадывается) :) Вопрос человеческого взаимодействия. Если разработчик сам убеждён, что идея отличная, иногда он считает, что это должно быть абсолютно очевидно и другим. А если это не так, почему-то обижается.
...а руководитель непрерывно мониторит изменения в тикетах
И является слабым местом всей схемы. Конечно, мне приходится мониторить изменения в тикетах, но это а) Повышенная ментальная нагрузка, в одном из спринтов у меня было около 100 задач б) Неэффективно
Вы писали совсем о другом: убедить руководителя, что идея разработчика принадлежит ему – иначе он откажется её продвигать. Это совершенно нездоровые отношения.
Я не писал, что это необходимое условие. Но бывает, что если твоя личная идея не двигается в лоб, нужно "подарить" её руководителю, и тогда - о чудо! - она вдруг начинает двигаться быстрее.
Я когда-то думал, как вы, и тоже считал это нездоровой ситуацией. Потом со временем понял, что так тоже бывает, это часть жизни. Вопрос приоритетов: нужно, чтобы твоя идея воплотилась, или нужно, чтобы тебя почитали. Это разная мотивация. Я сам получаю кайф от того, что люди со временем начинают действовать так, как я бы хотел, чтобы они действовали, пусть даже совершенно не упоминая меня в качестве инициатора перемен.
Про п.4 я сразу предполагал, что его поймут не только лишь все :) Да, джобхоппинг в среднем был проще до недавнего времени. Но бывают случаи, когда и компания хочет разработчику что-то интересное дать, и разработчик хочет больше денег и статуса, а у них ничего не получается из-за сущей ерунды - они просто не начинают говорить об этом. И в последнее время, кмк, это станет актуальнее в связи с кризисом в экономике и тем, что программистов, кажется, на рынке труда становится больше, а вакансий меньше.
П.5 да, полного доверия не будет, как и дружбы и любви до гроба. Тут скорее я хотел дать понять, что разработчик может управлять тем, как относятся к нему другие. "Может управлять" ключевое. А то многие же пишут, что все начальники козлы, все менеджеры только "эффективные", с такой обречённостью.
Если задача приостановлена, это должно быть отражено в тикете. Тогда и вопросов не будет.
Тут самый вопрос в том, кто выступает инициатором изменений. Две ситуации: "Разработчик написал в тикете, что задача не решается потому-то, и спокойно её отложил" и "Разработчик написал в тикете, что задача не решается потому-то, и обговорил с руководителем новые сроки её исполнения". Почти одно и то же, да.
Не может быть никаких исключений. В сколько-нибудь серьёзном проекте (где в принципе присутствует иерархия руководства) у программистов просто не должно быть доступа на прод
По-хорошему, да. Особенно когда у вас крупная компания, и никакой даже не стратап
То же самое. PR должен включать в себя деплой скрипт, в котором всё это делается, запускаемый релиз менеджером. В идеале ещё и роллбэк скрипт, на случай непредвиденностей.
В идеале да, так надёжнее. Но есть срочные хотфиксы, например.
Фичи не должны напрямую мержиться в мастер. Сначала в релизный бранч, где всё в комплексе тестируется, и только после того, как QA дали добро – в мастер и на прод.
Всё верно. Конечно, у нас есть релиз-ветки. Вопрос в том, чтобы передать информацию и важных деталях релиза конкретной фичи от разработчика (который это сконструировал) выше так, чтобы было надёжно. Иногда разработчик забывает это сделать.
Я бы в конторе, где такое происходит, работать не хотел. Руководитель, радостно присваивающий себе идеи подчинённых, и подчинённые-подхалимы, которые его к этому подталкивают.
Ну тут сказать нечего. Если вам дают руку помощи, а вам кажется, что ваш труд присваивают, то просто работайте. У меня был один разработчик. Мы как-то начали пилить Nodejs-библиотеку, я, совершенно не думая, в авторах сначала указал свою фамилию, потом его. Он мне закатил хорошенькую истерику по поводу того, что я присваиваю его труд :) Слава богу, в скорости уволился сам.
Тоже при найме молодёжи сталкивался с тем, что Git - это либо "такой плагин для VScode", либо "такой сайт, где ещё репозитории". Сказать, что был в шоке - ничего не сказать. Людям не преподают идею системы контроля версий
Программировал для себя с 14, после школы работал года полтора на какую-то контору. Знания на уровне миддла. Опыта не так много, но быстро соображает. Сеньором не взяли бы, конечно, но если тянет миддловскую нагрузку, почему бы не платить?
Нет. В здании, из которого Магадан хорошо видно
Меня так госка упустила. Прошёл собеседование, отправили анкету в СБ. Обещали месяц, после месяца сказали, что ещё рассматривают. Я принял офер другой компании. Эти потом опомнились, мол, куда же ты убежал?
Вот смущает порядок "мердж в master, далее тесты". А если тесты упали? Revert-commit, reset --hard?
О да, в сериале эта идея гениально показана!
Серьёзно? В прод релизит сам разработчик? Расскажите подробнее? Это раскатка сначала на маленькой аудитории? Как тестирование строится? Кто за факапы отвечает?
Ну да, "чтобы он подумал, что" - это не про явные договорённости "ты мне, я тебе", а скорее про симбиоз.
Программисту нужно до зарезу перейти с Vue2 на Vue3, а у менеджера сроки-дедлайны, и не очень понятно, зачем отдавать человеко-месяц фронта на работу, результатом которой будет "всё осталось ровно так, как было". Вопрос в аргументации
Это ваша постановка видения ситуации, вы так интерпретируете. Я написал по-другому. Это перечислено в числе прочих заходов, и как последний вариант. У меня нигде не написано, что руководитель шантажирует продвижением вашей идеи за мелкий прайс.
Эффективно, когда разработчик сразу заявляет: вижу риск, что задача не будет выполнена, потому что то-то и то-то. Предлагаю... или жду ответа, как быть. Тут выкидывается куча ненужной коммуникации, а также риски, что уведомлений о сотне задач руководитель не увидит нужное. Быстро и сразу к делу.
Хочется ответить репликой из "Москва слезам не верит": "Гоша! Нельзя быть таким серьёзным!"
Дело не во вредности руководителя, а в том, что он тупо не понимает, в чём преимущество нововведения. Можно просто принять, что руководитель тупой (хотя на самом деле может быть n причин что-то тормозить, о которых разработчик просто не догадывается) :)
Вопрос человеческого взаимодействия. Если разработчик сам убеждён, что идея отличная, иногда он считает, что это должно быть абсолютно очевидно и другим. А если это не так, почему-то обижается.
Затаился перед прыжком вбок ))
И является слабым местом всей схемы. Конечно, мне приходится мониторить изменения в тикетах, но это а) Повышенная ментальная нагрузка, в одном из спринтов у меня было около 100 задач б) Неэффективно
Я не писал, что это необходимое условие. Но бывает, что если твоя личная идея не двигается в лоб, нужно "подарить" её руководителю, и тогда - о чудо! - она вдруг начинает двигаться быстрее.
Я когда-то думал, как вы, и тоже считал это нездоровой ситуацией. Потом со временем понял, что так тоже бывает, это часть жизни. Вопрос приоритетов: нужно, чтобы твоя идея воплотилась, или нужно, чтобы тебя почитали. Это разная мотивация. Я сам получаю кайф от того, что люди со временем начинают действовать так, как я бы хотел, чтобы они действовали, пусть даже совершенно не упоминая меня в качестве инициатора перемен.
Про п.4 я сразу предполагал, что его поймут не только лишь все :)
Да, джобхоппинг в среднем был проще до недавнего времени. Но бывают случаи, когда и компания хочет разработчику что-то интересное дать, и разработчик хочет больше денег и статуса, а у них ничего не получается из-за сущей ерунды - они просто не начинают говорить об этом. И в последнее время, кмк, это станет актуальнее в связи с кризисом в экономике и тем, что программистов, кажется, на рынке труда становится больше, а вакансий меньше.
П.5 да, полного доверия не будет, как и дружбы и любви до гроба. Тут скорее я хотел дать понять, что разработчик может управлять тем, как относятся к нему другие. "Может управлять" ключевое. А то многие же пишут, что все начальники козлы, все менеджеры только "эффективные", с такой обречённостью.
Я же сам был разрабом лет 10, у меня были хорошие тимлиды, но чаще посредственные или плохие. Я стараюсь быть для своих разработчиков хорошим.
Отвечу так же попунктно
Тут самый вопрос в том, кто выступает инициатором изменений. Две ситуации: "Разработчик написал в тикете, что задача не решается потому-то, и спокойно её отложил" и "Разработчик написал в тикете, что задача не решается потому-то, и обговорил с руководителем новые сроки её исполнения". Почти одно и то же, да.
По-хорошему, да. Особенно когда у вас крупная компания, и никакой даже не стратап
В идеале да, так надёжнее. Но есть срочные хотфиксы, например.
Всё верно. Конечно, у нас есть релиз-ветки. Вопрос в том, чтобы передать информацию и важных деталях релиза конкретной фичи от разработчика (который это сконструировал) выше так, чтобы было надёжно. Иногда разработчик забывает это сделать.
Ну тут сказать нечего. Если вам дают руку помощи, а вам кажется, что ваш труд присваивают, то просто работайте. У меня был один разработчик. Мы как-то начали пилить Nodejs-библиотеку, я, совершенно не думая, в авторах сначала указал свою фамилию, потом его. Он мне закатил хорошенькую истерику по поводу того, что я присваиваю его труд :)
Слава богу, в скорости уволился сам.
Есть же простое решение: открыть свою фирму и писать свой код. Тогда вам никто не будет говорить, что надо делать.
Либо это звучит как "кладите мою зарплату в тумбочку и отвалите, я занимаюсь тем, что мне нравится".
А какие вредные?
Тоже при найме молодёжи сталкивался с тем, что Git - это либо "такой плагин для VScode", либо "такой сайт, где ещё репозитории". Сказать, что был в шоке - ничего не сказать. Людям не преподают идею системы контроля версий
Хороший эвфемизм к "уволить дармоедов из отдела инклюзивности нахрен"
Программировал для себя с 14, после школы работал года полтора на какую-то контору. Знания на уровне миддла. Опыта не так много, но быстро соображает. Сеньором не взяли бы, конечно, но если тянет миддловскую нагрузку, почему бы не платить?
Ну и не знайте. Таланты с рынка будут доставаться нам. Пусть для вас такие люди будут погромистами
Ну по каким ещё причинам нанимают программистов, на ваш взгляд? Кроме модельной внешности?