То, что умеешь не всегда совпадает с тем, что нравится делать.
Для руководителя главное — понять что разработчику нравится делать, а не что он умеет делать лучше всего. Иногда это совпадает, но это скорее исключение из правила.
Для разработчика главное — совершенствоваться в том, что нравится делать, а не в том, что получается делать эффективнее всего прямо сейчас.
Неочевидный вывод: цель тестового периода понять можно ли платить деньги сотруднику за то, что ему нравится, а не за то, что он умеет.
Для руководителя главное — понять что разработчику нравится делать, а не что он умеет делать лучше всего. Иногда это совпадает, но это скорее исключение из правила.
Для разработчика главное — совершенствоваться в том, что нравится делать, а не в том, что получается делать эффективнее всего прямо сейчас.
Неочевидный вывод: цель тестового периода понять можно ли платить деньги сотруднику за то, что ему нравится, а не за то, что он умеет.
За последние десять лет программирование, как отрасль, сделало качественный скачок. Теперь это не инструмент, который решает задачи. Теперь это ещё и способ поставить задачу.
Типичные задачи десять лет назад были о автоматизации, структурировании, бесперебойном процессе и оптимизации. Все эти интернет-магазины, соцсети, цэрмки не на йоту не выходили за пределы банального ручного решения задачи. Мол, можно и без компьютера на калькуляторе и в табличках.
Сейчас же компьютеры работают с задачами, которые принципиально даже не ставились лет десять назад. И да, беспилотные авто, генерация видео — это цветочки. Настоящий хардкор начинается тогда, когда результат работы программы неизвестен даже создателям. Можно отдать массив данных классификатору и увидеть связи, о которых люди даже не догадывались. Можно моделировать свертывание белка и находить новые органические связи. Можно доказывать теоремы, которые вообще непонятно даже в какую сторону начать досказывать.
Типичные задачи десять лет назад были о автоматизации, структурировании, бесперебойном процессе и оптимизации. Все эти интернет-магазины, соцсети, цэрмки не на йоту не выходили за пределы банального ручного решения задачи. Мол, можно и без компьютера на калькуляторе и в табличках.
Сейчас же компьютеры работают с задачами, которые принципиально даже не ставились лет десять назад. И да, беспилотные авто, генерация видео — это цветочки. Настоящий хардкор начинается тогда, когда результат работы программы неизвестен даже создателям. Можно отдать массив данных классификатору и увидеть связи, о которых люди даже не догадывались. Можно моделировать свертывание белка и находить новые органические связи. Можно доказывать теоремы, которые вообще непонятно даже в какую сторону начать досказывать.
Я не первый раз слышу, что в лихие девяностые программистам приходилось быть первопроходцами и решать задачи, которых принципиально не существовало, а сейчас, мол, всё уже придумано и остаётся только комбинировать существующие решения и заворачивать всё новые слои абстракции. Пиксели становятся меньше, процессоров больше и связь лучше, но это всё ещё те самые пиксели и процессоры.
В общем, ничего не меняется. Как сто лет назад всё было придумано до нас, так и сейчас тоже всё придумано до нас.
В общем, ничего не меняется. Как сто лет назад всё было придумано до нас, так и сейчас тоже всё придумано до нас.
Главное умение исполнителя — умение задавать вопрос «зачем» в ответ на декларативно поставленную задачу.
Худшее, что может сделать разработчик — сделать то, что его просят и не понимать зачем это нужно.
Худшее, что может сделать постановщик задачи — ответить «просто сделай и всё».
Худшее, что может сделать разработчик — сделать то, что его просят и не понимать зачем это нужно.
Худшее, что может сделать постановщик задачи — ответить «просто сделай и всё».
Писать идеальный код можно только одному или максимум вдвоём. Когда разработчиков много, код пишется без контроля одного сверхразума, который определяет что хорошо и что плохо и поэтому код можно сделать только «приемлемым», а не «идеальным». И важны тут две вещи: научиться жить с приемлемым, а не идеальным кодом и определять приемлемость кода без человеческого фактора.
Писать понятный код.
Рано или поздно любому разработчику приходится оценивать чужой код. Хорошие программисты могут интуитивно оценить код, но далеко не всегда аргументированно могут обьяснить почему. И вот тут начинаются определения, вроде «понятный», «интуитивный» или «хороший». Казалось, и хрен бы с ними, но вот такие программисты рано или поздно начинают проводить собеседования или насаждать решения в проекте. И вот тут начинается жопа. Остальные, менее опытные программисты начинают подстраиваться под субъективное качество кода, а собеседования проходят только те, кто смог подстроится под «можно лучше».
1. Всё, что можно превратить в строгие правила, нужно превращать. Паттерны, линтеры, покрытие тестами, числовые значения — подходит всё, что не зависит от субъективного мнения.
2. Любая дискуссия о качестве кода должна быть о нарушении правил или о расширении набора правил. «Вот так вот лучше» с куском кода в комментариях к пулл реквесту писать нельзя.
3. Любую задачу можно решить несколькими способами.
Рано или поздно любому разработчику приходится оценивать чужой код. Хорошие программисты могут интуитивно оценить код, но далеко не всегда аргументированно могут обьяснить почему. И вот тут начинаются определения, вроде «понятный», «интуитивный» или «хороший». Казалось, и хрен бы с ними, но вот такие программисты рано или поздно начинают проводить собеседования или насаждать решения в проекте. И вот тут начинается жопа. Остальные, менее опытные программисты начинают подстраиваться под субъективное качество кода, а собеседования проходят только те, кто смог подстроится под «можно лучше».
1. Всё, что можно превратить в строгие правила, нужно превращать. Паттерны, линтеры, покрытие тестами, числовые значения — подходит всё, что не зависит от субъективного мнения.
2. Любая дискуссия о качестве кода должна быть о нарушении правил или о расширении набора правил. «Вот так вот лучше» с куском кода в комментариях к пулл реквесту писать нельзя.
3. Любую задачу можно решить несколькими способами.
В эфире новая рубрика «Цитаты из худлита». Источник цитаты — книга, которую я читал, художественная литература. Название оставлять не буду, поиграем в игру такую, где нужно вспомнить произведение по цитате. Только чур не гуглить, а вспоминать из прочитанного. А если не читали, а захотелось, то наверняка найдёте ответ в чатике.
Итак, история о поврежденном мозге.
https://telegra.ph/Citata-o-povrezhdenii-mozga-12-22
Итак, история о поврежденном мозге.
https://telegra.ph/Citata-o-povrezhdenii-mozga-12-22
Telegraph
Цитата о повреждении мозга
Левое полушарие моего мозга оказалось отключенным – совсем как поврежденная секция спин-звездолета, которую перекрыли воздухонепроницаемыми переборками, отдав обреченные отсеки во власть пустоты. Способность мыслить я все же сохранил, вскоре восстановилась…
Давайте проведем аналогию системы званий и зарплат разработчиков с военным делом. «Джуны» — это те, кто уже прошел курс молодого бойца, отслужил в армии, умеет метко стрелять и, черт побери, знает какой кусок гранаты кидать во врага, а какой оставлять в руке. Получается те, кто только пришли в армию в неплохой физической форме, с двумя руками и без плоскостопия — еще не солдаты-джуны, а только хотят ими быть. И после пары боевых действий такого салагу перестают считать салагой и наконец он становится «джуниором». Такому бойцу можно доверить прикрывать спину и не беспокоится за качество выполнения поставленной задачи — задача будет выполнена настолько качественным образом, насколько это только вообще возможно. Да, патронов он потратит больше, да, время выполнения может быть слега увеличено.
В итоге, как бы банально это не прозвучало, но если вы не готовы пойти со своим коллегой в разведку, то он все еще находится за пределами градаций разработчиков.
#перечитываяэкстраполяцию
В итоге, как бы банально это не прозвучало, но если вы не готовы пойти со своим коллегой в разведку, то он все еще находится за пределами градаций разработчиков.
#перечитываяэкстраполяцию
Очень часто разрабочики забывают о том, что код программы пишется для людей, а не для компьютеров. Компьютер в состоянии выполнить код любой запутанности и сложности, а вот человеческий мозг нужно беречь и заботиться о нём. Почти всегда лучше пару раз нажать ctrl+c, ctrl+v и сделать код симметричным и декларативным, чем выписывать мапы и редьюсы с лямбдами.
Перефразируя Оккама:
Из двух одинаково работающих кусков кода лучше тот, который проще прочитать человеку.
Перефразируя Оккама:
Из двух одинаково работающих кусков кода лучше тот, который проще прочитать человеку.
Тупой начальник.
Для многих поводом устраиваться на работу есть конкретный начальник, у которого есть чему учиться. И наоборот, в процессе поиска сотрудников в команду менеджеры на собеседованиях задают вопросы, в которых они сами профессионалы. Например, когда собаку съел на алгоритмах поиска, рубиконом на собеседовании становится вопрос про красно-чёрного дерево.
И здесь контринтуитивно правильное поведение. Нанимать в команду к себе нужно тех, кто умеет делать то, что сам делать не умеешь или делаешь плохо. И наниматься нужно в ту команду, будешь знать в чём конкретно ты лучше всех.
Для многих поводом устраиваться на работу есть конкретный начальник, у которого есть чему учиться. И наоборот, в процессе поиска сотрудников в команду менеджеры на собеседованиях задают вопросы, в которых они сами профессионалы. Например, когда собаку съел на алгоритмах поиска, рубиконом на собеседовании становится вопрос про красно-чёрного дерево.
И здесь контринтуитивно правильное поведение. Нанимать в команду к себе нужно тех, кто умеет делать то, что сам делать не умеешь или делаешь плохо. И наниматься нужно в ту команду, будешь знать в чём конкретно ты лучше всех.
Касательно последнего поста, в чате появился очень правильный вопрос. Мол, как же в таком случае собеседовать человека, который как бы лучше тебя разбирается в том вопросе, в котором его надо собеседовать? Отметём очевидный способ приглашенного друга-эксперта и поговорим о небанальном.
Собеседуемому мало разбираться в своей профессии лучше остальных. Ему еще нужно доходчиво объяснять свою позицию и агрументированно объяснять свои решения. В итоге всё просто. Спрашивать нужно о какой-то насущной проблеме, где проблема есть и решение не выработанно. Попросить продумать решение, рассказать о плане реализации и дать оценку. В итоге за короткое собеседование оценивать нужно то, насколько собеседуемый поменял точку зрения интервьюера, насколько тот что-то такое новое понял, до чего до этого не догадался бы.
Само собой, этот способ не будет работать в тех областях, где интервьюер дупля не отстреливает. Например, бренд-маркетолог собеседовать сеньорного программиста на кубернетосах будет крайне неэффективно.
Собеседуемому мало разбираться в своей профессии лучше остальных. Ему еще нужно доходчиво объяснять свою позицию и агрументированно объяснять свои решения. В итоге всё просто. Спрашивать нужно о какой-то насущной проблеме, где проблема есть и решение не выработанно. Попросить продумать решение, рассказать о плане реализации и дать оценку. В итоге за короткое собеседование оценивать нужно то, насколько собеседуемый поменял точку зрения интервьюера, насколько тот что-то такое новое понял, до чего до этого не догадался бы.
Само собой, этот способ не будет работать в тех областях, где интервьюер дупля не отстреливает. Например, бренд-маркетолог собеседовать сеньорного программиста на кубернетосах будет крайне неэффективно.
Все побежали и я побежал.
Через тридцать минут мы будем в сами-знаете-в-чём осваивать разговорный жанр в рамках «Вечернего Лямбда Шоу». Назвали это «Lambda Talk Show #1» и я вообще понятия не имею как это название локализовать. Как оно пойдёт и попрёт ли я тоже не знаю, но надеюсь потом почитать ваши нетоксичные комментарии в чате.
https://joinclubhouse.com/event/MzE4E11R
Через тридцать минут мы будем в сами-знаете-в-чём осваивать разговорный жанр в рамках «Вечернего Лямбда Шоу». Назвали это «Lambda Talk Show #1» и я вообще понятия не имею как это название локализовать. Как оно пойдёт и попрёт ли я тоже не знаю, но надеюсь потом почитать ваши нетоксичные комментарии в чате.
https://joinclubhouse.com/event/MzE4E11R
В нашем чатике прислали сканы с книги 1940 года, где немного показана разработка самолетов того времени. Добавлять от себя ничего не буду, просто читайте и наслаждайтесь.
Не первый раз встречаю недоумение со стороны тех, кто задачи ставит (менеджеров там всяких или дизайнеров ещё каких), что, мол, «это же очевидно, зачем это расписывать» или «тут вот этой картинкой подразумевалось вот это, а не вон то».
Да, мыслью, что задачи и проблемы расписывать надо подробно и понятно, удивить тяжело, и особенно читетелей «Экстраполяции». Да, мы знаем, что фишка в том, что «понятно» и насколько подробно хочется видеть описание проблем — это просто субъективные термины. И вот вам лаконичное правило, которое можно показывать любому продакт-овнеру без дополнительных объяснений и эти самые продакт овнеры сами, без дополнительных мотиваций начинают всё объяснять достаточно подробно.
Это правило бутерброда. Если что-то в макетах или документации можно понять неправильно, то оно обязательно будет реализовано неправильно.
Да, мыслью, что задачи и проблемы расписывать надо подробно и понятно, удивить тяжело, и особенно читетелей «Экстраполяции». Да, мы знаем, что фишка в том, что «понятно» и насколько подробно хочется видеть описание проблем — это просто субъективные термины. И вот вам лаконичное правило, которое можно показывать любому продакт-овнеру без дополнительных объяснений и эти самые продакт овнеры сами, без дополнительных мотиваций начинают всё объяснять достаточно подробно.
Это правило бутерброда. Если что-то в макетах или документации можно понять неправильно, то оно обязательно будет реализовано неправильно.
Я тут прочитал охерительный критерий, как понять, легаси у тебя, или ещё нет.
Короче, вот ты чот поделал, запустил тесты, увидел зелёную линию и задаёшь себе вопрос — деплоить можно? Если «да, щас поставлю деплой и пойду спать» — ты ещё не в легаси. Если «а хер его знает» — добро пожаловать в клуб.
#dimoneverything
Короче, вот ты чот поделал, запустил тесты, увидел зелёную линию и задаёшь себе вопрос — деплоить можно? Если «да, щас поставлю деплой и пойду спать» — ты ещё не в легаси. Если «а хер его знает» — добро пожаловать в клуб.
#dimoneverything
Ребята, вакансия. Мне в команду нужен диджитал маркетолог. Колектив интересный, задачи дружные. Всё, как вы любите.
https://telegra.ph/Performance-Marketing-Lead-03-01
https://telegra.ph/Performance-Marketing-Lead-03-01
Задачи, о которых просят пользователи.
Существует небезосновательный миф о том, что делать нужно только те задачи, о которых прям умоляют пользователи, а те, о которых не просят, делать не надо. Это как бы и не миф вовсе, задачи действительно нужно делать только тогда, когда они будут полезны пользователям, но вот интерпретация пользовательских реквестов — это прям целое искусство.
Есть две крайности, ударяться в которые будет очень плохо.
Первая крайность бездумно потакает всем похотям пользователей, конечно предварительно группирует входящие запросы по подобию. А если в команде есть бизнес-аналитик, то ещё очень быстро появляется желание оценивать полезность реквестов и отсеивать их. Мол, «удовлетворим 20% вот этих желаний, получим 80% выгоды, а на остальные подзабьём» или ещё как-то так. Принципиально аналитики картины не меняют, хотя да, эффективность повышают.
Вторая крайность говорит, что нужно вообще забить на отдельные реквесты пользователей и даже не пытаться их записывать. Те штуки, которые действительно нужно делать, будут сниться в ночных кошмарах всем членам команды. Пользователи прям достанут, умоляя сделать ту или иную фичу. Когда-то такой подход декларировала компания «Basecamp» в своей книжке «Rework», кажется.
А фишка в том, что оба подхода принципиально не верны. К пользовательским запросам нужно относиться, как к капризам и просьбам ребёнка. Когда дети хотят конфету, это скорее значит, что им надо дать каши. Это в том смысле, что комбинация из понимания потребностей пользователей, причин, вызывающих эти потребности и того, как пользователи это интерпретируют, может дать очень хорошее видение будущих фич. Но никак не прямое исполнение декларируемых желаний.
#перечитываяэкстраполяцию
Существует небезосновательный миф о том, что делать нужно только те задачи, о которых прям умоляют пользователи, а те, о которых не просят, делать не надо. Это как бы и не миф вовсе, задачи действительно нужно делать только тогда, когда они будут полезны пользователям, но вот интерпретация пользовательских реквестов — это прям целое искусство.
Есть две крайности, ударяться в которые будет очень плохо.
Первая крайность бездумно потакает всем похотям пользователей, конечно предварительно группирует входящие запросы по подобию. А если в команде есть бизнес-аналитик, то ещё очень быстро появляется желание оценивать полезность реквестов и отсеивать их. Мол, «удовлетворим 20% вот этих желаний, получим 80% выгоды, а на остальные подзабьём» или ещё как-то так. Принципиально аналитики картины не меняют, хотя да, эффективность повышают.
Вторая крайность говорит, что нужно вообще забить на отдельные реквесты пользователей и даже не пытаться их записывать. Те штуки, которые действительно нужно делать, будут сниться в ночных кошмарах всем членам команды. Пользователи прям достанут, умоляя сделать ту или иную фичу. Когда-то такой подход декларировала компания «Basecamp» в своей книжке «Rework», кажется.
А фишка в том, что оба подхода принципиально не верны. К пользовательским запросам нужно относиться, как к капризам и просьбам ребёнка. Когда дети хотят конфету, это скорее значит, что им надо дать каши. Это в том смысле, что комбинация из понимания потребностей пользователей, причин, вызывающих эти потребности и того, как пользователи это интерпретируют, может дать очень хорошее видение будущих фич. Но никак не прямое исполнение декларируемых желаний.
#перечитываяэкстраполяцию
Природа уже настолько очистилась, что помимо маркетолога мы еще хотим усилиться руби разработчиком. Ищем уверенного мидла, в надежде доучить до восьмидесятого левела в процессе работы. Продукт, трэвел.
Третий руби, последний-распоследний рейлс, постгрес, реббит. Практически нет джаваскрипта, всё уверенно держится на серверном рендеринге. Сервисная архитектура, CI/CD, тестов могло быть и по-больше.
Резюме шлите мне в директ (@aratak).
И да, если вдруг вам не надо, то наверняка будет интересно соседу. Репосты и шаринги не только вакансий, а и других постов «Экстраполяции» мотивируют меня писать больше. Спасибо.
#экстравакансия
Третий руби, последний-распоследний рейлс, постгрес, реббит. Практически нет джаваскрипта, всё уверенно держится на серверном рендеринге. Сервисная архитектура, CI/CD, тестов могло быть и по-больше.
Резюме шлите мне в директ (@aratak).
И да, если вдруг вам не надо, то наверняка будет интересно соседу. Репосты и шаринги не только вакансий, а и других постов «Экстраполяции» мотивируют меня писать больше. Спасибо.
#экстравакансия