Хорошая реплика. Уточнил бы, «а 20%-то жалко, поди?» и смотрел, что скажет. Вполне возможно, что скажет, «да не, мне здесь нормально, всего хватает». Это значит, что ему хорошо и он мотивирован. Или скажет «я планирую их заработать и здесь» — опять же, отличный повод про это поговорить. В общем, я только за.
На самом деле, любому разработчику следует время от времени на собеседования ходить. Чтобы понимать, что и где требуется и не застревать в «локальной компетентности» текущей компании. За одно — может чего полезного принесёт.
Я несколько раз наблюдал, как после ухода ключевого сотрудника из небольшой компании, её штормило примерно неделю, а потом всё приходило в норму и было гораздо лучше, чем раньше ;).
Но опять же, люди внезапно смертны. Поэтому в любом случае bus-factor надо делать хоть немного, но больше единицы.
Наверное, я не очень точно ответил. Давайте считать, что по построению — руководитель всегда готов ответить на вопрос о перспективах. И будет периодически мониторить, интересно ли Асе то, чем она занимается.
Если при этих условиях Ася так и не узнала про свои перспективы, то либо их нет (и нормально, что она уходит туда, где они есть). Либо они есть. Но, прежде чем прийти с внешним оффером, Ася ни разу про них не спросила. И даже не обозначила, что ей всё надоело / она хочет чего-то большего. Вот как раз тут и возникает вопрос про необходимые качества, перечисленные в вашей цитате.
Но я совершенно согласен с тезисом, что иногда руководители, сами того не желая, прилагают гораздо больше усилий к тому, чтобы хороший сотрудник ушёл, чем сам сотрудник.
Всё тайное когда-то становится явным. Я не приветствую раскрытие зарплат (ровно потому, что иногда нужно отдельно разъяснить, почему они именно такие) но не считаю, что при этом произойдёт катастрофа.
Это достаточно интересная техническая задача ;). Опять же, как отмечено выше, факт, что клиника оказывает какую-то услугу по ДМС не означает, что она не окажется внезапно платной. Даже в рамках одной и той же услуги могут быть нюансы.
Ну, лучший вариант — да. А что, если не знают пока, не нашли общий язык? Можно, конечно, работу поменять. Или всё-таки искать тот самый общий язык. Но только для того, чтобы он появился нужно понимать язык, на котором говорит бизнес. Тогда и своему, разработческому, языку научить его будет легче. Об этом примерно половина статьи :)
Если каждый год новый легаси-проект, то только идти с евангелистикой — писать книжки, статьи на хабр :), на конфах выступать — и всех убеждать, что надо писать чистый код.
Если продукт более-менее надолго, то тут проще — жёсткое ревью кода, почаще встречаться и обсуждать архитектуру, юнит-тесты, опять же. Короче, сделать систему, в которой писать плохо просто не получится. И, да, это сложно, неблагодарно и не всегда понятно, с какой стороны подходить.
Переписать такой код с нуля не удастся, даже и не мечтайте :). Самое эффективное, что можно сделать — это точечно переписывать наиболее страшные куски, которые доставляют больше всего боли. А то, что не переписывается, инкапсулировать и не трогать. В результате получится, что части, в которых изменения происходят чаще всего, будут более-менее приличными, а старый древний копролит мамонта будет изолирован, и вам не надо будет туда лезть. Несколько лет назад я работал над продуктом, которому такой подход помог.
Рефакторинг ради эстетики, действительно несёт мало пользы, Однако, он необходим, если:
— изменения в проекте становятся дорогими и долгими из-за низкого качества кода и архитектуры
— в ближайшее время планируется развитие продукта с добавлением новых фичей (у нормального живого продукта это состояние перманентно)
— как альтернатива предыдущему — команда проекта будет расширяться
А вся история с рефакторингом ни во что не выльется, после рефакторинга туда внесут такие-же изменения, о которых тот кто рефакторил, даже не задумывался и как результат не подготовил код…
А вот этот абзац серьёзно настораживает. Во-первых, мы не можем подготовить код к любым изменениям, поэтому такое положение дел совершенно нормально. С другой стороны, что значит «внесут изменения»? Придёт незнакомый человек в офис и испортит красивый код?
Если с командой всё в порядке, то такие изменения как минимум обсуждаются заранее. В том числе и с тем, кто делал рефакторинг. Уверяю вас, чтобы сделать кривой костыль в условиях, когда код обсуждается и регулярно проводится ревью, надо очень постараться. Особенно после того, как код приведён в относительный порядок.
А вот если даже небольшие правки ведут к костылям, то надо прежде всего настраивать коммуникацию и распределение ролей в команде, а делать рефакторинг в такой ситуации — действительно, пустая трата времени и денег заказчика. Это симптомы того, что у кода нет владельца (aka code owner) или он не справляется.
В точку прямо.
Без тестов грустно. Иногда помогает — вместо честных юнит-тестов автоматизировать хотя бы функциональные. По принципу — все контролы на месте, ничего не пропало. Инструмент не посоветую, но можно поспрашивать тестировщиков они должны знать. Ну и покрыть юнит-тестами для начала хотя бы «стыки» между компонентами. По опыту, самая большая засада — именно при интеграции.
По второму вопросу точно буду отдельно что-то писать. В двух словах — бизнес говорит на языке денег, поэтому разговаривать с ним надо на языке денег. Поддержка кода и внедрение стоят времени. Цель рефакторинга — сэкономить время на внедрение новых фич и избавиться от части багов (обычно попутно получается). Соответственно, я обычно некоторое время собираю статистику по таким задачам — сколько времени уходит на их решение, а потом прихожу и говорю, что рефакторинг займёт X часов и сэкономит Y часов на каждой фиче — вот список.
Надо понимать, что затраты на рефакторинг — это инвестиции, и бизнес должен чётко видеть ROI для него.
Вполне можно себе представить. Если человек себя зарекомендовал хорошо, работая программистом, и бизнес ожидает, что его навыки могут помочь, почему бы и нет. Это нормальный эксперимент и, кажется, риски совсем небольшие.
Ну, кто знает, что нас ждёт впереди… Мне например гораздо спокойнее, что за плечами есть опыт и навыки работы программистом и знание о том, что при желании я их восстановлю, придаёт уверенности ;)
Кстати, считаю, что «повышение в менеджеры» — некорректная фраза совершенно. По факту это — переход в параллельную область деятельности, где абсолютно другие метрики и рост. К сожалению, многие, действительно, воспринимают это как повышение. Вероятно, именно поэтому в отрасли так много плохих менеджеров, выросших из отличных программистов.
Может быть, не во всех компаниях так принято, но как минимум в Яндексе «лестница» для программиста ничуть не ниже, чем для менеджера.
Без проблем :)
«Растерял квалификацию» в моём случае — отстал от технологий. Пять лет вместо статей по технологиям читал ДеМарко, Листера и Брукса с постепенным переходом в «наивное управление продуктами» и «доморощенный маркетинг». За это время эти самые технологии где-то ушли далеко вперёд (фронтенд), а где-то просто выветрились из головы (C++, скажем).
По времени стало происходить практически сразу, так как был горячим приверженцем подхода «ПМ должен посвящать всего себя управлению проектом и не отвлекаться на код». Соответственно, практики за это врем не было совсем. Немного спасал курс по ООП, который в универе читал. Помогал поддерживать хоть какую-то форму.
Фактически, сейчас могу оценить качество спроектированной системы, качество кода, но сам код (скажем, на C++) писать уже не берусь. А то, что пишу, например, на питоне показывать никому тоже не хочу, так как стыдно — сам вижу, ЧТО получается в итоге :). С другой стороны уверен, что, если понадобится, то за полгода-год на позиции джуниора вполне реабилитируюсь. Мозги, вроде, не заржавели ;).
Так что, навыки они не обнуляются, но глубоко прячутся (пропорционально времени без практики). Это как с игрой на рояле после десяти лет перерыва — руки, вроде, «помнят», но многое надо снова вспоминать по нотам.
Слава, привет! Хороший пост про «встань и иди», но тема про обнуление навыков, по-моему, не раскрыта.
На собственном опыте — после перехода в ПМы, действительно, техническую квалификацию растерял и, чтобы её восстановить, приходится снова болезненно реабилитироваться. С другой стороны, общее чувство красивого кода, умение видеть и строить архитектуру систем и так далее, оно никуда не делось. Так что, обнуление, конечно, происходит, но восстановиться можно. Если, конечно, готов учиться заново.
В общем, можете считать официальным комментарием ;).
Для того, чтобы картинки индексировались, нужно, чтобы робот мог их скачать по http. При этом, очевидно, не нужно нарушать целостность https и класть на страницу картинки с незащищёнными http урлами. Ссылка на https картинку нормально обработается и сохранится у нас в базе. Когда придёт время, робот пойдёт качать картинку с этим же урлом, используя http протокол.
Добавили абзац в документацию. Спасибо за обратную связь ;)
На самом деле, любому разработчику следует время от времени на собеседования ходить. Чтобы понимать, что и где требуется и не застревать в «локальной компетентности» текущей компании. За одно — может чего полезного принесёт.
Но опять же, люди внезапно смертны. Поэтому в любом случае bus-factor надо делать хоть немного, но больше единицы.
Если при этих условиях Ася так и не узнала про свои перспективы, то либо их нет (и нормально, что она уходит туда, где они есть). Либо они есть. Но, прежде чем прийти с внешним оффером, Ася ни разу про них не спросила. И даже не обозначила, что ей всё надоело / она хочет чего-то большего. Вот как раз тут и возникает вопрос про необходимые качества, перечисленные в вашей цитате.
Но я совершенно согласен с тезисом, что иногда руководители, сами того не желая, прилагают гораздо больше усилий к тому, чтобы хороший сотрудник ушёл, чем сам сотрудник.
Опять же — много нюансов. Даже пломбировка зуба, например, в зависимости от «размера повреждения» может в страховку входить, а может и не входить.
Если продукт более-менее надолго, то тут проще — жёсткое ревью кода, почаще встречаться и обсуждать архитектуру, юнит-тесты, опять же. Короче, сделать систему, в которой писать плохо просто не получится. И, да, это сложно, неблагодарно и не всегда понятно, с какой стороны подходить.
— изменения в проекте становятся дорогими и долгими из-за низкого качества кода и архитектуры
— в ближайшее время планируется развитие продукта с добавлением новых фичей (у нормального живого продукта это состояние перманентно)
— как альтернатива предыдущему — команда проекта будет расширяться
А вот этот абзац серьёзно настораживает. Во-первых, мы не можем подготовить код к любым изменениям, поэтому такое положение дел совершенно нормально. С другой стороны, что значит «внесут изменения»? Придёт незнакомый человек в офис и испортит красивый код?
Если с командой всё в порядке, то такие изменения как минимум обсуждаются заранее. В том числе и с тем, кто делал рефакторинг. Уверяю вас, чтобы сделать кривой костыль в условиях, когда код обсуждается и регулярно проводится ревью, надо очень постараться. Особенно после того, как код приведён в относительный порядок.
А вот если даже небольшие правки ведут к костылям, то надо прежде всего настраивать коммуникацию и распределение ролей в команде, а делать рефакторинг в такой ситуации — действительно, пустая трата времени и денег заказчика. Это симптомы того, что у кода нет владельца (aka code owner) или он не справляется.
Без тестов грустно. Иногда помогает — вместо честных юнит-тестов автоматизировать хотя бы функциональные. По принципу — все контролы на месте, ничего не пропало. Инструмент не посоветую, но можно поспрашивать тестировщиков они должны знать. Ну и покрыть юнит-тестами для начала хотя бы «стыки» между компонентами. По опыту, самая большая засада — именно при интеграции.
По второму вопросу точно буду отдельно что-то писать. В двух словах — бизнес говорит на языке денег, поэтому разговаривать с ним надо на языке денег. Поддержка кода и внедрение стоят времени. Цель рефакторинга — сэкономить время на внедрение новых фич и избавиться от части багов (обычно попутно получается). Соответственно, я обычно некоторое время собираю статистику по таким задачам — сколько времени уходит на их решение, а потом прихожу и говорю, что рефакторинг займёт X часов и сэкономит Y часов на каждой фиче — вот список.
Надо понимать, что затраты на рефакторинг — это инвестиции, и бизнес должен чётко видеть ROI для него.
Может быть, не во всех компаниях так принято, но как минимум в Яндексе «лестница» для программиста ничуть не ниже, чем для менеджера.
«Растерял квалификацию» в моём случае — отстал от технологий. Пять лет вместо статей по технологиям читал ДеМарко, Листера и Брукса с постепенным переходом в «наивное управление продуктами» и «доморощенный маркетинг». За это время эти самые технологии где-то ушли далеко вперёд (фронтенд), а где-то просто выветрились из головы (C++, скажем).
По времени стало происходить практически сразу, так как был горячим приверженцем подхода «ПМ должен посвящать всего себя управлению проектом и не отвлекаться на код». Соответственно, практики за это врем не было совсем. Немного спасал курс по ООП, который в универе читал. Помогал поддерживать хоть какую-то форму.
Фактически, сейчас могу оценить качество спроектированной системы, качество кода, но сам код (скажем, на C++) писать уже не берусь. А то, что пишу, например, на питоне показывать никому тоже не хочу, так как стыдно — сам вижу, ЧТО получается в итоге :). С другой стороны уверен, что, если понадобится, то за полгода-год на позиции джуниора вполне реабилитируюсь. Мозги, вроде, не заржавели ;).
Так что, навыки они не обнуляются, но глубоко прячутся (пропорционально времени без практики). Это как с игрой на рояле после десяти лет перерыва — руки, вроде, «помнят», но многое надо снова вспоминать по нотам.
На собственном опыте — после перехода в ПМы, действительно, техническую квалификацию растерял и, чтобы её восстановить, приходится снова болезненно реабилитироваться. С другой стороны, общее чувство красивого кода, умение видеть и строить архитектуру систем и так далее, оно никуда не делось. Так что, обнуление, конечно, происходит, но восстановиться можно. Если, конечно, готов учиться заново.
Для того, чтобы картинки индексировались, нужно, чтобы робот мог их скачать по http. При этом, очевидно, не нужно нарушать целостность https и класть на страницу картинки с незащищёнными http урлами. Ссылка на https картинку нормально обработается и сохранится у нас в базе. Когда придёт время, робот пойдёт качать картинку с этим же урлом, используя http протокол.
Добавили абзац в документацию. Спасибо за обратную связь ;)