Насколько я понимаю оригинальный текст — речь именно про одну компанию. Более того, чуть ли не один отдел. И в рамках одной компании игнорить код на ревью — ну, скажем мягко, неэффективно. Конечно, это должно входить в KPI, метрики, да куда угодно. Код на ревью — в том числе твой код, твоя ответственность. Понятно, что бывают ситуации, завалы-авралы, но в общем и целом, моя позиция именно такая — код написан и отдан на ревью. Горячий шарик ответственности перешел из твоих рук в руки ревьювера. Если код лежит без движения и сроки затягиваются — ответственен в этом именно ревьювер. По-дружески можно подойти потыкать, но это не обязанность.
Меня при чтении удивил момент, что code review — практически добровольный труд ответственного. Хочу проверяю, не хочу не проверяю. Особенно, если не пилит автор кода.
Мне кажется, что это само по себе нездоровая постановка вопроса, когда программист должен бегать и убеждать, что его код нужно пропихнуть в бой. Как по мне, эта административная вещь должна решаться автоматически. Пришел код на ревью — загорелась зеленая лампочка.
Пролежал рабочий день без рассмотрения — красная. На второй день лампочка загорается у руководителя ревьювера. На третий — у руководителя руководителя.
Заголовок спойлера
Вообще, в сферу ответственности программиста пытаются впихнуть как-то слишком много. Архитектура, гайдлайны, качество кода, оптимальность, скажем понятны. Потом туда добавляется расшифровка бизнес-процессов а вместе с ним генерирование бизнес-логики. Т.е. бизнес проблему еще не осознал до конца, а уже требует ее качественное решение. ОК. Потом сюда же добавляются навыки руководителя и проектного мышления. Оценка и контроль времени и рисков. Стратегическое мышление и планирование. И естественно, параллельно самостоятельно профессионально расти вширь и ввысь.
Зачем такому сотруднику компания? А еще точнее, что его заставляет продолжать работать программистом, кроме любви к работе с кодом. Он исполняет роль полноценного руководителя средней степени крупности, но при этом без формальных полномочий. Мне не кажется, что обычно программист горит желанием заниматься всеми этими дополнительными вещами и с удовольствием продолжал бы «платить» компании и своему начальнику за то, чтобы просто хорошо решать нормально поставленные задачи без лишнего погружения в бизнес, коммуникации и прочее.
Вот есть ощущение, что переинженерили. Уж очень сложно, дорого, тяжело и беда с обслуживанием.
Условный надувной пластмассовый круг с двигателем и радио от макета выглядит привлекательнее. При на порядок-два меньшей цене их можно располагать на пляжах, набережных и мостах чаще, при этом предполагая управление случайными свидетелями.
Заметил тонущего — сорвал этот круг и как уж умеешь, направил к нему. Дальше прибывает спасатель и вытаскивает человека. Винт из пластика, чтобы не покалечил.
А можно еще вопрос. Вы писали, что у вас не идеальный английский. Приходилось ли себя перебарывать, что вы возможно говорите и пишете с ошибками и все это заметили? Как вообще ваши взаимоотношения с английским с момента переезда?
А можете поделиться, как удалось совмещать столь активные поиски с текущей работой в России? Для меня каждое собеседование — стресс, на английском вдвойне. Море времени на подготовку, как-то расчистить рабочее время на само интервью, тестовые задания. В вашем случае еще и перелеты. Ну и при таких объемах собеседований, мне кажется, текущий начальник не мог не догадываться, особенно при разговорах на английском в офисе.
Ну и не могу не поздравить, как минимум, интересный опыт вам обеспечен.
Как я вижу смысл — получить некий аналог курса доллара как такового. Т.е. из бесконечного шума изменения валютных пар вычленить динамику каждой конкретной валюты к некоему абсолюту. Сейчас обыватель может отдельно получить динамику курса какой-либо валюты к доллару, часто воспринимаемому как абсолют + динамику индекса доллара, который тоже не идеален. Благодаря этому посчитанному абсолюту можно оторвать интересующую валюту от эффектов самого доллара и получить ее чистую динамику. Т.е. не делать оговорку «вот здесь курс был низкий, но вы же помните, как тогда взлетел доллар ко всем валютам». Что дальше делать с этой информацией — загадка. Оценивать активы, пассивы, эффект от инвестиций в чем-то кристаллизованном, например.
Я только спросить:)
Думаю, у многих вопросы к научности медицины возникают из-за
1) неоднозначности в постановке диагноза
2) неоднозначности в способе лечения одного и того же человека с одним и тем же диагнозом, но разными врачами
3) заговорщицкого умалчивания деталей.
Т.е. делаешь анализ — Helicobacter pylori зашкаливает. Эндоскопист однозначно посылает к гастроэнтерологу дальше для определения схемы приема антибиотиков. Приходишь к гастроэнтерологу — получаешь вялое молчание и сопутствующее лечение, желудок он считает ОК. Переспрашиваешь — с ленцой и раздражением отвечает, что тут ничего страшного, выводить бактерию не надо и это вообще просто мода такая, от нее никто не умирает.
И у пациента реально остается ощущение, что эти два врача просто из разных орденов. Т.е. ни один из них не ссылается на общепринятый протокол, который стоит применять в твоем случае. Это не бесплатная медицина, т.ч. на ограничение по времени на пациента и прочее не сошлешься.
Насколько я понял, замена как раз таки бесплатно, входит в подписку.
Насчет того, лучше ли покупка аренды — вопрос открытый. Точно знаю, что у начинающих и никому не известных есть проблема завалов работ. Вроде и все неплохие, выкинуть точно жалко, как и продать по стоимости материалов. Но и не берет никто за чуть более приличные деньги. А так — отличный вариант хотя бы мастерскую разгрести. Плюс постоянный источник мелких денег может быть лучше, чем редкие более хорошие деньги. Плюс какая-никакая бесплатная реклама имени.
Но тут правда нужен или лизинг (допустим, после года-двух аренды можно забрать 1 работу), или возможность льготного выкупа.
Не думаю, что эти работы всерьез будут дорожать со временем. Мы говорим скорее о fast art, как появилось, так и ушло в никуда.
Too big to be just an aggregator. Яндекс как-то внезапно для себя разом начал расхлебывать все отрицательные стороны своих огромных маленьких сторонних проектов. Что с едой, что с такси, бизнес-модель «а давайте дадим проекту свои имя, деньги и вычислительную платформу, а человеков возьмем у ближайшего рабовладельца» внезапно начала вредить всему зонтичному бренду. Самая жесть начнется, если когда они еще и весь накал госрегулирования разом ощутят.
Ну, как минимум, можно менять картину раз в месяц забесплатно:)
Можно поддержать молодых художников, но не отдать ползарплаты.
Захотел в отпуск — повесил море, устал от жары — снежный пейзаж. Портрет в стиле ню. Штурвал. Розы. Тигров. И все за один год и по подписке. Съехал — не перевозишь хлам в другой город.
Из предложений, до кучи еще напрашивается сорт оф лизинг, ну или как минимум возможность купить особенно понравившийся предмет.
Идея — крутая! Искренне желаю вам успеха. Просто бизнес по схеме win-win, когда все в выигрыше. И авторы массового искусства, и пользователи сервиса. Надеюсь, наладите сотрудничество с молодыми художниками и застройщиками, чтобы поставить дело на поток.
Спасибо за ответ по содержанию.
По-моему, совсем немного недоработали, чтобы добить задачу и сделать более универсальное решение.
Ваш вариант заточен на прогноз одного дня, в случае, если захотите прогнозировать даже завтра+послезавтра модель придется перестраивать основательно.
В таком случае, топ критериев вполне интерпретируем.
Во-первых, модель вполне разумно говорит, что продажи завтра очень похожи на вчера. Это логично, так она избавляется от влияния годовой сезонности и изменения ассортимента, в некотором смысле восстанавливает тренд.
Во-вторых, модель строит коэффициент продажи в (день_недели_завтра / день_недели_вчера), вернее 7 таких коэффициентов. Во сколько раз продажи в среду выше таковых в понедельник, во сколько четверг выше вторника и т.д. Так она восстанавливает недельную сезонность.
На самом деле, здесь уже сделано 95% работы, остается обработать исключительные ситуации.
В третьих, учесть цену. В идеале, было бы подавать на вход скидку а не цену, результаты бы чуть улучшились.
Ну и в-четвертых — праздники как еще неописанные всплески спроса. Их Ваша модель скорее всего видит через те самые дни до праздника.
В принципе, можно было бы построить регрессию по данным с аккуратно заведенными фичами и получить аналитическую функцию прогноза, но Ваш вариант, особенно для пилота, вполне жизнеспособен. Было бы еще интересно проверить, нет ли подозрительных выбросов переобучения, приводящих к тому, что например при повышении цены в каком-то диапазоне растет спрос.
При всех шероховатостях, вы все равно молодцы, что пытаетесь идти по трудному пути!
1. Пилотом обычно называют все же тестовое внедрение, а у Вас я из текста так и не понял, пошел ли Ваш прогноз в заказ. Это очень важно, тк моментально дает Вам кучу фидбека, гордости за себя и тикетов для работы ;)
2. Не указан горизонт и уровень прогнозирования, а это очень важно, для понимания цифр. Одно дело, прогнозировать ближайшую неделю и суммарно товарную группу, другое — один товар на пару месяцев вперед.
3. Касаемо фичи «продажи в день прогноза», если прогноз на будущее. Обычно делают каскад фич: продажи предыдущего дня, продажи предыдущего того же дня недели (пн к пн и т.д.), месяца, года. Не уверен, что здесь это сработает, но все же. И тогда прогноз на много дней надо запускать итеративно, на дальнейших днях либо подменяя факт прогнозом, либо используя модель без фичи.
4. Не очень понятно, подавали ли флаги дней недели в RF. Банально, логарифмировали ли целевую переменную. Дни недели должны быть в топе!
5. Такое чувство, что фичу «дней до Курбан-байрам» RF просто использовал как некий идентификатор дня или восходящий тренд.
С тз индикативности, хотелось бы увидеть прогноз по каким-нибудь шоколадкам, кофе или бытовой химии. Они куда лучше должны показать качество модели, чем спокойное 45 недель в году куриное яйцо.
А это точно 4-дневка?
Как по мне, это в лучшем случае легализованные полдня отгула в неделю. Или 2 дня отгула в месяц, которые во многих компаниях есть и так.
Может быть, я неправильно понимаю пункт про работу в нерабочий день, но как по мне, что сидеть готовым к письму/звонку, что сидеть в офисе — примерно одинаковое удовольствие. Даже в чем-то более противное. Т.е. формально — иди, гуляй, походы, музеи, спорт, пикник, дети. Но при этом, пожалуйста, постоянно будь на связи и будь готов в разумные сроки отреагировать на входящий звонок/письмо. Это не просто офисная тюрьма, где хоть прокрастинировать разрешают, а тюрьма со стеклянными стенами. Вроде и вот она воля, а выйти нельзя.
Да, в парадигме, когда работа в радость и есть неотвратимое желание ей заниматься, может быть оно и не так.
Агрессивное создание и захват рынка в надежде заработать позже, на много большем обороте. Ну или банальная пирамида для инвесторов, это как посмотреть.
Собственно, автор намекает на второе, если я правильно его понял. Для чего он это делает? Не известно. Может дружит с конкурентом, может альтруист-правдоруб.
Я до последнего ждал рекламы очередного BI Tableau etc.
Реальных проблем в этой ситуации несколько, по-моему.
Руководитель не знает, какие данные ему нужны, чтобы руководить. До определенной степени это даже нормально, если бы он не делал крайним в этой ситуации программиста. Заковыка в том, что если он точно знает, какие данные ему нужны, то и знает список ситуаций, которые он в них ищет. А значит это автоматизируемая работа, достаточно объяснить, в каких случаях присылать большое красное письмо «здесь неОК», письмо «здесь все ОК» не то чтобы необходимо.
Но руководитель правильно в общем-то боится пропустить нестандартную ошибку/проблему. И в общем-то понятно, что он не знает, как искать что-то нестандартное. Но при чем здесь программист все равно непонятно.
Визуализация данных — это отдельная область работы, понятно, что у большинства системных/бэкэнд программистов в ней пробел. Это и про сторителинг, и про композицию, и про управление вниманием. Сильно не факт, что это должно сочетаться в одном человеке.
Меня просто зацепила строчка с противопоставлением облака — необходимость в инженере «У нас в Skyeng сейчас 30+ аналитиков-фулстеков и пока нет ни одного дата-инженера… потому что вся наша инфраструктура данных построена на облачных сервисах»
Не суть. Видимо, неправильно вас понял.
Если честно, не понял ваш тезис о том, что вам не нужен дата-инженер, потому что все ваши данные в облаках. Либо у вас есть много разнородных данных и/или аналитики над ними, и вам нужен человек, который будет разгружать специалистов в этом плане, либо у вас немного данных и/или аналитики, и специалист вам не нужен. Также специалисты по работе с данными могут справляться без помощника, но это заставляет страдать либо их, либо ваши бюджеты :). По крайней мере, мне так кажется.
Мне кажется, что это само по себе нездоровая постановка вопроса, когда программист должен бегать и убеждать, что его код нужно пропихнуть в бой. Как по мне, эта административная вещь должна решаться автоматически. Пришел код на ревью — загорелась зеленая лампочка.
Пролежал рабочий день без рассмотрения — красная. На второй день лампочка загорается у руководителя ревьювера. На третий — у руководителя руководителя.
Зачем такому сотруднику компания? А еще точнее, что его заставляет продолжать работать программистом, кроме любви к работе с кодом. Он исполняет роль полноценного руководителя средней степени крупности, но при этом без формальных полномочий. Мне не кажется, что обычно программист горит желанием заниматься всеми этими дополнительными вещами и с удовольствием продолжал бы «платить» компании и своему начальнику за то, чтобы просто хорошо решать нормально поставленные задачи без лишнего погружения в бизнес, коммуникации и прочее.
Условный надувной пластмассовый круг с двигателем и радио от макета выглядит привлекательнее. При на порядок-два меньшей цене их можно располагать на пляжах, набережных и мостах чаще, при этом предполагая управление случайными свидетелями.
Заметил тонущего — сорвал этот круг и как уж умеешь, направил к нему. Дальше прибывает спасатель и вытаскивает человека. Винт из пластика, чтобы не покалечил.
и все это заметили? Как вообще ваши взаимоотношения с английским с момента переезда?Ну и не могу не поздравить, как минимум, интересный опыт вам обеспечен.
Думаю, у многих вопросы к научности медицины возникают из-за
1) неоднозначности в постановке диагноза
2) неоднозначности в способе лечения одного и того же человека с одним и тем же диагнозом, но разными врачами
3) заговорщицкого умалчивания деталей.
Т.е. делаешь анализ — Helicobacter pylori зашкаливает. Эндоскопист однозначно посылает к гастроэнтерологу дальше для определения схемы приема антибиотиков. Приходишь к гастроэнтерологу — получаешь вялое молчание и сопутствующее лечение, желудок он считает ОК. Переспрашиваешь — с ленцой и раздражением отвечает, что тут ничего страшного, выводить бактерию не надо и это вообще просто мода такая, от нее никто не умирает.
И у пациента реально остается ощущение, что эти два врача просто из разных орденов. Т.е. ни один из них не ссылается на общепринятый протокол, который стоит применять в твоем случае. Это не бесплатная медицина, т.ч. на ограничение по времени на пациента и прочее не сошлешься.
Насчет того, лучше ли покупка аренды — вопрос открытый. Точно знаю, что у начинающих и никому не известных есть проблема завалов работ. Вроде и все неплохие, выкинуть точно жалко, как и продать по стоимости материалов. Но и не берет никто за чуть более приличные деньги. А так — отличный вариант хотя бы мастерскую разгрести. Плюс постоянный источник мелких денег может быть лучше, чем редкие более хорошие деньги. Плюс какая-никакая бесплатная реклама имени.
Но тут правда нужен или лизинг (допустим, после года-двух аренды можно забрать 1 работу), или возможность льготного выкупа.
Не думаю, что эти работы всерьез будут дорожать со временем. Мы говорим скорее о fast art, как появилось, так и ушло в никуда.
Можно поддержать молодых художников, но не отдать ползарплаты.
Захотел в отпуск — повесил море, устал от жары — снежный пейзаж. Портрет в стиле ню. Штурвал. Розы. Тигров. И все за один год и по подписке. Съехал — не перевозишь хлам в другой город.
Из предложений, до кучи еще напрашивается сорт оф лизинг, ну или как минимум возможность купить особенно понравившийся предмет.
По-моему, совсем немного недоработали, чтобы добить задачу и сделать более универсальное решение.
Ваш вариант заточен на прогноз одного дня, в случае, если захотите прогнозировать даже завтра+послезавтра модель придется перестраивать основательно.
В таком случае, топ критериев вполне интерпретируем.
Во-первых, модель вполне разумно говорит, что продажи завтра очень похожи на вчера. Это логично, так она избавляется от влияния годовой сезонности и изменения ассортимента, в некотором смысле восстанавливает тренд.
Во-вторых, модель строит коэффициент продажи в (день_недели_завтра / день_недели_вчера), вернее 7 таких коэффициентов. Во сколько раз продажи в среду выше таковых в понедельник, во сколько четверг выше вторника и т.д. Так она восстанавливает недельную сезонность.
На самом деле, здесь уже сделано 95% работы, остается обработать исключительные ситуации.
В третьих, учесть цену. В идеале, было бы подавать на вход скидку а не цену, результаты бы чуть улучшились.
Ну и в-четвертых — праздники как еще неописанные всплески спроса. Их Ваша модель скорее всего видит через те самые дни до праздника.
В принципе, можно было бы построить регрессию по данным с аккуратно заведенными фичами и получить аналитическую функцию прогноза, но Ваш вариант, особенно для пилота, вполне жизнеспособен. Было бы еще интересно проверить, нет ли подозрительных выбросов переобучения, приводящих к тому, что например при повышении цены в каком-то диапазоне растет спрос.
1. Пилотом обычно называют все же тестовое внедрение, а у Вас я из текста так и не понял, пошел ли Ваш прогноз в заказ. Это очень важно, тк моментально дает Вам кучу фидбека, гордости за себя и тикетов для работы ;)
2. Не указан горизонт и уровень прогнозирования, а это очень важно, для понимания цифр. Одно дело, прогнозировать ближайшую неделю и суммарно товарную группу, другое — один товар на пару месяцев вперед.
3. Касаемо фичи «продажи в день прогноза», если прогноз на будущее. Обычно делают каскад фич: продажи предыдущего дня, продажи предыдущего того же дня недели (пн к пн и т.д.), месяца, года. Не уверен, что здесь это сработает, но все же. И тогда прогноз на много дней надо запускать итеративно, на дальнейших днях либо подменяя факт прогнозом, либо используя модель без фичи.
4. Не очень понятно, подавали ли флаги дней недели в RF. Банально, логарифмировали ли целевую переменную. Дни недели должны быть в топе!
5. Такое чувство, что фичу «дней до Курбан-байрам» RF просто использовал как некий идентификатор дня или восходящий тренд.
С тз индикативности, хотелось бы увидеть прогноз по каким-нибудь шоколадкам, кофе или бытовой химии. Они куда лучше должны показать качество модели, чем спокойное 45 недель в году куриное яйцо.
Как по мне, это в лучшем случае легализованные полдня отгула в неделю. Или 2 дня отгула в месяц, которые во многих компаниях есть и так.
Может быть, я неправильно понимаю пункт про работу в нерабочий день, но как по мне, что сидеть готовым к письму/звонку, что сидеть в офисе — примерно одинаковое удовольствие. Даже в чем-то более противное. Т.е. формально — иди, гуляй, походы, музеи, спорт, пикник, дети. Но при этом, пожалуйста, постоянно будь на связи и будь готов в разумные сроки отреагировать на входящий звонок/письмо. Это не просто офисная тюрьма, где хоть прокрастинировать разрешают, а тюрьма со стеклянными стенами. Вроде и вот она воля, а выйти нельзя.
Да, в парадигме, когда работа в радость и есть неотвратимое желание ей заниматься, может быть оно и не так.
Собственно, автор намекает на второе, если я правильно его понял. Для чего он это делает? Не известно. Может дружит с конкурентом, может альтруист-правдоруб.
Реальных проблем в этой ситуации несколько, по-моему.
Руководитель не знает, какие данные ему нужны, чтобы руководить. До определенной степени это даже нормально, если бы он не делал крайним в этой ситуации программиста. Заковыка в том, что если он точно знает, какие данные ему нужны, то и знает список ситуаций, которые он в них ищет. А значит это автоматизируемая работа, достаточно объяснить, в каких случаях присылать большое красное письмо «здесь неОК», письмо «здесь все ОК» не то чтобы необходимо.
Но руководитель правильно в общем-то боится пропустить нестандартную ошибку/проблему. И в общем-то понятно, что он не знает, как искать что-то нестандартное. Но при чем здесь программист все равно непонятно.
Визуализация данных — это отдельная область работы, понятно, что у большинства системных/бэкэнд программистов в ней пробел. Это и про сторителинг, и про композицию, и про управление вниманием. Сильно не факт, что это должно сочетаться в одном человеке.
«У нас в Skyeng сейчас 30+ аналитиков-фулстеков и пока нет ни одного дата-инженера… потому что вся наша инфраструктура данных построена на облачных сервисах»
Не суть. Видимо, неправильно вас понял.