И раз уж примеры пошли - то я в своей жизни чаще видел наоборот крупные и долгоживущие бизнесы, в которых какая-то кривая хрень годами работает непойми как, но деньги приносит (вроде) и ее ни выкинуть ни переделать не дают. В поддержку вкладываются по минимуму. Развитие может быть и вовсе заблочено, потому что дорого и стремно.
Понятно, что если ты стартап и себя прокачиваешь только ради последующей продажи - то вкладываться сильно в инженерное качество странно. Но мир не из одних стартапов состоит.
Документация сама по себе конечно же прибыль не генерит. Но работа над ней способствует приведению мыслей в порядок, и это уже в свою очередь помогает избежать потерь. Сколько именно в %%, посчитать действительно сложно. Но при «продажах» новых идей есть точно такая же трудность, как посчитать, и там как-то получается
Я тоже часто такой довод слышу. "Судя по нашему финансовому результату, все отлично, не нойте и идите работайте".
Но во-первых разве (ваш) номинальный финансовый результат показывает упущенные возможности? Да, заработала компания в этом году 100 рублей, и это круто, потому что год-к-году прирост составил скажем 10%, а в сегодняшних условиях в конкретной нише это вообще космос - но разве из этого следует, что нельзя было сделать 120 рублей, действуя иначе (двигаясь более осознанно)?
А во-вторых, и это самое главное - а откуда уверенность, что сегодняшний пусть даже позитивный фин.рез получен не "в долг у самих себя", и завтра из-за сегодняшних поспешных решений вы не начнете терять?
В моем понимании такие вещи как аккуратность, вдумчивость, осознанность должны быть в балансе со скоростью, интенсивностью и мощностью. В статье же говорится о том, что есть нарушение этого баланса, и это проблема.
В том же популярном сегодня эджайле в манифестах говорится что "работающий продукт важнее исчерпывающей документации" и это верно. Но обратите внимание на слово "исчерпывающей", оно важно - речь не о том, чтобы не было вообще никакой документаци.
Вообще не согласен. "Мой опыт (интуиция) подсказывает что вот тут надо делать вот так" - вполне достаточное логическое обоснование. И если в основе решения именно такой довод, то указать это в документации необходимо, иначе потом придется вспоминать и догадываться. Никогда ничего не надо стесняться.
И "тривиальные очевидные вещи" для эксперта могут быть крайне ценны, полезны и очень неочевидны для массы других людей.
Не нужны в хранилищах update/delete по таблицам фактов - проектируйте их сразу как append-only и горя мутаций не познаете. Да и не только в кликхаусе так стоит делать.
О, да! Такое чувство что эту статью написал я сам о своей ситуации )))
Самое неприятное, что «продать» руководству мысль о необходимости исправления ситуации у меня категорически не получается. Думаю, все понимают что это очень долгая песня, результата можно и не дождаться в своей должности, нужны более «низко висящие фрукты». А тут еще и измерить эффект затруднительно. В общем, надо быть сильно уверенным в себе стратегом, чтобы в подобное инвестировать.
Очень грустно, что у нас как класс отсутствует нормальное загородное жилье. По какому фактору ни возьми, везде получишь страшную неоднородность. А если все хотя бы просто нормально, то "неоднородность" будет в цене таког объекта.
И то, что мыслящие энергичные девелоперы в поисках своей целевой аудитории вынужденно идут в сторону повышения класса своих объектов (порой даже надуманно), тоже очень показательно.
Можно проще сказать: у всех управленческих решений есть различные последствия на различных сроках, и сила хорошего руководителя в том, чтобы держать баланс между сделать как будет лучше прямо сейчас и сделать как будет лучше потом. Многие к сожалению перегибают в сторону первого.
А критическое мышление ваше вполне можно сделать внешней функцией - найти в коллективе человека, который на себя эту роль возьмёт, и к нему прислушиваться.
Звучит как обвинение в несправедливости. Но если включить немного объективности, то окажется, что затраты компании и кандидата на собесе сопоставимы. Надо просто учесть цену часа кандидата и совокупные цены часов тех людей, которые с ним со стороны компании дело имеют.
Да уж, автор позорник. Таких точек помимо полюса есть еще бесконечно много расположенный на удалении от второго полюса на 1+2пи/к вроде так. В ощем смысл в том что 1км на запад можно ходить по кругу один или более раз.
И кстати, мне эту задачу задавали на собесе в 2004 году, когда ещё Илон Маск сам наверное джуном был. Одним словом, это явно не его задача а кого-то постарше )
Всё это конечно прекрасно, но я вот уже в который раз сталкиваюсь с тем, что в коллективах, много лет номинально живущих по эджайлу, не выполнены пре-реквизиты: не определены стейкхолдеры, спонсоры, не закреплены границы продуктов. Отдельная проблема в том, что бизнес может быть большим, и для эффективной работы ему нужна какая-то базовая "архитектура" самой компании и межведомственного взаимодействия, которая сама по себе снизу-вверх не рождается.
В итоге "гладко было на бумаге, но забыли про овраги".
Не раскрыта тема применимости данного метода (и вообще любых джойнов в потоке) при условии несовпадения моментов появления данных в СИ. Понятно, что у флинка есть некое "окно", и он в памяти держит сколько-то недавно прочитанных записей - но во-первых, неплохо бы описать настройки этого "окна", а во-вторых как быть если его не хватило? - искать эти "не совпавшие по времени прилета" записи уже в СП? - окей, так можно, но для чего тогда вообще весь этот огород с флинком?
Бизнес никогда - нет, НИКОГДА!!! - не даст ресурсов чтобы уже работающее и приносящее профит переделать "как следует". Даже могу рассказать почему так, но это отдельно. Поэтому у технаря есть толька два варианта - либо сразу заложить запас на развитие в своей конструкции либо переделывать уже работающее тихо незаметно в свободное время. А если бизнес отличается "плодовитостью" на гипотезы и эмвипишечки, то технарь обязан быть провидцем и понимать, что из этого перспективно, а что заведомо чушь - и штуки стоящие делать с запасом прочности, а ерунду делать так, чтобы потом как можно дешевле было ее выкинуть.
Есть две реальности. Первая - идеальный мир специалиста: заказчик знает что ему нужно и может это выразить письменно, понятен срок и критерии приемки, есть достаточно ресурса и компетенций для выполнения. Вторая реальность - идеальный мир заказчика (бизнеса): ничего не понятно и нет способа разобраться кроме как попробовать и оценить результат (что еще тоже надо придумать как делать), надо бежать одновременно в разные стороны, проверять по N гипотез в месяц, уметь запускать АВ-тесты десятками, внедряться в пром за 15 минут и отчетность видеть в реальном времени.
Кажется, что совместить невозможно, но в этом и есть "магия айти". Для меня лично основная проблема в том, что хотелки бизнеса растут со скоростью, превышающей рост возможностей ит-команд, нарастает разрыв между ожиданиями и реальностью. А людей, которые этот разрыв должны контролировать, заполнять и удерживать приемлемым (это архитекторы, сильные синьоры и ит-менеджмент), нету в достаточном количестве и качестве. Поэтому часто происходит потеря контроля над ситуцией и бизнес улетает в космос и далее все по худшему сценарию вашей статьи.
В 99% случаев упускается главное - ЗАЧЕМ инженеру работать БЫСТРЕЕ своего собственного внутреннего уровня нормы? К потере удовольствия от работы и к выгоранию это приведет непременно, а денег дополнительных сильно много не принесет. Да и бизнес во многих компаниях спешит не потому что это реально необходимо, а потому что конкретным менеджерам так хочется по каким-то личным причинам.
Соглашусь, что умеренный напряг в планах (на 20-30% от "нормы") это ок, но напряг вдвое-втрое опытного работника (который сразу это видит и понимает, что сделать никак не получится) только демотивирует окончательно.
Есть пределы у этой формулы - конкретный разработчик даже если будет очень хорошо замотивирован (финасово и не только) имеет небесконечную производительность. Желания менеджеров же могут запросто быть нереальными.
Посчитать трудно, да.
И раз уж примеры пошли - то я в своей жизни чаще видел наоборот крупные и долгоживущие бизнесы, в которых какая-то кривая хрень годами работает непойми как, но деньги приносит (вроде) и ее ни выкинуть ни переделать не дают. В поддержку вкладываются по минимуму. Развитие может быть и вовсе заблочено, потому что дорого и стремно.
Понятно, что если ты стартап и себя прокачиваешь только ради последующей продажи - то вкладываться сильно в инженерное качество странно. Но мир не из одних стартапов состоит.
Про replacing движки примеры бы не помешали. Ну и про final рассказать и про optimize и про, как этим всем рекомендовано пользоваться.
Документация сама по себе конечно же прибыль не генерит. Но работа над ней способствует приведению мыслей в порядок, и это уже в свою очередь помогает избежать потерь. Сколько именно в %%, посчитать действительно сложно. Но при «продажах» новых идей есть точно такая же трудность, как посчитать, и там как-то получается
Я тоже часто такой довод слышу. "Судя по нашему финансовому результату, все отлично, не нойте и идите работайте".
Но во-первых разве (ваш) номинальный финансовый результат показывает упущенные возможности? Да, заработала компания в этом году 100 рублей, и это круто, потому что год-к-году прирост составил скажем 10%, а в сегодняшних условиях в конкретной нише это вообще космос - но разве из этого следует, что нельзя было сделать 120 рублей, действуя иначе (двигаясь более осознанно)?
А во-вторых, и это самое главное - а откуда уверенность, что сегодняшний пусть даже позитивный фин.рез получен не "в долг у самих себя", и завтра из-за сегодняшних поспешных решений вы не начнете терять?
В моем понимании такие вещи как аккуратность, вдумчивость, осознанность должны быть в балансе со скоростью, интенсивностью и мощностью. В статье же говорится о том, что есть нарушение этого баланса, и это проблема.
В том же популярном сегодня эджайле в манифестах говорится что "работающий продукт важнее исчерпывающей документации" и это верно. Но обратите внимание на слово "исчерпывающей", оно важно - речь не о том, чтобы не было вообще никакой документаци.
Вообще не согласен. "Мой опыт (интуиция) подсказывает что вот тут надо делать вот так" - вполне достаточное логическое обоснование. И если в основе решения именно такой довод, то указать это в документации необходимо, иначе потом придется вспоминать и догадываться. Никогда ничего не надо стесняться.
И "тривиальные очевидные вещи" для эксперта могут быть крайне ценны, полезны и очень неочевидны для массы других людей.
Не нужны в хранилищах update/delete по таблицам фактов - проектируйте их сразу как append-only и горя мутаций не познаете. Да и не только в кликхаусе так стоит делать.
О, да! Такое чувство что эту статью написал я сам о своей ситуации )))
Самое неприятное, что «продать» руководству мысль о необходимости исправления ситуации у меня категорически не получается. Думаю, все понимают что это очень долгая песня, результата можно и не дождаться в своей должности, нужны более «низко висящие фрукты». А тут еще и измерить эффект затруднительно. В общем, надо быть сильно уверенным в себе стратегом, чтобы в подобное инвестировать.
Очень грустно, что у нас как класс отсутствует нормальное загородное жилье. По какому фактору ни возьми, везде получишь страшную неоднородность. А если все хотя бы просто нормально, то "неоднородность" будет в цене таког объекта.
И то, что мыслящие энергичные девелоперы в поисках своей целевой аудитории вынужденно идут в сторону повышения класса своих объектов (порой даже надуманно), тоже очень показательно.
Можно проще сказать: у всех управленческих решений есть различные последствия на различных сроках, и сила хорошего руководителя в том, чтобы держать баланс между сделать как будет лучше прямо сейчас и сделать как будет лучше потом. Многие к сожалению перегибают в сторону первого.
А критическое мышление ваше вполне можно сделать внешней функцией - найти в коллективе человека, который на себя эту роль возьмёт, и к нему прислушиваться.
Звучит как обвинение в несправедливости. Но если включить немного объективности, то окажется, что затраты компании и кандидата на собесе сопоставимы. Надо просто учесть цену часа кандидата и совокупные цены часов тех людей, которые с ним со стороны компании дело имеют.
Да уж, автор позорник. Таких точек помимо полюса есть еще бесконечно много расположенный на удалении от второго полюса на 1+2пи/к вроде так. В ощем смысл в том что 1км на запад можно ходить по кругу один или более раз.
И кстати, мне эту задачу задавали на собесе в 2004 году, когда ещё Илон Маск сам наверное джуном был. Одним словом, это явно не его задача а кого-то постарше )
Всё это конечно прекрасно, но я вот уже в который раз сталкиваюсь с тем, что в коллективах, много лет номинально живущих по эджайлу, не выполнены пре-реквизиты: не определены стейкхолдеры, спонсоры, не закреплены границы продуктов. Отдельная проблема в том, что бизнес может быть большим, и для эффективной работы ему нужна какая-то базовая "архитектура" самой компании и межведомственного взаимодействия, которая сама по себе снизу-вверх не рождается.
В итоге "гладко было на бумаге, но забыли про овраги".
Ну войти получилось, молодец, поздравляю. Но самое интересное же внутри )
Не раскрыта тема применимости данного метода (и вообще любых джойнов в потоке) при условии несовпадения моментов появления данных в СИ. Понятно, что у флинка есть некое "окно", и он в памяти держит сколько-то недавно прочитанных записей - но во-первых, неплохо бы описать настройки этого "окна", а во-вторых как быть если его не хватило? - искать эти "не совпавшие по времени прилета" записи уже в СП? - окей, так можно, но для чего тогда вообще весь этот огород с флинком?
Бизнес никогда - нет, НИКОГДА!!! - не даст ресурсов чтобы уже работающее и приносящее профит переделать "как следует". Даже могу рассказать почему так, но это отдельно. Поэтому у технаря есть толька два варианта - либо сразу заложить запас на развитие в своей конструкции либо переделывать уже работающее тихо незаметно в свободное время. А если бизнес отличается "плодовитостью" на гипотезы и эмвипишечки, то технарь обязан быть провидцем и понимать, что из этого перспективно, а что заведомо чушь - и штуки стоящие делать с запасом прочности, а ерунду делать так, чтобы потом как можно дешевле было ее выкинуть.
Есть две реальности. Первая - идеальный мир специалиста: заказчик знает что ему нужно и может это выразить письменно, понятен срок и критерии приемки, есть достаточно ресурса и компетенций для выполнения. Вторая реальность - идеальный мир заказчика (бизнеса): ничего не понятно и нет способа разобраться кроме как попробовать и оценить результат (что еще тоже надо придумать как делать), надо бежать одновременно в разные стороны, проверять по N гипотез в месяц, уметь запускать АВ-тесты десятками, внедряться в пром за 15 минут и отчетность видеть в реальном времени.
Кажется, что совместить невозможно, но в этом и есть "магия айти". Для меня лично основная проблема в том, что хотелки бизнеса растут со скоростью, превышающей рост возможностей ит-команд, нарастает разрыв между ожиданиями и реальностью. А людей, которые этот разрыв должны контролировать, заполнять и удерживать приемлемым (это архитекторы, сильные синьоры и ит-менеджмент), нету в достаточном количестве и качестве. Поэтому часто происходит потеря контроля над ситуцией и бизнес улетает в космос и далее все по худшему сценарию вашей статьи.
В 99% случаев упускается главное - ЗАЧЕМ инженеру работать БЫСТРЕЕ своего собственного внутреннего уровня нормы? К потере удовольствия от работы и к выгоранию это приведет непременно, а денег дополнительных сильно много не принесет. Да и бизнес во многих компаниях спешит не потому что это реально необходимо, а потому что конкретным менеджерам так хочется по каким-то личным причинам.
Соглашусь, что умеренный напряг в планах (на 20-30% от "нормы") это ок, но напряг вдвое-втрое опытного работника (который сразу это видит и понимает, что сделать никак не получится) только демотивирует окончательно.
Есть пределы у этой формулы - конкретный разработчик даже если будет очень хорошо замотивирован (финасово и не только) имеет небесконечную производительность. Желания менеджеров же могут запросто быть нереальными.
Да вроде нету проблемы себя уволить )
Это эксплуатация вашего энтузиазма. Но если считаете, что она адекватно оценена в ваших условиях труда, то видимо всё в порядке.